怎么判断一个 Agent 系统行不行？大多数人的办法是：给它几个问题，看回答像不像样。
这套办法正在失效。当 Agent 从"回答问题"进化到"完成任务"——进容器、跑命令、改文件、起服务——文本打分就量不出真本事了。一篇来自阿里云的评测实践（千问AI平台，钟玟，2026-08-19）给出了一个更硬的方案：看容器终态，算过程分。
二值通过率，太粗了
评测的对象是 DeepSeek 今年8月 MIT 开源的 Agent 运行框架 Harness（下称 DSH）。它是"模型之外的运行时"：负责工具调用、上下文管理、权限控制和会话记录。用 DeepSeek 自己的话说，Agent = Model + Harness——模型决定能力上限，Harness 决定能力落地方式。
问题在于：怎么客观评一个 Harness？这篇评测实践先点了传统方法的三个死穴：问答式基准量不了真实环境里的状态变更；LLM 当裁判打分，方差大、还有宽松偏差（手松，给谁都高分）；只报"过/没过"的二值通过率，会把"任务完成度、结果正当性、过程可靠性"三种完全不同的信号压成一个数。
他们的解法是把考试拆成三个维度，全部用规则化脚本打分，不用模型当裁判：
- **outcome（任务完成度）**：结果对不对。55%权重来自 benchmark 自带验证器的原样判定，25%来自逐条测试断言的通过率，20%来自产物完整性——要求写出的文件是不是真写出来了，"仅提及不算，跑测试不算写"。
- **compliance（红线规则）**：手段正不正当。有没有作弊、有没有绕过约束。
- **process（过程可靠性）**：步骤靠不靠谱。从执行轨迹里提取信号，判断拆解和执行是否有条理。
这个设计的类比很接地气：就像高考阅卷。机器批客观题对应 Code-As-Judge，过程分对应大题的演算步骤分。学生答错一道大题，步骤分照样能区分"接近做出来"和"完全没思路"。
实测：80%通过率，0.85均分
考场是 terminal-bench 2.1 的一个10任务子集。任务在自包含容器里执行，判定对象是容器终态——落盘的文件、监听的端口、可复现的程序行为，不是模型写出来的文字。
DSH 搭配 Qwen3.7-Plus 模型，结果如下：10项任务通过8项，通过率80%。三维平均分：outcome 0.74、compliance 0.98、process 0.83，整体均分0.85。30次评估（3个评估器×10任务）成功率100%。
两个失败案例值得看。extract-elf 的 outcome 只有0.19：6个必需产物只写出了2个。chess-best-move 是0.2，跑了701秒还是没做出来。另有2项任务虽然验证器判过，但因为耗时逼近预算被0.50封顶——"时限本身构成任务约束"。
对照组是 Codex：同样8项通过，但 outcome 平均0.81，比 DSH 高一截；一个有趣的差异是，DSH 做不出的 extract-elf，Codex 做出来了（0.87），而 DSH 通过的一项任务在 Codex 上反而触了时限。模型相同（都是 Qwen3.7-Plus 做底座评估环境），跑分差异主要来自 Harness 的工程实现——这正是"评 Harness 而非评模型"的意义。
图：DSH 与 Codex 在同一考场上的三维得分，差异集中在 outcome。
过程分为什么值钱
这篇实践里最有工程含金量的，不是分数本身，而是打分依据的可审计性。
DSH 的架构天然帮了忙：它以 Session Log 作为唯一权威事件源，系统提示词、工具调用、权限切换全部追加进同一日志，轨迹可完整回放。评测方再把采集组件以插件方式挂进 Harness 的 Cordis 微内核，不改一行源码就拿到了全量轨迹。打分逻辑封装成平台的 AGENT + Skill，规则化、可复现，从机制上排除了"模型打分"的方差。
反过来想：如果 Agent 框架没有完整的事件日志，这套评测根本做不了。这给选型提了个醒——日志和轨迹不是可观测性的锦上添花，是你能不能审计这个 Agent 的前提。
港大一篇同期论文（HELIX，arXiv:2608.13951）从另一个角度印证了这个判断。它把 Harness 定义为"模型与任务之间的主动共同决定者"：Harness 不只是执行环境，还决定了模型明天从什么轨迹里学。HELIX 在一次65候选的进化轮里，靠换一个更合适的 Harness 就把任务覆盖率提升了4.0%——模型没动，只改了外面的壳。既然 Harness 对行为的影响这么大，为它建一套可复现的考卷，就成了必然。
图：HELIX 提出的闭环——构建、交互、验证、更新模型，再为新模型重建 Harness。来源：arXiv:2608.13951。
图：从"整体过没过"到"分维度可审计"，Agent 评测正在工业化。
对想自己动手的团队，这篇实践还留了一条省钱的门路：评估任务被固化成"详细流程 Prompt + 评分脚本"的 Skill 形态之后，评估本身的难度远低于被评的 Agent 任务，用成本更低的小模型就能承载判分工作。原文引了一句《师说》来解释这件事——弟子不必不如师，师不必贤于弟子。评测管线的成本一旦降下来，从"跑一次看一次"变成"每次改动都跑"，才算真正可行。
源势AI观点
我们做企业 Agent 落地时，内部已经用上了类似的原则，说三条。
第一，验收标准定在"终态"上，不要定在"回答"上。我们给能源客户交付巡检 Agent 时，验收项是"异常工单是否正确生成、派发给对的人"，不是"Agent 复述任务多流利"。容器终态的思路在业务侧的对应物，就是可验证的业务状态变更。
第二，过程分要留。只看结果，出了问题没法归因；有了轨迹和过程评分，"是检索错了还是决策错了"一查便知。我们要求所有交付的 Agent 必须带完整事件日志，这不是客户要求，是我们自己的底线。
第三，别用 LLM 给 LLM 的工作打关键分。规则能覆盖的地方用规则，把模型裁判留给规则够不着的主观环节。这篇实践里"评估任务难度低于被评任务，可以用小模型执行评分"的思路，对控制评测成本也很有参考性。
Agent 从能演示到可上线，中间隔着的就是这套考卷。
