跳转到内容
Yzx Wiki

Writing effective tools for agents — with agents

简介

Section titled “简介”

这是一篇 Anthropic 关于 agent 工具设计的工程文章。文章的核心判断是：agent 的能力上限，很大程度上受限于给它的工具是否“适合 agent 使用”。因此，工具不该只按传统 API 或函数接口的思路去写，而应被视为一种介于确定性系统与非确定性 agent 之间的新契约，并通过原型、evaluation 和 agent-assisted optimization 反复打磨。

关键点

Section titled “关键点”
  • 文章先明确区分了传统软件接口与 agent 工具的差异：传统函数面向确定性系统，而 agent 工具面对的是会误解、会跳步、会幻觉的非确定性调用者。
  • Anthropic 给出的实践流程很清晰：先快速搭一个工具原型，在本地 MCP server、Claude Code 或 API 中手动试用；再构建 grounded in real-world 的 evaluation；最后让 Claude Code 自己分析 transcript、重写工具实现和描述。
  • 文章特别强调 evaluation 的现实性。好的任务通常需要多个工具调用、贴近真实数据和真实工作流；差的任务则只是“会不会调某个 API”的沙箱题。
  • verifier 不必过度机械。它可以是字符串比对，也可以让 Claude 做 judge，但不应因为格式细节或合理变体而误杀正确答案。
  • 除了准确率，文章建议同时跟踪 runtime、tool call 数量、token 消耗和错误率，因为这些指标能揭示工具是否让 agent 走了绕路策略。
  • 在 Anthropic 的内部实验里，Claude Code 不只是实现工具，还能通过分析 held-out evaluation transcripts 继续优化工具自身，甚至在 test set 上超过“专家手写”实现。
  • 文章沉淀出的设计原则包括：只做高价值且真正适合 agent 的工具；用 namespacing 清晰划分边界；返回高信号、语义清晰的上下文；通过 concise/detailed 等模式控制响应粒度；用分页、过滤、截断和更好的报错来节省 token；以及把 tool description 当 prompt 一样精细调优。
  • 一个很关键的例子是：很多看似“功能完整”的底层 API 工具，其实对 agent 并不友好。比起 list_contacts，agent 往往更需要 search_contacts 或 message_contact 这类更贴近任务分解方式的工具。
  • 文章还指出，连 namespacing 的前缀/后缀选择、返回格式是 XML/JSON/Markdown、甚至错误提示的措辞，都会在 evaluation 上产生非平凡影响。

ℹ️ Conflict:

  • “更多工具” 不等于更强。过多、重叠或过底层的工具会让 agent 更分心、更耗 context，也更容易走错路径。
  • 这篇文章倡导 evaluation-driven tool design，但也隐含一个代价：为了让 agent 工具真正高效，你需要持续维护 eval、held-out test set 和 transcript 分析流程，这本身就是额外工程负担。

相关链接

Section titled “相关链接”

来源引用

Section titled “来源引用”