Composio：agent 會不會做事，常常卡在工具整合，而不是模型智商

很多 agent 專案看起來卡在 reasoning，其實更常卡在工具整合。

模型可以規劃得很漂亮，說要查 Gmail、建 Jira ticket、讀 Notion、改 GitHub issue、寄 Slack 訊息。可是到了真的執行，問題就來了：OAuth 怎麼處理？每個工具 API 的 schema 誰維護？權限怎麼收？使用者授權怎麼分？錯誤重試怎麼做？工具回傳格式變了怎麼辦？哪些 action 可以自動做，哪些必須先問人？

這也是 Composio 值得看的原因。

截至 2026-06-10 前後，ComposioHQ/composio 約有 2.8 萬 stars，repo 在 6 月仍活躍更新，package release 節奏很密。它切的不是 agent 推理本身，而是 agent 要真的碰外部世界時最麻煩的一段：工具、整合、授權和 action execution。

English TL;DR

Composio is an open-source integration and action layer for AI agents, focused on connecting agents to external tools and apps.
Its value is handling tool schemas, auth flows, integrations, and execution surfaces across common SaaS/dev tools.
It is useful when agents need to operate across Gmail, Slack, GitHub, Linear, Notion, Jira, browsers, or custom tools.
It is not a replacement for policy design, human approval, audit logs, or secure workflow boundaries.
Adoption judgment: evaluate Composio when tool integration is slowing agent products more than prompting is.

Agent 真正碰到世界時，工具層會變成主要複雜度

早期 agent demo 常常只接一兩個 tool：搜尋網路、讀檔、跑程式。這樣很容易做出效果。但一旦進到真實公司流程，工具數量會暴增，而且每個工具都有自己的 authentication、permission、rate limit、API quirks、資料模型和錯誤格式。

Composio 的定位就是把這些整合問題收斂。官方文件強調 tool integrations、auth、agent framework support、MCP、hosted tools、custom tools。它的價值不在於讓模型更聰明，而是讓模型有比較一致的方式去使用外部 action。

這點很重要。因為 agent 產品最後要不要有價值，常常不是看它能不能想出下一步，而是看它能不能安全、穩定、可追蹤地把下一步做完。

適合誰

第一種，是正在做 agent SaaS 或內部助理的團隊。
如果你的 agent 需要讀寫多個 SaaS，例如 Gmail、Slack、GitHub、Linear、Notion、Jira、Google Calendar，Composio 可以減少你自己維護一堆 integration wrapper 的成本。

第二種，是已經選了 agent framework，但缺 action layer 的團隊。
很多框架擅長 orchestration，卻不一定幫你處理各種第三方工具的授權與 schema。Composio 支援常見 agent framework，適合放在「agent 要用工具」那一層。

第三種，是想用 MCP 或工具目錄標準化內部能力的團隊。
工具一多，最怕每個專案都自己定義一份 schema。Composio 這類工具層可以成為統一入口，讓 agent 能用更一致的方式呼叫能力。

不適合誰

第一種，是 agent 還沒有明確 action 場景的人。
如果你的產品只是問答或內容生成，暫時不需要寫入外部系統，導入 Composio 可能太早。

第二種，是需要完全自建、安全隔離極高的環境。
金融、醫療、政府、內部高敏資料系統，可能需要非常嚴格的自管 auth、network boundary、audit。Composio 仍然可以參考，但導入模式要審慎，不是直接接雲端就好。

第三種，是把工具整合當成授權策略替代品的人。
能呼叫工具不代表應該呼叫。你仍然要設計哪些 action 需要使用者確認、哪些只能讀、哪些能寫、哪些要進 approval queue。

限制與風險

第一個限制，是工具層會放大安全責任。agent 一旦能操作真實工具，錯誤就不只是答錯，而是可能寄錯信、改錯 issue、建立錯任務、外洩資料。導入 Composio 時要先做 action classification，把 read-only、draft、write、destructive action 分清楚。

第二個限制，是第三方 API 會變。Composio 可以幫你維護整合，但任何 integration layer 都會受上游 API、OAuth policy、rate limit 影響。重要流程不能只靠 happy path，要有 fallback、錯誤提示和人工接管。

第三個限制，是 agent 的 tool choice 仍然需要評估。工具 schema 再完整，模型也可能選錯工具、填錯參數或誤解上下文。你需要 traces、測試案例、sandbox、mock tools，才能逐步提高可靠性。

採用判斷

我的判斷是：Composio 適合那些已經從「agent 能回答」走到「agent 要做事」的團隊。

如果你目前最大痛點是每接一個 SaaS 都要重寫 auth 和 action wrapper，那它值得評估。尤其是 agent 產品需要快速覆蓋多個工具時，統一 integration layer 會讓開發速度和維護成本差很多。

但如果你的核心問題仍然是需求不明、任務不清、資料品質不穩，Composio 不會替你解決。工具層應該在流程邊界清楚後再上。比較健康的導入方式，是先從 read-only 或 draft action 開始，建立 logging 和 human approval，再逐步開放真正寫入權限。

GitHub Star History

Star History 連結：https://star-history.com/#ComposioHQ/composio&Date

參考來源

GitHub Repo: https://github.com/ComposioHQ/composio
Composio Documentation: https://docs.composio.dev/
Composio Tools Docs: https://docs.composio.dev/toolkits/introduction
Composio Releases: https://github.com/ComposioHQ/composio/releases
GitHub API Metadata: https://api.github.com/repos/ComposioHQ/composio