机器心脏社论部

只有使用良好的工具，我们才能拥有良好的智能身体。

在代理时代，工具不再只是对传统API或功能接口的简单封装，而是确定代理是否可以有效完成任务的关键。

为了使代理商真正发挥其潜力，我们需要重新考虑开发工具开发的方式。传统的软件开发依赖于确定性逻辑，而代理是非确定性的，并且可能在相同的输入下产生不同的输出，这意味着为代理设计工具需要新的范式。

新的范式不仅在于如何开发工具，还关乎如何制造工具真正最大化其有效性。毕竟，AI代理的强度取决于我们为它们提供的工具，但是问题是：如何最大化这些工具？

拟人化的一篇文章指出了每个人的可行途径。

原始链接：https://www.anththropic.com/engineering/writing-tools-for-agents

这是博客的内容：

在本文中，Anthropic介绍了一些被证明在各种代理AI系统中最有效的性能改进技术。

构建和测试工具原型；如何创建和运行全面的评估；与代理（例如Claude代码）合作，以自动提高模型性能。

工具定义

在计算机中，确定性系统每次给出相同的输入时都会产生相同的输出。即使在相同的初始条件下，也可能会产生不同的响应，而不是确定性系统。

在传统软件开发中，我们在确定性系统之间建立合同。例如，关于天气Getweather（\’NYC\’）的函数呼叫，该函数将以完全相同的方式返回纽约的天气。

基于大型模型的工具是一种全新的软件形式，它反映了确定性系统和非确定性代理之间的合同。

例如：当用户问：“我今天想带上雨伞吗？”时，代理可以调用天气工具或基于常识直接回答，甚至首先提出澄清问题（例如确认特定位置）。有时，代理商也可能会遇到幻觉或根本无法弄清楚如何使用该工具。

这意味着，当我们为代理编写软件时，我们必须从根本上重新考虑该方法：我们不能再将工具和MCP服务器作为普通函数或API编写，但需要专门为代理设计。

那么您如何设计工具？

如何编写工具？

首先，快速构建工具原型并在本地进行测试。

接下来，进行了全面的评估，以衡量随后变化的影响。

与代理商合作，您可以不断重复评估和改进的周期，直到代理可以在现实生活中表现出强大的性能为止。

构建原型

在本教程中，我们以基于克劳德的代理结构为例。

如果您使用Claude代码编写工具，则最好向Claude提供相关文档，例如该工具所依赖的软件库，API或SDK（包括可以使用的MCP SDK）。

此外，通常可以在官方文档网站上以llms.txt文件的形式找到适合LLM阅读的文档，您可以自己下载它。

您还可以将工具封装在本地MCP服务器或桌面扩展程序（DXT）中，以在Claude Code或Claude Desktop应用程序中连接和测试它们。

值得一提的是，如果您将本地MCP服务器连接到Claude代码，请运行Claude MCP添加名称命令[args .]。

此外，要将本地MCP服务器或DXT连接到Claude Desktop应用程序，分别转到设置，开发人员或设置，分别是扩展。您还可以将工具直接传递到拟人API呼叫中进行编程测试。

完成这些操作后，您必须自己测试它们才能找到缺点。

运行评估

接下来，您需要通过评估来衡量工具的有效性。

评估可以在几个部分中进行，首先是生成评估任务。

完成早期原型后，Claude代码可以验证您的工具并生成数十种提示和响应。

这些技巧应源自实际使用方案，并基于真实的数据源和服务（例如内部知识库和微服务）。

这些高质量的评估任务通常需要多个工具调用，甚至需要数十次。那么什么是好任务评估？您可以参考以下示例：

安排下周与Jane举行的会议，讨论我们最新的Acme Corp项目。附上我们上次项目计划会议的会议记录，并预订会议室。客户ID 9182报告说，一次购买时被扣除了三次。查找所有相关的日志条目，并确定其他客户是否受到相同问题的影响。客户莎拉·陈（Sarah Chen）刚刚提交了取消订单的申请。准备保留计划。确定：（1）他们离开的原因； （2）哪种保留计划最吸引人； （3）在提出计划之前，我们应该注意的风险因素。还有一些较弱的任务：

