superglue：用自然語言描述映射，把 ERP 與長尾系統接起來

它想取代的不是 ETL 工具，而是導入專案裡的人力協調

多數整合產品的問題設定是「資料怎麼從 A 搬到 B」，superglue 的問題設定更前面一層：ERP 或企業系統導入時，真正吃掉時間的是來回確認欄位對應、清理歷史資料、上線後維持同步這類需要人協調的工作。README 舉的對照是 Sage Intacct 遷移：手動用 Excel 轉換、每份總帳歷史要清理十到十五輪、單一專案耗掉 140 小時；改成用自然語言描述映射後，185 個科目在一小時內完成遷移。這組數字來自專案自己的說明，不是第三方驗證的結果，閱讀時要當成廠商敘事而非基準測試。

目標讀者因此不是資料工程團隊，而是負責客戶導入的顧問公司、企業內部的 IT 與財務系統負責人，以及想為 AI agent 建立受治理資料存取層的平台團隊。README 用「governed data access」與「track data usage across your org」描述後者，意思是它同時想當 AI 平台與內部系統之間的閘道，而不只是排程搬資料的管線。這個定位讓它跟傳統 ETL 的比較基準不同：後者比的是吞吐與轉換算子，superglue 比的是描述一個映射需要多少人力。

機制：agent 從公司知識推導，而不是從預先寫好的連接器清單挑選

README 的關鍵句是「learns how your systems work from your company's knowledge」，並且強調它處理的是「the implementation that normally requires human coordination and engineering work」。把這兩句放在一起讀，可以看出架構上的取捨：它不是靠一份預先寫死的連接器目錄去覆蓋每個 SaaS，而是讓 agent 依你提供的知識去推導某個系統怎麼運作，再產出整合與工具。

支援清單的寫法也印證這點。README 先宣告「works with any REST, GraphQL, SOAP, file-based, or database system」，後面那一長串 ERP、CRM、資料庫、專案管理、通訊、支付、電商、HR、DevOps、分析、廣告、檔案協定、客服、CMS、身分驗證、AI 與垂直系統的名單，讀起來更像「這些是我們已經看過的類別」，而不是「這些是我們寫好的連接器」。清單末端那句「and any system with an API, database, or file connection」把範圍開到最大，但也意味著覆蓋深度取決於 agent 對該系統的理解，而不是取決於某個連接器版本的成熟度。

倉庫層面能確認的只有：主要語言 TypeScript，預設分支 main，另有 npm 上的 @superglue/client 客戶端 SDK。README 沒有描述內部資料流、agent 如何取得公司知識、或產出的工具以什麼形式執行。這些都必須回到 docs.superglue.cloud 才可能找到，本文不對此推測。

跑起來的兩條路：雲端註冊，或自架 Docker 映像

README 的 Quick Start 只有兩個選項，沒有第三條。選項一是到 app.superglue.cloud 註冊後直接開始建置；選項二是自架，README 給的說明是「Self-host for maximum control and customization」，並把實際步驟指向 docs.superglue.cloud/getting-started/setup 的 self-hosted 章節。也就是說，倉庫本身沒有提供可照抄的安裝指令，只有指向文件站的連結。

能從 README 確認的部署線索是 Docker：徽章連到 hub.docker.com/r/superglueai/superglue，映像名稱為 superglueai/superglue。若要走自架，這是唯一在 README 出現的具體部署產物。至於需要哪些環境變數、要不要外接資料庫、agent 使用的模型金鑰怎麼設定，README 一律沒有交代，必須查文件站。

客戶端側則有 npm 套件 @superglue/client，這是 SDK 而非主服務。README 沒有給出任何一行呼叫範例，所以本文也不示範 API 形狀。實務上，第一次評估的順序應該是先讀文件站的自架章節，確認相依服務清單，再決定要不要拉 Docker 映像；跳過這步直接部署，很可能卡在文件沒寫進 README 的前置條件上。

授權是 FSL，不是開源授權，這點會決定能不能用

README 的 License 段落寫得很短：superglue 本體是 FSL 授權，客戶端 SDK 是 MIT 授權，細節見 LICENSE 檔案。倉庫的授權標示是 NOASSERTION，代表自動偵測無法判定，必須人工讀 LICENSE 才能確定條款。

FSL（Functional Source License）不是 OSI 認可的開源授權，它的常見結構是限制你把軟體用於與原廠競爭的商業用途，並在特定期間後轉為較寬鬆的授權。實際的限制範圍、競爭用途怎麼定義、轉換期多長，全部寫在 LICENSE 裡，本文無法從 README 得知，也不提供法律意見。可以確定的是：如果你的組織有一條「只用 OSI 認可授權」的規則，superglue 本體會直接卡在這條規則上，而 @superglue/client 的 MIT 授權不影響主服務的授權判斷。

