昨天下午，我們團隊的一位工程師在 SaaStr 舞台上看到 Anthropic 展示他們內部的 GTM 技術堆疊，截了一張投影片的圖，然後向 Zero 提了一個問題：這裡面哪些是我們還沒有的？ 六小時十九分鐘後，Snowflake 已在生產環境上線，供所有 Zero 客戶使用。這是我們一年內推出的第 180 多個整合，而且越來越多時候，撰寫下一個整合的人根本不是工程師。以下是讓這一切成為可能的框架，以及建立在其上的內部技能。
代理人平台沒人告訴你的事
LLM 就像一顆裝在瓶子裡的大腦。光靠它自己，它可以幫你寫一首關於資料倉儲的詩，但它無法真正打開它。將聊天機器人變成代理人的關鍵——也就是你的團隊真正付費購買的東西——在於代理人能否深入你已在使用的工具，並在其中實際完成工作。
我們將這種觸及能力稱為連接器層。在打造 Zero 一年後，我們相信這是代理人產品中最重要的基礎設施。因此我們自己打造了它。更重要的是，我們圍繞它建立了一套工作流程，讓團隊中的任何人都能自行開發連接器。
為什麼不用 MCP，為什麼不用 Zapier
這兩個選項在早期都有人問過我們。它們各有所長，但都不是我們需要的。
MCP 是一種協定，不是產品。對於希望自己的服務能被任何 LLM 呼叫的工具開發者來說，它非常出色。但目前部署的 MCP 伺服器會給模型一份工具清單，並信任它能安全地呼叫這些工具。它沒有每個組織專屬的憑證保險庫、沒有限制哪些端點可被存取的防火牆、也沒有能將呼叫追溯到授權人類的稽核日誌。對於一個代理人可能同時接觸客戶生產環境中的 Stripe、另一個代理人可能在 CEO 的 Gmail 中起草郵件的產品來說，「信任模型」根本不算是一種安全模型。
Zapier 式整合平台解決的是另一個問題：它們將確定性的觸發器連接到確定性的動作。代理人的運作方式並非如此。代理人會在思考過程中臨時決定，下一步是查詢 Snowflake，然後建立一張 Linear 工單。它需要的是立即可用的憑證、有範圍限制的 HTTP 客戶端和稽核追蹤，而不是預先建立好的自動化流程。
因此我們做了最務實的事：建立一個整合登錄檔，其中每個條目都包含驗證元資料、指定哪些密鑰要注入沙箱的環境對應、允許存取的主機防火牆，以及處理 OAuth 或 token 特殊情況的小型處理器。這就是基礎設施。
但基礎設施並不是這個故事最有趣的部分。最有趣的部分是在它之上發生的事。
讓每個人都能開發連接器的技能
每天大約有兩個新的 SaaS 工具進入我們的整合待辦清單。有些來自客戶的需求，有些來自團隊成員發現 Zero 無法完成他們需要的事，有些來自業務開發對話，其中潛在客戶的技術堆疊包含我們尚未支援的工具。
如果每一個都必須排進工程師的佇列，我們一週只能推出一個。但我們現在一天就能推出一個。
原因在於一套我們稱為連接器開發技能的內部工具。它是一個 Zero 技能，形式與我們提供給客戶的相同，但指向我們自己的程式碼庫。當團隊中的任何人說「我想新增 Notion 連接器」時，Zero 會引導他們完成整個流程：
- 從使用者情境出發。 使用者實際上想用這個工具做什麼？「查詢資料庫」、「建立頁面」、「在工作區中搜尋」。技能堅持在動到任何檔案之前，先確立具體的使用者故事。連接器的目標是賦予代理人某種能力，而不是對 API 進行全面封裝。
- 確認驗證形式。 OAuth、API token，或兩者皆有。技能了解每種形式的含義：OAuth 需要同意介面和重新導向的配置；API token 需要每個組織的密鑰注入，以及使用者取得 token 的方式。開發者選擇符合工具的形式，後續所有事項都由此衍生。
- 將端點對應到使用情境。 不是「封裝整個 REST API」，而是只選取能滿足使用者故事的少數端點。三個精心挑選的端點，勝過四十個代理人從不使用的端點。
- 產生十二個檔案。 登錄檔條目、處理器、防火牆規則、平台圖示、環境對應配置，以及教導 Zero 如何使用連接器的代理人技能。技能負責產生骨架，開發者負責填入意圖。
- 開啟兩個 PR。 一個提交到連接器框架，一個提交到技能函式庫。兩者都會由工程師審查，但審查的重點是正確性，而不是教導開發者如何使用框架。
過去需要大量內部知識的事情（選哪種驗證形式、選哪些端點、哪十二個檔案要放在哪兩個 repo、防火牆規則如何與動態子網域組合）現在都由技能本身承載。開發者帶來的是對使用者的理解，技能帶來的是骨架。
這就是為什麼設計師、業務開發主管或產品經理最終也能推出連接器。他們知道使用者想要什麼，技能則知道其他一切。
案例研究：昨天的 Snowflake
昨天 Anthropic 在 SaaStr 舞台上展示了他們內部的 GTM 技術堆疊：Salesforce 作為系統記錄、Clay 用於資料豐富、LeanData 用於路由、Gong 用於通話、Jira 用於工單、Intercom（Fin）用於客戶支援、Ironclad 用於合約、Snowflake 作為資料倉儲。[演講連結]
我們的一位工程師截了那張投影片，丟進 Zero，只問了一個問題：「這些工具裡，我們缺少哪些連接器？」
以下是隨後發生的實際時間軸，所有時間均為 PDT。
16:59。 截圖送達。Zero 將其與連接器目錄進行比對：10 個工具中有 7 個已存在（Salesforce、Gong、Jira、Intercom、Ironclad、Gmail、Slack）。三個缺失（Clay、LeanData、Snowflake），其中 Snowflake 被標記為最有價值的，因為資料倉儲是 GTM 技術堆疊的基礎。回覆在 17:00 送達。
17:01。 追問：「這些工具哪些可以做成 api-token 連接器？」Zero 查閱驗證文件：Clay 有個人 API 金鑰，Snowflake 最近推出了程式化存取 Token，LeanData 僅支援 OAuth 且與 Salesforce 綁定。 結論在 17:02 出爐：先做 Snowflake（價值最高、驗證最簡潔），再做 Clay。
17:04。 工程師說「開始」。連接器開發技能接手。到 17:07，它已將 Clay 排除在外（唯一的公開介面是每個資料表的 webhook，沒有真正的連接器可以建立），並確認了 Snowflake 的形式：SNOWFLAKE_PAT 密鑰 + SNOWFLAKE_ACCOUNT 變數，對 Snowflake REST API 和 SQL API v2 使用 bearer 驗證，動態子網域防火牆規則參照 Zendesk 的模式建立。
17:35。 兩個 PR 在同一分鐘開啟：
vm0-skills#176：面向代理人的技能。如何撰寫 Snowflake SQL、格式化結果、在暫時性錯誤時重試。vm0#13356：連接器本身。登錄檔條目、PAT 處理器、防火牆產生器、平台圖示、環境對應配置。
18:22。 技能 PR 合併。
18:42。 連接器 PR 合併。
18:52。 發布 PR 自動開啟。
23:18。 [email protected] 及其餘發布列車部署至生產環境。Snowflake 對所有組織上線。
從「Anthropic 技術堆疊的截圖」到「Zero 可以查詢你的資料倉儲」，共花了六小時十九分鐘。一位工程師，一段對話，零次移交給「連接器團隊」。
這裡的高效率並不是因為工程師跑得快，而是因為連接器開發技能承擔了過去需要大量內部知識的部分：選擇哪種驗證形式、哪些端點對應到使用者情境、哪十二個檔案需要放進哪兩個 repo、防火牆規則如何與動態子網域組合。開發者寫的是意圖，技能寫的是骨架，生產環境完成了其餘的事。
這就是這個框架帶給我們的價值。不只是速度（雖然速度確實很快），更重要的是誰可以承擔這項工作。Snowflake 的開發者碰巧是一位工程師，但他不必是。
為什麼 api-token 是一等公民
這個值得單獨提出的附注，是一個讓人出乎意料的刻意設計選擇。
大多數代理人平台將 OAuth 視為唯一正統的驗證方式，把 api-token 當作舊系統的備用方案。我們恰恰相反。API token 在我們的連接器模型中是一等公民，擁有相同的同意介面、相同的每組織保險庫、相同的稽核追蹤、相同的防火牆執行。
原因有兩個。
第一，api-token 驗證的首次使用時間更短。Snowflake 最近推出程式化存取 Token 正是出於這個原因：長效、可限制範圍、可撤銷的憑證，不需要走一遍 OAuth 流程。擁有 PAT 的使用者可以在不到一分鐘內在 Zero 中開始工作。OAuth 流程即使再順暢，也需要更長時間，並對使用者要求更多。
第二，OAuth 並非總是可用。有些企業工具根本不提供 OAuth，或者將其鎖在企業版方案之後。將 api-token 視為對等選項（而非備用方案），意味著我們可以妥善支援這些工具，而不是讓它們躺在「即將推出」的墓地裡。
昨天上線的 Snowflake 連接器使用的是 api-token。傳送客戶郵件串的 Gmail 連接器使用的是 OAuth。兩者都經過相同的框架、相同的技能、相同的審查流程。開發者選擇符合工具的形式，框架讓兩種形式的建置成本都很低。
180 多個整合真正解鎖了什麼
數字本身不是重點。重點是在這種密度下，代理人不再是你召喚的工具，而是你生活其中的環境。
當 Zero 同時連接你的 CRM、你的資料倉儲、你的客服信箱、你的設計工具和你的程式碼庫，它能做到任何單一整合代理人都無法做到的事。它可以執行 Snowflake 查詢，與未解決的 Linear 工單交叉比對，然後在客戶成功團隊所在的 Slack 頻道發布摘要。它可以閱讀一通 Gong 通話記錄，找到潛在客戶詢問的功能，確認它是否在產品路線圖上，然後起草後續跟進郵件——全部一氣呵成。
每個新連接器帶來的價值不是線性增長，而是組合式增長。第 180 個連接器比第 1 個更有價值，因為它能與前面 179 個組合使用。
這是這個框架背後的賭注。而技能背後的賭注是：複利增長的速度，取決於你的團隊中有多少人被允許為這堆積木添磚加瓦。
接下來
我們正在努力將連接器開發技能開放給客戶使用。如果你正在為你的團隊使用 Zero，並且需要整合某個內部工具（你的帳務系統、你的資料倉儲、你的自訂內部管理後台），昨天用來推出 Snowflake 的那套工作流程，就是你用來推出自己整合的工作流程。相同的骨架、相同的驗證模型、相同的防火牆、相同的稽核追蹤，只是換了一位開發者。
如果這讓你感興趣，我們很樂意聊聊。
