让你的 Agent 自我进化的瑞士军刀：Composio CTO Karan Vaidya 谈打造智能工具

摘要

• Karan Vaidya 认为，真正的护城河来自使用驱动的工具迭代，而不只是覆盖超过1,000个应用、超过50,000个工具的目录。 他表示，运行时故障可以实时触发新版本工具，而曲折的执行轨迹会沉淀为可复用技能，让 Agent 下次走上“直线路径”。在他看来，跨 Agent、跨应用积累的经验才是护城河；Nathan 则表示自己过去几周一直在使用 Composio。

• Agent 系统最稀缺的资源是注意力，因此暴露更多工具反而可能让产品变差。 Karan 警告，Agent 可能“用错刀片，在上下文过载中自杀”（“use the wrong blade and suicide via context overload”）；Composio 的做法是只呈现少量元工具，在需要时即时发现相关动作或技能，并用代码沙箱处理10,000甚至100万条记录。“Harness 说到底就是上下文”（“Harness is nothing but context”）。

• 公司的 go-to-market 分化为两类：专业用户买的是配置简单，开发者买的是治理能力。 1个 MCP server 就能把 Claude Code 或类似运行时接入托管认证；生产团队则可以按模块采用发现、沙箱、认证或完整执行层。Karan 称 AWS、Zoom、Glean 和 Airtable 都是客户，动作级权限、钩子、人工审批、SOC 2 和 VPC 自托管共同构成企业信任基础。

• 最强的用例已经接近完整工作任务，而自治程度越高，权限设计的价值就越大。 Karan 的 Agent 会寻找开源项目贡献者、补齐联系方式、用自己的邮箱发起联系，并在1到2周内生成30–40次调用；销售 Agent 也能准备类似的定向外联草稿。他的控制模型将研究型 Agent 与执行型 Agent 分开：前者拥有广泛读取权限但不能采取行动，后者可以写入但只能访问有限数据，并接受人在环检查。

• 技能可能通过把判断力转移到可复用指令中，让前沿模型重新商品化。 Karan 通常让 Opus 创建技能，再让 Sonnet 执行；据他在自身体验中的判断，Haiku 表现并不理想，而测试过的 GPT 技能案例约90%可以直接运行，当前模型整体达到90–95%也并不难。关键例外是 Anthropic 更擅长轮询，而 GPT 可能停下来等待输入。Composio 正在开发指标和基准测试，也已经进行部分面向模型供应商的适配，把降低模型锁定作为核心价值主张。

• AI 会强化底层基础设施，同时从界面和定制化层面对成套 SaaS 形成压力。 Karan 预计 AWS 和 Cloudflare 会受益于软件创建规模扩大；如果 Salesforce 和 Slack 能快速推出 Agent 化界面，也有机会守住阵地。Nathan 给出的更尖锐测试对象是 Intercom：两人交谈时，他称 Fin 面向数千家客户、以每次0.99美元的价格解决接近70%的工单，但 Composio 提供的133个工具可能让部分公司自行打造定制技能，潜在节省80–90%；Karan 预计企业会选择性内制，而不是全面转向自建。

• Composio 的内部成本结构，已经显露出劳动力从执行转向监督 Agent 的早期信号。 一支3人团队负责构建和改进工具的流水线，公司总人数约15人；Karan 称上月该流水线的支出约为10万美元，其中 token 成本已经高于人力成本。他的概括是：“我们需要更多人来消耗更多 token”，同时公司计划推出共用1个钱包的高级工具包和 universal CLI。

精读

1. 一把好用的瑞士军刀，不能把50,000片刀刃全部摊给模型

• Nathan 的切入点是：Composio 覆盖超过1,000个应用、提供超过50,000个工具，囊括大量没有必要重复开发的常见集成。即便只是给 Google Drive 或 Slack 开通访问权限，也可能要在控制台完成一系列操作、点击大量权限设置，足以劝退普通用户。

• Karan 接受“瑞士军刀”这个比喻，但不认为工具覆盖面就是终点：把所有刀片都递给模型，它可能“用错刀片，在上下文过载中自杀”。他对 Composio 的定义是“Agent 化工具执行层”。