另一件 README 明講的事是貢獻流程：所有貢獻者必須先讀 CONTRIBUTING.md 並簽署 Contributor License Agreement。CLA 加上 FSL，意味著這個專案的程式碼主導權集中在原團隊手上，外部貢獻者要接受這個前提。

維護成本的來源是 agent 行為，不是版本升級

對這類工具，升級成本通常不是「改了幾行程式」，而是「agent 產出的映射行為有沒有變」。README 完全沒有提到版本號、發行說明或升級路徑，檢索到的近期發行記錄也是空的。這代表兩件事：第一，無法從現有材料判斷它的發版節奏與破壞性變更政策；第二，任何關於「升級很平滑」的說法都沒有依據。

可以合理推論的是相依面。自架要跑 Docker 映像，agent 要能取得公司知識並呼叫外部系統，因此維運成本會落在模型供應商的金鑰與額度、對外網路與憑證管理、以及整合目標系統的 OAuth 憑證更新上。README 的 topics 裡出現 oauth2，支援清單裡有 Auth0 與 Okta，但沒有說明憑證如何儲存與輪替，這是要在文件站確認的項目。

長期成本還有一項常被忽略：如果映射邏輯是由自然語言描述生成，那麼描述本身就成了需要版本控制的資產。README 沒有交代這些描述存在哪裡、能不能匯出。若你的合規要求是「所有資料轉換規則必須可審計、可重現」，這一點必須先問清楚再採用。

什麼時候它是錯的工具

第一種情況是規模很小、系統固定的整合。如果你只是要把 Stripe 的付款事件同步到內部 Postgres，寫一支 webhook 接收器加上重試邏輯，可能一個下午完成，而且行為完全可預測。引入一個需要自架、需要模型呼叫、授權又非開源的平台，換來的是不確定性而不是效率。

第二種情況是對寫入路徑要求嚴格可審計的環境。agent 依知識推導系統運作方式，本質上是把部分判斷交給模型。README 強調「governed data access」與使用追蹤，但沒有說明治理機制是規則式白名單、人工審核關卡，還是事後日誌。金融、醫療這類需要事前審批每個欄位映射的場景，必須先確認治理是事前還是事後，否則不該上線。

第三種情況是目標系統完全不在支援範圍內，而且沒有穩定的 API、資料庫或檔案介面。README 把適用範圍寫成「any system with an API, database, or file connection」，反過來說，沒有這三者之一的系統（例如只有桌面用戶端、只能人工操作的舊系統）不在它的射程內。

第四種是團隊無法承擔維運。自架路線要自己顧 Docker 映像、相依服務與模型金鑰；雲端路線則是把資料與流程放在 app.superglue.cloud 上。兩條路都有明確的代價，README 沒有提供第三條折衷方案。

替代路線：寫死的連接器，或自己組 agent 管線

最直接的替代是傳統 iPaaS 與連接器框架，例如 Airbyte 或 Meltano 這類以連接器目錄為核心的工具。差異在問題設定的層次：它們提供的是已經寫好、版本化的連接器，你選一個、填憑證、設定同步頻率，行為可預期且可重現；代價是遇到目錄裡沒有的系統，你得自己寫連接器，而且每個新系統都是一次工程投入。superglue 反過來，把「沒有現成連接器」當成預設情境，用 agent 去推導，代價是行為的可預測性下降，且需要治理機制補上。

另一條路是自己用 LLM 框架組管線，例如以 function calling 搭配 MCP 伺服器，把每個內部系統包成工具，再讓 agent 呼叫。這條路控制力最強，你可以決定每個工具的輸入輸出schema、審核關卡與日誌格式；代價是這些你都得自己寫，而 superglue 想省下的正是這部分。README 的 topics 裡同時出現 function-calling 與 mcp，說明它與這條路線並非互斥，比較像是把後者包成產品。

選擇的判準可以簡化成一句：你要的是「連接器目錄的確定性」，還是「描述映射的省力」。前者選 iPaaS，後者才輪到 superglue。兩者混用的情況也存在，例如用 iPaaS 處理穩定的高頻同步，用 superglue 處理一次性的歷史資料遷移與長尾系統。

編輯結論

如果你的團隊正在處理 ERP 導入、歷史資料搬遷，或要為多個內部系統建立受治理的 AI 資料存取，而且願意接受 FSL 授權與自架維運成本，superglue 值得先跑一次自架流程再評估。若你只需要三五個固定 SaaS 之間的點對點同步，或組織政策不接受 agent 依知識庫自動生成寫入邏輯，它會是過重的工具。動工前先確認三件事：LICENSE 檔案的 FSL 具體條款與變更日期、docs.superglue.cloud 上自架章節列出的環境變數與相依服務、以及你的目標系統是否落在 README 那份支援清單內。

官方來源

1. Issues
2. Project website
3. README
4. superglue-ai/superglue on GitHub