什么活不能串行

我原来的怀疑

很长一段时间里，我觉得多 agent 并行是个找问题解决的方案。什么活急成那样，非得插队？串行 agent 有一个没人写进 PPT 的好处：一个全程累积的上下文，每一步都看得见之前学到的一切。没有信息交换要设计，因为根本没有"交换"这回事——记忆是完整的、免费的。并行则相反，先收一笔协调税：拆任务、隔离上下文、规定每个分支返回什么、合并时调解互相矛盾的结论。而且合并那一步本身是串行的——总得有人读完所有分支的产出才能合成，分支开得越多，这步越重。对小任务，这笔账不用算：税是固定的，省下的时间趋近于零。

这些我都说对了。我错的是以为它会一直对。

串行到底影响什么

全串行的账单有四行，只有第一行是"慢"。第一行是墙钟：一次长运行让人干等，或者更糟，教会人不再开口问。第二行是上下文压力：串行运行必须把见过的一切背在一个窗口里，而长窗口会退化——中间被遗忘，压缩悄悄吃掉细节。并行分支拿的是小而聚焦的上下文。所以并行同时是一种上下文管理策略，提速只是顺带的。第三行是重启成本：串行跑到第五十步中的第四十步死了，从头再来；分支独立失败，可以从分叉处单独重跑那一个，不必重跑全部。第四行是路径依赖：串行是贪心的，第一步走错，后面全被污染，而且你永远看不到没走的那条路长什么样。并行分支可以走真正不同的路线，再让评判者挑——这是并行在买质量，不只是买时间。

交叉点

结论翻转的原因，是账本两侧的增长方式不同。协调税近似固定：分支接口设计一次、反复复用。串行的墙钟随你敢交出去的任务颗粒线性增长。而任务颗粒随模型能力增长——能力每涨一截，工作单元就从"回答这个"变成"研究这个""审计这套代码""跑完这轮评估"。与此同时，单步可靠性上升，并行的经典风险——分支朝五个方向跑偏——在下降。一侧是固定成本加下降的风险，另一侧是线性增长的等待。越线不是品味问题，是时间问题。

我在自己的系统里已经不知不觉越过两次了。我的评估框架要并行跑几百个提示词，串行得跑几天——所以它的驱动被刻意做成无共享状态，N 路运行互不相干。而我的访客 agent，串行爬一遍 corpus 能让访客等上一分钟，正在接受同一套改造，只是低一个层级：同一层内彼此独立的检索 fan out 出去，只剩合成一步等所有人到齐。

真正难的是交换

并行真正要的不是算力，是回答一个问题：分支之间说什么？我的规矩是从反面学来的——分支之间应该交换工件，不交换对话。每个分支把耐久的产出写进一个共享的地方——黑板、store、corpus——合并方读工件，不读聊天记录。书面记录扛得住压缩、可以被检查、可以被作者自信之外的东西验证。让 agent 互相聊状态那条路，token 账单会爆，而且丢的恰好是合并时最需要的信息。

而且这堵墙后面还有一堵墙。并行生成会撞上串行验证：N 个分支产出 N 份东西，总得有人、或有一套 eval 来验收，而验证带宽是整个系统里最稀缺的资源。已经有团队在代码评审上撞过了——生成的变更把人淹没，最后只好再建一台机器去审第一台。你敢并行到什么程度，由你的门禁决定——由你的基准能不能真红决定——不由你能开多少分支决定。

我仍然串行的地方

深度是加宽不了的。每一步都依赖上一步完整结果的推理链，没有可以 fan out 的层，在那儿并行是演戏。小任务继续串行，因为税比奖大。分支之间需要细粒度共享可变状态的活，省下的钱会全花在合并冲突上。但这些如今是需要我逐个论证的例外了。不知不觉间默认翻了面：过去的问题是"这活为什么需要不止一个 agent"，现在的问题是"这活到底急在哪里不能并行——我把它留在队列里，到底省下了什么？"