Multi-Agent 系统设计原理

背景

“在 Multi-Agent 系统中，主 Agent 如何动态派生 Subagent 协同工作？”

这个问题看似简单，但如果你回答”就是多写几个 Prompt，让大模型自己看着办”，可能就差点意思了。

为什么？因为在实际的大模型工程落地中，放任自由就等于系统崩溃。

今天我们就来拆解一套能在百万级并发下稳定运行的多智能体架构，看看高手是怎么玩转”分身术”的。

---

一、核心运转逻辑：主 Agent 不干杂活

假设我们要干个大活，比如”调研过去十年七十五家科技公司的技术路线演进”。这要是让一个 Agent 单干，CPU 非得烧了不可。

高手的设计思路是什么？

主 Agent 自己不动手干杂活，它只负责规划和调度。

1.1 动态大纲：系统的灵魂

主 Agent 接到任务后的第一件事，是生成一个动态大纲（Dynamic Outline）。

这个大纲实时记录了：

• 哪些任务已经查过了
• 哪些任务正在执行中
• 哪些任务还没分发下去

动态大纲示例：
┌─────────────────────────────────────────────────────┐
│ 任务：调研75家科技公司技术路线演进                    │
├─────────────────────────────────────────────────────┤
│ ✅ 已完成：                                          │
│    - 苹果公司技术路线（Subagent-A 完成）              │
│    - 谷歌公司技术路线（Subagent-B 完成）              │
├─────────────────────────────────────────────────────┤
│ 🔄 进行中：                                          │
│    - 微软公司技术路线（Subagent-C 执行中）            │
│    - 亚马逊技术路线（Subagent-D 执行中）              │
├─────────────────────────────────────────────────────┤
│ ⏳ 待分发：                                          │
│    - Meta、特斯拉、英伟达...（剩余71家）              │
└─────────────────────────────────────────────────────┘

这个大纲就是整个系统的全局唯一真相源，谁领了什么任务、完成进度如何，一目了然。

1.2 delegate_task：派生 Subagent 的工具

主 Agent 手里握着一个核心工具：delegate_task。

当它发现大纲里有子任务需要分发时，就调用这个工具，瞬间派生出多个独立的 Subagent。这些小机器人领了任务就并行地去爬网页、读文档了。

主 Agent
    │
    ├── delegate_task("调研苹果公司") → Subagent-A
    ├── delegate_task("调研谷歌公司") → Subagent-B
    ├── delegate_task("调研微软公司") → Subagent-C
    └── delegate_task("调研亚马逊") → Subagent-D

在这个过程中，主 Agent 就像指挥家——它不弹琴，只负责看谁拉错了、谁还没开始。

这就是动态派生的核心：主 Agent 负责”想”，Subagent 负责”干”。

---

二、强制压缩机制：防止上下文爆炸

Subagent 都在外面干活了，问题也跟着来了。

2.1 信息爆炸问题

想象一下，如果 Subagent 把查到的几万字网页原文一股脑全发给主 Agent，会发生什么？

• 主 Agent 的上下文窗口瞬间爆掉
• 模型陷入”看了后面忘前面”的尴尬境地
• Token 费用能让老板直接找你谈话

2.2 解决方案：强制压缩

我们要给 Subagent 下个死命令：回来之前必须自我压缩。

Subagent 执行流程：

1. 爬取网页（获取原始内容，可能几万字）
2. 阅读分析（理解内容，提取关键信息）
3. 自我压缩（提炼结论和事实，过滤噪音）  ← 关键步骤！
4. 汇报结果（只带回精炼简报）

这样，主 Agent 拿到的永远是精炼简报，它的大脑永远能保持清醒。

这叫”收敛重于发散”——子节点必须负责压缩信息。

---

三、防止无限繁衍：工程硬约束

接下来这个难点更刺激：无限繁衍问题。

有没有人遇到过这种情况：Agent 碰到一个难题解决不了，就开始疯狂”生孩子”，子又生孙、孙又生子……Token 消耗呈指数级爆炸，系统直接死循环。

