生产环境里的 AI 为什么悄悄出错：语义漂移、评审瓶颈与智能体治理
InfoQ 的一场线上研讨会聚集了来自 ThoughtWorks、隐私与金融领域的实践者，讨论智能体系统上线后最容易被忽视的故障：它们不崩溃，却会稳定地给出错误结果。与会者还谈到编码智能体的产出速度已超过人工评审，以及企业该如何为自主智能体设定身份、权限与审批边界。
先看三个变化
这场研讨会题为《生产环境中的 AI：哪些会失效、哪些能正常运行，以及由谁审批上线？》，由 Hien Luu 主持，嘉宾包括 ThoughtWorks 的 Zichuan Xiong 与 Prem Chandrasekaran、隐私领域专家 Katharine Jarmul，以及金融 AI 从业者 Lan Chu。
Luu 在开场时归纳了三项驱动因素：
- AI 的失效方式与传统软件不同。它很少直接崩溃，更常见的是生成看起来合理、实际不准确的内容。
- 编码智能体产出生产代码的速度，已经超过了人类逐行评审的速度。
- 敏感数据出现了新的泄露途径，包括提示词、上下文窗口，以及检索到的文档。
这三条分别对应可靠性、研发流程和安全边界，也构成了整场讨论的主线。
隐性故障：系统显示正常，业务结果却在出错
Xiong 提到了大模型流水线中普遍存在的「语义漂移」。他举了一个文本转 SQL 的例子：翻译智能体频繁把不同业务域里的「会员」当成同一个概念，销售语境和客服语境下的会员被混为一谈。错误会一路传到下游的分析报表里，而且常规的链路追踪发现不了，因为每一步调用都成功返回了。
Chu 分享的案例更隐蔽。某金融合规系统用向量相似度阈值来拦截违规投资建议，做法是把文本转成向量（一串代表语义的数字），距离太近就判定为相似内容。后来底层嵌入模型做了一次后台更新，向量的距离分布随之改变，线上误报和漏报同时飙升。与此同时，所有基础设施健康检查仍然显示正常。
Chandrasekaran 补充了另外两类风险：检索增强生成（RAG，先从知识库找资料再让模型作答）的流水线可能无意中召回敏感文档；模型本身会记住训练数据，这些记忆可被用于去匿名化，甚至泄露 API 密钥。他还提到 GitSpawn 漏洞：恶意仓库配置能在开发者执行常规命令时触发未授权代码运行。
人工评审跟不上，流程要重新分工
当编码助手生成的代码量越来越大，逐行人工评审就成了瓶颈。Chandrasekaran 的观点是，风格和语法层面的检查必须交给 CI/CD 流水线自动化完成，人工评审只保留三类判断：高层架构、业务意图、非功能性需求。
Xiong 建议把工作「左移」，在拉取请求生成之前，就在智能体的运行框架（harness）层面评估它的意图是否符合预期。Chandrasekaran 还强调变异测试值得重新重视：故意在代码里制造小改动，看自动化测试能否发现。这样验证的是测试是否真的检查了底层逻辑，而不只是刷到了表面的覆盖率数字。
对正在用 AI 编程工具写代码的团队来说，这一点尤其现实：生成速度已经不是瓶颈，如何用自动化手段接住这些产出才是。
评估不是上线前的清单，而是长期运行的基础设施
Chu 认为，评估体系应当像监控一样持续运转，而不是发布前打勾的检查表。有效做法包括：在调用链的每个环节（span 级别）做在线追踪、过滤日志，再用大模型对故障模式分类。这样，生产环境里出现的边缘案例才能被回收进离线基准测试集，形成闭环。
智能体治理：把它当成刚入职的工程师
Jarmul 提醒，不要把提示词工程当作安全防线。她主张系统性红队测试、持续威胁建模、为自主智能体划定严格的功能范围，并提升可观测性，以应对更大的事件量。
Chandrasekaran 给出的类比很直观：把每个 AI 智能体当成一名新入职的工程师来管理。具体做法包括：
- 分配独立的非人类身份，而不是共用人类账号；
- 实施分级访问控制，区分只读操作与可回滚的写入操作；
- 对第三方 MCP（让模型调用外部工具的协议）依赖项做版本管理；
- 把 API 密钥隔离在沙箱里，不让智能体运行环境直接接触。
最后一点被反复强调：工程、安全、隐私团队负责验证防护机制是否有效，但「是否上线」本身是业务决策，不该由技术团队单独拍板。
原文链接：https://www.infoq.com/news/2026/10/ai-systems-production/
关键要点
- 生产环境中的 AI 故障多为「静默错误」：链路追踪和健康检查都正常，业务结果却已偏移，语义漂移和嵌入漂移是两类典型成因。
- 编码智能体的产出速度已超过人工逐行评审，团队应把风格与语法检查自动化，人工只审架构、意图和非功能性需求。
- 评估体系要作为持续运行的基础设施，通过 span 级追踪和故障分类，把线上案例反馈进离线基准。
- 智能体应按「新员工」管理：独立身份、分级权限、依赖版本锁定、密钥沙箱隔离；上线审批属于业务决策。