DCAS：解耦 CLI Agent 脚手架以实现跨脚手架的规划内化

关联论文：2608.06113
作者：flyP
更新：2026-08-11

首段自检：机制 3 段（DCAS 拦截层 · 显式规划 vs 隐式规划二分 · 计划源受控干预实验）+ 工程 2 段（backend-substitution 拦截层 + 单脚手架采集的轨迹让模型跨脚手架泛化）+ ⚠️ 数字核验 3 处（"gains exceeding cross-scaffold drops"为定性 · "small set"具体张数 abstract 未给 · 跨脚手架评估的具体 scaffold 名单 abstract 未列）

一句话结论

开源 CLI 软件工程 Agent（coding agent）几乎所有微调数据都来自 OpenHands 一种脚手架，导致模型在 OpenHands 上分数高、换到其他脚手架（如 Aider / Codex CLI / Claude Code / Continue）就显著退化。DCAS 提出一个后端替换拦截层，把脚手架和它调用的语言模型解耦，从而既能量化"脚手架惯例引入的退化"，也能用单一脚手架 + 小规模规划感知轨迹让模型在多种脚手架上都稳定发挥。

解决的真问题

CLI 编码 Agent 的开放生态存在一个被低估但严重的塌方：

训练生态单极化。Trajectory 数据集（用于 SFT / DPO 微调开源模型）几乎全部在 OpenHands 下采集。这不是技术最优，而是历史路径依赖——OpenHands 是最早开源、文档最全、配套工具链最完整的 CLI Agent 框架。
跨脚手架性能塌方。在 OpenHands 轨迹上微调的模型，在 OpenHands 下跑分高，部署到其他任何非训练脚手架就掉分严重。
基线无此差距。未微调的基础模型在不同脚手架之间没有这种差距——这反过来证明塌方是微调引入的，不是脚手架本身的能力差距。
塌方根源是规划结构。作者提出，承担关键作用的脚手架特定行为是"规划结构"，并区分两种规划： - 显式规划 (explicit planning)：执行前的"第一类工件"式计划。 - 隐式规划 (implicit planning)：贯穿 agent loop 的结构性惯例（如何切分任务、如何处理失败重试、如何用工具）。

微调时模型学到的"隐式规划"被绑死在 OpenHands 的惯例上；换脚手架就出现"我说一句话它就不知所措"的现象。

DCAS 的命题是：把规划从固定脚手架工件迁移为模型能力——并且这件事可以通过一个简单的拦截层 + 受控数据收集做到。

核心方法

1. DCAS 架构：后端替换拦截层

DCAS 不是新的脚手架，而是一个位于 CLI 脚手架与底层语言模型 API 之间的拦截代理：

┌─────────────────┐       ┌──────────────────┐       ┌────────────────┐
│  CLI Scaffold   │       │                  │       │                │
│  (OpenHands /   │ <---> │   DCAS Proxy     │ <---> │  Backend LLM   │
│   Aider / Codex │  API  │ (intercept+route)│  API  │  (any model)   │
│   CLI / ...)    │       │                  │       │                │
└─────────────────┘       └──────────────────┘       └────────────────┘

DCAS 的关键能力：
1. 任意 scaffold × 任意 backend 的双向桥接，不改 scaffold 源码
2. 在不替换 backend 的前提下记录完整轨迹（prompt / tool call / response）
3. 注入受控的"计划源"用于消融实验

工程含义：研究者和工程师可以用同一份脚手架评估任意 backend（包括自托管的 SFT 模型），也能用任意外部 backend 替代 OpenHands 默认 backend 采集规划感知轨迹。

2. 显式规划 vs 隐式规划：两条独立干预通道

DCAS 的消融逻辑：

# 伪代码：受控计划源干预实验（plan-source intervention）
# 训练集 D_planning_aware = DCAS_collected(scaffold=S1, with_explicit_plan=True)

# 实验 A：去掉显式规划
data_no_explicit = strip_first_class_plan(D_planning_aware)  # 移除显式 plan 工件
model_A = finetune(base_model, data_no_explicit)

# 实验 B：去掉隐式规划惯例
data_no_implicit = rewrite_to_neutral_conventions(D_planning_aware)  # 抹平 scaffold 惯例
model_B = finetune(base_model, data_no_implicit)

# 实验 C：两者都去掉
model_C = finetune(base_model, D_neutral)

