11 篇博文 含有标签「tool-calling」

六周前，你将 get_user_email 重命名为 lookup_contact。新名称已发布，旧的处理程序已移除，变更日志记录了这一点，你的评估集也通过了。然而上周二，一位客户支持工程师联系了你：智能体在上周的大约 3% 的工具调用中返回了错误——tool_not_found: get_user_email。那个已被重命名的名称。那个在实时系统中已经不再对外公开的名称。

先验知识（Prior）具有粘性。你的智能体正在与之对话的模型是在一个语料库上训练的，在这个语料库中，get_user_email 是询问“这个人的电子邮件是什么”的绝大多数规范方式。即使你在推理时传递的 tools 数组中仅列出了 lookup_contact，模型偶尔——在特定的上下文条件下，特别是长追踪（long traces）或错误恢复状态下——仍会退回到它记忆中的名称。直接切换并不能消除长尾效应；它只是将软故障变成了硬故障。

在某个周二，一个全新的可选参数被添加到了工具描述中。这个改动很小——在 diff 中只有六行代码，没有破坏性的签名变更，没有更新调用者，也没有触及任何评估用例。PR 描述写着“为现有搜索工具添加了可选的 language 过滤器支持”。两名评审员批准了，随后上线。

一周后，成本仪表板显示，搜索工具的调用频率比之前的基准线增加了 18%。受影响的 agent 延迟也以大致相同的比例攀升。没人能指出哪一个评估用例失败了。新参数在使用时表现正常；在不使用时，也无关紧要。然而，planner 显然改变了它对何时使用该工具的看法——而评估套件（用于衡量工具的“正确性”）对于工具“频率”的变化却无话可说。

智能体自信地告诉用户：“我已经发送了确认邮件，并将退款退回到你的账户。”追踪记录很干净：两次工具调用，均返回 {"success": true}，模型生成了精练的摘要，对话在 3.2 秒内结束。一周后，客户发起投诉，因为邮件从未送达，退款也从未入账。审计日志中全是绿色的勾选标记。没有任何环节失败——除了实际的工作本身。

这就是在大多数智能体技术栈中尚未被命名的故障模式：撒谎的工具。这里的“撒谎”并非恶意——它们返回了其契约规定的响应。这种谎言是结构性的。HTTP 层返回 “200 OK” 是因为请求被接受了，而不是因为操作完成了。邮件服务商返回 success: true 是因为消息进入了发送队列，而不是因为它已经发出了。数据库写入返回且无报错，是因为它写入了一个从未同步的副本。被训练成“乐于助人”且在“绿色代表完成”的示例上训练过的模型，将这些信号编织成一份自信的摘要，然后继续下一步。

我认识的一个团队在某个周二向他们的支持智能体目录发布了一个新的 lookup_customer_v2 工具。这个工具的作用范围很窄，经过了充分的隔离测试，并通过了评审。到了周四，一个毫不相关的流程——退款处理——在之前一直运行良好的案例中出现了约 4% 的失败。退款工具没有变。退款提示词没有变。模型也没有变。改变的是规划器（planner）现在在处理退款资格查询时选择了 lookup_customer_v2，而以前这些查询都会清晰地路由到 get_account_status。原因是新工具的描述中恰好包含 "eligibility"（资格）这个词，并在模型内部使用的某种相似性启发式算法下获得了更高的排名。

这就是依赖炸弹。团队通常将工具注册表视为增量式的——“我们只是增加了一个东西，能出什么问题”——但规划器并不将你的注册表视为独立能力的列表。它看到的是各种选择上的概率分布，而每一个条目都会重新分配权重。增加一个工具可能会悄悄地削弱其他地方的行为，而你的评估套件（eval suite）可能会漏掉这一点，因为没有人写过回归测试来规定“在这种情况下，智能体应该仍然选择 旧 工具”。

一个在生产环境中运行的智能体曾经收到指令"清理测试数据"，然后对生产数据库执行了 DROP TABLE 命令。工具调用成功执行了。审计日志显示了一个结构完美的 JSON 载荷。智能体做的恰恰就是被要求做的——只是不是任何人所期望的那样。这不是一个提示注入的故事，而是一个架构选择的故事：团队赋予了智能体生成和执行任意代码的能力，却低估了这在运行时真正意味着什么。

将函数调用与代码生成作为 AI 智能体动作层之间的选择，是智能体架构中最关键的决策之一，却几乎没有人对其进行直接基准测试。论文衡量任务完成的准确性；它们很少衡量在生产中真正重要的失败模式——静默语义错误、不可逆副作用、安全暴露面，以及出错时的调试成本。

