【技术干货收藏】Anthropic三大新功能实战:彻底解决AI Agent工具使用痛点
Anthropic近期发布三大Beta功能(Tool Search Tool、Programmatic Tool Calling和Tool Use Examples),分别解决AI Agent开发中的工具选择困境、上下文诅咒和参数格式问题。通过按需加载工具定义、代码编排处理流程和示例教学,大幅降低token消耗近90%,提升准确率20%以上,推动AI Agent从"Prompt Engineeri
前言
之前分析了AI Agent面临的两大瓶颈:工具选择的困境和上下文的诅咒。那时我还只是基于概念性的探讨,预判这会是行业必须攻克的难题。
没想到,Anthropic的效率比我想象的还要快。
就在11月24日,他们正式发布了三项Beta功能,直接将这些想法落地成了产品。这不是论文,不是概念验证,而是可以在Claude开发者平台上直接调用的真实API。
这篇文章,我将带你深入拆解这三个功能——Tool Search Tool、Programmatic Tool Calling 和 Tool Use Examples。它们分别瞄准了AI Agent开发中最头疼的三个问题:找工具、用工具、以及用对工具。
第一招:Tool Search Tool——让AI学会"查字典"
痛点:工具太多,上下文先爆了
来看一个真实的数据。当你给AI接入5个常见的MCP服务时:
| 服务 | 工具数量 | Token消耗 |
|---|---|---|
| GitHub | 35个工具 | ~26K tokens |
| Slack | 11个工具 | ~21K tokens |
| Sentry | 5个工具 | ~3K tokens |
| Grafana | 5个工具 | ~3K tokens |
| Splunk | 2个工具 | ~2K tokens |
| 合计 | 58个工具 | ~55K tokens |
还没开始干活,55K tokens就没了。如果再加上Jira(~17K tokens),你的上下文直接逼近100K。Anthropic透露,他们内部测试时甚至见过134K tokens被工具定义吃掉的极端情况。
更致命的是,工具太多还会让AI"眼花"。当存在notification-send-user和notification-send-channel这样名字相近的工具时,AI很容易选错。
解法:按需加载,而非全量预载
Tool Search Tool的思路很简单:不要让AI背着整个工具箱上路,而是教它使用"工具目录"。
实现方式是这样的:你把所有工具定义照常提交给API,但给绝大多数工具标记上defer_loading: true。这些工具不会进入AI的初始上下文——AI一开始只看到一个"搜索工具"的能力(大约500 tokens)。
当任务来临时,AI会先搜索"我需要什么工具",找到相关的3-5个工具后,才把它们的完整定义加载进来。
效果如何?看这张官方对比图:

Tool Search Tool对比图
左边是传统方式:所有工具定义预加载,消耗77K tokens;右边是Tool Search Tool:按需加载,只消耗8.7K tokens
- Token消耗:从77K降至8.7K,节省近90%
- 准确率提升:Opus 4从49%提升到74%,Opus 4.5从79.5%提升到88.1%
这就像是把"死记硬背"变成了"开卷考试"——AI不需要记住所有工具的细节,只需要知道"有这么一本目录可以查"。
第二招:Programmatic Tool Calling——让AI用代码说话
痛点:回合制交互,中间结果撑爆上下文
这个痛点我在上一篇文章里详细讲过。传统的工具调用是"你一句我一句"的回合制:
- AI请求获取员工列表(等待…)
- 系统返回20个员工
- AI逐个请求每个人的账单(等待20次…)
- 系统返回几千条账单流水(AI被迫全部读入上下文)
- AI终于得出结论
问题在于:那几千条账单明细,AI真正需要的只是"谁超标了"这个结论,但它不得不把所有原始数据都塞进自己的"大脑"里。
解法:让AI写脚本,自己跑批处理
Programmatic Tool Calling允许AI编写一段Python代码来编排整个工作流。代码在安全沙箱中运行,自行调用工具、处理数据、做聚合计算,最后只把精炼的结果返回给AI。

