各家AI擅长点不同,我要在一个软件里联合开发

那天在 Windows 上开着 Codex。跑着跑着，内存往上爬。把窗口关掉，进程没跟着走，也没把内存还回来，关不干净。等它总算消停，整台机器已经被拉爆过一轮。

卡住我的不是项目多。就是一个桌面助手，把自己吃满了。

后来的需求变了。写代码、改中文、审改动、查资料，各家擅长的点不一样，我想让它们坐在同一张桌子上，各干一段，最后收成一份。问题于是从「内存够不够」，变成「活怎么分、记忆怎么不串、改动怎么收」。

5 秒结论

机器内存先被单一助手吃满。

一个知识库接不住所有项目，会串台。

各家擅长点不同，要能调度。

分开的工作副本带着这次会话和目录里的文件，改动以 PR 收回来看。

01

机器内存被拉爆，单一助手待不久

一台 Windows，一个 Codex，一个长会话。内存不是一下子满的，是一点点往上爬，爬到你不得不管它的时候。关掉窗口，进程还在，内存也没回来。

于是变成：清一遍，干活，再清一遍。这一步的结论其实很窄——单一桌面助手，在这台机器上待不久。不是我的项目太重，是它自己把自己撑住了。

所以第一件事，是把两个「内存」分开说。机器内存是机器资源，被吃满就是被吃满；对话记忆是上下文，混了就是混了。这两件事的解法完全不同，混在一起谈，永远谈不清。

02

一个知识库接不住全部

昨天写公众号，今天写小程序，旁边还挂着一条代码。如果这些活都进同一份知识库，助手的上下文就很容易串。昨天的表述串进今天的代码，小程序的结构被当成公众号的规矩。

它不是「记错了」，它是本来就在同一个池子里读。

独立窗口看起来像个解法。但如果这些窗口底下连的还是同一份知识库，记忆照样混。窗口是新的，上下文不是。

03

各家擅长点不同，才要拆开给几家

写代码、改中文、审改动、查资料，各家长短不同。有的下手快，有的改中文顺，有的看改动仔细，有的查资料稳。

我不在这里点名哪家做什么，因为分工不该由一篇文章替你定。但有一件事是确定的：一件活，往往要拆开给几家，再收成一份。拆得开、收得住，才叫联合开发。

04

到这一步，才出 Orca

我需要一张调度桌。Orca 在这台 Windows 上是 1.4.217，开源 MIT，桌面端。它启动的，仍然是我已经在用的那些助手，走我在付的订阅；软件本身不另卖一份模型。

先说清它不做什么。它不是内存补药，也没治好那个内存问题。多家助手一起跑，通常比只开一家更吃内存。它管的是另一件事：怎么把几家摆在同一张桌子上，各干各的。

拿我手头三条活举例。三条活，分进三份工作副本（worktree）。这里必须说准：worktree 隔开的是这份仓库的一份工作副本，它不是沙箱。共用的知识库、全局记忆，分开目录之后，仍然可能被一起读到。别指望窗口一分开，记忆就自动干净。

再说跟着一条活走的东西，其实只有两样：这个会话里已经说过的话，加上这个目录里的文件。新开一个助手，它读得到文件，读不到没写进文件的上一段聊天——除非接着同一个会话继续。所以我不写「不用再填任何背景」，那句话不成立。

这张图片可以看到我的多项目是通过工作区的形式来进行隔离的；这样就可以做到项目之间的清晰的隔离

这张图里能看到分支「微信公众号」相对 master，下面是还没提交的文件，底部是提交。它说的是：改动还停在这条分支上，可以看，也可以先不进主线。PR 是再往上收的那一步，这张图本身不是 PR 页面。

干完之后，改动以 PR 回来看。PR 收回的是可看、可退的改动，不收回记忆。合一次 PR，不会让上下文自动变干净。这两件事要一直分开想。

顺带省下来的一步是：不用自己再 clone 一份来做隔离，工作副本这件事交给工具管。

05

带走三句

第一句：机器被单一桌面助手拖死的时候，先分清是桌面壳的问题还是程序本身的问题，换成调度桌，不等于内存就回来了。

第二句：活要分开、还要审完再收的时候，用 worktree 和 PR。

第三句：因为模型是有幻觉的，一个模型去写一个项目，用其他的模型和Agent去看的时候，会发现意想不到的bug和视角。