摘要：智能体的浪潮正席卷而来，从自动化客服到代码生成，无数开发者投身其中，期望打造出无所不能的数字员工。

智能体的浪潮正席卷而来，从自动化客服到代码生成，无数开发者投身其中，期望打造出无所不能的数字员工。

但现实却是，我们精心打造的智能体时常犯错、效率低下，甚至产生“幻觉”。

那么，是模型不够聪明，还是我们从一开始就走错了路呢？或许，问题不在于智能体本身。

我们常常习惯性地将传统API直接“封装”后丢给智能体，却忽略了一个致命差异，软件是确定性的，而智能体是非确定性的。

而这种根本性的错配，正是导致智能体“乱搞”的根源。

或许有人会说，智能体的强大程度取决于其能力边界，最直接的增强方式就是为其接入尽可能多的API和功能。

将公司内部所有的API都封装成工具，让模型自行选择调用，这难道不是最大化其潜能的捷径吗？

从另一个角度看，这种“暴力美学”恰恰是传统软件开发思维的惯性体现。

9月12日，人工智能公司Anthropic发布的一篇官方教程，提出了“智能体可供性”（Agent Affordances）这一个关键概念。

例如，一个返回所有联系人的list_contacts工具，会让智能体在庞杂的无关信息中耗尽宝贵的上下文。

这就像让人类一页一页翻阅整本电话簿来找一个人，效率极低。而真正高效的做法，就是构建整合的、面向任务的工具。

正如Anthropic的案例所示，与其提供零散的list_users、list_events和create_event工具，不如设计一个整合的schedule_event工具。

这个工具能在内部完成查找各方空闲时间、预定会议室等一系列原子操作，实现一次调用解决一个复合任务。

而这不仅极大节省了token消耗，更重要的是，它让工具的行为模式与智能体，乃至人类解决问题的思维路径保持了一致。

因此，构建工具的第一原则就是：从追求数量转向追求质量，让每个工具都成为一个清晰、独立且高价值的能力单元。

也有观点认为，大语言模型如此强大，理应能从工具的名称和参数中自行推断其用途。

花费大量精力去雕琢工具的描述（description）和命名，似乎确实是一种不必要的“过度工程”。

毕竟，好的代码应是自解释的，好的工具也应如此，但这种看法却低估了“描述”在智能体工作流中的核心地位。

因为对于智能体而言，工具描述并不仅仅是给人看的“注释”。

模糊、重叠或有歧义的描述，会直接导致智能体在决策时产生混淆，最终调用错误的工具、使用错误的参数，或者干脆放弃使用工具。

而且，Anthropic也在文章中明确指出，在SWE-bench Verified评估中，正是对工具描述的精准改进，让Claude Sonnet 3.5模型的错误率大幅降低，任务完成率显著提升。

这个数据有力地证明了“说明书”的巨大价值。

当工具库庞大时，“命名空间”策略就显得更加重要。

比如，通过使用asana_search和jira_search这样的前缀来区分不同服务下的搜索功能，就能极大地降低智能体的“选择困难症”。

因此，第二原则则是：将工具描述和规范视为引导智能体行为的“代码”，投入精力精心设计，其回报将远超预期。

这样做能给予调用方最大的灵活性，让智能体自行解析和提取所需信息，不是吗？

除此之外，返回冗余信息会严重浪费本就宝贵的上下文空间。

教程中还以Slack线程为例，一个包含各种技术ID的“详细”响应消耗了206个token，而一个只返回核心线程内容的“简洁”响应仅消耗72个token，用约三分之一的成本传递了关键信息。

以上是详细工具响应的示例（206 个 token）

这也就意味着，第三原则是：将工具响应视为与智能体的一轮“对话”，必须让这轮对话清晰、简洁且富有建设性。

因为高效的工具，是智能体能力的放大器。

它应该像人类专家一样，提供整合的解决方案，使用清晰的语言沟通，并永远以任务目标为导向。

所以，别再乱搞了。

来源：小芳医学科普