MultiAgent

MultiAgent & PromptChain

什么叫 PromptChain？这是 Agentic Workflow 中的概念，LLM 在 Workflow 中不再负责整体规划，而只负责节点的实现，针对每个节点预先输入 Prompt，LLM 跟随 Workflow 进程就能依次执行。

二者对比：

对比项	多阶段 Prompt Chain	多 Agent
执行单元	一条 Workflow 中的处理节点	可以独立完成子目标的 Agent
工作方式	节点按照既定逻辑处理输入并产生输出	Agent 可以选工具、观察结果并迭代执行
控制方式	Workflow 负责节点跳转和状态流转	可以用固定编排，也可以由模型动态委派
上下文	上下文通常沿处理链路传递	可以按 Agent 隔离上下文、工具、权限和状态
运行状态	主要关注整条链路执行到了哪个节点	还要区分各 Agent 的任务、状态、尝试次数和交付结果
结果交付	节点输出通常作为后续节点的输入	可以传消息、共享状态，也可以交付结构化结果
失败处理	重试失败节点或从 Workflow 检查点恢复	还要决定哪个角色可以降级、跳过或重新执行

两者亦可同时出现，外层使用固定 Workflow，节点内部再运行各自的 Agent。

一个 MultiAgent 系统需要考虑哪些问题？

需要确定的问题	具体要考虑什么	一个常见例子
每个 Agent 负责什么？	子目标、Prompt、工具、上下文和权限是否需要隔离	技术调研可以拆成资料检索、数据分析和结论复核
谁决定下一步做什么？	流程由代码控制，还是由模型动态选择角色和任务	固定审核流程交给代码，不确定的检索方向交给模型
多个 Agent 怎么配合？	顺序、并行、路由、交接、循环，还是几种方式组合	多路资料检索并行执行，Reviewer 在资料齐全后统一复核
Agent 之间交付什么？	传完整对话、共享状态，还是只传结构化结果和必要证据	检索 Agent 交付结论、引用和 Artifact URI，而非完整对话
怎么记录状态和处理失败？	是否单独记录角色状态，超时后重试、跳过、降级还是终止	某一路检索超时后保留其他结果，并明确标记缺失项
Agent 部署在哪里？	同一进程内运行，还是通过网络跨服务、跨团队或跨安全域	本地角色可以直接调用，远程角色需要身份、协议和任务状态

MultiAgent 的编排方式

模式	控制方式	适用场景	主要代价
Sequential	代码按固定顺序调用多个 Agent	步骤确定，前后依赖清楚	时延累加，灵活性有限
Parallel	代码把独立任务并行分发后归并	多维评审、独立检索、投票	状态归并和部分失败处理
Router	规则或模型把请求路由给一个或多个专家	业务域清楚、分类相对稳定	路由错误会直接选错专家
Supervisor/Manager	主 Agent 动态调用子 Agent，并保留最终控制权	子任务无法提前完全确定，需要统一答案	主 Agent 成为瓶颈，协调成本高
Handoff	当前 Agent 把控制权和必要上下文交给另一个 Agent	客服分流、分阶段对话、专家直接服务用户	会话历史和权限边界更难维护
Evaluator-Optimizer	生成者和评审者循环迭代	有明确评分标准，迭代确实能改善结果	容易无限打磨，需要停止条件
Group Chat	Agent 共享会话，按轮转或 Selector 依次发言	讨论、评审、需要相互修正的任务	上下文容易膨胀，停止条件难定
Debate	多个 Agent 多轮提出、质疑并修正观点	结论可由证据检验，分歧本身有价值	容易重复争论，不保证更正确
Event-driven/Peer	Agent 根据消息和本地规则决定后续动作	跨服务、跨团队的开放协作	一致性、安全和调试最复杂

编排方式之间可以交叉。

Agent 角色委派：动态 VS 静态

静态 DAG 图，角色、依赖和执行路径在运行前已经确定，每个 Agent 之间的依赖关系可以用有向无环图表示，这就是固定的静态委派。静态委派的好处是流程固定，遇到超时、错误等失败情况好控制。

动态委派，指的是在 Router、Supervisor/Manager、Handoff 等体系中，根据任务进行的不同状况，需要 LLM 来动态地委派角色，包括委派数量、子任务如何拆解、什么时候结束子任务等。

当然，二者同样可以交叉，例如，外层固定收集资料、分析和审核三个阶段，资料收集阶段再由主 Agent 根据问题创建 Subagent。审核和发布门槛仍由固定流程控制，调研方向可以在运行时扩展。总的来说，宏观层面采用 DAG，微观层面采用动态委派。

⭐子任务⭐

保证子任务顺利完成

Agent 要执行子任务，首先要输入 Prompt，从 Prompt 上可以进行入手，必须给定所有规范，例如子任务目标和成功标准，标明依赖的上游任务、可用工具与权限，并约定输出 Schema 和产物位置等

判断子任务能否并行

业务上不存在明显交叉或依赖关系的 Agent Task 可以初步判断为可并行。比如调研任务的“查官方文档”和“查论文与基准测试”可以并行。

同时需要注意，并行 Subagent 的输出不要直接写入那些会被系统当成“唯一真实状态（source of truth）”的共享字段。比方说在 Note.md 里面有一个字段 Truth，此时有多个并行 Subagent 的任务中涉及到改写 Note.md 里的 Truth 字段，那么就会出现最后只有一个 subagent 成功改写了 Truth，其余 subagent 的输出丢失了。所以，绝对不要允许多 Agent 改写或输出同一个权威字段。

防止子任务任务重复

任务范围要做隔离，比如隔离可调用的工具、隔离可读写的工作区、隔离彼此的核心任务等。

这些都可在后台做校验

防止子任务输出缺失

注意，这里是输出缺失而不是丢失，缺失指的是 Agent 主动不输出结果，而非输出了但因为某些原因丢失了（网络原因、OOM 等）。

这个问题和结构化输出类似，都是如何强制 LLM 输出我们想要的内容，我们可以在 Prompt 上入手，给出输出 Schema，让 LLM 照着输出，然后在后端用字段校验，没有输出视为失败，返回 LLM 重新输出。

因为不像结构化输出，有的 LLM 提供了原生结构化输出，所以暂时只有提示词强制 Schema + 后端校验重试。

Agent 通信

Agent 之间的通信方式，用的不是 Agent 和 LLM 厂商之间的 Message。如果是进程内的多 Agent，通过参数、返回值和共享状态就可以通信；而如果是跨进程甚至跨服务的 Agent，就需要外部手段。