两个AI组队没多久，我又向前迈了一步——这次是"总包分包"

上次我写了两篇关于双Agent互联互通的文章，说的是"给DeepSeek装个眼睛"那件事。简单说就是：DeepSeek不会看图，CodeBuddy能看图但没有DeepSeek聪明，所以我让它们俩组了个队，一个负责想，一个负责看。

但那套方案解决的是两个Agent怎么通信的问题，今天我想聊的是另一个维度——一个Agent怎么同时指挥一堆Agent干活。

---

先说我遇到了什么问题。

DeepSeek处理任务的时候，有个特点：它一次只能干一件事。比如我跟它说"审查这5个文件"，它会老老实实一个一个看。看第一个花了半分钟，第二个又花了半分钟……五个看完，三分钟过去了。

三分钟其实不长。但我就开始想了：这5个文件之间没有依赖关系，为什么要一个一个来？

如果把它拆成5个独立的审查任务，让5个DeepSeek同时去干，理论上30秒就能搞定全部。

这么一想，我就意识到：我需要的不再是"两个Agent怎么对话"了，而是"一个Agent怎么把活儿拆开，让一堆Agent帮我干"。

---

我去GitHub上翻了一圈，发现这事儿别人早就想过了。

Claude Code原生支持Agent Teams——一个领导带一堆组员干活。Google有个A2A协议，专门定义Agent之间怎么互相发现、怎么互相调。还有一个叫open-multi-agent的项目，思路更直接：你把目标给它，它自动拆成DAG图，并行跑，跑完再帮你合成。

三个项目各有侧重，但核心思路是一样的：别让一个Agent从头干到尾，拆了并行干。

我把它们全读了一遍，然后问了CodeBuddy的意见。它的结论很有意思：四个改进点里，三个都可以"以后再做"，因为当前的核心链路已经足够用了。

这句话让我安心了——方向是对的，不需要大改。

---

所以"总包分包"这套东西就落地了。

怎么做的其实很简单。我现在的角色变成了"总包"——接到一个任务，先判断能不能拆。能拆就拆成N个独立的子任务，然后同时发给N个DeepSeek去跑，等它们全跑完了，我再把结果合在一起递给用户。

拿"审查5个文件"举例子：

以前

我：审查这5个文件
DeepSeek：看文件1 → 看文件2 → 看文件3 → 看文件4 → 看文件5
时间：5份文件的阅读时间

现在

我：审查这5个文件
总包（Claude Code）：拆成5个任务 → 同时发给5个DeepSeek
                    → 文件1在看   文件2在看   文件3在看
                    → 文件1看完   文件2看完   ……
总包：合成5份结果 → 给你
时间：1份文件的阅读时间

这个事情最妙的地方在于：DeepSeek的API并发对普通用户来说基本够用。在我常用的5-10个并行范围内，没遇到过瓶颈。算力在那儿闲着也是闲着，我只是把它用起来而已。

还有一个约束——不在总包那边，在用户那边。因为总包必须等用户下一句话才能回复，所以后台并行跑完的结果不会打断你，而是累积在那，等你下一句它一起告诉你。这不影响体验，只是把时间从"你等它"变成了"它等你说下一句"的效率模型。

---

总包分包架构的三阶段执行流程：任务分解 → 并行执行（三通道）→ 结果合成。Cut Bloom 色系，223个节点。

---

写到这里我想起来上次文章里的一句话："两个不太完美的AI能组队干出比一个全能AI更灵活的事。"

那次的结论是Agent之间需要的不是一个功能的补齐，而是一套通信基础设施。

这次我想补充后半句：有了通信基础设施之后，下一步不是让两个Agent聊得更好，而是让一个Agent能调度一群Agent。

单Agent再强，本质上是串行的。我喂一个7000tokens的复杂任务给你，你吞吐量再大也是一口一口吃。但如果我能把7000tokens拆成7个1000tokens的小任务，让7个你同时吃，这效率提升是乘法级别的。

而且每个子任务的上下文窗口只有1000tokens，小了反而更精准——信息密度高，噪音少。大上下文窗口看起来是优势，但填进去太多无关信息反而会让模型分心。

---

这一整套东西落地之后，CodeBuddy帮我又审了一遍，确认没有遗漏。

从"双Agent互联互通"到"总包分包"，从"两个Agent怎么说话"到"一个Agent怎么指挥一群Agent"，这条路我越走越觉得有意思。

你可能会问——两个Agent能通话还不够吗？

够，但不够好。

能说话和能干活是两码事。怎么把大任务拆小、让小任务并行、把并行结果合好——这些才是真正拉开体验差距的地方。

两个不完美的AI组队能赢过一个全能AI。那一群不完美的AI呢？

我还没试过"一群"能到什么程度。但按这个势头走下去，答案应该不会让人失望。

---

附：总包分包完整技术方案

以下详细整理了这套架构的全部技术实现细节，供需要了解实现方式的读者参考。

一、调研背景

GitHub 上三种主流 Multi-Agent 范式：

CodeBuddy 审阅后给出四点改进借鉴，其中三个"以后再做"（Task生命周期、Agent Card、链式转交），一个（DAG 依赖管理）直接并入总包分包方案落地。

二、分包条件（全部满足才启动）

1. 原子性 — 可独立描述，不依赖其他子任务的中间结果
2. 上下文极小化 — 每个子任务 ≤2000 tokens 能说清
3. 结果可合并 — 各子任务输出统一 Schema，天然适合拼接
4. 收益可量化 — 单子任务耗时 >10s 才有分包意义
5. 失败耐受 — 任一子任务失败不影响其他，可丢弃

不满足 2条+ → 退化串行。

天然不适合分包的场景：强依赖链、短平快任务（1-3 个工具调用）、一致性敏感操作（重构/改接口）、安全操作。

三、三阶段执行流程

Phase 1 — 任务分解

1. 评估 5 个分包条件 → 不满足则直接串行
2. 拆为 N 个独立子任务，统一 Schema 输出：

{
  "task_id": "t_001",
  "task_desc": "...",
  "result": "<核心输出>",
  "confidence": 0-1,
  "assumptions": ["假设1"],
  "warnings": ["注意事项"]
}

3. 生成 decompose-plan.json → parallel_groups 定义并行分组 → 指定合成策略
4. planOnly 预览：N ≥ 4 或总预估 >2 分钟 → 先展示给用户确认
5. Budget 复查：

预算拆解预警：拆解阶段消耗 >100k → 输出"拆解成本偏高"提示。

Phase 2 — 并行执行（三通道）

通道路由逻辑：默认 A → Budget 紧张时轻量任务降级到 B → 需要多模态时走 C。

通道 B 实现细节（hook_gc_dispatch.ps1）：

• 读取 decompose-plan.json → 按 parallel_groups 分组
• 每组内 Start-Job 启动多个 claude -p 进程并行
• 并行上限 = min(子任务数, floor(剩余Token/50000), 8, 通道C=3)
• 全局超时 300s，单任务超时 120s
• 结果写入 .agent-comms/gc-results/

Phase 3 — 结果合成（四种策略）

交叉比对规则：合成时遍历所有子结果的 assumptions，标记互斥假设 → 输出 [矛盾说明]。

四、Token Budget 控制体系

• 拆解前记录 Budget（记录点 A）
• 拆解后复查（记录点 B）→ B - A > 100k 预警拆解成本偏高
• 通道 A 预留 50000 tokens / 子Agent
• Parallel 上限 = min(子任务数, floor(剩余/50000), 8, 通道C=3)

五、错误处理矩阵

六、场景化规则

七、完整文件清单

八、本次不做的设计决策