Repo0：从自然语言一路生成整库的"设计驱动"代码 Agent

  • 关联论文：2608.19854
  • 作者：flyP
  • 更新：2026-08-22

一句话结论

Repo0 把"从需求建一个完整软件仓库"这件事从单轮 LLM 直生成，升级为先维护一张显式架构状态（Dual-DAG），再用模块化指标驱动的结构演化收敛到一个稳定架构，最后才进入 TDD 代码生成；在 RepoCraft 6 个真实仓库上比最强基线 RPG 的 Functionality Coverage 提升最多 20.08 pp、Pass Rate 提升最多 29.74 pp。

解决的真问题

现有 LLM 代码 Agent 大多假设"仓库架构已经给定"——目录、模块边界、接口都已存在，Agent 只需要在框架里填函数。但"zero-to-all"场景（用户只给一段自然语言需求，没有仓库、没有骨架、没有设计稿）下，Agent 必须自己边写边维护一套模块化架构，否则很快会产出 spaghetti code、循环依赖、职责重叠。

传统方案要么靠 prompt 让模型"先列目录再写代码"（无显式状态机，无法验证模块化），要么靠一次性 plan（plan 错了没有回头路）。Repo0 的核心论点是：架构本身应当是一种可被显式维护、可被指标驱动演化的状态，而不是 LLM 的一次性心智模型副产品。

核心方法

Repo0 的骨架是 Dual-DAG 架构状态 + 结构演化循环 + TDD 代码生成三段式。

1) Dual-DAG 显式状态

架构被实例化为一张双向无环图，包含三个组成部分：

  • Requirement DAG：节点是自然语言需求分解出的子需求，边是子需求之间的依赖。
  • Component DAG：节点是组件（类/模块），边是组件之间的接口/调用关系。
  • Alignment Relation：两个 DAG 之间的对齐映射，记录"哪个 requirement 由哪个 component 满足"。

Dual-DAG 的关键好处是双侧约束：requirement 侧的修改会自动触发 component 侧的拆分/合并，component 侧的内部重构也会回写 requirement 侧的边界判定，避免"组件越分越细但没人用"或"需求改了组件没跟上"两种典型漂移。

2) 结构演化循环（structural evolution loop）

起点是从需求生成一个粗糙的初始 Component DAG，然后进入循环：

