编排拓扑模式

共 17 题
📑 题目列表 17 题
#
★★★

1. Supervisor(管理者)模式下主 Agent 如何做子 Agent 的任务分解与结果聚合

请阐述在多智能体 Supervisor(管理者)编排模式下,主 Agent 是如何对任务进行分解、将子任务委派给子 Agent,并对子 Agent 返回的结果进行校验与聚合的?

  • Supervisor 的角色定位与循环控制(LLM 驱动循环 vs 确定性循环)
  • 任务分解的方法(任务树/DAG、上下文裁剪)与子任务描述质量
  • 结果聚合的策略(投票、加权、仲裁、置信度校验)与失败处理

Supervisor 模式由一个主 Agent 作为总控,负责把用户目标拆解为可执行子任务,选择并委派给合适的子 Agent,再收集、校验并聚合结果。任务分解上,Supervisor 通常维护一个任务队列或 DAG,把大目标递归拆成原子子任务,每个子任务附带明确的输入、目标与验收标准,避免子 Agent 目标漂移。委派时根据子 Agent 的能力描述(capability manifest)做路由,并尽量数据亲和(就近传数据)。聚合时不能简单拼接,而要对子 Agent 输出做结构化校验(schema、格式)、语义一致性检查,必要时用置信度、投票或仲裁者裁决冲突;对失败或超时的子任务启动重试、降级或上报。工程上常用 LangGraph 构建 Supervisor 循环:supervisor 节点决定 next 指针,路由到各 worker,worker 返回后回到 supervisor 直到满足终止条件。

Supervisor 模式的核心价值是把"编排决策"集中到一处,便于权限控制、可观测与审计;代价是主 Agent 成为单点与瓶颈。因此工程上要为主 Agent 设置步数上限、超时与预算,并让子 Agent 结果尽量结构化以便确定性校验,降低对 LLM 判断的依赖。

# LangGraph 风格:Supervisor 循环路由
from typing import TypedDict
from langgraph.graph import StateGraph, END

class State(TypedDict):
    messages: list
    next: str

def supervisor(state):
    # LLM 决定下一个执行者;全部完成则返回 END
    return {"next": decide_next(state["messages"])}

def worker_a(state):
    return {"messages": run_agent("A", state)}

def worker_b(state):
    return {"messages": run_agent("B", state)}

g = StateGraph(State)
g.add_node("supervisor", supervisor)
g.add_node("worker_a", worker_a)
g.add_node("worker_b", worker_b)
g.add_conditional_edges("supervisor", lambda s: s["next"],
                        {"worker_a": "worker_a", "worker_b": "worker_b"})
g.add_edge("worker_a", "supervisor")
g.add_edge("worker_b", "supervisor")
#
★★★

2. Network(点对点)模式下多个 Agent 如何自主发现彼此能力并协商

在 Network(点对点)多智能体模式下,Agent 之间如何自主发现彼此的能力并协商协作,工程上如何实现能力发现与任务协商?

  • 能力发现机制(目录/注册表、广播、描述文件、能力协商)
  • 协商协议(任务描述、报价、确认、拒绝)与消息格式
  • 与中心化调度的差异(无单点、涌现编排、失败范围)

点对点模式没有统一总控,Agent 通过能力发现与协商自主匹配协作。能力发现常见做法包括:注册中心/目录服务(每个 Agent 发布 capability manifest,含能力、输入输出 schema、可用状态与 SLA)、广播式发现(一发多收、按能力匹配回复)、或基于共享黑板/公共知识库的间接发现。协商通常采用类合同(contract)协议:请求方发出带任务描述、约束与预算的请求,候选 Agent 评估后返回报价或接受,请求方择一并确认,形成约束关系。工程上要定义结构化消息(任务、状态、结果、元数据)与版本号,并实现超时、拒绝与降级兜底,防止协商僵局。

点对点模式的优势是去中心化、无单点、可横向扩展,适合动态、异构、规模较大的场景;弱点是全局可控性低、难以统一审计与仲裁,容易产生"协商风暴"或死锁。因此生产环境常在底层用消息总线/注册表实现,而在上层仍保留一定治理能力(如能力白名单、SLA 合约)。

