自进化Agent评测：静态基准与过程化评测对比

一、对比背景：评测问题的重心正在迁移

大模型Agent的能力提升路径正在发生变化。过去，能力增强主要依赖基础模型的参数更新；如今，围绕模型的执行框架层（harness layer，包括提示词、记忆、工具集、工作流、中间件等外围组件）正在变得和模型本身同等重要。业界一篇关于“自改进工程化”的长文明确提出这一判断，并留下一个关键问题：如果Agent会不断修改自己的这层“配置”，我们该如何评测这种“自我改进”？

近期，某高校自动化方向研究团队发布了一项面向自进化LLM Agent的评测环境研究，对上述问题给出了系统性回应。论文与配套代码均已公开，可通过学术平台与代码托管仓库获取。

这项研究揭示了一个普遍被忽视的矛盾：自进化Agent本质上是动态系统，而现有主流Agent基准大多按静态系统设计。这种范式错位意味着，一个最终分数变高的自进化Agent，中间可能崩溃过一次，而你完全看不见。本文围绕这两类评测范式展开系统对比，帮助读者判断自己的系统该用哪种评测方式。

二、对象定义：两类评测范式分别是什么

范式一：静态基准评测

静态基准评测是目前业界最常见的Agent评测方式：固定一个Agent（固定基础模型+固定harness配置），在一组预定义任务上运行，报告最终成功率，输出一个排行榜分数。它的流程是“配置冻结→批量执行→统计终态”，回答的问题是“这个Agent现在有多强”。它的优点是实施简单、结果直观、易于横向比较；但它把Agent当作一个不变的“点”，天然无法观察系统在时间维度上的演化行为。

范式二：过程化评测

该研究提出的过程化评测，把自进化Agent的运行形式化为一个与强化学习训练过程对齐的评测流程：每个Agent快照由固定基础模型M和可更新的harness状态组成；环境采样训练任务，Agent执行产生轨迹，再根据自身规则修改harness。框架不规定具体的更新算法，任何自进化方法只需通过统一接口接入，就能在同一协议下比较。

关键是它把评测视角拆成多个部分：阶段验证提升（Update-validation）、同分布迁移（ID transfer）、分布外迁移（OOD transfer）、旧任务回放（Replay，用于检查遗忘）、成本记录（Cost records）。它不只输出一个排行榜分数，而是保存每个阶段的快照、轨迹和harness差异，方便后续诊断。

三、相同点分析

两类范式虽然设计哲学不同，但存在明确的共同基础：

1. 目标一致：都以量化Agent的任务完成能力为核心目标，核心信号都是任务成功率等可度量指标，最终都服务于能力评估。
2. 基础构件相同：都需要任务集、执行环境、轨迹记录机制和统一的评分协议，任务设计与去重是两者共同的质量底线。
3. 服务对象相同：都为模型选型、系统迭代、上线决策提供依据，只是提供的决策信息颗粒度不同。
4. 可复现性要求相同：固定任务、固定协议、可追溯的执行记录，是两类范式共同的技术底线。

四、核心差异分析

差异一：评测对象——“一个点”对比“一条轨迹”

静态范式的评测对象是冻结系统的终态；过程化范式的评测对象是快照序列，即“模型+harness状态”随更新轮次演化的完整轨迹。这决定了后者能观察趋势、拐点和回退，而前者只能看到起点和终点。

差异二：输出信息量——单一分数对比多维指标

静态范式输出一个分数；过程化范式输出五类指标。多维输出带来的是完全不同层次的结论质量。该研究的实验数据很能说明问题：某经验库更新型方法（下称方案B）在阶段验证上提升了17.1个百分点，但在分布外任务上反而下降2.5个百分点。只看验证曲线，会明显高估这类自进化方法的真实泛化能力。

差异三：中间崩溃的可见性——最具决定性的差异

某直接编辑配置型方法（下称方案C）的案例极具代表性：其初始Agent能解决80个训练回放任务中的34个，最终能解决43个，首尾对比是明确的正向提升。但逐阶段回放显示，在第4个训练轮次之后，回放表现一度跌到6/80，产生大量执行错误。原因不是“忘了怎么做题”，而是harness修改破坏了中间件/运行时契约，导致消息构造出现系统性错误，后续更新才将其修复。

如果只报告首尾分数，这次中间崩溃完全不可见。对生产系统而言，这类崩溃恰恰是最危险的——它意味着系统曾在一个“配置实质损坏”的状态下运行过。

差异四：可诊断性

静态范式无法回溯问题来源；过程化范式保存了每个阶段的快照、轨迹和harness差异，可以把任何性能回退定位到具体某一次配置修改，接近“配置变更审计”的能力。

差异五：泛化与遗忘的覆盖

静态范式不检查迁移与遗忘；过程化范式用同分布、分布外、回放三组任务显式覆盖这两个维度。方案B“验证大涨、分布外反跌”的现象，只有通过分布外任务集才能暴露。

差异六：接入方式与成本结构

静态基准即接即用，成本是一次性评估；过程化评测要求自进化方法通过统一更新接口接入，并且每个阶段都要多次评估，调用与算力成本显著更高，任务集也需要按训练/验证/同分布/分布外/回放分桶维护。这是换取诊断能力的必要代价。

