用看板编排跨六仓库的 AI 编码流程

一次改动要跨 Go 后端、Svelte 前端、UI 库和 3 个驱动仓库，AI 写完代码只是中途的一步。Oizom 的 Envizom 团队把这件事做成了 Orch2：用看板管理流程，用 TypeScript 脚本调度，让 Claude agent 负责写代码和解决冲突。

作者称，这套系统约 5,100 行 TypeScript，花了 2 天搭建，包含 12 个看板阶段。首张完整工单从 Todo 走到 6 个仓库全部合并，消耗 0.8M tokens。值得读的不是这个数字有多低，而是他们怎样把执行、隔离和人工放行拆开。

为什么调度流程交给脚本

Orch2 把三件事分开：工单系统是独立产品，Orch2 是它的客户端，agent 是 Orch2 启动的执行者。只有需要写代码或处理冲突时，才启动 LLM。

固定流程由脚本执行，需要判断的编码任务才交给模型。

这样做的理由很实际：普通 TypeScript 的执行路径可预测，出错容易定位，也不用为搬运状态持续消耗 tokens。

看板就是整个操作界面，没有额外仪表盘，也没有面向用户的 CLI。用户只需填写 Src Branch，所有仓库的工单分支统一使用工单 key，其余信息自动推导。Orch2 在讨论串里回复 PR、预览地址和执行结果，问题通过问题卡片呈现。

每轮 agent 执行都会留下简短回执，累计 token 用量。卡片按工单展示，分析页按天汇总；798,400 这样的数字改成以百万为单位显示，也就是 0.8。这里统计的是 token 消耗，原文没有给出实际账单。

每位开发者运行自己的 orch，配有独立的看板 agent 和 token。把工单分配给哪个 agent，就交给对应机器执行。同一套代码还提供 preview 模式，在开发服务器上运行单个实例，负责生产预览。

每张工单为什么要复制整套产品

跨仓库任务的难点，是验证这些改动放在一起能不能运行。Orch2 给每张工单分配完整工作区：6 份仓库克隆、独立数据、独立应用栈，以及独立的一段端口。

Git 先维护每个仓库的 bare mirror，再用 --reference --dissociate 克隆。前者借用本地对象加速，后者解除对象依赖，让工作区拥有自己的 Git 对象。作者称检出只需几秒。GitHub 认证通过每条命令的 HTTP header 传入，凭据不写入工作区磁盘。

入口路由器只占一个端口，按主机名分流：<ticket>.localhost 访问应用，code-<ticket>.localhost 访问浏览器 IDE code-shell。浏览器自行解析 *.localhost，新增工单不用添加 DNS 记录或重载代理。

数据也来自真实环境的副本。SQLite 通过受 token 保护的只读文件服务提供 VACUUM INTO 快照，避免直接复制正在使用 WAL 的数据库文件而得到损坏副本。下载后还检查文件魔数，防止把 HTML 错误页保存成数据库。

这部分解决的是复现条件：agent、开发者和验收者面对同一套可运行环境，减少只看单个仓库时漏掉的集成问题。

agent 能改代码，但不能自行决定交付

作者给 agent 设置了五层限制。

第一层清理环境变量中的秘密，覆盖 agent、应用栈和 IDE。第二层把每条 shell 命令放进操作系统沙箱：macOS 用 Seatbelt，Linux 用 bubblewrap；只允许写工作区和构建缓存，网络限定为 localhost、包仓库和 GitHub。

第三层在 SDK permission callback 和 PreToolUse hook 中重复执行权限策略，拦截 git push、切换分支、reset --hard、ssh，以及下载后直接通过管道交给 shell 执行的操作。Orch2 管理的文件只读，拒绝时返回原因。

第四层缩小工具范围，只开放 Orch2 自己的 MCP server，提供工单与讨论串、计划、应用栈控制和 endWork。没有 connectors，也没有 web fetch，作者担心后者泄露工单文本。

第五层是交付门禁：计划未完成、应用栈不健康或合并不干净，endWork 都会被拒绝。只有人把卡片移动到 Git Push，Orch2 才提交并推送代码。

他们在生产使用中还确定了一条规则：基础设施故障交给人。agent 修不了防火墙，继续尝试只会消耗 tokens。

我的判断

我认可这套分工：让脚本掌握状态流转，让模型处理代码，让人掌握提交和推送的放行权。相比让一个 agent 包办全部流程，它更容易回答「现在卡在哪里、谁能处理」。

但效果仍是作者的经验之谈。原文只给出首张完整工单的 0.8M tokens，没有任务规模、模型版本、失败率、人工介入次数，也没有与人工开发或其他方案的对照。不能据此判断它更便宜或更快。

完整复制产品也有前提。这里使用 SQLite，本地能启动整套产品；依赖大量云服务、共享测试环境的团队，隔离成本可能高得多。五层限制值得借鉴，但列出设计不等于证明安全，原文也没有提供绕过测试结果。Envizom 代码是私有的，读者拿到的是设计说明，无法直接复现实现。

能拿来做什么

• 给现有 AI 编程流程增加执行回执，记录每轮结果、token 用量和阻塞原因，先弄清资源花在哪里。
• 前端与后端联动修改时，优先建立按工单隔离的运行环境，把代码、数据和端口一起隔离，方便集成验收。
• 把提交推送、计划完成和服务健康做成明确门禁；仅在提示词里要求 agent 自觉遵守，约束不够可靠。
• 将鉴权、网络和基础设施故障分流给人处理，为 agent 设置停止条件，避免它在权限范围外反复重试。