摘要：最近帮朋友调试他做的LLM智能体时，发现一个挺普遍的问题，他给智能体装了十多个工具，可智能体要么不用，要么用错，好好的功能愣是发挥不出来。

最近帮朋友调试他做的LLM智能体时，发现一个挺普遍的问题，他给智能体装了十多个工具，可智能体要么不用，要么用错，好好的功能愣是发挥不出来。

后来翻到Anthropic的官方教程才明白，给LLM智能体写工具，跟咱们平时写API完全不是一回事。

今天就借着这份教程，跟大家聊聊怎么给智能体做工具，不是讲空泛的理论，就聚焦实际开发里最关键的那些点，先得搞清楚，智能体用的工具到底是个啥。

咱们平时写的软件，比如查天气的函数getWeather("NYC")，不管调用多少次，返回的结果和格式都一样，这叫确定性系统之间的契约。

但智能体不一样，它是个非确定性系统，就算你给同一个问题，它可能会调用工具，可能自己瞎回答，甚至还会反问你一句。

就像有人问“今天要带伞吗？”，有的智能体会查天气工具，有的直接说“可能会下雨”，还有的会问“你在哪座城市啊？”。

这种不确定性，让智能体的工具成了个新东西，它得是确定性系统和非确定性智能体之间的特殊约定，不能再按老思路开发了。

那具体怎么开发呢？Anthropic给的流程挺实在，先搭原型再评估，反复优化。

搭原型的时候，要是用Claude的话，得把工具依赖的软件库、SDK这些文档给它，官方网站上有个llms.txt文件，专门给LLM读的，直接下载用就行。

本来想把工具直接挂到线上测试，后来发现不对，先封装到本地MCP服务器或者桌面扩展程序里更稳妥。

连接ClaudeCode有专门的命令，ClaudeDesktop里也能通过设置找到开发者或者扩展程序入口。

这些都弄好后，得自己先测几遍，看看有没有明显的漏洞，比如参数传错了会不会报错，返回的结果能不能看懂。

原型搭好就到评估环节了，这步最容易走形式，评估任务得从真实场景里找，不能搞那些假模假样的测试题。

比如“帮着安排下周和Jane开AcmeCorp项目的会，带上上次的会议记录，再订个会议室”，这种需要多次调用工具的任务才管用。

每个任务还得有能验证的结果，不用太复杂，要么比对着标准答案看字符串对不对，要么让另一个LLM帮忙判断。

运行评估的时候，建议直接调LLM的API写代码跑，用个while循环把API和工具调用包起来，一个任务跑一个循环。

要是用Claude，记得开那个交错思维功能，能看到它为啥选这个工具、不选那个工具，挺有用的。

评估完了分析结果也有讲究，不能只看准确率，智能体没说出来的东西往往更重要，比如它卡在某个步骤不动了，或者反复调用同一个工具，这些都得留意。

还有那些调用数据，比如冗余调用多了，可能是分页设置有问题，参数错误多了，可能是工具说明没写清楚。

我之前没注意这些，光看准确率高就觉得工具没问题，结果放到实际场景里照样不好使。

后来照着教程把评估记录传给ClaudeCode，让它帮忙分析，才发现不少之前没看到的问题，工具开发流程理顺了，还得知道怎么把工具做高效。

智能体的上下文是有限的，你给它一堆工具，它反而不知道该用哪个。

就像查联系人，传统软件能一个个翻，但智能体要是拿到所有联系人列表，光读这些内容就把上下文占满了。

如此看来，不如做个能直接搜索联系人的工具，省得浪费资源。

而且工具最好能整合多个功能，比如别分开做查用户、查日程、建会议的工具，直接做个能安排会议的工具，一步到位，还能省不少调用次数。

命名和响应设计也得花心思，智能体可能要接好多个MCP服务器，工具一多就容易混。

给工具加个命名空间，比如按服务分asana_search、jira_search，或者按资源分asana_projects_search，能帮它分清。

响应内容更是关键，别把那些uuid、技术链接一股脑全返回，智能体看不懂还占token。

尽量给语义化的信息，比如把长串的ID改成“客户1号”“订单2号”，它处理起来就顺多了。

还可以加个参数让智能体选要详细结果还是简洁结果，比如查Slack消息，要ID的时候就给详细的，只是看内容就给简洁的，能省不少token。

工具的说明文档也不能马虎，本来想随便写两句用途就行，后来发现不对，得像给新同事讲工具似的，把那些没说出来的规矩都写清楚。

比如参数为啥叫user_id不叫user，查询格式有啥要求，这些都得明确。

Anthropic说就改改说明文档，ClaudeSonnet3.5在SWE-benchVerified评估里表现就好了不少，错误少了，完成任务的比例也高了，很显然，好的说明能帮智能体少走很多弯路。

再聊聊实际用的时候该注意啥，还有以后的方向。

我之前帮一个电商做智能客服的工具，就按教程里的原则来的。

没做一堆小工具，而是整合了查订单、调日志、做留任方案的功能，叫ecommerce_order_handle_issue。

参数里明确要customer_id、order_id，还能选要详细结果还是简洁结果。

评估的时候发现智能体总忘要客户所在地区，就在说明里补上，后来用着就顺多了。

现在不少行业都这么做，金融的投研工具能选返回摘要还是详细数据，企业协作工具按部门分命名空间，都挺管用的。

至于未来，智能体和工具的互动方式肯定会变，MCP协议会更新，LLM的能力也会更强。

但不管怎么变，围绕评估来迭代工具的思路应该不会错。

现在给智能体做工具还在摸索阶段，没有统一的标准，但只要抓住智能体的特性，多测试多优化，总能做出好用的工具。

毕竟智能体再厉害，没有趁手的工具也发挥不出实力，这一点，用过智能体的人怕是最有体会。

来源：法之生活一点号