#
★★★

3. Hierarchical(分层)编排与扁平 Network 在处理长任务时可靠性差异

在处理长任务时,Hierarchical(分层)编排与扁平 Network 编排在可靠性上存在哪些差异?

  • 分层编排的控制边界与错误传播隔离
  • 扁平网络的状态一致性与故障定位难度
  • 长任务下的状态持久化、恢复与重跑成本

分层编排把任务分成若干层,上层负责分解与调度,下层负责执行,错误被限制在局部子树上,便于隔离、重试与恢复,表现更像"可治理的树"。扁平 Network 中每个 Agent 参与到点对点协商,长任务跨度大、依赖链长,一旦某环节失败,故障难以定位,状态一致性更难保证,且缺乏集中恢复点,重启与回放成本高。因此长任务可靠性上,分层明显占优:可以在每层设置 checkpoint、超时、重试与降级,并且能通过上层逐级重放。扁平网络更适合短小、独立、并行密集的任务。

长任务的可靠性核心是"可恢复、可定位、可回放"。分层天然提供故障域与恢复锚点;扁平网络则把复杂度推到消息层,需要额外实现全局状态、分布式事务与因果追踪,工程代价大。工程实践中常以分层为主干、局部用扁平并行,兼顾治理与效率。

#
★★★

4. Swarm / 去中心化蜂群模式适合哪些任务,失败传播如何控制

Swarm(去中心化蜂群)模式适合处理哪些类型的任务?其失败传播如何控制?

  • Swarm 的适用任务特征(大量相似、独立、可并行、容错)
  • 去中心化协调原则(局部规则、涌现行为、自组织)
  • 失败传播控制(冗余、取代、局部隔离、无单点依赖)

Swarm 模式适合由大量相似、彼此独立、可并行、且允许部分个体失败的任务,例如批量数据标注、内容改写、异常扫描、舆情采集、多路搜索等。其自组织依赖局部规则(就近选人、择优、差异化),不依赖全局总控。失败传播控制:一是任务冗余与冗余投票,允许部分个体失败或给出坏结果,靠多数一致或质量投票收敛;二是任务块独立、失败不影响整体,支持局部重试与重新调度;三是无单点依赖,个体可随时替换;四是加抑制机制(如失败计数、冷却期)防止坏个体反复拉低全局质量。

Swarm 的哲学是"用冗余换可靠",适用于对单点精确性要求不高、但对吞吐与鲁棒性要求高的场景。它不适合强依赖、强顺序、需要精确决策的任务,因为缺乏全局仲裁。工程上要配合质量闸门(LLM-as-Judge 或人工抽检)来拦截劣质个体输出。

#
★★★

5. Supervisor、Pipeline、Parallel 三种多 Agent 拓扑各适合什么任务,如何选型?

Supervisor、Pipeline、Parallel 三种多 Agent 拓扑各自适合什么任务?应如何选型?

  • 三种拓扑的结构与流程特征
  • 各自适用场景(依赖、并行、动态决策)
  • 选型决策依据(任务依赖、可并行性、动态性、治理需求)

Pipeline(流水线)是固定顺序的线性链路,前一个 Agent 的输出是后一个的输入,适合有明确阶段依赖的任务,如"解析→分类→生成",结构简单、可预测、易调试,但一个环节失败则整链中断。Parallel(并行/扇出)把任务拆成多个独立子任务同时执行再合并,适合无相互依赖、可并行加速的任务,如多地检索、多角分析,吞吐高但需要合并逻辑。Supervisor(总控)由主 Agent 动态决定下一步做哪个子任务、是否重试,适合依赖关系动态、需要按中间结果实时决策的任务,如复杂推理、多步操作。选型上:依赖固定→Pipeline;可并行且独立→Parallel;依赖动态、需要裁决→Supervisor;复杂任务可组合(Supervisor 内嵌 Parallel 或 Pipeline 子图)。

