智能体架构模式 — Arsanjani & Bustos

概述

本页综合整理了《面向多智能体系统构建的智能体架构模式》（Agentic Architectural Patterns for Building Multi-Agent Systems，Arsanjani & Bustos，Packt，2026，ISBN 978-1-80602-957-0）一书中的设计模式目录。全书将模式语言分为五大组：多智能体协作、可解释性与合规、鲁棒性与容错、人机交互，以及智能体级别模式。每个模式均遵循"场景–问题–解决方案"结构，提供实现指导，并映射到 GenAI 成熟度等级（参见 Arsanjani GenAI 成熟度模型）。

书中代码示例使用 Python 与 Google Gemini/ADK，但作者指出这些模式与 LLM 无关，可通用于任意模型。

第一部分：多智能体协作模式

智能体路由器（基于意图的路由）

场景： 系统中存在多个专用智能体，用户以自然语言提交请求，系统需将其分派给正确的专家智能体。

问题： 随着智能体数量增长，硬编码条件路由会逐渐失效；关键字匹配脆弱，无法安全区分各智能体的能力边界。

解决方案： 采用两步路由：（1）配备严格 Schema 的 LLM 执行语义意图提取，将原始查询转换为结构化的 RoutingIntent 对象，其中包含动词（动作）和名词（资源）；（2）能力图将 (动作, 资源) 元组映射到智能体名称。若无匹配项，请求将被拒绝，而非错误转发。

后果： - 优势：解耦、可扩展（新智能体只需在图中注册，无需改动路由逻辑）、安全（能力图充当白名单）。 - 劣势：LLM 提取增加延迟；Schema 过于细粒度会导致图结构脆弱。

实现指导： 将规范动作/资源对控制在 10–20 个以内。使用函数调用模式进行结构化意图提取（而非自由文本提示词）。对重复查询增加语义缓存层，绕过 LLM 提取。

任务委派框架

主管架构（集中式编排）

场景： 一项复杂任务需要多个顺序或条件步骤，每步由专用智能体处理。

问题： 系统如何在不频繁人工干预的情况下，可靠地控制流程、追踪状态并防止任务丢失？

解决方案： 中央编排智能体接收顶级目标，制定计划（静态或 LLM 生成），并通过结构化消息将子任务委派给工作者智能体，收集结果并驱动条件分支。

特性	说明
控制流	层级化；编排者向工作者委派任务
主要优势	可预测、审计链清晰、易于治理
主要劣势	编排者是单点故障，也是潜在瓶颈
适用场景	受监管工作流（金融、医疗）、具有清晰顺序逻辑的流程

实现指导： 严格分离关注点——编排者只负责路由和状态，工作者执行领域任务。在每个交接处强制使用 JSON Schema 输出。实现检查点（如 LangGraph 持久化器），使工作流在编排者重启后仍可恢复。

蜂群架构（涌现式去中心化协作）

场景： 任务是动态的，解决路径无法预定义，或对组件故障有高韧性要求。

问题： 在无中央控制器（该控制器可能成为瓶颈或故障点）的情况下，一组自主智能体如何协作？

解决方案： 共享任务板持有带生命周期状态的任务对象。智能体轮询任务板并自主选取与自身能力匹配的任务。完成后更新任务状态，供下一个有能力的智能体继续处理。

特性	说明
控制流	点对点；智能体从共享任务板自主选取任务
主要优势	韧性高（无单点故障）、可水平扩展
主要劣势	调试困难；行为涌现，可预测性较低；治理复杂
适用场景	创意任务、内容生成流水线、动态环境

实现指导： 企业场景建议先从主管架构起步。对需要自主性的子团队引入蜂群架构。许多生产系统采用混合模式：主管负责整体业务流程，将部分模块委托给自组织团队处理。

智能体组合拓扑

黑板知识中枢

场景： 多个专用智能体需要向共享解决方案贡献局部事实，且贡献顺序无法预先确定。

问题： 在不产生紧耦合或竞争条件的情况下，智能体如何在定义不清的问题上协作？

