从单一 Agent 到 Multi-Agent

Multi-Agent 的必然性

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

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

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

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

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

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

从 ReAct 到结对 Agent

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

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

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

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