从单一 Agent 到 Multi-Agent

一.Multi-Agent 的必然性

1. 单个 Agent 的哲学是上下文工程的哲学，而在复杂的任务中，只有引入 Multi-Agent，才能继续保证单个 Agent 的上下文的洁净：
   我们在单一 Agent 的上下文章节提到过：

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

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

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

2. Agent 不是真实的人，我们只需要无限复制上下文就能无限创造相同的 Agent：

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

二.从单一 Agent 的概念演化映射为 Multi-Agent 中的概念

1. 从 ReAct 到结对 Agent

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

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