W讀Podcast｜50,000 個工具塞給 AI Agent，它不會當機嗎？Composio CTO 聊 Smart Tool 的真正門檻

TL;DR

Composio 提供超過 50,000 個工具、橫跨 1,000+ 個 App，透過單一介面讓 AI Agent 存取。但核心價值不是工具數量，而是 just-in-time tool discovery 和持續學習機制，避免 Agent 被塞爆 context window
他們的工具整合 pipeline 由 3 個人的團隊搭建，主要靠 Agent 自動生成。上個月光 token 費就花了 10 萬美金，已經超過人力成本
Skills 可以跨模型使用：用 Opus 建立 skill，換 Sonnet 執行，90-95% 的 skill 直接能用。這對避免 model lock-in 有很大意義
Composio 有 133 個 Intercom 工具，理論上你可以自建 support agent 取代 Fin，成本可能只有十分之一。Build vs Buy 的天秤正在往 build 傾斜
MCP vs CLI 之爭不會有單一贏家，兩者會共存。Composio 準備推出 Universal CLI，一個 CLI 管所有 App

Podcast 與來賓背景

這集在 2026 年 3 月 22 日播出的 The Cognitive Revolution，是由 Nathan Labenz 主持的 AI 深度訪談節目，專門找 AI 領域的 builder、研究者和產業玩家來聊最前線的技術趨勢和產品思維。Nathan 本身是 Waymark 的創辦人，對 AI 的實際應用有很扎實的第一手經驗，所以他的提問通常不會停在表面。

這集的來賓是 Karan Vaidya，Composio 的共同創辦人兼 CTO。Composio 簡單講就是 AI Agent 的工具執行層（agentic tool execution layer），讓你的 Agent 可以透過單一介面存取幾乎所有你用得到的 SaaS 工具。目前已經有 AWS、Zoom、Glean、Airtable 這些大公司在用他們的服務來建構自己的 Agent 產品。Karan 是 IIT Bombay 電腦科學出身，現在人在舊金山。這集是贊助集，但 Nathan 先玩了兩週才錄的，所以觀點算是有實測基礎。

給 Agent 一千把刀，它會先捅自己

Nathan 在節目一開頭就用了一個很精準的比喻：Composio 是 AI Agent 的瑞士刀。但 Karan 馬上接了一句讓我印象很深的話：如果你真的把一千把刀同時遞給 Agent，它會「用錯的那把刀自殺」（suicide via context overload）。

這個觀察太真實了。

任何認真在用 Claude Code 或 OpenClaw 的人都知道，context window 的注意力機制不是免費的。你塞越多工具進去，模型的表現就越差。這跟人類一樣，你桌上同時攤開二十份文件，效率絕對比只看三份低。所以 Composio 真正要解決的問題，不只是「怎麼讓 Agent 連上更多工具」，而是「怎麼在對的時間，只給 Agent 對的工具」。

Just-in-Time Tool Discovery：別什麼都塞進 Context

Composio 的做法是 just-in-time tool discovery。Agent 不會一次看到所有 50,000 個工具，它看到的是一組精選的少量工具，然後根據當下任務需求，動態載入新的工具到 context 裡。

這個設計很聰明。因為你想想，如果使用者今天只是要處理 email，Agent 根本不需要知道 Shopify 的 API 長什麼樣子。把所有工具都塞進去只會分散注意力，降低準確度。

在之前寫的前 OpenAI 工程師的 Coding Agent 使用心法：Context 管理、CLI 為王、測試先行有聊過類似的概念：context engineering 的本質就是「少即是多」。Composio 把這個原則用在工具層，邏輯是一樣的。

而且在 developer 端，Composio 其實有兩種產品定位。一種是給個人使用者（prosumer），你在 Claude Code 裡加一行 MCP server 設定就搞定，不用再一個一個去設 Google Drive 的 OAuth、Slack 的權限、Datadog 的 API key。另一種是給企業開發者用的 SDK，提供完整的 auth 管理、scope 控制、sandbox 執行環境，還有 governance 和 observability。

Nathan 自己就分享了一個很有感的經驗：他想幫同事設好 Claude Code 連 Google Drive，結果光是跑一遍 OAuth 流程就搞得七葷八素。這種痛我相信每個用過 Cloud Code 接 Google 服務的人都懂。

持續學習：工具會自己進化

