模型上下文协议（MCP）可赋予LLM智能体数百种工具来解决现实世界任务。但如何让这些工具发挥最大效用？

在本文中，我们将介绍在各类智能体AI系统¹中提升性能的最有效技术。

我们首先介绍如何：

最后总结我们在过程中发现的高质量工具编写关键原则：

在计算领域，确定性系统在给定相同输入时每次都会产生相同输出，而非确定性系统——如智能体——即使在相同初始条件下也可能产生不同响应。

传统上编写软件时，我们是在确定性系统之间建立契约。例如，getWeather("NYC") 这样的函数调用每次都会以完全相同的方式获取纽约市的天气。

工具是一种新型软件，反映了确定性系统与非确定性智能体之间的契约。当用户问"我今天该带伞吗？"时，智能体可能会调用天气工具、根据常识回答，甚至先询问地点。有时，智能体可能会产生幻觉，甚至无法理解如何使用工具。

这意味着在为智能体编写软件时需要从根本上重新思考：我们不应像为其他开发者或系统编写函数和API那样编写工具和MCP服务器，而需要为智能体设计它们。

我们的目标是扩大智能体通过使用工具追求各种成功策略来有效解决广泛任务的范围。幸运的是，根据我们的经验，对智能体最"符合人体工学"的工具最终对人类来说也出奇地直观易懂。

在本节中，我们将介绍如何与智能体协作编写和改进你提供给它们的工具。首先快速搭建工具原型并在本地测试。然后运行全面评估来衡量后续变更的效果。与智能体协同工作，你可以重复评估和改进工具的过程，直到智能体在现实任务中表现出色。

如果不亲自动手，很难预测哪些工具对智能体来说符合人体工学，哪些不符合。首先快速搭建工具原型。如果你使用Claude Code编写工具（可能一次性完成），为Claude提供工具所依赖的任何软件库、API或SDK（可能包括MCP SDK）的文档会很有帮助。LLM友好的文档通常可以在官方文档网站的llms.txt文件中找到（这里是我们API的）。

将工具包装在本地MCP服务器或桌面扩展（DXT）中，可以让你在Claude Code或Claude Desktop应用中连接和测试工具。

要将本地MCP服务器连接到Claude Code，运行 claude mcp add <name> <command> [args...]。

要将本地MCP服务器或DXT连接到Claude Desktop应用，分别导航至 Settings > Developer 或 Settings > Extensions。

工具也可以直接传入Anthropic API调用进行程序化测试。

亲自测试工具以发现任何粗糙边缘。收集用户反馈，建立对工具预期支持的用例和提示的直觉。

接下来，你需要通过运行评估来衡量Claude使用工具的效果。首先生成大量基于现实世界使用的评估任务。我们建议与智能体协作分析结果并确定如何改进工具。请参阅我们的工具评估手册了解端到端流程。

生成评估任务

使用早期原型，Claude Code可以快速探索你的工具并创建数十个提示和响应对。提示应受现实世界用例启发，并基于真实数据源和服务（例如内部知识库和微服务）。我们建议避免过于简单或表面的"沙盒"环境，这些环境无法以足够复杂性对工具进行压力测试。强大的评估任务可能需要多次工具调用——可能多达数十次。

以下是强任务的示例：

以下是一些弱任务：

每个评估提示应与可验证的响应或结果配对。你的验证器可以简单到对真实答案和采样响应进行精确字符串比较，也可以高级到让Claude评判响应。避免过于严格的验证器，这些验证器会因格式、标点或有效替代措辞等虚假差异而拒绝正确响应。

对于每个提示-响应对，你还可以选择指定期望智能体在解决任务时调用的工具，以衡量智能体在评估过程中是否成功理解每个工具的用途。然而，由于可能存在多种正确解决任务的路径，尽量避免过度指定或过拟合策略。

运行评估

我们建议通过直接LLM API调用以编程方式运行评估。使用简单的智能体循环（包装交替LLM API和工具调用的while循环）：每个评估任务一个循环。每个评估智能体应获得单个任务提示和你的工具。

在评估智能体的系统提示中，我们建议指示智能体不仅输出结构化响应块（用于验证），还要输出推理和反馈块。指示智能体在工具调用和响应块之前输出这些内容，可以通过触发思维链（CoT）行为来提高LLM的有效智能。

如果你使用Claude运行评估，可以启用交错思考以获得类似的"开箱即用"功能。这将帮助你探究智能体为何调用或不调用某些工具，并突出工具描述和规范中需要改进的具体领域。

除了顶层准确率，我们建议收集其他指标，如单个工具调用和任务的总运行时间、工具调用总数、总token消耗以及工具错误。跟踪工具调用有助于揭示智能体追求的常见工作流，并为工具整合提供机会。

