第11章智能体应用设计模式

[11.1 概述](#11.1 概述)

[11.2 流程与控制](#11.2 流程与控制)

[11.2.1 提示链](#11.2.1 提示链)

[11.2.2 路由](#11.2.2 路由)

[11.2.3 并行化](#11.2.3 并行化)

[11.3 增强与优化](#11.3 增强与优化)

[11.3.1 反思](#11.3.1 反思)

[11.3.2 规划](#11.3.2 规划)

[11.3.3 学习与适应](#11.3.3 学习与适应)

[11.3.4 目标设定与监控](#11.3.4 目标设定与监控)

[11.3.5 探索与发现](#11.3.5 探索与发现)

[11.4 交互与协作](#11.4 交互与协作)

[11.4.1 人机协作](#11.4.1 人机协作)

[11.4.2 多智能体协作](#11.4.2 多智能体协作)

[11.5 稳健性与安全](#11.5 稳健性与安全)

[11.5.1 异常处理与恢复](#11.5.1 异常处理与恢复)

[11.5.2 优先级调度](#11.5.2 优先级调度)

[11.5.3 安全护栏](#11.5.3 安全护栏)

[11.5.4 评估与监控](#11.5.4 评估与监控)

[11.6 本章小结](#11.6 本章小结)

随着智能体应用在实际系统中的使用逐渐增多，在工程实践中逐步显现出一些具有共性的设计问题，例如在复杂任务场景下如何组织多步骤执行流程，如何在运行过程中进行决策调整，以及在多智能体或人机协作环境中如何保证系统的可控性与稳定性。已有经验表明，这类问题往往难以通过单一能力模块或局部技术优化得到有效解决，而更多体现为系统层面的设计挑战。

在此背景下，从设计模式的角度对智能体应用进行分析和整理，有助于对分散的工程经验进行抽象与归纳。本章在一定程度上参考了Google工程师提出的Agentic Design Patterns $1$ ，并结合前文对智能体能力的系统介绍，对相关内容进行了有针对性的总结，重点关注智能体在应用层面的组织方式。

11.1 概述

在当前的工程范式下，智能体系统的构建重心正显著地从"底层模型能力调用"转向"上层应用逻辑编排"。这一转变意味着，尽管基础模型的推理能力构成了智能体的认知核心，但系统的最终表现往往在更大程度上取决于应用层的结构组织与运行机制。从架构设计的视角审视，智能体设计模式不仅是代码片段的复用，更是对大规模语言模型非确定性本质的一种工程化约束。本章对相关模式的梳理，并非侧重于模型内部参数的微调或训练算法的改进，而是着眼于如何在应用层面通过逻辑框架的组合，实现复杂任务的可靠解构与执行。

为了提供一套具备实践指导意义的分析框架，本章将复杂多样的智能体设计模式归纳为以下4个核心维度。

（1）流程与控制：这一部分主要探讨任务执行路径的组织形态。从简单的顺序提示链到复杂的动态路由，其核心价值在于确立信息流转的确定性边界。在多步决策场景中，合理的流程控制能够有效缓解模型在长上下文处理中的注意力偏移问题。

（2）增强与优化：侧重于决策质量与执行过程的闭环改进。通过引入规划机制、自我反思以及目标监控，智能体得以在执行过程中根据反馈进行自我纠偏。这种模式在一定程度上赋予了系统处理动态环境的能力，使其在面对未预见约束时表现出更强的健壮性。

（3）交互与协作：关注点从单体智能转向群体智能，涵盖多智能体间的通信协议、角色分工以及人机协同的深度耦合方式。这种协作模式被广泛视为突破单模型算力与知识瓶颈的有效途径。

（4）稳健性与安全：作为系统从实验原型走向工程化部署的必要前提，这一维度涵盖异常恢复、资源调度以及安全护栏机制。在实际应用场景中，如何保障系统在极端输入或资源受限情况下的基本功能完整，已成为学术界与工业界共同关注的焦点。

上述分类方式主要服务于工程实践中的系统分析与设计需求。需要说明的是，在实际开发过程中，这些模式往往并非孤立存在。读者在参考本章内容时，应结合具体的业务场景、实时性要求以及资源成本等约束条件，进行模式的选择、变通与交叉组合。通过这种结构化的设计思维，开发者可能更有机会在模型能力的随机性与应用需求的确定性之间寻得一种技术平衡。

11.2 流程与控制

11.2.1 提示链

模式定义

提示链模式（Prompt Chaining）也被称作"流水线（Pipeline）模式"，是智能体系统中最基础且应用最广泛的结构化范式。其核心思想借鉴了计算机科学中"分而治之"的策略：将一个庞大复杂的整体目标拆解成一系列更小、更易驾驭的子步骤。由此形成的处理链条中，每一个步骤都由一个精心设计的提示词驱动 $2$ 。关键在于，上一个步骤输出的结果会无缝传递给下一个步骤，作为其输入的上下文依据，如图11-1所示。这种环环相扣的机制构建了信息的传递路径与依赖关系，使得先前操作的成果和经验能够持续指导下一步行动。通过这种方式，大语言模型在已有基础上不断深化对任务的理解并精进执行过程，从而显著提升最终产出的质量，使其更贴近期望的解决方案 $3$ 。

图11-1 提示链模式

核心机制

当在一个提示词中包含多个目标时，大模型往往因"认知带宽"限制，无法同时聚焦多个任务，易出现指令忽视、上下文漂移、错误累积等问题。提示链将复杂任务拆解为单核心指令的子任务，逐步解决单一提示的缺陷。

（1）降低认知负荷：每个子任务仅含一个核心指令，模型无须在多目标间切换，确保指令被充分执行。

（2）结构化输出与上下文锚定：要求子任务输出采用机器可读的结构化格式（如JSON），确保信息精确传递；每个子任务提示显式引用前序输出，强制模型保持对初始目标的聚焦。

（3）分步验证与错误隔离：每个子任务完成后进行结果验证，仅通过验证的输出进入后续步骤；早期错误仅影响当前步骤，无须修改后续所有步骤，降低修复成本。

案例分析

以提示链应用于信息处理工作流程为例，设定LLM需要解决的问题为"把一份冗长的行业政策文件先拆出关键政策条款，再为每个条款找实际落地案例，最后整合成一份逻辑清晰的分析报告"，提示链架构下的问题处理步骤和细节如图11-2所示：

图11-2 提示链在信息处理工作流程的应用

设计原则

尽管提示链在增强系统稳健性方面表现优异，但在工程实践中也存在显著的固有约束。首先是延迟累积问题：由于各步骤存在严格的先后依赖关系，系统的总响应时间等于所有模型推理时间的线性相加。其次是误差传导风险：若链条在前端环节产生了微小的幻觉或事实性错误，这种负面效应可能会在后续环节中被逐级放大。因此，在设计提示链时，通常引入"反馈环"或"检查点（Checkpoints）"机制，以确保链条的每一环在交付下一环节前均处于预设的质量阈值之内。

11.2.2 路由

模式定义

路由模式（Routing）在智能体架构中承担着"意图识别与任务分发"的核心职能 $4$ 。与线性执行的提示链不同，路由机制引入了逻辑分支，使系统能够根据输入数据的特征、用户意图的语义空间或当前环境变量，动态地将任务引导至最匹配的处理单元，如图11-3所示。这种模式在一定程度上解决了单体提示词在处理异构任务时的泛化能力不足问题，通过"专才专用"的原则提升了系统的整体效能。

图11-3 路由模式

实现方式

路由的实现方式通常取决于对响应延迟、成本预算及分类精度的权衡，主要包含以下几种典型路径：

（1）基于LLM的路由：利用大语言模型强大的自然语言理解能力，通过特定的提示词驱动模型对输入进行语义解析，并输出结构化的路径标识符。LLM路由能够处理极具模糊性和上下文依赖的任务，不仅能判断"用户想做什么"，还能识别其中蕴含的情感、语调或潜在需求。

（2）基于嵌入的路由：方法通常与检索增强生成（RAG）技术紧密耦合，利用高维向量空间的数学特性来实现语义匹配。系统预先将不同的功能模块或知识库定义为一组"基准向量"，当新的查询进入时，系统将其转化为相同维度的嵌入向量（Embedding），并通过计算余弦相似度等指标进行路径匹配。

（3）基于规则的路由：这是最符合传统软件工程逻辑的方式。通过预定义的逻辑（如if-else或switch-case语句），结合关键词匹配、正则表达式或请求头中的特定结构化字段（如User-ID、API-Key、地理位置标签）进行静态分发。

（4）基于机器学习模型的路由：采用专门针对路由任务训练的判别式模型（如轻量级分类器、随机森林或微型神经网络）来执行路径判定。这是一种处于"规则"与"生成"之间的中间路线，兼顾了灵活性与效率。通过收集真实场景下的历史标注数据，训练一个多分类模型（Classifier）。该模型能够识别输入文本的特征分布，并以极高的概率输出其所属的业务领域。

设计原则

基于规则的路由具有零延迟和高确定性，但难以应对模糊表达；基于LLM的路由语义理解力强，但存在推理时延与Token成本，设计时通常采用"先规则、后模型"的漏斗结构。在工程上应尽量降低路由环节的计算权重，避免出现"为了路由一个简单任务而消耗大量算力"的资源错配现象。过细的路由会导致系统拓扑过于复杂，增加维护成本；过粗的路由则可能导致下游执行单元负担过重。

11.2.3 并行化

模式定义

并行化模式（Parallelization）是智能体系统应对高吞吐量需求与降低端到端延迟的关键手段。在处理相互独立、无因果依赖的子任务时，传统的串行逻辑往往会造成计算资源的浪费与响应时间的冗余。并行化模式借鉴了计算机系统结构中的并发执行思想，允许智能体同时激活多个执行线程或子模块，如图11-4所示，通过分布式处理来突破时间线性增长的约束。

图11-4 并行化模式

核心模式

该模式通常包含以下两个核心子模式。

（1）分段并行：将单一复杂任务横向切分为多个独立的子环节。例如，在进行大规模研报分析时，系统可并行调用不同的智能体分别审查财务数据、市场竞争与法律风险，最后通过聚合模块整理反馈。

（2）冗余并行与投票机制：为了抑制大模型的随机幻觉，系统可以针对同一任务并发请求多个模型实例或使用不同的采样参数 $5$ 。通过对比、多数表决或中立评审等算法，从多个备选答案中筛选出一致性最高的输出。

设计原则

尽管并行化在效率提升上表现显著，但在工程实现层面也引入了新的变量。首先是状态一致性问题：由于各并行分支处于独立的运行环境，如何确保各子任务在聚合时能够共享必要的全局上下文，是架构设计的难点。其次是资源配额管理：大规模的并发请求可能触发底层模型服务的速率限制，开发者通常需要在并发度与API稳定性之间寻得平衡。并行化不仅是一种性能优化手段，更是智能体系统迈向工程化成熟度的重要标志。通过合理的并行策略设计，开发者能够使系统在处理复杂任务的过程中，表现出更接近人类组织团队协作的高效特征。

11.3 增强与优化

11.3.1 反思

模式定义

反思模式（Reflection）是指智能体在完成一次任务后，对自身的行为过程、生成结果或内部状态进行审视与评估，并基于评估结论对后续行为进行调整的一种机制 $6$ 。这种机制本质上是一种自我纠错或自我改进的能力，使智能体不再局限于一次性生成结果，而是能够在已有输出的基础上识别不足之处，根据反馈、内外部的评价标准或者和预期目标进行对比并主动进行修正，逐步优化响应质量。

与简单的线性推理或者固定决策方式不同，反思模式的核心特点是引入了反馈循环。智能体不仅关注当前输出结果是否完成任务，还会回溯生成过程，检查推理是否充分、结论是否合理，并据此生成改进版本或调整后续策略 $7$ 。

典型流程

反思模式的流程如图11-5所示，主要按照如下步骤展开。

1）执行阶段

智能体根据当前目标与输入条件完成一次任务执行，或者生成初始的响应结果。该阶段旨在提供一个可供后续分析的候选方案，而非直接寻求最优解。

2）评估和批判阶段

在获得初始结果后，Agent对输出进行系统性检查与分析。该阶段可以由同一智能体触发，也可以借助额外的模型调用或者规则机制完成，重点关注结果的事实准确性、连贯性、风格、完整性、是否遵循指令等。

3）反思和优化阶段

基于评估阶段识别出的问题，智能体对当前结果进行反思，并确定改进方向。常见做法是对输出内容进行修订、调整生成策略，或者重新规划任务执行方式。

4）迭代阶段（可选）

经过优化后的输出或调整后的方案可以再次进入执行流程，从而形成多轮循环。该循环可持续进行，直至结果满足预期要求，或达到系统设定的中止条件。这种基于反馈不断重复的执行机制，使智能体在复杂任务中具备逐步逼近目标的能力 $8$ 。

图11-5 自我反思流程

实现方式

在反思模式的具体实现中，常见的一种做法是将流程分为两个逻辑角色：生产者（Producer）和批评者（Critic），即"生产者--批评者"或"生产者--审阅者"模型，如图11-6所示。虽然单一智能体也能对自身输出进行反思，但将生成与评估的职责进行分离，通常能够带来更稳定、更系统化的反馈结果。在工程实践中，这种分离既可以通过两个独立智能体实现，也可以通过同一大语言模型的多次调用，并配合不同的系统提示词来完成。

1）生产者智能体

生产者负责任务的初始执行，核心目标是快速生成可用的候选结果，如编写代码、撰写博客或指定计划等。该智能体主要关注内容生成本身，依据初始指令给出第一版输出，而不对结果进行深入的自我评估。

2）批评者智能体

批评者专门用于审阅和分析生产者的输出，其角色设定通常更加明确且具有限制性，例如被要求以"资深软件工程师"或"严谨的事实核查员"的身份进行判断。批评者依据预先定义的标准（如事实准确性、实现质量、表达规范或完整性等）对结果进行检查，识别潜在的问题，并给出改进建议或结构化反馈。这种"以评促改"的机制在大语言模型系统中已被证明能够有效提升输出质量 $9$ 。

图11-6 生产者与批评者

设计原则

反思机制的效能取决于评论者与生成者之间的"视角分歧"，如果两者的提示词或模型参数高度一致，反思将流于形式。此外，系统必须设定严密的终止判定逻辑（如质量评分达标或达到最大迭代次数），以防系统陷入无休止的自我否定与逻辑递归。

11.3.2 规划

模式定义

规划模式（Planning）是智能体实现复杂目标的基础，其核心逻辑在于智能体在正式行动前，首先利用推理引擎将宏观目标解构为一系列具备逻辑先后的子任务或行动蓝图，如图11-7所示。这种"预思考"机制类似于人类的执行功能，能够显著降低模型在处理长程任务时的逻辑耗散，确保每一个执行动作都指向最终目标的达成。

图11-7 规划模式

实施策略

（1）任务拆解与子目标分解：将一个复杂的复合请求拆解为可操作的独立步骤 $10$ 。例如，在"策划并预订一次商务旅行"任务中，规划模式会自动识别并排序：查询行程安排、比价机票、锁定酒店、执行预订。

（2）多路径并发规划：针对高度不确定的环境，智能体可以预先生成多条候选路径（Path A/B/C），并根据环境反馈动态选择最优分枝，从而避免在单一路径失效时导致任务崩溃。

（3）工具发现与动态编排：规划不仅是行动的排序，还涉及对外部工具（API、数据库、解释器）的调用时机预判，确保在正确的时间节点调用正确的外部能力 $11$ 。

设计原则

规划的颗粒度是一个关键的权衡点：过于精细的计划会消耗多余的推理开销且容易在环境波动时失效，而过于粗糙的计划则会导致模型在执行中因缺乏明确指令而偏离预设航道。此外，设计者必须防范"规划幻觉"，即模型生成了逻辑上看似合理但在实际环境或工具限制下无法完成的任务步骤，通常需引入自检机制来验证每一步的可行性。

11.3.3 学习与适应

模式定义

学习与适应（Learning & Adaptation）模式是智能体能力持续提升的核心机制。通过这些过程，智能体能够超越预先设定的规则或者参数，在与环境的交互中不断修正自身行为与内部表示，从而实现性能的自主优化。

实现机制

1）基于反馈的策略学习

智能体通过与环境交互，根据奖励或惩罚信号调整行为策略，以在动态或不确定环境中学习最优决策路径。这一机制是强化学习及其在智能体系统中的核心体现，也是当前LLM智能体实现"行动-反馈-改进"闭环的重要基础 $12$ 。

2）基于数据结构的表示学习

智能体通过监督或无监督方式，从数据中学习输入与输出关系或潜在结构，用于分类、预测、聚类与环境建模，帮助其形成对任务和环境的稳定认知表示。

3）快速与持续适应机制

该机制包括少样本/零样本学习、在线学习与基于记忆的学习。智能体能够借助少量示例或历史经验迅速适应新任务，并在运行过程中持续更新知识，以支持长期运行中的稳定性与泛化能力 $13$ 。

案例分析

自我改进编码智能体（Self-Improving Coding Agent，SICA）由Maxime Robeyns、Martin Szummer和Laurence Aitchison提出，能够自主编辑自身源代码并持续提升性能，体现了智能体在学习与适应方面的一种新型实现路径 $14$ 。

SICA的自我改进流程如图11-8所示。首先，SICA回顾历史版本及其基准测试表现，选出得分最高的版本（综合成功率、时间和计算成本加权）。该版本进行新一轮自我修改，分析归档以发现改进点，并直接修改代码库。修改后的智能体再次进行基准测试，结果记录归档。此过程不断循环，实现基于历史表现的学习。该机制使SICA无须传统训练范式即可进化能力。

图11-8 SICA的自我改进流程 $14$

设计原则

在工程落地时，核心挑战在于如何防止"知识污染"。如果检索到了不相关或过时的历史经验，反而会干扰模型当前的判断。因此，必须设计精密的语义过滤机制，确保提取的经验与当前上下文具备高度的结构相似性。系统还需要具备"遗忘"或"更新"的能力。当业务规则发生变更时，陈旧的成功案例可能演变为错误的引导。架构上通常采用时间衰减权重或手动标记机制，以确保智能体学习到的始终是最前沿的策略。另外，引入学习机制会增加额外的向量检索与上下文填充开销。开发者需评估任务的重复率，对于随机性极强、几乎不重复的任务，过度设计学习模块可能会导致系统臃肿，产生不必要的工程损耗。

11.3.4 目标设定与监控

模式定义

目标设定与监控（Goal Setting & Monitoring）模式要求开发者将模糊的业务指令转化为具备"退出条件"和"成功准则"的结构化任务描述，如图11-9所示为目标设定与监控流程示意图。与其配套的监控机制则充当了系统的感知器，负责在任务执行的全周期内，实时对比当前执行状态与预设目标之间的偏离度，从而确保智能体不偏离业务主轴。

图11-9 目标设定与监控模式

核心逻辑

（1）目标参数化与约束定义：将业务指令结构化。例如，"帮我分析行业趋势"被转化为：分析维度（竞争对手、技术路线）、数据范围（近5年）、产出格式（JSON或Markdown）以及时间预算 $15$ 。

（2）执行轨迹监控：监控器持续记录智能体的"思维-行动-观察"链条。通过对这些中间状态的分析，系统可以快速识别出智能体是否陷入了逻辑循环、幻觉堆叠或正在向非预期的方向过度探索。

（3）偏离纠偏与异常中断：当监控器检测到当前状态严重偏离初始意图（例如，智能体在处理法律文书时开始讨论厨艺）时，它会立即触发纠偏逻辑，重新注入初始目标以强行拉回逻辑主轴，或在必要时直接熔断任务 $16$ 。

设计原则

监控机制的设计应遵循"非干扰性"原则，即监控过程不应显著拖慢主业务流的执行速度。在实际部署中，通常在工具调用前后或长链推理的关键节点设置检查点。开发者需在监控深度（如全量检测）与系统性能之间寻求平衡，避免过度监控带来的算力浪费与响应延迟。

11.3.5 探索与发现

模式定义

探索与发现（Exploration & Discovery）模式赋予了智能体在信息不完备的环境下主动拓展知识边界的能力。不同于被动的信息检索，该模式强调智能体能够识别自身认知空白，并主动通过试错、外部工具调用或实验模拟来获取必要的缺失信息，从而实现从"静态知识应用"向"动态问题解决"的跃迁。

核心模式

1）结构化探索

结构化探索旨在为智能体的认知行为提供系统化的引导框架，从根本上解决"搜索空间爆炸"的问题。该模式的核心在于模仿人类的认知路径，引入课程学习与渐进式探索机制 $17$ ，为智能体构建一个从简化环境到复杂场景的过渡阶梯。初期，系统将智能体限制在低风险、高信息密度的环境子集中，随能力提升逐步解除约束。同时，结合层次化探索策略，架构师可将决策解耦为"战略导向"与"战术执行"两个层面，使探索行为不再是无序漫游，而是具有明确意图的战术推进。

2）内在动机驱动

内在动机驱动通过构建内部奖励信号，赋予了智能体"自发性学习"的能力，使其能够脱离外部稀疏奖励的限制进行持续进化。其底层逻辑多基于预测误差（Prediction Error）：当环境反馈显著偏离内部模型预测时，系统会产生正向奖励，驱使智能体主动寻找能最大化认知增益的状态 $18$ 。从信息论视角看，这一过程本质上是通过技能获取来降低环境的分布熵（Entropy Reduction），为应对未知任务储备通用的底层能力。

3）协同与社会化探索

为规避群体性的局部最优，系统通常在初始化阶段引入策略差异或参数变异。特别是在冷启动阶段，模仿学习可利用专家演示数据划定高价值的先验区域，引导智能体进行精细化搜索。此外，构建中央经验回放池是实现群体进化的关键手段，通过共享个体的长尾发现与失败教训，将偶然的个体经验转化为群体的结构化知识，从而加速生态系统的整体演进。

设计原则

由于探索过程本质上带有不可预测性，工程上必须为其设定明确的"资源红线"，包括最大探索深度、API调用次数以及时间预算。此外，系统应具备对探索产出进行质量评估的能力，防止智能体在无效信息的噪声中迷失方向。

11.4 交互与协作

11.4.1 人机协作

模式定义

人机协作（Human in the Loop，HITL）模式强调在智能体工作流的特定节点引入人类的判断与干预。在处理高风险任务或需要复杂价值观对齐的决策时，完全自动化的系统可能面临不可控的道德或逻辑风险。HITL机制确保了智能体在具备高效执行力的同时，始终处于人类的战略监管之下 $19$ 。人机协作模式流程示意图如图11-10所示。

图11-10 人机协作模式

典型范式

（1）批准模式：智能体在执行具有副作用的操作（如发送外部邮件、调用支付接口）前，必须获得人类的明确授权。

（2）反馈模式：人类对智能体的中间产出进行评审或修改，智能体根据反馈动态调整后续生成的策略。

（3）接管模式：当智能体识别到任务超出其处理边界时，系统自动将控制权移交给人类专家，确保业务流程的连续性。

设计原则

同步阻塞式的人类审批会极大地降低系统的整体吞吐量，因此通常采用任务挂起与回调机制来实现异步协作。为了降低人类决策者的认知负荷，系统提交的上下文信息必须经过高度精简，既要提供支撑判断的关键证据，又要避免冗余信息造成的视觉疲劳。此外，设计者还需制定明确的超时策略，确定当人类未能在规定时间内响应时，系统是应采取默认拒绝操作还是转入低风险的安全降级模式。

11.4.2 多智能体协作

模式定义

多智能体协作（Multi-Agent Collaboration）模式是智能体系统向更高阶演进的标志。通过将多个具备不同专才的智能体组合在一起，系统可以并行处理复杂任务的不同维度 $20$ 。模式遵循任务分解原则，先将高层目标拆分为若干子问题，再分配给拥有相应工具、数据访问权限或推理能力的智能体分别处理。多智能体协作模式示意图如图11-11所示。

图11-11 多智能体协作模式

协作形式

多智能体协作模式设计系统时，多个独立或半独立智能体共同实现目标。每个智能体有明确角色、目标，并可能访问不同工具或知识库。该模式的核心在于智能体间的互动与协同，主要有以下6种协作形式。

顺序交接：智能体依次执行任务，当前智能体完成后将输出传递给下一个智能体。这种模式类似于传统规划流程，但明确由不同智能体分别承担各环节。
并行处理：多个智能体同时处理问题的不同部分，最终将各自的结果进行整合。
辩论与共识：智能体基于不同视角或信息源展开讨论，通过辩论推动决策优化，最终达成共识。
层级结构：由管理者智能体根据各工作智能体的工具或插件能力动态分配任务，并负责汇总结果。每个智能体通常专注于管理与其相关的一组工具，而非由单一智能体处理所有工具。
专家团队：由具备不同领域专长的智能体（如研究员、写作者、编辑等）协同合作，共同完成复杂的输出任务。
批评-审查者：一组智能体生成初步输出（如计划、草稿、答案等），另一组智能体对其在政策、安全、合规、正确性、质量及目标对齐等方面进行评审。原作者或最终负责的智能体再依据反馈进行修订。

交互方式

多智能体的交互方式是多智能体系统的基础。多智能体的具体交互方式如图11-12所示。

图11-12 多智能体的交互方式

单智能体：最基础的模型，智能体独立运行，无须与其他实体交互。该模型适用于可拆分为独立子任务的场景，但能力相对受限。
网络型：多个智能体以去中心化方式直接交互，通过点对点通信实现信息、资源和任务的共享。该模型弹性较好，但通信协调与决策一致性较难维持。
监督者型：由专门的监督者智能体协调下属智能体，负责通信中转、任务分配与冲突解决。该模型层级清晰、易于管理，但容易发生单点故障和性能瓶颈的风险。
工具型监督者：监督者不直接指挥，而是为其他智能体提供资源、指导或分析支持，以赋能而非控制的方式提升系统灵活性。
层级型：采用多层监督结构，高层监督者管理低层监督者，底层为执行具体任务的操作智能体。该模型适用于复杂问题的分层治理，便于扩展与分布式决策。
定制型：最为灵活的模型，针对具体问题或应用场景设计独特的关系与通信结构，可融合多种模型或创新设计。该模型特别适合需要优化特定性能、适应动态环境或集成领域知识的场景。

设计原则

智能体间的频繁交互极易产生大量冗余信息或通信爆炸，因此必须设计严格的消息路由和过滤机制，确保每个专家仅接收与其职能相关的输入。当不同智能体给出相互矛盾的结论时，系统需要预设有效的仲裁与共识机制，例如通过"首席智能体"进行最终决策或采用多数表决算法。同时，为了保证协作的连贯性，系统还需维护一个集中的状态空间或全局共享记忆，确保所有参与者能够实时同步任务的最新进度与环境变量。

11.5 稳健性与安全

11.5.1 异常处理与恢复

模式定义

异常处理与恢复（Exception Handling & Recovery）模式并非进行传统的程序错误捕捉，而是针对智能体特有的失效场景，如工具调用超时、模型输出格式歧义、逻辑陷入死循环等，建立的自动化补救流程。其核心逻辑在于，系统不应寄希望于模型产生"永远正确"的结果，而应具备处理"错误结果"并从中恢复的能力。

实现机制

该模式通常由三个核心环节构成闭环 $21$ ，如图11-13所示：

（1）异常探测：负责实时监控智能体的运行脉搏，敏锐捕捉工具执行异常（如API返回500错误）、响应超时或非预期的输出结构。

（2）异常处理：根据错误类型执行预设策略，如记录日志便于后续分析、对瞬态错误进行重试、切换备用工具或策略以及对系统功能进行优雅降级，同时在必要时通知人类操作员介入。

（3）恢复：恢复系统稳定性，可能执行状态回滚（撤销错误操作）、进行故障诊断并自我修正（如重新规划路径、调整提示词）或将重大问题上报更高层次系统或人工团队。

图11-13 异常处理与恢复模式

设计原则

异常处理与恢复模式虽然能提高智能体的健壮性，但也有一些限制。首先，故障检测和恢复逻辑的设计成本较高，需要针对不同任务定义恰当的错误判定和补救措施。过多的错误处理规则可能导致系统复杂化；反之规则不足则可能遗漏某些边缘情况。其次，依赖外部工具或服务的Agent无法完全避免网络故障或第三方服务不可用的情况，此时只能降级服务或等候人类介入。此外，异常恢复（如状态回滚、参数调整）可能导致系统效率下降，因此需要权衡性能和可靠性。未来研究可探索将反思机制与异常处理模式相结合：当发生故障时，让智能体自动反思并调整策略（如提示词优化）来避免重复错误。

11.5.2 优先级调度

模式定义

优先级调度是一种针对计算资源（如API配额、并发槽位、推理带宽）进行权衡分配的管理范式。在多任务并行的复杂应用中，系统通过识别任务的重要性、紧急程度及用户权重，确保关键路径始终能够获得充足的算力支持 $22$ 。从策略角度看，优先级调度可分为静态调度和动态调度两类。静态调度在任务到达时即确定其优先级，并在整个生命周期内保持不变；而动态调度则允许优先级随着运行时信息变化而动态调整。在实际智能体系统中，优先级调度常采用分层（多粒度）设计：在高层对总体目标或项目排序，在中层对目标下的子任务排序，在执行层对具体行动或工具调用排序，从而兼顾长期战略和即时响应。

实现机制

典型的优先级调度模块由以下4个核心组件构成。

任务队列：存放待处理任务。
优先级评估机制：根据预定标准为任务打分。
排序器：按分值对任务排序。
调度控制器：负责执行任务。

在该机制下，任务首先被收集到队列中，调度模块根据定义好的规则（如紧急性、重要性、依赖关系、资源可用性等）对每个任务进行评估；然后排序器按得分对队列中的任务进行降序排列；最后调度控制器依次从队列头取出最高优先级任务并分配资源执行，从而确保关键任务优先完成。这一过程使得系统能在资源有限、目标冲突时聚焦最重要的工作，表现出更高的智能性和健壮性。

设计原则

尽管优先级调度在许多场景中有效，但也存在一些局限性。首先，任务重要性和紧急性常具有一定主观性，不同用户或团队成员对优先级的评估可能不一致，导致调度决策难以统一。其次，过度强调高优先级任务可能会导致次要任务被忽视或耽搁，进而在长期产生负面影响。此外，在高度动态或开放的环境中，预定义的优先级规则可能不足以应对意外情形，需要智能体具备更多的学习和预测能力。由于优先级调度通常依赖已有信息，当新的需求或干扰出现时，系统还需迅速调整策略，这对模型性能提出了挑战。

11.5.3 安全护栏

模式定义

安全护栏（Guardrails）模式也被称为安全模式，随着智能体日益自主化并被集成至关键业务系统，确保其行为的合规性与可控性已成为核心挑战。安全护栏机制作为智能体架构中的"免疫系统"，旨在构建一层独立于推理模型之外的防护网，确保系统始终在安全、合规及预期的边界内运行。它们在整个智能体系统中充当保护层的作用，引导智能体的行为和输出，防止有害、偏见、无关或其他不良影响 $23$ 。这种保护层可以在多个阶段实施，包括输入阶段，通过对输入的内容进行验证或者清洗来过滤恶意内容，在输出阶段进行输出结果的过滤或者再处理，以分析生成的内容是否有害或带有偏见。此外，还可以通过提示词对智能体进行行为约束，以及通过对工具使用进行限制、引入外部内容审核API对输入与输出进行审查，并结合"人机协作"机制在关键场景下进行人工干预与复核。

实现路径

（1）输入端拦截：输入护栏的核心任务是防御"提示词注入（Prompt Injection）"与"指令越狱"。恶意用户可能通过精心构造的文本（如"忽略所有前序指令"）试图篡改系统的系统级设定。对此，工程上常部署轻量级的判别模型（BERT或DistilBERT变体）作为前置防火墙，在指令进入大模型推理前识别并阻断异常意图。

（2）输出端脱敏：输出护栏主要聚焦于数据隐私与业务逻辑的严谨性。一方面，利用正则匹配或命名实体识别（NER）技术，自动识别并掩码处理（Masking）身份证号、API密钥等敏感信息；另一方面，通过格式校验器强制约束输出结构（如JSON Schema），确保智能体生成的非结构化文本能够被下游系统无误解析。

设计原则

构建工业级的护栏机制需在执行效率与架构稳健性之间寻求严密的平衡。由于安全校验位于推理的关键路径上，工程实施应优先采用向量相似度匹配或专用小模型等轻量化方案，以避免因通用模型的过度计算而损害系统响应速度。在架构层面，必须严格遵循最小权限原则与关注点分离模式，将安全防御逻辑与核心推理模块解耦，从而收敛攻击面并防止单点失效引发的级联故障。此外，系统还需建立深度可观测机制，通过结构化的审计追踪将隐性的拦截决策透明化，为合规性审查及安全阈值的持续调优提供确凿的数据支撑。

11.5.4 评估与监控

模式定义

评估与监控（Evaluation & Monitoring）模式是对智能体运行状态的动态画像。与传统软件工程中基于断言的确定性测试不同，智能体系统的评估需要超越简单的"成功/失败"二元对立，转而侧重于对思维链与执行轨迹的全程追踪。该模式的核心目标是实现对大语言模型非确定性逻辑的"黑盒透视"，将不可预测的生成行为转化为可量化、可审计的工程指标。

评估方法

（1）自动化指标：这是最基础、最高效的评估层。它不依赖复杂的语义理解，而是基于确定的规则或数学计算（如代码可执行性检测、JSON格式校验、关键词覆盖率）。其特点是极快且零边际成本，但无法捕捉深层逻辑谬误。

（2）LLM评审（LLM-as-a-Judge） $24$ ：利用高阶大语言模型模拟人类评估者。通过预设的评分标准，对智能体的推理过程、安全性及"有用性"等主观指标进行定性打分。它具备较强的语义理解能力，且比人工评估更具可扩展性，适合规模化的质量回归测试。

（3）人工评估：由领域专家或最终用户参与的评估，被视为所有评估方法的"黄金标准"。它通常用于高风险领域的最终验收或构建评估集的基准答案，虽然成本高昂且周期长，但最能反映真实的用户体验。

评估维度

1）响应质量评估

评估体系需兼顾事实的准确性、逻辑的严密性以及与用户意图的对齐度。对于结构化或半结构化任务，基础的基准匹配仍是最高效的验证手段。在生产级应用中，通常利用Levenshtein距离衡量文本相似度，或采用语义嵌入向量计算余弦相似度，甚至引入LLM评审的模式。

2）资源开销监测

对于由大语言模型驱动的系统，Token吞吐量直接关联运营成本与响应延迟。建立精细化的用量追踪机制，系统不仅需要记录单次交互的输入与输出Token数量，更应维护全生命周期的累计消耗账本，将这些结构化的度量数据对接至Prometheus或Grafana等可观测性平台。通过分析Token消耗的时空分布规律，开发者可以精准定位冗余的提示词模板，从而在维持响应质量的同时实现算力资源的集中管理。

3）智能体轨迹评估

智能体轨迹评估比传统软件测试更复杂，因其行为具有概率性，需同时考察决策过程与最终结果。尤其在多智能体系统中，还需衡量协作效率、通信准确性和对动态环境的适应能力。在此基础上，可从以下几个具体指标对智能体轨迹进行细化评估：

轨迹一致性：通过对比实际执行路径与预设的"理想轨迹"，评估智能体是否遵循了预期的SOP（标准作业程序）。例如，客服智能体是否严格按顺序执行了"意图识别---工具调用---结果验证---回复生成"的流程。
协同效能评估：在多智能体系统中，评估维度需扩展至群体层面。重点考察信息传递的准确性（如票务智能体是否将日期准确传达给酒店智能体）、任务分配的合理性以及系统的整体熵增。
测试集分层：主流实践倾向于构建分层评估体系。单元测试文件用于快速验证单次交互的原子能力；而综合评估集则包含复杂的多轮会话记录与工具调用序列，用于在系统迭代时进行全量回归测试。

设计原则

监控数据的核心价值在于"反馈驱动进化"。通过对大量执行轨迹的回溯，开发者可以定位模型在哪个环节产生了"逻辑幻觉"或"逻辑循环"。监控采集过程应尽量减少对系统执行效率的影响。同时，评估体系不应局限于准确率，还应包含执行耗时、经济成本、工具调用有效性以及用户满意度。

11.6 本章小结

本章系统性地论述了智能体应用开发中的核心设计模式，旨在为开发者提供一套从实验性原型向生产级系统跨越的工程范式。设计模式的应用本质上是在大语言模型的随机性生成能力与企业级应用所需的确定性逻辑之间，构建起一层稳健的架构约束。通过对流程控制、增强优化、交互协作以及稳健性保障4个维度的深度解构，我们可以清晰地看到智能体系统是如何从单一的模型调用演进为复杂的有机架构的。

在架构底层，流程与控制模式奠定了系统的"骨架"，通过提示链、路由及并行化机制，实现了任务的有序解构与高效分发。而增强与优化模式则赋予了系统类人的"认知深度"，利用规划、监控与反思机制构建起闭环反馈，有效抑制了模型幻觉并提升了复杂决策的准确度。进入群体智能阶段，交互与协作模式通过角色分工与人机协同，突破了单体模型的认知瓶颈与资源限制，实现了能力的规模化扩展。最后，稳健性与安全模式作为系统的"护栏"，通过异常恢复、优先级调度与安全过滤，确保了智能体在非确定性环境下的工程可靠性与合规性。

智能体开发已不再仅仅是提示词的艺术，而是一门严谨的系统工程。开发者在实践中不能机械地套用模式，而是应该结合具体的业务约束、成本预算与容错等级，灵活地进行模式的组合与变通，从而构建出真正具备工业强度、能够自主应对复杂现实挑战的智能体应用。

第11章 智能体应用设计模式