为 Agent 编写高效工具——与 Agent 协作

发布日期： 2025年9月11日

来源： Anthropic 工程博客

文章讨论了如何为 LLM Agent 构建高质量工具，强调 Agent 的效能取决于其工具的质量。Model Context Protocol（MCP）可以为 Agent 提供数百个工具，文章介绍了最大化工具效能的技术。

核心主题

文章概述了如何：

• 构建和测试工具原型
• 使用 Agent 创建和运行全面的评估
• 使用 Claude 自动改进工具性能

什么是工具？

文章区分了确定性系统（每次输出相同）和非确定性 Agent——后者"即使在相同的起始条件下也能产生多样化的响应"。工具代表了"一种新型软件，反映了确定性系统与非确定性 Agent 之间的契约"。关键洞察是为 Agent 而非为传统开发者或系统设计工具。对 Agent 最"人体工学"的工具，对人类来说也"出奇地直观易懂"。

如何编写工具

构建原型

建议是快速搭建原型，并通过本地 MCP 服务器或 Desktop Extension（DXT）进行连接。自己测试工具可以帮助发现粗糙之处。llms.txt 文件中的 LLM 友好文档在使用 Claude Code 时会有所帮助。

运行评估

生成评估任务： Claude Code 可以根据实际用途创建提示-响应对。文章警告不要使用"过于简单或表面的'沙箱'环境，无法以足够的复杂性对工具进行压力测试"。强任务可能需要多次（甚至数十次）工具调用。

强任务示例包括多步骤场景，如安排带附件的会议、跨日志条目调查客户计费问题、或准备需要综合客户数据的留存方案。

弱任务是简单的单步骤查询，无法测试真正的复杂性。

每个提示应与可验证的响应配对。验证器的范围从精确字符串比较到 Claude 判断响应。文章建议不要使用"过于严格的验证器，因虚假差异而拒绝正确响应"。

运行评估： 建议使用直接 LLM API 调用和简单 Agent 循环进行程序化运行。文章建议指示 Agent 在工具调用和响应块之前输出推理和反馈块，因为这"可能通过触发链式思考（CoT）行为来提高 LLM 的有效智能"。

使用 Claude 时，可以启用交错思考以获得类似功能。需要收集的指标包括运行时间、工具调用次数、Token 消耗和工具错误。

分析结果： Agent 可以帮助发现问题，"但请记住，Agent 在反馈和响应中省略的内容往往比包含的内容更重要"。文章指出"LLM 并不总是表达其真实含义"。阅读原始记录和分析工具调用指标至关重要。

与 Agent 协作

评估记录可以拼接后交给 Claude Code 来自动分析和改进工具。文章中的大部分建议来自"使用 Claude Code 反复优化我们内部工具实现"的经验。留出的测试集防止了过拟合。

编写高效工具的原则

选择正确的工具

"更多的工具并不总是带来更好的结果。"一个常见的错误是工具仅仅包装现有 API 端点，而不管是否适合 Agent。Agent 具有与传统软件不同的"独特'可供性'"。

通讯录类比很好地说明了这一点：返回所有联系人会浪费有限的 Context，而 search_contacts 工具要好得多。建议是构建"少数针对特定高影响力工作流的深思熟虑的工具"。

工具可以合并功能。给出的示例：

• 用一个 schedule_event 工具替代单独的 list_users、list_events 和 create_event 工具
• 用一个 search_logs 工具替代 read_logs
• 用一个 get_customer_context 工具替代单独的客户/交易/笔记工具

"太多工具或重叠的工具也会分散 Agent 追求高效策略的注意力。"

工具命名空间

Agent 可能可以访问"数十个 MCP 服务器和数百个不同的工具"。命名空间有助于划定边界。按服务分组（如 asana_search、jira_search）和按资源分组（如 asana_projects_search）有助于 Agent 选择正确的工具。

前缀和后缀命名空间的选择对工具使用评估有"不可忽视的影响"，且因 LLM 而异。

返回有意义的上下文

工具实现应"只向 Agent 返回高信号信息"。它们应"优先考虑上下文相关性而非灵活性，避免使用低层级的技术标识符"。name、image_url 和 file_type 等字段比 uuid、256px_image_url、mime_type 更有用。

将"任意的字母数字 UUID 解析为更具语义意义和可解释性的语言"通过减少幻觉显著提高了精确率。

response_format 枚举参数可以让 Agent 控制详细程度。文章提供了一个包含 DETAILED 和 CONCISE 选项的枚举示例。在 Slack 示例中，简洁响应使用的 Token 约为详细响应的"三分之一"。详细响应包含下游工具调用所需的 ID。

响应结构格式（XML、JSON、Markdown）也会影响性能，没有放之四海而皆准的解决方案，因为"LLM 基于下一个 Token 预测进行训练，往往在与训练数据匹配的格式上表现更好"。

为 Token 效率优化工具响应

文章建议实现"分页、范围选择、过滤和/或截断，并设置合理的默认参数值"。对于 Claude Code，工具响应默认限制为 25,000 Token。

截断时，包含有用的指导来引导 Agent 采用 Token 高效的策略。错误响应应"清楚地传达具体且可操作的改进信息，而不是不透明的错误代码或堆栈跟踪"。

Prompt Engineering 工具描述

这被描述为"改进工具最有效的方法之一"。描述被加载到 Agent 的 Context 中，共同引导行为。建议是思考"你如何向新员工描述你的工具"，并将隐式上下文显式化。

输入参数应"命名明确：不要使用名为 user 的参数，试试名为 user_id 的参数"。

文章指出，"Claude Sonnet 3.5 在 SWE-bench Verified 评估上达到了最先进的性能"，这归功于对工具描述的精确优化——"大幅降低了错误率并提高了任务完成率"。

展望未来

文章总结道，我们需要将软件开发"从可预测的确定性模式重新定位到非确定性模式"。高效工具"有意图且清晰地定义、明智地使用 Agent 上下文、可以在多样化的工作流中组合使用"。随着 Agent 变得更加能干，"他们使用的工具也将随之演进"。

致谢

由 Ken Aizawa 撰写，研究、MCP、产品工程、市场、设计和应用 AI 部门的同事参与贡献。