# 从单一 Agent 到 Multi-Agent

> 解释为什么复杂任务需要多个角色清晰、上下文干净的 Agent 协作。

## Multi-Agent 的必然性 [#multi-agent-的必然性]

单个 Agent 的哲学是上下文工程的哲学，而在复杂的任务中，只有引入 Multi-Agent，才能继续保证单个 Agent 的上下文的洁净。我们在 [上下文](../single-agent/context) 一节提到过：

> 要评判一个 Agent 上下文工程质量的好坏，根本便在于“约束（**我是谁？**），信息（**从哪里来？**），任务（**到哪里去？**）”这三点是否完整、明确、清晰；以及与以上三点无关的冗余上下文应尽可能剔除。

而在一个复杂的任务如“软件开发”中，我们需要多个不同的角色，如产品经理、架构师、编码人员、测试人员、运维人员等等，我们不该让单个 Agent 去担任多个不同的角色，这不符合“约束（**我是谁？**）这一点需要明确”的要求。

另外，在一个复杂的任务中必然包含一系列可以解耦的子任务，那么对于每一个子任务我们都应只让执行的 Agent 了解与子任务相关的必要信息，如果让单一 Agent 了解全部的信息去完成全部的任务，则不符合“与以上三点无关的冗余上下文应尽可能剔除”的要求。

Agent 不是真实的人，我们只需要无限复制上下文就能无限创造相同的 Agent。既然一个复杂的任务包含一系列可以解耦的子任务，那么我们就可以创造等量的 Agent 去分别执行——这样做除了上述“维持上下文洁净”上的意义，更重要的是大大提升了任务执行的效率，以及节省了 LLM 的上下文容量和 token 消耗。

在 The One 里，这就是**工作组**：主助手把一个事项的活交给一个工作组模板时，组里的每个角色都有自己的指令，移交时只传过去发出方选择交出的内容。见[工作组](../../the-one-app/working-groups)。

## 从单一 Agent 的概念演化映射为 Multi-Agent 中的概念 [#从单一-agent-的概念演化映射为-multi-agent-中的概念]

### 从 ReAct 到结对 Agent [#从-react-到结对-agent]

ReAct 是单个 Agent 在每次行动之后审视当前的状态进行重新推理。

而到了 Multi-Agent 的领域中，我们便可以让另一个 Agent 来担任这个审视者的角色，形成结对 Agent；当然 Multi-Agent 的架构并不是死板的，更自然的是一个 Agent 的 reviewer 在 review 之后继续后续的工作，再与其他 Agent 进行通讯。

当一个 Agent 在运行时就能这样做——在 Graph 运行期间创建、克隆并连接其他 Agent，而不是遵循一张预先固定的拓扑——这种能力，我们称之为 [Prolifera Engineering（增殖式工程）](../prolifera-engineering)。

而当一套被验证有效的协作结构不再只存在于一次运行的记忆里，而是连同每个成员的 prompt、Skill 与工具，被完整写成一份可复用的 Graph 模板时——这份记录，我们称之为这支小组的基因：[A-Genetic Engineering（Agent 基因工程）](../a-genetic-engineering)。

Source: https://the-zeroth.com/zh/docs/multi-agent-architecture/evolution