技术摘要：CRANE——通过零空间编辑为代码智能体注入约束性推理

1. 问题陈述

现代代码智能体必须应对双重需求：它们既需要强大的推理能力（规划、上下文整合及错误恢复）来解决复杂的软件任务，又必须严格遵守工具使用协议（简洁输出、正确的模式格式及规范的工具调用时机），以便与执行环境有效交互。

近期观察表明，成对的模型检查点之间存在错位：

• 指令模型（Instruct Models）： 这些模型简洁且遵守工具规范，但往往缺乏深层规划或恢复行为，导致过早编辑或陷入循环。
• 思考模型（Thinking Models）： 这些模型表现出更强的推理和恢复能力，但往往“过度 deliberation（深思熟虑）”，消耗过多 token，并因违反工具协议或未能采取行动而降低性能。

现有的模型合并技术（如 Task Arithmetic、TIES、SLERP）通常将合并视为端点的对称融合。它们并非专为非对称的代码智能体场景而设计，在该场景中，目标是将“思考”模型中的特定推理行为注入到“指令”骨干网络中，同时严格保留指令模型已部署的工具接口。简单的合并往往会破坏智能体执行所需的协议保真度。

2. 方法论：CRANE

CRANE（通过零空间编辑为代码智能体注入约束性推理）是一种无需训练的参数编辑方法，它将思考模型与指令模型检查点之间的差异向量（$\delta = \theta_{\text{think}} - \theta_{\text{inst}}$）视为候选推理编辑的方向池。它采用三阶段流程，在保留智能体行为的同时选择性地注入这些编辑：

阶段 1：幅度阈值处理（去噪）

原始差异向量 $\delta$ 包含有用的推理信号和噪声。CRANE 应用保守的稀疏化规则以移除低置信度的坐标。

• 机制： 应用确定性的中值幅度阈值。幅度低于 $|\delta|$ 中值的坐标被置零。
• 重缩放： 剩余的非零条目被缩放 2 倍，以大致保持整体更新尺度。
• 目标： 丢弃可能扰动智能体接口但未贡献有意义推理的低幅度噪声。

阶段 2：保守泰勒门控（CTG）

此阶段通过评估特定编辑方向是否同时有利于推理迁移和工具使用保留，来确定每个参数块（层和组件）的注入强度。

• 校准： 使用小型校准集定义两个掩码损失函数：
  • $L_R$（推理）：衡量在由思考模型生成的代码推理提示上的性能。
  • $L_A$（智能体行为）：衡量在由指令模型生成的工具使用提示上的性能。
• 评分： 对于每个坐标 $j$，一阶改进分数计算为 $s_K(j) = -g_{K,j}\delta_j$，其中 $g_K$ 是损失的梯度。
• 门控逻辑： 仅当编辑方向同时是两个损失的下降方向时，坐标才获得正权重：
  $$p_j = [\min\{s_R(j), s_A(j)\}]_+$$
• 聚合： 权重按块聚合，并相对于参考 FFN/专家块进行归一化，以确定最终缩放系数 $S_{\text{CTG}}(c, l)$。

阶段 3：分级 Sigmoid 投影（GSP）

即使是有益的编辑也可能破坏关键格式 token（例如工具分隔符、JSON 模式、聊天模板）。此阶段抑制“格式关键”子空间中的更新。

• 激活收集： 在格式关键轨迹（控制工具调用和模式的 token）上收集指令模型的隐藏状态。
• SVD 投影： 对激活矩阵执行奇异值分解（SVD）。具有高奇异值的方向对应于强烈影响格式关键输出的输入方向。
• 软掩蔽： 不使用硬零空间投影，而是在奇异值空间中应用Sigmoid 掩码。高幅度（格式关键）的方向被显著衰减，而低幅度方向则被保留。这确保了平滑过渡而非不连续的截断。

