论文链接：arxiv.org/abs/2608.06113 PDF 全文：arxiv.org/pdf/2608.06113 发表会议：ASE 2026（IEEE International Conference on Automated Software Engineering） 发表时间：2026 年 8 月 6 日 机构：华为加拿大软件卓越中心（Centre for Software Excellence, Huawei Canada） + 加拿大女王大学（Queen’s University） 作者：Kishanthan Thangarajah, Boyuan Chen, Ahmed E. Hassan 领域标签：cs.SE 软件工程 / CLI Agent / 规划能力内化
一、论文背景
1.1 什么是 CLI Agent？它和代码补全工具有什么区别？
如果你用过 GitHub Copilot、Cursor 之类的工具，你可能会觉得"AI 写代码"已经司空见惯——模型在编辑器里给你补全一两行，或者根据注释生成一个函数。这类工具的本质是代码补全（Code Completion）：模型只负责"写"，不负责"想"和"跑"。
但近两年兴起的一类完全不同的工具叫 CLI Agent（命令行智能体）——它不是一个编辑器插件，而是一个端到端的软件工程助手。你给它一个任务描述（比如"修复 auth.py 里导致用户无法登录的 bug"），它会自主完成以下全部流程：
- 规划：理解任务，拆解出要做的事
- 探索：在你的代码库里搜索相关文件
- 写代码：修改对应的文件
- 执行：在沙箱里运行命令、跑测试
- 观察反馈：看测试是否通过
- 迭代：如果失败，分析原因，修改后重来
整个循环可能持续几十轮，中间不需要你人工干预。它的最终产物往往是一个可以直接合并的 Pull Request。
可以用一个类比来理解两者区别：
| 维度 | 代码补全工具 | CLI Agent |
|---|---|---|
| 工作方式 | 你写一行，它补一行 | 你给任务，它独立完成全部 |
| 介入程度 | 每步都需人在场 | 可异步运行，回来收 PR |
| 能力范围 | 单文件内补全 | 跨多文件、跨命令、跨工具 |
| 形象类比 | 一个聪明的打字员 | 一个能独立交付的初级工程师 |
CLI Agent 是 2025—2026 年软件工程 AI 最炙手可热的方向，主流产品包括 OpenHands、Claude Code、Aider、Cline、OpenCode、SWE-agent 等等。
1.2 什么是 Scaffold（脚手架）？
Scaffold（脚手架） 这个词借用了建筑业的隐喻。在 CLI Agent 语境里，它指的是围绕大语言模型搭建的那一整套外部程序结构——包括提示词模板、工具调用接口、循环控制逻辑、规划与反思机制、文件系统访问方式等等。
换句话说，大模型本身只是"大脑"，而 scaffold 是把这个大脑变成可用工程实体的"身体+神经系统"。同一个模型，装进不同的 scaffold 里，表现会天差地别。
用一个具体例子：把 Claude Opus 4.6 装进 OpenHands，在 SWE-bench Verified 上能跑到 68.4%；但同样的模型直接提示不做任何 agent 循环，分数会大幅下降。中间差的几十个百分点，正是 scaffold 贡献的。
常见 scaffold 及其特点：
| Scaffold | 开发方 | 显式规划机制 | 特点 |
|---|---|---|---|
| OpenHands | All-Hands-AI | 规划散布在 CodeAct 循环中 | 开源、生态最大、76K+ stars |
| Claude Code | Anthropic | 有独立的 Plan Mode | 闭源、原生规划阶段 |
| OpenCode | 社区 | 有独立 Plan agent | 开源、模块化 |
| mini-swe-agent | Princeton | 无显式规划（~100 行 bash-only） | 极简、研究用途 |
| Aider | 社区 | 有 | git-first 的 CLI pair-programmer |
1.3 开源生态的"OpenHands 一家独大"困境
随着 CLI Agent 的快速发展，开源社区涌现了大量"开源 CLI Agent 模型"——通过对开源基座模型（如 Qwen3、Llama、GLM）做后训练（SFT/RL），让它们具备软件工程能力。代表模型包括 SWE-Lego-Qwen3、SWE-Gym 系列、CoderForge、Nebius 等等。
但 DCAS 论文揭示了一个被严重低估的问题：所有这些开源模型，其训练数据（即"agent 轨迹"）几乎全部是在 OpenHands 这一个 scaffold 下采集的。
为什么会这样？因为 OpenHands 是当前最成熟、最易用、社区最大的开源 scaffold。研究者在收集训练数据时，自然倾向于用最顺手、最稳定的工具。这导致了一个隐蔽的后果：
开源 CLI Agent 模型被训练成了"OpenHands 专用模型"——它们在 OpenHands 下表现优异，但一旦换到其他 scaffold，性能会大幅退化。
这就是论文所称的Scaffold Lock-in（脚手架锁定） 问题。
这个问题的危害在于：现实中的开发者和企业选择 scaffold 时，依据是成本、许可、延迟、数据隐私等工程因素，而不是"我的模型当初是在哪个 scaffold 下训练的"。如果一个开源模型只能在 OpenHands 下跑出宣传的分数，那它的"开放性"就大打折扣——你拿到了权重，却没法在任何环境里真正复现那个分数。
1.4 当前方法的核心缺陷
论文的引言部分指出，过去的 CLI Agent 研究存在一个结构性盲区：
- 训练与评估脱节：训练用 OpenHands，评估也用 OpenHands，导致跨 scaffold 的退化问题被系统性地掩盖
- 把 scaffold 当作"外部不变量"：以前的工作默认 scaffold 是固定的，没有去分离"scaffold 贡献了什么" vs “模型贡献了什么”
- 规划能力被外部化：scaffold 提供的规划机制（Plan Mode、CodeAct 等）实际上承担了大量"思考"工作，但模型本身没有学到这种能力
DCAS 论文的核心动机就是：如果我们能搞清楚 scaffold 贡献了什么、模型缺失了什么，就能把"外部 scaffold 能力"转化为"模型自身能力"，从而打破 scaffold 锁定。
二、论文定位和关联工作
DCAS 并非凭空出现，它处在 CLI Agent、Agent 微调、规划能力研究三条脉络的交汇点上。
2.1 CLI Agent scaffold 谱系（基础设施层）
| 工作 | 年份 | 核心贡献 | 与 DCAS 的关系 |
|---|---|---|---|
| ReAct（Yao et al.） | 2022 | 提出 Reason+Act 交替循环，奠定了几乎所有现代 agent 的底层范式 | DCAS 指出所有 CLI scaffold 底层都共享 ReAct 的 act/observe 循环，这是能力可迁移的基础 |
| SWE-agent（Princeton） | 2024 | 用 agent-computer interface 解决真实 GitHub issue，SWE-bench 的基准推动者 | 论文实验中 mini-swe-agent 作为"极简 scaffold"对照 |
| OpenHands（All-Hands-AI） | 2024 | 开源、最成熟的 CLI Agent 平台，CodeAct 架构 | DCAS 的核心诊断对象——它就是"训练生态收敛"的那个单一 scaffold |
| Claude Code（Anthropic） | 2024 | 闭源 scaffold，独立 Plan Mode | DCAS 借助其规划阶段收集 planning-aware 轨迹 |
| OpenCode（社区） | 2025 | 开源、模块化的 CLI Agent | DCAS 跨 scaffold 评估目标之一 |
2.2 开源 Agent 微调谱系（数据层）
| 工作 | 年份 | 训练数据来源 | 关键问题 |
|---|---|---|---|
| SWE-Gym（Pan et al.） | 2024 | 在 OpenHands 下收集 | 训练-评估 scaffold 一致，未暴露锁定问题 |
| Nebius（Trofimova et al.） | 2025 | OpenHands 轨迹 | 同上 |
| SWE-Lego | 2026 | OpenHands 轨迹 | DCAS 诊断的典型受害者——跨 scaffold 暴跌 |
| CoderForge（Ariyak） | 2026 | OpenHands 轨迹 | 同上 |
关键观察：这些工作都默认了"scaffold 一致性"假设，从未系统性地评估跨 scaffold 行为。DCAS 是第一个把这个盲区公开化并给出解决方案的工作。
2.3 规划能力研究谱系（方法层）
- PlanToAction（Liu, 2026）：探索显式 plan-then-execute 范式，但未考虑跨 scaffold 迁移
- Plan-then-Execute 范式：经典 AI 规划的思路，先产生完整计划再执行
- ReAct（Yao, 2022）：把规划和执行交织在一起
DCAS 在此脉络上的创新点是：区分了显式规划与隐式规划两种形式，并经验性地证明它们是可分离的两种能力——这是过去工作没有提出的洞察。
2.4 DCAS 的定位总结
| 维度 | 之前路线 | DCAS 的突破 |
|---|---|---|
| 训练 scaffold | 默认用 OpenHands | 明确诊断这是锁定问题 |
| 评估 scaffold | 与训练相同 | 跨 scaffold 评估作为标配 |
| 规划来源 | 完全依赖 scaffold | 尝试把规划内化为模型能力 |
| 规划概念 | 不区分显式/隐式 | 明确区分并经验性分离 |
| 工具基础设施 | 各 scaffold 不互通 | DCAS 拦截层实现任意 scaffold × 任意模型 |
一句话定位：DCAS 是第一个系统性地把"scaffold 锁定"作为一个独立研究问题提出、诊断并给出可行解法的工作。
三、问题定义
3.1 从现象到本质：scaffold 锁定到底是什么？
具体现象：在 OpenHands 下训练的开源 CLI Agent 模型（如 SWE-Lego-Qwen3-32B），在 OpenHands 下评估能拿到 52.6% Pass@1；但换到 OpenCode 下评估，直接暴跌到 8.4%。
核心洞察：DCAS 作者发现一个关键对比——未经微调的基座模型并不存在这种分化。
| 模型 | OpenHands | Claude Code | OpenCode | mini-swe-agent |
|---|---|---|---|---|
| Qwen3-32B（未微调基座） | 29.0% | 23.2% | 18.4% | 8.0% |
| SWE-Lego-Qwen3-32B（微调后） | 52.6% | — | 8.4% | — |
基座模型在四个 scaffold 间的分差约为 21 个百分点，而微调模型在两个 scaffold 间的分差就达到 44 个百分点。这说明性能分化是微调过程"安装"进去的，而不是 scaffold 接口本身造成的。
3.2 抽象问题：fine-tuning 到底"安装"了什么？
这是论文最关键的洞察。作者提出一个假设：
微调过程在模型身上"安装"的，主要是训练 scaffold 特有的"规划结构"（planning structure）。这种规划结构承担了模型表现中"承重"（load-bearing）的角色——拿掉它，模型就垮了。
论文进一步把"规划结构"拆成两种截然不同的形式：
显式规划（Explicit Planning）
定义：在执行任务前，模型/scaffold 先产生一份"作为独立工件（first-class artifact）的计划"，然后再按计划执行。
类比：就像施工前先画一份完整的施工图。
例子：Claude Code 的 Plan Mode、OpenCode 的 Plan agent——都有一个明确的"先规划、后执行"两阶段结构。
隐式规划（Implicit Planning）
定义：不产生独立的计划工件，但 scaffold 通过结构约定（structural conventions） 在整个 agent 循环中持续塑造执行——比如工作如何拆解为子步骤、探索何时转为行动、工具调用如何排序、失败如何触发重新规划。
类比：没有正式施工图，但有一套成熟的施工流程和默契——老工人看一眼就知道下一步该干啥。
例子：OpenHands 的 CodeAct 循环把规划散布在每一步推理-行动中；mini-swe-agent 几乎没有任何显式规划结构，完全靠 ReAct 循环的隐式约定。
为什么必须做这种区分？
| 维度 | 显式规划 | 隐式规划 |
|---|---|---|
| 存在形式 | 一段可见的计划文本/工件 | 内嵌在执行流程中的约定 |
| 可迁移性 | 容易——计划可以跨 scaffold 共享 | 困难——约定是 scaffold 特有的 |
| 学习难度 | 模型容易学到"生成计划"这个显式动作 | 模型需要学到一整套 turn-by-turn 的行为模式 |
| 论文研究价值 | 可作为干预变量直接测试 | 需要更精细的训练数据设计 |
这个区分的精妙之处在于：它把"scaffold 锁定"这个看似无解的工程问题，抽象成了一个可以科学研究的对象——你可以分别操控显式规划和隐式规划，看它们对性能的独立贡献。
3.3 形式化的问题定义
给定：
- 一个开源基座模型 $\mathcal{M}_{base}$（如 Qwen3-32B）
- 一组 scaffold $\mathcal{S} = \{s_1, s_2, ..., s_n\}$（OpenHands、Claude Code、OpenCode、mini-swe-agent 等）
- 一个基准测试 $\mathcal{B}$（SWE-bench Verified）
观察到的现象：
$$\text{Gap}(\mathcal{M}_{FT}, s_{train}, s_{test}) = \text{Perf}(\mathcal{M}_{FT}, s_{train}) - \text{Perf}(\mathcal{M}_{FT}, s_{test})$$其中 $\mathcal{M}_{FT}$ 是在 $s_{train}$ 下微调的模型，且当 $s_{test} \ne s_{train}$ 时这个 Gap 显著大于 0。
求解目标：找到一个训练流程 $\mathcal{T}$，使得微调后的模型 $\mathcal{M}_{DCAS}$ 满足：
$$\forall s_i \in \mathcal{S}: \text{Perf}(\mathcal{M}_{DCAS}, s_i) \geq \text{Perf}(\mathcal{M}_{base}, s_i) + \delta$$即在所有 scaffold 上都有一致提升，而非只在某个 scaffold 上爆发。
约束：
- 不能修改 scaffold（闭源的 Claude Code 改不了）
- 不能依赖大规模 frontier 模型做推理（否则失去"开源"意义）
- 训练数据要能在任意 scaffold 下采集
3.4 抽象的精妙之处
这个抽象的精妙之处有三点：
- 把工程问题变成了科学问题：不再是"为什么我的模型不行"，而是"规划结构中哪一部分是承重的"
- 显式/隐式规划的分离让因果干预成为可能——你可以分别测试拿掉哪一种规划会让模型退化多少
- 把"scaffold 能力"重新定义为"模型能力"——这是从"依赖外部工具"到"内化到参数"的范式跃迁，本质上是一种能力迁移
四、问题解法
DCAS 的解法分为三层：基础设施层（DCAS 拦截层）、诊断层（plan-source 干预）、治疗层（planning-aware 微调）。我们逐一展开。
4.1 基础设施：DCAS 后端替换拦截层
要解决的问题
要做跨 scaffold 研究，必须能用同一个模型跑多个 scaffold，并且能在任意 scaffold 下采集训练数据。但现实里存在两个硬障碍：
- 闭源 scaffold 的模型绑定：Claude Code 设计上只接 Anthropic 自己的 API，你没法把 Qwen3 接进去
- 各 scaffold 的 API 格式不统一：每个 scaffold 假设的后端协议都不同
DCAS 的做法：API 流量拦截
DCAS（Decoupling CLI Agent Scaffolding）是一个位于 scaffold 和模型后端之间的代理层。它的核心思路类比于 Web 安全里的"中间人代理"——所有从 scaffold 发出的 API 请求都会先经过 DCAS，再被转发到真正的模型后端。
| 组件 | 输入 | 输出 | 作用 |
|---|---|---|---|
| CLI scaffold（如 Claude Code） | 用户任务 | 向"模型 API"发出的请求 | 不变——它以为自己在和原生后端对话 |
| DCAS 拦截层 | scaffold 发出的请求 | 转发到任意指定后端 | 透明代理，记录流量，改写后端地址 |
| 实际模型后端（如 Qwen3-30B） | DCAS 转发来的请求 | 模型输出 | 不变——它以为自己在和原生客户端对话 |
关键设计：不修改 scaffold 本身。这一点至关重要，因为：
- 闭源 scaffold（Claude Code）改不了
- 修改开源 scaffold 会污染实验——你想测的是"scaffold 原貌下的行为"
DCAS 解锁的三件事
- 跨 scaffold 评估同一模型：同一个 Qwen3-30B 可以在 Claude Code、OpenHands、OpenCode、mini-swe-agent 下评估，结果可比
- 跨 scaffold 轨迹采集：可以在任意 scaffold 下记录"模型+scaffold"的完整轨迹，作为训练数据
- 不依赖 frontier 模型推理：评估和推理都用开源后端，避免了"看起来开源，实际上离不开 Claude/GPT"的伪开源陷阱
4.2 诊断层：Plan-Source 干预实验
有了 DCAS 这个基础设施，作者设计了第一个关键实验——Plan-Source Intervention（计划源干预），用来回答"规划到底值多少钱"。
实验设置
- 执行器（executor）：Qwen3-Coder-30B-A3B-Instruct（开源 30B 模型）
- scaffold：Claude Code 2.0.76（有独立 Plan Mode）
- 基准：SWE-bench Verified
- 最大轮数：100 轮
- 干预变量：计划的来源——由谁/什么模型生成 plan
四个实验组
| 组别 | 计划来源 | Pass@1 | 与上一组的差值 |
|---|---|---|---|
| 1 | 无计划 | 42.8% | — |
| 2 | 模型自己规划（self-plan） | 48.2% | +5.4 |
| 3 | 开源规划器 Qwen3-Coder-480B-A35B | 49.2% | +1.0 |
| 4 | 前沿规划器 Claude Sonnet 4.5 | 57.8% | +8.6 |
关键洞察
- 计划质量的杠杆效应：从"无计划"到"前沿模型计划"，纯靠计划质量提升了 15 个百分点（57.8% - 42.8%）。这个幅度甚至超过了跨 scaffold 的退化幅度（SWE-Lego 从 OpenHands 到 Claude Code 退化约 8.4 个百分点）
- 规划器能力随规模分层：模型自己规划（48.2%） < 开源 480B 规划器（49.2%） < 前沿规划器（57.8%）。计划质量随规划器能力单调提升
- 一个反直觉发现：作为规划器，Claude Sonnet 4.5 反而优于 Claude Opus 4.5。作者的解释是——Sonnet 4.5 产生的计划更"贴合 30B 执行器的能力轮廓"，而 Opus 4.5 的计划可能过于激进，30B 模型执行不了
- 核心结论：对于固定的执行器模型，你给它的计划可能比你换一个更强的执行器更值钱
4.3 治疗层：Planning-Aware 轨迹微调
诊断实验确认了"规划是高杠杆组件"后，下一个问题是：能不能通过训练，把规划能力内化到模型参数里？
训练数据采集
- 数据源 scaffold：Claude Code 2.0.76（因为它有明确的 Plan Mode，方便分离两种规划）
- 轨迹源模型：GLM-4.7（故意不用 frontier 模型——这样可以确保任何性能提升都来自 scaffold 的规划约定，而不是从 frontier 模型"蒸馏"出来的）
- 轨迹数量：576 条两阶段（plan + execute）轨迹
- 通过 DCAS 采集：DCAS 拦截并记录 Claude Code + GLM-4.7 的完整对话
两个数据集变体
为了分离显式规划与隐式规划，作者构造了两个训练集：
| 数据集 | 包含的规划形式 | 用途 |
|---|---|---|
| PlanOnly | 仅隐式规划（执行轨迹的结构约定） | 测试隐式规划单独能带来什么 |
| Plan+Exec | 显式计划 + 执行轨迹（两种都有） | 测试加上显式规划后有什么增量 |
训练配置
- 方法：Full-parameter SFT（全参数监督微调）
- 工具：LLaMA-Factory
- 上下文长度：65K
- 精度：BF16
- 被训练模型：Qwen3-Coder-30B-A3B-Instruct（与诊断实验相同的执行器）
训练结果
| 训练集 | 推理时无 plan | 推理时 self-plan | self-plan 增量 |
|---|---|---|---|
| 基线（未微调） | 42.8% | 48.2% | +5.4 |
| PlanOnly | 53.8% | 53.8%（无提升） | 0 |
| Plan+Exec | 52.8% | 55.8% | +3.0 |
| 外部 frontier planner（参照） | 57.8%（来自 Sonnet 4.5） | — | — |
两个关键发现
发现 1：PlanOnly 训练把隐式规划"烤"进了模型
PlanOnly 训练后，模型在"无 plan"设置下直接达到 53.8%，比未微调基线高 11 个百分点。更有意思的是——此时再给推理时的 self-plan，性能没有任何提升（还是 53.8%）。
这说明：隐式规划已经被内化进 turn-by-turn 的行为里，外部的 plan 已经无增量可加。模型不再需要外部规划阶段，因为它"随时都在规划"。
发现 2：Plan+Exec 训练保留了显式规划能力
Plan+Exec 训练后，模型无 plan 时是 52.8%（略低于 PlanOnly），但开启 self-plan 后能再涨 3 个百分点，达到 55.8%——接近外部 frontier planner 的 57.8%，但推理时完全不需要 frontier 模型。
这说明：显式规划和隐式规划是两种可分离的能力，可以在训练数据层面分别操控。这个发现直接验证了论文第三章的理论区分。
全景对比表
| 配置 | 推理时需要 frontier 模型？ | Pass@1 | 适用场景 |
|---|---|---|---|
| 未微调 + 无 plan | 否 | 42.8% | 基线 |
| 未微调 + Sonnet 4.5 plan | 是 | 57.8% | 强但依赖闭源 |
| PlanOnly 微调 + 无 plan | 否 | 53.8% | 纯开源、即开即用 |
| Plan+Exec 微调 + self-plan | 否 | 55.8% | 开源、接近最强 |
五、评估指标与实验证据
5.1 评估指标体系
| 指标 | 定义 | 衡量的能力 | 论文中的角色 |
|---|---|---|---|
| Pass@1 | 单次尝试中模型成功解决 SWE-bench Verified 任务的比率 | 端到端软件工程能力 | 主指标，所有 RQ 都用它 |
| Cross-scaffold Gap | 同模型在不同 scaffold 下的 Pass@1 差值 | scaffold 锁定程度 | 诊断指标，衡量问题严重性 |
| Plan-source Gain | 固定执行器，更换计划源带来的 Pass@1 提升 | 规划质量的杠杆效应 | 验证"规划是高杠杆组件" |
| Generalization Gain | 在非训练 scaffold 上的 Pass@1 提升 | 规划能力的可迁移性 | 验证"内化而非记忆" |
5.2 基准选择
- SWE-bench Verified：SWE-bench 的精校子集，包含真实 GitHub issue 和对应的通过测试。是 CLI Agent 评估事实上的行业标准。
- 为什么选它：(1) 任务足够难，能区分方法优劣；(2) 社区公认，结果可比；(3) 规模适中，可承受多 scaffold × 多模型的矩阵实验
5.3 三个研究问题的实验设计
论文围绕三个 Research Question（RQ）展开：
RQ1：规划质量值多少钱？（Plan-Source Intervention）
实验设计：固定执行器（Qwen3-30B）和 scaffold（Claude Code 2.0.76），只改变计划源——从"无计划"到"self-plan"到"开源规划器"到"frontier 规划器"。
结论：计划源带来的最大增益是 15 个百分点（42.8% → 57.8%），超过了跨 scaffold 的退化幅度。这意味着对于一个固定执行器，计划质量是比模型选择更高杠杆的变量。
RQ2：规划能力能否被内化？（Planning-Aware Fine-tuning）
实验设计：在 Claude Code 下通过 DCAS 采集 576 条两阶段轨迹，用 PlanOnly 和 Plan+Exec 两种变体分别微调同一个 30B 执行器。
结论：两种变体都能显著提升基线（+11% 和 +10%），且 PlanOnly 把隐式规划完全内化（推理时不需要 plan），Plan+Exec 保留了显式规划能力（self-plan 再加 3 个百分点，达到 55.8%）。
RQ3：内化的能力能否跨 scaffold 泛化？（Cross-scaffold Generalization）
实验设计：把 Plan+Exec 微调后的模型部署到训练时从未见过的 scaffold——OpenCode 和 mini-swe-agent——上评估。
结果：
| Scaffold | 是否在训练中见过 | 微调后 Pass@1 | 相对基线变化 |
|---|---|---|---|
| Claude Code 2.0.76（训练 scaffold） | 是 | 55.8%（self-plan） | 基线 |
| Claude Code 2.1.73（新版本） | 否（版本不同） | 57.2% | +1.4 |
| OpenCode | 否 | 基线 + 3.4% | 泛化 |
| mini-swe-agent | 否 | 基线 + 7.0%（self-plan） | 泛化更强 |
结论：学习到的行为是结构性的，不是 scaffold-specific 的记忆。在最陌生的 mini-swe-agent（一个只有 ~100 行 bash 的极简 scaffold）上反而获得了最大的 +7.0% 提升——说明微调学到的是普适的规划能力，而不是对某个 scaffold 的适配。
5.4 关键指标如何证明论文核心主张
| 论文核心主张 | 支撑指标 | 实验证据 |
|---|---|---|
| 存在 scaffold 锁定 | Cross-scaffold Gap | SWE-Lego 在 OpenHands→OpenCode 暴跌 44 个百分点 |
| 锁定由微调安装 | 基座 vs 微调模型对比 | 基座模型跨 scaffold 分差 21%，微调后达 44% |
| 规划是高杠杆组件 | Plan-source Gain | 15 个百分点的纯规划增益 |
| 规划可被内化 | RQ2 结果 | PlanOnly+Plan+Exec 都显著超越基线 |
| 内化能力可跨 scaffold 泛化 | RQ3 结果 | 非训练 scaffold 上一致提升 +3.4% ~ +7.0% |
| 显式/隐式规划可分离 | PlanOnly vs Plan+Exec | PlanOnly 推理时不需要 plan，Plan+Exec 仍能从 plan 受益 |
六、效果优势的根源解释
为什么 DCAS 的方法能在指标上取得如此一致的提升？这一节从根源上建立"方法差异→机制变化→指标提升"的因果链。
6.1 Baseline 的根本局限：规划被外部化导致的"能力幻觉"
Baseline 做了什么？
过去所有的开源 CLI Agent 微调（SWE-Gym、SWE-Lego、Nebius、CoderForge）都遵循同一个套路：
- 在 OpenHands 下跑大量任务，收集成功轨迹
- 用这些轨迹做 SFT 训练开源模型
- 在 OpenHands 下评估，报告高分数
Baseline 为什么曾经有效？
在 OpenHands 下评估时，模型并不只是在"回忆"训练数据——它是在一个完全相同的 scaffold 环境里运行。OpenHands 的 CodeAct 循环、工具调用格式、失败重试策略，这些"脚手架结构"在训练和评估时完全一致。
此时模型的高分数实际上是**“模型能力 + OpenHands 规划结构”的合力。但研究者和用户往往把这个合力误认为纯粹的模型能力**——这就是"能力幻觉"。
Baseline 的根本局限：能力没有被内化
一旦换到非训练 scaffold：
- OpenHands 的 CodeAct 循环没有了——模型失去了它依赖的隐式规划约定
- 工具调用格式不同——模型发出的指令对不上新 scaffold 的接口
- 失败重试策略不同——模型不知道何时该重新规划
机制层面的瓶颈：规划能力被外部化为 scaffold 制品，模型参数里并没有真正的"规划能力"——只有"在特定 scaffold 下执行计划的能力"。这不是一个可以靠"更多数据"或"更大模型"解决的问题，而是能力所在位置的错误——能力被放在了外部，而不是内部。
6.2 DCAS 方法的根本性改变
DCAS 方法不是在 baseline 上"做加法"，而是改变了能力所在的层级——从 scaffold 制品转移到模型参数。
因果链 1：显式/隐式规划分离 → 训练数据可控
方法差异：DCAS 在收集训练数据时，通过 Claude Code 的 Plan Mode 天然分离了两阶段，并能分别构造 PlanOnly 和 Plan+Exec 两种数据集。
机制变化：过去所有工作训练的是"一锅粥"——显式规划、隐式规划、scaffold 特定的工具调用格式全部混在一起，模型分不清哪部分是普适能力、哪部分是 scaffold 适配。DCAS 让这两种信号变得可分离、可独立操控。
指标体现：PlanOnly 训练后推理时不需要 plan 也能达到 53.8%，说明隐式规划被干净地内化了；Plan+Exec 还能再从 self-plan 获益 3 个百分点，说明显式规划能力作为独立技能被学到了。这种"分离可加性"在 baseline 上是不可能观察到的。
因果链 2：用 GLM-4.7 而非 frontier 模型采集轨迹 → 切断蒸馏混淆
方法差异：DCAS 用 GLM-4.7（一个非 frontier 的开源模型）作为轨迹源模型，而不是 Claude/GPT。
机制变化：如果用 frontier 模型采集轨迹，后续微调的增益就有了"从 frontier 模型蒸馏"和"从 scaffold 规划约定学习"两种不可分离的解释。用 GLM-4.7 后，任何性能提升都只能归因于 scaffold 的规划约定——因为 GLM-4.7 本身没有 frontier 水平的能力可以"教给"30B 模型。
指标体现：PlanOnly 提升 +11%，Plan+Exec 提升 +13%（无 plan / self-plan）。这些增益只能来自 Claude Code scaffold 暴露的规划结构，反证了 scaffold 规划约定的独立价值。
因果链 3：DCAS 拦截层 → 跨 scaffold 评估与训练
方法差异：DCAS 让任意 scaffold × 任意模型的组合成为可能。
机制变化：过去"训练 scaffold = 评估 scaffold"的闭环被打破。现在可以：
- 在 Claude Code 下训练（利用其规划结构）
- 在 OpenCode、mini-swe-agent 下评估（验证泛化）
- 同一个模型在不同 scaffold 下的表现可以直接对比
指标体现：RQ3 中模型在非训练 scaffold（OpenCode +3.4%，mini-swe-agent +7.0%）上一致提升，这是 baseline 根本无法测量的维度——baseline 在非训练 scaffold 上只会退化。
因果链 4：规划从制品到能力 → 普适性提升
方法差异：DCAS 的核心思想是把规划"从 scaffold 制品内化为模型能力"。
机制变化：内化后的规划能力不再依赖特定 scaffold 的结构约定，而是变成模型 turn-by-turn 行为的一部分。模型在任何 ReAct 风格的 scaffold（即所有 CLI scaffold）下都能调用这种能力。
指标体现：在最陌生的 mini-swe-agent（~100 行 bash-only，没有任何显式规划结构）上，微调后的模型反而获得了最大的 +7.0% 提升——因为 mini-swe-agent 本身几乎不提供规划支持，模型内化的规划能力在这里价值最大。这个结果反证了"能力内化"的成功——越是不提供外部支持的 scaffold，内化能力的增益越明显。
6.3 反事实推理：如果去掉 DCAS 的关键设计会怎样？
| 去掉的设计 | 预期退化 | 依据 |
|---|---|---|
| 去掉 Plan/Exec 分离，用混合数据训练 | 无法区分两种规划的贡献，RQ2 的洞察消失 | 论文 PlanOnly vs Plan+Exec 的对比就是反例 |
| 去掉 DCAS 拦截层，只在 OpenHands 下训练评估 | 回到 baseline 的 scaffold 锁定陷阱 | 这正是 SWE-Lego 等模型的现状 |
| 用 Claude Opus 4.5 替代 GLM-4.7 采集轨迹 | 增益无法归因——可能是蒸馏也可能是 scaffold 约定 | 论文刻意选 GLM-4.7 的设计动机 |
| 只在训练 scaffold 上评估 | 看似分数更高，但无法证明泛化 | 这正是过去工作的盲区 |
6.4 根源总结
DCAS 的优势不是"凑巧好"，而是结构上必然更好：
- 能力位置正确：把规划从外部制品放到模型参数里，这是"治本"而非"治标"
- 信号干净：显式/隐式规划分离 + 非 frontier 轨迹源，让因果归因清晰
- 评估全面：DCAS 拦截层让跨 scaffold 评估成为标配，消除了 baseline 的评估盲区
- 泛化内建：目标是"在所有 scaffold 上一致提升"而非"在某个 scaffold 上爆发"，这是一个更难但更有价值的优化目标
七、必要知识反推
假设找一个完全没有知识和信息的人去做 DCAS 这个工作，他最少必须掌握哪些知识？这些知识又是在什么关键节点上融合的？
7.1 领域知识层（研究对象的基本运作机制）
| 必须掌握的知识 | 为什么必须 | 不掌握会怎样 |
|---|---|---|
| CLI Agent 的完整执行循环（ReAct、工具调用、失败重试） | 这是研究对象本身 | 无法识别哪些行为是"规划" |
| 各主流 scaffold 的架构差异（OpenHands 的 CodeAct、Claude Code 的 Plan Mode、mini-swe-agent 的极简循环） | 这是诊断 scaffold 锁定的前提 | 无法设计跨 scaffold 评估 |
| SWE-bench Verified 的任务结构和评估协议 | 这是衡量成败的尺子 | 无法报告可信数字 |
| 后训练（SFT/RL）的基本流程 | 这是"治疗"手段 | 无法把规划能力内化到模型 |
7.2 方法论知识层（研究脉络与抽象方法）
| 必须掌握的知识 | 为什么必须 | 不掌握会怎样 |
|---|---|---|
| ReAct 范式及其在 agent 中的普遍性 | 这是"为什么内化能力可跨 scaffold 迁移"的理论依据 | 无法论证泛化的合理性 |
| 显式规划 vs 隐式规划的哲学/认知科学区分 | 这是论文核心洞察的概念基础 | 会把 scaffold 锁定当成单一问题，无法做精细干预 |
| 因果干预实验设计（控制变量、干预源） | 这是 Plan-Source 实验的方法论支撑 | 无法得出"规划是高杠杆组件"的结论 |
| 知识蒸馏 vs 结构学习的区别 | 这是选择 GLM-4.7 而非 frontier 模型的设计依据 | 增益归因会被蒸馏混淆 |
7.3 工程知识层（系统实现）
| 必须掌握的知识 | 为什么必须 | 不掌握会怎样 |
|---|---|---|
| HTTP/HTTPS API 代理与流量拦截 | 这是 DCAS 拦截层的实现基础 | 无法在不修改 scaffold 的前提下接入任意后端 |
| 主流 scaffold 的 API 协议（Anthropic API、OpenAI API、OpenHands 协议） | DCAS 需要理解并转发这些协议 | 拦截层无法工作 |
| LLaMA-Factory 等开源微调工具链 | 这是实际训练的基础设施 | 无法复现训练流程 |
| BF16 训练、65K 长上下文训练的工程配置 | 这是训练稳定性的保障 | 训练会失败或效果不好 |
7.4 知识融合的关键节点
DCAS 论文的创造性不在任何单一知识点上，而在几个关键融合节点：
融合节点 1：scaffold 架构差异 × 因果干预设计
要设计 Plan-Source 实验，必须同时理解：
- 不同 scaffold 的规划机制差异（领域知识）
- 如何用控制变量法设计干预（方法论知识）
只有两者结合，才能想到"固定执行器和 scaffold，只换计划源"这个精妙的实验设计。
融合节点 2：API 拦截工程 × 规划概念分离
DCAS 拦截层不只是一个技术工具——它的设计直接服务于"显式/隐式规划分离"这个概念目标：
- 在 Claude Code（有 Plan Mode）下采集 → 天然能分离两阶段
- 通过拦截层记录完整 API 流量 → 能精确切分 plan 阶段和 execute 阶段的轨迹
工程实现和概念目标在这里高度耦合。
融合节点 3：非 frontier 轨迹源 × 归因清晰度
选择 GLM-4.7 而非 Claude Sonnet 作为轨迹源，这个看似工程性的决定，实际上是为了让"内化 scaffold 规划"和"蒸馏 frontier 能力"两种解释可分离。没有这个设计，整篇论文的因果论证都会塌掉。
八、论文中可以提取的通用性灵感
DCAS 虽然是 CLI Agent 领域的工作，但它揭示的原理具有明显的普适性。
8.1 灵感一：能力所在的位置比能力本身更重要
核心思想：一个能力是存在于外部工具/规则/流程中，还是内化到模型/人的参数里，决定了它的可迁移性。外部能力只能在其原始上下文中发挥作用；内化能力则可以跨上下文使用。
论文证据：OpenHands 微调的模型在 OpenHands 下分数很高，但能力实际在 OpenHands 的 scaffold 里，不在模型里——换 scaffold 就垮。DCAS 把规划能力从 scaffold（外部）迁移到模型参数（内部），模型才能跨 scaffold 一致工作。
推广场景：
- RAG vs 长上下文微调：RAG 把知识放在外部检索系统里，微调把知识放进参数——两者的迁移性和成本结构完全不同
- 企业流程改进：把"最佳实践"写成 SOP 文档（外部化）vs 培训员工掌握底层思维模型（内化）——后者的适应面更广
- 编程教育：教学生"用什么算法"（外部）vs 教学生"怎么想出算法"（内化）
- Agent 工具使用：硬编码工具调用规则（外部）vs 让模型学会"什么时候需要工具"（内化）
8.2 灵感二：双系统分离让干预可科学化
核心思想：当一个复杂行为由两种不同机制的合力构成时，把它们清晰区分开，就能分别研究、分别干预、分别优化。混为一谈时，任何结果都难以归因。
论文证据：论文把"规划"拆成显式（pre-execution plan）和隐式（structural conventions）两种，然后能分别构造 PlanOnly 和 Plan+Exec 数据集，分别测量它们的独立贡献。这种分离让"规划是高杠杆组件"这个结论变得可验证。
推广场景：
- 多模态学习：把"视觉理解"拆成"对象识别"和"关系推理"，分别训练和评估
- 代码评审：把"找 bug"拆成"语法层问题"和"语义层问题"，分别用不同工具
- 员工绩效管理：把"业绩"拆成"执行能力"和"决策能力"两个维度分别评估
- 健康干预：把"减重"拆成"饮食控制"和"运动消耗"两个独立变量
8.3 灵感三：基础设施先于洞察——工具决定能看见什么
核心思想：很多研究洞察不是"想到了"，而是"终于能看见了"。能看见的前提是有合适的测量基础设施。先建工具，洞察自然会来。
论文证据：没有 DCAS 拦截层，就无法做跨 scaffold 评估；无法跨 scaffold 评估，就看不见 scaffold 锁定现象；看不见现象，就无从诊断和治疗。DCAS 这个基础设施的存在，本身就是一个核心贡献——它让"不可见的问题"变成了"可研究的问题"。
推广场景：
- 可观测性系统：APM、日志、追踪——没有它们，性能问题就是"玄学"
- 机制可解释性：SAE 等工具让"模型内部"从黑箱变为可观察对象
- A/B 测试平台：没有它，产品决策只能靠"拍脑袋"
- 临床试验的对照组机制：没有对照组，“药物是否有效"就无从回答
8.4 灵感四：评估维度决定优化方向——评估在哪里，改进就在哪里
核心思想：你会优化你被评估的东西。如果评估只在一个维度上做，改进也会只发生在那个维度上，即使其他维度已经悄悄退化。
论文证据：过去所有开源 CLI Agent 都在训练 scaffold 下评估，所以都在训练 scaffold 上表现最好——但跨 scaffold 能力悄悄退化了，没有人测量也就没有人发现。DCAS 把"跨 scaffold 一致提升"作为新的评估维度，优化方向立刻就变了。
推广场景：
- 机器学习模型的公平性：如果不评估不同子群上的表现，模型就会在少数群体上悄悄退化
- 软件系统的韧性：如果不评估故障场景下的表现，系统就会在异常情况下崩溃
- 教育的全面发展：如果只考阅读，数学和社交能力就会被忽视
- 企业的可持续性：如果只评估短期利润，长期品牌和员工健康就会退化
8.5 灵感五：用弱者做老师可以避免混淆
核心思想：当你想证明"某种结构/方法/流程本身有价值"时，应该用能力较弱的实例来体现这种结构——这样任何增益都只能归因于结构，而不是实例本身的能力。
论文证据：DCAS 用 GLM-4.7（非 frontier 模型）作为轨迹源，确保后续微调的增益只能来自 Claude Code scaffold 的规划约定，而不是从 frontier 模型蒸馏出来的能力。如果用 Claude Sonnet 做 trajectory source，读者就有理由质疑"增益到底是 scaffold 的功劳还是蒸馏的功劳”。
推广场景：
- 教学法研究：用普通老师讲一门新教学法，学生提升更能归因于教学法本身
- A/B 测试中的控制组设计：避免"天花板效应"污染结论
- 工艺改进验证：用普通工人验证新工艺，而不是用最熟练的工匠
- 管理咨询：用普通团队试点新流程，效果更可归因于流程本身
附录：关键术语速查
| 术语 | 含义 |
|---|---|
| CLI Agent | 通过命令行交互的自主软件工程智能体 |
| Scaffold（脚手架） | 围绕大模型搭建的外部程序结构（提示词、工具、循环、规划等） |
| Scaffold Lock-in | 微调后的模型只能在训练 scaffold 下正常工作的现象 |
| Explicit Planning（显式规划） | 执行前产生的独立计划工件 |
| Implicit Planning（隐式规划） | 内嵌在执行流程中的结构约定 |
| DCAS | 论文提出的后端替换拦截层，解耦 scaffold 与模型后端 |
| Plan-Source Intervention | 固定执行器，只改变计划来源的因果干预实验 |
| PlanOnly / Plan+Exec | 两种训练数据变体，分别只含隐式规划 / 同时含两种规划 |
| SWE-bench Verified | 真实 GitHub issue 的端到端软件工程基准 |
| Pass@1 | 单次尝试的成功率，是论文的主指标 |