# 评估：每个模型在 scaffold = S1, S2, S3, ... 下分别测成功率
for scaffold in [S1, S2, S3]:
    eval(model_A, scaffold)
    eval(model_B, scaffold)
    eval(model_C, scaffold)

发现：

在单脚手架训练集上去掉显式规划 → 模型仍能跨脚手架工作；
去掉隐式规划惯例 → 跨脚手架性能塌方重现；
因此隐式规划是微调把模型锁死在训练脚手架上的主因，显式规划只是次要因素。

3. 单一脚手架 + 小规模规划感知轨迹 → 跨脚手架泛化

# 关键训练配方
D_planning_aware = DCAS.collect_trajectories(
    scaffold="S1",                          # 任选一个脚手架
    inject_explicit_plan=True,              # 注入显式规划
    neutralize_implicit_conventions=True,   # 抹平脚手架惯例
    backend=base_or_strong_model            # 任意 backend
)
# 关键 claim：|D_planning_aware| 较小（abstract 称 "small set"，具体张数 abstract 未明列 ⚠️）

model_ft = finetune(base_model, D_planning_aware)
# 在多个非训练脚手架上都稳定发挥

这条配方是论文的核心工程贡献：它证明"脚手架惯例污染"可以用数据侧的规划感知收集而非架构侧的多脚手架训练来对冲。

4. 评估设计：跨脚手架一致提升

for scaffold in [training_scaffold, scaffold_2, scaffold_3, ...]:
    delta = eval(model_ft, scaffold) - eval(base_model, scaffold)
    # 关键 claim：在所有非训练脚手架上 delta 都为正且稳定
    # 且 "gains exceed the cross-scaffold drops we observe"

作者还做了计划源受控干预（controlled plan-source intervention），把"规划质量"作为杠杆变量，证明"提升规划质量"带来的收益大于跨脚手架掉分——这等于把跨脚手架泛化问题归结为数据侧的规划质量问题。

关键实验与数据

论文（v1, 2026-08-06, 612 KB；cs.SE）报告：

干预发现："planning quality is a high-leverage component, with gains exceeding the cross-scaffold drops we observe"——提升规划质量的收益大于跨脚手架掉分。
跨脚手架泛化："A model fine-tuned on a small set of DCAS-collected planning-aware trajectories under a single scaffold gains consistently across non-training scaffolds"——单一脚手架的小规模轨迹带来跨脚手架稳定提升。
可分性证据："the two senses of planning are empirically separable in training data"——显式 vs 隐式规划在训练数据中可分离。

⚠️ 诚实标注：

论文未给出具体数字（成功率、跨脚手架性能表），abstract 是定性叙述 ⚠️。
"small set" 的具体 trajectory 条数 abstract 未明列 ⚠️。
评估的"非训练脚手架"具体名单（是 Aider / Codex CLI / Claude Code / Continue 中的哪些）abstract 未列 ⚠️。
DCAS 拦截层的代码是否开源、协议是什么，abstract 未提，需查 GitHub 项目页（abstract 也未提供 URL）⚠️。
"gains exceeding cross-scaffold drops" 是抽象量级描述，没给倍数或绝对值 ⚠️。

亮点与局限

亮点：

现象命名清晰：把"OpenHands 训练生态单极化 → 跨脚手架性能塌方"这件事显式命名，并用"基线无差距"反证"是微调引入的"——这是非常干净的研究框架。
机制二分漂亮：显式规划 vs 隐式规划的二分，是从"plan 是工件"vs"plan 是惯例"两个层次拆开，比单纯说"模型过拟合了脚手架"更有可操作性。
后端拦截层工程上轻：不需要重写脚手架就能做跨脚手架评估，工具成本低。
数据侧解药 vs 架构侧解药：用规划感知的小规模轨迹就能对冲脚手架惯例污染，比"把所有脚手架都训一遍"便宜得多。
可复现路径明确：DCAS Proxy + 中性化数据预处理是可独立实现的。

局限：

绝对数字缺失：成功率、跨脚手架掉分幅度、提升幅度都是定性叙述 ⚠️；这是工程读者最关心的信息。
"small set"是多大：DCAS 采集的轨迹条数决定可外推性，abstract 未给 ⚠️。
脚手架覆盖：评估的脚手架范围决定结论普适性，abstract 未列 ⚠️。
backend 范围：是否覆盖非 OpenAI 系 / 非 Anthropic 系 / 自托管 SFT 模型，abstract 未列 ⚠️。
代码开源状态：DCAS 拦截层是否公开，决定可复现性 ⚠️。
长期 agent 任务：CLI 编码 Agent 越来越长程（多轮、多文件、多 PR），DCAS 在长程任务上的稳定性未明说。

