Agent 评测别把「调优 Loop」 跑成「刷题 Loop」

创作型 Agent 的评测不能只盯固定 benchmark。更可靠的做法，是用 Scenario Model 每轮生成样本外任务，再让 baseline 和 candidate 在同一批新题上做配对比较。

导语

Agent 系统最容易让团队产生安全感的东西，是一条向上的 ​benchmark 曲线​。

今天 72 分，下周 81 分，再过两周 89 分。看起来系统在变强，prompt 更稳，工具调用更准，失败 case 越来越少。

但这里有个不舒服的问题：它是真的更会做新任务了，还是只是越来越熟悉那套题？

对创作型 Agent 来说，这个问题尤其危险。这类 Agent 不是回答标准题，而是在开放创作空间里完成任务。用户的需求会换场景、换素材、换约束、换验收标准。固定 benchmark 能帮你挡回归，却不能长期证明 ​泛化能力​。

图：分数上涨不等于新任务能力上涨

问题不在 Agent 会不会循环，而在团队怎么调系统

很多人说 Agent Loop，指的是单次任务里的循环：

理解目标 -> 调工具 -> 观察结果 -> 修正 -> 再执行

这很重要，但评测体系里还有一层更关键的 loop：

跑 benchmark -> 看失败 case -> 改 skill / tool / schema / prompt / evaluator -> 再跑 benchmark

这才是系统优化循环。

一个创作型 Agent 的表现，通常不是由模型单点决定的。它背后有工具、编辑器能力、schema、资源库、模板、skill、retry 策略和 evaluator。团队每次看到失败 case 后，都会改一点系统。

问题也出在这里。

当固定 benchmark 反复参与这个优化循环，它就不再只是测试集，而开始变成 ​训练信号​。这里的训练不一定是模型训练，也可能是工程层面的适配。

比如某个失败 case 被写进 skill，某类工具调用被特殊加强，某个 evaluator 偏好反过来塑造 executor 输出。几轮之后，系统确实更会做这套题了，但这不等于更会处理新的创作请求。

这就是 Benchmark Loop。

固定题有价值，但别让它背两个职责

固定 benchmark 不是错。它很适合回答一个问题：已知能力有没有退化？

某个工具之前能不能调用，某个已修 bug 有没有复现，某条高频路径是否仍然稳定，这些都应该用固定集看。因为题目不变，跨轮比较才有意义。

问题在于，很多团队会让固定集同时承担第二个职责：证明系统泛化能力提升。

这就麻烦了。

评测职责	固定 benchmark 是否适合	原因
回归防护	适合	题目固定，能跨轮比较
已修问题复测	适合	可以确认 bug 是否复现
泛化能力证明	不适合单独承担	长期参与优化后会被污染
新任务适应性	不适合单独承担	用户需求空间远大于固定题库

Goodhart 定律在这里很直接：当 benchmark 分数变成目标，它就不再只是质量代理指标。

测试集污染也不只发生在模型训练语料里。Agent 系统的污染，常常发生在 prompt、skill、tool 和 evaluator 这些工程层。

不要拿练习册原题考试

可以把创作型 Agent 想象成一个正在学复杂创作软件的人。

固定 benchmark 是练习册。练习册能帮他掌握基础动作，但考试不能永远考原题。否则你看到的是记忆，而不是能力。

更合理的方式是：

1. 保留固定题，检查基础能力有没有退化。
2. 每轮根据真实任务空间生成一批新题。
3. baseline 和 candidate 在同一批新题上同时跑。
4. 逐 case 比较谁做得更好。
5. 有价值的新题经过 review 后，再考虑进入长期回归集。

这套方法的核心，是把固定题和新题的职责分开。

固定题守底线。新题测泛化。

图：固定题守底线，轮换题测泛化

Scenario Model：维护出题模型，而不是只维护题库

如果每轮都要有新题，题从哪里来？

不能让 LLM 随机编一批 prompt。那样会生成很多坏题：需求不自然、验收标准不清、要求产品做不到的能力，或者内部 metadata 直接泄露给 executor。

