32 篇博文 含有标签「tool-use」

团队最开始有 5 个工具和一个在生产流量中命中率达 95% 的规划器（planner）。18 个月后，他们有了 51 个工具，而规划器的命中率降到了 26%，原本那 5 个工具能干净利落处理的简单案例——预订会议、查询客户、提交工单——现在有时会路由到错误的工具，因为目录中有三个听起来很像的“替代品”。没有人故意让规划器变差。每一次工具的增加在当时看来都是合理的。这种累积的代价就是“可组合性税”（composability tax），每一个在工具目录增长过程中缺乏淘汰机制的产品都在支付这笔费用。

这笔“税”是一条曲线，而不是悬崖。Berkeley Function Calling Leaderboard 直接测量了这一点：在日历调度任务中，当跨多个领域的工具从 4 个增加到 51 个时，准确率从 43% 下降到了 2%。在客户支持类任务中，GPT-4o 从 58%（单一领域，9 个工具）下降到 26%（7 个领域，51 个工具）。Llama-3.3-70B 在同样的扩张下从 21% 降到了 0%。这种趋势在不同模型和任务类型中不断重复：每增加一个工具，规划器就会在曲线上进一步下滑，而且随着目录变大，边际损害会变得更严重，因为新加入的条目与现有的条目越来越难以区分。

你智能体系统提示词中的工具描述是一个六个月前的评估产物（eval artifact）。它说 search_pricing 返回“带有结构化定价的最新库存数据”，规划器（planner）对此深信不疑，因为自描述调优的那天起，提示词中的任何内容都没有更新过。而实际上，在过去的 40 分钟里，search_pricing 端点的 p95 延迟一直保持在 11 秒，因为上游供应商正在对你的账户进行限流。而那个被提示词描述为“可能略微陈旧”的更便宜的 search_cache 工具，只需 200 毫秒就能返回同样的答案。但规划器还是选择了 search_pricing，因为描述读起来仍和评估时一样，且规划器没有任何关于目前调用这两个工具成本的信号。

这就是静态工具描述的结构性失效。规划器是在根据一个已经发生变化的世界快照做出路由决策。工具选择实际上并不是一个能力问题——大多数生产环境中的智能体都有两三个在回答内容上高度重合的工具——它本质上是一个“等待成本”问题，而等待成本正是你的提示词模板所看不见的东西。

只要为你的智能体连接一个 GitHub MCP 服务端，在用户输入一个字之前，你可能就已经消耗了 1.2 万到 4 万个 token。连接一个文件系统服务端、一个日历、一个数据库、一个内部 CRM 以及一个第三方工具目录，据测算，一个重型桌面配置的纯工具披露 (tool disclosure) 就会产生 6.6 万个 token —— 这几乎占了 Claude Sonnet 200K 上下文窗口的三分之一，而且在每一个规划轮次 (planning turn) 都要付费。智能体还没开始干活，用户还没开始提问，账单就已经开始计费了。

这就是“披露税” (disclosure tax)，它是目前交付的智能体系统中定价最低估的条目。团队添加 MCP 服务端的方式就像曾经添加微服务一样 —— 每一个集成看起来都像是一个免费的组合原语 (composition primitive)，采购理由也顺理成章（“更多工具 = 更多能力”）。而单位经济效益仪表盘 (unit economics dashboard) 从未反映出每个服务端的成本，因为成本隐藏在 token 桶里，没有人将其归因于连接器。结果是，每当有人添加另一个集成时，智能体就会变得更慢、更笨、更贵，而团队却通过重新调整提示词 (prompt) 和催促模型厂商发布新版本来解释这种退化。

你的可观测性技术栈中的单工具仪表盘讲了一个令人宽慰的谎言。search_listings 的成功率是 96%，显示为绿色。book_appointment 是 95%，也是绿色。而连续调用这两个工具的智能体（agent）三周以来的成功率一直只有 78%，却没人能解释原因。原因不在任何一个工具内部，而是在它们之间的缝隙里——那个没有任何仪表盘面板覆盖的地方。

