从模型到智能体：重构三条防御防线
MLOps治理如何与智能体系统对应：三条防线各自需要补充什么，存在哪些缺口，以及欧盟、FDA和金融监管机构发出了哪些信号。
来源: From MLOps to AgentOps: Redrawing the Three Lines of Defense
智能体AI打破了为传统软件和传统模型制定的治理规范，但这一观点在具体案例中才更易显现。在企业和金融服务领域，多年来形成的MLOps实践——包括模型清单管理、验证流程、偏差监控以及审批工作流——在组织采用大语言模型和智能体后并不会被废弃。实际发生的变化比大多数人想象的要更为有限且具体。
想象一下，一个模型风险团队正在处理一份普通的申请。表格中列出了关于训练数据、版本号、审批状态以及上次漂移检测日期的常规问题，而该团队已经处理过大量此类申请。接着出现了系统描述：四个协同工作的智能体，它们之间共享六种工具，检索索引每天都会重新构建，最终结果是由一系列看似都正常的步骤产生的。但表格中的任何内容都无法与这些描述对应上。
2026年麦肯锡开展的AI信任度调查涵盖了约五百家机构，结果也类似：大约三分之一的企业表示其治理水平足以应对当前正在运行的自主智能体。其余企业则继续使用旧的申请表格，希望它已经足够好。但实际上往往并非如此，因此关键任务就是找出其缺陷所在。
现有方案已涵盖的内容
MLOps治理是一系列控制措施，旨在确保传统机器学习模型从训练到退役的全周期都保持可信性。具体包括：
- 模型版本控制，以便明确知晓生产环境中运行的是哪个模型及其原因。
- 漂移监测，用于及时发现输入数据变化导致的模型性能下降。
- 可追溯至训练集和验证集的数据来源追踪。
- 在任何模型投入生产前设置审批流程。
- 遵循适用于所有生产级软件的CI/CD及变更管理规范，这些规范是MLOps治理体系的核心部分，而非独立于其之外的内容。
这些措施无法自动执行，必须有人负责落实每项控制措施，同时还需有人验证责任人是否完成了任务。
责任分配通常通过“三道防线”这一框架来实现，银行及其他受监管行业长期以来一直使用该框架来明确各方职责。需要说明的是：内部审计师协会在2020年将其更名为“三道防线模型”，重点更偏向于创造价值而非单纯的防御功能。尽管官方名称已更改，金融领域和模型风险相关领域仍沿用“三道防线”这一说法，本文也是如此。
在传统的MLOps体系中，责任划分如下：
- 第一道防线涉及产品、数据及工程方面，负责模型的开发、测试、部署及文档编写。
- 第二道防线涉及合规与风险管控，负责制定模型使用政策、监测偏见问题，并在模型上线前对高风险应用进行审查。
这种架构已经十分成熟且被广泛理解，适用于其最初设计的系统，也就是那些结构固定、只需验证一次并在后续审查周期间进行监控的模型。
针对智能体，各项职责需作哪些调整
AgentOps治理同样基于这三项职责，但由于系统行为的不同，每项职责所检查的内容也有所差异。这些差异可归结为五点具体区别。
一个模型变成了多个。传统的做法是针对单个模型进行版本控制。而四智能体系统则是一个整体：基础模型、四个系统提示词、六个工具定义，以及一个按自身节奏更新的检索层。这些组件中的每一个都可能改变系统行为，因此必须对每一部分进行版本控制与测试。这与其说像是一个注册表条目，不如说更像是将提示词和工具结构视为源代码，通过版本控制、拉取请求审核，以及在正式部署前使用保留数据集进行金丝雀测试。仅跟踪模型本身，就会让大约四分之三的行为层面处于无人管理状态。
正确的输出会落在可接受的范围内。将相同的输入交给传统模型，它也会返回相同的输出，这就是验证如此简单的原因。而大型语言模型在不同运行中可能会给出两个不同但都有依据的答案。因此，第二种评估方式不再判断答案是否正确，而是考察答案在大多数情况下是否处于可接受的区间内。这就需要设置明确的阈值作为评估标准，例如在模型发布前要求在标记过的测试集上达到一定的通过率，当模型的置信度或评估分数低于设定下限时则触发人工审核。对于特定应用场景而言，界定“大多数情况下可接受”的标准本身就需要专门的研究，绝非一蹴而就之事。
单一所有者变为链条结构。单个模型进行单独预测时，其所有者显而易见；而由四个智能体组成的系统则不存在明确所有者。当最终结果出错但每一步都正确时，就需要通过决策日志来记录中间传递过程及最终结果：每个智能体的输入、各项决策以及传递的内容。若没有这样的日志，就无从确定哪个智能体应承担责任，事故发生后各方只会争论不休，而无法事先达成一致。
漂移监控并非行为监控。漂移检测是通过将预测结果与已知的基准值进行比较来实现的。它无法了解智能体在运行过程中的具体操作：它调用了哪些工具、采取了何种动作，以及是否始终在指定范围内活动。智能体可观测性平台通过记录完整的执行轨迹——包括工具调用、参数信息，以及一个智能体的输出如何传递给下一个智能体——来弥补这一缺陷。许多此类平台依赖 OpenTelemetry 等开放标准，以确保不同供应商之间的轨迹数据能够相互兼容。对于该系统而言，执行轨迹是审计人员事后重建事件信息的唯一依据。若没有这一轨迹，第三方审计就只能对“黑箱”进行审计，并将其称为独立验证。
日历式的重新训练逐渐转变为持续性的变化。传统模型会按照固定时间表进行重新训练：每月、每季度，或在新数据积累到足够数量时。而基于RAG或持续微调构建的系统，则能随着知识库的更新频繁改变其实际行为，甚至可能每天都会调整。如果检索层每晚更新一次，那么通过季度审查构成的第三层检查频率则比系统实际变化频率低约90倍。
两种程序的交汇点
直接对比来看，这两种程序具有相似的结构。它们都遵循相同的三个步骤，也需要版本控制、测试、审查以及独立审计。两者的区别在于细节程度、频率以及各自所监控的对象。
MLOps治理机制在这里并没有出错。其设计前提是模型在两次审查之间的行为保持稳定，而那种每晚都会重建检索索引的系统根本无法维持如此长的稳定性。所有这五种差异都源于该前提的失效：原本每月才会发生变化的情况现在可能每天都会出现，有时甚至根本没人去调整模型。
要缩小这一差距，并不需要从头构建新的治理功能。只需为现有体系增添它们之前并不需要的功能，并坦诚评估每种功能的成本即可：
- 第一项功能：对提示词和工具进行版本控制，并在推广前进行金丝雀测试。这主要属于工程实践上的改进，而非需要新增团队。
如果想要可靠地查明是哪四个智能体做出了决策，以上各项都不是可选项。
监管机构目前的表态
目前还没有任何单一的监管框架能够完全跟上智能体式人工智能的发展步伐，但来自不同行业的三种现有模型已经展现了未来的发展方向。
- 《欧盟人工智能法案》适用于所有行业。无论其他情况如何，第50条规定的透明度义务均将于2026年8月2日生效。要求更为严格的附件三中的高风险义务最初也定于同一日期实施，但2026年5月已达成原则共识、目前仍在等待正式通过的“数字综合法案”会将这些义务的实施时间推迟至2027年12月。合规时间表应将这一推迟情况标注为待定状态。
- 美国食品药品监督管理局对人工智能驱动的医疗设备的监管是垂直化且以产品为中心的，其核心工具是“预先确定的变更控制计划”。根据该计划，只要后续型号的更新仍在规定的性能范围内，最初的批准即可使其合法化。该监管体系还包含良好的机器学习实践指南，以及逐步向ISO 13485标准靠拢的质量管理体系。实际上，变更控制已成为审批流程的一部分，而非事后附加的义务。
这三份文件均不能直接作为复制模板。综合来看，它们指明了方向：调整预先设定的权限边界、风险等级，以及公开承认现行规则与代理行为之间的不匹配。
返回申请表
现有的申请表可以保留。此外，团队还需要一份针对多智能体系统的独立问卷，该问卷应围绕其现有的三个核心维度来设计，并且要意识到如实作答需要付出实际努力。
哪个环节会首先得到改进？很可能是版本控制，因为它类似于工程师们已经掌握解决方法的版本控制问题。而针对连锁决策的责任界定问题则可能最难解决。这其实是一个披着技术外衣的组织设计问题，仅靠评估环节是无法弥补的。
相关阅读
- 从智能体循环到工作流图：类型化状态、证据门控与有界恢复 —— 为何长时间运行的智能体会超出单个循环的处理能力，以及如何通过明确的节点、边、类型化数据结构、经过验证的转换规则和节点级权限来提升其可靠性。
- 任务智能体的LLMOps实践：基于MLflow的追踪、评估与CI门控 —— 使用FastAPI构建PydanticAI任务助手，通过MLflow进行追踪，借助GenAI评估工具进行性能评分，并在GitHub Actions中防止功能退化，所有操作均在本地模型上完成。