3.1 两个硬性约束

为了防范这种工程灾难，我们的架构里加了两个硬性约束：

约束类型	具体规则	作用
辈分隔离	只有主 Agent 有派生权，Subagent 严禁再派生 Subagent	扁平化管理，杜绝递归
物理限流	在代码里直接锁死最大并发数（比如20个）	用工程刚性限制模型随机性

正确架构（扁平化）：
主 Agent
├── Subagent-A
├── Subagent-B
├── Subagent-C
└── Subagent-D（最多20个）

错误架构（嵌套）：
主 Agent
└── Subagent-A
    └── Subagent-A-1
        └── Subagent-A-1-1
            └── ...（无限递归，系统崩溃）

这就是”扁平优于嵌套”——严禁递归派生，防止系统失控。

用工程的刚性去限制模型的随机性，这才是老司机的做法。

---

四、状态冲突解决：大纲即真相

任务一多，Subagent 之间会不会踩脚？

比如：

• Agent-A 和 Agent-B 都在查同一家公司，重复劳动
• Agent-A 把 Agent-B 刚写好的结论给覆盖了

这时候，动态大纲就派上用场了。

4.1 任务边界划分

主 Agent 分发任务时，会基于动态大纲做严格的边界划分：

def distribute_tasks(outline):
    for task in outline.pending_tasks:
        # 检查是否已被其他 Agent 领取
        if task not in outline.in_progress:
            # 检查是否已完成
            if task not in outline.completed:
                # 标记为进行中，分配给新 Agent
                outline.mark_in_progress(task)
                delegate_task(task)

状态必须中心化，大纲才是全局唯一真相源。

每个 Subagent 只知道自己领了什么任务，而主 Agent 通过大纲掌握全局状态，确保大家各走各的路、互不干扰。

---

五、系统评估：LLM-as-a-Judge

这种动态系统怎么评估好坏？

因为它每次跑的路径都不一样，传统的单元测试基本就失效了。你不能写断言说”第3步必须调用工具A”，因为下次运行可能第2步就调用了。

目前最前沿的方案是 LLM-as-a-Judge：

评估流程：
┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  主 Agent   │ ──→ │  最终报告   │ ──→ │  裁判模型   │
│  执行任务   │     │  （输出物） │     │  打分评判   │
└─────────────┘     └─────────────┘     └─────────────┘

简单说，就是请一个更牛的模型来当裁判，让它给主 Agent 产出的最终报告打分：

• 信息完整性：该调研的是不是都调研了？
• 逻辑连贯性：结论是不是有理有据？
• 准确性：引用的事实是不是正确？

通过这种规模化的自动评测，我们才能真正量化改了这个系统是真的变聪明了还是在乱跑。

---

六、总结：构建稳健 Multi-Agent 系统的三原则

构建百万级并发的多智能体系统，靠的绝对不是让模型自由发挥，而是克制的工程约束。

记住这三句话：

原则	核心思想	工程手段
收敛重于发散	子节点必须负责压缩信息	强制压缩机制，过滤噪音
扁平优于嵌套	严禁递归派生，防止失控	辈分隔离 + 物理限流
状态必须中心化	大纲是全局唯一真相源	动态大纲统一管理任务状态

在 AI 时代，能写出 Prompt 只是入门；能设计出稳健、可控的工程架构，才是你拿高薪的底气。

---

写在最后

Multi-Agent 系统的魅力在于：它让大模型从”单打独斗”进化成”团队协作”。

但团队的规模越大，管理的复杂度就越高。就像现实中的项目管理一样，没有好的流程和约束，团队就会陷入混乱。

主 Agent 就像项目经理，Subagent 就像团队成员，动态大纲就是项目管理工具。三者协同，才能让系统跑得稳、跑得快。

希望这篇文章能给你带来一些启发。如果你也在做 Agent 相关的工作，欢迎交流讨论！