多 Agent 改代码最怕“合并失控”：用 Apron Agents 把并行开发锁进本地 Git 沙箱
让多个编码 Agent 同时处理一个需求，瓶颈往往不是“能不能生成代码”，而是怎样避免它们互相踩文件、把未经检查的改动推到真实远端，以及怎样让人能逐块判断变更是否值得合并。常见的做法是给每个 Agent 开一个 worktree 或分支；但分支数量、测试时机、合并顺序和审查记录仍要自己拼装。
Apron Agents 是一个本地运行的 Python 工具，试图把这条链路固化下来：编排器先把任务拆成相对独立的问题，工作 Agent 在隔离克隆中工作，合并控制器逐个候选合并并运行测试，最后由仪表盘提供按块审查的入口。它的关键取舍是：整个过程中使用临时目录中的裸仓库充当一次性的“假 GitHub”，真实 remote 不在它的操作路径内；最终结果仅复制回当前工作目录，真实提交、推送仍由开发者自行执行。
这不是一个替代 Git 审查制度的产品，也不保证 Agent 写出的代码正确。它更像给并行编码 Agent 增加一层本地的变更隔离与合并闸门，尤其适合“需求可拆分、但主分支不应被自动碰触”的小型功能迭代。
先理解它在隔离什么
Apron 的一次运行包含四种职责：
- orchestrator（编排器）：将自然语言任务拆为小问题，设计目标是让问题尽量不依赖同一批文件；
- worker（工作 Agent）：每个问题在独立的 sandbox clone 中修改，不直接操作你的真实远端；
- merge controller（合并控制器）：按候选分支逐一合并，并在每个候选合并上执行测试命令；
- dashboard（仪表盘）：展示运行状态与差异。在 supervised 模式中，计划和每次合并都必须人工批准；autonomous 模式则在测试通过时允许自动合并。
这里的“隔离”不能被误读成完整的安全沙箱。项目的 worker 仍会在本机运行你选择的编码 CLI，并允许该 CLI 在其克隆目录里编辑、检索和执行命令。因此它主要解决的是 Git 变更传播边界，不是把不可信提示词、依赖安装或任意 shell 行为隔离成容器级安全域。处理来自外部的任务描述、或需要访问生产凭据的仓库时，仍应结合最小权限、独立环境和人工审查。
最小可复现流程：先用 demo 验证合并门
项目要求 Python 3.11 或更高版本。最小安装与试运行如下：
pip install apronagents cd /path/to/your/project apron start --runner demo --test-command 'pytest -q'
demo runner 使用进程内的假 Agent，不需要 Claude、Codex 订阅或 API 密钥，适合先观察任务、候选改动、测试和审查按钮之间的流程。--test-command 'pytest -q' 是一个示例：它会在每个候选合并上运行；如果你的项目采用 Node、Go 或多阶段检查，应替换为仓库实际可重复执行的验证命令，而不是机械照搬。
确认流程后，可以让工具自动检测后端，或显式指定已安装的 CLI：
apron start "为导入接口增加 CSV 校验" \ --runner codex \ --workers 3 \ --mode supervised \ --test-command 'pytest -q' \ --no-browser
README 列出的 runner 为 claude-code、codex、api 与 demo。自动检测的顺序是 Claude CLI、Codex CLI、API 凭据、demo。代码中定义的 Codex 调用使用 codex exec --full-auto --skip-git-repo-check，所以选择 codex 并不意味着 Apron 会替你提供额外的模型权限控制；应先确认本机 Codex 的登录状态、工作目录和权限策略。
为什么“一个任务一条分支”还不够
并行开发的真正风险在合流阶段。两个 Agent 分别完成“给 API 增加字段”和“更新表单校验”，各自单独测试都可能通过；一旦合并顺序不同，可能出现类型不一致、迁移遗漏或测试夹具失效。Apron 的合并控制器把检查放到每一个候选合并之后，避免只在最后面对一团难以归因的冲突。
建议把任务写成边界清楚的交付物，例如“在既有 parser 中拒绝空列名，并补充对应单元测试”，而不是“全面改善导入功能”。拆分器对“文件独立”的问题效果最好；多个任务都要改同一个核心接口时，更多 worker 只会放大冲突概率。此时应主动减少并发，把共享类型、数据库迁移或公共配置作为先行任务，剩余任务再并行。
supervised 模式适合以下情况：支付、权限、数据迁移、公共 SDK，以及团队刚引入 Agent 的阶段。每次点击合并前，应至少检查 diff 是否越过任务范围、测试是否真的覆盖目标行为、是否引入新的依赖或配置。只有当仓库测试足够可靠、任务原子性强且变更风险较低时，才考虑 autonomous 模式；“绿灯”只能证明当前测试命令通过，不能替代需求验收和安全审计。
运行记录不是装饰，而是交接材料
运行完成后可查询本项目的历史记录：
apron report apron report 8a645bde
第二条命令中的值是一次运行 ID 的唯一前缀。报告包含任务、计划是否通过计划闸门、每次审查及退回原因、合并时间与最终复制的文件；它可以保存到变更记录，或在创建真实 PR 时作为审查上下文。对于“为什么这个 Agent 的改动被退回”“最终目录里有哪些文件来自本轮自动化”这类问题，这比只保留终端日志更可追溯。
工具还会读取已有的 .claude/agents/ 定义，但按 README 的说明是只读发现；在仪表盘修改的 Agent 定义则写入项目的 .apron/ overlay，并在下一问题加载。把 .apron/ 是否纳入版本控制作为团队约定的一部分：需要共享 Agent 行为时应审查并提交；只用于个人实验时则避免把临时提示词混进仓库。
采用前的边界清单
Apron Agents 当前 PyPI 版本为 0.1.3，项目元数据标为 Beta，并以 MIT 许可证发布。它适合用来验证一种工程流程，而不应在没有演练的情况下直接进入关键生产仓库。实际接入前，建议完成以下检查：
- 先在可回滚的测试仓库用
--runner demo跑通，确认最终复制回工作目录的行为符合预期； - 为
--test-command选用无交互、确定性较高的命令，并让测试失败能清楚定位到候选合并； - 保持
--mode supervised，直到团队确认任务拆分质量、差异审查和失败回退流程； - 不把“本地假 remote”误当作凭据隔离。Agent CLI 仍在本机执行，敏感环境变量、SSH 凭据和生产配置应遵守现有隔离策略；
- 把真实的
git commit、git push和 PR 创建放在人工最终检查之后，保留常规的 CI、代码所有者审查与分支保护。
多 Agent 编码的价值不在于把合并按钮交给模型，而在于把“并行探索”和“受控合流”拆开。Apron Agents 的本地临时远端、逐候选测试和人工合并门，提供了一个可试验的中间层：让 Agent 并行产出小改动，同时把真实仓库的最终决定权留在开发者手中。