创作型 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 是练习册。练习册能帮他掌握基础动作但考试不能永远考原题。否则你看到的是记忆而不是能力。更合理的方式是保留固定题检查基础能力有没有退化。每轮根据真实任务空间生成一批新题。baseline 和 candidate 在同一批新题上同时跑。逐 case 比较谁做得更好。有价值的新题经过 review 后再考虑进入长期回归集。这套方法的核心是把固定题和新题的职责分开。固定题守底线。新题测泛化。图固定题守底线轮换题测泛化Scenario Model维护出题模型而不是只维护题库如果每轮都要有新题题从哪里来不能让 LLM 随机编一批 prompt。那样会生成很多坏题需求不自然、验收标准不清、要求产品做不到的能力或者内部 metadata 直接泄露给 executor。需要维护的是 Scenario Model也就是场景模型。它建模的不是物理世界而是创作任务空间用户会提出什么样的需求这些需求会覆盖哪些工具能力、编辑器 schema、素材资源、项目结构、运行时行为和验收标准。Scenario Model 的输入可以包括真实用户请求分布常见创作任务类型已有评测 casetool 能力与 schemaasset catalog 和 template历史失败样本产品当前重点方向它输出的不是新的长期题库而是每一轮评测开始时冻结的一批 Rotating Evaluation Set。Rotating Set同轮配对跨轮不硬比新题带来一个现实问题每轮题都不一样分数怎么比答案是不要直接比较不同轮次的绝对分。要比较同一轮里 baseline 和 candidate 在同一批新题上的表现。流程可以这样设计图同一批新题内比较 baseline 与 candidate配对比较比绝对分更重要。CaseBaselineCandidate判断AFailPass候选版本改善BPassPass持平CPassFail候选版本退化DFailFail共同能力缺口如果 candidate 在同一批新任务上明显多赢、少退化才有理由说这轮系统改动提升了样本外能力。第 N 轮 70 分和第 N1 轮 75 分不能硬比。因为两轮任务的难度、长尾能力比例、素材组合和交互复杂度可能完全不同。轮内复用保证公平跨轮不复用保证样本外性。生成式评测也要治理Scenario Model 不是免费午餐。它会生成坏题。有些失败不是 Agent 不会做而是 case 本身不成立prompt 有歧义验收标准前后矛盾要求超出产品能力或者 schema 组合非法。所以 Scenario Model 自己也要被评测。一个关键指标是 Invalid Case Rate也就是无效用例率。无效 case 应该从分母里剔除并进入出题模型改进而不是被当成 Agent 能力缺口。更重要的是rotating failure 不应该立刻进入 autoloop。否则新题很快又会被污染成训练信号。更稳的流程是先诊断失败是系统问题还是题目问题。有效失败再进入人工 review。只有代表真实能力缺口的 case才能 promotion 到固定回归集、skill 改进或 tool 改进。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 真正该存的是 CheckpointRAG 找不到答案时别急着怪模型不如试试 SAG 知识库Agent 从上手到精通打造有记忆的个人智能体Agent Memory 架构拆解别再把向量库当唯一记忆系统Hermes Skill Runtime 架构拆解三层加载如何压住 Agent 上下文成本