Programmatic Tool Calling流程图
关键区别:工具调用的结果不再返回给模型,而是在代码执行环境中直接处理,最终只有精炼结果进入AI上下文
看这段AI生成的代码:
team = await get_team_members("engineering")
# 并行获取所有级别的预算
levels = list(set(m["level"] for m in team))
budget_results = await asyncio.gather(*[
get_budget_by_level(level) for level in levels
])
budgets = {level: budget for level, budget in zip(levels, budget_results)}
# 并行获取所有人的开支
expenses = await asyncio.gather(*[
get_expenses(m["id"], "Q3") for m in team
])
# 计算超标人员
exceeded = []
for member, exp in zip(team, expenses):
budget = budgets[member["level"]]
total = sum(e["amount"] for e in exp)
if total > budget["travel_limit"]:
exceeded.append({
"name": member["name"],
"spent": total,
"limit": budget["travel_limit"]
})
print(json.dumps(exceeded))
这段代码的精妙之处:
- 并行执行:用
asyncio.gather同时发起多个请求,而不是逐个等待 - 本地计算:数据聚合在沙箱里完成,不经过AI的上下文
- 精准输出:AI最终只看到
exceeded这个列表,而非2000+条原始账单
实测数据:
- Token消耗:从43,588降至27,297,减少37%
- 准确率:GIA基准测试从46.5%提升至51.2%
- 延迟:省掉了19+次模型推理的时间
Anthropic还透露,他们的新产品Claude for Excel就是用这个技术实现的——可以读写几千行的电子表格,而不会撑爆上下文。
第三招:Tool Use Examples——用例子说话
痛点:JSON Schema能定义结构,但无法传达"潜规则"
这是一个容易被忽视、但实战中极其恼人的问题。
看这个工单创建工具的Schema:
{
"due_date": {"type": "string"},
"reporter_id": {"type": "string"}
}
Schema告诉AI:“这两个字段都是字符串”。但它没说:
due_date到底要2025-11-25还是Nov 25, 2025?reporter_id是12345还是USR-12345?
以前,开发者只能在描述里写一大堆文字说明,或者祈祷AI猜对。
解法:直接给例子,一看就懂
Tool Use Examples允许你直接在工具定义里嵌入具体的调用示例:
{
"name": "create_ticket",
"input_schema": {...},
"input_examples": [
{
"title": "Login page returns 500 error",
"priority": "critical",
"reporter": {"id": "USR-12345", "name": "Jane Smith"},
"due_date": "2024-11-06"
},
{
"title": "Add dark mode support",
"reporter": {"id": "USR-67890", "name": "Alex Chen"}
},
{
"title": "Update API documentation"
}
]
}
三个例子,AI瞬间学会:
- 日期格式是YYYY-MM-DD
- 用户ID是USR-开头的
- 紧急bug要填完整信息,普通需求可以简化,内部任务只需标题
这就是少样本学习(Few-shot Learning)直接嵌入工具层。效果:复杂参数的调用准确率从72%飙升到90%。
组合拳:三者如何协同工作?
这三个功能不是孤立的,它们解决的是AI使用工具的完整链路:
| 环节 | 痛点 | 解法 |
|---|---|---|
| 发现工具 | 工具定义太多,撑爆上下文 | Tool Search Tool(按需加载) |
| 执行工具 | 中间结果太多,回合制低效 | Programmatic Tool Calling(代码编排) |
| 调对工具 | 参数格式不明,容易出错 | Tool Use Examples(示例教学) |
Anthropic在文章中给出了分层策略的建议:
先找瓶颈,再上对应方案:
- 如果上下文被工具定义撑爆 → 先上Tool Search Tool
- 如果中间结果太多影响推理 → 上Programmatic Tool Calling
- 如果参数总是填错 → 加Tool Use Examples
然后逐层叠加: Tool Search Tool确保找对工具,Programmatic Tool Calling确保高效执行,Tool Use Examples确保调用正确
AI Agent正在从"实习生"变成"资深工程师"
回顾这三个功能,它们的共同点是什么?
都在教AI用"工程师思维"解决问题,而非用"学生思维"死记硬背。
- Tool Search Tool:资深工程师不会背API文档,他会查
- Programmatic Tool Calling:资深工程师不会手动逐行处理数据,他会写脚本
- Tool Use Examples:资深工程师学习新API,第一件事是看example
Anthropic正在把这些"工程师常识"内化到AI的工作方式中。这不仅仅是功能的迭代,更是AI Agent开发范式的转变——从"Prompt Engineering"走向真正的"Software Engineering"。
当AI可以自主搜索工具、编写代码批量处理数据、并在看不见的沙箱里完成复杂逻辑时,我们对它的信任边界在哪里?
以前,AI的每一步操作都摊在上下文里,我们可以看到它"在想什么"。现在,越来越多的过程被封装进代码里、隐藏在沙箱中。我们看到的只是输入和输出。
这是效率的必然代价,但也值得每一个AI应用开发者认真思考。
如何开始使用?
这三个功能目前都是Beta状态,需要通过特定的header开启:
client.beta.messages.create(
betas=["advanced-tool-use-2025-11-20"],
model="claude-sonnet-4-5-20250929",
max_tokens=4096,
tools=[
{"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"},
{"type": "code_execution_20250825", "name": "code_execution"},
# 你的工具定义...
]
)
如果你正在构建复杂的AI Agent系统,尤其是需要接入大量MCP服务的场景,我强烈建议去认真研究。
普通人如何抓住AI大模型的风口?
为什么要学AI大模型
当下,⼈⼯智能市场迎来了爆发期,并逐渐进⼊以⼈⼯通⽤智能(AGI)为主导的新时代。企业纷纷官宣“ AI+ ”战略,为新兴技术⼈才创造丰富的就业机会,⼈才缺⼝将达 400 万!
DeepSeek问世以来,生成式AI和大模型技术爆发式增长,让很多岗位重新成了炙手可热的新星,岗位薪资远超很多后端岗位,在程序员中稳居前列。

