5 万个工具塞给 agent，它先把自己玩死：Composio CTO 谈工具层怎么做

Composio 有一条跑了一年多的 agent 流水线，专门用来生成和维护工具集成。上个月这条流水线烧掉大约 10 万美元 token，维护它的工程师只有 3 个人。整个公司 15 人。

CTO Karan Vaidya 在 Cognitive Revolution 里把这个数字讲得很平静。他的原话是，token 成本已经明显高过人力成本，而且内部开发本身就是人力资本的好几倍。这家公司对外提供的产品是 1,000 多个应用、50,000 多个工具，通过一个接口交给 agent 调用。

主持人 Nathan Labenz 一开始把 Composio 称作「agent 的瑞士军刀」。Karan 接了一句更狠的：如果你真把一千个工具塞进上下文，agent 大概率会挑错那把刀，然后在上下文过载里把自己玩死。

工具多不等于能力强

这个反驳点出了整个 MCP 生态过去一年最尴尬的地方。最早那一波 MCP 热潮，本质是把 API 包一层壳，一百个工具就是一百个函数描述，全都躺在 system prompt 里。模型每次推理都要读完，注意力被稀释，选错工具的概率跟着上涨。Karan 的措辞是「注意力不免费」，哪怕上下文窗口涨到一百万、五百万，塞满依然是负收益。

Composio 的做法是只给 agent 几个元工具，让它自己按需发现。用户说「帮我连上 Google Drive」，中间隔着 Claude Code 这层智能中介，它会直接调认证管理工具，不会把一句模糊的搜索意图丢给工具发现。真正进入上下文的，是当下这个任务需要的那几个工具。

第二层是沙箱。Nathan 问得很直接：到底什么该跑在你们的基础设施上，什么该跑在本地。Karan 的答案里有一个具体场景。让 agent 处理一万封邮件，逐个函数调用，一百封就撑爆上下文。所以 Composio 提供沙箱，让 agent 写代码，用程序化方式批量调用工具。「LLM 写代码，代码再调 LLM」，处理一万封甚至一百万封邮件都行。

沙箱里还预置了一批确定性的脏活。认证是最典型的一项，agent 不用每次重新拼 OAuth 流程。文件分享是另一项，挂载目录里的文件默认传到 S3，生成可分享链接，agent 只要把报告复制进去，对外发送这件事就完成了。Karan 说这类小工具看起来不起眼，对 agent 的成功率和准确率提升很大。

工具坏了，现场再造一个

持续学习是这集里信息密度最高的部分。Composio 的所有集成由内部 agent 流水线生产：拿到开发者应用、拿到凭证、生成 action、找依赖、在真实场景和边缘 case 上测试。

关键在于运行时的反馈闭环。当 agent 调用某个工具反复报错，或者明显读不懂工具描述，这条流水线会被实时唤起，生成这个工具的新版本，直接替换进 agent 的上下文。Karan 说同一个工具可能存在几万个版本。

另一条路径是轨迹压缩。agent 完成任务时经常走 Z 字形，绕一圈才到终点。Composio 保存了完整的端到端轨迹，知道它执行了什么、想达成什么，然后把这条 Z 字线提炼成一组 skill。下一次遇到类似任务，agent 走直线，更快、更省 token、更可靠。失败也会被沉淀成使用禁忌，提前写进上下文：这个工具在这些场景下会踩坑，别这么干。

Karan 给这套东西下了个定义：harness 的本质就是上下文工程，只不过工程对象换成了工具。

「harness is nothing but context. 你必须把上下文工程做好。」

Nathan 追问升级的分发逻辑：所有人都自动拿到新版本吗，我调好的东西会不会被改坏。Karan 的回答分两层。通用的改进全员共享，比如他们发现 Google Calendar 的官方文档在若干场景下是错的，靠大量 agent 真实调用才撞出来，这种修正应该扩散到整个客户群。个性化的改进只给单个用户，因为那个工具在这个人的用法下还能更好。skill 层面则刻意保持稳定，不轻易改动，用它来锁住你已经调顺的行为。

