与 Agent 一起，为 Agent 编写有效工具
官方原文: https://www.anthropic.com/engineering/writing-tools-for-agents
发布日期： 2025 年 9 月 11 日
来源： Anthropic Engineering Blog
Agent 的效果上限，很大程度上取决于工具质量。本文讨论如何为 LLM Agent 构建、评估并持续改进工具。MCP 可以让 Agent 接入数百项工具，但数量本身不等于能力。
核心内容
本文覆盖三件事：构建并测试工具原型；用 Agent 建立和运行完整 eval；借助 Claude 自动分析并改进工具性能。
工具是什么
确定性系统在相同输入下给出相同输出，非确定性 Agent 即使起始条件相同，也可能产生不同回答。工具是这两类系统之间的契约，因此应当为 Agent 设计，而非仅为传统开发者或传统软件封装 API。对 Agent 使用顺手的工具，通常也会让人感到直观。
如何编写工具
先做原型
先快速搭起原型，再通过本地 MCP server 或 Desktop Extension（DXT）连接并亲自试用，能最快发现不顺畅之处。使用 Claude Code 时，也可以在 llms.txt 中提供面向 LLM 的说明。
运行评测
生成评测任务。 Claude Code 可以根据真实使用方式生成 prompt-response 对。不要只建过于简单、表面的 sandbox；它们没有足够复杂度来压测工具。高质量任务可能需要多次，甚至数十次工具调用，例如安排附带附件的会议、跨日志排查客户账单问题、或综合客户数据制定留存方案。单步骤查找类任务则很难检验真实能力。
每个 prompt 都应配有可验证的结果。verifier 可以是精确字符串比对，也可以由 Claude 评判；避免 verifier 过于严格，因无关格式差异误判正确答案。
运行评测。 推荐以直接 LLM API 调用配合简单 agentic loop 进行程序化运行。可要求 Agent 在工具调用与回答前输出 reasoning 和 feedback block，这可能触发 chain-of-thought（CoT）行为并提高实际表现。Claude 可启用 interleaved thinking 获得类似能力。应记录运行时长、工具调用次数、token 消耗和工具错误。
分析结果。 Agent 能帮助发现问题，但它没写出来的内容，有时比它写出来的更重要；LLM 并不总能准确表达自身状态。因此仍要阅读原始 transcript，并分析工具调用指标。
与 Agent 协作优化
可以把 eval transcript 拼接后交给 Claude Code，让它分析并改进工具。本文的大量建议都来自用 Claude Code 反复优化内部工具实现的经验。务必保留 held-out test set，避免工具只对已见案例过拟合。
编写有效工具的原则
选择正确的工具粒度
工具越多并不一定越好。常见错误是机械地包装每个 API endpoint，而不考虑是否适合 Agent。Agent 与传统软件的使用方式不同，应优先构建少量、围绕高价值工作流的工具。
例如，通讯录不应返回全部联系人，而应提供 search_contacts。也可把低层操作合并为更符合任务的工具：
- 用
schedule_event取代分别暴露list_users、list_events、create_event。 - 用
search_logs取代read_logs。 - 用
get_customer_context聚合客户、交易和备注信息。
过多或彼此重叠的工具会让 Agent 分心，也更难形成高效策略。
使用命名空间
Agent 可能同时访问数十个 MCP server、数百个工具。按服务分组，如 asana_search、jira_search，或进一步按资源命名，如 asana_projects_search，有助于它选择正确工具。采用前缀还是后缀式命名会对 tool-use eval 产生不可忽略的影响，而且结果可能因 LLM 而异。
返回有意义的上下文
工具应只向 Agent 返回高信号信息，优先保证上下文相关性，避免暴露低层技术标识符。例如 name、image_url、file_type 通常比 uuid、256px_image_url、mime_type 更有用。把无意义的字母数字 UUID 解析成可理解的实体描述，能减少 hallucination 并提高准确性。
可通过 response_format 枚举让 Agent 选择 DETAILED 或 CONCISE。文中的 Slack 示例显示，简洁响应的 token 约为详细响应的三分之一；详细模式则保留下游工具调用所需 ID。XML、JSON、Markdown 等结构也会影响表现，但没有通用最优格式，LLM 往往更擅长训练数据中常见的格式。
为 Token 效率设计响应
应实现合理默认值的 pagination、范围选择、过滤和截断。Claude Code 默认将工具响应限制为 25,000 tokens。发生截断时，要告诉 Agent 下一步如何以更省 token 的方式继续；错误响应也应清晰说明可操作的修复方法，不要只返回晦涩 error code 或 traceback。
把工具描述当作 Prompt Engineering
工具描述是改进工具的高收益手段之一，因为它们会被加载进 Agent 的 Context 并持续引导行为。可以设想向一名新员工介绍工具时会说什么，再把隐含前提明确写出。参数名也应无歧义，例如用 user_id 而不是 user。
文章指出，对工具描述做精确调整曾显著降低错误率并提高任务完成率，是 Claude Sonnet 3.5 在 SWE-bench Verified 上取得先进表现的重要因素之一。
展望
Agent 时代的软件开发需要从完全可预测的确定性模式，转向能容纳非确定性行为的设计。有效工具应有明确意图、节制使用 Agent Context，并能在多种工作流中组合。随着 Agent 能力提升，它们使用的工具也会继续演进。
致谢
本文由 Ken Aizawa 撰写，研究、MCP、产品工程、市场、设计与 Applied AI 团队的同事参与贡献。