本文是对 Anthropic《如何为 Agent 构建工具》一文的重点介绍。文章首先将工具定义为确定性系统与非确定性 Agent 之间的契约，强调工具设计应以 Agent 为中心，以拓展其解决任务的有效范围。接着，文章描述了一个迭代式工具开发流程：从快速构建原型和本地测试开始，通过基于真实用例的全面评估来衡量工具效果，并利用 Agent 分析评估结果以进行持续改进。文章还提出了编写高效工具的五项核心原则：选择高影响力工具而非越多越好；使用命名空间避免混淆；返回有意义、高信号的上下文信息；优化工具响应的 Token 效率，包括分页、过滤和提供有帮助的错误提示；以及对工具描述进行细致的提示工程，明确化输入输出。这些原则共同指导开发者将传统软件开发思维转向适应非确定性 Agent 的模式，确保工具与 Agent 能力同步发展。
Anthropic 刚刚发布了一篇很值得阅读的文章《如何为 Agent 构建工具》，包括：如何编写高质量的工具和评估，以及如何利用 Claude 来为自己优化工具，从而提升性能。
https://www.anthropic.com/engineering/writing-tools-for-agents
传统软件是确定性系统，而像 Agent 这样的系统是非确定性的。工具是一种新型软件，它反映了确定性系统与非确定性 Agent 之间的契约。我们编写工具时，需要为 Agent 而不是为其他开发者或系统来设计。我们的目标是通过工具，让 Agent 能够采用多种成功策略，扩大其解决各类任务的有效范围。
本文描述了一个与 Agent 协作编写和改进工具的迭代流程：首先构建一个快速原型并进行本地测试，然后通过全面的评估来衡量后续的改动，并与 Agent 一起重复评估和改进的过程。
快速构建工具原型，亲身体验。使用 Claude Code 编写工具时，提供相关软件库、API 的文档会有帮助。将工具包装在本地 MCP 服务器或 DXT 中，以便在 Claude Code 或 Claude 桌面应用中连接和测试。
通过运行评估来衡量 Claude 使用工具的效果。评估任务应基于真实世界用例，并具有足够的复杂性。强大的评估任务可能需要多次（甚至数十次）工具调用。在评估中，我们建议收集准确率、运行时间、工具调用次数、Token 消耗和错误等指标。
我们内部 Slack 工具在留出测试集上的性能表现 
我们内部 Asana 工具在留出测试集上的性能表现
Agent 是你发现问题和提供反馈的得力伙伴。你可以让 Agent 分析评估结果并为你改进工具。将评估 Agent 的对话记录粘贴到 Claude Code 中，Claude 擅长分析这些记录并一次性重构大量工具。
更多的工具并不总是带来更好的结果。Agent 的“上下文”有限，应避免返回大量无关信息。应构建少量、有思想、针对特定高影响力工作流的工具。例如，实现一个 search_contacts 而不是 list_contacts 工具。工具可以整合功能，将多步操作合并为一次调用。
当工具功能重叠或目的模糊时，Agent 可能会混淆。使用命名空间（例如 asana_search, jira_search）可以帮助在大量工具之间划定界限，帮助 Agent 在正确的时间选择正确的工具。
工具应只返回高信号信息，优先考虑上下文相关性而非灵活性。避免使用 UUID 等底层技术标识符，多使用自然语言名称。可以通过 response_format 枚举参数让 Agent 控制返回“简洁”还是“详细”的响应。
优化上下文的数量和质量同样重要。为可能消耗大量上下文的工具响应实现分页、过滤和截断等机制。如果截断响应或出现错误，应提供清晰、可操作的改进建议来引导 Agent。
这是最有效的方法之一。编写工具描述时，要像向新同事解释一样，将隐含的背景信息明确化。避免模糊性，对预期输入和输出进行清晰描述和严格定义。例如，使用 user_id 而不是 user 作为参数名。对工具描述的微小改进都能带来显著的性能提升。
为 Agent 构建有效的工具，需要我们将软件开发实践从确定性模式转向非确定性模式。有效的工具是有意图且清晰定义的，能明智地使用 Agent 上下文，并能直观地帮助 Agent 解决真实世界的任务。通过系统性、评估驱动的方法，我们可以确保随着 Agent 能力的增强，它们使用的工具也能同步发展。
