Agent能力成熟度模型
1. 定义与边界
Agent 能力成熟度模型用于评估一个团队从“能调用模型”到“能稳定上线 Agent 系统”的工程能力。它不是模型智商排行,也不是产品宣传分级,而是围绕自主性、工具能力、状态管理、评测、安全和运维的工程成熟度分层。
2. 为什么重要
Agent 项目失败常不是模型完全不行,而是团队过早开放自主性:
- 没有 eval baseline 就上线。
- 没有 trace 就无法定位失败。
- 工具 schema 和权限混乱。
- 状态不可恢复,失败后只能重跑。
- 高风险动作没有人工审批。
成熟度模型的价值是把“能 demo”与“能生产”区分开。
3. L0-L5 模型
| 等级 | 名称 | 能力状态 | 典型系统 |
|---|---|---|---|
| L0 | LLM 辅助 | 单轮或多轮生成,无行动能力 | 文案生成、摘要 |
| L1 | 工具增强 | 可调用少量只读工具,流程仍由代码控制 | RAG 问答、查询助手 |
| L2 | 受控 Agent | 单 Agent loop,有限工具,明确退出条件 | 客服工单、数据分析助手 |
| L3 | 生产 Agent | 持久状态、trace、evals、HITL、权限分级 | 编程 Agent、运营处理 Agent |
| L4 | 组织级 Agent 平台 | 多 Agent/多工作流复用,统一治理和观测 | 企业 Agent 平台 |
| L5 | 自优化 Agent 组织 | 持续评测、策略自动推荐、工具生态治理、跨团队 SLO | 大规模企业 Agent 操作系统 |
L5 不是“完全无人管”,而是组织已经具备系统化反馈闭环:线上 trace 能回放为 eval,失败模式能自动归类,工具和策略变更有影响分析,安全策略由平台强制执行,人仍保留高风险责任边界。
4. 维度评分表
| 维度 | L0 | L1 | L2 | L3 | L4 | L5 |
|---|---|---|---|---|---|---|
| 任务边界 | 提示词描述 | 固定场景 | 明确目标和退出条件 | 任务契约化 | 任务目录与准入机制 | 任务组合、依赖和影响分析 |
| 工具能力 | 无 | 只读查询 | 少量读写工具 | 风险分级、幂等、审批 | 工具注册中心与版本治理 | 工具质量评分和自动退役 |
| 状态管理 | 聊天历史 | 临时上下文 | 任务状态对象 | 持久化、恢复、摘要 | 统一状态/记忆服务 | 跨任务记忆治理和污染检测 |
| 编排 | 单次调用 | 固定 workflow | Agent loop | 图/队列/人类在环 | 跨 Agent 编排平台 | 多团队自治编排和全局限流 |
| 评测 | 人工抽查 | 问答集 | 任务集 + 工具准确率 | 轨迹评测 + 回归 | 持续评测与线上实验 | 失败自动入库、策略自动建议 |
| 安全 | 内容过滤 | 基础权限 | 工具白名单 | 最小权限、审计、红队 | 组织级策略引擎 | 持续红队、供应链和策略漂移检测 |
| 运维 | 无 | 日志 | trace | 成本/延迟/失败监控 | SLO、容量、治理报表 | 业务价值、风险和成本联合优化 |
5. 组织能力要求
成熟度不是单个工程师把 loop 写复杂,而是组织能力同步提高。
| 等级 | 组织能力 | 最低责任人 |
|---|---|---|
| L0 | Prompt 模板管理、人工抽查 | 业务 owner |
| L1 | 数据源 owner、只读工具 owner、RAG 质量 owner | 应用负责人 |
| L2 | Agent 任务 owner、工具 owner、安全审批 owner | 产品 + 后端 + 安全 |
| L3 | Eval owner、Trace owner、灰度发布 owner、HITL 运营 owner | 平台/业务联合小组 |
| L4 | 工具注册、策略引擎、统一观测、跨团队治理 | Agent 平台团队 |
| L5 | 组织级 eval 资产、红队体系、成本与风险委员会 | 技术委员会/治理委员会 |
6. 升级条件
L0 到 L1
升级前提:
- 明确模型需要访问哪些外部数据。
- 能把数据访问封装为只读工具。
- 能评测检索和回答质量。
不要升级的情况:
- 只是想让回答“更像内部专家”,但没有数据源和任务闭环。
L1 到 L2
升级前提:
- 任务不是固定一步,存在需要模型判断的工具选择。
- 每个工具有 schema、错误码和测试样例。
- 有最大步数、超时和失败升级。
不要升级的情况:
- 固定查库后回答即可,用 RAG 或 workflow 更稳定。
L2 到 L3
升级前提:
- 有离线 eval dataset 和回归流程。
- 记录完整 trace 和工具结果。
- 高风险动作有人类审批。
- 状态可恢复,工具尽量幂等。
不要升级的情况:
- 还无法解释失败来自模型、工具、数据还是权限。
L3 到 L4
升级前提:
- 多团队复用 Agent 能力。
- 工具、策略、评测、观测需要平台化。
- 有统一的安全、合规和成本治理。
不要升级的情况:
- 只有一个业务 Agent,平台化会过早抽象。
L4 到 L5
升级前提:
- 多个业务线已经通过统一平台运行 Agent。
- 线上 trace、人工反馈、事故复盘能自动转化为评测样本候选。
- 工具、策略、模型、提示词变更都有回归和影响分析。
- 有跨团队 SLO、风险预算、成本预算和安全红队节奏。
不要升级的情况:
- 平台还主要靠人工巡检,失败样本不能自动闭环。
- 缺少业务价值度量,只是在追求更高自主性。
7. 工程实现模板
成熟度可以落到配置与准入清单:
agent:
name: customer_refund_agent
maturity_target: L3
owner: support-platform
task_contract:
goal: 判断退款资格并创建退款申请
exit_conditions:
- refund_request_created
- policy_not_matched
- human_escalated
max_steps: 8
timeout_seconds: 90
tools:
- name: get_order
risk: low
permission: read
- name: read_refund_policy
risk: low
permission: read
- name: create_refund_request
risk: medium
permission: write
idempotent: true
- name: issue_payment
risk: high
permission: write
requires_human_approval: true
evals:
dataset: evals/refund_agent_v1.jsonl
min_task_success_rate: 0.85
max_policy_violation_rate: 0.00
observability:
trace_required: true
log_tool_args: redacted
release_gates:
shadow_min_runs: 200
assisted_min_runs: 100
max_human_override_rate: 0.20
rollback_on_policy_violation: true
8. 上线门槛
| 目标级别 | 允许上线形态 | 最低门槛 |
|---|---|---|
| L1 | 内部只读助手 | 数据源权限明确,回答有引用,禁止写工具 |
| L2 | 小流量受控 Agent | max steps、工具 schema、失败升级、基础 trace |
| L3 | 生产 Agent | 离线 eval 达标,100% trace,高风险 HITL,灰度和回滚 |
| L4 | 企业平台 | 工具注册中心、统一策略、统一观测、跨团队权限治理 |
| L5 | 自优化组织 | 线上反馈自动进入 eval 候选,策略变更可回归,持续红队 |
9. 生产实践
| 实践 | 对应成熟度 | 说明 |
|---|---|---|
| 只读灰度 | L1-L2 | 先让 Agent 建议,不执行写操作 |
| Shadow mode | L2-L3 | 与人工或规则系统并行运行,不影响结果 |
| 回放评测 | L3 | 用线上失败 trace 构造回归样本 |
| 工具风险分级 | L2-L4 | 读、可回滚写、不可回滚写、资金/合规动作分层 |
| 统一 trace schema | L3-L4 | 支持跨 Agent 比较和审计 |
| 策略即代码 | L4 | 权限、审批、脱敏、模型路由统一配置化 |
| 自动失败入库 | L5 | 从线上异常、人工拒绝、红队样本生成回归候选 |
10. 常见反模式
| 反模式 | 常见等级 | 后果 | 修正 |
|---|---|---|---|
| L0 阶段承诺端到端自动化 | L0-L1 | 业务预期超过系统能力 | 明确只读/建议态边界 |
| 没有工具测试就调 prompt | L1-L2 | 错误被归因到模型,实际是工具契约问题 | 先做工具单测和 schema 校验 |
| L2 没有最大步数和失败升级 | L2 | 死循环、重复操作、用户等待 | 加 max_steps、timeout、escalation |
| L3 没有线上 trace 回放 | L3 | 线上失败无法复现 | 统一 run/span schema 和回放工具 |
| L4 平台先行 | L3-L4 | 抽象过早,业务 Agent 仍不可用 | 先沉淀 2-3 个稳定业务模式 |
| L5 追求完全自动自治 | L5 | 高风险责任边界消失 | 保留人类审批、红队和治理委员会 |
11. 评测方法
成熟度验收建议:
| 指标 | L2 门槛 | L3 门槛 |
|---|---|---|
| Task Success Rate | 有基线 | 达到业务阈值并可回归 |
| Tool Call Accuracy | 统计关键工具 | 覆盖所有工具和参数 |
| Policy Violation Rate | 人工抽查 | 自动检测 + 0 容忍红线 |
| Trace Coverage | 记录主要步骤 | 100% 模型/工具/审批 span |
| Human Escalation | 有手动入口 | 有触发条件和审计 |
| Cost per Task | 粗略估算 | 持续监控和预算告警 |
L4-L5 还需要组织级指标:
| 指标 | 说明 |
|---|---|
| Eval Freshness | 评测集是否覆盖最近线上失败和业务变化 |
| Tool Quality Score | 工具错误率、参数失败率、文档清晰度 |
| Policy Drift Rate | 策略变更后违规样本是否增加 |
| Cross-team Incident Rate | 一个团队的工具或策略是否影响其他团队 |
| Value per Cost | 每单位成本带来的业务节省或质量提升 |
12. 安全与治理
成熟度越高,自主性越高,治理要求越高:
- L1:重点防止错误检索和数据泄露。
- L2:重点防止工具误用、循环失控、越权读取。
- L3:重点防止不可逆动作、提示注入、审计缺口。
- L4:重点防止平台级供应链风险、策略漂移、跨团队权限扩散。
- L5:重点防止自动优化系统把错误反馈固化为组织级策略。
每次升级都应经过安全评审、红队样本、失败回放和灰度计划。
13. 权威资料
- OpenAI, A practical guide to building agents: https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/ (核对日期:2026-05-09)
- OpenAI Agents SDK docs: https://openai.github.io/openai-agents-python/ (核对日期:2026-05-09)
- Anthropic, Building effective agents: https://www.anthropic.com/engineering/building-effective-agents (核对日期:2026-05-09)
- Anthropic, Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents (核对日期:2026-05-09)
- LangGraph durable execution / persistence / interrupts: https://docs.langchain.com/oss/python/langgraph/overview (核对日期:2026-05-09)
- OpenAI Evals guide: https://platform.openai.com/docs/guides/evals (核对日期:2026-05-09)
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework (核对日期:2026-05-09)
- OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/ (核对日期:2026-05-09)