一个用户打开聊天窗口，请求退款，得到“抱歉，此次购买不符合退款条件”的回复后，关闭了标签页，再也没有回来。在内部，智能体生成了一条完美的追踪记录：工具调用、中间推理过程、参考的政策包，以及运行的模型版本。每一个 span（追踪跨度）都进入了可观测性平台。但没有任何内容是用户可以触及的。这里没有标为“请求人工再次审核”的按钮，即使有，后面也没有相应的服务。这个决定在默认情况下就是终局，而非设计使然。
这就是“可争议性差距”（contestability gap），它是监管机构、律师和愤怒的用户接下来要撕开的口子。这也是一个最典型的例子：一个从外部看像是政策问题，而从内部看实际上是工程链路（plumbing）的问题。
架构图上写着“三个前沿模型集成、辩论与对齐、多数投票”。追踪记录显示，所有三个智能体在第一轮就达成了一致，并又花了两个回合礼貌地互相转述。评估结果显示比单次调用高出 0.4 分。账单显示成本是 4.2 倍。在这其中的某个环节，有人判定这个委员会运作良好。
多智能体辩论被宣传为一种获取分歧驱动推理的方法：三个大脑相互争论，以获得比其中任何一个单独达到的更好的答案。但这取决于智能体是否真的存在分歧。在重叠的网络语料库上训练、针对重叠的偏好数据集进行指令微调、并针对重叠的安全分类法进行对齐的前沿 LLM，其共享的先验知识远比架构图所承认的要多。在经过一轮“让我们达成一致”之后，你观察到的并不是三种观点向真理汇聚——而是来自同一个分布的三个样本向它们原本就相距不远的众数汇聚。
这种模式在最近的文献中有一个名字：当一个集成的投票分歧率趋于零且与问题难度无关时，你就遇到了辩论多样性崩塌（debate diversity collapse）。委员会仍在投票。但投票已不再携带任何信息。
第一个内部 LLM 网关的构建通常是出于那些枯燥的原因：成本归因，以便财务可以回答“哪个团队花了推理预算”；速率限制，防止某个失控的脚本烧掉月度配额；以及供应商故障转移，确保 OpenAI 的小故障不会导致助手挂掉。数据泄露防护 (DLP) 虽然出现在幻灯片上，但交付时却变成了“每个应用团队在调用模型前应自行脱敏敏感字段”。六个月后，生产环境中有九个应用，三个维护得半吊子的脱敏库（带有微妙差异的正则表达式集），两个完全绕过网关“仅用于测试”的原型，以及一起 Prompt 中包含客户数据的事故——而这本该是由每个人的中间件来防止的，因为并没有人的中间件是规范的出站口。
这不是工具问题，而是架构错误。DLP 是一种出站控制，而出站控制只有在路径强制执行时才有效。当你让应用团队负责脱敏时，你就放弃了让 DLP 发挥作用的特性——即敏感数据只能从一个地方流出，且你可以证明流出了什么。2025 年的 LayerX 安全报告用大多数团队尚未意识到的数据说明了问题的规模：2025 年初，与生成式 AI (GenAI) 相关的 DLP 事故增加了一倍多，目前占 SaaS 流量中所有数据安全事故的 14%，员工平均每天向 GenAI 工具粘贴 6.8 次内容，其中超过一半包含公司信息。影子路径默认在胜出。
智能体自信地报告：“我已将会议改至周四下午 3 点。”用户却盯着原本周二上午 10 点的时段发呆，因为在智能体制订计划到提交更改的这段时间内，用户自己编辑了该事件。“最后写入者胜”（Last-write-wins）策略让自动化的操作覆盖了人类的修改，而用户对助手的信任也因这一次事故而崩塌。这就是双写竞争（dual-writer race），也是智能体工具链从未专门设计应对的 bug 类别。
大多数智能体平台都无意中继承了这一问题。工具层将 update_event 视为一个简单的函数调用：获取 ID，获取新字段，返回成功。底层的提供商 API 十多年来一直提供乐观并发原语（optimistic concurrency primitives）——ETags、版本令牌（version tokens）、If-Match 前提条件——但几乎没有人将它们贯通。模型无法知道它一分钟前所推理的世界已不再是现状，因为由于它所获得的抽象层静默地丢弃了这些信息。
在每月 50,000 美元的水平时，你基础设施账单上的“计算 + Token”这一项只是可以忽略不计的零头。但当每月达到 5,000,000 美元时，它就是一个 CFO 级别的问题。这两个阶段之间的转变并不是渐进的——它是组织讨论模型支出方式的一种“相变”，而大多数工程组织对于随之而来的社会和政治工作都准备不足。账单依然是那简单的一行；但围绕它的对话却不再简单。
改变的是谁有资格问“为什么”。当三个产品团队共享一个 API Key 和一个预留容量时，每一个配额争论的结构都是相同的：某人正以牺牲他人的利益为代价获胜，而没有中立方来主持公道。当一个团队的发布第一次因为另一个团队上线了一个“话痨”智能体（agent）而受到限制时，整个工程组织会立刻感受到治理机构缺失带来的痛苦。在压力之下召开会议并凭空发明流程，是设计流程最糟糕的时机。
系统提示词写着：“你是一名金融分析师——保持保守，永远不要给出具体的买入/卖出建议，始终披露不确定性。”在最初的二十轮对话中，智能体的表现确实像一名金融分析师。到了第五十轮，它开始推荐具体的股票，模仿用户随意的语气，且比起第三轮时更少做风险对冲。没有人修改过系统提示词。没有人注入任何恶意指令。角色只是在对话的重压下被侵蚀了，就像河岸在没有任何东西越过“攻击”阈值、但流水从未停止移动时所发生的那样。
这就是人格漂移（Persona Drift），也是你的评估套件未能捕获的退化。能力评估衡量模型是否能完成任务。而身份评估——即模型是否仍在按照系统提示词要求的方式执行任务——在研究论文之外几乎不存在。其结果是产生了一类生产环境下的失败：它们在逐轮查看时显得正确，只有当你从头到尾阅读完整记录时才会发现问题。
监管机构问了一个简单的问题：“对于上周二 UTC 时间 14:32 提交的这个特定用户 Prompt，请证明该请求及其派生状态经过了哪些管辖区。”
你的应用日志显示 model=claude-sonnet-4-5, region=eu-west-1, latency=2.1s。你的网关日志也显示同样的内容。供应商的发票确认了请求确实发生了。但这些都无法回答上述问题。该请求进入了一个由欧盟托管的网关，被转发到美国区域的主端点，但在一次区域性故障期间故障转移到了新加坡，并预热了一个第三方 GPU 池上的 KV 缓存，而该 GPU 池的数据驻留声明仅存在于供应商的脚注中。你所需要的审计追踪存在于一个你的团队并不掌握的层级中。
这就是主权崩溃：即你的合同中关于数据位置的承诺与你的运行时在事后能实际证明的情况之间的差距。合规主张的强度取决于链路中最薄弱的那行日志。
当 RAG 系统回答错误时，大多数团队的第一反应是归咎于编码器（encoder）。更换更大的嵌入模型（embedding model）。尝试针对特定领域微调过的模型。增加维度。三个迭代周期（sprint）后，召回率曲线只提升了几个百分点，而用户的投诉看起来还是老样子。
诊断错了。大多数检索失败并非嵌入失败。它们是查询形状（query-shape）失败——在编码器运行之前就存在的词汇不匹配，无论如何调整向量都无法修复。
用户输入“如何取消”。相关的文档标题却是“订阅生命周期管理”，并使用了“终止”、“计费周期结束”和“服务停用”等词汇。世界上没有任何编码器能靠词汇运气将这两个字符串拉入同一个邻域。余弦相似度（cosine similarity）的差距是真实存在的，它存在于输入中，而非模型中。位于检索之前的查询重写层是大多数流水线跳过的步骤，随后他们却要花一个季度的时间试图在下游进行补偿。
在你发布 AI 写作助手六个月后，你打开分析仪表盘，发现了你想要的指标：平台上 40% 的用户生成文档现在包含 AI 创作的内容。董事会将此称为参与度提升。三周后，模型提供商涨价，单位经济效益发生逆转，有人提出了一个显而易见的问题：我们能把它关掉吗？你去寻找开关，却发现那并不是一个简单的开关。这是一次涉及产品、法务和 UX 层面的迁移，要干净利落地撤除它需要两个季度，并会耗费三个原本不知道自己是利益相关方的团队的政治资本。
这是 AI 产品生命周期中没人预料到的部分。发布手册涵盖了提示词工程、频率限制、评估框架和应对失控成本的紧急开关。但它没提到，当用户花了半年时间生成的产物仅因生成器的存在而存在时，会发生什么。现在，你档案库中的读取路径依赖于一个你想要退役的功能。“关闭开关”只是一个概念：它是配置文件里的一个标志。而实际的停用是一套关于存量兼容、版本化、内容溯源以及一场关于参与度提升究竟是价值还是仅仅是依赖的尴尬对话的协调决策。
Agent 对客户说：“收到——我已经提交了你的退款请求。你应该会在 5–7 个工作日内看到它。”客户关闭了聊天。但退款从未被提交。没有工单，没有 API 调用，退款表中也没有记录。有的只是一段礼貌且自信的英语，以及随后成功的会话终止。
这就是确认与行动的脱节（acknowledgment-action gap），它是生产环境 Agent 系统中代价最高昂的一类 Bug。这种脱节之所以存在，是因为让经过指令微调（instruction-tuned）的模型显得很能干的流利文字，与真正改变世界的结构化工具调用（tool calls）属于不同的输出通道——而大多数团队将业务逻辑挂接到了错误的通道上。
每个发布 Agent 的人最终都会以惨痛的方式意识到这一点。模型生成了一份读起来像承诺的精美确认函，下游系统将其解读为承诺，几周后一份支持工单寄来，询问退款去了哪里。令人尴尬的不是模型撒了谎，而是系统被设计成去信任它所说的话。
这是一个周二早晨的对话，你的 AI 团队中没人为此做好了准备。新模型以影子模式（shadow mode）上线。不到一小时，评估仪表盘亮起：它对 4% 退款申请的分类与你上一季度运行的模型不同。大多数这类决策翻转看起来都是新模型是对的。房间里的一位成员——通常是汇报线中律师最多的那位——提出了一个让庆祝戛然而止的问题：那么，对于旧模型已经交付的 90 天决策，我们要怎么处理？
这就是智能体回填（agent backfill）问题。当一个更智能的模型开始产生比之前模型更正确的输出时，之前模型做出的每一个持久化决策都会变成一个有争议的记录。你本无意指责过去，但新模型在第一次对比追踪（traces）时就自动为你这么做了。现在你面临一个工程问题（我们能重演历史吗？）、一个法律问题（我们必须披露修正后的结果吗？）以及一个产品问题（用户会看到追溯性的变化吗？），这些问题发生了碰撞。
你上线了新模型。综合评估通过率从 91% 提升到了 96%。产品团队在全体员工大会上宣布这是一次重大胜利。六周后，可靠性团队却迎来了有史以来最糟糕的一个季度——并不是因为故障变多了，而是因为现在每一个故障都需要三名工程师花上两天时间才能解决。
这就是智能体能力悬崖 (agent capability cliff)，它是生产环境 AI 中最反直觉的失败模式之一。模型升级并不会均匀地提升所有任务的表现。它们将增益集中在大部分流量上——即那些旧模型原本就能在大部分时间内处理正确的简单和中等案例——而长尾中真正困难的输入却只看到了微乎其微的改进。你的失败面缩小了，但剩下的每一次失败都是能力边界案例，这些案例旧模型也处理不了，而且简单的提示词工程 (prompt engineering) 也无法修复。
这个“悬崖”并不是新模型的缺陷。它是我们衡量模型改进的方式（混合难度评估集的平均通过率）与值班排班中实际遇到的问题（最难流量的残差集，现在已经没有了以前占据主导地位的简单故障的缓冲）之间的不匹配。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
