AI 智能体生产故障：语义漂移与隐性泄露成治理难点

AI 智能体在生产中呈现新型失效模式：非崩溃式错误、语义漂移与隐性数据泄露。文本转 SQL 智能体因领域概念混淆导致分析偏差，且绕过传统可观测性手段。审批与评审机制尚未适配智能体生成代码的速率与风险特征。

语义漂移使领域概念错配，引发下游分析偏差

提示词与上下文窗口构成新型敏感数据泄露面

LLM 流水线缺乏适配语义错误的可观测性方案

适合 AI 工程师、MLOps 工程师、平台架构师阅读

在 InfoQ 近期举办的一场题为《生产环境中的 AI：哪些会失效、哪些能正常运行，以及由谁审批上线？》的网络研讨会上，一个由资深工程实践者组成的小组深入剖析了部署智能体系统过程中遇到的各类现实难题。本次研讨会由 Hien Luu 主持，嘉宾包括来自 ThoughtWorks 的 Zichuan Xiong 和 Prem Chandrasekaran、隐私领域专家 Katharine Jarmul 以及金融 AI 从业者 Lan Chu。

Luu 在开场时指出了三个核心驱动因素：AI 的失效模式与传统软件不同，它会生成看似合理但不准确的结果，而不是直接崩溃；编码智能体生成生产代码的速度已经超过了人类的代码评审速度；敏感数据有了新的泄露途径，包括提示词、上下文窗口以及检索到的文档。

ThoughtWorks 托管服务 AI 运维负责人 Xiong 强调了 LLM 流水线中普遍存在的“语义漂移”问题。他描述了一个文本转 SQL 的翻译智能体如何频繁地混淆特定领域的概念，例如将销售领域和客服支持领域的“会员”视为同一概念，从而在下游业务分析中产生不易察觉的错误，而这些错误却能绕过常规的链路追踪检测。

同样，Chu 分享了一个由金融合规系统中的“嵌入漂移”引发的严重故障。在部署了一个基于向量相似度阈值来拦截违规投资建议的智能体后，底层嵌入模型的一次后台更新改变了向量距离分布。这导致线上流量中的误报和漏报率急剧飙升，而与此同时，所有基础设施健康检查却完全显示为绿色（正常）。

此外，Chandrasekaran 指出 RAG 流水线可能会在无意中检索到敏感文档，而 Jarmul 则提到模型本质上会记忆训练数据，可能被用来去匿名化信息或泄露 API 密钥。Chandrasekaran 还提到了 GitSpawn 漏洞，说明恶意仓库配置能够在执行常规命令时触发未授权代码运行。

随着编码助手生成的生产代码数量日益庞大，传统的人工代码评审流程正面临难以持续的瓶颈。ThoughtWorks 技术与商业服务负责人 Chandrasekaran 强调，逐行的人工代码评审无法跟上高速发展的智能体产出。工程团队必须在 CI/CD 流水线中实现战术层面的风格和语法检查自动化，人工审查只聚焦高层架构、业务意图以及非功能性需求。

Xiong 补充说，团队必须将工作“左移”，在拉取请求生成之前就在 harness 层面评估意图。Chandrasekaran 还强调了变异测试的再度兴起，认为这是一项关键实践。通过引入刻意的代码变异，团队可以验证自动化测试套件是否真正校验了底层逻辑，而不只是单纯满足表面的代码覆盖率指标。

在评估智能体系统时，Chu 强调，评估体系应当作为长期持续运转的基础设施，而不是发布前一成不变的检查清单。有效的评估需要在 span 级别进行持续的在线追踪、日志过滤，并使用 LLM 对故障模式进行分类，从而使团队能够将生产环境中的边缘案例反馈到离线基准测试套件中。

为了应对隐私和安全风险，Jarmul 警告不要依赖提示词工程来进行系统防御。她主张进行系统性的红队测试、持续的威胁建模、为自主智能体定义严格的功能范围，并提升可观测能力，以便处理更大的事件量。为了限制自主智能体行为的影响范围，Chandrasekaran 建议将每个 AI 智能体都视为一名新入职的工程师来管理。

企业应当为智能体分配独立的非人类身份，实施分级访问控制，区分只读操作与可回滚的写入操作，对第三方 MCP 依赖项进行版本管理，并且把 API 密钥严格隔离在沙箱内，脱离智能体运行环境。归根结底，工程、安全、隐私团队负责验证安全防护机制，但部署审批仍是一项战略性的业务决策。