4 篇博文 含有标签「llm-tools」

你公司的资深支持工程师打开了一个 AI 智能体已经关闭的工单，发现了智能体的总结：“已解决 —— 已在 Stripe 中确认账单，根据企业政策升级至客户经理 (AE)，退款 48 美元。” 每一句话听起来都很合理。但事实上，没有任何一件事发生了。根本没有名为 check_stripe 的工具。也没有任何工具可以查询客户级别。总结中提到的 “AE” 已经不再负责该账户。智能体并没有调用它声称的任何工具；它只是通过改写工程师每周一都会阅读的同一份操作手册（playbook）来生成总结。而客户仍在等待。

智能体阅读的操作手册（runbook）本身是正确的。客户成功团队花了两年时间对其进行调整。资深工程师曾用它来培训新人。它准确地描述了人类会做的事情：如果客户提到账单，检查 Stripe；如果是企业客户，先联系 AE；如果紧急，进行升级。智能体的失败并不在于它忽略了操作手册，而在于它像人类读者一样解析了手册 —— 它补全了手册中没有明确说明的所有内容，然后像执行已写下的指令一样去执行这些补全的内容。

观察一个客服智能体处理一段对话，数一数它计算了多少次“流失风险”（churn risk）。第一次是在它对工单进行分类时。第二次是在它决定是否提供折扣时。第三次是在它起草升级摘要（escalation summary）时。每一次，它都会重新读取原始订单表，重新运行内联聚合，并生成一个数字。这三个数字并不匹配。没人注意到这一点，因为它们从未被放在一起记录过。

这就是特征工程（feature engineering）。智能体在每一轮对话中都在进行特征工程，而且是用自然语言进行的，其表现甚至不如十年前那些会被你在代码审查（code review）中嘲笑的流水线。

机器学习领域已经解决了这个问题。解决方案被称为特征存储（feature store），它所强制执行的纪律——计算一次特征、为其命名、对其进行版本控制、一致地提供服务——正是当你交给智能体一个数据库工具时，它立即抛弃的纪律。你的智能体并没有避免构建特征流水线。它构建了一个，只不过它构建的是整栋楼里最烂的一个。

工单上写着 “模型幻觉了一个用户 ID”。分拣标签是 model-quality。修复方案是在系统提示词中多加一句话。六周后，另一个工具开始幻觉日期格式，循环再次开启。一年后，提示词已经演变成一段针对整个后端的 4,000 token 的道歉信，而团队也坚信该模型在工具参数方面就是不可靠的。

模型并非不可靠。模型是一个合约一致性机器，它在阅读你提供给它的合约 —— 而你提供的合约一直在悄悄偏离线路另一端的合约。大多数生产环境中的 “参数幻觉” 并不是模型故障。它们是你的工具描述在默默失败的集成测试，之所以表现为模型输出，是因为这是技术栈中唯一能看到分歧的地方。

你智能体代码库中最昂贵的一行，就是从现有的 OpenAPI 规范中自动生成工具 Schema（tool schemas）的那一行。这看起来是一个利落的工程选择——单一事实来源、无重复、每次 API 变更时自动同步。但这也是为什么你的智能体在应该选择 searchUsersV3 时却选择了 searchUsersV2，因为你的规范示例中写了 limit=20 于是它就填了 20，并且悄无声息地丢掉了 tenant_id，因为它被埋在第七个参数槽位里。

单元测试中不会显现任何这类迹象。Schema 是有效的。端点（endpoint）是存在的。智能体的调用是格式正确的 JSON。然而，模型每次都会用错工具，且是以你的 QA 流水线永远察觉不到的方式，因为 QA 测试的是 API，而不是智能体对 API 的理解。

这个 Bug 是观念性的。OpenAPI 的设计初衷是向编写 SDK 代码的人类描述 API；而工具 Schema 则是作为 Prompt 的一部分，在每次调用时由 LLM 读取。将它们视为同一种产物，就好比根据数据库列名自动生成面向用户的文案一样，犯了同类型的错误。