【我把多 Agent 编程收进了 Orca】

我的电脑屏幕上，同时开着三四个 AI 编程助手。任务栏里挤满了长得差不多的窗口，我一会儿点开这个看一眼，一会儿切到那个问一句。最要命的是同一个项目——上午在 A 里改了接口，下午到 B 里接着写，B 根本不知道 A 改过什么，上下文得我从头再讲一遍。机器在喘气，我在来回跑，项目却没快多少。

1. 为什么 Orca 好用

1.1 飞书的边界

这份烦躁不是凭空来的。很长一段时间，我把一整支 agent 队伍都安排在飞书里，讨论、对齐、留档，全在那儿。飞书做协作的面，确实做得好——我把飞书当协作工作台这件事还专门写过一篇《我把飞书做成了我的 AI 协作工作台》。

但复杂开发是另一回事。那是「看报错、定位文件、改代码、跑测试、再看」一个接一个的循环，每一步都要代码和工具链在眼前，我不想在每个循环里都回飞书开个窗口。飞书教会我一件事：协作有协作的桌子，编程有编程的工地。

1.2 多 GUI 的摩擦

于是我回到工程环境，一口气打开不止一个 agent：Codex 管一块，Qoder 管一块，各开各的客户端。新的麻烦马上来了。

先是电脑吃不消。图形客户端往往都不轻，开两三个，风扇就先替我抗议。事情一多，我还要在窗口之间来回切，切着切着，脑子里那根线就断了。

更难受的是同一个项目怎么接力。A 刚改完，B 并不会凭空知道发生了什么；它得重新读代码、重新理解状态，我也得再讲一次。agent 明明多了，我却成了负责搬上下文的人。

1.3 我要的环境

我后来意识到，问题不在于缺一个更聪明的 agent。我缺的是一个「地方」：能把许多 agent 聚到一处，给每个任务一块独立的地盘，又能让我随时看清每条线走到哪里。

这也是为什么，我不太想再用一个大而全的 AI 客户端解决所有事情。飞书已经帮我处理协作，到了编程这里，我只想要一个专注编程的 agent 集合工具。

1.4 Orca 的回答

后来我遇到了 Orca。Orca 管自己叫 Agent Development Environment，可以理解成专门给人和编程 agent 共用的工作环境。Claude Code、Codex、OpenCode 这些命令行 agent 都能并排放进去，用自己的订阅，各干各的活。

进到 Orca 以后，我不用再为每个 agent 单独开一套图形客户端。项目、Issue、PR、工作区也待在同一张视图里，少了很多「我刚才在哪儿来着」的停顿。更关键的是，它能为任务创建独立的 git worktree：几个 agent 各在自己的工地施工，互不踩代码；做完以后，改动又能回到同一个项目里看。

它也没有因为专注编程，就把常用能力砍掉。离开电脑时，我可以用手机 companion 看 agent 进行到哪一步；重复工作可以按提示词设成定时自动化；Git 状态、diff 批注、冲突处理和 PR 评审，都能留在应用里。它原生接入 GitHub 和 Linear，Issue、PR、项目看板就在项目旁边。

我尤其喜欢它同时保留 GUI 和 CLI。想直接点，就在界面里操作；想让 agent 代劳，公开 CLI 可以查 worktree、控制终端、跑自动化。我还可以把这些命令封进自己的 Skill，让 agent 反过来驱动 Orca。这个玩法是我顺着公开接口搭出来的：GUI 负责让我看得明白，CLI 负责把重复动作交给 AI。

工具到这里才算真正就位。Orca 对我最重要的地方，也慢慢显出来了：它放得下一整套多 agent 开发流程。

2. 我是如何使用 Orca 的

2.1 先想清楚

我的第一步不是开工，而是先把事情想清楚。

我参考的是 Matt Pocock 的开发流程：别急着把需求丢给 AI，先把模糊想法压力测试成一份 agent 能读懂的说明，再拆成能独立完成的小块，让每个 agent 带着新鲜、干净的上下文去干活。他提到过 smart zone / dumb zone：上下文越长、越杂，agent 的表现越容易往下掉。所以任务要拆小，上下文要新。

