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

你的智能体调用一个工具，获取响应，并立即将其视为真理进行推理。没有 Schema 检查。没有新鲜度验证。没有针对响应预期形式的健全性测试。这是每个主流智能体框架的默认行为，它悄无声息地导致了一整类传统监控永远无法捕获的生产环境故障。

工具结果验证缺口是指“工具返回了某些内容”与“工具返回了正确内容”之间的地带。大多数团队痴迷于确保工具调用正确——选择正确的工具、生成有效的参数、处理超时。几乎没有人验证返回的内容。

大多数 Agent 演示仅使用 5 个工具，而生产系统通常拥有 50 个。这两个数字之间的差距，正是大多数 Agent 架构分崩离析的地方。

当你给一个 LLM 4 个工具和一个明确的任务时，它通常能选对。但当你给它 50 个工具时，更有趣的事情发生了：准确率大幅下降，Token 成本激增，且失败模式通常表现为模型幻觉出一个工具调用，而不是承认它不知道该用哪一个。来自 Berkeley Function Calling Leaderboard 的研究发现，在跨多个领域的日历调度任务中，当工具数量从 4 个扩展到 51 个时，准确率从 43% 骤降至仅 2%。这绝不是一个平滑的性能退化曲线。

大多数 LLM 流水线在无意中表现出了令人尴尬的顺序执行特征。一个智能体调用天气 API，等待 300 ms，调用日历 API，再等 300 ms，调用流量 API，再次等待 —— 最后才综合出一个答案。如果这三个调用是并行运行的，那 900 ms 的总延迟本可以缩减到 300 ms。没有人故意将系统设计成顺序执行；这只是在编写一个接一个的异步调用时自然而然产生的结果。

推测执行（Speculative execution）是一系列技术的统称，这些技术通过在你确定需要某些工作之前就提前执行它们，来降低感知的延迟 —— 包括运行并行的假设、预取可能的后续步骤以及同时生成多个候选输出。这些技术直接借鉴了 CPU 设计，自 20 世纪 90 年代以来，处理器就一直在推测性地执行未来的指令。应用到 AI 流水线时，这种本能 —— 押注可能的结果、取消失败者、接受偶然的浪费 —— 可以产生显著的加速。但如果你不小心选择应用时机，协调开销也可能会抵消所有的收益。

在扩展 AI Agent 时，大多数团队都会遇到一个违背直觉的失败模式：Agent 的工具集越强大，它的表现就越差。你为了处理更多场景而增加工具，准确率却下降了。你增加了更优秀的工具，它却变得更慢，并开始选错工具。你加入了编排逻辑来管理工具选择，结果你在原始的复杂性之上又重建了一层复杂性，而整个系统几乎无法运行。

增加工具的本能是错误的。生产环境中 Agent 的性能提升往往源于“删减”。

有一个 100 行代码的 Python Agent，在 SWE-bench Verified 上获得了 74–76% 的评分——仅比资金雄厚的团队构建的最先进系统低 4–6 个百分点。执行循环本身并不是复杂性所在。世界级的团队会投入 6 到 12 个月的时间来围绕该循环构建基础设施。这种基础设施有一个名字：Harness。

公式很简单：Agent = Model + Harness。Model 负责推理，Harness 负责其他一切——工具执行、上下文管理、安全管控、错误恢复、状态持久化以及人在回路（human-in-the-loop）工作流。如果你花了几个月的时间优化 Prompt 和模型选择，却交付了脆弱的 Agent，那么你一直在优化错误的东西。

大多数构建 AI Agent 的团队都犯了同样的错误：在没有证据表明需要复杂架构之前就过度设计。对 47 个 Agent 部署案例的生产分析发现，68% 的案例如果使用设计良好的单 Agent 系统，会获得相同甚至更好的结果。多 Agent 税——更高的延迟、复合的故障模式、运维复杂度——往往在用户感知到收益之前就将其消耗殆尽。

这并不是在反对 Agent，而是主张以构建任何严肃生产系统的方式来构建它们：从能工作的最简单方案开始，监控一切，只有在更简单的版本明显失效时才增加复杂度。

你将智能体连接到 50 个 MCP 工具。它可以查询数据库、调用 API、读取文件、发送电子邮件、浏览网页。理论上，它拥有所需的一切。但在实践中，一半的生产事故都源于工具使用——错误的参数、上下文预算超支、级联重试循环，导致成本是预期的十倍。

这是大多数教程都会跳过的部分：你加载的每个工具定义都是预先支付的 Token 税，甚至在智能体处理单条用户消息之前就开始计算了。连接了 50 多个工具后，仅定义一项就会在每次请求中消耗 70,000–130,000 个 Token。这并非极端情况——这是任何连接到多个 MCP 服务器的智能体的默认状态。

当你的智能体在放弃之前，第三次默默地重试同一个损坏的工具调用时，你就会意识到，“仅仅添加工具”并不是一种生产环境的策略。工具调用解锁了真正的能力——外部数据、副作用、保证格式的输出——但使其工作的智能体循环（agentic loop）具有在演示中不会表现出来的尖锐边缘。

这篇文章将探讨这些边缘：循环实际上是如何运行的，悄悄破坏并行执行的格式规则，如何编写能让模型做出正确选择的工具描述，以及如何处理错误以让模型恢复而不是陷入死循环。