HELIX：模型-工具链协同进化以实现递归自我改进

# 模型–框架协同进化实现递归自我提升
来源：https://arxiv.org/html/2608.13951

###### 摘要
扩展智能体能力通常只从一个角度进行：优化模型本身。然而，模型是通过运行时框架来执行任务的，该框架负责管理上下文、工具、控制流、权限和终止决策。框架并非中立的封装层——它是智能体行为的活跃协同决定因素。对于交互式智能体，其影响具有递归性：它既调控模型当下的执行过程，也塑造模型未来学习的轨迹。将模型与框架视为独立产物会割裂这一反馈循环。我们认为，要闭合这个循环，需要将**模型–框架协同进化**作为首要原则。协同进化拒绝一种虚假的不对称性，即一个组件进化而另一个保持静态。框架设计既决定固定模型的执行效率，也构建模型改进所需的数据结构。反过来，更强的模型可能倾向于采用匹配其新能力特征的框架。这种双向依赖关系赋予框架构建双重目的：实现更强的即时执行，以及生成**经验证的兄弟轨迹**——成对的结果记录包含成功案例、性能退化、接近成功和替代方案——作为模型下次更新的结构化训练信号。

近期研究已开始将框架适配与模型学习相结合，但在异构运行时设计间实现源可追溯、可审计的交接仍然困难。我们围绕**构建–更新–重建**三阶段组织方案：**构建**源可追溯的固定模型框架；从**经验证的兄弟轨迹**中更新模型；为更新后的模型**重建**框架——因其能力特征变化可能倾向于不同的运行时设计。在此范式内，我们提出HELIX，一个支持双重目的框架构建的源可追溯基础系统。它将OpenCode、Pi Mono、Nanobot和Hermes Agent分解为类型化端口、原子单元、配方、产品外壳和运行时策略，使干预操作显式化而非隐含于临时提示中。预执行检查确保可审计性。证据平面保留轨迹、测试结果、策略决策和来源信息，维持结果丰富性而非简化为单一成功标记。HELIX为每个产品合约暴露96个端口，并枚举4⁵=1024种耦合配方（若验收条件独立选择则达4⁶=4096种）。我们验证了协同进化循环的两侧。在执行侧，包含65个候选方案的进化轮次找到了一个固定框架，比Pi基准的任务覆盖率提升4.0%，而完整的事后方案组合展示了最高58.0%的额外覆盖率。选定成员随后通过重复运行和官方SWE-bench评估器进行验证。在学习侧，来自该深度验证的200个槽兄弟切片生成了438条经验证的SFT、评论器、过滤器和偏好记录。提升当前执行质量的同一过程，也为明日的模型更新生成所需数据。这些结果共同将源可追溯的框架构建定位为执行期框架演进与后续模型更新之间的可审计接口。代码已发布于https://github.com/HKUDS/HELIX。

