最近读了阿里云云原生公众号的《完整还原已经服务千家企业的 AIOps Agent 的评测和调优实践》，讲的是他们的生产运维 Agent STAROps 怎么构建评测集、怎么用评测结果反过来调优。这篇文章信息密度很高，把其中我认为最值得记的思路整理在这里。
原文：https://mp.weixin.qq.com/s/U3djT_peTic52CdpxEhNeQ （收录于开源项目 Alibaba AI Agent Handbook）
核心观点：结论正确 ≠ 过程可信#
传统评测只看 Agent 最后给出的根因对不对，像考场答题。但一次根因分析实际是「Agent 判断 → 工具取证」的多轮循环，真正的能力藏在这个循环里。文章提出要评三件事：
- 思路是否通用——在一类故障上表现好，换个场景可能就不行，评测集要覆盖足够多的场景才能看出差异；
- 结果错在哪一步——要能对照每一步：调了什么工具、返回了什么、据此做了什么判断；
- 执行效率——有没有无效调用、上下文是否越堆越乱。
还有一类最难发现的错误：时间窗查错。工具调用成功、数据真实、推理自洽，甚至结论碰巧正确——但数据对应的根本不是这次故障的时间段。要抓住这类错误，评测数据必须记录故障的真实时间窗供对照。这是全文反复强调「证据」的由来。
一条评测数据长什么样#
核心要求是能还原一次完整的分析轨迹，而不只是答案。轨迹分五步：目标、观测、工具、动作、结果。轨迹与答案的区别在于：只存答案只能比结论；存了轨迹，才能看出 Agent 在哪一步查错了数据、做错了判断。答案对了也可能是碰巧对的。
除轨迹外，还要一起保存两样东西：
- 配套条件（环境、工具、观测手段）——否则下一个版本的 Agent 跑同一道题时换了环境，结果不可比；
- 核验依据（评价标准）——否则分数变化说不清是 Agent 变了还是判分的人变了。
运维场景还有四个特有约束：环境绑定（故障要在真实服务和流量里发生）、时间绑定（调用链等证据保留期短，要及时保全）、完整因果链（每一步都要有证据）、低频高风险（生产故障不能反复试，用故障注入在评测环境里造出来）。
标准答案的七个字段#
这一节最具体、最有参考价值。一份可核验的标准答案由七个字段组成：
| 字段 | 作用 |
|---|---|
| 根因实体 | 写到具体资源或服务，才能判断定位准不准 |
| 故障类型 | 记录可验证的机制，不是表面现象 |
| 因果链 | 原因、传播、影响分开写，Agent 把传播节点当根因时能看出错在哪 |
| 鉴别点 | 为什么排除了相似候选——答案不仅说明「是什么」，还要说明「不是什么」 |
| 告警锚点 | 实际触发的事件和时间窗，专治时间窗查错 |
| 关键数字 | 必须附上原查询，谁都可以重查一遍 |
| 评分规则 | 按字段独立打分，可以根因对而传播链错 |
其中对数字的要求近乎苛刻：文中有个例子，一条答案写着「错误率约 25%」，人工阅读没发现异常，工具重新查连续五个时间窗的错误数均为零。由此形成的规则是：写不出可执行查询的数字，不能进入标准答案。
构建流程：注入只是其中一步#
一条数据的构建共十二步、四个阶段：设计（Agent 选场景、设计故障）→ 注入与验证（工具执行，必须确认干净基线、验证信号真生效、等告警真触发、恢复环境）→ 取证与写答案（故障期间和恢复后各取一次）→ 检查与入库（程序门禁查规则可判的事，准入复核查需要判断的事）。
两个容易踩的坑值得记下：
- 注入命令执行成功 ≠ 故障发生了。注入完成要逐项证明信号真的出现，包括告警源头对不对、有没有别的变更混进来、异常有没有沿调用链传播出去；
- 噪音干扰直接作废。同一个时间窗里有别人的故障在跑，这次注入的信号就说不清是谁的。
多 Agent 分工与「AI Native」的压力测试#
构建拆给四个 Agent 并行：ScenarioAgent（题目）、EnvironmentAgent（环境）、BuildAgent（构建与复核）、SupervisorAgent（质量监督）。人的位置是三件事：定目标、定验收、终审——这些要结合业务判断，留给人类；逐条构建、逐条核对交给 Agent。值得注意的是：复核时不沿用构建时的上下文，要重新取证据核对，否则复核会顺着已有的答案走。
文章有个很有意思的视角：评测集是用来评 Agent 的，但构建评测集本身也是一项复杂的 Agent 任务，能看出一个组织的 Agent 工程成熟度——它同时考验 Agent 自身能力、Agent 间协同、基础设施（环境可重建、状态保存、失败重试）和治理机制（程序检查、独立复核、人工终审）。
题目从哪来：能力地图 + 线上回流#
两个出题来源：
- 能力地图：横轴是能力域（代码与变更、数据库、容器、中间件、云产品、主机、网络），纵轴是难度（单点故障 → 有传播链 → 多故障并发 → 告警风暴）。纵轴的本质是要排除多少干扰才能定位。空着的格子就是没覆盖的能力，告警风暴那一格是下一批构建任务；
- 线上回流：真实发生过的问题还原成评测数据。顺序很要紧——先保全，再还原，因为调用链这类证据保留期短。机制还原（Agent）→ 等价重放（工具）→ 重建验证（程序比对线上与重放的信号时序）。
评测集本身也要被评测#
入库前合格不代表一直有效，五项检查按短板执行（不能用平均分抵消局部问题）：质量、覆盖、区分度、规模、新鲜度。
最有启发的是区分度：评测集用久了，强弱模型都能拿高分，分数失去区分能力。此时主动提高难度再比较——把简单题换成有传播链的、多故障并发的，看分差能否重新拉开。加难后分数下降不能读成能力退步，是题目变难了。
新鲜度也不能只看数据年龄：基础镜像、告警规则一变，昨天刚建好的数据也可能跑不通。主要看抽样原样重跑，年龄只是辅助。失效数据要下架，否则被评 Agent 答错会被记成能力问题，研发可能去修一个并不存在的缺陷。
成本的诚实提醒#
三项投入（人工、环境、模型调用）的走向：起步靠人工，中期环境投入追上来，后期构建侧模型调用超过人工，而环境成为最高的一块——集群、流量、观测常年在跑。所以用了 Agent，总成本不一定下降，真正减少的是重复的人工操作。文中引用公开研究：自动化流水线构建一条被接受的评测任务约 40 美元、1-2 小时。
我的几点收获#
- 「结论正确不等于过程可信」对任何 Agent 评测都成立，不只运维——评估要从「看答案」转向「看轨迹」；
- 标准答案的质量决定评估上限：七个字段的设计（尤其鉴别点和告警锚点）是可直接借鉴的模板；
- 评测集是活的东西，需要和产品一样持续迭代、检查、下架失效数据；
- 自动化构建评测集本身，就是检验一个团队 Agent 工程能力的试金石。