• 这一执行层组合了即时发现、动态注入工具、认证、授权、范围化访问、沙箱，以及新邮件、Slack 消息或 pull request 等触发器。Composio 的 dashboard 还提供治理、可观测性和审计能力。它的任务，是只向 Agent 提供完成当前执行所必需的上下文。

• Nathan 表示，过去几周他一直在使用 Composio，其中就包括处理 Google Drive 和 Slack 的权限问题。这让配置负担成为他亲自测试后的结论，而不只是对理论集成成本的描述。

2. 个人用户买便利，生产团队买控制权

• 对 Claude Code 或类似 Agent 产品的高级个人用户来说，价值主张是用1个 MCP server，替代分别安装、学习 Google Drive、Zoom、Datadog 及其他集成。认证既可以通过对话发起，也可以在 Composio 的 dashboard 中管理。

• 生产环境开发者可以通过 MCP、API 或 SDK 接入完整 harness，也可以只选用发现、Workbench 沙箱、认证或 actions 等模块。团队自有工具可以与 Composio 工具并列运行，不必被迫采用全有或全无的架构。

• Karan 表示，规模化运行后，治理、可观测性和审计能力都很关键。他提到 AWS、Zoom、Glean 和 Airtable 是客户；这些客户的评估结果，也能让处理敏感公司数据的小型买家更放心。

• 安全体系从动作级最小权限开始：Agent 可以读取邮件，但不一定被允许发送邮件。执行前后钩子可以增加策略检查或人工审批；SOC 2 和 VPC 自托管则对应企业要求，Composio 也已经针对 AWS 的用例在 AWS 内部自托管。

3. 代码沙箱把海量任务变成可处理的工作

• Nathan 问的是架构问题：Claude Code 在本地执行 Bash，部分 provider tools 在远程运行，结果还要在两种环境之间传递——那么工具执行究竟应该放在哪里？Karan 的回答是，Composio 的沙箱主要负责移除那些模型本不该重新搭建的基础设施。

• Agent 会获得一套工具和抽象层，以尽量减少代码量，尤其是认证以及在程序化执行和 function call 之间转换的部分。Karan 表示，同样类似 Docker image 的环境很快也会支持本地运行，用于内部工具或机器本地工具。

• 当 Agent 需要处理10,000封邮件时，直接 function calling 会失效，因为不可能让每一条结果都占据上下文。放进沙箱后，Agent 可以写代码，甚至在代码中再次调用 LLM，处理10,000条、甚至潜在的100万条记录。Karan 称这“有点像 Inception”。

• 挂载文件夹解决了另一个不起眼但常见的故障点：放入其中的文件会被上传至 S3，并获得可分享链接。Agent 可以分析邮件或 Stripe 活动，生成报告，将报告复制到指定文件夹后分享出去，而不用另行搭建文件分享流水线。

4. Smart MCP 的关键在渐进式披露和从执行中学习

• Nathan 将 Smart MCP 与第一代 API wrapper 区分开来：他要的是能够接收高阶意图、组合多次调用并逐步披露能力的一层。他认为 MCP 和 CLI 之争没有那么根本，因为两种接口最终都可以支持智能披露。

• Karan 的核心约束是：“注意力绝对不是免费的。”即便上下文达到百万 token，把50,000个定义全部展示出来也可能拖垮性能，因此模型起初只看到少量工具，相关动作则在运行中动态注入。

• 发现机制不只适用于工具，也适用于即时调用的技能。检索到的技能可以规定应该调用哪些动作、应在 Workbench 中运行什么代码，以及此前哪条轨迹曾经得到目标结果；Agent 再将这套配方调整到当前请求上。

• 反复出现的失败会变成执行前的预警：将陷阱、应该做什么和不应该做什么提前放入上下文。Karan 对整个产品理念的概括是：“Harness 说到底就是上下文。你必须对上下文进行工程化。”

5. 用户请求从指令变成完整结果

• Composio 通常接收不到用户的原始语言，因为 Claude Code 或其他 Agent 运行时充当了“智能中介”。如果用户要求连接 Google Drive，运行时已经知道应调用连接管理，而不是发出含义模糊的发现请求。

• Karan 将12月视为信任拐点：用户开始相信，当前模型已经具备明显更高的自治能力。软件工程率先发生变化，但知识工作者也越来越多地只描述想要的结果，把工具选择和中间步骤交给 Agent。