Composio 最有意思的技術亮點，我認為是他們的 continuous learning 機制。

整個流程是這樣的：他們有一條內部的 Agent pipeline，負責自動建立和維護所有工具整合。當線上的 Agent 在使用某個工具時出了問題，比如一直 error 或模型看不懂工具描述，系統會在背景自動觸發那條 pipeline，即時產生一個新版本的工具，然後直接換進 Agent 的 context 裡。

更進一步，他們還會把 Agent 的執行軌跡（agentic trajectory）轉換成 skills。舉個例子：如果 Agent 為了完成一個任務繞了一大圈（Karan 稱之為 zigzag trace），系統會把那段彎路壓縮成一條直線，變成一個可重複使用的 skill。下次遇到類似任務，Agent 直接走捷徑。

這個機制解決了一個很根本的問題：官方文件經常是錯的或不完整的。Karan 提到，因為他們的工具被成千上萬個 Agent 用各種方式戳過，結果發現很多 App 的官方文件根本沒寫對。Google Calendar 就是一個具體例子，他們的工具已經比官方文件建議的方式更好用了。

這種「被大量 Agent 戳出來的品質」，就是 Composio 的護城河。你自己包一個 API wrapper 很快，但要累積幾萬次實際使用的 edge case 經驗，那是另一回事。

Skills 是對抗 Model Lock-in 的解藥

這集裡面我覺得最值得記下來的觀點：Skills 可以讓你在不同模型之間自由切換，而且可靠度在 90-95%。

Karan 的實際做法是：用 Opus 來建立 skill（因為 Opus 比較聰明，第一次導航和探索的能力更強），然後日常執行時換成 Sonnet（速度更快、更便宜）。他說這個組合的效果「phenomenally well」。Haiku 不行，但 GPT 系列大概有 90% 的 skill 可以直接套用。

他的論點是：所有 frontier model 都已經很會 follow instructions 了。如果你的 skill 寫得夠詳細，包含了完整的執行路徑、步驟、注意事項，那模型之間的差異就被 skill 吸收掉了。

這跟我之前在用過 Claude Sonnet 4.5 的龍蝦 OpenClaw 再回頭看便宜模型：OpenRouter 多模型實測心得聊到的邏輯可以對照著看。當時的結論是便宜模型省的是 API 成本，花的是你的時間成本。但如果有了 well-defined skills，這個等式可能會改變，便宜模型真的就夠用了。

不過 Karan 也坦白承認，跨 provider 還是有一些行為差異。比如 Anthropic 的模型在 polling（輪詢）這種 agentic 行為上做得比較好，Agent 會自己寫等待邏輯。但 GPT 遇到需要 polling 的情況就會停下來等 user input。這些 nuance 會導致 5-10% 的 skill 需要調整。

Composio 正在開發的解法是「meta skills」，專門把 skill 從一個 provider 翻譯到另一個 provider，進一步降低切換成本。老實說，如果這個做到位了，model provider 的定價權會被大幅削弱。

Intercom Fin 的 99 美分，能被 10 美分取代嗎？

Nathan 在節目裡做了一個很有意思的思考實驗。

Intercom 的 Fin agent 可以自動解決大約 70% 的客服 ticket，定價是每次 99 美分。這是一個很成功的產品，Intercom 也因此成為「傳統 SaaS 成功轉型 AI」的典範案例。

但 Nathan 發現 Composio 上有 133 個 Intercom 相關的工具，基本上覆蓋了 Intercom 平台的所有功能。所以他的問題是：如果我用這 133 個工具，搭配自己定義的 skill，是不是可以自建一個比 Fin 更客製化的 support agent，而且 token 成本可能只要 10 美分？

Karan 的回答很務實：Fin 對很多公司來說還是很棒的產品，因為不是每間公司都想花時間自己建。但如果你需要高度客製化，或是想控制 Agent 可以存取哪些 App、做哪些動作，自建確實給你更大的自由度。

這跟之前在 SaaSpocalypse 來了，但不是所有軟體公司都會死聊到的趨勢一脈相承。AI Agent 正在把 Build vs Buy 的天秤往 Build 那邊推。不是所有 SaaS 都會死，但按人頭計費的模式會越來越難賣，尤其是那些核心功能可以被一組工具加一個 skill 取代的產品。

