多 Agent 系统如何设计编排流程，并控制每个 Agent 的任务边界？｜高频面试题解析

60 秒回答模板

多 Agent 系统设计时，我会先明确为什么需要多个 Agent：通常是任务复杂、角色能力不同、需要并行处理或需要独立审核。架构上可以有一个 coordinator 负责接收目标、拆解任务、选择 Agent、维护全局状态和合并结果；planner 负责计划，executor 负责执行工具或子任务，reviewer 或 critic 负责校验结果。每个 Agent 都要有清晰边界，包括输入输出 schema、可调用工具、权限范围、状态读写范围、超时和失败策略。编排流程可以是固定 DAG、状态机、黑板模式或计划执行循环，但关键路径要可追踪、可回滚、可人工接管。上线前还要处理冲突、重复执行、循环调用、上下文污染、成本失控和观察性问题。

考点 多 Agent 拆分要有真实动机

难度 真实面经题

回答目标 划清多 Agent 编排边界

深入解析

先定义多 Agent 的必要性

不是每个复杂任务都要拆成多 Agent。只有当任务需要不同专业角色、并行执行、相互校验或工具权限隔离时，多 Agent 才有价值。面试里要先说明拆分动机，否则容易变成把一个 Agent 人为拆成多个名字。

编排器维护全局流程

多 Agent 一般需要 coordinator 或 orchestrator 维护用户目标、任务分解、执行顺序、共享状态、超时控制和最终合并。它不一定生成全部内容，但要负责谁来做、做完怎么交接、失败怎么处理，以及什么时候停止。

每个 Agent 要有边界契约

Agent 边界要写成契约：输入是什么、输出 schema 是什么、能访问哪些工具和数据、能修改哪些状态、不能做什么、失败如何返回。比如检索 Agent 只返回证据，执行 Agent 只调用授权工具，审核 Agent 只判断是否满足标准。

流程可以用图或状态机表达

编排方式可以是固定 DAG、状态机、planner-executor 循环、黑板共享模式或事件驱动模式。生产系统里常把关键路径固化成流程图，把不确定性限制在某些节点，避免多个 Agent 自由对话导致循环、冲突和不可复现。

冲突和失败要显式处理

多 Agent 会出现结论冲突、工具重复调用、部分任务失败、上下文污染和成本超限。需要设计仲裁规则、去重机制、重试上限、人工接管、降级路径和结果置信度。不能让 Agent 之间无限互相说服。

可观测性决定能否上线

每个子任务的输入、输出、工具调用、状态变更、耗时、成本和错误都要记录。否则一旦结果错误，很难判断是任务拆解错、某个 Agent 输出错、工具调用错还是合并错。可观测性也是后续评估和调优的基础。

易错点

只介绍什么是 Agent，没有回答编排流程和任务边界。
把多个 Agent 设计成自由聊天，缺少 coordinator 和停止条件。
没有定义输入输出 schema、权限和状态读写范围。
忽略冲突仲裁、重复工具调用和循环调用问题。
所有上下文共享给所有 Agent，造成权限和上下文污染风险。
缺少日志和追踪，线上出错无法定位责任节点。

面试官追问

多 Agent 和单 Agent 加多个工具的区别是什么？

多 Agent 是把任务拆成多个有边界的角色和状态流转；单 Agent 多工具是一个模型在同一上下文里选择工具。前者更适合权限隔离、并行和审核，后者简单、成本低、可控性更强。

如果两个 Agent 给出相反结论，你会如何仲裁？

先看证据来源、角色优先级、置信度和业务规则。可以让 reviewer 仲裁、回到用户确认、追加检索或执行小实验验证；不能让两个 Agent 无限争论。

如何避免多 Agent 系统陷入循环调用？

设置最大轮次、任务状态机、重复任务检测、成本预算和停止条件。每次计划更新都要和目标差异比较，连续无进展就降级、人工接管或返回不确定结果。

共享上下文和独立上下文分别有什么风险？

共享上下文有利于协同，但容易泄露权限、污染记忆和放大错误；独立上下文更安全可控，但需要明确交接摘要和证据引用，否则信息断裂。

多 Agent 编排中哪些状态必须持久化？

用户目标、任务分解、每个子任务状态、工具调用结果、关键证据、权限决策、失败原因和最终合并结果都应持久化，方便恢复、审计和复盘。

如何评估某个 Agent 是否应该被拆出来？

当某个职责需要独立权限、独立工具、独立评估标准或并行执行时可以拆；如果只是同一模型换个角色名，拆出来只会增加成本和不确定性。