选型本质是在"控制力、吞吐、可预测性"之间权衡。Pipeline 确定性最强、成本最低;Parallel 吞吐最高但不能处理依赖;Supervisor 最灵活但成本高、有单点。生产上常按"外层 Supervisor 决策 + 内层 Pipeline/Parallel 执行"的混合拓扑落地。

#
★★

6. Debate(辩论)模式下多个 Agent 互审如何提升答案正确率与幻觉抑制

在多智能体 Debate(辩论)模式下,多个 Agent 相互审查如何提升答案正确率并抑制幻觉?

  • 辩论机制(多 Agent 提立场、互评、反驳、收敛)
  • 幻觉抑制原理(交叉验证、证据要求、分歧暴露)
  • 成本与收敛控制(轮数、先验、投票)

Debate 模式让多个 Agent 针对同一问题分别提出答案与理由,然后相互审视、质疑、反驳,经过多轮迭代后收敛到共识或由仲裁者裁决。其提升正确率的机制是:不同 Agent 的初始化与视角不同,错误往往是独立的,通过交叉验证可暴露彼此的事实与逻辑漏洞;要求"提出证据/引用"能迫使 Agent 偏离单纯的语言惯性,抑制无依据的幻觉。工程上可让 Agent 先独立作答再互评,或引入"提问者/答辩者"角色。要注意控制轮数与 token 成本,避免循环论证与无谓争吵,可用置信度、外部证据或仲裁者做最终裁决。

Debate 有效的关键前提是各 Agent 错误独立、且能基于事实互验。若所有 Agent 共享同一知识缺口或同源模型,辩论可能只是"自说自话",因此常配合检索增强、外部证据来做事实锚点。代价是成本成倍增长,需用轮数上限与收敛判据裁剪。

#
★★

7. 如何根据任务复杂度选择编排拓扑并做降级(复杂→单一 Agent)

如何根据任务复杂度选择合适的编排拓扑,并在复杂场景下做好降级(复杂→单一 Agent)?

  • 复杂度评估维度(依赖、步骤、上下文、不确定性)
  • 拓扑与复杂度匹配
  • 降级策略与触发条件(失败、超时、成本超限)

任务复杂度可从依赖结构、步骤数、上下文规模、不确定性四维评估。简单任务(单步、无依赖、低不确定性)直接用单一 Agent 或 Pipeline;中等任务(可并行、有阶段)用 Parallel 或 Pipeline;复杂任务(动态依赖、多步推理、需裁决)用 Supervisor 或分层。降级策略:为拓扑设置失败/超时/成本预算阈值,检测到子 Agent 反复失败、协商僵局、成本超限或质量下降时,自动降级为简单拓扑——例如多 Agent 失败后回退为单一强 Agent 直答,或把层级扁平化。降级要可观测、可回放,并记录触发原因供后续优化。

多 Agent 不是越多越好,编排成本随 Agent 数量上升。降级本质是"用更简单、更可控的方式兜底",避免复杂拓扑在压力下崩溃。良好的设计是"复杂优先、简单兜底",并让降级路径有清晰入口与退出条件。

#
★★

8. Handoff(交接)模式在 LangGraph 中如何实现状态在 Agent 间传递

在 LangGraph 中,Handoff(交接)模式是如何实现状态在 Agent 之间传递的?

  • LangGraph 的状态图与 reducer 语义
  • Handoff 的机制(send、命令、next 指针)
  • 交接状态(如何携带上下文、如何避免冗余)

LangGraph 中每个 Agent 是图中的一个节点,共享一个 State 对象;节点通过返回的字典更新 State 的字段,字段用 reducer(如 add_messages、自定义合并)控制是覆盖还是追加。Handoff 通过节点返回值中的 next 字段(或 send 命令)决定控制权移到哪个 Agent,同时把需要传递的上下文写入 State 的共享字段。例如用 messages 字段累积对话,各 Agent 读取自己需要的子集;或用专门的 ctx 字段传递领域上下文。这样实现"控制权交接 + 状态传递"分离,避免把整个历史塞给每个 Agent。

LangGraph 的 Handoff 关键是"共享 State + 条件路由",这是它比手写循环更可靠的地方,因为状态显式、可检查点、可回放。交接时要注意上下文裁剪:只把当前 Agent 需要的字段传过去,减少 token 与信息泄漏。