组合不是加法。当工具 A 的输出流入工具 B 的输入时，故障面并不是 B 对“有效调用”的狭隘定义下的 1 - (0.96 × 0.95)。它是 A 在 B 的标准下所有微妙偏差方式的完整笛卡尔积：A 返回的日期格式是 MM/DD/YYYY，而 B 期望的是 ISO 8601；返回的价格单位是分，而 B 解析的是元；分页游标指向了最后一个结果之后的一项；或者上游服务昨天重命名了一个实体 ID。这些情况都能顺利通过 A 自身的契约测试（contract tests），但每一个都会导致 B 崩溃。团队的单工具可靠性指标永远看不到这一点，因为按各自的标准来看，每个工具都运行良好。

一个 200 毫秒的工具调用在火焰图（flame graph）上看起来就像是杂音。但在 Agent 循环中堆叠七个这样的调用，杂音就变成了信号 —— 模型在 800 毫秒内完成了思考，但用户却等待了 4.5 秒，因为每一次工具调用都在重新支付首个调用已经吸收掉的启动成本。残酷之处在于，这种成本在任何单一的追踪（trace）中都不会显示为异常。它表现为干脆利落的 Demo 与反应迟缓的生产环境 Agent 之间的差异，而大多数团队会将其归咎于模型。

Model Context Protocol (MCP) 已成为 Agent 工具链的默认集成界面，这意味着它也成了延迟（latency）堆积的重灾区。MCP 的设计 —— 基于 stdio 或可流式 HTTP 的 JSON-RPC、能力协商（capability negotiation）、动态工具发现 —— 对于一个必须桥接任意客户端和服务器的协议来说是正确的。但它隐含的单次调用成本结构对于 Agent 实际的访问模式并不友好。Agent 的模式不是“每个会话调用一次工具”，而是“每轮对话调用七个工具，每个会话进行四十轮对话”。

这篇文章将探讨这种错配：冷启动税究竟存在于何处，为什么它在长生命周期的 Agent 中是叠加而非被摊销（amortize）的，以及如何通过“预热池”（warm-pool）规范将数秒的惩罚降低到 100 毫秒以下。

SQL 工具在数据从网络线路传出时即发送行。智能体调用它并期待得到结果。而一年前编写的运行环境（当时所有工具都是请求-响应式的）在调用模型之前，会尽职地将整个流缓冲成一个单一字符串。40 秒后，缓冲区达到了 200 KB，上下文窗口被消耗了一半，智能体正在对一个查询的第 47,000 行进行推理，而它本可以在第 30 行就停止。没有人故意设计这种失败——这仅仅是因为将“工具已返回”视为规划器唯一响应事件的结果。

向流式工具的转变正在规划器尚未察觉的情况下发生。SQL 引擎发出渐进式结果集。文档提取器生成分页。搜索 API 在相关性评分稳定后按批次返回命中结果。MCP 的 Streamable HTTP 传输协议（2025-03-26 规范中 HTTP+SSE 的替代方案）使增量响应成为一流的传输模式，而不再是一项稀有的功能。传输层已经准备就绪，但其上的规划器还没有。

安全审查分别批准了这三个工具。对客户数据库的只读访问被评估为低风险，因为智能体（agent）只能查看记录而不能修改。发送邮件给自己（Send-email-to-self）被评估为低风险，因为收件人被硬编码为一个服务账号邮箱，且智能体已被授权向该邮箱写入。模板渲染（Template-render）被评估为低风险，因为它是一个不带 I/O 的确定性 Jinja 风格转换。发布三周后，数据丢失防护（DLP）仪表板标记了出现在一个有两百名员工可读的 Slack 频道中的客户 PII。事后分析（post-mortem）发现泄露源于智能体将这三个工具组合成了一个没有任何单一 ACL 授权的链路：读取客户记录，通过模板渲染，将结果发送到它自己的服务账号，而该邮箱又自动转发到了该频道。

没有一个工具被滥用。没有提示词注入（prompt injection）绕过任何检查。智能体完全按照其工具目录所说的那样执行，而这种组合产生了一种安全审查从未被要求评估的能力。