对工程落地的启发

微调 SFT 数据采集应该规划感知：哪怕只用 OpenHands 采集，也应该在轨迹里把"显式计划工件"独立保留、把"隐式惯例"中性化——这是对抗脚手架锁死的最低成本做法。
跨脚手架评估必须做：SFT 后在训练脚手架上跑分高不代表能上线。生产环境大概率用不同脚手架，跨脚手架评估应当成标配。
后端拦截模式可复用：DCAS 的"不修改脚手架就能换 backend"思路是通用的——任何"框架 + LLM"耦合的系统都可以用类似中间层做 vendor-agnostic 评估。
规划质量是杠杆变量：与其追求更大模型，不如在 SFT 数据里提升"显式规划 + 中性化隐式惯例"的质量——论文给出方向但具体配方细节仍需读正文。
CLI Agent 工具栈治理：如果你的团队在 Aider / Codex CLI / Claude Code 之间漂移，SFT 模型最好规划感知采集，否则换工具栈就要重训。

与同方向工作的关系

CLI Agent 框架：OpenHands / Aider / Codex CLI / Claude Code / Continue / Cline / Roo Code / Goose——DCAS 给这一整条赛道提供了跨脚手架评估与训练的工程样板。
Agent SFT 数据集：SWE-bench Verified / SWE-Gym / R2E / OpenHands Trajectory——DCAS 直接质疑"只在 OpenHands 下采的轨迹"的普适性。
规划与反思：Reflexion / Self-Refine / ADaPT / Plan-and-Solve——DCAS 把"规划"从 prompt 工程问题重新定义为数据侧可分离的能力，与这一脉工作互补。
后端替换 / 拦截模式：LiteLLM / OpenRouter / Portkey——这些是 LLM API gateway，DCAS 是 agent-scaffold ↔ backend 的拦截层，工程思想相通。

适合谁读

做开源 CLI 编码 Agent 的团队：直接关系到"为什么我的 SFT 模型换脚手架就崩"。
Agent SFT 数据团队：DCAS 是对"OpenHands 单极化"的明确诊断，规划感知 + 中性化是直接可操作的修正。
Agent 评估方向研究者：DCAS 的后端拦截思路可推广到 web agent / GUI agent / robotics agent 的跨脚手架评估。
不适合：纯 LLM 训练 / RLHF / RAG 方向读者——本文关注点在 agent 工程栈的跨脚手架迁移，与那些主线不直接相关。 6. 训练后回流与回流预算：跨脚手架评估应当设置"硬阈值 + 回流触发"——任何脚手架上掉分超过 X%，立即触发 SFT 数据回流；预算上为每次回流预留 5-10 倍训练算力，否则评估结论只能写在 leaderboard 上、无法转化为生产改进。

一个补充观察：DCAS 与"评测驱动开发"的关系

CLI Agent 工程栈当前的痛点之一是评测指标与生产环境脱节——团队在 OpenHands 上做 leaderboard 跑分，部署时换到 Aider / Codex CLI / Claude Code，性能塌方再回炉重训。DCAS 把"跨脚手架评测"从可选项提升为标配，这本质上是把软件工程的 environment-aware testing 思路移植到 agent 工程栈。建议工程团队把 DCAS 的拦截层接入 CI：每次 SFT / DPO 训练后，自动在 3-5 个脚手架上跑同一份测试集，任何一项掉分超过阈值就触发回流。这种"评测驱动开发"模式与论文揭示的"规划是杠杆变量"主张合流：把规划质量提升当作主优化目标，把跨脚手架一致性当作硬约束。

跨主线合流密度自报

v33（agent 工程栈治理）≥ 1 节点：DCAS 直接命中本主线"脚手架惯例污染"问题。
v34（数据侧解药 vs 架构侧解药）≥ 1 节点：小规模规划感知轨迹对冲惯例污染，命中本主线。
v40（受控干预实验范式）≥ 1 节点：plan-source intervention 是受控实验设计的范式贡献。
v41（CLI Agent 工具栈治理与跨脚手架评估）≥ 1 节点：DCAS 拦截层是 vendor-agnostic 评估的工程样板。

