你的团队第一次意识到 Agent 可以调用 revoke_api_key 是在某个早晨，一位好心的用户输入了：“这个 Token 感觉太旧了，能帮我轮换一下吗？” 这个工具是在六个月前作为认证团队 MCP 服务批量导入的一部分注册的。它通过了 Schema 验证，出现在目录枚举中，然后就一直闲置在那里。没有任何评测（Eval）调用过它，也没有任何生产环境追踪（Trace）触及过它。直到某条提示词（Prompt）、某个规划器（Planner）决策，事件频道（Incident Channel）才发现该工具竟然存在。
这就是隐藏在每一个拥有复杂工具目录的 Agent 中的失效模式。四十个注册函数和一个可以组合它们的规划器，产生了一个你从未观察到的计划可达图的长尾。假设“我们测试了常用路径”掩盖了一个事实：危险的分支几乎从定义上来说就是你从未见过的那一个。
我上个季度接触的一个团队上线了一个他们称之为“路由项目”的东西：在他们的旗舰模型前端放了一个微型 BERT 分类器，用来判断查询是否足够简单，以便分流给更便宜、更快速的备选方案。这个项目在三周内就回本了。成本仪表盘上绿光一片。旗舰模型的评估套件——包含三百个对抗性案例、每周的评分运行等等——依然在每个周五稳稳通过。
上线六周后，某个特定产品界面的留存率下降了四个百分点，没人能找到原因。旗舰模型表现正常。延迟也正常。结果发现，路由竟然将 71% 的查询发送到了廉价模型。这种情况从第二周就开始了。对于大多数用户来说，这个廉价模型才是真正的产品，而这个廉价模型根本没有任何评估套件。
这是我在 2026 年看到的采用 LLM 路由进行成本控制的团队中最常见的失败模式：评估规范被绑定在系统的昂贵长尾部分，而廉价的头部部分——即承载大部分请求量、定义了产品体验的部分——却处于盲跑状态。
你的 AI 技术栈中最危险的数据存储是那个无人设计的存储。这一切始于一次冲刺期间的 Slack 消息：“真实用户是捕捉真实 Bug 的唯一途径 —— 让我们把一定比例的生产流量接入评估流水线，以便我们可以每晚进行回放。”六名工程师给这条消息点了赞。九个月后，该存储桶包含了 430 万条追踪（traces），当失败率上升时，评估任务会呼叫值班人员，而失败案例会被逐字发送到一个有 40 人阅读的 Slack 频道。这些追踪包含电子邮件地址、公司内部名称、部分信用卡卡号、员工电话号码，以及用户解释其愤怒原因的客户支持对话记录。
没有人梳理过数据流。没有 DPIA（数据保护影响评估）涵盖它。上季度的隐私审查查看了模型供应商的 API；但它没有查看你的评估任务。然后，一份数据主体删除请求送达，团队发现“删除该用户的所有数据”这句话已经无法对应到他们实际能做的任何事情。
一位产品经理（PM）带着一张幻灯片走进 AI 功能评审会，上面写着：“参与度 +12%，会话时长 +8%，留存率上升 3 个百分点。” 房间里的人纷纷点头。而在两个工位之外，客服主管正盯着另一张图表：涉及 AI 界面的工单增加了 22%，最常见的处理逻辑是“用户放弃，由人工客服协助”。这两个数字都是真实的，且都来自同一个产品。PM 的仪表盘建立在这样一个假设之上：AI 功能产生的事件形状与它所取代的按钮完全相同。事实并非如此。仪表盘统计的数据与用户实际体验之间的差距，正是 AI 功能在众目睽睽之下悄然失败的原因。
确定性功能的操作手册将交互视为点击流：用户触发一个事件，系统做出反应，用户继续操作。AI 功能具有不同的事件形状——一个包含阶段、重试、转向人工以及遥测数据永远无法看到的离线判断的“任务弧”（Task Arc）。将确定性仪表盘套用在这个任务弧上，就像是用 2018 年的面试流程来筛选 2026 年的工作职位。数字在上升，但这些数字本应预测的结果却在下降。
运维工程师调出一个 trace。模型已返回，span 正常关闭，API 调用显示 stop_reason: end_turn。从平台提供的各种信号来看，这是一次成功的生成。3 分钟后，客户报告说 Agent 煞有介事地写了半个配置文件，宣布操作完成，然后就继续下一步了。Trace 里没有任何预警信号，因为预警信号不在 API 协议里 —— 供应商提供的停止原因只有四到七类，而你的事故排查所需要的答案，恰恰隐藏在这些类别的缝隙之中。
停止原因（Stop reasons）是工程师在故障排查时最先查看的字段，也是最具误导性的字段。这些值是为运行时（runtime）设计的，旨在决定下一步该做什么：这一轮是否完成了？是否请求了工具？是否超出了预算？安全检查是否介入了？它们并不是为了让开发者重建答案出错的原因而设计的，而这两者之间的差异，正是生产团队耗费整个下午的时间所在。
模型正在逐个 Token 地输出 JSON。你的 UI 希望在字段出现的那一刻就进行渲染 —— 在冗长的回答正文之前显示置信度得分，或者在模型填充工具调用参数时实时显示它们。接着，有人尝试在每个数据块（chunk）上调用 JSON.parse，结果整个系统就崩溃了，因为 JSON.parse 是“全或无”的。它需要一个结构完整的文档才能返回任何结果。在模型输出闭合括号之前，你什么也显示不出来。
这不是一个可以通过 try/catch 解决的解析器问题。标准 JSON 解析器是针对内容长度已知的 HTTP 响应设计的。部分输入并不是它所建模的状态 —— 而是被视为“输入错误”。当你将 Token 流视为 HTTP 正文处理时，你继承了三十年来“文档要么完整，要么无效”的传统，而你的 UI 则为此付出了代价。
上个季度我交流过的一个团队发布了一个客户支持智能体，其系统提示词存储在 Postgres 的一行中，每个租户一行。这个方案听起来很合理：企业客户要求定制语气，“让提示词可编辑”是实现这一目标最廉价的方式。六个月后，发生了三件事。评估套件从 200 个案例膨胀到了 11,000 个，因为每个租户的提示词现在都需要自己的回归测试集。提示词更新工作流悄然变成了一个没有审核的写入路径，因为产品负责人被赋予了对表的直接访问权限。此外，由于部署流水线根本不知道提示词发生了变化，一个韩国租户提示词中损坏的 UTF-8 字符导致该租户的聊天机器人下线了两天，却没人察觉。
这些结果都不是需求强制导致的。它们是由一个无人刻意做出的架构决策所强制导致的：系统提示词存放在哪里？在代码中？在配置文件中？还是在数据库行中？团队选择了“数据库”，因为这是实现功能最快的路径，而后果在接下来的几个月里级联影响到了每一个相邻系统。
我今年雇佣的三位最优秀的 AI 工程师，如果让他们互相面试，可能都会被刷掉。那个能写出在模型升级后依然稳健的提示词（prompt）的人，这辈子没写过一个有用的评估（eval）用例。那个能设计出捕捉到关键故障的评估集的人，写的提示词其他工程师根本不想去维护或扩展。那个能设计出既能“故障闭合”（fail closed）又不阻塞正常路径的护栏（guardrail）的人，对另外两个人的看法我在这里不便多说。
职级体系将他们三人都称为“AI 工程师”。定级委员会在对比他们的晋升材料时，仿佛他们做的是同样的工作。其实不然。
用户提交了一个 42。该查询在技术上是成功的——智能体返回了一个合理的答案。只是为了得到这个答案，它经历了三个嵌套的子智能体、一次 200K token 的文档获取，以及一个递归的计划优化循环。这些扇出（fanout）操作并非用户的本意，而是隐藏在智能体所读取页面中的一句话。
这就是代币放大（token amplification）：一种提示词注入攻击，它不窃取数据，不调用未授权工具，也不会留下明显的安全特征。它只是烧光你的账单。云账单是攻击载荷，而用户的请求则是载体。
供应商声称这次升级是无缝替换。API 契约保持不变。配置中的模型名称几乎没变。一周后，你的上下文窗口防御机制（context-window guard）开始在以前从未触发过的提示词（prompts）上报警，你的停止序列（stop-sequence）正则匹配在了错误的位置，而你的少量样本（few-shot）示例之一开始产生一个极其自信的错误答案，而你的评估套件恰好没有覆盖到这一点。没有人动过提示词。没有人动过温度参数（temperature）。有人悄悄重新训练了分词器（tokenizer）。
分词器更改是供应商不会称之为“破坏性”（breaking）的破坏性更改。API 层面保持了字节级稳定，SDK 没有升级主版本，发布说明中提到了“改进的指令遵循能力”——但从你的输入字符串到模型实际看到的整数序列的映射函数已经被替换了。你的代码关于文本如何转换为标记（token）的每一个假设现在都出现了微妙的偏差。这种隐形代价是，在有人重新通过 count_tokens 运行标准提示词并发现答案之前，你会经历两周“感觉模型不太一样”的困惑期。
大多数生产环境中的 AI 功能在发布时只带有一个置信度阈值。在阈值之上，模型给出回答；在阈值之下，用户会得到一句生硬的“我不确定”。这个单一的数值同时承担着两个完全不同的任务，这就是为什么即便你对已回答查询的准确率看起来不错，但信任度指标却已经连续两个季度下滑的原因。
正确的设计至少应该有两个切分点。一个“弃权”（abstain）阈值设在低位：低于该值时，模型拒绝回答，因为此时保持沉默比给出任何答案都更有价值。一个“升级”（escalate）阈值设在中间：在两个切分点之间，系统将案例交给人工审核员，而不是直接将其丢弃。将它们合并成一个刻度盘，你发布的产品在出错时和不确定时会让人感到同样无用——在用户只需打开另一个标签页就能找到免费替代品的市场中，这是最糟糕的处境。
这并不是什么新鲜想法。拒绝选项分类器（reject-option classifier）的文献自 20 世纪 70 年代以来就一直在主张拆分阈值，将“歧义”拒绝（输入介于已知类别之间）与“距离”拒绝（输入远离任何训练数据）区分开来。生产环境中的 AI 团队总是在以惨痛的方式重新学习这一教训，通常是在首次发布大约六个月后，当支持队列中挤满了询问“这玩意儿是坏了还是怎么了”的人时。
在过去六个月中，我审计过的每一个团队都声称自己是供应商无关的。但实际上没有一个团队能做到。在评估套件中得分最高的系统提示词之所以表现出色，是因为它倾向于单一供应商的分词器行为、JSON 模式协议、拒绝节奏以及停止序列处理 —— 而编写该提示词的团队甚至无法说出其中哪些偏差在起作用。当 CFO 询问为什么采购清单上更便宜的模型不能直接替换时，诚实的回答是：这需要两个工程师季度的提示词重新调优以及对每个评估进行完全的基准重设。这不仅仅是一个勾选项。它是一个季度的成本项。
一直困扰团队的心智模型是将供应商可移植性视为一次性的架构决策。你添加了一个抽象层，在配置中写了一个 model: 字段，以此自我庆贺，然后继续前进。一年后，当供应商提价、发布弃用通知，或者在你关注的某个类别上出现了一周糟糕的拒绝服务时，你发现那个抽象层只是一个围绕特定模型提示词的薄包装。你买到的可移植性是语法上的。而你真正需要的是行为上的可移植性，且行为上的可移植性在你停止支付的那一刻就会衰减。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