下周与jane@acme.corp安排会议。在付款日志中搜索public_complete和customer_id=9182。查找具有45892客户ID的取消请求。每个评估提示都应与可验证的响应或结果配对。您设置的验证器可以像对基本事实和采样响应之间进行准确的字符串比较一样简单，或者与要求大型模型来判断响应一样高级。避免使用过于严格的验证器，该验证者由于错误差异而拒绝正确的响应，例如格式化，标点符号或有效的替代措辞。

对于每个提示响应对，您还可以选择在求解任务时指定代理调用的工具，以衡量代理在评估过程中是否成功掌握了每个工具的目的。但是，由于可以有多种有效解决任务的有效方法，因此请尝试避免过分指定或过度拟合策略。

接下来是运行评估。

也可以使用简单的智能循环（例如，与循环循环一起包装LLM API和工具调用）：每个评估任务对应于一个循环。每个评估代理都应分配一个任务提示和相关工具。

如果您使用Claude进行评估，则可以直接启用交织的思维。这使您可以探讨代理为什么打电话或不调用某些工具的原因。

单个工具调用和任务的总运行时间；工具调用总数；全令牌消耗；刀具错误情况。

接下来是结果分析。

一般而言，有时候，特工错过反馈和答案通常比他们提到的更重要。 LLM并不总是完全表达其真正的含义。

您需要观察代理会陷入困境或困惑的地方。我们需要根据反馈来定位工具的薄弱环节。

同时，我们需要查看原始对话记录（包括工具呼叫和工具响应），以捕获未在代理COT中明确出现的行为。请记住，评估代理并不一定会真正知道正确的答案或最佳策略。

此外，您需要分析工具呼叫指标：

太多的冗余调用可能表明需要重新设计分页或令牌限制参数；由无效参数引起的错误可能表明该工具需要更清晰的描述或更好的用法示例。用户还可以与代理商合作。

您甚至可以让代理直接帮助您分析结果并改进工具。

只需将评估代理的对话记录拼写下来，然后将其粘贴到Claude代码中。克劳德（Claude）擅长分析对话记录，并且可以一次重构大量工具。

如何编写有效的工具？什么是原则

选择正确的工具

这并不意味着工具越多，结果就越好。我们已经观察到了一种现象：工具只是封装了现有的软件功能或API接口，而尚不清楚称这些工具真正适合代理。

原因是代理商与传统软件的负担能力不同，也就是说，他们以与传统软件完全不同的方式感知和使用工具。

例如：LLM代理的上下文有限（即一次可以处理的信息量有限），而计算机存储器价格便宜且几乎无限。在通讯录中查找联系人的任务中，传统软件可以有效地存储和处理联系人，然后再检查一个，然后检查一个。但是，如果LLM代理使用返回所有联系人的工具，并且必须一一读取，则将浪费有限的上下文空间。 （想象一下，当您在通讯录中寻找联系时，您必须从头到尾阅读它，这实际上是一次暴力搜索。）

更好，更自然的方式（对于代理人和人类而言）是直接跳到相关页面（例如，按字母顺序定位）。

此外，该工具具有在底部同时处理多个离散操作（或API调用）的能力。

例如，工具可以：

返回结果时附加相关的元数据；或完成通常需要在一个呼叫中加入的多步任务。以下是集成功能的一些示例：

与其实现list_user，list_events和create_event工具，不如实现Schedule_event工具，该工具可以找到空闲时间并可以直接安排其他任务。而不是实现read_logs工具，而是实现仅返回相关日志线和必要上下文的search_logs工具。与其实施list_transactions和list_notes工具，不如实现get_customer_context工具，该工具可以一次汇总有关客户的所有最新信息。因此，您构建的每个工具都应具有明确的独立目标。工具应使代理商能够分解和解决像人类这样的任务，同时获得相同的基础资源，同时减少中间结果所消耗的上下文空间。

过多的具有重叠功能的工具或工具会分散代理商的注意力，并阻碍他们选择有效的策略。

因此，仔细而选择性的计划需要建立哪些工具（或不需要构建）通常会带来更大的回报。

为工具设置名称空间

AI代理可以访问数十个MCP服务器和数百种不同工具，包括其他开发人员的书面工具。

当工具在功能或用途中重叠时，代理可能会混淆使用哪种工具。

名称空间（即将相关工具与统一的前缀分组）可以在不同工具之间划定边界；一些MCP客户端将默认使用此方法。