from typing import TypedDict, Annotated
from langgraph.graph import StateGraph, END
from langgraph.graph.message import add_messages

class State(TypedDict):
    messages: Annotated[list, add_messages]
    ctx: dict           # 交接上下文

def agent_a(state):
    return {"ctx": {"order_id": extract(state)}, "next": "agent_b"}

def agent_b(state):
    order_id = state["ctx"]["order_id"]   # 读取交接上下文
    return {"messages": f"处理订单 {order_id}", "next": END}

g = StateGraph(State)
g.add_node("agent_a", agent_a)
g.add_node("agent_b", agent_b)
g.add_conditional_edges("agent_a", lambda s: s["next"], {"agent_b": "agent_b"})
g.add_conditional_edges("agent_b", lambda s: s["next"], {END: END})
#
★★

9. 多 Agent 的消息传递与共享状态如何设计,如何避免状态不一致?

多 Agent 间的消息传递与共享状态应如何设计?如何避免状态不一致?

  • 消息传递 vs 共享状态两种模式
  • 状态一致性策略(单一事实源、版本号、乐观锁、事件溯源)
  • 冲突处理与只读副本

设计上先明确"单一事实源"(Single Source of Truth):把关键状态集中在一处(如中央 State、数据库、事件日志),Agent 通过消息触发变更,而非各自维护一份副本。消息传递采用结构化协议(任务、状态、结果、traceId),接收方幂等处理。共享状态用版本号/乐观锁避免并发写覆盖,冲突通过合并策略(最后写、字段级合并、冲突仲裁)解决。对只读数据可用副本+缓存,但写路径必须收敛到单一事实源。跨进程场景可用事件溯源(Event Sourcing)把所有变更落为事件,重建任意状态,天然保证一致与可回放。

状态不一致的根源是"多个 Agent 各自持有可变副本并并发修改"。规避的办法是"读写分离、写收敛、读可缓存":所有写操作经过统一入口,配版本号与幂等,读操作可容忍短暂不一致(最终一致)。工程上把状态与逻辑解耦,消息只作为变更的载体。

#
★★

10. Agent 间的任务委派与结果校验如何形成闭环?

Agent 间的任务委派与结果校验应如何设计,才能形成闭环?

  • 委派协议(任务描述、验收标准 AC、超时、重试)
  • 结果校验层(确定性校验 + LLM 校验 + 人工兜底)
  • 闭环反馈(不合格→返工/重派/升级,合格→聚合)

闭环设计包括:委派时给出明确任务描述、输入、验收标准(AC)与约束;执行 Agent 返回结构化结果;接收方先做确定性校验(schema、格式、工具结果、规则),再按需做语义/事实校验(必要时 LLM-as-Judge 或人工抽检);不合格则标记返工原因并重派(可换 Agent 或换策略),合格则进入聚合或下一环节。全程记录 traceId 与版本,支持回放与审计。这样"委派→执行→校验→(返工/通过)"形成闭环,避免"只委派不管结果"。

闭环的关键是"校验独立于执行"与"可返工"。校验器要与执行器解耦,避免同源偏置;返工要有上限(次数、预算),超限升级给人。把验收标准前置到委派阶段,能显著降低返工率。

#
★★

11. Agent 编排的拓扑,链式、星型、树型与网格?

请对比 Agent 编排中链式、星型、树型与网格四种拓扑的结构与适用场景?

  • 四种拓扑的结构特征
  • 各自优缺点与适用场景
  • 拓扑选择依据

链式(Pipeline):线性串联,前输出为后输入,简单可预测,适合固定阶段任务,但单点故障断链、无并行。星型(Hub-and-Spoke):中心协调者分发与聚合,类似 Supervisor,管理集中、便于治理,但中心是瓶颈与单点。树型(Hierarchical):分层向下分解,错误隔离好、可扩展,适合复杂长任务,但上层存在单点且可能有冗余。网格(Mesh):点对点全互联,灵活去中心化、鲁棒,适合动态协作,但协商成本高、难审计。实际系统常为混合拓扑,如星型或树型为骨架、局部用网格或链式。

