如何为 Agent 设计好用的工具

如何为 Agent 设计好用的工具

原文：Writing effective tools for agents — with agents | Anthropic Engineering Blog | 2025.9.11

导语

Agent 的效能取决于我们为其提供的工具。

这是 Anthropic 在这篇博客中反复强调的核心观点。MCP 可以为 Agent 提供数百种工具，但如何让这些工具真正发挥效能？

这篇文章分享了 Anthropic 在实践中总结的工具设计方法论——甚至包括如何用 Claude 来优化 Claude 的工具。

---

一、工具的本质：一种新型软件契约

传统软件中，我们在确定性系统之间建立契约：getWeather("NYC") 每次调用都以完全相同的方式获取天气。

但工具是确定性系统与非确定性 Agent 之间的契约。当用户问"我今天应该带伞吗？"，Agent 可能调用天气工具，也可能根据常识回答，甚至先询问位置。

这意味着我们需要从根本上重新思考方法：为 Agent 设计工具，而不是像为其他开发者写 API。

---

二、工具开发的三阶段迭代

阶段一：构建原型

快速实现工具，包装在 MCP 服务器或 DXT 中，在 Claude Code 或 Claude Desktop 中测试。亲自使用工具，发现粗糙的边缘。

阶段二：运行评估

生成大量评估任务（基于真实用例），通过 LLM API 批量测试。收集准确率、运行时间、token 消耗等指标。

好的评估任务示例：

• "安排下周与 Jane 开会讨论最新的 Acme Corp 项目。附上上次项目规划会议的笔记并预订会议室。"

差的评估任务示例：

• "安排下周与 jane@acme.corp 开会。"

区别在于：好的任务需要多次工具调用，考验 Agent 的综合能力。

阶段三：与 Agent 协作

让 Claude Code 分析评估记录并自动优化工具——包括工具描述、参数设计和错误处理。

---

三、五条工具设计原则

原则 1：为 Agent 选择正确的工具

更多的工具不等于更好的结果。不要简单包装现有 API——要考虑 Agent 的"可供性"。

好的做法： 实现 search_contacts 而非 list_contacts；实现 schedule_event 而非分别实现 list_users、list_events、create_event。

原则 2：命名空间你的工具

按服务（如 asana_search、jira_search）和资源（如 asana_projects_search）对工具进行命名空间划分。

原则 3：返回有意义的上下文

• 优先返回自然语言名称而非不透明的 UUID
• 提供 response_format 枚举参数，允许 Agent 选择"简洁"或"详细"模式
• 简洁模式可以节省约 2/3 的 token

原则 4：针对 token 效率优化

• 实施分页、过滤、截断
• 合理的默认参数值（Claude Code 默认将工具响应限制为 25,000 tokens）
• 错误响应要具体、可操作

原则 5：对工具描述进行提示工程

工具描述被加载到 Agent 的上下文中，直接引导 Agent 的行为。即使微小的改进也能产生巨大的效果。

---

四、关键洞察

"对 Agent 来说最符合'人体工程学'的工具，对人类来说也出奇地直观易懂。"

这意味着：如果你觉得一个工具的 API 很别扭，Agent 也会这么觉得。

---

读后感

这篇文章改变了我对"工具"的理解。工具不是简单的 API wrapper，而是 Agent 与世界交互的接口。就像 UI/UX 设计师为人类设计界面一样，我们需要为 Agent 设计"ACI"。

---

本文是 Anthropic AI Agent 系列 第 4 篇，共 15 篇。下一篇：Think Tool：让 Agent 学会"停下来想一想"

关注公众号 coft 获取系列更新。