解决方案： 中央黑板存储带类型、带版本的事实与假设。控制器仲裁贡献周期（发布 → 评估 → 整合）。智能体之间不直接通信，而是向黑板发布内容并从中读取。

后果： 优势——对非良定义问题具有灵活性，完整审计链。劣势——中央控制器可能成为吞吐瓶颈；与直接消息传递相比延迟更高。

合同网市场（中介者 + 竞标）

场景： 多个智能体具有重叠能力，任务应动态分配给最合适的智能体。

解决方案： 中介者广播任务公告，智能体提交竞标（能力评分、可用性），中介者将任务授予最佳竞标者。

带守卫能力的监督树

场景： 系统需要故障隔离——一个失败的智能体不得污染整体工作流。

解决方案： 智能体被组织成监督树。父智能体监控子智能体健康状态，并在其子树内重启或替换失败的智能体，以限制爆炸半径。

协作模式

多智能体规划

场景： 复杂目标需要任务分解、依赖追踪和并行执行。

解决方案： 规划智能体生成子任务有向无环图；调度器按依赖关系将子任务分配给智能体；综合智能体汇总结果。

知识共享

场景： 智能体需要访问随工作流推进而演进的共享领域知识。

解决方案： 共享知识库（如向量数据库 + 键值缓存）使智能体可通过语义相似度发布和检索事实。

多智能体场景中的工具路由

场景： 多个智能体共享同一工具集，系统必须防止工具冲突并将工具调用路由到合适的智能体。

解决方案： 工具注册中心负责仲裁访问，对有状态工具强制执行独占租约，并向感兴趣的智能体广播结果。

共识

场景： 多个智能体对同一数据产生相互冲突的评估（如两个风险模型意见不一致）。

解决方案： 智能体参与结构化迭代辩论，各自分享推理过程，其他方进行批判。当所有方接受共同结论或援引仲裁机制（人工或规则）时，达成收敛。

典型用例： 金融预测场景——两个分析师智能体接收相同市场数据却得出不同预测，共识机制迫使它们暴露假设并趋于一致。

智能体协商

场景： 智能体目标相互竞争，必须就资源分配或动作优先级达成一致。

解决方案： 智能体交换结构化提案与反提案（受合同网启发），协商协议定义终止条件。

资源分配

场景： 共享资源（API、计算、数据库）必须在智能体间合理分配，以避免饥饿或耗尽。

解决方案： 资源管理智能体追踪可用性并强制执行基于配额或优先级的分配；智能体显式请求、持有并释放资源。

冲突解决

场景： 智能体产生不兼容的动作或相互矛盾的世界状态更新。

解决方案（四种策略）： 1. 层级解决 — 级别较高的智能体获胜 2. 基于策略的解决 — 规则引擎裁决 3. 协商 — 智能体谈判至双方均可接受的结果 4. 博弈论解决 — 收益矩阵决定最优结果

实现指导： 始终创建可解释的解决记录（审计链）。为无法自动解决的冲突定义升级路径至人在回路（HITL）。在生产上线前用仿真测试冲突解决路径。

编队控制

场景： 一组物理或虚拟智能体（如无人机、并行处理单元）必须自组织为协调结构。

解决方案： 智能体通过局部规则（近邻通信）维护相对位置；编队控制器广播目标配置，智能体自主调整。

第二部分：可解释性与合规模式

指令保真度审计

场景： 在层级化多智能体系统中，工作者智能体可能成功完成本地子任务，却悄然违反原始高层指令中的约束——即"静默失败"。

问题： 在最终落实动作前，系统如何验证工作者的输出严格符合原始指令中的所有约束？

解决方案： 专属审计智能体同时接收原始指令与工作者输出，其唯一职责是将二者与已声明的约束进行比对，并返回结构化审计裁定（PASS/FAIL 及原因）。仅当审计通过，编排者才最终落实该动作。

后果： 优势——显式合规检查点，可审计记录。劣势——在每次审计交接处增加延迟和 Token 成本。