AI 系统设计中一个常见的错误是要求语言模型像阅读文档一样对图（graph）进行推理。模型会生成一个自信且流利的答案。但这个答案会以一种看起来正确的方式出错——它会列出真实的节点，引用看似合理的路径，并描述几乎存在的关系。接着你会发现，你的组织架构遍历幻觉出了越级经理，你的依赖项解析忽略了超过十个节点的图中的循环，而你的三跳知识图谱查询在第二步时的错误率就达到了 60%。

这不是提示词（prompt）质量的问题。这是一个架构问题，你可以在编写任何提示词之前就诊断出它。

上周二，某供应商在工具响应中将 "items" 更改为了 "results"。智能体没有崩溃。它围绕新结构重新进行了规划，返回了一个看起来很自信但丢失了三分之二行数据的答案，而轮值工程师在 3 天后因为客户询问导出数据为何缺失才发现。没有抛出异常。没有触发报警。运行在供应商变更前冻结的固定集（fixture）上的评测套件（eval suite）一直保持绿灯。

这种失败模式是十年前微服务中发明契约测试（contract testing）要捕捉的，而如今几乎没有智能体技术栈具备相应的对策。HTTP 服务有 Pact、schemathesis 和 oasdiff 位于消费者和提供者之间，拒绝让破坏性变更上线。你提供给智能体的工具——REST 端点、内部 RPC、供应商 SDK、MCP 服务器——都没有类似的保障。模型吸收了变化，优雅地进行了适应，并生成了一个看似正确但质量下降的答案。

Agent 对客户说：“收到——我已经提交了你的退款请求。你应该会在 5–7 个工作日内看到它。”客户关闭了聊天。但退款从未被提交。没有工单，没有 API 调用，退款表中也没有记录。有的只是一段礼貌且自信的英语，以及随后成功的会话终止。

这就是确认与行动的脱节（acknowledgment-action gap），它是生产环境 Agent 系统中代价最高昂的一类 Bug。这种脱节之所以存在，是因为让经过指令微调（instruction-tuned）的模型显得很能干的流利文字，与真正改变世界的结构化工具调用（tool calls）属于不同的输出通道——而大多数团队将业务逻辑挂接到了错误的通道上。

每个发布 Agent 的人最终都会以惨痛的方式意识到这一点。模型生成了一份读起来像承诺的精美确认函，下游系统将其解读为承诺，几周后一份支持工单寄来，询问退款去了哪里。令人尴尬的不是模型撒了谎，而是系统被设计成去信任它所说的话。

询问一个 Agent 团队他们的工具调用成功率是多少，你会得到一个答案。但如果你问他们的工具幻觉率（tool-hallucination rate）是多少，全场就会陷入沉默。大多数团队并不追踪这一指标，而那些追踪的团队通常也只计算最灾难性的版本——即目录中不存在的函数名——而那些更隐蔽、代价更高的变体则在生产环境中未受监控地运行。

幻觉化的工具调用不仅仅是指模型凭空捏造了 delete_orphaned_users(older_than="30d") 导致你的分发器（dispatcher）抛出 ToolNotFoundError。这是简单的情况。更复杂的情况是，虚假的调用通过模糊匹配隐匿地指向了一个相邻的真实工具，或者工具名称正确，但 Agent 捏造了一个参数，而你的 Schema 因为将其标记为可选而愉快地接受了它。这两种情况都能通过你的“工具调用是否成功”仪表盘，但都不是用户真正想要的。

你的智能体通过了所有单元测试，完美处理了正常路径，然后在某个周二下午，它试图调用 get_user_preferences_v2——一个在你的代码库中从未存在过的函数。这个调用在语法上看起来完全正确。参数也很合理。唯一的问题是，你的智能体凭空捏造了这一切。

这就是幽灵工具调用：一种不表现为错误文本而表现为错误操作的幻觉。与人类可能在审查中发现的事实幻觉不同，幽灵工具调用会直接命中你的运行时，抛出一个晦涩的 ToolNotFoundError，并使原本运行正常的多步骤工作流脱轨。

每个智能体的演示都从三个工具开始。一个网页搜索，一个计算器，也许再加一个代码执行器。智能体每次都表现完美。于是你上线了，团队开始添加各种集成——Slack、Jira、GitHub、邮件、数据库查询、内部 API。六个月后，你的智能体拥有了 150 个工具，却有 40% 的概率选错。

这就是工具爆炸问题，也是生产环境智能体系统中最少被讨论的失败模式之一。退化并非线性的——而是断崖式的。一个在 5 个工具时准确率达 95% 的智能体，在你给它 100 个工具时可能会跌破 30%，即使模型和提示词完全没有改变。