与此同时AI与各行各业深度融合,飞速发展,成为炙手可热的新风口,企业非常需要了解AI、懂AI、会用AI的员工,纷纷开出高薪招聘AI大模型相关岗位。
AI大模型开发工程师对AI大模型需要了解到什么程度呢?我们先看一下招聘需求:

知道人家要什么能力,一切就好办了!我整理了AI大模型开发工程师需要掌握的知识如下:
大模型基础知识
你得知道市面上的大模型产品生态和产品线;还要了解Llama、Qwen等开源大模型与OpenAI等闭源模型的能力差异;以及了解开源模型的二次开发优势,以及闭源模型的商业化限制,等等。

了解这些技术的目的在于建立与算法工程师的共通语言,确保能够沟通项目需求,同时具备管理AI项目进展、合理分配项目资源、把握和控制项目成本的能力。
产品经理还需要有业务sense,这其实就又回到了产品人的看家本领上。我们知道先阶段AI的局限性还非常大,模型生成的内容不理想甚至错误的情况屡见不鲜。因此AI产品经理看技术,更多的是从技术边界、成本等角度出发,选择合适的技术方案来实现需求,甚至用业务来补足技术的短板。
AI Agent
现阶段,AI Agent的发展可谓是百花齐放,甚至有人说,Agent就是未来应用该有的样子,所以这个LLM的重要分支,必须要掌握。
Agent,中文名为“智能体”,由控制端(Brain)、感知端(Perception)和行动端(Action)组成,是一种能够在特定环境中自主行动、感知环境、做出决策并与其他Agent或人类进行交互的计算机程序或实体。简单来说就是给大模型这个大脑装上“记忆”、装上“手”和“脚”,让它自动完成工作。
Agent的核心特性
自主性: 能够独立做出决策,不依赖人类的直接控制。
适应性: 能够根据环境的变化调整其行为。
交互性: 能够与人类或其他系统进行有效沟通和交互。

对于大模型开发工程师来说,学习Agent更多的是理解它的设计理念和工作方式。零代码的大模型应用开发平台也有很多,比如dify、coze,拿来做一个小项目,你就会发现,其实并不难。
AI 应用项目开发流程
如果产品形态和开发模式都和过去不一样了,那还画啥原型?怎么排项目周期?这将深刻影响产品经理这个岗位本身的价值构成,所以每个AI产品经理都必须要了解它。

