如何设计平台的 Multi-Agent 架构？

先这样答

我会按职能拆分 Agent，并根据任务需要选择协作方式。Planner 负责理解任务并拆分步骤，Executor 负责执行，Reviewer 负责验证结果和把控质量，Router 负责分发任务和调度。这样每个角色都有明确职责，协作时也能看清任务由谁处理、结果由谁检查。

通信可以选三种方式。共享黑板让多个 Agent 读写同一份共享状态，适合需要围绕共同信息协作的场景。消息传递让 Agent 点对点交换信息，协作关系更直接。编排器则由中心化流程协调各个 Agent，便于统一控制任务顺序。选哪种方式，要看任务如何拆分，以及 Agent 之间需要怎样交换状态和结果。

落到工程实现，我会先明确状态放在哪里，再设计同步机制，避免各个角色对任务进度和结果的理解不一致。架构复杂度也要看使用范围。如果平台面向复杂协作，可以保留清晰的角色边界和调度方式。如果只是内部使用，就先看是否真的需要多 Agent、中心化编排或共享状态。能用更简单的方式完成任务，就不必为了架构完整而增加复杂度。

面试官会怎么追问

• 「这几个 Agent 的职责怎么划分，怎么避免互相做重复的事？」 Planner 负责把任务拆开，Executor 执行分到的任务，Reviewer 检查结果，Router 负责分发和调度。设计时要先明确各自的输入和输出。这样可以让执行与验证分开，也能减少职责重叠。

• 「共享黑板、消息传递和编排器，你会怎么选？」 先看 Agent 是否需要读写同一份状态。需要共享状态时，可以考虑共享黑板；点对点交换信息时，可以考虑消息传递。需要中心化控制流程时，可以使用编排器。选择时还要把状态存储位置和同步机制一起考虑。

• 「如果这是一个内部工具，还需要拆这么多 Agent 吗？」 不一定需要。先看任务能否由更简单的流程完成，再判断多角色协作是否有实际需要。如果增加角色和调度没有带来必要的协作能力，就应简化架构。复杂度要和使用场景匹配。

回答的坑

• 只报出四个角色的名字，却不讲各自的职责和协作方式，答案就停在概念层面。
• 只讲通信方案，不交代状态存在哪里、如何同步，也不判断内部场景是否需要复杂架构。