实现指导： 选择性地将审计应用于高风险交接（金融交易、合规敏感输出），而非每个步骤都审计。在审计覆盖率与延迟容忍度之间取得平衡。

分形思维链嵌入（FCoT）

场景： 标准思维链推理是线性且静态的。在多智能体环境中，当对等智能体提供新数据或相互矛盾的数据时，某个智能体的推理可能失效。

问题： 如何构建智能体的推理结构，使其支持动态自我修正并与对等智能体同步？

解决方案： FCoT 将推理结构化为递归、自包含的思维单元。每个单元依据目标函数（洞察力 + 一致性）进行检验。若检验失败，该单元触发时态重接地：正式修订更早的结论，而非仅追加内容。此机制支持： - 递归自我修正 — 持续对齐循环 - 动态上下文孔径 — 缩放细节层级 - 智能体间反思性 — 智能体评估并修订对等方的推理 - 时态重接地 — 过去的结论被重写，而非仅被延伸

后果： 优势——实时自我修正，透明审计链不仅展示做了什么决策，还展示为何被修订。劣势——比标准 CoT 延迟更高、Token 成本更大；需要编排基础设施支撑反思循环。

实现指导： 在实现 FCoT 之前先定义清晰的目标函数。应用于正确性能够证明额外成本合理的复杂高价值任务。对简单、时间敏感型任务则避免使用。

持久指令锚定

场景： 在深层智能体链中，原始高层指令位于上下文顶部。随着下级智能体不断追加推理和数据，指令被"淹没在中间位置"，LLM 对其关注度降低。

问题： 在深层层级化多智能体流水线中，关键约束如何在不被稀释或遗忘的情况下贯穿始终？

解决方案： 编排者将关键指令嵌入语义上显著的锚标签中（如 PERSISTENT_GOAL: [NO_FORWARD_LOOKING_STATEMENTS] 或 <CRITICAL_INSTRUCTION>...</CRITICAL_INSTRUCTION>）。这些锚点随每次交接的上下文一并传递，其设计使其无论位于提示词的何处都能保持显著性。

后果： 优势——显著减少指令漂移，提供可审计的约束可追溯性。劣势——轻微提示词开销；需要在所有智能体间保持一致的模板规范。

实现指导： 在整个系统内标准化锚点格式。使用结构化标签（而非散文），使锚点在每次交接时能被可靠地解析和重新插入。

共享认知记忆

场景： 在多智能体集群中，每个智能体维护各自私有的上下文窗口。若一个智能体发现关键状态变化，其他智能体仍一无所知——产生"巴别塔效应"。

问题： 工作流中的所有智能体如何维护同步、权威的共享世界状态认知？

解决方案： 集中式共享认知记忆模块（全局暂存区）作为单一事实来源。所有智能体通过带类型的工具对其进行读写。记忆中存储带时间戳、归属于具体智能体的事实，使下游智能体能够评估数据的新鲜度和可靠性。

后果： 优势——防止语义漂移；比在消息中传递大型状态负载更高效。劣势——集中式记忆可能成为瓶颈或单点故障；并发写入需要原子操作。

实现指导： 使用低延迟、持久化键值存储（Redis、Memcached），而非内存字典。对每条记忆条目强制设置 TTL（生存时间），防止过期事实持续存在。通过带类型的工具（update_order_status(id, status)）暴露记忆，而非通用文本写入。

系统可靠性的模式组合

在生产级智能体系统中，将多种可解释性模式组合使用可构建分层防御：

共享认知记忆 — 事实的基础层；所有智能体共享同步状态
持久指令锚定 — 确保使命在深层智能体链中得以延续
FCoT 嵌入 — 智能体推理过程中持续内部自治理
指令保真度审计 — 落实动作前的最终外部质量关卡

第三部分：鲁棒性与容错模式

鲁棒性成熟度谱系（五个等级）