想清楚这一步，我交给自己的 SuperBrain。它是一个「外脑会诊」Skill。第一轮，几个 CLI 席位互不商量，各写各的答案；第二轮，它们读到脱敏后的同侪答案，再修订自己的方案；最后由主 agent 整合判断。

这个过程很像把几个人拉到一张桌上，但不让他们一开始就互相带节奏。很多一拍脑袋的念头，走完两轮就会露出破绽。拆任务之前，我得先把「到底要做什么」吵明白。

2.2 拆成 Issue

想法清楚了，我会把结论拆成一条条可以独立完成的 GitHub Issue。每个 Issue 小到足够让一个 agent 单独接住，又清楚到不用再猜我到底想要什么。拆得好不好，直接决定后面执行时会不会跑偏。

这条从结论到执行的路，我没有让它停在设想里，而是把它做成了独立开源项目——GitHub Issue Workflow，v0.1.0 已经发布，我自己也一直在用。

它由几个能拼在一起用的 Skill 组成，合起来就是一条完整的流水线：先把仓库的上下文和我真正想做的事，整理成一条可执行的 Issue；再把 Issue 放进隔离的 worktree 里受控修复；Autopilot 会自己找出符合本地规则、带 agent-ready 标签的待办 Issue，在 Orca 里给每个任务开一块看得见的独立工地；最后还有一个负责整套工具本地升级的。我把它们当成同一条流水线上的环节来用，英文名反而不怎么去记。

2.3 隔离执行

Issue 有了，就该施工。

Orca 的 worktree 隔离本身已经能用：每个任务在自己的 worktree 里跑，agent 可以并行作业，不会直接踩到彼此的代码。「一个 Issue 对应一个 worktree、再交给一个 agent」这条线，我已经在 GitHub Issue Workflow 里落地成了单机的 Orca 自动化：Autopilot 找到符合条件的 Issue，就在 Orca 里开一块看得见的独立工地，最多三件同时并行。

改动默认不会自己推到远程、不会自动建 PR、更不会发布——一切都等我过目。我 accept 之后，改动才在本地合并，那条 Issue 也顺手关掉。任务一旦拆小，再放进隔离的工地，每个 agent 看到的上下文就会短很多：只看自己那一段，够用，也不乱。

2.4 汇总验收

并行跑完，结果要收回到我眼前。

在 Orca 里，我可以直接看每个 worktree 的改动，读 diff、批注、处理冲突、评审和批准 PR。GitHub 的改动就在应用里，不用再跳到另一个地方找。哪个 agent 的解法更合适，要不要合并，哪一段得返工，这些判断仍然由我来做。

我并不想把判断也自动化。Orca 负责把工地铺开、把线索摆齐，我负责最后拍板。这样既能并行，又不至于把项目变成一辆没人握方向盘的车。

2.5 从共享 Skill 到共享大脑

跑过几轮之后，我越来越在意一件事：这次做完，究竟有什么能留给下一次？

现在，我的 Skill 已经能在飞书和 Orca 两端共享。同一套方法，在协作的桌子上能用，到了编程的工地上也能用。至少 agent 不用每换一个地方，就重新学一遍我怎么做事。

下一步，我想再往前走一点：让多个 agent 共享知识和经验，跨过飞书与 Orca 的边界，连成一张「共享大脑」。它目前还是一个愿景，协议也好、系统也好，我都还没做出来。飞书那篇文章里我写过一句话：多用知识库，多沉淀。现在 Orca 把执行这一头接住了，我想继续把另一头接起来。

回到开头那台风扇呼呼转的电脑。现在做同样的事，我不用再在几个窗口之间当搬运工：agent 在一张工作台里干活，会诊、Issue、改动和经验也能顺着一条线留下痕迹。

Orca 是这条线的执行端。至于共享大脑，我还在往前搭。