四种拓扑是"控制集中度 × 连接复杂度"的组合。选择时权衡治理能力、吞吐、容错与成本:需要强治理用星型/树型,需要高并发与去中心化用网格,需要简单线性用链式。

#
★★

12. 编排拓扑的容错设计,Supervisor 单点故障、子 Agent 失败隔离与拓扑降级(复杂拓扑→单一 Agent)?

多 Agent 编排的容错设计应如何考虑 Supervisor 单点故障、子 Agent 失败隔离与拓扑降级(复杂拓扑→单一 Agent)?

  • Supervisor 高可用(多副本、状态持久化、故障转移)
  • 子 Agent 失败隔离(超时、重试、故障域、熔断)
  • 拓扑降级策略与触发条件

容错设计分三层:其一,Supervisor 单点故障——通过状态持久化 + 多副本 + 故障转移解决,把 Supervisor 的决策状态(任务队列、当前进度)写入可恢复存储,副本具备相同状态,故障时无缝切换;同时可把监督逻辑与 LLM 决策解耦,用确定性状态机兜底。其二,子 Agent 失败隔离——为每个子 Agent 设超时、重试上限、熔断与故障域,失败只影响局部,不级联到全局;用断路器在连续失败时快速跳过。其三,拓扑降级——检测到复杂拓扑反复失败、预算超限或质量下降时,自动降级为更简单拓扑,最极端是回退为单一强 Agent 直答,保证可用性优先。

容错本质是"冗余 + 隔离 + 降级"的组合。Supervisor 要可恢复,子 Agent 要可隔离,整体要有降级路径。把"最好"的复杂拓扑与"最稳"的简单兜底并存,是生产级系统的通用做法。

#

13. 多 Agent 的成本与延迟控制,何时单 Agent 更好?

多 Agent 系统的成本与延迟应如何控制?什么情况下单 Agent 反而更好?

  • 多 Agent 的 token 与延迟开销来源
  • 单 Agent 的适用场景
  • 成本/延迟的量化评估与决策

多 Agent 的成本与延迟随 Agent 数量、上下文重复传输、协商轮数与反思轮数上涨。单 Agent 更好的场景:任务简单、单步可完成;上下文小、无需分工;对延迟敏感、需要快速响应;任务质量对多 Agent 无增益(如已确定的模式)。工程上应建立"基线单 Agent 结果"作为对照,只有当多 Agent 带来可测量的质量/召回提升且成本在预算内,才启用多 Agent。可用 token 记账、延迟 P99 监控与成本预算闸门做决策。

"多 Agent 更好"是个假设而非规则。成本/延迟的量化对比(单 Agent vs 多 Agent 在相同评测集上的质量/成本/延迟)是决策依据。多数生产任务应默认单 Agent,仅在确需分工、裁决、并行时升级。

#

14. 编排状态管理,全局状态、局部状态与错误恢复的快照与回放机制如何设计

在 Agent 编排中,全局状态、局部状态与错误恢复的快照与回放机制应如何设计?

  • 全局状态(共享上下文)与局部状态(Agent 私有)的划分
  • 快照(checkpoint)的时机与内容
  • 回放(重放)机制与错误恢复

设计上把状态分为全局状态(跨 Agent 共享,如任务元数据、结果集、决策历史)与局部状态(单个 Agent 内部,如局部思考、临时变量)。全局状态存入中央存储并纳入快照;局部状态按需序列化。错误恢复采用"快照 + 回放":在关键节点(每步 Agent 完成后、supervisor 决策后)写 checkpoint,保存状态 version 与对应的输入;失败时回滚到最近一致快照,用保存的输入重放该节点,保证幂等与可恢复。快照频率要权衡(过高增加 IO 成本,过低丢失较多进度)。工程上 LangGraph 的 checkpointer 即实现此机制,支持进程重启后的恢复。

快照与回放的核心是"确定性":同一状态 + 同一输入应产生同一结果,才能可靠回放。因此要把随机性(温度、非确定性调用)记录在快照中,或对重放节点限定确定性。状态划分清晰,回放范围才可控。

