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 并行执行，最后汇总结果。

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

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

模式 2：流水线（Pipeline）

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

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

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

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

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

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

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

上下文共享 vs 隔离

多 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

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