Claude Code 为何如此强大？Anthropic 万字长文揭秘 AI Agent 工具开发五大“心法”

Anthropic 的工程团队又发表了一篇 AI Agent 相关的技术文章——《为 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 设计“交互界面”。

当然，这篇文章的内容远不止我总结的这些，强烈建议你阅读原文和翻译版本，相信会有更多收获。

See all posts