#

15. 编排与并行,任务分解的粒度与依赖建模(串行/并行/条件)如何决定,结果合并的时序如何保证

在编排与并行中,任务分解的粒度与依赖建模(串行/并行/条件)应如何决定?结果合并的时序如何保证?

  • 任务分解粒度(粗细的权衡)
  • 依赖建模(DAG:串行/并行/条件边)
  • 结果合并的时序控制(join、fan-in、barrier)

任务分解粒度取决于任务规模、依赖关系与成本:粒度过细导致协调与上下文重复开销,过粗导致单点过载与并行度不足。依赖建模用 DAG 表达:串行边表示顺序依赖,并行边表示可并发,条件边表示按结果分支。结果的合并时序用 fan-in/join 机制保证:只有当某节点的所有前置依赖完成(all-done)才能合并,用"计数器/依赖计数"或图引擎的拓扑调度实现;条件分支则按运行时结果决定走哪条路径,join 只等实际执行的路径。时序保证依赖"先完成依赖再执行"的调度约束,而非依赖 LLM 自觉。

并行正确性取决于"依赖约束"而非"运气"。用 DAG + 依赖计数可确定性保证 join 时序,避免部分结果未到就合并。粒度与依赖建模要提前设计,运行时再动态调整成本高。

#

16. 编排的执行引擎,状态机、工作流引擎与事件总线的适用边界如何划分

多 Agent 编排的执行引擎中,状态机、工作流引擎与事件总线各自的适用边界如何划分?

  • 三种执行模型的机制
  • 各自适用场景与边界
  • 组合使用的场景

状态机(FSM)适合状态有限、可枚举、转移明确的流程,如 Agent 生命周期(idle→running→waiting→done/failed),确定性强、易校验,但状态多时难以维护。工作流引擎(如 LangGraph、Temporal、Airflow)适合复杂、长时、有依赖与并行/条件分支的流程,提供 DAG、重试、定时、人工介入,可观测性好,适合编排多 Agent 的长期任务。事件总线(Kafka、RabbitMQ)适合异步、解耦、高吞吐、事件驱动:Agent 发布事件、订阅者响应,适合松耦合与大规模并行,但缺乏集中流程控制、难追踪单一事务。划界:需要确定性状态管理用 FSM;需要复杂流程编排与恢复用工作流引擎;需要解耦与高吞吐异步通信用事件总线。实际常组合:工作流引擎编排主流程,事件总线做跨 Agent 异步解耦,FSM 管理单个 Agent 内部状态。

三种引擎是"控制力"与"吞吐/解耦"的两个极端:工作流引擎控制强但集中,事件总线吞吐高但弱控制。多 Agent 系统通常以工作流引擎为主干(保流程与恢复),事件总线支撑异步侧袋,FSM 管好单个 Agent 状态。

#

17. 编排的并行控制,fan-out/fan-in 的并发上限、超时聚合与部分结果处理?

编排中的并行控制应如何设计 fan-out/fan-in 的并发上限、超时聚合与部分结果处理?

  • fan-out 并发上限(并发度、令牌桶、限流)
  • fan-in 超时聚合(等待策略、超时阈值)
  • 部分结果处理(迟到结果、失败结果、部分成功聚合)

fan-out 时用并发上限(信号量/令牌)控制同时执行的子任务数,结合下游容量与限流,防止背压与过载。fan-in 聚合时设置"完成阈值":等待一定数量的结果(如全部、或 N/M 多数)而非无限等待,配超时阈值与接线策略。超时后的部分结果处理:对迟到结果标记过期或丢弃,对失败结果按策略重试或降级,对已到结果按"多数一致/加权/最高置信度"聚合并标记不确定性。要保证聚合的幂等性,避免重复处理。

并行控制的核心是"限定下界的最小等待 + 超时上界 + 部分结果的可解释聚合"。完全等待所有结果会拖慢整体并放大失败;只等少数又会降低质量。用"完成阈值 + 超时 + 部分结果标记"取得平衡,同时控制并发量保护下游。