智能体进化不等于能力单向提升：EvoAudit揭示递归改进的工程边界

摘要：研究系统评估了四种智能体框架演化方法在通用与代码任务中的递归自我改进效果。结果显示，16个演化智能体虽然都发现了此前未覆盖的任务，却同时丢失了部分原有能力；部分可靠性提升还伴随部署成本增加。文章据此提出保留既有能力、显式验证改进收益的评测框架，并提出基于选择、分析、变异和门控的 EvoAudit 流程。

---

核心发现：递归自我改进存在能力遗忘

这项研究关注的是“Agent harness evolution”：在不更新基础模型权重的情况下，自动修改智能体的提示、工具编排、执行流程或验收机制，以实现递归自我改进（Recursive Self Improvement，RSI）。研究覆盖四种演化方法、两种 harness 类型，以及通用任务和代码任务四个评测池，并通过重复评估、受控扩展、组件干预和 admission replay 检验改进是否真实、稳定且可迁移。

结果揭示了智能体进化中最容易被单一分数掩盖的问题：16 个演化后的智能体都完成了此前未覆盖的任务，但也都丢失了部分原先能够完成的任务。换言之，框架演化不是单调的能力累加，而是一次能力分布的重新分配。某项通用任务实验中，可靠性提高了 5.2 个百分点，却同时丢失了 10 个此前已覆盖任务，因此不能把可靠性增益直接解释为整体能力提升。

为什么最高基准分不等于最大真实改进

研究最重要的工程结论是：最终得分最高的智能体，并不是四个评测池中平均改进幅度最大的智能体。基准排行榜通常只奖励最终通过率，容易忽略以下三类隐性代价：

1. 能力遗忘：新任务覆盖增加，但原有任务可能被破坏。
2. 可靠性与成本耦合：多数可靠性提升同时带来更高部署成本。
3. 局部收益不可加：针对具体问题的专门修改通常优于泛化提醒，但把多个组件组合起来后，单项收益可能消失或反转。

因此，智能体 harness 的评估不能只记录“平均分”或“新任务覆盖率”，还应维护任务级别的能力保留率、回归失败数、部署成本，以及跨 harness、跨范式和跨任务类型的迁移表现。更严格的 admission gate 也不必然是好事：它可能淘汰具有互补能力的候选方案，使最终平均分更高，却没有带来更大的平均改进。

EvoAudit 的工程机制

EvoAudit 将上述诊断转化为一个“选择—分析—变异—门控”的改进闭环。其价值不在于训练更大的模型，而在于把评测证据直接接入框架演化过程：

• Select：从任务池和历史轨迹中选择具有代表性的样本，区分新增能力与既有能力回归。
• Analyze：定位失败来自提示、工具调用、上下文组织、错误恢复还是验收逻辑，而不是只修改表面指令。
• Mutate：针对具体失败模式生成 harness 修改，避免依赖泛化提醒；变异过程需要控制组件间交互，防止单项修复在组合后失效。
• Gate：依据任务级回归、可靠性、部署成本和适用条件决定是否接纳候选版本，而不是仅依据总体基准分。

从工程实现看，EvoAudit 更接近带回归测试的自动代码演化，而不是无约束地搜索提示词。候选 harness 必须通过重复评估，确认新增任务覆盖没有以牺牲既有任务为代价；同时需要记录额外 token、工具调用、失败重试和执行时间，才能判断可靠性提升是否值得上线。

迁移边界：通用任务与代码任务表现并不一致

研究还发现，改进的跨环境迁移具有选择性。在通用任务目标上，改进在两种 harness 类型和不同演化范式下通常都会降低覆盖率；在代码任务目标上，使用 outer-layer-only harness 时，覆盖率反而能够上升。这说明 harness 层的修复并不天然等价于可迁移的能力：任务类型、执行框架边界和改动位置都会影响泛化。

这带来一个实际限制：不能把某个智能体在单一环境中获得的框架优化，直接复制到其他工具链或任务集合。尤其对于代码智能体，测试生成、编译反馈、补丁提交和验证脚本可能与通用工具调用形成不同的反馈闭环，外层执行策略的效果必须单独测量。

给开发者的部署建议

如果要构建可持续演化的 agent harness，建议将评测和发布流程设计成以下形式：

• 为每个候选版本保存任务级通过矩阵，而不是只保存聚合分数。
• 将“新增任务覆盖”与“既有任务保留”作为两个独立指标，必要时增加回归测试集。
• 对同一候选进行多次重复评估，区分真实改进与采样随机性。
• 同时记录 token 消耗、工具调用次数、重试次数、端到端延迟和人工介入率。
• 对每个组件修改执行单变量消融，再测试组合效果，避免把交互效应误判为独立增益。
• 在 admission 阶段保留候选版本及其任务级证据，使更严格的门控不会误删互补方案。
• 明确迁移条件：分别验证通用任务、代码任务、不同 harness 和不同工具环境。

总体而言，这项研究并未证明递归自我改进可以无条件提升智能体，而是给出了一条更严格的工程路线：把智能体框架演化视为软件发布过程，持续验证新增能力、旧能力保留、成本预算和迁移边界。只有当这些指标同时成立，递归改进才可能从实验室中的分数增长转化为可部署的系统能力。

---

消息来源：Hugging Face Daily Papers (2026-11-05)

—— 完 ——

主题标签： #递归自我改进 关注 #Agent Harness 关注 #智能体评测 关注 #EvoAudit 关注 #能力回归 关注