分析结果

智能体是你发现问题和提供反馈的有益伙伴，涵盖从矛盾的工具描述到低效的工具实现和令人困惑的工具模式等各个方面。但请记住，智能体在反馈和响应中省略的内容往往比包含的内容更重要。LLM并不总是言尽其意。

观察智能体在哪里卡住或困惑。阅读评估智能体的推理和反馈（或CoT）以识别粗糙边缘。审查原始记录（包括工具调用和工具响应）以捕捉智能体CoT中未明确描述的任何行为。读懂言外之意；记住你的评估智能体不一定知道正确答案和策略。

分析你的工具调用指标。大量冗余工具调用可能表明需要调整分页或token限制参数；大量因无效参数导致的工具错误可能表明工具需要更清晰的描述或更好的示例。当我们推出Claude的网页搜索工具时，我们发现Claude不必要地在工具的查询参数后附加了2025，这偏斜了搜索结果并降低了性能（我们通过改进工具描述将Claude引导到了正确方向）。

你甚至可以让智能体为你分析结果并改进工具。只需将评估智能体的记录拼接起来并粘贴到Claude Code中。Claude是分析记录和一次性重构大量工具的专家——例如，确保在进行新更改时工具实现和描述保持自洽。

事实上，本文中的大部分建议都来自使用Claude Code反复优化我们的内部工具实现。我们的评估建立在内部工作空间之上，反映了内部工作流的复杂性，包括真实项目、文档和消息。

我们依靠保留测试集来确保不过拟合"训练"评估。这些测试集表明，即使超越"专家"工具实现（无论是研究人员手动编写还是Claude自身生成），我们仍能提取额外的性能改进。

在下一节中，我们将分享从这个过程中学到的一些经验。

在本节中，我们将经验提炼为编写有效工具的几条指导原则。

更多工具并不总能带来更好的结果。 我们观察到的一个常见错误是工具仅仅包装现有软件功能或API端点——无论这些工具是否适合智能体。这是因为智能体对传统软件具有不同的"可供性"——即它们以不同方式感知使用这些工具可以采取的潜在行动。

LLM智能体的"上下文"有限（即它们一次能处理的信息量有限），而计算机内存廉价且丰富。考虑在通讯录中搜索联系人的任务。传统软件程序可以高效地逐个存储和处理联系人列表，在继续之前检查每个联系人。

然而，如果LLM智能体使用返回所有联系人的工具，然后必须逐个token地阅读每个联系人，它就在不相关信息上浪费了有限的上下文空间（想象一下通过逐页从头到尾阅读通讯录来搜索联系人——即通过暴力搜索）。更好且更自然的方法（对智能体和人类都是如此）是首先跳到相关页面（也许按字母顺序找到它）。

我们建议构建少量针对特定高影响力工作流的深思熟虑的工具，这些工具与你的评估任务匹配，并从此扩展。在通讯录案例中，你可能会选择实现 search_contacts 或 message_contact 工具，而不是 list_contacts 工具。

工具可以整合功能，在底层处理可能多个离散操作（或API调用）。例如，工具可以用相关元数据丰富工具响应，或在单个工具调用中处理频繁链式的多步骤任务。

以下是一些示例：

确保你构建的每个工具都有清晰、独特的用途。工具应使智能体能够像人类在访问相同底层资源时那样细分和解决任务，同时减少原本会被中间输出消耗的上下文。

太多工具或重叠的工具也会分散智能体追求高效策略的注意力。仔细、有选择地规划你构建（或不构建）的工具可以带来巨大回报。

你的AI智能体可能访问数十个MCP服务器和数百种不同工具——包括其他开发者构建的工具。当工具功能重叠或用途模糊时，智能体会对使用哪个感到困惑。

命名空间（将相关工具分组在公共前缀下）有助于划定大量工具之间的边界；MCP客户端有时默认这样做。例如，按服务（如 asana_search、jira_search）和按资源（如 asana_projects_search、asana_users_search）对工具进行命名空间划分，可以帮助智能体在正确的时间选择正确的工具。

我们发现选择基于前缀还是基于后缀的命名空间对我们的工具使用评估有显著影响。效果因LLM而异，我们鼓励你根据自己的评估选择命名方案。

智能体可能调用错误的工具、用错误参数调用正确的工具、调用过少的工具或错误处理工具响应。通过有选择地实现名称反映任务自然细分的工具，你同时减少了加载到智能体上下文中的工具和工具描述数量，并将智能体计算从上下文卸载回工具调用本身。这降低了智能体整体犯错的风险。