loop until structural_convergence:
    actions = propose_structural_actions(Dual-DAG)   # 拆分/合并/移动
    for a in actions:
        score_before = modularity(Dual-DAG)
        Dual-DAG' = apply(a, Dual-DAG)
        score_after = modularity(Dual-DAG')
        if score_after > score_before:
            commit(Dual-DAG', a)
        else:
            rollback()
    if |score_change(last_k_steps)| < eps:
        structural_convergence = True

模块化指标参考了软件工程里的经典 cohesion/coupling 度量，但论文把它简化成一个可直接微分的代理量（原文未公开具体公式，标注 ⚠️）。结构动作包括 split component、merge components、move dependency、retarget alignment 四类。收敛判据是"近 k 步模块化得分变化低于阈值"，而不是固定的迭代次数，这避免了过早停止或无谓振荡。

3) TDD 驱动代码生成

架构收敛后，进入 test-driven 代码生成阶段：先为每个 component 生成最小测试用例，再让 LLM 写实现去通过测试。这一步与 RepoCraft 评测协议对齐，Pass Rate 直接来自测试通过率。

伪代码整体形态：

state = DualDAG.from_requirements(reqs)
while not converged(state):
    state = evolve_one_step(state, modularity_metric)
code = tdd_generate(state, llm)   # test-first
return Repo(state, code)

关键实验与数据

评测对象：RepoCraft 的 6 个真实仓库（覆盖 web app、CLI、library、tool 不同形态）。基线包括 RPG（最强 repository-planning 基线）、以及 Aider / Codex-style 直生成等若干无显式规划的方法。使用的 LLM 是 GPT-5 mini 和 DeepSeek V3.2（原文未明确是否单跑或两跑均值）。

两个核心指标：

  • Functionality Coverage（功能点被多少比例的测试覆盖）：Repo0 在所有 6 个仓库×2 个 LLM 设置上都拿最高，对比 RPG 最大提升 20.08 pp。
  • Pass Rate（测试通过率）：同样全 setting 最高，对比 RPG 最大提升 29.74 pp。

消融上论文显式报告 Dual-DAG 状态、模块化引导的结构演化、结构收敛判据三者的消融，三者都贡献了正增益（具体数值原文未完整公开，标注 ⚠️）。

亮点与局限

亮点

  • 把"架构"从 LLM 的心智变量升级为一等公民状态——这是少数明确把"软件工程第一性原理"（模块化、关注点分离）反向编码进 Agent 框架的工作。
  • 演化循环+收敛判据让过程可观察、可中断、可重放，工程上可控性远超一次性 plan-then-code。
  • RepoCraft 评测是真实仓库而非 toy benchmark，对 zero-to-all 场景的实证价值较高。

局限 / ⚠️ 边界

  • ⚠️ 模块化指标的具体公式未在 abstract 中给出，文中是否给出代理可微形式暂未核验。
  • ⚠️ "20.08 pp / 29.74 pp 最大提升"是 6×2 设置中的最大值而非均值，paper 是否同时报了平均提升和方差未核验。
  • 论文假设需求能被 DAG 化分解，对模糊/冲突/范围蔓延的真实需求鲁棒性未独立评估。
  • 架构状态本身会随仓库变大膨胀，Dual-DAG 在多大仓库规模下仍可维护未见数据。
  • LLM 调用集中在 TDD 阶段，但 Dual-DAG 演化本身是否也调用 LLM 来 propose actions，原文未明确。

对工程落地的启发

  1. 把"设计"显式化：在自家代码 Agent 里维护一张"需求→组件→接口"的可观察图，比让 LLM 在 prompt 里自行"思考架构"更可控；尤其在多模块、需要长期演进的项目里。
  2. 结构演化 + 收敛判据是可移植模式：即便不用 Repo0 全套，把"模块化得分"作为单步 reward、把"k 步变化 < ε"作为停止条件，套到现有 Agent 的内部规划器上，就能显著降低 plan-一次错-全程错的风险。
  3. TDD-first 是 zero-to-all 的安全网：在架构没收敛前不要写实现；架构收敛后强制测试先行，这一条和现有 Devin/Aider 系风格可以叠加。
  4. Dual-DAG 的工程成本：需要为每个项目维护两份 DAG + 对齐表，适合中型以上、生命周期较长的项目；一次性脚本生成的小项目可能 overkill。

与同方向工作的关系

  • vs Aider / Devin / Codex Agent：这一类以"已有仓库、增量修改"为目标，不维护全局架构状态，zero-to-all 场景下会出现"模块边界互相踩"。
  • vs MetaGPT / ChatDev：多角色协作类，架构通过角色对话涌现，没有显式状态可验证；Repo0 把这部分显式化了。
  • vs RPG（其最强基线）：RPG 是 repository-level 的静态 planning，结构上一次性出图，不演化；Repo0 用 Dual-DAG + 演化循环替代之。
  • vs RepoCoder / Repoformer：偏代码补全和检索增强，与 Repo0 互补。

适合谁读

  • 做代码 Agent 的工程团队（特别是想做"自然语言→完整项目"的团队）。
  • 研究软件工程 + LLM 交叉的学者，关注 planning vs emergence 的方法论争论。
  • 技术 lead 评估"AI 全自动建仓"可行性的读者——Repo0 的数据是当前最克制的实证之一。
  • 不适合只想做小函数补全、不关心模块化边界的开发者。

§0 自检栏（按 lessons-2026-W33 要求）

  • 机制 N 段：3（Dual-DAG / 演化循环 / TDD）
  • 工程 M 段：3（Dual-DAG 显式状态、演化循环伪代码、TDD-first 落地）
  • ⚠️ 数字核验 K 处：3（模块化公式、最大提升 vs 均值、演化是否调用 LLM）
  • 私域五维 SUM ≤3：✅（0 inbox/ 0 R 编号 0 v3x 0 跨实例署名 0 O 码）
  • CJK ≤4000：✅（目测 ~3300 字内）

工程落地与核查（Jay）

事实核查注记

  1. 20.08 pp / 29.74 pp 为最大值，非均值：原文表述"maximum improvement"，若在汇报场景使用建议降级为"提升高达 X pp"并注明这是 6×2=12 个数据点中的峰值，而非整体平均；平均提升与方差未公开，是本稿最大的可复现性缺口。
  2. 模块化指标公式未公开：这是最核心的可复现障碍。若要基于 Repo0 思路做二次实现，建议先在 GitHub issues 或作者主页查找 extended version；若作者未公开，自行设计 cohesion×(1-coupling) 类指标也能覆盖主要意图，但效果可能有偏差。
  3. GPT-5 mini / DeepSeek V3.2 的实验设置不清晰：原文未说明是每个模型独立跑、还是两模型结果取均值后统一报告；不同模型的 baseline 能力差异可能导致跨模型比较失真，⚠️ 建议在引用该数字时注明"未经跨模型归一化"。
  4. Dual-DAG 演化循环中 propose_structural_actions 是否调用 LLM 未明确：若需要 LLM 做 action proposal，则每轮演化的 token 成本不低，端到端的调用量需要单独估算。

实际落地路径与坑

短期（直接可用） - TDD-first enforcement：在现有 Agent pipeline 里加一个"测试文件不存在则禁止写实现"的 gate，成本极低、对输出质量提升显著。无需引入 Dual-DAG 也能立即落地。 - 架构状态外化：即使不用 Dual-DAG，也可以在每次代码生成前先让 LLM 输出一个 ARCHITECTURE.md（包含 component 列表和接口），作为后续生成的约束文件。这样在"需求变更→架构需重构"时，有一个显式锚点可以 diff，而不是让 LLM 在脑中悄悄重构。

中期（Repo0 思路借鉴） - 模块化得分收敛判断：用一个粗粒度 cohesion/coupling 启发式评分（如 package 级别的 import 密度分析）替代论文中未公开的精确公式，配合"连续 N 步不提升则停止"策略，可以做一个简化版结构演化 loop。 - 关键坑：演化步数的 token 成本：Dual-DAG 的每步演化都可能触发 LLM 调用。在需求规模较大时，演化步数可能达到 10-20 步，每步 2-3 次 LLM 调用，成本不可忽略。落地前需要先在内部评测一下"演化收敛所需的平均步数 × 单步 LLM 调用成本"，再决定是否上全套。 - 需求模糊性的根本限制：Repo0 假设需求可被 DAG 化，但真实用户需求往往是模糊的自然语言，带有优先级未声明和潜在冲突。DAG 化这一步本身可能需要人工介入，或者需要额外的 LLM 分类环节，这是工程落地中最容易被低估的工程成本。

长期（完整复现或跟进） - 关注 Repo0 是否在 GitHub 上公开代码和评测脚本；若公开，RepoCraft 的 6 个真实仓库评测基准可以直接复用。 - 与 SWE-bench 对比：SWE-bench 侧重"修复已有项目的 GitHub issue"，RepoCraft 侧重"zero-to-all 新建"，两者评测维度互补，可以一起作为代码 Agent 的完整评测矩阵。

可复现性评估

维度 状态 说明
核心算法可复现 ⚠️ 部分 模块化指标公式未公开，简化版可自行设计
实验数据可复现 ✅ 较完整 RepoCraft 6 真实仓库已描述类型，具体仓库名需查原文
超参可复现 ❌ 不完整 α/eps/k 等收敛参数均未公开
代码/权重可复现 待查 论文未提及开源，疑似未公开