例如，名称空间可以按服务（例如asana_search，jira_search）或资源（例如Asana_projects_search，asana_users_search）进行划分，该空间可以帮助代理在正确的时间选择正确的工具。

如果您不这样做，则代理商可以：

调用错误的工具；或用错误的参数调用正确的工具；或致电太少工具；甚至不正确地处理工具响应。从工具中返回有意义的上下文

同样，工具实现应注意仅向代理返回高信号信息。他们应优先考虑上下文相关性，而不是灵活性，并避免使用低级技术标识符（例如：uuid，256px_image_url，mime_type）。诸如名称，image_url和file_type之类的字段更有可能直接影响代理的下游操作和响应。

代理商处理自然语言名称，术语或标识符的能力也比处理晦涩的标识符要好得多。实践发现，仅将任意字母数字的UUID解析为语义上更有意义，更易于解释语言（即使是0个索引ID方案）可以显着提高Claude在检索任务中的准确性，从而减少幻觉。

在某些情况下，即使只是触发下游工具调用（例如，search_user（name=\’jane’）send_message（id=12345）），代理可能需要灵活地与自然语言和技术标识符输出相互作用。您可以通过在工具中公开一个简单的Response_Format参数来启用这两个功能，从而允许代理返回“简洁”或“详细”响应（如下图所示）。

您可以添加更多格式以提高灵活性，类似于GraphQl，也可以精确选择要接收的信息。这是一个响应式枚举的示例，该枚举控制了该工具的响应水平：

枚举ResponseFormat {

详细=“详细”，

简洁=\’confise\’

}

这是详细的工具响应（206个令牌）的示例：

这是简洁工具响应（72个令牌）的示例：

松懈的线程和线程答复由唯一的线程_TS标识，这是获得线程答复所需的。可以从“详细”工具响应中检索到需要这些ID的“详细”工具响应中的thread_ts和其他ID（Channel_id，user_id）。 “简单”工具响应仅返回线程内容，而不包括ID。在此示例中，大约1/3的令牌用作“简单”工具响应。

您的工具响应结构（例如XML，JSON或MARKDOWN）也可能会对评估性能产生影响：没有一个大小适中的解决方案。这是因为LLM是基于下一个令牌预测训练的，并且在使用匹配培训数据的格式时倾向于表现更好。最佳响应结构因任务和代理而异，建议根据您自己的评估选择最佳响应结构。

优化工具响应以提高令牌效率

优化上下文质量至关重要。但是，在优化工具响应中返回给代理的上下文数量同样重要。

人类建议，对于任何可以消耗大量上下文的工具响应，结合了分页，范围选择，过滤和/或截断，并设置合理的默认参数值。对于Claude代码，默认情况下，工具响应限制为25,000个令牌。将来，代理的有效上下文长度会随着时间的推移而增长，但是对上下文有效工具的需求将永远存在。

如果您选择截断响应，请确保向代理商提供实用的指导。您可以直接鼓励代理商采用更有效的代币策略，例如在知识检索任务中而不是单一的广泛搜索中的多个小规模的针对性搜索。同样，如果工具调用会引发错误（例如，在输入验证期间），则可以迅速设计错误响应以清楚地传达特定和可操作的改进，而不是使用晦涩的错误代码或回溯。

这是截断工具响应的示例：

这是无用错误响应的示例：

这是错误响应的有用示例：

快速构建工具描述

让我们谈谈改进工具的最有效方法之一：快速构建工具描述和规格。由于这些内容被加载到代理的上下文中，因此它们可以共同指导代理人实施有效的工具呼叫行为。

在编写工具描述和规格时，请考虑如何向团队中的新成员描述您的工具。考虑可以隐式介绍的上下文——专用查询格式，专业术语的定义以及基础资源之间的关系——。通过清楚地描述（并使用严格的数据模型执行）预期输入和输出来避免模棱两可。特别是，输入参数的命名应清晰清晰：不要使用名为用户的参数，而是尝试使用名为user_id的参数。

通过评估，您可以更自信地衡量快速构建的影响。即使对工具描述的较小改进也会导致重大改进。经过对工具描述的精确改进后，Claude Sonnet 3.5在经过SWE-Bench验证的评估中取得了最佳性能，大大降低了错误率并提高了任务完成率。

展望未来