Anthropic 新发的三个工具调用功能，可能会改变你做 AI Agent 的方式

故事是这样的。

前两天 Anthropic 发了一篇技术博客，讲的是他们新推出的三个高级工具调用功能。本来我也就随便扫一眼，觉得"哦又是 API 更新"，结果看着看着我愣住了。

这玩意儿，解决的是 AI Agent 落地过程中最核心的几个痛点。

不夸张地说，这篇东西可能会改变很多人做 AI Agent 的方式。

---

先问你一个问题

你有没有遇到过这种情况：你给 Claude 或者 GPT 接了一堆工具——GitHub、Slack、Jira、Google Drive……然后发现模型在疯狂犯错，明明应该用 notification-send-user，结果调了 notification-send-channel，或者参数填得一塌糊涂，日期格式乱七八糟。

很多人觉得这是模型不够聪明。

但 Anthropic 这篇文章直接把问题刨开了：不是模型不够聪明，是你塞给它的东西太多了。

文章里给了个数据：

服务	工具数量	Token 消耗
GitHub	35 个工具	~26K tokens
Slack	11 个工具	~21K tokens
Sentry + Grafana + Splunk	12 个工具	~8K tokens
合计	58 个工具	~55K tokens

对话还没开始，5 万多个 token 就没了。

更吓人的是，他们自己内部见过工具定义消耗 134K tokens 的情况。134K 啊朋友们，Claude 3.5 的上下文窗口才 200K，还没干正事儿呢，三分之二就没了。

这就是所谓的 “Context Bloat”，上下文膨胀。

---

功能一：Tool Search Tool

思路特别简单粗暴：与其一开始把所有工具定义都塞进去，不如只给模型一个搜索工具，让它按需发现。

就像你去图书馆借书，不会把整个图书馆的书都背在身上，而是需要什么找什么。

这个改动带来的效果，不是一点点提升，是质变。

指标	传统方式	Tool Search Tool
Token 消耗	~72K	~8.7K
上下文窗口保留	~64%	95%
Opus 4 准确率	49%	74%
Opus 4.5 准确率	79.5%	88.1%

准确率反而更高了，因为它不需要在一堆工具里瞎找。

我之前做 AI Agent 的时候就特别痛苦，给模型接了十几个工具，它就真的会乱选。现在看来，不是模型的问题，是我喂太多了。

---

功能二：Programmatic Tool Calling

这个更骚。

传统工具调用有个巨大的问题：中间结果会疯狂污染上下文。

比如你要检查哪些团队成员超了差旅预算，你需要调三个工具：

1. 获取团队成员
2. 获取每人的费用记录
3. 获取预算标准

20 个人的团队，每人的费用记录有 50-100 条明细，这就是 2000 多条数据，50KB 以上，全部塞进模型的上下文。

模型还得一条条去算，去比对。

这个过程又慢又容易出错，而且会把真正重要的信息挤出上下文窗口。

Programmatic Tool Calling 的思路是：让 Claude 写 Python 代码来编排整个流程。代码在沙箱里跑，工具调用的中间结果不进模型的上下文，只有最终结果进去。

上面的例子，2000 多条费用明细，全部在代码里处理完，最终只给模型看谁超标了。

从 200KB 的原始费用数据，变成 1KB 的最终结果。

指标	传统方式	Programmatic Tool Calling
平均 Token 用量	43,588	27,297 (-37%)
知识检索准确率	25.6%	28.5%
GIA 基准	46.5%	51.2%

我看完这部分的时候就在想：这特么不就是让 AI 干它最擅长的事儿吗，写代码比写自然语言推理靠谱多了。

---

功能三：Tool Use Examples

这个相对直观。

JSON Schema 能定义参数的类型、必填字段、枚举值，但它定义不了使用模式。比如：

• 日期应该用什么格式
• 用户 ID 是 UUID 还是 USR-12345 这种格式
• 可选参数在什么情况下该填、什么不该填

文章里举了个工单 API 的例子，你可以直接在工具定义里放示例调用：

{
  "name": "create_ticket",
  "input_examples": [
    {
      "title": "Login page returns 500 error",
      "priority": "critical",
      "labels": ["bug", "authentication", "production"],
      "reporter": {
        "id": "USR-12345",
        "name": "Jane Smith",
        "contact": {"email": "jane@acme.com"}
      },
      "due_date": "2024-11-06"
    }
  ]
}

从这些示例里，模型能学到：

• 日期用 YYYY-MM-DD 格式
• 用户 ID 是 USR-XXXXX 格式
• critical 级别的 bug 需要完整联系方式和紧急升级配置

内部测试，工具使用准确率从 72% 提升到了 90%。

---

背后的哲学

看完这三个功能，我突然意识到一件事。

Anthropic 不是在简单地优化 API，他们在重新思考 AI Agent 到底应该怎么干活。

传统思路是：把所有工具定义塞进 prompt，让模型在自然语言里推理、选择、调用。这个思路有个前提假设——模型足够聪明，能处理所有这些信息。

但现实是：上下文窗口再大也是有上限的，信息越多干扰越多，模型越容易犯错。

Anthropic 的新思路是：

• 模型不需要知道所有工具，只需要知道怎么找到它需要的工具
• 模型不需要看到所有中间结果，只需要代码替它处理完
• 模型不需要猜测怎么用工具，你直接示范给它看

搜索而非枚举，代码而非推理，示例而非定义。

这三件事背后是同一个哲学：把模型的认知负担降到最低，让它专注于真正需要判断力的地方。

我有时候觉得，做 AI 产品跟教育孩子有点像。不是你教的东西越多越好，而是你教的方式要对。你给孩子一个图书馆，不如先教会他怎么用索引。

---

怎么用

文章最后有个建议我觉得特别好：不是每个 Agent 都需要三个功能全上，先看看你的瓶颈在哪。

问题	解决方案
上下文爆炸	Tool Search Tool
中间结果污染上下文	Programmatic Tool Calling
参数错误频发	Tool Use Examples

对症下药，别上来就全副武装。

这三个功能现在都是 beta 状态，需要在 API 请求里加 beta header。我估计很快会 GA。

---

最后

老实说，看完这篇文章我挺兴奋的。不是兴奋于新功能本身，而是兴奋于这种工程思路。AI Agent 这件事，很多人都在做，但真正思考清楚底层问题并给出系统解决方案的，Anthropic 算是往前迈了一大步。

对了，这三个功能是互补的：

• Tool Search Tool 负责找到对的工具
• Programmatic Tool Calling 负责高效执行
• Tool Use Examples 负责正确调用

一个完整的工具使用闭环。

我觉得做 AI Agent 的朋友们可以好好看看这篇文章，不是学 API 怎么调，是学他们怎么思考问题、拆解问题、解决问题的。

磨平一些信息差。