需要维护的是 Scenario Model，也就是场景模型。

它建模的不是物理世界，而是创作任务空间：用户会提出什么样的需求，这些需求会覆盖哪些工具能力、编辑器 schema、素材资源、项目结构、运行时行为和验收标准。

Scenario Model 的输入可以包括：

• 真实用户请求分布
• 常见创作任务类型
• 已有评测 case
• tool 能力与 schema
• asset catalog 和 template
• 历史失败样本
• 产品当前重点方向

它输出的不是新的长期题库，而是每一轮评测开始时冻结的一批 Rotating Evaluation Set。

Rotating Set：同轮配对，跨轮不硬比

新题带来一个现实问题：每轮题都不一样，分数怎么比？

答案是，不要直接比较不同轮次的绝对分。要比较同一轮里 baseline 和 candidate 在同一批新题上的表现。

流程可以这样设计：

图：同一批新题内比较 baseline 与 candidate

配对比较比绝对分更重要。

Case	Baseline	Candidate	判断
A	Fail	Pass	候选版本改善
B	Pass	Pass	持平
C	Pass	Fail	候选版本退化
D	Fail	Fail	共同能力缺口

如果 candidate 在同一批新任务上明显多赢、少退化，才有理由说这轮系统改动提升了样本外能力。

第 N 轮 70 分和第 N+1 轮 75 分不能硬比。因为两轮任务的难度、长尾能力比例、素材组合和交互复杂度可能完全不同。

轮内复用保证公平，跨轮不复用保证样本外性。

生成式评测也要治理

Scenario Model 不是免费午餐。它会生成坏题。

有些失败不是 Agent 不会做，而是 case 本身不成立：prompt 有歧义，验收标准前后矛盾，要求超出产品能力，或者 schema 组合非法。

所以 Scenario Model 自己也要被评测。一个关键指标是 ​Invalid Case Rate​，也就是无效用例率。

无效 case 应该从分母里剔除，并进入出题模型改进，而不是被当成 Agent 能力缺口。

更重要的是，rotating failure 不应该立刻进入 autoloop。否则新题很快又会被污染成训练信号。

更稳的流程是：

1. 先诊断失败是系统问题还是题目问题。
2. 有效失败再进入人工 review。
3. 只有代表真实能力缺口的 case，才能 promotion 到固定回归集、skill 改进或 tool 改进。
4. promotion 时最好重投影 prompt，替换措辞、素材和非核心参数，避免系统记住原题 wording。

三层评测分工

最终，创作型 Agent 的评测体系应该拆成三层：

层级	回答的问题	使用方式
Fixed Regression Set	已知能力有没有退化	固定不变，跨轮可比
Rotating Evaluation Set	本轮系统改动是否提升样本外能力	每轮生成，同轮配对
Scenario Model Quality	出题模型是否可靠	看无效率、覆盖率和自然度

这三层缺一不可。

只看固定集，容易刷题。只看新题，难以守住已知能力。只生成新题但不治理出题模型，又会被坏题拖偏。

结语

Agent 系统分数上涨，不一定代表系统变强。它可能只是越来越会做那批固定题。

真正值得相信的评测，不该只问系统有没有把 benchmark 跑高，而要问这轮 prompt、skill、tool、schema、retry 或 evaluator 的改动，是否让 Agent 在新的、自然的、真实感足够强的任务上做得更好。

固定集守住过去，轮换集检验未来。对会持续自我调优的 Agent 系统来说，这个区分比漂亮的分数曲线更重要。

推荐阅读

代码不是 AI 编程的最终资产，AI Coding 真正该存的是 Checkpoint

RAG 找不到答案时，别急着怪模型，不如试试 SAG 知识库

Agent 从上手到精通：打造有记忆的个人智能体

Agent Memory 架构拆解：别再把向量库当唯一记忆系统

Hermes Skill Runtime 架构拆解：三层加载如何压住 Agent 上下文成本