Orca 多 Agent 开发：从 Issue 拆解到隔离验收

本案例根据 Niall 的《我把多 Agent 编程收进了 Orca》整理，聚焦作者已经使用的任务拆解与验收流程。个人配置不代表产品通用限制，规划中的能力不计入已完成成果。

从多个窗口到一个开发流程

原文作者曾同时打开多个 AI 编程客户端。同一个项目在不同助手之间接力时，需要反复解释上下文；多个任务又容易把改动混在一起，让验收变得困难。

作者希望集中管理这些 Agent，但不是让它们直接在同一个工作目录里一起改代码。真正的要求有两个：每个任务有独立空间，任务结束后又能把改动放在同一个项目里检查。

这次实践选择 Orca 作为执行环境，将讨论、Issue、隔离工作区和人工验收串成一条流程。

作者先使用自己的 SuperBrain 工作方法对方案做讨论。第一轮，各个席位独立给出判断；第二轮，读取脱敏后的其他答案并修订；最后由主 Agent 整合。

这一阶段的目的不是追求答案数量，而是提前暴露需求中的分歧。哪些事情一定要做，哪些暂时不做，哪些假设还没证据，应先形成清楚的结论。

讨论结束后，作者把结论拆成 GitHub Issue。每条 Issue 应小到一个 Agent 可以独立接住，又足够清楚，让执行者不用再次猜测目标。

作者将这套方法做成了 GitHub Issue Workflow 项目，原文记录它已经发布并被用于日常工作。重点不在 Issue 的名字，而在把“想做什么”转换成有边界、有输入、有完成标准的任务。

原文描述的自动化会寻找符合本地规则、带有 agent-ready 标签的待办 Issue，再为每个任务建立独立的 git worktree，交给一个 Agent 执行。

工作区隔离让各任务的改动可以分别查看，减少直接互相修改工作文件的情况。不过，它不会自动消除业务依赖，也不会替代合并时的冲突检查。

作者在自己的单机配置中最多同时运行三个任务。这是当时采用的并行策略，不是 Orca 的通用并发上限，也不是所有项目都应照搬的数量。

任务完成以后，改动回到作者面前。作者查看 diff、批注问题、处理冲突，决定接受还是返工。

在原文这套受控流程中，改动默认不会自动推送到远程、创建 PR 或发布。作者接受后才进行本地合并并关闭对应 Issue。自动执行与最终发布之间，保留了明确的人工判断点。

表中的材料要求是对原文流程的整理，不表示某个工具会自动补齐这些内容。

原文已经记录的成果，是把“讨论结论 → Issue → 独立 worktree → 人工接受”做成作者实际使用的单机工作流，并在飞书与 Orca 两端共用一部分 Skill。

作者还提出跨工具共享知识与经验的“共享大脑”愿景，但明确写到相关协议和系统尚未完成。因此，不能把共享 Skill 写成已经拥有跨 Agent 的统一记忆系统。

原文也没有提供改造前后的缺陷率、吞吐量或用时对照。本案例呈现的是流程变化，不宣称已经证明某种效率倍数。