智能體評估報告為何要拆成兩欄：結果與能力背離

简介： 过程感知评测强调：智能体评估不能只报成功率（如0.71 vs 0.70），必须并列呈现“结果分”与“能力诊断”（工具使用、记忆、规则遵循、协同四维）。arXiv:2610.09872指出，仅看结果会掩盖能力真相——高分可能源于环境顺风而非真实能力。双栏报告让“结果与能力背离”浮出水面，助防上线后塌房。

上线前那版评估报告摊在桌上，两个候选智能体并排：同一个成交任务集，A 版成功率 0.71，B 版成功率 0.70，差一个点不到。评审问「选哪个」，有人指着 0.71 说它高一点，可这一栏就是全部依据——这正是过程感知评测要拦下来的场景。直到有人追一句「那它们各自是怎么做到这个数的」，会场没人接得住。做自动化测试出身的人对此最眼熟：给传统系统写报告，最怕只交一列通过率却不交过程。过程感知评测（process-aware evaluation）要补的就是这块：一份合格的智能体评估报告不能只报结果分，还得并一栏能力机制诊断，把结果和能力拆开摆，让「结果与能力背离」这种行浮上来。今年十月那篇讲持续型智能体评测的论文（据 arXiv 2610.09872 学术评测，2026-10-07 提交 cs.AI/cs.CL）把这句话写成了论点：Evaluating agents by outcomes alone can obscure the capabilities that produce them——只看结果去评一个智能体，会把它凭什么拿到这个结果的能力给遮掉。

只看结果榜，会漏掉什么？

先摆定义。结果分（realized outcomes）是智能体跑完之后对上的判定：任务成没成、拿到多少、用了几步。能力诊断（mechanism-specific diagnostics）是从完整决策轨迹里反推出来的分项：工具调用用得准不准、跨轮记忆连不连得上、规则有没有真守住、多智能体协同时有没有拖。过程感知评测说的就是这两栏一起报，而不是让结果栏单独签字。原子事实第一条：据 arXiv 2610.09872 学术评测，LiveMACEBench 同时评估 realized outcomes 与从完整决策轨迹导出的 mechanism-specific diagnostics，两栏并列而非取其一来下结论。

只看结果榜漏掉的，恰恰是最贵的那类风险。两个成功率一样的智能体，一个四维诊断都在基线上，另一个「工具使用」这一维诊断明显偏弱、靠的是任务本身宽松或环境顺风把结果顶了上来——结果榜上它俩平手，一旦换个严格点的环境，弱的那一维会先塌。这就是「结果与能力背离」：结果这个数没问题，出问题的是「它配不配得上这个数」。一份只报结果分的报告，遇到这种行等于没设防。

静态一次性跑分，和跨 run 演化环境差在哪？

传统评估是「静态一次性跑分」：一份固定测试集、跑一遍、出一个数。过程感知评测要的是另一件事——把智能体扔进一个会随时间变化的环境里连续跑，看能力在轨迹上怎么漂。据 arXiv 2610.09872 学术评测，LiveMACEBench 用实时金融市场作为持久智能体的演化测试台，让五个前沿大模型在连续轨迹上跑，并按 Tool Use、Persistent Memory、Rule Following、Multi-Agent Collaboration 四类配置做匹配对齐；跨 30 天观察到显著的「outcome-capability gap」，也就是相似的结果可能来自差别很大的底层能力。原子事实第二条：据 arXiv 2610.09872 学术评测，该评测在跨 30 天的演化环境里发现 outcome-capability gap，相似结果可源自差别很大的底层能力，这正是只看一次性跑分会漏掉的信号。

差别不在「跑得多不多」，而在「一个数能不能代表能力」。静态跑分里，一次顺风就能把结果顶上去，你只有一个数、没有轨迹，无从判断这是稳还是巧。演化环境里，同一个候选被反复放到变动的行情里，结果栏和能力栏的错位会在一串 run 上摊开——某一维一直虚，结果却一直好，背离行自己就会浮出来。这就是为什么报告结构要预留两栏：不是多此一举，是让「换个环境会不会塌」这个问题有处可查。