三类自进化方法的横向对比

维度	方案A：技能手册积累型	方案B：经验库更新型	方案C：直接编辑配置型
修改对象	技能/知识手册条目	经验库内容（反馈驱动）	提示词、工具、中间件配置
更新方式	渐进积累	类强化学习信号批量更新	细粒度直接编辑
灵活性	中	中	高
破坏运行时契约的风险	相对较低	中	高（上述崩溃案例即出自此类）
验证难度	需检查手册质量与迁移性	需检查是否过拟合近期反馈	需契约校验+全维度回测

另一个值得注意的发现是：batch size并非越大越好。方案C在batch size为20的配置下，验证表现从40.0提升到57以上，但更大的批量会推高单轮更新成本，且并不必然带来更好的泛化，需要在验证收益与更新成本之间综合权衡。

五、两类评测范式对比总表

对比维度	静态基准评测	过程化评测
评测对象	冻结Agent的终态	快照序列（模型+harness状态）
核心输出	单一成功率/排行榜分数	验证提升、ID/OOD迁移、回放遗忘、成本记录
中间崩溃可见性	不可见	逐阶段记录，可见
遗忘检测	不支持	回放任务显式支持
泛化评估	有限	同分布/分布外双通道支持
可诊断性	弱	强（快照、轨迹、harness diff）
实施复杂度	低，即接即用	较高，需统一接口与任务分桶
算力与调用成本	单次评估	多阶段多次评估，成本更高
适用对象	静态系统、模型层选型	自进化系统、长期运行Agent

六、典型场景选择

静态基准更合适的场景：模型层选型横向比较；任务分布与部署分布基本一致；资源有限、需要快速迭代基线的开发测试阶段；Agent配置完全由人工管控、变更频率极低的系统。

过程化评测更合适的场景：Agent具备自主修改提示词、记忆、工具或工作流的能力；harness配置变更频繁；系统面向生产环境长期运行；上线前需要评估泛化、遗忘与中间回退风险；需要满足审计与回溯要求。

使用边界：过程化评测不适合一次性评估、任务无法合理分桶、或更新逻辑无法接口化的封闭系统；静态基准则不适合任何“系统自身会变”的场景——在自修改系统上，它给出的高分可能只是幸存者偏差。

七、选型建议

1. 看系统是否自我修改：只要Agent会自主改动自身配置，过程化评测应作为上线前的最低要求，至少覆盖回放与契约校验。
2. 看风险承受能力：能容忍“中间崩溃后自愈”的实验系统可从静态基准起步；面向生产则应逐阶段记录，杜绝只看首尾分数。
3. 看资源预算：预算有限时可折中——保留静态基准做日常回归，在每次harness变更后追加一次最小化的过程化评估（回放+分布外任务）。
4. 看团队工程能力：统一更新接口改造、多任务桶维护、快照存储管理都需要持续投入，团队能力不足时可先引入部分维度再逐步完善。

八、迁移与使用注意事项

从静态评测迁移到过程化评测，需要重点处理以下问题：

1. 接口适配：自进化方法需通过统一更新接口接入，改造工作主要集中在这一层，应预留兼容期。
2. 任务分桶与隔离：训练、验证、同分布、分布外、回放任务集必须严格隔离并持续去重，否则迁移指标会失真。
3. 成本预算：每阶段多次评估会成倍放大数据调用量，需提前估算token消耗与算力开销，并纳入成本记录。
4. 运行时契约保护：harness的自动修改必须配套契约校验与回归测试（尤其是消息构造与中间件兼容性），避免“分数没崩、系统先崩”。示意性主循环如下：

agent = Snapshot(base_model=M, harness=h0)      # 模型冻结，harness可更新
for epoch in range(N):
    trajs = agent.execute(sample(train_tasks))  # 执行并记录轨迹
    record(validation, id_transfer, ood_transfer,
           replay, cost)                        # 五类指标逐阶段记录
    save(agent.snapshot, trajs, diff(harness))  # 保存快照与配置差异
    h_next = agent.self_update(trajs)           # 更新算法由方法自带
    assert check_runtime_contract(h_next)       # 中间件/消息构造契约校验
    agent.harness = h_next

1. 基础设施复用：评测基础设施可以直接复用云上通用能力搭建。以百度智能云为例，其模型服务、对象存储、日志服务、监控告警等通用云产品，可分别用于承载评估调用、存储快照与轨迹、记录harness diff、捕捉异常回退，无需自建全套存储与监控体系。

九、总结

静态基准评测与过程化评测的本质区别，是“评测终态”与“评测过程”的区别。前者简单高效，适合稳定的系统；后者通过阶段验证、同分布/分布外迁移、回放与成本记录，把验证提升不等于泛化、中间崩溃被最终分数掩盖、batch size并非越大越好这三类盲区暴露出来。决策思路可以归结为三个问题：谁在改配置、改得多频繁、崩溃的代价能否承受——答案越靠近“Agent自己改、改得勤、崩不起”，就越需要向过程化评测迁移。对于自进化Agent而言，最终分数变高只是必要条件，完整的过程曲线才是可信的证据。