###### 目录
1.  [引言](https://arxiv.org/html/2608.13951#S1)
    1.1 [贡献](https://arxiv.org/html/2608.13951#S1.SS1)
2.  [模型–框架协同进化](https://arxiv.org/html/2608.13951#S2)
    2.1 [两个耦合的反馈时间尺度](https://arxiv.org/html/2608.13951#S2.SS1)
    2.2 [框架进化轮次的双重输出](https://arxiv.org/html/2608.13951#S2.SS2)
    2.3 [从验证经验到下一系统状态](https://arxiv.org/html/2608.13951#S2.SS3)
    2.4 [固定框架性能与方案组合产出](https://arxiv.org/html/2608.13951#S2.SS4)
3.  [HELIX系统](https://arxiv.org/html/2608.13951#S3)
    3.1 [框架作为显式干预变量](https://arxiv.org/html/2608.13951#S3.SS1)
    3.2 [源可追溯的端口、原子单元与配方](https://arxiv.org/html/2608.13951#S3.SS2)
    3.3 [预执行检查与配方枚举](https://arxiv.org/html/2608.13951#S3.SS3)
    3.4 [运行时模型–框架交互](https://arxiv.org/html/2608.13951#S3.SS4)
    3.5 [证据平面保持干预身份](https://arxiv.org/html/2608.13951#S3.SS5)
4.  [设计优势](https://arxiv.org/html/2608.13951#S4)
    4.1 [有界修改使构建与重建可行](https://arxiv.org/html/2608.13951#S4.SS1)
    4.2 [持久身份支持跨轮次归因](https://arxiv.org/html/2608.13951#S4.SS2)
    4.3 [证据关联的兄弟轨迹携带经验进入模型更新](https://arxiv.org/html/2608.13951#S4.SS3)
5.  [实验设计](https://arxiv.org/html/2608.13951#S5)
    5.1 [评估目标与研究问题](https://arxiv.org/html/2608.13951#S5.SS1)
    5.2 [基于LiveCodeBench的修复子集](https://arxiv.org/html/2608.13951#S5.SS2)
    5.3 [选定成员的SWE-bench Verified后续评估](https://arxiv.org/html/2608.13951#S5.SS3)
    5.4 [共享模型与尝试协议](https://arxiv.org/html/2608.13951#S5.SS4)
6.  [结果](https://arxiv.org/html/2608.13951#S6)
    6.1 [研究问题1—今日执行：进化能否超越基线？](https://arxiv.org/html/2608.13951#S6.SS1)
    6.2 [研究问题2—快速框架进化带来的执行广度](https://arxiv.org/html/2608.13951#S6.SS2)
    6.3 [研究问题3—用于下次模型更新的学习数据](https://arxiv.org/html/2608.13951#S6.SS3)
7.  [讨论](https://arxiv.org/html/2608.13951#S7)
    7.1 [从更新到重建的回归使改进递归化](https://arxiv.org/html/2608.13951#S7.SS1)
    7.2 [模型–框架组合拥有双重改进前沿](https://arxiv.org/html/2608.13951#S7.SS2)
    7.3 [方案组合覆盖度揭示执行潜力与数据产出](https://arxiv.org/html/2608.13951#S7.SS3)
    7.4 [经验证的失败案例丰富模型更新数据](https://arxiv.org/html/2608.13951#S7.SS4)
8.  [相关工作](https://arxiv.org/html/2608.13951#S8)
    8.1 [递归自我提升与模型–框架协同进化](https://arxiv.org/html/2608.13951#S8.SS1)
    8.2 [框架作为智能体–计算机接口](https://arxiv.org/html/2608.13951#S8.SS2)
    8.3 [自动化框架与工作流演进](https://arxiv.org/html/2608.13951#S8.SS3)
    8.4 [交互数据与可执行软件基准](https://arxiv.org/html/2608.13951#S8.SS4)
9.  [局限性与有效性威胁](https://arxiv.org/html/2608.13951#S9)
    9.1 [评估范围](https://arxiv.org/html/2608.13951#S9.SS1)
    9.2 [改进动因](https://arxiv.org/html/2608.13951#S9.SS2)
    9.3 [尝试与选择的影响](https://arxiv.org/html/2608.13951#S9.SS3)
    9.4 [自动化评估的局限](https://arxiv.org/html/2608.13951#S9.SS4)
    9.5 [数据规模与模型更新](https://arxiv.org/html/2608.13951#S9.SS5)
    9.6 [安全性与维护](https://arxiv.org/html/2608.13951#S9.SS6)
10. [结论](https://arxiv.org/html/2608.13951#S10)
11. [选定成员后续结果](https://arxiv.org/html/2608.13951#A1)
    A.1 [重复LCB评估](https://arxiv.org/html/2608.13951#A1.SS1)
    A.2 [官方SWE-bench评估](https://arxiv.org/html/2608.13951#A1.SS2)
12. [验证器锚定的案例轨迹](https://arxiv.org/html/2608.13951#A2)
    B.1 [Pytest：目标成功但存在回退](https://arxiv.org/html/2608.13951#A2.SS1)
    B.2 [Xarray：清晰的语义接近错过](https://arxiv.org/html/2608.13951#A2.SS2)
13. [参考文献](https://arxiv.org/html/2608.13951#bib)

## 1 引言
扩展智能体能力通常被框架化为模型改进问题。然而，已部署的智能体是一个执行中的模型–运行时组合。在用户请求与最终补丁之间，存在实质性的运行时环节：系统指令、上下文构建、会话状态、工具模式、权限检查、提供商适配、交互循环、重试与压缩策略、终止规则和验证器。我们将此运行时称为**智能体框架**。它并非中立的封装层。通过改变模型的观测内容、可执行操作、故障恢复方式以及终止时机，框架协同决定了智能体可达的行为。模型与框架在两个时间尺度上交互。在单个任务中，框架构建模型的观测与动作接口；模型生成消息与操作；框架检查并执行这些操作，返回环境反馈，并决定交互是否继续。在改进轮次间，这些交互产生的经验证轨迹塑造下一个模型，而更新后的模型成为框架组合重建的条件。因此，递归改进的单元是模型–框架系统而非模型本身：更新后的组合在外部指定的任务、目标和验证器下重新进入同一过程。因此，我们将**模型–框架协同进化**视为递归自我提升的首要原则。

每个框架进化轮次有两个输出。第一个是为当前模型提供更强执行力：进化可以识别更优的固定框架，并在快速构建的方案组合中暴露更多覆盖范围。第二个是为下次模型更新提供数据：匹配的成功案例、性能退化、接近成功和替代方案成为**经验证的兄弟轨迹**。这些输出并非分离的目标。改变当下执行的同一框架干预，构建了明日可用的学习信号。因此，框架既是当前模型的行为算子，也是其后继模型的课程算子。

近期研究已展示基于轨迹的框架适配和框架–模型联合优化[2, 3]。HELIX针对一个互补的系统需求：当运行时行为在异构框架家族间重组时，保持干预身份和经验证据。我们将此交接组织为三个阶段：
1.  **构建**。针对固定模型，在匹配任务上构建并评估显式、源可追溯的框架候选方案。
2.  **更新**。将所得经验证兄弟轨迹转化为学习记录，用于更新模型。
3.  **重建**。为更新后的模型再次进化框架，其能力特征可能偏好不同的运行时设计。

使构建–更新–重建可重复需要超越临时提示或工具更改。现代框架是大型紧耦合系统，因此在组件变更时，干预必须保持显式、可执行和可审计。HELIX提供此基础。它将OpenCode、Pi Mono、Nanobot和Hermes Agent分解为类型化端口、原子单元、配方、产品外壳和运行时策略。预执行检查验证声明的组合，而证据层在执行过程中保留轨迹、测试结果、策略决策、来源信息和结果标签。

我们的评估跟踪一个方案组合逐步深化的过程。完整的65候选LCB进化矩阵识别出一个更强的固定框架，并暴露比Pi最多高58.0%的事后方案组合覆盖度。选定成员随后通过重复运行和官方SWE-bench验证，其兄弟产物生成438条SFT、评论器、过滤器和偏好记录。这些结果共同将当前模型的框架进化与驱动下次协同进化轮次的数据交接联系起来。

### 1.1 贡献
本文有三个贡献：
1.  **系统级递归改进的可审计形式化**。我们将模型–框架协同进化显式化为构建–更新–重建，包含任务级交互循环和跨轮次从验证经验到模型更新与框架重建的回归。
2.  **有界框架修改基础**。HELIX将源衍生的运行时行为表示为类型化端口、原子单元、配方、产品外壳和策略，然后通过预执行检查、组装和证据捕获保持每个声明的干预。
3.  **经验证经验交接**。我们展示快速框架进化如何暴露更强且互补的任务结果，以及相同的匹配展开如何物化为用于模型更新的SFT、评论器、过滤器和偏好记录。

## 2 通过构建–更新–重建实现模型–框架协同进化
上文引入的反馈循环只有在框架同时被视为执行策略和数据生成策略时，才能成为可重复过程。我们将模型–框架组合（而非仅模型）视为被改进的状态。当轮次的验证结果同时决定用于更新模型的数据和用于重建下一框架组合的证据时，此轮次即具有递归性。由于任务、目标和验证器保持外部指定，这是一种有界的、验证器锚定的系统级递归改进形式。

### 2.1 两个耦合的反馈时间尺度
设第 t 轮的系统状态为 Z_t = (M_{θ_t}, Φ_t)，其中 M_{θ_t} 是当前模型，Φ_t = {H_{φ_i}}_i 是为其构建的框架组合。在单个任务内，模型与框架形成快速交互循环：H_{φ_i} 构建上下文并暴露操作，M_{θ_t} 返回消息与工具调用，H_{φ_i} 检查并执行这些操作后返回下一观测或终止。跨轮次时，更慢的改进循环将这些证据转化为模型更新和重建的组合。设任务 x ∼ D，参数为 θ 的模型 M_θ，以及配置和实现参数为 φ 的框架 H_φ。一次运行产生轨迹：
τ_{t,i,x,k} ∼ P(τ | x, M_{θ_t}, H_{φ_i}, k)  (1)
其中 t 索引协同进化轮次，i 为框架候选，k 为尝试序号。轨迹包括模型消息、工具调用与结果、会话事件、工作区效应和终止决策。验证器观测任务、轨迹、工作区差异、测试证据和策略证据：
y_{t,i,x,k} = V(x, τ_{t,i,x,k}, ΔW_{t,i,x,k}, 𝒯_{t,i,x,k}, ℘_{t,i,x,k})  (2)
标签 y 无需二值化，可区分已解决、目标未命中、性能退化、无操作、策略违规、补丁噪声或评估器差异等情况。由于 H_φ 改变了可达轨迹及事后保留的证据，快速交互循环同时决定当前行为和更慢改进循环可用的经验。因此，框架进化轮次必须同时评估其执行价值与学习数据价值。

### 2.2 框架进化轮次的双重输出
对于固定模型，一个部署目标选择在验证奖励上最优、同时考虑运行时成本 C 和策略风险 P 的框架：
J_deploy(M_{θ_t}, H_φ) = E_{x,k}[R(y,τ) − λC(τ) − μP(τ)]  (3)
权重 λ 和 μ 明确表明“解决更多任务”并非唯一部署目标。一个通过过度工具调用、不安全权限或不稳定重试获得成功的框架，可能劣于稍欠精确但可预测的框架。固定框架效用仅为第一个输出。在模型与任务固定时，评估的候选方案也创建兄弟集合：
S_{t,x} = {(H_{φ_i}, τ_{t,i,x,k}, y_{t,i,x,k})}_{i,k}