同样，工具实现应注意只向智能体返回高信号信息。它们应优先考虑上下文相关性而非灵活性，并避免低级技术标识符（例如：uuid、256px_image_url、mime_type）。像 name、image_url 和 file_type 这样的字段更可能直接告知智能体的下游操作和响应。

智能体处理自然语言名称、术语或标识符的能力通常比处理晦涩标识符要成功得多。我们发现，仅仅将任意字母数字UUID解析为更具语义意义和可解释性的语言（甚至0索引ID方案）就能显著提高Claude在检索任务中的精确度，减少幻觉。

在某些情况下，智能体可能需要灵活性来同时处理自然语言和技术标识符输出，如果只是为了触发下游工具调用（例如，search_user(name='jane') → send_message(id=12345)）。你可以通过在工具中暴露一个简单的 response_format 枚举参数来启用两者，允许智能体控制工具返回"简洁"还是"详细"响应（下图）。

你可以添加更多格式以获得更大灵活性，类似于GraphQL，你可以精确选择想要接收的信息片段。以下是一个控制工具响应详细程度的 ResponseFormat 枚举示例：

以下是详细工具响应示例（206个token）：

以下是简洁工具响应示例（72个token）：

甚至你的工具响应结构——例如XML、JSON或Markdown——也会影响评估性能：没有一刀切的解决方案。这是因为LLM在下一个token预测上训练，往往在与训练数据匹配的格式上表现更好。最佳响应结构因任务和智能体而异。我们鼓励你根据自己的评估选择最佳响应结构。

优化上下文质量很重要。但优化工具响应中返回给智能体的上下文数量同样重要。

我们建议对任何可能消耗大量上下文的工具响应，实现分页、范围选择、过滤和/或截断的组合，并设置合理的默认参数值。对于Claude Code，我们默认将工具响应限制为25,000个token。我们预计智能体的有效上下文长度会随时间增长，但对上下文高效工具的需求将保持不变。

如果选择截断响应，请务必用有用的指令引导智能体。你可以直接鼓励智能体追求更token高效的策略，例如进行许多小范围、有针对性的搜索，而不是一次广泛搜索（用于知识检索任务）。同样，如果工具调用引发错误（例如在输入验证期间），你可以通过提示工程使错误响应清晰传达具体且可操作的改进建议，而不是不透明的错误代码或回溯。

以下是截断工具响应示例：

以下是无帮助的错误响应示例：

以下是有帮助的错误响应示例：

现在我们来讨论改进工具最有效的方法之一：对工具描述和规范进行提示工程。 由于这些内容被加载到智能体的上下文中，它们可以共同引导智能体采取有效的工具调用行为。

编写工具描述和规范时，思考你会如何向团队新成员描述你的工具。考虑你可能隐含带入的上下文——专门的查询格式、小众术语的定义、底层资源之间的关系——并将其明确化。通过清晰描述（并用严格数据模型强制执行）预期的输入和输出来避免歧义。特别是，输入参数应明确命名：不要使用名为 user 的参数，尝试使用名为 user_id 的参数。

通过评估，你可以更有信心地衡量提示工程的影响。即使对工具描述进行微小改进也能带来显著提升。在对工具描述进行精确改进后，Claude Sonnet 3.5在SWE-bench Verified评估中达到了最先进性能，大幅降低了错误率并提高了任务完成度。

你可以在我们的开发者指南中找到其他工具定义最佳实践。如果你正在为Claude构建工具，我们还建议阅读关于工具如何动态加载到Claude系统提示的内容。最后，如果你正在为MCP服务器编写工具，工具注释有助于披露哪些工具需要开放世界访问或进行破坏性更改。

要为智能体构建有效工具，我们需要将软件开发实践从可预测的确定性模式重新定位到非确定性模式。

通过本文描述的迭代、评估驱动过程，我们发现了成功工具的一致模式：有效的工具是经过深思熟虑且明确定义的，明智地使用智能体上下文，可以在多样化工作流中组合使用，并使智能体能够直观地解决现实世界任务。

未来，我们预计智能体与世界交互的具体机制将不断演变——从MCP协议的更新到底层LLM本身的升级。通过系统化、评估驱动的方法来改进智能体工具，我们可以确保随着智能体能力的增强，它们使用的工具也将随之进化。

由Ken Aizawa撰写，感谢来自研究部门（Barry Zhang、Zachary Witten、Daniel Jiang、Sami Al-Sheikh、Matt Bell、Maggie Vo）、MCP部门（Theodora Chu、John Welsh、David Soria Parra、Adam Jones）、产品工程部门（Santiago Seira）、市场部门（Molly Vorwerck）、设计部门（Drew Roper）和应用AI部门（Christian Ryan、Alexander Bricken）同事的宝贵贡献。

¹超出训练底层LLM本身的范围。