等级	成熟度	核心能力	关键模式
1	基础编排	硬编码链	无；任何故障都是灾难性的
2	被动恢复	重试、超时、冗余	并行执行共识、看门狗超时、自适应重试
3	自适应容错	自愈、回退、检查点	自愈复活、回退模型调用、增量检查点、限速调用、延迟升级
4	可观测与可审计	因果追踪、信任评分、金丝雀测试	因果依赖图、信任衰减与评分、金丝雀智能体测试
5	自治理与安全	沙箱隔离、共识、隔离、防火墙	智能体网状防御、执行信封隔离、多数投票

推荐上线路径： 先从等级 2 起步保障基础稳定性；随系统规模增长推进到等级 3；为满足企业级治理要求引入等级 4–5。

并行执行共识

场景： 由单一非确定性 LLM 做出的高风险决策（信用评分、医疗分诊）具有不可接受的风险。

问题： 如何减轻关键 LLM 决策的单点故障风险？

解决方案： 两个或多个独立智能体使用不同模型或提示词并行执行同一任务。编排者比较输出，若二者在定义容差范围内一致，则结果通过验证；若差异显著，则启用解析智能体或人工审核。

后果： 优势——为关键决策提供验证层，抵御模型故障的冗余。劣势——成本和延迟更高（重复 LLM 调用）；需要明确定义容差和升级路径。

实现指导： 针对每个用例精确定义"一致"（如 5% 数值容差、语义相似度阈值等）。为分歧情况制定明确的决胜协议。

延迟升级策略

场景： 每次智能体故障立即升级至人工处理会造成告警疲劳和运营瓶颈；许多故障都是瞬时的。

问题： 系统如何在不使人工运营者不堪重负的情况下智能处理故障？

解决方案： 分层恢复路径：（1）自动重试；（2）备用智能体或简化范围；（3）仅在自动路径耗尽后才升级至人工。每次升级都打包完整上下文包，便于人工高效审查。

后果： 优势——减少不必要的打扰；增强对瞬时故障的韧性。劣势——在通知人工之前引入延迟；重试窗口需仔细调优。

看门狗超时主管

场景： 与外部 API 交互或执行复杂推理的智能体可能无限期挂起，冻结整个工作流。

问题： 系统如何在无人工干预的情况下检测并从无响应智能体中恢复？

解决方案： 编排者将每次智能体调用包裹在定时执行块中。若智能体在超时时间内未响应，则强制终止并触发回退行为（备用智能体、简化分析或升级）。

后果： 优势——防止级联停滞故障；强制执行时间边界。劣势——中途取消任务可能使资源处于不一致状态；超时值需仔细校准。

实现指导： 使用异步非阻塞定时器（Python asyncio.wait_for）。回退逻辑不仅要处理超时事件，还要处理被取消任务的所有清理工作。

带提示词变异的自适应重试

场景： 智能体因持续误解提示词而确定性地失败。简单重试（相同提示词）只会重现同样的失败。

问题： 系统如何从确定性 LLM 失败循环中恢复？

解决方案： 失败时，元智能体或编排者在重试前变异提示词。变异策略： - 改写 — 更换措辞 - 添加示例 — 提供少样本示范 - 分解 — 添加显式思维链指令（"请逐步思考……"） - 约束收紧 — 添加格式强制（"Ensure your response is valid JSON"）

后果： 优势——从确定性失败中恢复；变异后的提示词通常比原始提示词产生更准确的结果。劣势——成本和延迟增加；生成有意义的变异本身可能需要一次 LLM 调用。

自愈智能体复活

场景： 智能体进程完全崩溃，需要在不丢失任务上下文的情况下重启。

解决方案： 健康监视器检测到崩溃后，检索智能体最后一个检查点状态，并以该状态恢复启动智能体进程。

增量检查点

场景： 长时间运行的多步骤流水线若在中途被中断，将丢失所有进度。

解决方案： 编排者在每个步骤完成后将工作流状态持久化到持久存储。重启时，执行从最后一个检查点恢复，而非从头开始。

多智能体多数投票