• 一个直接例子是：给 Agent Gmail 访问权限，让它检查过去1个月的邮件，判断哪些已经没有价值，然后归档。Agent 会写代码，并在代码中调用 LLM 对邮件进行分类。

• Karan 自己的招聘流程更接近一项完整的招聘工作：扫描 agentic、Python 和 TypeScript 项目，找出优秀贡献者，补齐所在地、邮箱、LinkedIn 和社交信息，然后用自己的邮箱联系候选人。他说，在发出数千封邮件后，系统在1到2周内生成了约30–40次调用。

6. 长上下文自治让权限成为架构原语

• Nathan 描述了一个本地、规模达 GB 级的数据库，里面存有5年的邮件、Slack、私信、录音电话和播客文字稿。它能提供丰富的关系历史，但也可能包含通过邮件发送的密码、恢复码或信用卡信息，而这些内容他无法安全地逐一盘点。

• Karan 的答案不是打造一个全方位受信任的助手，而是建立“多个 Agent”，分别配置不同能力。研究型 Agent 可以广泛读取信息，却没有发送消息或执行外部动作的权限，从而让庞大上下文保持在自身范围内。

• 可写入、能够执行动作的 Agent 则采用相反配置：拥有行动权限，但只能接触很少的敏感个人或公司信息。人在环检查可以在执行前审阅拟发送的消息或拟执行的操作，降低机密 token 被发送到外部的风险。

• 原则是能力隔离：广泛知识和广泛行动能力不应自动共存。Composio 的 scopes 和 hooks，旨在为不同的 Claude Code、Codex 或其他 Agent 实例表达这种隔离关系。

7. 每次失败都能改进工具，或沉淀成可复用技能

• Composio 的集成本身也是通过内部 Agent 流水线构建的：Agent 获取开发者应用凭证、创建 actions、识别依赖，并测试真实场景和边缘案例。当客户的 Agent 无法理解或成功使用某个工具时，也可以调用同一套机制。

• 一次运行时失败可能立即生成新版本工具，并将其插入当前上下文。Karan 表示，同一个工具可能累积数万个版本；如果某次改进只服务于一个客户的特殊工作流，它也可以保持个性化。

• 通用修正则会广泛传播。Agent 使用 API 的方式“疯狂且各不相同”，会发现文档没有正确描述的场景；Karan 称，最近这些自治发现已经让 Composio 的 Google Calendar 工具“远好于文档建议的水平”。

• Nathan 担心升级会破坏已经调校好的工作流。Karan 的回答是，工具可以广泛改进，但学习得到的技能不会频繁变化，因此能够保留用户想要的执行轨迹和可重复行为。

8. 技能让切换模型变得可行，但还不够无缝

• 详细技能会把路径写得足够清楚，从而降低重复执行时所需的判断。Karan 的常规工作流是让 Opus 发现并编码一套成功流程，再切换到更快、更便宜的 Sonnet 执行后续任务；他称这一做法“效果非常好”，但根据自身体验，Haiku 表现并不理想。

• 跨供应商移植的稳定性较弱，但整体仍然很高。Karan 表示，在他对 GPT 模型的测试中，90%的技能可以直接运行；在其他场合，他将当前模型普遍可实现的水平描述为90–95%，剩余部分则暴露出原始技能中嵌入的供应商特定行为。

• 他给出的最典型反例是轮询：Anthropic 模型通常会等待并持续轮询，直到任务完成；GPT 则可能停下来要求用户输入。即便两个模型都理解书面指令，这些默认行为也会改变执行结果。

• 被问及 Gemini Flash 时，Karan 的表述有所保留：他还没有亲自测试完全相同的技能迁移场景，尽管生产环境的体验很顺畅；他预计当前版本或下一轮迭代都能达到所需水平。

9. 技能翻译层可能成为反模型锁定层

• Nathan 的重新表述是，技能可能成为一层“重新商品化层”。前沿模型在质量上的差异可能制造粘性，但穷尽式指令会把更多行为从模型默认能力中抽离出来，沉淀为可移植的产物。

• 因此，Composio 将自己的 harness 定位为避免模型锁定的一种方式：认证、工具和技能留在同一层，底层模型则可以从 Anthropic 切换至 OpenAI，最终也可以切换到 Karan 认为成本可能便宜约10x的开源模型。