Skill 是模型的笼子，也是解药

这一集最有争议的判断藏在中段。Nathan 提到业内流行的一种看法：各家前沿模型的能力曲线差不多，但行为风格在分化，这种分化会形成黏性，给模型厂商带来定价权。Karan 的看法反着来。

只要 skill 写得足够细，把路径、轨迹、粒度都定义清楚，前沿模型之间基本可以互换。他给出的实测比例是：Opus 负责第一次写 skill，写完之后切到 Sonnet 执行，效果非常好；切 Haiku 不行；切到 GPT 系，90% 到 95% 的 skill 开箱即用，剩下 5% 到 10% 卡在行为差异上。

差异长什么样，他举了一个很具体的例子。任务需要轮询等待时，Anthropic 的模型会自己写代码持续轮询，GPT 会停下来等用户输入。这类习惯会被写进 skill 的结构里，换模型就不太顺。

Composio 正在做的是把这类差异抹平，也就是 skill 翻译层。Karan 的说法是 95% 很容易，做到 100% 是个硬问题，因为那些不结构化的行为习惯很难被机械转换。他们已经在做，也设了指标和 benchmark。

Nathan 当场承认自己的世界观在对话中发生了变化，原本以为模型分化会带来更多锁定，现在觉得商品化可能来得更快。这个判断对做 agent 产品的人有直接含义：把 skill 当成资产来攒，把模型当成可替换的执行器，切换成本能压到很低。

Karan 顺带把公司定位也压在这上面：Composio 的 harness 可以接 Anthropic、OpenAI、开源模型。今天用 Opus，明天想换更便宜的开源模型，认证和 skill 都在一个地方，切过去还能保持 99% 的可靠性。

招聘 agent 和 Fin 的那笔账

被问到最喜欢的用例，Karan 讲的不是某个具体任务，而是一份完整工作。

他让 OpenClaw 做招聘。agent 去翻 GitHub 仓库，找高质量 commit 的作者，专门盯 agent 框架、Python 和 TypeScript 项目，把候选人的地理位置、邮箱、LinkedIn 和其他社交资料补齐，然后用自己的邮箱发信。过去一两周，这套流程给他约到了 30 到 40 个电话。他强调这是「一份工作」，并非「一个任务」。

另一个场景是邮件归档。用户把整个 Gmail 权限交出去，让 agent 读上个月的邮件，判断哪些没用，写代码批量归档。销售场景则在另一端：agent 把目标人找齐、资料备好、邮件起草完，人只需要按发送键。

由此自然引出一个尖锐问题。Nathan 是 Intercom 用户，他注意到 Fin agent 能解决接近 70% 的客服工单，定价 99 美分一单。而 Composio 上架了 133 个 Intercom 工具。他的推算是：如果自己拿这些工具写 skill，token 成本可能只有 10 美分级别，省下八九成，还能按自己的业务定制。

Karan 没有回避。他先夸 Fin 是好产品，早期自己也在用，理由很实在：很多公司不想投入时间，希望开箱即用。分歧在定制性上。自己搭的人，能把 agent 限定在特定工具、特定 skill 上，还能顺带接上别的应用，这种自由度是买不来的。

至于这是不是一场运动，他的判断偏保守：build 对 buy 的替代会零散发生，不会全面铺开。有些公司花这个时间不划算，有些很划算。但摩擦会持续下降，天平会慢慢往 build 那边偏。

大多数 agent 到 agent，不如做成工具

Nathan 提了一个概念区分：工具是为你自己的利益服务的，agent 可能代表别人的利益。Karan 的回应不太讲哲学，讲上下文。

他举预约会议的例子。如果主 agent 手里有日历，它知道那个时间段有没有董事会，能直接判断冲突。如果把这个任务委派给一个专门管预约的 subagent，那个 subagent 看不到日历，很可能约到冲突时间，然后你只能问一句「这怎么回事」。