看着都是新词,其实接触起来,也不难。
从0到1的大模型系统学习籽料
最近很多程序员朋友都已经学习或者准备学习 AI 大模型,后台也经常会有小伙伴咨询学习路线和学习资料,我特别拜托北京清华大学学士和美国加州理工学院博士学位的鲁为民老师(吴文俊奖得主)
给大家准备了一份涵盖了AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频 全系列的学习资料,这些学习资料不仅深入浅出,而且非常实用,让大家系统而高效地掌握AI大模型的各个知识点。

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
适学人群
应届毕业生: 无工作经验但想要系统学习AI大模型技术,期待通过实战项目掌握核心技术。
零基础转型: 非技术背景但关注AI应用场景,计划通过低代码工具实现“AI+行业”跨界。
业务赋能突破瓶颈: 传统开发者(Java/前端等)学习Transformer架构与LangChain框架,向AI全栈工程师转型。
AI大模型系统学习路线
在面对AI大模型开发领域的复杂与深入,精准学习显得尤为重要。一份系统的技术路线图,不仅能够帮助开发者清晰地了解从入门到精通所需掌握的知识点,还能提供一条高效、有序的学习路径。
- 基础篇,包括了大模型的基本情况,核心原理,带你认识了解大模型提示词,Transformer架构,预训练、SFT、RLHF等一些基础概念,用最易懂的方式带你入门AI大模型
- 进阶篇,你将掌握RAG,Langchain、Agent的核心原理和应用,学习如何微调大模型,让大模型更适合自己的行业需求,私有化部署大模型,让自己的数据更加安全
- 项目实战篇,会手把手一步步带着大家练习企业级落地项目,比如电商行业的智能客服、智能销售项目,教育行业的智慧校园、智能辅导项目等等

但知道是一回事,做又是另一回事,初学者最常遇到的问题主要是理论知识缺乏、资源和工具的限制、模型理解和调试的复杂性,在这基础上,找到高质量的学习资源,不浪费时间、不走弯路,又是重中之重。
AI大模型入门到实战的视频教程+项目包
看视频学习是一种高效、直观、灵活且富有吸引力的学习方式,可以更直观地展示过程,能有效提升学习兴趣和理解力,是现在获取知识的重要途径

光学理论是没用的,要学会跟着一起敲,要动手实操,才能将自己的所学运用到实际当中去,这时候可以搞点实战案例来学习。
海量AI大模型必读的经典书籍(PDF)
阅读AI大模型经典书籍可以帮助读者提高技术水平,开拓视野,掌握核心技术,提高解决问题的能力,同时也可以借鉴他人的经验。对于想要深入学习AI大模型开发的读者来说,阅读经典书籍是非常有必要的。
600+AI大模型报告(实时更新)
这套包含640份报告的合集,涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师,还是对AI大模型感兴趣的爱好者,这套报告合集都将为您提供宝贵的信息和启示。
AI大模型面试真题+答案解析
我们学习AI大模型必然是想找到高薪的工作,下面这些面试题都是总结当前最新、最热、最高频的面试题,并且每道题都有详细的答案,面试前刷完这套面试题资料,小小offer,不在话下

AI时代,企业最需要的是既懂技术、又有实战经验的复合型人才,**当前人工智能岗位需求多,薪资高,前景好。**在职场里,选对赛道就能赢在起跑线。抓住AI这个风口,相信下一个人生赢家就是你!机会,永远留给有准备的人。
如何获取?
这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

火山引擎开发者社区是火山引擎打造的AI技术生态平台,聚焦Agent与大模型开发,提供豆包系列模型(图像/视频/视觉)、智能分析与会话工具,并配套评测集、动手实验室及行业案例库。社区通过技术沙龙、挑战赛等活动促进开发者成长,新用户可领50万Tokens权益,助力构建智能应用。
更多推荐
所有评论(0)