• Karan 有时将切换模型描述为保留99%的可靠性，但他也单独承认，未经处理的跨供应商技能移植率更接近90–95%。剩余工作在于进行面向供应商的转换，补偿已知的行为差异。

• Composio 正在开发指标和基准测试，也已经完成部分供应商之间的适配。Karan 表示，从易于实现的90–95%提升到100%确实很难，因为技能缺乏结构，还可能悄悄编码了创建该技能的模型所特有的假设。

10. Agent 赋能层扩张，但传统系统仍掌握数据

• Karan 看好专门为 Agent 打造的工具：包括 Mem0、Supermemory 和 Zep 等记忆产品，Skyfire 等支付基础设施，Shopify 等商业平台，以及 Exa、Firecrawl、Tavily 等搜索或检索服务。

• Composio 选择跨品类合作，而不是押注某一个赢家，让开发者根据用例自由组合。记忆产品已经存在明显需求，而与 OpenClaw 运动相关的后台 Agent，正在提升市场对支付和商业能力的兴趣。

• 被问到仍然缺失的品类时，Karan 诚实地没有给出答案：开发者似乎正在攻克人类几乎所有的活动，包括 Agent 向人委派任务。他表示，还需要进一步思考，才能说出一个显眼的空白领域。

• 尽管 Agent 原生产品正在兴起，大多数使用场景仍然会触及 Slack、Salesforce 等传统软件，因为“那就是记录系统”。在基础设施层面，Karan 预计随着软件创建变得更容易，对底层平台的依赖会增加，AWS 和 Cloudflare 因而受益。

11. SaaS 靠界面生存，定制化推动自建与采购重新权衡

• Karan 预计，现有 SaaS 的界面会发生变化，但底层记录系统仍然重要。创业公司会打造新的 Agent 化界面，而 Salesforce、Slack 等既有厂商也在快速推进，因此最终胜负取决于执行速度，而不只是既有地位。

• Nathan 的反驳更看好大客户中的成熟供应商：AI-first CRM 可能很有吸引力，但企业销售周期会给 Salesforce 时间复制最强功能。更具颠覆性的威胁，可能是客户将狭窄工作流带回内部，而不是改用一整套竞争性软件。

• Intercom 将这种权衡具体化。Nathan 表示，两人交谈时，Fin 已经在数千家客户中解决接近70%的客服工单，每次解决的价格为0.99美元，并提供即时、全天候响应；但 Composio 暴露了133个 Intercom 工具，这让他推测企业可以自行编码一套客服技能。

• Nathan 假设，每个案例的 token 成本可能约为0.10美元，从而潜在节省80–90%。Karan 认为定制化比节省成本更重要：内部 Agent 可以调用多个应用、限制特定动作，并执行公司专属治理规则。他预计1年内不会出现大规模离开 Fin 的现象，但也同意，摩擦成本下降后，“人们会逐步从采购转向自建”（“people will inch towards build compared to buy”）。

12. Agent 委派、token 经济学和界面仍将两极分化

• Karan 的委派判断标准是任务的上下文权重。如果一项任务只消耗“1–2%”的上下文，主 Agent 就应继续掌控并获得合适工具；把预约安排交给缺乏上下文的子 Agent，可能导致它与主 Agent 已经看到的重要董事会会议发生冲突。

• 深度研究适合交给并行子 Agent，因为探索过程会消耗大量上下文，最终可以压缩后再返回。Karan 提到 Claude 的共享任务列表模式，以及 Composio 的 Agent 化工具；后者会保留 session ID，以支持多轮自然语言交互。

• 在内部，一个 orchestrator 可以监督20–30个 Claude Code Agent。一支3人团队负责构建和改进 Composio 工具的流水线；相对于全公司约15名员工，公司上月在这条流水线上花费了约10万美元。Karan 表示，该项工作的 token 成本已经高于人力成本，并将这种模式概括为：“我们需要更多人来消耗更多 token。”

• 产品扩张也遵循同样的整合逻辑：计划中的高级工具包将让多个服务共用1个 Composio wallet，而不是继续分别管理 API key；universal CLI 则可以通过一个界面访问多个应用。Karan 预计 CLI 和 MCP 会在一个“两极化世界”中共存，token 分配和不断提升的可追踪性将共同决定二者的平衡。