Anthropic出手，补齐Agent当下的短板

文｜博阳

编辑｜徐青阳

早在 2024 年 11 月，Anthropic 的 Model Context Protocol （MCP）发布，它承诺了一个美好的未来，通过这个协议，大模型就能随意调用工具，瞬间获得操作整个数字世界的能力。OpenAI 在 2025 年 3 月曾公开表示要在自家产品里支持 MCP。

当时，业内都认为工具调用这个难题很快就会借着MCP得到解决，通向Agent元年之路畅通无阻。

因此 2025 年的夏天，MCP 生态确实爆发了。GitHub 上涌现了数以万计的 MCP Servers，从操作 Kubernetes 集群到订购披萨，似乎一切皆可 Agent 化。

然而一年多时间过去了，想象中Agent爆发的场景并没有发生，它们迷路了。

当企业试图将成百上千个内部工具挂载到自家Agent模型上时，它们开始变得迟钝、健忘，无法完成任务。全自动执行工具调用，很多时候变成了一场昂贵的报错循环。

在2025年的4月，我在和Konjie老师沟通的过程中，形成了一个共识，即MCP确实是一个残缺的协议，因为它没有规定大语言模型和MCP的交互模式。

也就是说，MCP只承诺提供统一的工具接口，但并没有规定大模型应该如何发现、选择、组合这些工具。

当时，kongjie老师认为，这个工作应该是Agent集成商或者Agent平台的活儿。但在这之后，除了LangChain一直在优化之外，大家的进步都很慢。

直到 2025 年 12 月，随着 Anthropic 低调但极其重要地发布了 高级工具调用（Advanced Tool Use）套件。终于自己动手补齐了这个「残缺」的协议。

这也许会带来Agent开发的新一轮重要变化。

01. 只有接口，没有规则

要理解为什么 Agent 会迷路，我们必须重新审视Agent和工具间到底有什么交互模式。

在 MCP 协议下，当一个 Agent 试图解决问题时，它必须经历四个连续的交互步骤：感知、决策、组装、执行。

在2025年的工程实践中，这四个步骤每一步都布满了地雷。

步骤一：感知阶段

在这个阶段中，Agent 做的是打开工具箱，查看自己有哪些能力可用。

在旧的MCP模式中，这是一个静态全量的过程。为了让 Agent 随时可用，开发者被迫把成百上千个工具的完整定义（Schema），包括名称、描述、参数结构一股脑塞进 System Prompt。

这导致了上下文的公地悲剧。

大量的工具说明书挤占了模型的上下文。根据Anthropic的计算，大概50 个工具的定义就会吃掉约 20,000 Tokens。结果Agent 的注意力全放在记住工具名上了，其他的执行、推理严重受损。

这一切，都是因为缺乏按需发现机制。模型只能遍历所有工具进行搜索。

步骤二：决策阶段

在这个阶段，Agent 根据用户指令，在工具列表中挑选最合适的那一个。而此时，当工具从 10 个增加到 1000 个时，列表里必然充满了功能高度相似的选项。

MCP 并没有提供区分这些细微差别的机制，模型只能依靠工具定义中微弱的语义差异去猜测。

这导致了决策瘫痪。

面对海量选项，模型的注意力机制被稀释，而且很容易选错。选错工具是连锁反应的开始。一旦第一步选错，后面的参数组装和执行全是无用功。

造成这一问题的原因，也是缺乏动态收缩机制。

步骤三：组装阶段

这一步，当Agent 选中了工具后，会开始根据 Schema 填写入参（Arguments）。

这是被大多数人忽视，但报错率最高的一步。MCP 的工具定义中，Schema 往往只定义了显性语法（例如：参数 date 是字符串），但没有传递隐性规则（例如：这个日期必须是 YYYY-MM-DD 格式，且不能早于 2020 年）。 更没有教你具体这个工具怎么用。

这导致了就算工具选对了，也得猜谜式试错。

Agent 只能靠直觉填参。然后经历报错 → 换个格式重试 → 再报错的地狱循环，在这一过程中，大量的 Token 被浪费在其中，而不是推进任务。

这一切都是因为MCP缺乏最佳实践的显式指引。模型不仅需要知道参数是什么类型，还需要知道参数长什么样，怎么用。

步骤四：执行阶段