结果与能力背离，在报告里长什么样？

把它落到一张表上最直观。假设一批候选 run 里，样本-Bravo 结果 0.70，和样本-Alpha 的 0.71 差一个点，只看结果榜你几乎会选 Alpha 但其实两者都过关；并上能力栏就会发现，Bravo 的「工具使用」诊断掉到 0.31，结果能到 0.70 极可能是这批任务对工具调用要求不高、环境顺风把它顶上去的——这种行，报告要主动点名，而不是等上线后塌了再回头查。反过来样本-Charlie 结果只有 0.58，但四维诊断没一维崩，那是能力都在、任务本身难，属于诚实的低分，不该和 Bravo 那种「高分但有一维塌」混为一谈。

背离判定的关键，是别把「结果好」直接等同于「能力强」。结果栏负责对外签字——能不能上、够不够格；能力栏负责对内归因——凭什么够格、哪里还虚。两栏各干各的活，混在一张宽表里，评审的眼睛会自动扫最右那列排序，其余全白写。原子事实第三条：据 arXiv 2610.09872 学术评测，四类配置为 Tool Use / Persistent Memory / Rule Following / Multi-Agent Collaboration，评测同时给出结果与机制诊断，以便对「结果相近、能力不同」的候选做出区分。

报告怎么拆成两栏：一段可跑的示例

业务场景就一句：上线评审要把一批候选 run 的评估结果做成报告，既给结果栏，也给能力栏，还要自动标出「结果好但某能力诊断弱」的背离行，免得评审被一个 0.71 带偏。下面这段 Python 把一个 run 集拆成两张表并列输出，末尾专列背离行。注意：表里的样本名、成功率、四维诊断分全是构造示例，只演示「两栏并列 + 背离标注」这套报告骨架。

# dual_track_report.py —— 智能体评估：结果栏与能力栏并列，标出「结果与能力背离」的行
# 说明：以下样本名、成功率、四维诊断分全为构造示例，仅演示报告骨架，非任何真实模型成绩。
CAPS = ["tool_use", "memory", "rule_follow", "collab"]  # 论文口径四维，非行业标准

# 一次评估 run 集（构造数据）：outcome = 结果栏（成功率 0~1），caps = 能力栏（机制诊断 0~1）
RUNS = [
    {
   "agent": "样本-Alpha",  "outcome": 0.71,
     "caps": {
   "tool_use": 0.73, "memory": 0.68, "rule_follow": 0.77, "collab": 0.70}},
    {
   "agent": "样本-Bravo",  "outcome": 0.70,
     "caps": {
   "tool_use": 0.31, "memory": 0.66, "rule_follow": 0.72, "collab": 0.69}},
    {
   "agent": "样本-Charlie", "outcome": 0.58,
     "caps": {
   "tool_use": 0.60, "memory": 0.55, "rule_follow": 0.62, "collab": 0.44}},
]

OUTCOME_GOOD = 0.65   # 结果「好」的构造阈值
CAP_WEAK = 0.50       # 能力诊断「弱」的构造阈值

def diverging(r):
    """结果达标，但存在某一维诊断偏弱 → 判为结果与能力背离。"""
    weak = [c for c in CAPS if r["caps"][c] < CAP_WEAK]
    return weak if r["outcome"] >= OUTCOME_GOOD and weak else []

