北京
基础设施监控一片绿，业务指标却已经崩了。这是InfoQ一场线上研讨会里，几位一线工程负责人反复提到的一类事故。
这场讨论的主题是「AI进生产：什么会坏、什么管用、谁来批准」。主持人是Hien Luu，参与者包括ThoughtWorks的Zichuan Xiong和Prem Chandrasekaran、隐私方向专家Katharine Jarmul，以及金融AI从业者Lan Chu。
Luu开场就点了三个核心变化：AI的失败方式和传统软件不一样，它不会崩溃，而是生成看起来很像真的错误内容；编码智能体产出生产代码的速度，已经超过人类审查的速度；敏感数据有了新的泄露出口——提示词、上下文窗口，以及被检索到的文档。
看不见的漂移
Xiong是ThoughtWorks托管服务的AI运维负责人，他提到LLM流水线里普遍存在的「语义漂移」。他举了text-to-SQL翻译智能体的例子：这类智能体经常把领域特有的概念压平，比如在销售和客户支持两个域里，把「member」当成同一个东西处理，结果在下游业务分析里产生细微、隐蔽的错误，而标准的链路追踪根本发现不了。
Chu讲了一个更严重的案例，发生在金融合规系统里，起因是「嵌入漂移」。他们部署了一个智能体，用向量相似度阈值来拦截被禁止的投资建议。后来底层嵌入模型做了一次没有公告的后台更新，向量距离分布随之改变。线上流量里误报和漏报同时飙升，而所有基础设施健康检查依然是全绿的。
Chandrasekaran补充了RAG流水线的风险：它可能无意中检索到敏感文档。Jarmul则指出，模型本身会记住训练数据，可以被用来去匿名化信息，或者暴露API密钥。Chandrasekaran还提到了GitSpawn漏洞——恶意的仓库配置能在日常命令执行过程中运行未授权代码。
人审不过来，怎么办
编码助手产出的生产代码量越来越大，传统的人工代码审查流程顶不住了。Chandrasekaran是ThoughtWorks的技术与商业服务负责人，他强调逐行人工审查没法跟上智能体的产出速度。工程团队应该把战术性的风格和语法检查自动化，放进CI/CD流水线，人工监督只保留给高层架构、业务意图和非功能性需求。
Xiong补充说，团队要左移，在拉取请求生成之前，就在harness层面评估意图。Chandrasekaran还提到变异测试正在回归：通过故意引入代码变异，团队可以验证自动化测试套件到底是在检验底层逻辑，还是只满足了表面的代码覆盖率指标。
在评估智能体系统时，Chu强调评估必须被当作永久存续的基础设施，而不是发布前的静态清单。有效的评估需要span级别的持续在线追踪、日志过滤，并用LLM对失败模式做分类，把生产环境里的边缘案例系统性地喂回离线基准测试集。
隐私和安全方面，Jarmul提醒不要依赖提示词工程来做系统防御。她主张系统化的红队测试、持续的威胁建模、为自主智能体定义严格的功能边界，以及扩展可观测性来应对增长的事件量。
为了限制自主智能体行为的爆炸半径，Chandrasekaran建议把每个AI智能体当成一名新入职的工程师来对待：给智能体独立的非人类身份，实施分层访问控制，区分只读操作和可回滚的写操作，对第三方Model Context Protocol（模型上下文协议）依赖做版本管理，并把API密钥严格隔离在智能体运行时环境之外的沙箱里。
工程、安全和隐私团队负责验证安全护栏，但最终是否上线的批准，仍然是一个战略性的商业决策。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