在这一阶段中，Agent 发起调用，等待结果，读取结果，决定下一步。

在传统的 MCP 模式中，这是一个线性阻塞（Linear Blocking）的过程。 如果任务需要“翻阅 100 页日志找到报错行”，Agent 就必须进行 100 次“调用-等待-读取-思考”的循环。

这导致了推理瓶颈与信息污染。

首先它巨慢，每一次微小的操作都要经过一次完整的 LLM 推理和网络往返，耗时极长。而且它还会很脏，工具返回的中间结果（例如 100 页的原始日志）会被全量塞回上下文。这些垃圾数据不仅浪费 Token，还会干扰模型对最终结论的判断。

这就是MCP缺乏逻辑编排与数据清洗的能力。这导致它工具就算用上了，效率也很低，还会进一步增加天量的上下文。

这四个步骤的崩坏，构成了一个完美的失败闭环。而 Anthropic 的新工具，就是针对这四个步骤的精准爆破。

02. Anthropic 用三板斧，重建工具调用的秩序

Anthropic最新发布的这套被统称为 Advanced Tool Use 的功能，精确地对应了上述四个痛点，在混乱的 MCP 荒原上重建秩序。

下面我们就来看看，他们是怎么一一松动这些“屎山问题”的。

1. 修复感知与决策：Tool Search Tool

针对「感知阶段的上下文超载」和「决策阶段的瘫痪」，Anthropic 给出的解法是 Tool Search（工具搜索），

它可以帮助MCP，不要把所有工具定义一股脑塞进上下文；而是先搜索，再只加载少量候选工具的定义。这把缺失的「工具发现与按需加载」做成了平台级能力。

Tool Search 的工作流程可以分为七步。

那它和过去有什么不同呢？

Tool Search就这三招：先收缩工具空间，再做精确选择，同时隐藏工具描述。

不过，这个工具依然有Anthropic只做系统层的限制，它「只负责找工具，不负责保证一定找对」。它的每次搜索只返回 3–5 个最相关工具。如果工具描述写得差、关键词不匹配、同义词覆盖不足，就可能搜不到你期待的工具。

所以文档还给出了工具库优化的建议。比如工具名/描述要清晰、描述里放用户会用的关键词、系统提示里提示工具类别等。

但只要定义准确，用户靠它一下就可以省下上万的token，进而把上下文空间还给计划、状态和约束，而不是被工具说明书吃掉。

2. 修复组装：Tool Use Examples

解决了找不到合适工具的问题，紧接就要解决怎么用工具的问题。

针对模型不知道怎么填参的痛点，Anthropic 引入了 Tool Use Examples（工具使用示例） 标准。

通过增加几个范例，模型可以更好的调用其 Few-Shot Learner（少样本学习者）的能力，更好的学会如何使用这些工具参数。

举个例子，比如我要链接个出票工具。

Anthropic 的内部数据显示，仅仅是加上这些示例，模型在处理复杂参数组装时的准确率就从 72% 飙升到了 90%。

更重要的是，它终结了那个报错-道歉-重试死循环，让组装这个工具使用步骤更精准。

3. 修复执行：Programmatic Tool Calling (PTC)

最后 Anthropic 通过加入 PTC (Programmatic Tool Calling)解决「执行阶段慢与脏」的问题。

回顾第一章，传统的 Agent 调一次工具，就需要看一眼返回结果，再调一次工具。这不仅慢，而且把中间看到的几千行垃圾日志全塞进了上下文，导致后续推理难以为继。

PTC 则允许模型编写代码来重新编排执行流程。 模型自己不再去翻页、过滤、查找，而是写一段脚本交给 Python 解释器去循环、过滤、聚合、并行。而模型只在关键时刻（比如换工具时）介入，它只接受结构化的脚本输出作为上下文，而不是把全部中间数据灌给模型。

这一改变让过去几十次网络往返被压缩成了一次秒级的代码执行。而且中间过程产生的数以万计的垃圾上下文在代码层就被消化了，永远不会污染模型的推理上下文。

Anthropic 的这套组合拳，本质上是在原本残缺的 MCP 接口层之上，强行构建了一个「交互层」。Tool Search 确保了模型能看见（Perception）正确的东西；Examples 确保了模型能组装（Formulation）正确的指令；PTC 确保了模型能执行（Execution）高效的操作。