01有监控不等于能运营
一家保险公司的技术负责人，在接受年度审计时被问到一个问题："你们部署了多少个AI Agent？它们运行状况如何？"他自信地回答："我们有24个Agent在运行，而且我们有Grafana监控面板，每天都有人盯着看。"
审计员追问："当Agent出现质量下滑时，你们能在几分钟内知道吗？你们知道每个Agent处理一个任务平均花费多少钱吗？你们能证明Agent的决策符合合规要求吗？"
沉默。技术负责人意识到，他们有监控工具，但没有运营能力。他们知道服务器在运行，但不知道Agent是否在有效工作；他们知道API成功率，但不知道任务完成质量；他们知道系统没有崩溃，但不知道成本是否可控。
02五个级别的本质差异
AgentOps成熟度的五个级别，对应了五种根本不同的运营思维，而不只是工具的差异。
M1：实验期。典型心态是"能跑就行，出了事人工看日志"。这个阶段通常出现在AI项目的早期，团队专注于功能实现，认为"等稳定了再考虑运营"。问题在于：没有运营能力的系统，永远无法真正稳定——因为没有观测，就无法发现不稳定的真实原因。
M2：监控期。有了Dashboard，有人盯着看。从M1到M2的跃迁，是从"看不见"到"看得见"的转变。这是一个重要进步，但M2的运营本质上是被动的：问题已经发生了，告警响了，人去查。它不能告诉你为什么质量在下滑，也不能告诉你成本的走向。
M3：量化期。这是大多数企业最关键也最困难的跃迁。从M2到M3，是从"看得见"到"量得出"的转变。M3意味着：每个Agent的关键服务指标（SLI）被定义，性能目标（SLO）被设定，每个任务的真实成本（CPTA）可追踪。决策开始基于数据，而不是感觉。
M4：优化期。自动化质量门禁（PRT）上线，Error Budget机制运转。M3是"量得出"，M4是"管得住"——团队不再依赖人工盯着指标，系统能够自动识别质量退化，自动触发告警和响应，自动控制Error Budget的消耗速率。
M5：自治期。Agent自己发现问题并修复，人类只处理异常。这是当前AI运营的前沿方向，多数组织距此还有相当距离，但它代表了AgentOps演进的终极目标。
03五维评估：诊断你在哪里
AgentOps成熟度不是单一维度的，而是五个维度的综合水平决定的。这五个维度分别是：可观测性（能否及时看到系统的真实状态）、指标体系（能否量化系统的服务质量）、自动化水平（能否减少人工干预的比例）、成本优化（能否追踪和控制运营成本）、合规治理（能否证明系统行为符合要求）。
级别判定有明确的规则。M1是五维均处于初级水平，无系统化运营。M2需要可观测性维度达到基本可用，其他维度可以很弱。M3需要同时满足三个条件：可观测性达到规范级、指标体系有SLI/SLO定义、成本追踪可工作。M4要求五维整体达到规范级，且自动化或合规治理中至少一个达到卓越级。M5要求五维全部卓越，且自动化达到满分。
一个常见的陷阱是"伪高级别"：技术工具已经到位，但流程和组织能力没有跟上。团队安装了所有M3需要的工具，但没有人真正看SLO仪表盘，没有人对SLO违反做出响应，没有人基于CPTA数据做成本优化决策——这是M2，不是M3。工具只是手段，运营能力才是成熟度的本质。
04M2到M3：最关键的跃迁
在五个跃迁中，M2到M3是对大多数企业而言最重要也最困难的一步。它要求三种能力同时建立：SLI/SLO体系、CPTA可追踪性，以及自动化告警。
SLI的定义是第一个挑战。一个有意义的SLI必须满足四个条件：用户可感知（指标变化用户能感受到）、可量化采集（有明确的数据来源）、可归因（指标异常能追溯到原因）、可行动（指标异常有明确的应对措施）。许多团队定义的"指标"无法满足这四个条件——它们可能是技术指标（API成功率），而不是业务价值指标（任务真正完成率）。
CPTA（Cost Per Task Achieved，每个业务语义成功任务的成本）的追踪是第二个挑战。它要求准确的成本归因（哪些成本属于这个Agent）和准确的任务成功判断（这个任务是否真正完成了用户意图）。后者往往需要LLM-as-Judge机制，而这个机制本身也需要定期校准。许多企业知道总的AI API费用，但无法回答"这个客服Agent处理一张工单平均花多少钱"。
05不可跳级的逻辑
AgentOps成熟度模型的一个严格规定是：不可跳级，每个级别必须稳固运行至少一个月才能跃迁。这个规定不是人为设置的障碍，而是基于对能力依赖关系的深刻认识。
M4的核心机制——PRT质量门禁和Error Budget管理——建立在M3的量化能力之上。如果SLI没有被准确定义，Error Budget就无从计算；如果CPTA无法追踪，成本预算制就无法运行；如果自动化告警没有建立，质量门禁也只是一张纸。在M3能力尚未稳固的情况下，试图直接跳到M4，最终只会得到一堆空洞的文档和没有人使用的仪表盘。
跳级还会带来另一个危险：团队误认为自己已经达到了更高级别，停止了对基础能力的真实补齐。当压力来临时——例如一次严重的生产事故——才会发现，所谓的"高级别"只是外壳，没有真实的运营能力支撑。
06成熟度会退化
AgentOps成熟度不是一旦达到就永久有效的标签。它会随着时间退化——主要有三个原因：关键人员流失（熟悉系统的工程师离职，运营知识没有传承）、工具版本迭代（监控系统升级后，原有的告警规则失效，但没有人注意到）、业务快速变化（新功能上线后，原有的SLI定义不再适用，但没有人更新）。
这意味着成熟度评估不是一次性工作，而是需要每季度复评的持续活动。复评的意义不在于给组织打分，而在于识别退化的信号：上次评估后，哪些维度的实际执行情况有所下滑？哪些工具仍在运行但已经无人关注？哪些流程被绕过了？
本章开头的那家保险公司，在梳理现状后诊断自己处于M2级别。他们花了12周推进到了M3——建立了5个核心SLI、设定了SLO目标、实现了CPTA的任务级别追踪。这12周的投入，让他们在下一次审计中能够清晰地回答那三个问题。更重要的是，他们第一次真正"了解"了自己的AI系统在做什么，花了多少钱，为用户创造了多少价值。
01一个普遍存在的现象
几乎所有企业在部署智能体系统之后，都会经历一段"蜜月期"：系统跑起来了，指标看起来不错，用户反馈积极，团队对成果感到满意。
然后，在某个普通的工作日，一些事情开始出错。可能是某个智能体开始以一种难以解释的方式产生低质量输出，可能是某个关键业务场景的成功率悄悄下滑，可能是成本指标在没有明显原因的情况下异常攀升。
团队开始追查，但发现自己没有足够的数据来定位问题——因为从一开始，就没有建立系统性的监控和分析机制。他们凭着对系统的直觉和对日志的手动翻查，几天后找到了一个可能的原因，修复了它，然后继续等待下一次类似的问题。
这不是个别团队的特殊遭遇，而是运营成熟度停留在低级别的系统性表现。
02为什么智能体运营需要独立的成熟度框架
软件运营领域有一套成熟的能力评估体系——从 CMMI 到 SRE 实践，这些框架已经帮助无数企业系统性地提升了软件系统的运营质量。
智能体系统的运营，在几个关键维度上和传统软件运营有根本性的不同，这些不同导致传统框架不能直接套用：
第一，智能体的"好"和"坏"更难测量。传统软件的运营质量，主要体现在可用性、延迟和错误率上。智能体的输出质量是主观的、概率性的、多维度的，任何单一指标都不能完整描述其运营状态。
第二，智能体系统的退化模式是渐进的而非突发的。传统软件通常以"正常运行 / 崩溃"两种状态存在。智能体系统更常见的退化模式，是输出质量的缓慢下滑、成功率的渐进降低——这种退化在早期几乎不可见。
第三，智能体运营需要持续的人类判断介入。传统软件运营可以高度自动化。智能体运营在很多关键节点上，仍然需要人类判断——输出质量的评估、边界情况的处理、模型更新后的重新校准。
本框架创新：针对智能体系统的概率性输出和渐进退化特征，构建专属五级运营成熟度模型，将 SRE 的"Error Budget"概念引入智能体质量管理，提出 M3 → M4 的跃迁条件作为规模化生产的关键门槛判断。
03五级运营成熟度
AgentOps 描述的是一个企业从"几乎没有运营能力"到"系统可以自我优化"的完整演进路径。
M1 · 实验级（Experimental）：运营靠感觉。没有系统性的监控，问题发现依赖用户投诉或人工观察，处理依赖个人经验。这是绝大多数企业在智能体系统上线初期的真实状态，也是大量企业在系统运行了相当长时间之后仍然停留的状态。
M2 · 可监控级（Observable）：建立了基础监控，有日志和告警，可以在问题发生后追溯。但监控覆盖的是基础技术指标（响应时间、错误率），没有系统性的质量指标追踪，问题发现依然滞后，没有量化的质量基准。
M3 · 可量化级（Measurable）★：建立了系统性的质量评估体系，有 SLI（服务级别指标）和 SLO（服务级别目标），能够持续追踪关键业务指标，有明确的质量基准和退化预警机制。
M3 是智能体系统从"实验性产品"到"生产级系统"的关键分水岭。没有达到 M3，智能体系统实际上还处于持续的探索状态，不具备稳定的价值交付能力。
M4 · 可优化级（Optimizable）：建立了基于数据的持续优化循环。不只是发现问题，而是能够主动识别优化机会，有自动化的质量门禁（未达标的变更自动被阻止发布），有 Error Budget 管理机制，有系统性的根因分析能力。
M3 到 M4 的跃迁，是大多数企业里最难迈过的一步，因为它要求把质量保障从"事后响应"重构为"前置防护"。
M5 · 自治级（Autonomous）：系统可以自我监控、自我评估、自我优化，在预设的边界内不需要持续的人工干预。人类的角色从"运营者"变成"系统设计者和边界定义者"。这是大多数当前企业的长期目标，而非近期可达的现实。
04M3 到 M4：那道最难跨越的门槛
在实践中，M3 和 M4 之间的差距，常常比它们在描述上看起来的要大得多。
M3 意味着：你知道系统现在的状态。M4 意味着：你的系统会主动阻止退化，而不是等你发现退化之后再处理。这个差距，需要两套机制支撑。
第一套是自动化质量门禁：每次代码变更、模型更新或配置修改，都必须通过自动运行的评测集检验，如果任何关键指标退化超过阈值，变更被自动阻止，而不是等上线后发现问题再回滚。这要求评测集足够完善、评测速度足够快、阈值设置足够合理。
第二套是 Error Budget 管理：为每个关键质量维度设定允许的退化预算，当某个维度的预算耗尽，强制暂停该方向的迭代工作，专注于质量修复。这要求团队在"快速迭代"和"保护质量预算"之间建立明确的优先级规则——这是一个需要管理层参与认可的文化和制度变革，不只是技术建设。
05这个框架揭示的底层逻辑
AgentOps 揭示的，是智能体系统的运营质量和业务价值之间存在一个时间滞后的强相关。
运营成熟度低的系统，在短期内可能感觉不出问题——系统在跑，用户在用，看起来还不错。但随着时间推移，那些未被系统性追踪的质量退化会积累，那些未被及时发现的边界案例会扩散，那些缺乏系统性根因分析的问题会反复出现。
运营成熟度是一种复利效应的能力——高成熟度的团队，每次出现的问题都在系统性地减少，每次修复都在让系统更强壮；低成熟度的团队，每次出现的问题在重复，每次修复只是临时止血，问题会以不同的形态在不同的时间再次出现。
这个复利效应，在系统运行的第一年并不明显，在第二年开始分化，在第三年会产生难以弥合的差距。
T1理论来源与学术引证
以下为本框架的理论基础说明，提炼自正文中的理论注释块。
本框架创新：针对智能体系统的概率性输出和渐进退化特征，构建专属五级运营成熟度模型，将 SRE 的"Error Budget"概念引入智能体质量管理，提出 M3 → M4 的跃迁条件作为规模化生产的关键门槛判断。
T2框架定位与适用边界
本框架是管理实践工具，为高管和研究者提供结构化分析视角，不提供可直接验证的因果预测。其有效性依赖于：分析者对所在行业的深度认知、可获取的组织数据质量、以及将分析结论与具体决策场景相结合的能力。
智能体时代的框架有一个共同的时效性问题——AI 技术演化速度快于传统战略框架的更新周期。建议每 12–18 个月对本框架的核心假设进行一次复盘，检视其前提条件是否仍然成立。