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

上周二，某供应商在工具响应中将 "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%，即使模型和提示词完全没有改变。