最终合并后的模型计算如下：
$$\theta_{\text{merged}} = \theta_{\text{inst}} + \Pi_{\text{GSP}} \left( \alpha \cdot S_{\text{CTG}} \cdot T(\delta) \right)$$

3. 主要贡献

1. 方向性合并公式： 一种针对成对指令/思考模型的模型合并新方法，将差异向量视为候选编辑池而非对称目标，并以特定的智能体行为为条件。
2. CRANE 方案： 一个三阶段、无需训练的流水线，结合了稀疏差异提取、工具使用感知的保守泰勒门控以及格式保留的分级 Sigmoid 投影。
3. 实证评估： 在三个基准测试（Roo-Eval、SWE-bench-Verified、Terminal-Bench v2）和两个模型规模（Qwen3-30B-A3B 和 Qwen3-Next-80B-A3B）上进行了全面评估。
4. 消融研究： 分析证实，每个组件（稀疏化器、泰勒门控、投影）对于观察到的性能 - 成本权衡都是必要的。

4. 实验结果

CRANE 在所有基准测试中始终优于各个端点模型和标准合并基线（Task Arithmetic、TIES、SLERP、AIM、LEWIS、RAIN），同时保持了效率。

• Roo-Eval（基于 IDE 的编码）：

  • 30B 规模： 达到 66.2% 的 pass@1，比指令基线（46.7%）高出 19.5%，比最佳替代合并方案高出 19.0%。
  • 80B 规模： 达到 81.5% 的 pass@1，比指令模型高出 8.7%。
  • 效率： CRANE 以更低的总 token 数（TTC）实现了这些提升，在 30B 规模下减少了约 6000 万 token 的使用量。

• SWE-bench-Verified（仓库级问题）：

  • 30B 规模： 解决了 122/500 个实例，优于指令基线（108）和最佳合并基线（113）。
  • 80B 规模： 解决了 180/500 个实例，超越了指令模型（168）及其他所有基线。
  • 效率： CRANE 以低于基线的聚合 token 成本解决了更多实例。

• Terminal-Bench v2（Shell/命令行工作流）：

  • 30B 规模： pass@1 提升至 7.6%（指令模型为 4.8%），pass@5 提升至 17.9%。
  • 80B 规模： pass@1 提升至 14.8%，pass@5 提升至 30.3%。
  • 效率： CRANE 显著减少了挂钟时间（例如，80B 规模下指令模型为 2 小时 28 分钟，而 CRANE 为 1 小时 58 分钟），同时保持了高成功率。

消融发现： 移除任何单一组件（幅度阈值处理、泰勒门控或 GSP）都会导致性能显著下降。值得注意的是，移除 GSP 会导致成功率下降最大，凸显了保留格式关键方向的重要性。

5. 意义与主张

本文主张，CRANE 成功解决了代码智能体中指令模型和思考模型检查点“互补但错位”的特性。通过将合并视为行为条件化的方向编辑问题，而非通用融合，CRANE 注入了思考模型的规划和恢复能力，同时未牺牲指令模型的工具规范性和效率。

作者强调，这些提升并非通过增加 token 预算或延长 rollout 获得的；事实上，CRANE 往往能用更少的 token 和更短的挂钟时间实现更优的结果。该方法提供了一条实用的、无需训练的路径，通过利用推理模型的优势并严格遵守已部署智能体协议的约束，来提升智能体性能。

承认的局限性：

• 该方法假设思考检查点提供有用的推理，而指令检查点提供有用的接口；如果未来的模型在两方面都已表现出色，则简单的合并可能就足够了。
• 校准集必须覆盖已部署的工具表面；工具或格式的重大漂移将需要重新校准。
• GSP 投影器的构建需要在格式轨迹上进行前向传播，这对于非常大的模型来说计算成本可能很高。
• 在某些语言（Java、Rust）上的表现仍低于 Python/JS/Go，这表明基础模型存在潜在的训练不对称性，而非合并方法本身的失败。