Karan 對 SaaS 產業的看法也很有層次。他認為底層基礎建設（AWS、雲端服務）只會越來越強，因為軟體越好寫，用量只會越大。但上層的 SaaS App，競爭會集中在「誰的 agentic interface 做得更快更好」。Salesforce、Slack 這些老牌子動得夠快就能活，動太慢就會被新創用新的 interface 包抄。

三個人管 Pipeline，Token 帳單超過人事成本

這集最讓我驚訝的數據：Composio 負責建構和維護整個 Agent pipeline 的核心團隊，只有三個人。整間公司大約 15 人。上個月光是那條自動建構工具整合的 pipeline，token 費用就花了大概 10 萬美金。

Token 成本已經超過人事成本了。

這是一個很具體的案例，說明 AI-first 公司的成本結構長什麼樣子。他們需要更多人，但不是要更多人去寫 code，而是要更多人去「管理 Agent」。Karan 的原話是：「We need more humans to spend more tokens.」

我的理解是，這個模式下的人才瓶頸不在寫程式的能力，而在判斷力。你要能判斷 Agent 做的決定對不對、pipeline 生出來的工具品質夠不夠好、哪些 edge case 需要人為介入。這跟傳統軟體公司的人力需求完全不一樣。

MCP vs CLI：不需要選邊站

最近 Twitter 上 MCP vs CLI 吵得很兇，尤其是 GitHub CLI 出來之後。Karan 的立場很明確：這會是一個雙極世界，兩者共存。

他的觀察是：GitHub CLI 已經被工程師用了很久，模型的 pre-training data 裡就有大量使用案例，所以模型天生就很會用 CLI。但 MCP 也已經進入 post-training data 了，因為 Claude Code 和 Codex 這些工具大量使用 MCP，模型對 MCP 的理解也在快速提升。

從企業角度，MCP 在 observability（可觀測性）和 traceability（可追溯性）上有優勢，所以更適合需要 governance 的場景。CLI 則在工程師的日常開發流程裡更自然。

Nathan 的看法我也同意：這個辯論可能有點小題大作了。兩種方式都能做到類似的事，現在的差異會隨著工具成熟而縮小。就像 REST vs GraphQL，最後大家都在用，沒有誰「贏了」。

Composio 兩邊都押：已經有 MCP server，同時也在 2026 年 3 月底推出 Universal CLI，一個 CLI 管所有 App。

Agent 時代的工具生態

除了傳統 SaaS 工具的整合，Karan 也提到了一類新的工具：專門為 AI Agent 設計的 agent enabler tools。包括記憶層（mem0、Zep、SuperMemory）、支付層（Skyfire）、搜尋層（Exa、Firecrawl、Tavily）。

這些工具的共同點是它們解決的問題在 AI Agent 出現之前根本不存在。Agent 需要跨 session 的記憶、需要自己付款購買服務、需要即時搜尋最新資訊。這些需求催生了一整個新的 infra 層。

Composio 的策略是跟這些 agent enabler 全部合作，讓使用者在 Composio 的介面裡就能啟用這些服務，甚至計畫推出 premium toolkit，用單一錢包就能付費使用所有第三方服務。

這個方向我覺得很聰明。降低使用者的 onboarding 摩擦力一直是最有效的競爭策略。

幾個值得記住的判斷

整理一下這集對我來說最有價值的幾個 takeaway：

Context engineering 就是 tool engineering。 Composio 做的事情本質上就是幫 Agent 工程化 context。什麼時候載入什麼工具、載入多少、怎麼描述這些工具讓模型看得懂，這些都是 context engineering 的延伸。

Skills 是跨模型的可攜資產。 如果你投入時間建立高品質的 skills，這些 skills 可以在不同模型之間遷移。這意味著你的投資不會因為換模型而歸零。

Token 成本正在取代人力成本。 Composio 的案例顯示，在 AI-first 的公司裡，token 帳單已經是人事成本的好幾倍。這個趨勢只會加速。

Build vs Buy 的答案正在改變。 當工具的取得成本趨近於零，customization 的成本也在下降，越來越多公司會選擇自建而非購買現成方案。

這個產業變化的速度真的太快了，每週都有新的範式出現。但有一個原則大概不會變：誰能在對的時間給 Agent 對的 context，誰的 Agent 就做得最好。

想看更多這類 AI Agent 和產業趨勢的分析，可以訂閱 wilsonhuang.xyz，後續更新都會發在那裡。