会自我改进，不等于会适应变化：PACE-Bench 如何评测 Self-Evolving Agent
随着 Claude plays robotics、Waddle 等工作将通用 Agent 带入机器人与物理世界，Agent 已经开始通过执行、反馈和代码修改完成真实任务。但真实世界不会始终固定：如果环境本身发生变化，过去成功的方案已经失效，Agent 还能不能靠新的交互自主恢复？这正是 Self-Evolving Agent 走向真实物理世界必须面对的问题。
为此，该团队提出 PACE-Bench（Physics Adaptation via Code Evolution），用代码驱动的物理设计作为 Self-Evolution 的可控测试场景。比如，一辆车原本能在公路上行驶，路面变成冰面后却开始打滑。目标和接口没有改变，但旧设计赖以成立的条件已经过时。Agent 必须从新反馈中识别失效假设，并修订定义机械结构与控制逻辑的设计代码，直到方案重新工作。
研究者在完整 Benchmark 上比较了四类范式下的 10 种 Self-Evolving 方法，并在选定子集上进一步评测更大的开源与前沿模型。结果并不乐观：在完整 Benchmark 上，表现最好的 Reflexion + Qwen3-14B 的 Pass@2 只有 35.9%。GPT-5.5 在静力学任务中达到 66.7%，却仍有三分之一的任务未能通过。不同方法还会引入额外的模型调用、搜索或参数更新，但计算时间更长并不代表在同样时间内能取得更高得分。
进一步分析显示，瓶颈并不只在于模型是否足够强。Reflexion 根据上一次 Box2D 执行返回的反馈分析失败，修改一次后便重新进入环境验证。Self-Refine 虽然在外层也能收到环境反馈，却会在下一次验证前仅靠模型自评连续修改最多五轮，结果反而显著退化。 当方法加入记忆或搜索后，Agent 又容易在固守旧设计与无方向探索之间摇摆。即使直接公开环境变化的精确参数，最佳结果也没有提高。但能真正 self-evolve 的 agent，其不仅要知道世界发生了什么（Know What），还要据此决定该改参数、结构还是控制方式，并写出能在新环境中运行的代码（Know How）。
➤ 项目主页
🔗 https://thunlp.github.io/PACE-Bench/
➤ 论文
🔗 https://arxiv.org/pdf/2608.14441
➤ 代码 & Benchmark
🔗 https://github.com/thunlp/PACE-Bench
Self-Evolving Agent 真正遇到环境变化时，会发生什么？
Self-Evolving Agent 会从交互中更新上下文、记忆、工具或模型参数，让之后的行为逐步改善。但现有评测通常保持执行条件不变，主要观察 Agent 能否在任务流中积累经验，或把学到的能力迁移到其他任务。真实环境却不会始终固定。当地形、材料或动力学发生变化时，一套过去有效的方案可能立即失效，Agent 必须判断哪些假设已经过时，以及应该继续修改原方案还是更换设计方向。
PACE-Bench 用 代码驱动的物理设计 来检验这种能力。在这里，Python 代码是一份可以直接执行的设计方案，同时也是 Agent 操作模拟环境的接口。代码本身定义机械结构、部件连接和控制逻辑。运行代码会在 Box2D 中生成对应的物理系统，Agent 可以从运动轨迹、任务得分和诊断信息中观察设计是否工作。每次修订后的代码都直接表示一套新的结构与控制方案。
环境变化后，任务目标和代码接口保持不变，旧设计赖以成立的物理条件却可能已经消失。例如，一辆车原本能在高摩擦路面上行驶，到了冰面后可能只会原地打滑。此时，Agent 不仅要判断摩擦发生了变化，还要把判断落实为新的可执行设计。整个适应过程是：
观察失败 → 推断环境变化 → 修订可执行设计 → 重新执行 → 根据新反馈继续迭代
图 1：S-01 桥梁任务中的 Source→Target 适应过程。Source 设计在原环境成功，在 Mutation 后的 Target 环境失效，Agent 随后通过反馈、物理推理和代码重设计完成适应。
PACE-Bench 究竟怎么测：从 Source 到 Target 环境
基于上述设置，PACE-Bench 构建了 36 个基础任务，覆盖六类物理领域：
静力学与平衡（Statics & Equilibrium）
运动学与连杆（Kinematics & Linkages）
动力学与能量（Dynamics & Energy）
颗粒与流体交互（Granular & Fluid Interaction）
控制（Cybernetics & Control）
奇异物理（Exotic Physics）
每个任务先在一个 Source 环境 中给出可行设计，再通过 Mutation（环境变异）系统性改变地形、摩擦、材料强度或动力学，得到四个 Target 环境。这样共形成 180 个环境和 144 个 Source→Target 环境对。变异前后，任务目标和代码接口保持不变。Agent 仍然使用同一组 Primitive API，也就是 Benchmark 提供的基础物理构件接口，用它们创建物体、连接结构并施加控制，而不能直接修改环境或评估器。
Agent 收到的是在 Source 环境中得分 100 的设计代码，但这份代码在对应的 Target 环境中已经失效。它最多有 20 次机会提交修改后的设计。每次提交都会在 Box2D 沙箱中真实执行，系统返回约束是否满足、任务进度和失败诊断，Agent 再据此继续修改。评测关注的正是它能否通过这条交互闭环，把失效的 Source 设计改造成能够适应 Target 环境的新设计。
图 2：左图给出六类物理领域及其 36 个任务，右图同步展示 36 个 Source 环境参考解的 Box2D 模拟过程。
为了让每个环境对都成为有效的 Self-Evolution 测试，研究者设置了三项条件。
第一，保证任务 Non-trivial。Source 设计必须在 Source 环境中得分 100，同时在四个 Target 环境中全部失败，从而排除“直接复制旧代码即可通过”的情况。
第二，保证任务 Solvable。每个 Target 环境都配有经过 Box2D 执行验证、得分为 100 的独立参考解，因此失败不能归因于题目无解。
第三，默认采用 Change-Hidden 设置。Agent 只知道一组“可能发生变化”的变量名称，却不知道真正改变了什么、变化方向及具体数值。约束和可见几何量仍会准确给出，但摩擦、阻尼、重力等隐藏参数需要从执行反馈中推断。
因此，PACE-Bench 同时测量两种不同能力：
Physical Inference（Know What）：从失败现象与诊断反馈中判断环境发生了什么变化。
Mechanism Redesign（Know How）：把这种判断转化为能在目标物理条件下工作的结构与控制机制。
这些任务如何构造，又如何避免「模型生成、模型自评」？
PACE-Bench 将任务生成、难度校准和最终判分彼此分离。
图 3：任务与变异环境生成、模块化实现与参考解推导、自动审计和人工验证组成三阶段构建流程。
首先，研究者构建 36 个任务及各自的四个 Target 环境，并采用模块化实现，让 Mutation 同步作用于环境、评估器与 Prompt。随后为每个环境推导独立参考解，并通过 Box2D 验证其达到 100 分。
接着，研究者用自动检查、Qwen3-4B 压力测试和三轮人工审查共同校准任务。题目既不能被旧设计直接通过，也必须有可执行解。反馈只指出失败发生在何处、何时以及差距多大，不直接给出修复方案。Claude Code 参与任务构造和参考解推导，但最终成功与否始终由 Box2D 和硬编码评估器决定。
研究者如何评测 Self-Evolving 方法？
该团队以 Qwen3-4B、Qwen3-8B 和 Qwen3-14B 为 Backbone，系统比较了 10 种 Self-Evolving 方法与一个 Vanilla 基线，覆盖四种主流范式：
Context-based: Reflexion、Self-Refine
Memory-augmented: ACE、ExpeL、ReasoningBank
Inference-time Search: Tree-of-Thoughts（ToT）、CodeEvolve
Parameter-based: SEAL、RAGEN、TTT-Discover
这里的 Vanilla 采用迭代闭环：生成候选代码 → Box2D 验证 → 将结构化诊断加入 Revision Prompt → 再次修改。每轮保留最近一次尝试和历史最佳尝试，但不使用额外记忆、额外 Agent 或权重更新。其他十种方法都在这条共同闭环上增加各自的 Self-Evolving 机制。
每个 Source→Target 环境对独立运行两次。该团队主要报告：
Pass@2：两个独立运行中至少一次成功的环境对比例。
Score@2：两个运行各自最佳得分的平均值，100 表示完整通过，负分表示仍有硬约束未满足。
Benchmark 饱和了吗？更大的模型也没有解决问题
答案很明确：远未饱和。 在完整 Benchmark 上，最佳组合 Reflexion + Qwen3-14B 的 Pass@2 只有 35.9%，Score@2 为 28.0。主结果也显示出明显的 Scaling。例如，Reflexion 从 4B、8B 到 14B 的 Pass@2 依次为 19.5%、26.6% 和 35.9%。但规模增长并没有让任务接近解决。
图 4：完整 PACE-Bench 上的 Pass@2 与 Score@2。括号中为相对同规模 Vanilla 的变化。
为了进一步检验更强的模型能否填平差距，该团队在静力学的 24 个环境对上固定使用 Vanilla，并加入 Qwen3-32B、DeepSeek-V4-Pro 与 GPT-5.5。
图 5：更大模型在静力学任务上的 Vanilla 结果。Qwen3-32B 的 Pass@2 与 14B 持平。GPT-5.5 提升到 66.7%，但仍有三分之一的环境对未能恢复。
同系列的 Qwen3-32B 没有超过 14B，说明参数规模并不会稳定转化为适应能力。GPT-5.5 提升明显，但仍未让任务饱和。
From-Scratch 对照进一步验证了任务难度。不给 Source 设计、让 Vanilla 从零构造方案时，Qwen3-4B、8B 和 14B 的 Pass@2 只有 11.3%–18.3%。按环境统计，Source 环境为 32.3%，四个 Target 环境仅为 6.4%–13.4%。Mutation 确实让 Target 环境进入了更困难、不能靠直接生成轻易解决的设计区域。
第一个反直觉结果：最复杂的「自我进化」，不一定更有效
主结果中，Reflexion 与 Self-Refine 之间的显著差异尤其值得注意。
Reflexion 每次拿到沙箱反馈后，会先增加一个专门的失败分析步骤，再修改代码。Self-Refine 则会在重新进入沙箱之前，连续进行最多五次内部自我批改。直觉上，多改几轮似乎应该更充分。但结果恰恰相反。Self-Refine 在 Qwen3-4B、8B 和 14B 上都显著落后于 Vanilla，14B 时更是从 32.0% 降到 7.1%，同时显著增加墙钟时间。
从效率看，答案又有所不同。研究者在运动学任务上用 Score/Hr（平均得分除以墙钟小时数）比较方法：
图 6：运动学任务上的 Score、墙钟时间与 Score/Hr。ToT 在 Qwen3-4B、8B 和 14B 上均取得最高单位时间效率。
ToT 的 Score/Hr 在 4B、8B 和 14B 上分别达到 45.7、46.4 和 57.8，但最高绝对得分由不同方法取得。Self-Refine 只有 2.0–3.6 Score/Hr，CodeEvolve 也仅为 3.7–7.5。「最终谁做得最好」和「同样时间内谁进步最快」是两个不同问题。额外计算只有转化为有效探索才有价值。
Takeaway 1：有模拟器验证的反思比未验证的连续修改更可靠。ToT 的单位时间效率最高，也说明更高成功率与更高效率对应两个不同目标。
第二个关键结果：为什么 Agent 会在「锁死」与「漫游」之间失衡？
为什么已经有初始设计和连续执行反馈，Agent 还是经常失败？
研究者把失败轨迹分为九类，并进一步分析每轮生成代码之间的 Jaccard 相似度。结果呈现出两种相反轨迹。保守的方法容易出现 Design Fixation（设计固化），围绕早期机制反复局部修补。改动激进的方法则更容易陷入 Stagnation 或无方向的 Exploration，迟迟无法收敛。
图 7：失败运行内部的错误类型份额。左图按六类物理任务统计，右图按方法统计。柱高表示失败类型构成，而不是全部任务中的绝对失败率。
Vanilla 的失败中，Design Fixation 占 41.0%。ACE 虽将 Stagnation 从 12.6% 降到 7.5%，却把 Fixation 推高到 47.1%。ReasoningBank 的代码也随迭代越来越相似。检索到的经验没有自动变成可迁移知识，反而可能限制更强模型根据当前反馈重新推理。
搜索方法容易走向另一个极端。ToT 的 Fixation 仅 0.3%，但 50.2% 的失败属于 Stagnation：它跳出了旧设计，却迟迟没有把探索收敛为可行方案。CodeEvolve 的交叉与变异又过于接近父代，Fixation 高达 66.3%。
Takeaway 2：Self-Evolving Agent 容易在固守旧设计与无方向探索之间失衡。Memory-augmented 方法可能把搜索锚定在早期方案，Inference-time Search 则可能跳出旧方案却无法稳定收敛。
关键不在于模块是否更复杂，而在于它能否利用新证据推翻错误假设，同时保留稳定的优化方向。
第三个关键结果：为什么更多信息不一定更有帮助？
PACE-Bench 默认隐藏具体物理变化。那么，模型失败会不会只是因为它没有猜中摩擦系数、重力或阻尼的变化？
为此，研究者设置了 Change-Exposed（CE）对照：直接告诉 Agent 哪些变量发生了变化，以及它们新的精确数值。这样，Physical Inference（Know What）几乎被从任务中移除，剩下的主要是 Mechanism Redesign（Know How）。
图 8：静力学与运动学任务上的 Change-Hidden（CH）与 Change-Exposed（CE）Pass@2。CE 对 4B 均有帮助，但未抬高整体最佳结果。
公开精确参数后，4B 的三种配置提高了 2.6–8.4 个百分点。到了 8B 和 14B，变化大多很小，Vanilla-14B 反而下降 7.2 个百分点。最佳 CH 结果为 17.9%，仍高于最佳 CE 的 14.6%。公开参数可以降低 Physical Inference 的难度，却没有解决 Mechanism Redesign。
模型可以正确理解“摩擦变小”，却未必知道应该调整轮子结构、质量分布或驱动方式，还是放弃原来的车辆机制。Mechanism Redesign 需要结合失败现象与物理约束，判断原设计为何不再成立，再决定是调整参数、修改结构与控制，还是提出新的机制，并把这一判断实现为可执行代码。这项任务同时考验物理推理、设计决策与迭代验证，单纯搜索大量参数组合无法概括其中的难点。
视频反馈也呈现出方法差异。在 14B 上，加入 VLM 生成的执行描述后，Vanilla 从 40.9% 降到 18.2%，Reflexion 从 40.9% 降到 27.3%。ACE 却从 13.6% 升到 22.7%，ExpeL 从 13.6% 升到 36.4%。错误类型的变化表明，一种可能解释是：视频信息会打散 Context-based 方法原本集中的推理，却能用新证据纠正 Memory-based 方法中的陈旧经验。
因此，方法需要判断哪些证据足以推翻旧假设，以及哪些信息只会带来无方向的变化。
Takeaway 3：更多信息并不总是更有帮助。公开精确变化没有抬高最佳结果，视频反馈也会因方法范式不同而产生相反影响。知道“什么变了”（Know What），仍不等于知道“怎样重新设计”（Know How）。
不同任务类别，难点相同吗？
不相同。聚合所有方法后，奇异物理 在 4B、8B 和 14B 上的 Pass@2 分别为 22.2%、25.0% 和 38.5%，始终最容易取得成功。动力学 则整体最难，分别只有 8.2%、9.7% 和 14.2%。
图 9：在全部方法上聚合的 Model × Category Pass@2。S/K/D/F/C/E 依次表示静力学、运动学、动力学、颗粒/流体、控制和奇异物理。
不同类别从 Scaling 中得到的收益也很不均衡。4B 扩展到 14B 时，奇异物理提升 16.3 个百分点，颗粒/流体提升 12.2 个百分点，而运动学仅提升 1.9 个百分点。结合具体任务看，运动学往往需要搜索连杆拓扑等组合结构。这类难点并不会随着模型推理能力增强而自然消失。
因此，类别结构比单纯的模型规模更能解释任务难度：Scaling 能改善推理，却未必能解决适应过程中的组合设计搜索。
PACE-Bench 带来了哪些启示？
综合这些结果，研究者得到三条面向下一代 Self-Evolving Agent 的启示。
第一，Self-Evolution 必须以可验证的环境反馈为锚。内部反思只有在吸收新证据时才有价值。真实执行、精确诊断和针对失败的反思，比无验证的多轮自我修改更可靠。
第二，记忆和搜索需要共同解决「跳得出去，也收得回来」。Memory-augmented 方法不能只反复取回早期高分方案，还应记录哪些假设已被物理证据否定。Inference-time Search 也不能只扩大分支数，而要识别机制级差异，并把资源集中到真正有希望的设计族上。
第三，更多信息只有被正确吸收，才会成为有效证据。公开精确物理参数没有抬高最佳隐藏设置的结果，视频反馈也会帮助 Memory-based 方法却干扰 Context-based 方法。评测不能只问模型获得了多少信息，还要问它能否把证据转化为可执行设计。
总结
PACE-Bench 把 Self-Evolution 放进一个更严格也更现实的场景：目标和接口不变，但环境变化让旧成功失效，Agent 必须从执行反馈中自主恢复。36 个任务、144 个环境对上的最佳 Pass@2 仍只有 35.9%，说明这项能力远未被解决。实验进一步表明，有环境验证的反思优于无验证的反复修改，记忆与搜索需要同时做到跳出旧方案并稳定收敛，知道“什么变了”也不等于知道“怎样重新设计”。下一步，Self-Evolving 方法需要把反馈变成可证伪的假设，主动淘汰过时经验，并把搜索资源集中到真正不同、又有希望的机制上。沿着这一方向，我们后续还会推出类型更多样、物理机制更丰富、难度更高的任务，并逐步将评测扩展到更丰富的模拟器、真实硬件和更长的交互周期。当真实世界不断变化、旧经验持续失效时，Agent 能否依靠新的交互自主恢复，可能才是 Self-Evolution 最终需要解决的问题。