大多数构建 AI 智能体的团队，都会在第五个迭代周期发现同一个问题：智能体再也无法可靠地选对工具了。十个工具时，基本还能用。二十个时，准确率开始下滑。五十个时，你会亲眼看着智能体在应该调用 update_record 的时候调用了 search_documents，而日志毫无解释。常见的反应是调整工具描述——加更多上下文、写得更明确、重写示例。这偶尔有效，但它绕开了根本原因：平面嵌入检索在大型工具库中架构上就是错的，更好的描述无法修复一个架构问题。

工具选择本质上是检索，而检索有已知的扩展上限。理解这些上限——以及绕过它们的结构化元数据模式——是让智能体系统在生产中稳定运行与需要持续人工维护之间的分水岭。

大多数团队在设计 LLM 智能体时，会花大量精力在工具选择和系统提示措辞上。而几乎没有人认真思考工具返回什么内容。这是一个后果不断叠加的错误——因为工具响应的结构决定了智能体能否有效推理、消耗多少上下文窗口，以及产生幻觉解读的频率。

工具输出 schema 设计是基础设施，而非管道细节。设计失误，你的智能体将以表面上像推理问题的方式失败，而根源其实是 schema 问题。

你交付了一个工具，让你的 Agent 可以获取用户个人资料。描述中写道：“通过用户 ID 检索用户信息。”六周后，后端团队将 user_id 重命名为 customer_uuid 并添加了一个必填的 tenant_id 字段。没有人更新工具的 Schema。你的 Agent 继续调用旧的签名，收到 400 错误，将空结果解释为“未找到用户”，并“热心地”创建了一个重复记录。

日志中没有错误。没有触发任何报警。Agent 全程都非常自信。

这就是工具文档问题：Schema 漂移将陈旧的描述变成了隐性故障向量。这可能是当今生产环境 AI 系统中最被低估的可靠性风险，而且你的 Agent 运行的时间越长，情况就越严重。

你从工具目录中注销了 lookup_account_v1，换上了 lookup_account_v2，并修改了系统提示词中的一个段落来指向新名称。测试通过了。三天后，支持工单开始提到助手“一直尝试调用不存在的东西”，或者——更令人不安的是——它用自信、看似合理的数字回答客户问题，却根本没有查询数据库。弃用并没有在通信层失败，它在规划器（planner）中失败了。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E4%B8%8B%E7%BA%BF%E4%B8%80%E4%B8%AA%E8%A7%84%E5%88%92%E5%99%A8%E5%B7%B2%E5%AD%A6%E4%BC%9A%E4%BE%9D%E8%B5%96%E7%9A%84%E6%99%BA%E8%83%BD%E4%BD%93%E5%B7%A5%E5%85%B7"]

这是将工具弃用视为语法变更与将其视为行为迁移之间的差距。智能体不仅是在注册表中拥有你的函数；它还拥有数月的计划、多步配方（recipes）以及通过该函数作为检查点的 few-shot 示例。撤掉它更像是停用下游服务非正式硬编码的内部 API——只不过下游服务是一个你无法通过 grep 搜索其习惯的模型，而且当它偏好的工具消失时，它的兜底方案是编造一个。

“发送邮件”工具和“删除账号”工具被放在了同一个确认弹窗后面。你的用户今天已经点击了 40 次“批准”（Approve），没有一次点击涉及阅读 Diff，而下一次点击——即向生产数据库提交一个不可逆变更的操作——看起来和之前的 40 次完全一样。这就是二元工具审批的失效模式，也是当今几乎所有发布的 Agent 框架的默认设置。

问题的核心框架在于，“需要人工审批”被视为附加在工具上的单个布尔值，而实际上它是一个包含五到六个类别的分类法，取决于工具可能造成的破坏类型以及这种破坏的可恢复程度。那些能够交付安全 Agent 的团队不再询问“这个工具是否需要确认对话框”，而是开始询问“这个工具属于哪种风险类别，以及哪个门槛（gate）对应于该类别”。审批门槛的正确数量既不是一个，也不是很多。它是每个风险类别对应一个，你必须在构建门槛之前先列举这些类别。