DCAS：解耦CLI智能体脚手架以让规划能力跨脚手架内化 DCAS: Decoupling CLI Agent Scaffolding to Internalize Planning across Scaffolds
把规划从脚手架固定产物变成可跨脚手架迁移的模型能力
前置知识
CLI 智能体脚手架（CLI agent scaffold）
把语言模型变成自主编码智能体的那层外壳框架：它管理智能体循环、向模型暴露一组工具、组织多轮对话、并决定智能体何时结束。本文研究的四款脚手架（OpenHands、Claude Code、OpenCode、mini-swe-agent）在规划结构上差异最大，但底层都跑同一个 ReAct 式的“行动—观察”循环。
全文的核心论点是：跨脚手架性能退化本质上是一种“脚手架约定不匹配”，而脚手架最核心的承重约定就是规划结构。
显式规划与隐式规划（explicit vs. implicit planning）
本文把规划拆成两层。显式规划指执行前产出一个作为一等对象的计划（如 Claude Code 的 Plan Mode）；隐式规划指脚手架逐轮施加的结构化行为——子步粒度、何时从探索转入行动、工具调用如何串联、失败如何触发重规划。论文的核心贡献之一就是证明这两层在训练数据里可被干净分离。
理解这两层是读懂全文方法（PlanOnly vs Plan+Exec 两个训练变体）与全部实验结果的前提。
SWE-bench Verified
一个人工筛选的 500 道真实 GitHub issue 子集，每题都有确定性可验证的补丁解。本文统一用它做评测，指标为 Pass@1（单次尝试解出的题目占比），执行阶段一律上限 100 轮，规划阶段上限 500 轮。
所有 RQ 的对比数据都在 SWE-bench Verified 上以 Pass@1 报告，看懂表格需要知道这个基准和指标的含义。
监督微调（SFT）与拒绝采样
用源模型跑任务、只保留补丁被验证通过的轨迹来构造训练数据（即拒绝采样），再对这些 per-turn 样本做全参数监督微调。本文用 LLaMA-Factory，学习率 $\eta = 4.0\times10^{-6}$、余弦调度、65,536 token 上下文、BF16、Flash Attention 2、DeepSpeed ZeRO Stage 3。
RQ2/RQ3 的“规划内化”本质就是一次小规模（576 条轨迹）的拒绝采样 SFT，理解它才知道增益从何而来。
ReAct 式执行循环（act/observe loop）
模型发出一个动作或规划步骤，脚手架回传一个观察，循环往复直到完成。所有四款脚手架底层都共享这个循环，因此模型具备在其他脚手架下运行的能力，缺的只是对各家规划约定的熟悉度——这是本文立论的关键推断。
这是“跨脚手架退化不是能力缺陷而是规划约定不匹配”这一推断的逻辑支点。
研究动机
当前开源 CLI 智能体生态高度依赖单一训练环境：SWE-Gym、Nebius、SWE-Lego、CoderForge 等主流轨迹数据集几乎全部在 OpenHands 脚手架下采集，微调后的模型在 OpenHands 下表现优异，部署到非训练脚手架性能便大幅退化。作者在四个 30B–32B 顶级开源模型上系统测了这一现象（Table 1）：SWE-Lego-Qwen3-32B 从 OpenHands 的 52.6% 跌到 OpenCode 的 8.4%（工具调用格式与 OpenCode 解析器不兼容）；Nebius-SWE-Rebench-30B 从 49.7% 跌到 mini-swe-agent 的 20.4%，崩塌 29 个百分点；SERA-32B 从 54.2% 跌到 26.4%。失败分三类：随脚手架“距离”递增的退化、工具格式不兼容的硬失败、上下文长度冲突（SERA、Nex-N1 微调到 32,768 token，与 Claude Code 硬编码的 32,000 token 输出上限冲突）。关键在于，这些模型的未训练基座在四个脚手架间差异明显更小，说明跨脚手架退化是微调“装”进去的而非能力缺陷；即便 Nex-N1 用多格式混合训练，OpenCode（26.2%）、mini-swe-agent（15.6%）仍大幅退化。
本文的目标是本文要查清跨脚手架部署鸿沟的成因，并在不进行脚手架专门重训的前提下把它补上。具体目标分三层：第一，定位这种退化的机制——证明它是某种被微调“安装”进去、脚手架间明显不同、模型能学会遵循的行为；第二，定量验证规划结构（显式规划与隐式规划两层）就是这个承重行为，并测出它的影响量级；第三，用少量规划感知轨迹训练出单一开源模型，使其在多个非训练脚手架上稳定保持性能，理想情况下在不依赖推理期外部规划器的前提下，逼近或匹配外部规划器注入（约 57.8%）的效果。可量化的成功标准是：一个 30B 模型在新版 Claude Code、OpenCode、mini-swe-agent 上的 Pass@1 都相对基座无规划基线正向提升，证明学到的是可迁移的结构化技能而非脚手架记忆。
与已有工作不同的是，以往工作普遍把性能提升押在数据规模和轨迹数量上——SWE-Gym、Nebius、CoderForge 都是数千到数万条轨迹，且集中在 OpenHands 下采集。本文切入的角度截然不同：它认为跨脚手架退化本质是“规划约定不匹配”，而承重信号其实藏在每条轨迹的规划结构里，而非数据量里。一个关键但被忽视的洞察是，规划可以拆成两层——显式规划（执行前产出的、作为一等对象的计划）和隐式规划（脚手架逐轮施加的结构化行为：子步粒度、何时从探索转入行动、工具调用顺序、失败后如何重规划）。各脚手架底层其实共享同一个 ReAct 式 act/observe 循环，模型具备在其他脚手架下运行的能力，缺的只是对各家规划约定的熟悉度。要把规划从“脚手架的固定产物”变成“模型的习得能力”，就需要一种能在任意 CLI 脚手架与任意后端模型间路由 API 流量、并采集规划感知轨迹的工具——而此前没有任何现成基础设施能做到这一点。Qwen3-Coder-Next 独立印证了脚手架专属偏置的存在，为本文假设提供了旁证。
核心方法
直觉上可以这样理解：四款 CLI 脚手架（OpenHands、Claude Code、OpenCode、mini-swe-agent）在规划结构上差异最大，但底层都跑着同一个 ReAct 式的“行动—观察”执行循环。模型在一个脚手架下训练过，就具备了在其他脚手架下运行的能力；它在非训练脚手架上缺的，只是对那套规划约定的熟悉。那么只要给它一小批能把“两层规划”都暴露出来的轨迹，它应该能学到一种可迁移的结构化技能，而不是死记某家脚手架的表面细节。技术路线据此分三步：先造一个 DCAS 后端替换拦截层，把任意 CLI 脚手架与任意后端模型之间的 API 流量经过一层中间代理做格式翻译，使脚手架完全不被修改；再用 DCAS 做三件事——（a）在执行器模型和脚手架都固定的条件下做受控的“规划源”干预（RQ1），（b）在目标脚手架下采集规划感知轨迹并用两个数据集变体做 SFT（RQ2），（c）把微调后的模型部署到训练时从未见过的脚手架上做泛化测试（RQ3）。整个流程中，脚手架在各 RQ 内部保持一致，性能差异只能归因于模型或规划本身。
全文最核心的创新是把“规划”概念性地拆成两层，并在训练数据里实证地把这两层干净地分开。显式规划指模型在执行前产出一个作为一等对象的计划（如 Claude Code 的 Plan Mode、OpenCode 的 Plan agent）；隐式规划指脚手架逐轮施加的结构化行为——子步粒度、何时从探索转入行动、工具调用如何串联、失败如何触发重规划。关键实验证据是：只用规划阶段轨迹训练的 PlanOnly 模型，在无规划条件下竟从 42.8% 跃升到 53.8%（+11.0%），却完全无法从自生成规划中再获益（53.2%，反而略降）——这证明它学到的是隐式规划约定，而非“如何使用一个显式规划步骤”；而同时包含规划与执行的 Plan+Exec 模型则在无规划下达到 52.8%，再加自规划又涨到 55.8%（+13.0%），说明它同时学到了两层。这个干净的两层分离是方法奏效的根基：可以单独教隐式约定，也可以叠加显式规划用法。配合 DCAS 拦截层（在不改脚手架的前提下替换后端）和规划器-执行器分离（强模型写计划、30B 模型执行），整个方法把“外部规划器注入”内化成了模型自身的、可迁移的能力。
方法步骤详情
方法分四步。第一步构建 DCAS 拦截层：在 McMillan 的开源 SWE-bench runner 基础上扩展规划阶段分离、结构化轨迹日志与多脚手架支持，把任意脚手架与后端模型间的 API 流量经中间层翻译并记录为轨迹文件。第二步（RQ1）固定执行器 Qwen3-Coder-30B-A3B-Instruct、脚手架 CC 2.0.76 与基准 SWE-bench Verified，用三种模板做受控干预：无规划基线、自规划（先产不超过八步计划、不改代码，再执行）、外部规划（由 Claude Sonnet/Opus 4.5 或开源 Qwen3-Coder-480B-A35B-Instruct 生成计划交后端执行），外部规划分默认/固定两种路由。第三步（RQ2）用 GLM-4.7 经 DCAS 替换进 Claude Code 采两阶段轨迹，拒绝采样留 576 条，构造 PlanOnly（14,162 per-turn 样本）与 Plan+Exec（36,259 per-turn 样本）两个 SFT 数据集，对 30B 模型做全参数 SFT（LLaMA-Factory，$\eta=4.0\times10^{-6}$、余弦调度、65,536 token、BF16、Flash Attention 2、DeepSpeed ZeRO Stage 3）。第四步（RQ3）把 Plan+Exec 模型部署到 CC 2.1.73 与 OpenCode v0.0.55、mini-swe-agent v2.2.8 测 Pass@1。
技术新颖性
DCAS 是首个在后端替换代理能力之上系统构建的研究方法，用于受控的跨脚手架评估和大规模的规划感知轨迹采集；此前的代理工具（如 claude-trace）只做 HTTP 流量拦截，没有发展成研究范式。规划“两层”概念拆分并在训练数据里实证可分离，是本文独有的——以往工作要么只谈显式计划阶段（MASAI、CodeR、HULA 的规划器-执行器架构），要么把规划和执行混在一个不透明的脚手架循环里，从未把两层拆开训练对比。与 Qwen3-Coder-Next 这类“多脚手架混合采集以拓宽分布”的做法不同，本文不靠扩大数据分布，而是靠暴露规划结构本身；与 Agentless、MASAI 等推理期仍需外部规划器的架构不同，DCAS 通过 SFT 把规划器角色内化进模型，推理期不再需要外部规划器。这种“后端替换 + 规划阶段分离 + 拒绝采样轨迹”的组合，让任意闭源脚手架（如 Claude Code）也能成为可采集、可对换的训练环境。
实验结果
三个 RQ 逐层给证。RQ1（Table 4）证明规划质量是高杠杆因素：无规划基线 42.8%，自规划 48.2%（+5.4%），开源 Qwen3-480B 规划器 49.2%（+6.4%），Opus 4.5 默认路由 56.0%（+13.2%），Sonnet 4.5 两种路由均 57.8%（+15.0%）；收益随规划器能力单调上升，且 15 个点的杠杆量级超过 Table 1 的跨脚手架跌幅，反直觉的是 Sonnet 4.5 作规划器反而优于更强的 Opus 4.5。RQ2（Table 5）证明规划可内化、两层在数据中可分：PlanOnly 无规划 53.8%（+11.0%）、自规划 53.2% 无额外收益；Plan+Exec 无规划 52.8%（+10.0%）、自规划 55.8%（+13.0%），后者已追平 Opus 4.5 注入的 56.0%、仅比 Sonnet 4.5 注入的 57.8% 低 2 个点，却无需推理期外部规划器。RQ3（Table 6）证明习得的是结构化技能而非记忆：新版 CC 2.1.73 上自规划 57.2%（+14.4%），是全文无需外部规划器的最高分且超过训练版本；从未训练过的 OpenCode 自规划 49.4%（+3.4%）、结构最不相似的 mini-swe-agent 自规划 42.4%（+7.0%）。整个 SFT 仅用 576 条轨迹，比 SWE-Gym、Nebius、CoderForge 动辄数千到数万条小一到两个数量级。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| SWE-bench Verified（规划源受控干预，CC 2.0.76） | Pass@1 | 57.8%（Claude Sonnet 4.5 注入规划） | 42.8%（同模型无规划） | +15.0% |
| SWE-bench Verified（Plan+Exec SFT 规划内化，CC 2.0.76） | Pass@1 | 55.8%（自生成规划） | 42.8%（基座无规划） | +13.0% |
| SWE-bench Verified（版本迁移到 CC 2.1.73） | Pass@1 | 57.2%（Plan+Exec 自规划） | 42.8%（基座无规划） | +14.4% |
| SWE-bench Verified（跨脚手架 OpenCode v0.0.55） | Pass@1 | 49.4%（SFT 自规划） | 46.0%（基座无规划） | +3.4% |
| SWE-bench Verified（跨脚手架 mini-swe-agent v2.2.8） | Pass@1 | 42.4%（SFT 自规划） | 35.4%（基座无规划） | +7.0% |
| SWE-bench Verified（跨脚手架退化现象，Table 1） | Pass@1 | 8.4%（SWE-Lego-Qwen3-32B 在 OpenCode） | 52.6%（同模型在 OpenHands） | −44.2%（退化，工具格式不兼容） |
局限与改进
作者承认几方面局限。首先，把跨脚手架鸿沟归因于规划结构只是“部分”被设计支持：RQ1 在脚手架内只隔离了显式规划，跨脚手架时规划与工具调用 schema 及解析器、轮次管理、上下文窗口协同变化，作者未在固定规划的同时逐一消融其余维度。其次，所有实验都用 SWE-bench Verified，迁移到其他代码库和任务类型未知；后端执行器只用 Qwen3-Coder-30B-A3B-Instruct 一个模型，增益未必能直接迁移到其他规模/架构。第三，训练轨迹只在 Claude Code 下采集，跨脚手架评估只覆盖 OpenCode v0.0.55 与 mini-swe-agent v2.2.8，Codex CLI 因走 OpenAI Responses API（SSE 流式）在 10–18 轮后卡死而无法纳入。第四，拒绝采样只留补丁通过的轨迹，偏向较易实例。第五，Pass@1 不反映轨迹效率、轮次数或推理质量，规划质量只能间接通过任务表现评估。我额外观察到：OpenCode（+3.4%）等开放脚手架增益远小于 CC 的 +13–14%；与 Kimi K2 的 65.8% 相比绝对差距仍不小。
独立分析的弱点
独立分析有几点。其一，跨脚手架迁移幅度不均：在结构最接近训练脚手架的 Claude Code 上增益最大（+13–14%），在开放脚手架上明显缩水（OpenCode 仅 +3.4%），结构性匹配假设虽能解释，但对只想用 OpenCode 的实践者而言回报可能不足以抵消采集成本——改进方向是用多个脚手架联合采集轨迹以拓宽结构风格。其二，源模型（GLM-4.7）和执行器（Qwen3-Coder-30B-A3B-Instruct）各只有一个，无法把“规划结构带来的增益”与“通用域内 SFT 暴露带来的增益”彻底分开；需补 execution-only、token-matched、degraded-plan 等对照训练。其三，显式 vs 隐式规划的拆分目前停留在概念层，只通过下游表现间接证明可分离，可直接对微调模型的规划做质量评分。其四，拒绝采样偏向易例，在难题上行为未知，可能高估真实部署收益。其五，没有与 RL 路线（DeepSWE、Kimi K2、SWE-RL）对比天花板。其六，工具格式与上下文长度不兼容是真实失败模式，但正交于本文学习问题，方法本身未解决。
未来方向
作者明确提出的方向：把 DCAS 扩展到 Codex CLI、Gemini CLI，以及 IDE 集成和 GUI 式编码智能体（它们同样经 API 与后端模型通信但交互界面不同）；把“规划器-执行器校准”作为一等设计变量来研究，包括最优规划器是否会随执行器规模变化而改变；在固定规划的同时消融其余维度，补齐 execution-only/token-matched/degraded-plan 对照；直接对微调模型的规划打分。基于成果可延伸的方向：跨多脚手架联合采集轨迹以补齐开放脚手架上较弱的迁移；把 DCAS 的 SFT 路线与 RL（如 SWE-RL、DeepSWE）组合以拉高天花板；研究规划技能能否与更大执行器组合迁移；推动把多脚手架评估作为社区评测的默认标准而非可选项，避免单脚手架分数系统性高估真实能力。
复现评估
复现友好度较高。作者在 Zenodo 放了 DCAS 源码和复现脚本（doi:10.5281/zenodo.19930073），HuggingFace 上放了 SFT 模型权重与蒸馏后的 GLM-4.7 轨迹数据集，并发布原始 claude-trace HTTP 日志便于独立核查 API 交互；脚手架版本精确指定（CC 2.0.76、CC 2.1.73、OpenCode v0.0.55、mini-swe-agent v2.2.8），SFT 超参完整给出（LLaMA-Factory、$\eta=4.0\times10^{-6}$、余弦、65,536 token、BF16、Flash Attention 2、DeepSpeed ZeRO Stage 3）。576 条轨迹的采集量级对中小团队可行。主要门槛：Claude Code 闭源（但可免费使用）；RQ1 的规划注入需 Claude API 额度；全参数微调 30B（MoE、A3B 激活）需多卡 GPU（论文未明确算力规模，但 ZeRO-3 全参微调通常意味着多张高显存卡）；SWE-bench Verified 评测本身需 Docker 跑官方镜像。综合难度中等。
论文图表
