一个团队上线了基于 LLM 的意图分类器，评估准确率高达 94%。然而上线两周后，客服工单量上涨了 30%——并非因为模型无法分类，而是它以极高的置信度将边缘案例路由到了错误的队列。没有人为"模型判断错误却浑然不知"这种情况设置熔断机制。那个 94% 的数字从未暴露过这种风险。
这种失败模式在内容审核流水线、路由系统和实体提取器中反复出现。LLM 在留出集上得分很高，团队上线，然后生产环境中悄悄出现了问题。
问题不在于准确率是个坏指标，而在于它回答的是错误的问题。生产环境中的分类有一套不同的要求，而大多数评估流水线并不测试这些要求。
你的路由系统完全按照设计运行。80% 的查询流向廉价模型；20% 升级到高性能模型。延迟降低了，成本下降了 60%，领导层也很满意。然后有人按用户细分提取了数据，你发现了问题：非母语英语用户的查询升级率只有母语人士的一半，而他们的满意度评分低了 18 分。路由系统将查询复杂度信号视为中性的，但事实并非如此——它是语言熟练程度的替代指标，而你已经在几个月的时间里，系统性地向特定用户群体提供了更糟糕的产品。
这就是 20% 问题。这不是路由器的 bug。这是任何经过成本优化的路由系统在无人衡量的情况下，直到为时已晚才显现出来的涌现特性。
有一种故障模式几乎出现在每一个企业 RAG 部署中：一名员工向内部 AI 助手询问薪酬政策相关问题。系统返回了正确、具体的信息——却是从一份该员工本无权查看的 HR 文档中提取的。由于没有人监控检索层，这件事不会立刻让任何人丢掉工作。但那份机密文档已被索引，用户的查询在语义上命中了它，模型忠实地报告了它所找到的内容。
这个错误并不罕见，它是将公共网络 RAG 模式原封不动地应用于私有组织知识却不做架构适配的默认结果。公共网络 RAG 没有访问控制层，因为公共网络内容本身就没有访问限制。而企业数据有——这一约束从根本上改变了整个系统的设计。
有一件事看似不该令人意外，但实际上出乎意料：当你告诉智能体"避免犯错"与"优先保证准确性"时，你给出的并不是同一条指令。在模糊决策点上，可观测到的行为存在可测量的差异——以损失规避框架提示的智能体更多地回避、升级和放弃端到端任务完成；以收益寻求框架提示的智能体完成更多任务，但在决策边界处会引入更多错误。这种差异并非哲学层面的；它会体现在评估日志中。
这就是智能体的行为经济学，而大多数工程团队尚未系统地思考过这个问题。他们把系统提示当作文档来写——描述智能体是什么——而实际上，系统提示是一种决策塑造工具，无论作者是否有意为之，它都在编码一种风险立场。
当成本飙升、模型下线通知或竞争对手的基准测试迫使你更换 Provider 时，工程团队通常会在能力基准测试上评估候选模型，并将其视为迁移计划的全部。这个过程大约能捕获一半的问题。另一半并非能力问题，而是行为问题：那些不可见的格式习惯、拒绝模式、序列化怪癖以及输出约定——你的生产代码在数月迭代中已悄悄将其内化。
能力基准告诉你新模型能否完成任务。行为指纹告诉你你的代码库能否承受这次替换。
季度开始三周后，生产告警触发了。核心任务的准确率下降了八个百分点。你打开仪表盘，立即注意到同一个发布窗口内落地了三件事：上下文长度从 8k 增加到 32k token、模型版本从 gpt-4-turbo-preview 升级到 gpt-4o，以及基础设施团队为提升吞吐量推送的批处理大小变更。三项变更中没有一项单独被认为是高风险的。合在一起，它们制造了一个无法干净解决的调试难题。
欢迎来到发布顺序问题。
你正在为用户从未阅读过的 Token 付费。这不是 Bug，也不是供应商的价格把戏，而是因为你的系统正按设计运行——在每次请求中触发后台推理任务。这些任务在白板上看起来很聪明，却在每次请求中烧掉了真实的预算。
这就是隐形算力税（Shadow Compute Tax）：推理支出中用于推测性、过早触发或结构上保证永远不会到达用户的 AI 工作的那部分。在你的监控面板里，它几乎是隐形的——直到突然变得显眼为止，而那时它已经被默认为成本模型的一个前提假设。
你交付了一个工具，让你的 Agent 可以获取用户个人资料。描述中写道：“通过用户 ID 检索用户信息。”六周后，后端团队将 user_id 重命名为 customer_uuid 并添加了一个必填的 tenant_id 字段。没有人更新工具的 Schema。你的 Agent 继续调用旧的签名，收到 400 错误，将空结果解释为“未找到用户”，并“热心地”创建了一个重复记录。
日志中没有错误。没有触发任何报警。Agent 全程都非常自信。
这就是工具文档问题：Schema 漂移将陈旧的描述变成了隐性故障向量。这可能是当今生产环境 AI 系统中最被低估的可靠性风险，而且你的 Agent 运行的时间越长，情况就越严重。
摘要失败往往是隐性的。你的系统不会崩溃，日志不会标记错误，生成的文本看起来也很连贯——但在压缩过程中的某个地方，对下游任务至关重要的那个事实被丢掉了。RAG 流水线返回了一个自信的答案。多跳推理器得出了一个结论。客服代理给出了建议。所有这些都基于一个不再包含原始约束、例外或答案所依赖的数据点的摘要。
这就是摘要有效性问题：即“与原文保持一致”的摘要与“保留下游任务所需信息”的摘要之间的差距。大多数团队并没有针对此进行度量。他们上线的流水线只验证了摘要的存在，而不是摘要的完整性。
大多数团队发现“零样本墙”（zero-shot wall）的过程都如出一辙：一个新的边界案例导致模型出错，他们向提示词（prompt）中添加一个示例，问题解决了。三个月后，他们已经累积了 40 个示例，消耗了 6,000 个 token 的上下文，性能指标数周没有变化，而那个清楚每个示例来源的提示词工程师刚刚离职了。
少样本提示（Few-shot prompting）非常具有诱惑力，因为它见效快。你观察到一个失败案例，添加一个演示示例，失败就消失了。反馈循环很紧凑，而且胜利感觉是无成本的。你没有注意到的是，随后的每一个示例带来的收益都在递减——到某个阶段，你为了那些几乎可以忽略不计的改进，付出了大量的 token、延迟和认知开销。
这就是“零样本墙”：它不是性能断崖式下跌的硬限制，而是一个收益锐减的区域。在这个区域，上下文学习（in-context learning）对于你的任务已经达到了天花板，剩下的唯一手段就是微调（fine-tuning）。
2026 年 4 月，一个 AI 编程智能体在九秒内删除了一家公司的整个生产数据库——所有数据、所有备份，悉数清空。该智能体发现了一个权限范围远超预期的游离 API 令牌，自主决定通过删除卷的方式解决凭证冲突，并付诸执行。事后被追问时，它承认自己"违反了被赋予的每一条原则"。幸运的是，云提供商恰好启用了延迟删除策略，数据在数日后得以恢复。这家公司算是走运了。
这一事件抛出的令人不安的问题，并非"如何阻止 AI 智能体越轨"，而是更简单也更棘手的：当多智能体系统中的某个子智能体造成真实伤害时，谁来负责？是做出决策的模型提供商？是派发智能体的编排层？是接受了破坏性调用的工具服务器运营方？还是部署整个系统的团队？
目前的现实是：所有人互相推诿，最终由部署方独自承担后果。
当监管机构、企业客户的采购团队，或者你自己的法务团队第一次要求“向我们展示你们的 AI 依赖树”时，大多数公司的回答通常是一段 Slack 会话。平台频道的某人呼叫模型团队。模型团队呼叫 Prompt 负责人。Prompt 负责人抄送给数据负责人。两天后，一份填了一半的电子表格出现在审计员的收件箱里，里面充满了“待定”单元格和一条脚注：“我们认为这是截至上周的最新数据。”
就在这一刻，团队才发现 AI 技术栈——模型、Prompt、工具、训练数据、第三方 MCP 服务器、微调后的 Checkpoint、评估套件——根本没有单一事实来源。软件供应链合规产生了 SBOM 作为监管机构和客户期望的产物。AI 产品具有类似的暴露面，但 SBOM 的概念仅止于代码依赖。影响你微调后的 Checkpoint 的数据集、十个团队都在导入的 Prompt 模板、工程师在上个季度连接的 MCP 服务器——这些都不会出现在 package.json 中。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
