34 用多 Agent 并行化扩展

章节 34 / 37 · 课程总览 · 起始 4:54:35

章节主旨

把此前一次只跑一个 agent 的串行做法,升级为同时跑多个 agent 并行工作,以此成倍放大产出;并给出并行的搭建方式、实践数量上限,以及「三方案并行竞标」这一进阶用法。

此前的工作都是Agent串行,即一次只跑一个,做完任务一再做任务二。并行化则是「一口气」同时做任务一、二、三,最后把各自输出重新合并。只要环境隔离得当,理论上可扩展到任意多个实例。

具体怎么开?没什么玄机——并行的全部动作就是多开几个终端实例。VS Code、Antigravity 或任何基于终端的工作流都支持分栏(pane),你在不同窗格里各跑一个 Gemini / GPT / Claude Code 即可。

Nick 自己偏好竖排三个(左、中、右),日常不超过三个同时跑。原因是超过后自己的注意力开始涣散,记不清每个 agent 在干什么——除非是可长时间无人值守的后台任务。

当前前沿模型大多用相近的数据、相近的方式训练,智能水平封顶在同一档;彼此有差异,但没有代差。因此并行不必都用同一个模型。

若某个 IDE 或模型限流更严、成本更高,与其对着跑三个 Claude 实例,不如一个 Claude、一个 Gemini、一个 GPT 各跑一个。因为各家的初始化文件(agents.md / claude.md / gemini.md 等)一致,对模型而言没有功能性差异。

好处有二:一是把每个平台的用量都压在其收费阈值(如 Claude Max 计划月费 200 美元之上再按额度加钱)之下,用三个模型顶替一个模型的超额;二是不同模型给出略有差异的解法,在还在「建造 / 试做」阶段时反而有益。

Nick 的经验值:两个同时跑是他常态的基线,四个是他认为「再多就适得其反」的软上限。开一堆标签页、每个都有 agent 在忙,看着像超能力,但那只是「感觉在产出」。

关键区分:感觉忙不等于真在忙,感觉在产出不等于真在产出。并行数一旦过多,大部分 agent 时间其实都花在「等你切到那个标签页去处理它」上,人成了瓶颈。

所以他把自己钉在三到四个,再多基本是搬石头砸自己脚。这条上限是给注意力设的护栏,不是技术极限。

不会搭某个工作流时,初级做法是直接让 agent「帮我建一个做这事的工作流」当第一版。进阶做法是:先让一个 agent 给出三种不同的搭建方案,每种都带详细步骤和优劣权衡(pros/cons),因为要分发给别的模型。

把三种方案分别丢给三个独立实例并行建,建完各自测分——比如一个 75%、一个 84%、一个 99%,显然选 99% 那个,它在速度、成本、准确度上综合最优。这样一次得到三倍的搜索空间,而不是从一个次优解慢慢改到最优。前期多花几分钟出方案,能省下后期两三小时才发现架构选错、还在调 bug 的时间。

工程上要点:给每个 agent 一个独立工作目录(Nick 用 tmp/1、tmp/2、tmp/3),并在 prompt 里明确告诉它「你现在在这个文件夹工作」,避免三份相似构建交叉污染文件。4:59:33

选定优胜方案后,把它搬进正式位置(如 DO 框架 / Claude Skills),然后必须重新全量测试——文件搬动后容易出现引用路径错乱,不重测就会留隐患。5:00:07 同样的并行思路不止用于「建造」,也可用于「执行」,乃至配合后台任务跑更多 agent。

parallelization(并行化,让多个 agent 同时工作以放大产出)
sequential(串行,一次只跑一个 agent,做完一件再做下一件)
soft max(软上限,超过后开始适得其反的经验数量界限,此处指 4 个 agent)
initialization files(初始化文件,agents.md / claude.md / gemini.md 等,统一后换模型无功能差异)
search space(搜索空间,并行多方案带来的可选解范围,越大越可能触及最优解)

Nick 认为并行 agent 的实践基线和软上限各是多少?为什么不建议再多? 答案:基线 2 个、软上限 4 个。再多时人成瓶颈,agent 大多在等你切标签页处理,「感觉在忙」不等于真产出。 4:57:23
为什么并行时可以混用 Claude / Gemini / GPT,而不是都开同一个模型? 答案:前沿模型智能水平相近、无代差,初始化文件统一后功能无差异;混用能把各平台用量压在收费阈值下、规避限流与超额成本。 4:56:22
「三方案并行竞标」的完整流程是怎样的? 答案:先让一个 agent 出三种带优劣的方案 → 分发到三个独立实例(各给 tmp/1,2,3 独立目录)并行建 → 各自测分选最优 → 搬入正式位置后必须重新全量测试。 4:58:10