只重修失败题不算进步：阿里云给 Qoder 建持续评测闭环

周五下午给 Agent 加一条新 Skill，五次试跑都过，于是点了发布。周一群里已经在吵：有的答案碰巧对，但执行轨迹显示它根本没查数据；有的回复说报告已经生成，文件却不存在；几个原先稳的场景也莫名变差。改一句提示词、把 Agent 从 OpenClaw 迁到 Qoder Cloud Agents，或是直接换模型，很多发布决定其实只停在「看起来还行」。Qoder Cloud Agents（下文称 QCA）是阿里云把智能体配置、工具和执行环境放在云端运行的产品。2026 年 11 月 2 日，阿里云社区把这件事写成一套持续评测，而不是一次验收。

为什么 Agent 不能只对答案

传统软件同一输入得到同一输出，单元测试加几项性能指标就够。Agent 交出来的是一整包：答案、过程、产物和行为边界。答案对，可能是猜对，没有查该查的信息。它说做完了，文件可能没生成，或生成了也不能用。任务完成了，也可能越权，或绕了不必要的远路。模型输出本身又是概率的，这次对不代表下次对。没有基线对照，几次试跑形成的印象既证明不了稳定，也证明不了改动真的变好。

因此要的不是一次性验收，而是一直转的评测环：发现问题，改进，回归验证，再发现问题。

评测系统里的角色和考试一一对应：

QCA 把这套环落到运行时，靠的是五条条件。评测直接调用正在运行的 Agent，环境和真实执行一致。事件和资源全程留下，业务里的真实会话可以变成新题，题库跟着业务走。运行时给每次评测干净的执行环境，并发任务互不干扰。版本管理让改动和回归发生在副本上，不影响生产任务。除了标准基准，还可以按失败案例自建评测集。

题从业务来，不从榜单来

评测数据有两个来源，用途不同。

业务评测集来自业务本身。早期用典型任务和已知问题出题，也可以拿外部数据改写成业务场景；之后把生产会话持续收成新用例。成熟阶段则是生产会话不断变成新的评测集。

开源基准一般是端到端流程，不只是一份数据。每个基准有自己的任务和打分脚本，有的还要特定工具、Skill 或执行环境。它适合比较通用 Agent harness 的能力，或和公开榜对照。Harness 在这里指包住模型的那层运行外壳：工具、权限、上下文和验证怎么接。

对已经托管在云上的业务 Agent，自建题更重要。题目来自真实任务和真实问题，比的是同一个 Agent 在不同版本、不同业务阶段有没有真的变好。这套题库跟着业务长，最后成为业务方自己的数据资产。模型和框架可以换，别人抄不走扎在你业务里的题。

分数可信，先隔离考场

评测里常见三种污染。别的任务留下的数据、文件或流程会给 Agent 额外提示，等于夹带小抄。环境自己变了，就分不清是 Agent 变了还是考场变了。上一次跑完的文件和状态会污染下一次。

所以每道题要有独立考场。QCA 把推理决策和沙箱里的工具执行拆开，每个会话单独一个隔离沙箱。评测时每道用例一个会话，隔离是结构带来的，不是跑完再收拾。

如果评测依赖特定的依赖、数据或工具，还得单独准备环境。把这套环境和 QCA 默认环境混在一起，验证就失效。自托管沙箱模式允许把准备好的评测环境直接当作执行环境，让执行、依赖和评测待在同一处。

答案、过程、产物分开查

只看最终答案会被三种情况骗到。证据不足但答案碰巧正确，是蒙对。声称完成但产物缺失或不可用，是假完成。答案来自数据泄漏而不是能力，是偷看答案。

QCA 因此坚持三查。查答案：结论是否正确、完整。查过程：必要步骤做了没有，有没有越界，有没有低效绕路，有没有在没有证据时硬答。查产物：文件能不能用，数据有没有按要求改。

不同的题交给不同的评估器，原则是能确定就先确定：

• 客观题用代码评估器。规则能判的，不叫模型。
• 主观题用模型评估器。要理解内容和判断质量时，才用大语言模型打分。
• 动手题用 Agent 评估器。需要打开文件或检查环境时，让另一个 Agent 去验交付物。

一道用例通常叠几种检查，每个评估器独立打分。打分本身还有三条硬规则。执行结束、环境冻结之后，才放入成功标准和检查逻辑，避免标准泄漏进执行过程。同一道题要多次运行、多次评分，用 pass@k 和 pass^k 看分布，而不是看一次结果。pass@k 表示 k 次里至少成功一次，pass^k 表示 k 次全部成功。原文只要求用这两个指标，没有给出具体的 k，也没有给出任何分数。云端会留下会话事件、执行轨迹、产物和每次打分依据。通过、失败、无法评，都要能回到具体证据。

在副本上改，用全量题验收

一轮评测的结果只是下一轮优化的起点。多数优化发生在语义层：改提示词、加 Skill、改工具描述。模型输出是概率的，改了不保证会照做，照做一次也不保证每次都一样。所以每次优化都要对照基线做回归，核心是把「改动」带来的不确定性压下去。

QCA 的托管架构把这件事做轻：快速克隆一份相同的 Agent，在副本上迭代出不同测试版本，生产上的业务 Agent 照常跑。

验收标准也要写死。只把先前失败的题再测一遍，只能说明改动对这一子集的失败案例有效。要用同一批数据、依赖和环境重跑全量评测集，目标指标明显变好，其他指标没有实质性回退，才算验证过的优化。只修好失败案例不是进步，总体不能退。

上线之后，线上信号不是分数

离线评测集覆盖的是已知问题和已知场景。生产里新冒出来的问题，可以主动、持续地收：把有价值的场景和问题写成用例，加进评测集，变成以后迭代用的业务数据资产。

线上评估和离线评测不是一回事。离线有预先写好的检查标准，结果可以打分。线上是开放的，会话来自真实业务，没有预置参考答案，只能先做异常初检。

所以线上要的是业务自己的观察指标，例如轨迹效率、工具调用是否准确、时间是否对得上。这些指标是用来发现异常的信号，不是成绩。

可信、灵活和成本不能同时拉满

评测同时想要三件事：结论可信、彼此可比；能按业务改；成本可控。实践里很难三者都拉到最大。不同业务可以自己排优先级，框架要留出这个取舍，而不是假装有一个万能分数。

评测也不是一次就给出完美准确分数的严考官，更像一轮一轮主动找问题的顾问。即使盖不住全部问题，只要指出的问题被处理、改进被验证，核心价值就在。

因此不必等完美数据和完美的端到端流程才开始。先拿业务里已经暴露的几个有代表性的失败案例，做一小套评测集跑起来。Agent 演进时再加题、改评分、扩大覆盖。评测和 Agent 一起跟着业务长。能被持续评测的 Agent 才可能持续变好；能持续变好，业务才可能长期信任它。

原文没有给出样本量、pass@k 的具体 k，也没有给出上线前后的分数对照。隔离、三查、副本回归和「线上指标不是分数」是方法约束，不是已测量的效果。

阿里云，Alibaba Cloud Community，Qoder Cloud Agents: An Evaluation Loop for Reliable, Continuous Agent Improvement，2026-11-02，https://www.alibabacloud.com/blog/qoder-cloud-agents-an-evaluation-loop-for-reliable-continuous-agent-improvement_603715