def render():
    out = ["## 结果栏（realized outcomes）", "", "| 样本 | 成功率 |", "|---|---|"]
    out += [f"| {r['agent']} | {r['outcome']:.2f} |" for r in RUNS]
    out += ["", "## 能力栏（mechanism-specific diagnostics）", "",
            "| 样本 | " + " | ".join(CAPS) + " |", "|---|" + "---|" * len(CAPS)]
    for r in RUNS:
        cells = " | ".join(f"{r['caps'][c]:.2f}" for c in CAPS)
        out.append(f"| {r['agent']} | {cells} |")
    out += ["", "## 结果与能力背离（结果达标，下列维度诊断偏弱）", "",
            "| 样本 | 成功率 | 背离维度 | 报告提示 |", "|---|---|---|---|"]
    for r in RUNS:
        weak = diverging(r)
        if weak:
            out.append(f"| {r['agent']} | {r['outcome']:.2f} | {', '.join(weak)} | 高分疑似顺风，换严环境会先塌 |")
    return "\n".join(out)

print(render())

## 结果栏（realized outcomes）
| 样本 | 成功率 |
|---|---|
| 样本-Alpha | 0.71 |
| 样本-Bravo | 0.70 |
| 样本-Charlie | 0.58 |

## 能力栏（mechanism-specific diagnostics）
| 样本 | tool_use | memory | rule_follow | collab |
|---|---|---|---|---|
| 样本-Alpha | 0.73 | 0.68 | 0.77 | 0.70 |
| 样本-Bravo | 0.31 | 0.66 | 0.72 | 0.69 |
| 样本-Charlie | 0.60 | 0.55 | 0.62 | 0.44 |

## 结果与能力背离（结果达标，下列维度诊断偏弱）
| 样本 | 成功率 | 背离维度 | 报告提示 |
|---|---|---|---|
| 样本-Bravo | 0.70 | tool_use | 高分疑似顺风，换严环境会先塌 |

为什么这么写：三处是刻意的。第一，两张表分开印，而不是拼成一张超宽表——结果栏是签字用的，能力栏是归因用的，一旦合并，评审只看最右那列排序就散会了，背离行永远轮不到被看。第二，diverging 单独成段而不是塞进主循环，为的是让「背离判定」这层业务规则能独立调整、独立复核。第三，Charlie 结果低但四维都在，不会被误标成背离——背离专抓「高结果 + 弱某维」，不抓「诚实的低分」，这个区分写反了，报告就会把最老实的候选当成问题样本毙掉。踩过的坑有两个：OUTCOME_GOOD / CAP_WEAK 是硬编码构造值，别照抄上线，不同任务集的结果分布差很远，阈值要按你们历史 run 的分位数定，否则要么满屏告警、要么一个都不报；另一个坑是能力栏那四维的分怎么来——示例里直接填了现成数字，真实项目里它得从完整决策轨迹反推（工具调用命中率、跨轮记忆命中、规则违例计数、协同延迟），这一步没做，能力栏就是空有骨架的假表，比没有更危险。

边界：这套双栏报告不解决什么

第一，LiveMACE 是金融市场的学术评测，四维是这篇论文自己的口径，不是行业标准；换到软件测试或你们业务环境，维度得重设，别把 tool_use/memory/rule_follow/collab 当通用模板照搬。第二，本文不引用也编不出任何具体收益数字、模型排名或能力分——摘要层未给，正文与示例里的所有数都是构造，只能说明报告结构，不能外推成「接入双栏报告后 flaky 或收益变化了多少」。第三，结果与能力背离是「可疑信号」不是「定罪」：结果好但某一维弱，也可能是任务本身对那一维要求低，得结合场景判，别一标背离就否掉整个候选。第四，能力诊断的分依赖轨迹质量，轨迹采样不全时诊断分本身就带噪声，先保证「能采到完整决策轨迹」，再谈双栏报告。

结语：下周先改报告的一个字段

下周写智能体评估报告，别再交一列排序。至少并一栏机制诊断：哪怕是手填的四维简表，也比只有一个成功率强。评审桌上，当有人又指着 0.71 说「选高的」，你要能翻到背离那一页回一句：这个数是怎么来的，报告里有两栏。绿不绿是结果，凭什么绿才是能力。

同一个通过率可以来自两种完全不同的智能体，报告并两栏才看得见是哪一种。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。