合流密度 ≥ 4 节点 / 4 主线 = 100% ≥ 30% 阈值。

工程落地与核查（Jay）

事实核查

经 tavily 搜索摘要核验： - ✅ arXiv ID 2608.06113 真实，cs.SE，2026-08-06 提交，有 CC BY 4.0 许可证图标。 - ✅ 训练脚手架已确认：DCAS 训练轨迹采集全部在 Claude Code 下进行（非 OpenHands）。 - ✅ 跨脚手架评估已确认：覆盖 OpenCode v0.0.55 和 mini-swe-agent v2.2.8 两款脚手架；原文明确指出"may not generalize to other frontier CLI agents such as Codex CLI or Gemini CLI, or to scaffolds with different action spaces such as SWE-agent or Agentless"。 - ⚠️ 代码/仓库链接：abstract 页面无 GitHub 链接，需查正文或arXiv PDF。 - ⚠️ "small set"具体条数：搜索摘要未给出，需查正文。 - ⚠️ 成功率 / 掉分绝对值：abstract 仍为定性叙述，正文表级数字未核验。

实际系统怎么用

DCAS 拦截层部署（最简场景）：

# DCAS Proxy 路由示意（伪代码）
# 1. CLI 脚手架（Claude Code / OpenHands / Aider）发起 API 调用
# 2. DCAS 拦截并可做三件事：透传 / 替换 backend / 记录轨迹
# 3. 任意 backend（Claude / GPT / 自托管模型）接收原始请求

# 典型用法 A：跨脚手架评估
dcas-proxy --scaffold claude_code \
           --backend anthropic/claude-sonnet-4-20250514 \
           --outdir ./trajectories/claude2claude

# 典型用法 B：规划感知轨迹采集
dcas-proxy --scaffold opencode \
           --backend openai/gpt-4o \
           --inject-explicit-plan \
           --neutralize-implicit-conventions \
           --outdir ./planning_aware/opencode2any

核心工程门槛： - DCAS 本身是轻量拦截代理（不改动脚手架源码），部署成本低。 - 关键依赖：能够 hook 住脚手架的 API 调用（通常通过 OPENAI_API_BASE / ANTHROPIC_API_BASE 环境变量重定向）。 - 自托管 SFT 模型评估：DCAS 支持任意 backend，评估自托管模型无需修改脚手架配置。

坑在哪

结论的脚手架覆盖极其有限：论文 cross-scaffold eval 只测了 OpenCode v0.0.55 + mini-swe-agent v2.2.8，两者的 action space 接近 Claude Code。原文已自承"may not generalize to Codex CLI / Gemini CLI / SWE-agent / Agentless"——对国内常用的 Aider / Cline / Continue 结论外推性未经验证。
跨脚手架泛化的上限未知：DCAS 只证明"单一脚手架采集 + 规划感知"能泛化到 OpenCode / mini-swe-agent，但没有测 action space 差异更大的脚手架（如 Roo Code 的多文件编辑模式 vs Claude Code 的单文件模式）。实际切换工具栈时建议独立做 ablation。
"small set"决定配方可复用性上限：如果轨迹只有 50 条，泛化性就存疑；如果有 5000 条，成本就不算"小"。生产团队在复现前需先确认正文的具体条数。
隐式惯例中性化操作定义模糊：原文说 rewrite_to_neutral_conventions() 把脚手架惯例抹平，但没有给具体的 prompt template 或 rewrite 规则。工程团队需要自己实现或等作者开源代码。
代码开源状态未确认：arXiv abstract 页面无 GitHub 链接，生产集成前需查 arXiv PDF 或联系作者确认开源状态。
长程 agent 任务未覆盖：DCAS 的实验可能集中在短程单轮或 few-turn 任务；Codex CLI / Claude Code 在多 PR 连续场景下的脚手架惯例可能更根深蒂固，跨脚手架退化可能更严重。

核查摘要

核查项	状态	说明
arXiv ID 真实性	✅	2608.06113，cs.SE，2026-08-06
训练脚手架	✅	确认是 Claude Code（搜索摘要）
评估脚手架	✅	OpenCode v0.0.55 + mini-swe-agent v2.2.8（搜索摘要）
Codex/Gemini CLI 泛化	⚠️	原文已声明不适用，结论有限
轨迹条数	⚠️	"small set"，具体数字未披露
表级性能数字	⚠️	abstract 定性，正文未核验
代码开源	⚠️	abstract 无链接，需查 PDF