昨天下午，我們團隊的一位工程師在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需要同意UI與重導流程；API Token則需每組織密鑰注入，以及使用者如何取得Token。作者選擇最符合工具的方式，後續流程自動展開。
- 對應端點到情境。 不是「包覆整個REST API」，而是只挑出能滿足使用者故事的幾個端點。三個精選端點的連接器，勝過四十個智能體永遠不會用到的端點。
- 產生十二個檔案。 註冊表項目、處理器、防火牆模式、平台圖示、環境對應流程、教導Zero如何使用連接器的智能體技能。技能負責產生架構，作者負責撰寫意圖。
- 開啟兩個PR。 一個到連接器框架，一個到技能庫。兩者都由工程師審查，但重點在於正確性，而不是教作者如何運作框架。
過去需要組織知識（哪種驗證方式、哪些端點、哪十二個檔案、哪兩個repo、動態子網域的防火牆模式如何組合），現在都由技能本身承擔。作者帶來使用者同理心，技能帶來架構。
這就是設計師、業務開發主管或PM也能推出連接器的原因。他們知道使用者要什麼，技能知道其他一切。
案例研究：昨天的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最近推出Programmatic Access Tokens，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在我們的連接器模型中是第一等公民，擁有同樣的同意UI、每組織保管、稽核追蹤與防火牆控管。
原因有二。
首先，api-token驗證的首次使用時間更短。Snowflake最近推出Programmatic Access Tokens正是為此：長效、可控範圍、可撤銷的憑證，不需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的同一套工作流程，也將是你打造自己連接器的流程。相同架構、相同驗證模型、相同防火牆、相同稽核追蹤，不同的作者。
如果你有興趣，歡迎與我們聯絡。