判断标准是上下文占用的规模。轻度、明确、一两步就能完成的事，做成工具交给主 agent 更好。探索型、重度吃上下文的任务，比如深度研究，才适合拆成多个 subagent 并行跑，再汇总回主 agent。

真正在生产里跑起来的 agent 到 agent，他点了两个。一个是 Claude 的 team of agents，一群 subagent 共享一份任务列表，通过列表互相派活、互相通信。另一个是 Composio 内部开源的一个编排器，一个 orchestrator 管 20 到 30 个 Claude Code 或 Codex，工程师只在这个编排层做决策。

Composio 自己也有一批「工具形态的 agent」。你把一句自然语言丢过去，说在这个应用里找点什么或者做点什么，它内部是个 agent，返回一个 session ID，你可以拿着 ID 继续多轮对话。

MCP 和 CLI 会长期共存

临结束时 Karan 主动提了 MCP 对 CLI 的争论，因为这个话题直接影响他们的产品。他的判断是多极世界，理由跟训练数据有关。GitHub CLI 这类命令行工具被工程师用了十几年，早就进了预训练语料，模型用起来很顺。MCP 也在快速进入训练数据，新模型对它的熟悉度在涨。

他们正在发一个通用 CLI，一个命令管所有应用，不用为 GitHub 装一个、为别的服务再装一个。在控制力、可观测性和可审计性上，Karan 认为 MCP 更强，这也是企业客户更看重的一面。Nathan 的总结是两边会各自成熟，长期看是同一枚硬币的两面，Karan 认可，并补了一条判断依据：token 花在哪里，agent 轨迹就沉淀在哪里，哪一边就会被训得更好。

关于谁在 AI 浪潮里变强，他的分层很清楚。核心基础设施在变得更强，AWS、Cloudflare 这类底座，软件越多、依赖越深，就越难被重写。SaaS 那一层拼的是谁能更快做出新的 agent 交互界面，Salesforce、Slack 这些老玩家的反应并不慢。Composio 两头都做，既服务创业公司，也服务在做新界面的在位者。

agent 原生工具这块，他报了三个类别。记忆是最大的一类，Mem0、Zep、Supermemory 都在上面。支付有 Skyfire，配合 OpenClaw 那波后台 agent 潮，商业类的调用明显变多。搜索是另一个高频类别，Exa、Firecrawl、Tavily 使用量都不小。Composio 的策略是全都接，不站队，让用户自己选。

Nathan 还提了一个体验问题：Brave Search、Perplexity、Brandfetch 这类通用 API，目前还得自己去申请 key 再填进来。Karan 说正在做 premium toolkit，一个钱包、一个面板、统一的额度管理，把多账户和多账单的麻烦收掉。

明天就能动手的几件事

• 给每个 agent 单独配一个权限 profile。做研究的 agent 给全量只读权限，但砍掉发送和写入；做外发的 agent 给写权限，但把敏感数据挡在外面，再挂上 human in the loop。
• 第一次做 skill 用最强的模型，跑通之后切到 Sonnet 这档执行。Karan 自己的日常就是这么干的，速度提升明显，效果不掉。
• 把 agent 绕远路的那几条轨迹记下来，手动或自动固化成 skill。一次整理，后面每次都走直线，省的是 token 和时间。
• 别把上千个工具一次性挂进上下文。接一个聚合端点，让工具按需加载，比如 Composio 的 connect.composio.dev/mcp，比逐个应用配 OAuth 省事得多。
• 给 agent 开独立邮箱和独立账号，别用你本人的。它要对外发信、要注册服务，出问题时你能直接掐掉。
• 自建还是买，先算一笔账：现有 SaaS agent 的年费，对上自建后的 token 成本加人力。省 80% 到 90% 在数学上成立，成立的前提是你愿意花那几周把 skill 调到能用。