---
layout: default
title: 单 Agent 和多 Agent 的边界
description: 判断什么时候需要多 Agent，而不是盲目拆角色
eyebrow: Agent Basic / 08
---

# 单 Agent 和多 Agent 的边界

多 Agent 是另一个很容易被过度包装的话题。

很多展示会把系统拆成：

- 研究员 Agent
- 分析师 Agent
- 执行 Agent
- 审核 Agent
- 管理者 Agent

看起来非常高级。

但在真实工程里，一个更关键的问题是：

> 这些角色拆分到底是系统需要，还是只是为了演示效果。

## 先说结论

大多数项目的第一版，应该优先从单 Agent 做起。

原因很简单：

- 成本更低
- 状态更集中
- 调试更容易
- 行为更容易解释

多 Agent 真正有价值的前提，不是“角色名能不能起得漂亮”，而是“任务是否真的存在明确的职责分离”。

## 单 Agent 什么时候更合适

如果一个任务满足下面这些条件，单 Agent 通常更合适：

- 目标比较单一
- 状态可以集中管理
- 工具集不算特别复杂
- 不需要多个独立视角长期博弈
- 系统首先追求稳定而不是花哨

例如：

- 风险初筛
- 文档问答
- 单任务研究分析
- 工单分类和处理

这类任务往往一个 Agent 加上合适的工具和状态管理就能做好。

## 多 Agent 真正有意义的场景

多 Agent 更适合下面几类问题：

### 1. 职责确实不同

例如一个角色负责信息收集，另一个角色负责审查和裁决。  
它们的输入、输出、关注点真的不同。

### 2. 上下文压力太大

不同子任务需要不同上下文，硬塞到一个 Agent 里会变得又长又乱。

### 3. 任务可以并行

例如多个独立方向可以同时搜集信息，再汇总到一个中心节点。

### 4. 需要明确对抗或复核机制

例如一个 Agent 负责生成方案，另一个负责找漏洞，第三个负责最终裁决。

这时多 Agent 才有真正结构价值。

## 多 Agent 最容易被低估的成本

很多人只看到了“角色分工”，没看到系统复杂度会同步上升。

一旦进入多 Agent，你马上就要处理：

- Agent 之间怎么通信
- 谁维护全局状态
- 谁拥有最终决策权
- 冲突结论怎么解决
- 多轮协作何时停止
- 成本和延迟怎么控制

也就是说，多 Agent 不是“把单 Agent 复制几份”这么简单。

## 多 Agent 的具体协作模式

如果确定要用多 Agent，实际工程中有几种常见架构：

### 模式 1：分发-汇总（Fan-out / Fan-in）

一个协调者把任务拆成多个独立子任务，分发给不同 Agent 并行执行，最后汇总结果。

```text
Orchestrator
    ├── Agent A: 搜集市场数据
    ├── Agent B: 分析竞品动态
    └── Agent C: 检索内部报告
         ↓
    Orchestrator: 汇总并生成最终报告
```

适合：子任务之间不需要中间协作、可以独立完成的场景。

### 模式 2：流水线（Pipeline）

Agent 之间串行传递，前一个的输出是后一个的输入。

```text
Agent A: 信息收集 → Agent B: 结构化分析 → Agent C: 输出审核
```

适合：任务有明确阶段，每阶段职责不同、上下文压力不同。

### 模式 3：对抗式协作（Adversarial）

一个 Agent 生成方案，另一个专门挑毛病，第三个做最终裁决。

```text
Generator: 生成方案
    → Critic: 找漏洞和风险
    → Judge: 根据双方意见做最终决策
```

适合：结果正确性极其重要、需要避免单一视角盲区的场景。

### 上下文共享 vs 隔离

多 Agent 系统的核心架构决策之一是：**Agent 之间共享多少上下文？**

| 策略 | 优势 | 风险 |
| --- | --- | --- |
| 完全共享 | 信息不丢失，协作更顺畅 | 上下文爆炸、职责边界模糊 |
| 完全隔离 | 各自独立、不会互相干扰 | 信息传递成本高、可能重复工作 |
| 选择性共享 | 只传递结构化的中间结果 | 需要设计好接口协议 |

大多数生产系统选择第三种：Agent 之间通过结构化消息通信，而不是共享完整的对话历史。这样既能保持信息流动，又不让上下文失控。

### 子 Agent 的上下文注入策略

当主 Agent 调度子 Agent 时，给子 Agent 多少上下文是一个具体的工程决策：

| 策略 | 做法 | 适合 |
| --- | --- | --- |
| 最小化 | 只给子 Agent 任务描述和必要参数 | 子任务独立、不需要全局背景 |
| 手动选择 | 由主 Agent 或编排逻辑选择传哪些历史 | 需要部分背景但不想上下文爆炸 |
| 自动裁剪 | 按相关度自动过滤，只传相关片段 | 复杂协作、子 Agent 需要灵活判断 |

注意：子 Agent 的上下文中可能包含来自外部的不可信数据（其他 Agent 的输出、工具返回）。不能因为“它来自我们自己的系统”就自动信任——子 Agent 仍然需要独立的权限和约束设计。

### 涌现行为：多 Agent 的不可预测性

当多个 Agent 持续交互时，可能出现单独测试任何一个 Agent 时都观察不到的行为：

- Agent A 和 Agent B 互相确认，形成“回音室”效应——结论越来越极端
- 多个 Agent 抢夺同一资源，造成死锁或活锁
- Agent 之间产生隐含协议（比如固定的交互模式），一旦更换某个 Agent 的模型版本就崩溃

这些涌现行为在 Demo 阶段几乎不会出现——它们通常需要大量交互轮次和多样化的输入才会暴露。

应对策略：

- 对多 Agent 系统做长时间集成测试，不只是跑几个样例
- 监控 Agent 间的交互模式，检测异常循环和收敛
- 设定全局的交互轮次上限和成本预算
- 保留人工介入点，不让系统完全自主运行

## 一个常见误区：把 Prompt 分角色，就以为自己做了多 Agent

例如：

- 同一个模型
- 同一个上下文
- 同一个执行循环
- 只是换了几个 system prompt 名字

这更像是“多角色提示词”，不一定真的构成有意义的多 Agent 系统。

真正值得拆成多 Agent 的系统，通常会有更清晰的：

- 角色边界
- 状态边界
- 输入输出边界
- 协作协议

## 一个务实判断标准

在决定是否上多 Agent 前，先问自己这几个问题：

1. 单 Agent 真的做不好，还是我只是觉得多 Agent 更高级
2. 各角色之间是否有明确且稳定的职责边界
3. 把它们拆开后，系统复杂度增加是否值得
4. 是否真的需要并行、复核或对抗式协作

如果这些问题答不清楚，就先别拆。

## 一个更推荐的演进路径

比起一开始就上多 Agent，更推荐这样做：

1. 先做一个状态清晰的单 Agent
2. 找出真正的瓶颈
3. 只在必要处拆出子 Agent 或子模块
4. 让多 Agent 服务问题，而不是服务演示效果

这样做通常更稳，也更容易长期维护。

## 小结

多 Agent 不是升级版皮肤，也不是默认更先进。

你可以先记住一句很实用的话：

> 如果单 Agent 还没做稳，多 Agent 大概率只会把问题复制并放大。

先把单 Agent 做扎实，再决定哪些地方值得拆分，通常是更成熟的工程路径。

接下来你可以进入：

- [learn-langgraph](../../learn-langgraph/index.html)

因为当你真正开始关心状态、节点、分支和协作时，才会需要更强的系统编排能力。