Agent系列3：改变你做 AI Agent 的方式

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

这个更骚。

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

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

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

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 的例子，你可以直接在工具定义里放示例调用：

json 复制代码

{
  "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 怎么调，是学他们怎么思考问题、拆解问题、解决问题的。

磨平一些信息差。