Anthropic 的工程团队又发表了一篇 AI Agent 相关的技术文章—— 《Anthropic 官方分享：为 AI 智能体打造高效工具——让 AI 智能体来帮忙 》 。他们家的文章我每篇都至少看三遍，绝对是学习 AI Agent 开发的必读材料，毕竟，目前地表最强的 Coding Agent Claude Code 就出自他们之手，全是宝贵的一手实战经验。
很多人好奇 Claude Code 为什么这么强？其实秘诀可以归结为两点：
强大的 Agent 模型 + “量身定制”的高效工具
你可能会说，编程能力和上下文工程也很重要。没错，但如今强大的编程能力已是一线大模型的基础标配；而所谓的“上下文工程”，如果你深入去看 Claude Code 的实现，会发现其核心也是通过 工具 来巧妙管理的。它并没有什么花哨的技巧，就是把会话信息和工具集交给模型，让模型自己决定下一步是调用工具还是输出结果。
大语言模型的三种能力“天赋点” 在深入聊工具之前，我们得先明白，现在的大语言模型已经分化出了不同的能力：
1. 聊天能力 (Chat) ：即语言理解与生成能力，能看懂用户输入的内容并生成高质量的文字回复，以 GPT-4o 为代表。 2. 推理能力 (Reasoning) ：即逻辑推理能力，通常通过**链式思考（Chain of Thought，CoT）**提升，可以处理复杂的数学问题和编程任务，以 DeepSeek R1、o1 为代表。 3. Agent 能力 (Agent) ：即自主规划与执行任务，主动调用外部工具或资源，自动完成复杂目标任务，以 Claude 4系列、GPT-5 为代表，国内的 豆包Seed 1.6、DeepSeek V3、GLM 4.5、Kimi K2、Qwen-Coder 等模型也有不错表现。
这些能力有时会存在“冲突”。比如像 Gemini 2.5 Pro 代码能力和写作能力都很强，但 Agent 能力却一般，导致基于它之上的 Gemini CLI 表现平平；与之相对的 GPT-5、Claude 4 的 Agent 能力非常强大，但写作表现反而一般，尤其是 GPT-5，写出来的文章简直没法看。
我想未来的发展趋势还是向更通用、更均衡的方向发展，目前 GPT-5 就在尝试这个方向，但还不够成熟；GPT-6 或许可以实现这样的突破。接下来期待一下 Gemini 3.0 和 DeepSeek R2，希望能给我们带来一些惊喜。
Agent 的成败，关键在工具 当一个模型具备了强大的 Agent 能力后， 工具 就成了它的手和脚，决定了它能力的上限。没有趁手的工具，再聪明的 Agent 也寸步难行。
这就是为什么 Claude Code 即使换成其他具备 Agent 能力的国产模型，表现依然不俗。因为它那套为编程场景精心设计的十几个工具，组合起来几乎能覆盖所有编程任务。
现在如果如果你要开发一个 Agent 应用，除非你非得用特定模型，大家起点都差不多，这些模型的价格也都能接受，反倒是工具成了成败的关键。
现在，让我们回到 Anthropic 的文章，看看他们总结的五大核心原则，学习如何打造“神器”级工具。
高效工具的五大核心原则 1. 谨慎选择工具：少即是多 工具并非越多越好。一个常见的误区是把现有的 API 简单封装成工具丢给 Agent。这完全没考虑到 Agent 的“思考”方式。
Agent 的“上下文”是它有限的“内存” ，而传统程序的内存则近乎无限。
文章举了一个例子：在一个地址本里找联系人。
• 糟糕的工具 ： list_contacts() ，它会返回所有联系人，Agent 不得不逐一“阅读”，极大浪费了宝贵的上下文空间。 • 高效的工具 ： Contactss(name="Jane") ，它直奔主题，只返回相关结果，就像我们人类会按字母索引查找一样。
核心思想 ： 用一个强大的复合工具，替代多个单一功能的小工具。
• 反例 ：提供 list_users 、 list_events 、 create_event 三个工具。 • 正解 ：提供一个 schedule_event 工具，它在内部完成查找参会者、检查日历、创建会议等一系列操作。
这样做既能减少工具数量，避免 Agent“选择困难”，又能将复杂的中间步骤“黑盒化”，大大降低 Agent 犯错的概率。
2. 清晰的命名空间：给工具“贴标签” 当工具变多时，Agent 很容易混淆。清晰的命名空间（给工具名加上统一的前缀或后缀）能像路牌一样引导 Agent 做出正确选择。
之前 Manus 有一篇《AI 智能体的上下文工程：构建高效 Agent 的七个宝贵教训》里面也提到类似的技巧，借助统一的前缀为工具分组。
例如，通过服务和资源来划分：
• 按服务 ： asana_search vs jira_search • 按资源 ： asana_projects_search vs asana_users_search
这种方式能显著降低模型调用错误工具的概率。
3. 返回高信息密度的上下文：说“人话”，别说“机器码” 工具返回给 Agent 的信息，质量远比数量重要。Agent 更擅长处理自然语言，而不是看不懂的机器 ID。
文章里的例子一针见血：
• 糟糕的返回 ：返回一长串 UUID，如 user_id: "8a7b9c1d-f2e3-4a5b-8c6d-7e8f9a0b1c2d" 。Agent 很难理解和利用这个信息。 • 优秀的返回 ：直接返回有意义的名称，如 user_name: "Jane Doe" ，或者至少是更易于处理的 0 索引 ID。
一个更高级的技巧是，让 Agent 自己决定需要多详细的信息。可以在工具中加入一个 response_format 参数：
enum ResponseFormat { DETAILED = "detailed" , # 返回所有细节 CONCISE = "concise" # 只返回核心信息 } 这样 Agent 就可以按需索取，灵活又高效。
4. 优化 Token 效率：不只要高质量，还要高“性价”比 上下文空间寸土寸金，除了保证返回信息的质量，控制数量也至关重要。
举个 Claude Code 的细节，如果你一个代码文件少于 2000 行（实际可能有出入）， Claude 会直接一次性加载到上下文中，如果超过这个数，那么它就会先调用代码检索工具，从文件中检索出跟上下文相关的一部分代码读取，根据需要可能多次读取，这样就算面对十万行以上的代码文件（我自己测试过），也能正常工作，而不是马上爆掉上下文。这就是典型的 Token 效率优化。
前面提到的 Manus 的那篇文章，也有过类似的分享：将文件系统作为外部上下文，就是把长的内容存到文件系统中，上下文中只保留文件路径，需要的时候再完整读取或者部分读取。
另一个被很多人忽略的细节是 错误信息 。当工具调用失败时，一个好的错误提示能引导 Agent 自我纠错。
• 无用的错误 ： { "error": "InvalidInput" } （Agent：错在哪了？我该怎么办？🤔） • 有用的错误 ： { "error": "Invalid date", "message": "Date '2022-01-01' is in the past. Please provide a future date." } （Agent：原来是日期错了，我马上改！👍）
好的错误信息不仅告诉 Agent “出错了” ，还告诉它 “错在哪” 以及 “如何修复” 。
嗯，Manaus 那篇文章也提到了保留并利用错误信息进行纠错。
5. 精心打磨工具描述：这是给 AI 的“说明书” 工具的描述（Description）和参数说明，是 Agent 理解工具用途的唯一途径。 这本身就是一种“提示工程” 。
文章建议，你应该像 向一位新入职的同事解释这个工具 一样来写描述。把所有潜在的歧义、专业术语、使用前提都讲清楚。
• 模糊的参数名 ： user (是用户 ID？用户名？还是邮箱？) • 清晰的参数名 ： user_id 或 user_email
Anthropic 文章中透露， Claude Sonnet 3.5 在权威的 SWE-bench 编程评测中能取得 SOTA 成绩，其中一个关键因素就是他们对工具描述进行了精确的优化，从而大幅降低了模型的错误率。
最后 打造高效的 Agent 工具是一个需要反复迭代和评估的系统工程。它要求我们转变思维，从为确定性系统编程，转向为非确定性的 Agent 设计“交互界面”。
当然，这篇文章的内容远不止我总结的这些，强烈建议你阅读原文和翻译版本，相信会有更多收获。
• 原文链接 ： Writing effective tools for LLM agents—using LLM agents https://www.anthropic.com/engineering/writing-tools-for-agents • 文中提到的 Manus 文章 ： Context Engineering for AI Agents: Lessons from Building Manus 《AI 智能体的上下文工程：构建 Manus 的经验教训》 https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus 我的解读： https://baoyu.io/blog/explain-Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus 
粤ICP备14082021号
免费POC，
零成本试错