场景： 三个或更多独立智能体对关键决策产生可能相互冲突的输出。

解决方案： 编排者收集所有输出并进行多数投票。若存在明确多数，则采纳；否则将平局升级处理。

因果依赖图

场景： 在复杂的多智能体工作流中，难以追踪哪个上游决策导致了下游故障。

解决方案： 每个智能体记录其推理链路和所消耗的输入。图将每个输出链接到其因果前驱，支持事后审计和根本原因分析。

智能体自我防御

场景： 智能体可能受到对抗性输入（提示词注入、数据投毒）的攻击，导致其行为被重定向。

解决方案： 智能体维护内部自我监控层，检测异常指令模式（如要求忽略之前约束的指令）。检测到后，智能体拒绝该指令并触发告警。

智能体网状防御（防火墙）

场景： 多智能体网络中一个被攻陷的智能体可能向其对等方发送恶意载荷。

解决方案： 智能体间通信经由防火墙智能体转发，该智能体在转发前验证消息 Schema 并强制执行策略。

执行信封隔离（沙箱隔离）

场景： 执行代码或调用外部 API 的智能体可能产生意外副作用。

解决方案： 智能体在隔离环境（容器、虚拟机、受限进程）中沙箱化执行。沙箱强制执行资源限制并限制未授权的 I/O。

限速调用

场景： 调用共享 API 的智能体可能耗尽速率限制，导致级联故障。

解决方案： 限速器包裹所有外部 API 调用，强制执行每智能体和每 API 的配额。超额请求被排队或以优雅降级方式拒绝。

回退模型调用

场景： 主 LLM 不可用，或对特定请求层级而言成本过高。

解决方案： 编排者维护回退层级。当主模型故障或成本超过阈值时，路由到更小、更快或更便宜的模型。

信任衰减与评分

场景： 智能体的可靠性随时间变化。上个月表现良好的模型或工具可能已退化。

解决方案： 每个智能体基于近期成功/失败率积累滚动信任评分。编排者利用信任评分路由任务，并对低信任智能体应用额外验证。

金丝雀智能体测试

场景： 将新版本智能体同时部署给所有用户存在大规模回归风险。

解决方案： 将少量流量（如 5%）路由到新版本智能体，与稳定版本进行性能指标对比。仅当指标保持在可接受范围内时，才继续推进上线。

优化格式转换开销

场景： 在智能体输出格式之间转换（如散文转 JSON）会消耗额外 Token 并引入错误。

解决方案： 在系统层面统一设计智能体输出 Schema，确保所有交接格式兼容，无需转换步骤。

模式与成熟度等级映射

模式	成熟度等级	类别
智能体路由器	2 – 动态单智能体	协作
主管架构	4 – 多智能体系统	任务委派
蜂群架构	6 – 自我修正智能体	任务委派
黑板知识中枢	5 – 高级多智能体	组合
合同网市场	5 – 高级多智能体	组合
监督树	5 – 高级多智能体	组合
共识	6 – 自我修正智能体	协作
智能体协商	6 – 自我修正智能体	协作
指令保真度审计	4–5	可解释性
FCoT 嵌入	4–5	可解释性
持久指令锚定	4–5	可解释性
共享认知记忆	4–5	可解释性
并行执行共识	2–3	鲁棒性
看门狗超时主管	2–3	鲁棒性
带提示词变异的自适应重试	2–3	鲁棒性
自愈复活	3	鲁棒性
增量检查点	3	鲁棒性
因果依赖图	4	鲁棒性
信任衰减与评分	4	鲁棒性
金丝雀智能体测试	4	鲁棒性
智能体自我防御	5	安全
智能体网状防御	5	安全
执行信封隔离	5	安全

参见

参考资料

Arsanjani, A., & Bustos, J.P. (2026). Agentic Architectural Patterns for Building Multi-Agent Systems. Packt Publishing. ISBN 978-1-80602-957-0. Code: https://github.com/PacktPublishing/Agentic-Architectural-Patterns-for-Building-Multi-Agent-Systems