生产环境AI：语义漂移、嵌入漂移与Agent治理

在最近一场题为“生产环境中的AI：什么会出问题、什么行之有效，以及由谁批准？”的InfoQ网络研讨会上，一组资深工程实践者齐聚一堂，深入剖析部署智能体系统在现实世界中面临的运营挑战。讨论由Hien Luu主持，参与嘉宾包括Zichuan Xiong和来自ThoughtWorks的Prem Chandrasekaran、隐私专家Katharine Jarmul，以及金融AI实践者Lan Chu。Luu在开场时指出了三个核心驱动因素：AI的失败方式与传统软件不同，它生成的是令人信服的不准确信息，而不是崩溃；编码智能体生成生产代码的速度超过了人类审查的速度；敏感数据有了新的泄露途径，可通过提示词、上下文窗口和检索文档泄露。

Xiong是ThoughtWorks托管服务AI运营负责人，他强调了LLM流水线中普遍存在的“语义漂移”问题。他描述了文本到SQL翻译智能体如何经常将领域特定概念压平，例如在销售和客户支持领域将“成员”同等对待，导致下游业务分析中出现微妙的隐藏错误，而这些错误能通过标准追踪。类似地，Chu讲述了金融合规系统中由“嵌入漂移”引起的一次严重故障。在部署了一个基于向量相似度阈值来阻止违禁投资建议的智能体后，底层嵌入模型的一次未通知的后台更新改变了向量距离分布。这在实时流量中造成了严重的假阳性和假阴性激增，而所有基础设施健康检查却完全显示正常。此外，Chandrasekaran强调了RAG流水线如何可能无意中检索到敏感文档，而Jarmul指出模型天生会记忆训练数据，可被用于去匿名化信息或暴露API密钥。Chandrasekaran还提到了GitSpawn漏洞，展示了恶意仓库配置如何在日常命令执行期间运行未授权代码。

随着编码助手生成越来越多的生产代码，传统的人工代码审查流程面临不可持续的瓶颈。ThoughtWorks技术与业务服务负责人Chandrasekaran强调，逐行人工代码审查无法与高速的智能体输出同步扩展。相反，工程团队必须在CI/CD流水线中自动化战术性的风格和语法检查，将人工监督严格保留给高层架构、业务意图和非功能性需求。Xiong补充说，团队必须左移，在生成拉取请求之前就在框架层面评估意图。Chandrasekaran还强调了变异测试作为一种必要实践的复兴。通过引入刻意的代码变异，团队可以验证自动化测试套件是否真正评估了底层逻辑，还是仅仅满足了表面层面的代码覆盖率指标。在评估智能体系统时，Chu强调评估必须被视为永久的、活的基础设施，而不是静态的发布前检查清单。有效的评估需要在跨度层面进行持续的在线追踪、日志过滤，并使用LLM对失败模式进行分类，使团队能够将生产环境中的边缘案例反馈到离线基准测试套件中。

在评估智能体系统时，Chu强调评估必须被视为永久的、活的基础设施，而不是静态的发布前检查清单。有效的评估需要在跨度层面进行持续的在线追踪，使团队能够捕获真实世界的用户交互模式，并系统地将生产环境中的边缘案例反馈到离线基准测试套件中。

为了应对隐私和安全风险，Jarmul告诫不要依赖提示词工程来防御系统。她提倡系统化的红队测试、持续的威胁建模、为自主智能体定义严格的功能范围，并扩展可观测性以处理扩展的事件量。为了限制自主智能体行动的爆炸半径，Chandrasekaran建议将每个AI智能体视为一名新的工程雇员。组织应授予智能体独特的非人类身份，实施区分只读操作与可逆写操作的分层访问控制，对第三方模型上下文协议（MCP）依赖进行版本管理，并将API密钥严格隔离在智能体运行时环境之外的沙箱中。最终，虽然工程、安全和隐私团队验证安全护栏，部署批准仍然是一项战略性的业务决策。

为了限制自主智能体行动的爆炸半径，Chandrasekaran建议将每个AI智能体视为一名新的工程雇员。组织应授予智能体独特的非人类身份，实施区分只读操作与可逆写操作的分层访问控制，对第三方模型上下文协议（MCP）依赖进行版本管理，并将API密钥严格隔离在智能体运行时环境之外。最终，虽然工程、安全和隐私团队必须验证安全护栏，部署批准仍然是一项战略性的业务决策。