Agent 设计模式：从 ReAct、CodeAct 到 Agentic Rag 与多智能体

Agent 设计模式 是指将大模型与规划、记忆、工具调用、信息检索、执行、反思、协作等功能模块组合起来的系统化框架。相比于单纯调用一个大语言模型（LLM）生成答案的"问答模式"，Agent系统通过构建思考---执行---反馈的闭环，支持更复杂的任务处理。单一 LLM 通常只能回答封闭式问题，其知识来自静态训练数据，难以执行多步骤操作或调用外部资源；而 Agent 通过内置规划（Planner）、短期/长期记忆、工具接口（Tool）、知识检索（Retriever）、行动执行（Executor）、自我评估（Evaluator）等模块，动态组织推理与行动的循环，从而应对更复杂的场景。关键在于，这些设计模式并非 互斥，实际工程中常常将多种模式组合使用，形成复合 Agent 架构。例如，一个系统可能同时使用基于检索的知识增强、可执行代码以及自我反思策略，实现更高的鲁棒性和准确性。

本篇将系统深入地解析五种常见的 AI Agent 设计模式：ReAct、CodeAct、Agentic RAG、Self-Reflection 和 Multi-Agent Planner。我会将对每种模式的核心思想、执行流程、系统结构、适用场景、优缺点、常见风险及工程选型建议逐一展开，帮助大家理解各种模式的本质区别及应用边界。

第一部分：从 RAG 到Agent，再到复合 Agent 系统

传统 RAG 的基本流程

传统的**检索增强生成（Retrieval-Augmented Generation，RAG）**框架主要由两个部分构成：。首先是检索组件，它通常包括一个用于将用户查询转换为向量的嵌入模型和一个向量数据库。用户输入的问题被编码成向量后，在知识库（如文档集合、数据库等）中进行相似性检索，得到相关文本或数据片段。然后，生成组件（LLM）将检索到的上下文内容与原始查询一起作为输入，通过语言模型生成答案。这样做的好处是，语言模型可以实时使用最新和领域特定的数据，提高回答的准确性和可信度。

简要流程图如下：

该流程的特点是被动检索：LLM只有在生成答案时才借助检索结果，且检索策略（查询向量计算等）是固定的，没有进一步的规划或迭代。传统 RAG 在企业问答、知识库 QA 等场景中广泛应用，能够让模型引用准确来源，减少幻觉，但对流程的控制能力较弱，一旦检索结果不足或不准确，系统自身很难主动修正。

Agent 相比 RAG 增加了哪些能力

Agent 系统 在 RAG 基础上增加了更多主动能力，其核心在于引入"智能体（Agent）"的概念，让 LLM 不仅仅是被动生成器，而是能够规划、决策、调用工具、管理状态和记忆。具体而言，Agent相比传统 RAG 增强了：

规划能力（Planner）：Agent 可以根据任务需求拆解子任务、生成行动计划。例如，一个问答 Agent 在收到复杂查询后，可以先分步思考需要哪些工具或检索步骤，再按序执行。
工具调用（Tool Use）：Agent 能够自主调用外部 API、数据库、代码执行环境等多种工具，丰富其动作空间。ReAct 就将链式思维与行动指令交替进行，让 LLM 在思考过程中决定何时使用工具；CodeAct 则将所有行动都抽象成代码，通过 Python 解释器执行。
状态管理与记忆（Memory） ：与传统 RAG 只在问答时读取数据不同，Agent 往往具有短期记忆和 长期记忆，能够记住之前的对话上下文、历史决策、用户偏好等，在多轮对话或多阶段任务中积累状态。例如，Agentic RAG 可能会缓存之前的检索结果或查询日志，用于加速后续检索。
反馈循环（Feedback Loop）：Agent 系统常常在每一步得到外部反馈（如工具执行结果、环境观测），并将其纳入新的思考阶段，形成循环闭环。ReAct 模式中即包含"思考---行动---观察"的循环；Self-Reflection 模式则让 Agent 对自身输出进行评估、修正。
多 智能体 协作：进一步的系统演进会引入多智能体（Multi-Agent）架构，不同智能体可以分工协作，如规划 Agent 指定任务、执行 Agent 完成子任务、评审 Agent 校验结果等。

这种从被动检索到主动规划与执行的演变，可以概括为RAG → 工具驱动 Agent → 反思型 Agent → 多 智能体 系统的趋势。简要演进视角示意图如下：

上述演进反映了系统能力的累积：首先引入工具和环境交互，然后加入自我评估机制，最终在复杂任务中用多个 Agent 协同工作。下一节我们将逐一深入分析这五种常见设计模式的细节。

第二部分：5种常见 Agent 设计模式逐一深度解析

以下对每种模式都依次展开：定义、核心组成、执行流程、流程图、适用场景、优缺点、失败风险、工程建议，并给出伪代码示例和选型建议。

ReAct 模式

模式定义

ReAct （Reasoning and Acting）模式是一种将链式思维与外部行动结合的策略。简单一句话定义：ReAct 是在自然语言生成过程中交替输出"思考（Thought）"和"行动（Action）"，再根据工具或环境反馈更新思考。与普通对话型 LLM 区别在于，它显式产出思考轨迹（类似链式思维）并在思考之间执行工具调用（如搜索、计算等），形成"思考 → 行动 → 观察 → 再思考"的闭环。这使得 Agent 在回答复杂问题时能够主动查询外部资源、处理突发情况，而不仅仅依赖模型内部知识。

一句话选型建议：当任务需要模型在推理过程中主动调用外部工具（如 搜索引擎 、数据库、计算器等）时， ReAct 模式非常合适。

核心组成

ReAct 模式的核心模块可以包括：

LLM （大语言模型）：作为"思考的引擎"。模型负责生成当前的思考内容（Thought）和决定接下来的行动（Action）。LLM同时承担规划和生成角色，不单纯输出最终答案，而是在内部展开多轮推理。
思想（Planner/Thought）：虽然本质也是由 LLM 实现，但可以认为 ReAct 的"思考"就是生成的可读推理过程，用于分解子任务或判断下一步行动。
工具/执行器（Tools/Executor）：ReAct模式定义了预设的"行动"类型，例如 API 调用、检索指令、计算步骤等。这些预定义工具能够被 LLM 识别并调用。常见工具包括：网络搜索引擎、数据库查询、计算器、知识库接口、命令行工具等。
环境/观测（ Environment /Observation）：工具执行后的结果或外部系统的反馈，作为下一轮思考的输入。例如，搜索工具返回的文档摘要、计算器输出的数值等。
短期记忆/对话上下文（Memory/Context）：ReAct通常在对话上下文中包含之前的"思考、行动、观察"记录，以供 LLM 下次生成时参考。这种上下文保持了 Agent 的状态，使其能记住已执行的操作和已观察到的信息。
反馈循环（FeedbackLoop）：通过循环调用LLM，ReAct模式在每一步都根据最新的观察结果更新思考。这个循环直到达到答案结束条件（例如生成最终答案或达到步数限制）。

下面是 ReAct 模式的组件关系示意图（架构图）：

这个图显示了 ReAct Agent 的关键结构：LLM可以读取对话记忆（包括之前的思考、行动、观察），通过工具接口调用外部资源，并将工具的输出作为新的输入。由于所有思考和决策都在 LLM 内完成，ReAct并没有额外的专门策划器或评估器；其"规划"和"评估"都是通过连续调用 LLM 来隐式实现的。

执行流程

ReAct 模式的运行时流程可按以下步骤描述：

用户输入（UserInput）：用户提出自然语言查询或任务指令，作为 Agent 的初始输入。例如："请告诉我最近美国的气温是多少？"。
LLM 生成思考与行动：将用户输入送入LLM，模型输出一段新的文本，该文本通常包括两部分交替出现------一部分是"思考（Thought）"，说明当前判断或下一步策略，另一部分可能是"行动（Action）"，指定要执行的具体工具调用或指令。例如：

Thought: 美国的天气数据可能在气象局网站可以找到。

Action: Search("latest temperature in USA")（调用搜索工具）

执行工具调用 ：Agent接收到 LLM 输出的行动指令后，调用相应的工具接口。若是Search(...)，则向搜索引擎发起查询；若是Math(...)，则调用计算器等。工具执行后返回**观察（Observation）**结果，比如网页摘要或计算结果。
更新思考循环 ：将观察结果添加到对话上下文中，再次调用LLM。此时 LLM 可以看到之前的思考、行动及观察记录，从而**"更新"思考**，决定下一步。例如，观察到温度是 22°C 后，模型继续生成：

Observation: "Latest temperature in USA is 22°C."

Thought: 温度已找到，我们可以继续回答其他问题或直接给出答案。

检查终止条件：重复步骤2-4，形成"思考 → 行动 → 观察"的循环。Agent会在某一轮判断当前信息足够或已到达预设步数时停止循环，输出最终答案。这可以在 LLM 的输出中通过特定的标记或由外部逻辑检测到。

整个执行流程如图所示：

示例伪代码（Python风格）：

复制代码

context = "用户的初始查询"for _ in range(max_steps): response = LLM.generate(context) # 模型生成包含 Thought 和 Action 的回答 thought, action = parse_response(response) if action: result = execute_tool(action) # 调用指定工具 context += f"\nObservation: {result}" # 将结果加入上下文 else: answer = response # 无需行动，模型给出答案 break

复制代码

适用场景

ReAct 模式适合以下典型场景：

复杂问答：需要结合外部资源和多步骤推理的问题，例如："请帮我查找最新的 COVID-19 疫情统计，并根据数据进行简单分析。"ReAct代理可以交替查询数据库或API，然后推理。
自动化助手：如智能客服或个人助理，需要在对话过程中执行任务（调用系统命令、检索企业知识库、调用翻译 API 等），同时对用户问题进行思考和回答。
网页浏览 / 爬虫 Agent：需要在互联网环境中执行操作的任务，如模拟用户浏览网站、抓取信息、填写表单等，通过 ReAct 方式不断生成"思考"和"下一步动作"。
游戏和任务规划：在游戏（如文本冒险）或机器人控制中，ReAct可以控制执行动作（如游戏步骤、机械臂命令），利用思考阶段规划路径。
研发辅佐：例如代码生成过程，Agent在生成代码片段后可以执行编译或单元测试，并根据错误结果反馈再次思考完善代码。

优点与局限

优点：
开放性与灵活性：ReAct 通过预定义工具接口，赋予 LLM 自主使用各种工具的能力，适应范围广。
可解释性：ReAct明确输出"思考"步骤，便于审计每一步逻辑；每次行动和观察也清晰记录，整体决策路径可读。
扩展性：只需增加工具接口，即可让 Agent 调用新能力；例如接入搜索引擎、计算器、数据库等。
人机协作：由于 ReAct 记录了每个推理步骤，方便人工干预和纠错，在出错时可手动调整思考链或行动序列。
局限：
开销和延迟：每一步都需要调用 LLM，推理链过长时成本和延迟都线性增加，实用时需限制循环次数或使用摘要记忆。
错误传播：当前思考依赖之前的决策和观测，如中间产生错误，会累积并影响后续步骤。
控制困难：LLM自主决定何时停下或如何行动难以完全控制，可能出现不必要的工具调用或停不下来的情况。
上下文膨胀：长轮次对话会使上下文变长，可能超出模型上下文窗口或导致性能下降。
稳定性：依赖模型生成的行动指令可能不可靠，需要严密的校验（如严格语法、工具名称黑白名单）以防执行错误命令。

常见失败点 / 风险点

推理链过长：ReAct链式推理往往不限制推理长度，如果任务复杂或模型犹豫不决，可能陷入无休止循环。需要工程上限制循环次数、设置时间/成本阈值。
工具调用错误：LLM可能生成无效或危险的工具调用，例如错误的 API 名称、注入恶意指令等。务必对模型输出进行解析验证，并在安全沙箱环境运行工具，防止漏洞被利用。
数据过期/检索污染：如果所用工具或知识库未更新，可能获取到过时或错误信息；也可能检索到与任务无关的数据（检索污染），误导后续推理。需要定期更新知识库，或加入检索结果质量过滤。
决策抖动：当模型在循环中连续思考时，可能由于细微的上下文差异而出现"踩刹车"现象，如前后输出思路不一致。可以通过限制 token 或使用统一的策略提示来减少抖动。
安全与隐私：ReAct允许模型在推理时访问外部数据（知识库、网络等），可能会泄露用户隐私或敏感信息，需做访问权限控制和审计。

工程实践建议

限制循环次数和步数：根据任务需求设定最大迭代次数，避免模型长时间思考。可使用简单的计数器或终止信号（如生成了"FinalAnswer"标签）。
验证动作安全性：对每一次模型生成的 Action 输出进行严格解析和验证。如工具名称和参数必须在白名单范围内，对代码指令进行语法检查，必要时运行在受限沙箱中。
适时加入人工审批：对于高风险任务（如财务决策、医疗咨询等），即便使用了ReAct，也应在关键决策节点引入人工审查环节，确保模型建议经过人工复核。
检索缓存与 并行化：如果多次查询相似问题，可缓存检索结果，减少重复调用搜索；对可并行的工具调用（如独立网页查询），可并行发送请求提高效率。
单 Agent 升级到多 Agent：当 ReAct 单一 Agent 无法胜任任务（例如需要大规模并行搜索或多角色对话）时，可考虑将任务分解给多个协作智能体（详见多智能体模式）。
监控和日志：对 ReAct Agent 应该保持详尽的日志，包括每一步的思考、行动和观察，便于事后分析和故障排查；同时监控其运行时性能和成本，及时优化。
小结：ReAct模式通过明确的思考与行动循环增强了 LLM 的工具使用能力，但其效果高度依赖模型生成质量和工具可靠度，需要在工程上做好安全控制和错误处理机制。

CodeAct 模式

模式定义

CodeAct 模式是一种将行动统一为可执行代码的 Agent 框架。简单定义：CodeAct 让 LLM 将任务转化为可执行的代码，通过代码执行来获取结果并驱动后续决策。与传统 ReAct 主要调用预设工具不同，CodeAct 将所有工具调用都抽象为 Python 代码，以代码执行的灵活性扩大了行动空间。Agent 使用 Python 解释器执行模型生成的代码，根据运行结果（输出或错误）继续生成新代码或结束任务。

一句话选型建议：当任务需要复杂计算、数据处理或组合多个工具（尤其可用现成代码库辅助）时，CodeAct更为高效可靠。

核心组成

CodeAct 模式的核心模块包括：

LLM （大语言模型）：负责根据任务提示生成代码。LLM在提示中接收任务要求和已有上下文后，输出符合语法的 Python 代码片段，这些代码即作为 Agent 的行动。
代码 执行环境 （Executor）：通常为一个隔离的 Python 解释器，用于运行 LLM 生成的代码。该环境可以加载必要的库（如NumPy、Pandas、网络请求库等），让代码拥有丰富的功能。
工具库（Libraries）：各种可调用的 Python 包和API，被视作 Agent 的工具。例如，统计分析可调用pandas、科学计算可调用SciPy、在线查询可调用 requests 等。与 ReAct 中硬编码的工具相比，这里通过代码导入现有库实现。
短期/ 长期记忆 （Memory）：运行时需要记录之前生成的代码和输出，作为上下文的一部分。每次新的 LLM 调用都会把先前的代码和结果加入提示中，让模型"记住"之前做了什么。
反馈循环（FeedbackLoop）：Agent通过执行代码并将结果反馈给LLM，然后 LLM 根据输出或异常信息更新代码计划。LLM可以根据错误提示自动调试、修改代码，形成连续对话。

CodeAct 核心结构示例如下：

该架构图显示 LLM 生成的代码由 CodeExec 执行，执行环境可以访问Libraries。执行结果或错误会被反馈给LLM（形成观察），并记入 Memory 以供下次参考。

执行流程

CodeAct 的运行流程可以描述为：

用户输入：用户给出任务描述或问题，如"请读取 data.csv 文件并计算每列的平均值"。
生成代码：将任务和之前的上下文传给LLM，模型输出一个或多个 Python 代码单元。例如：

复制代码

# 读取数据 import pandas as pd df = pd.read_csv('data.csv')

执行代码：在 Python 执行环境中运行该代码，如果代码无错误，则产生输出结果（可能是打印值或数据结构）；如果有错误（如拼写错误、路径不存在等），则返回错误信息。
结果反馈：将执行结果或错误消息追加到对话上下文，喂给 LLM 进行下一步决策。例如，如果读取成功，继续生成下一步计算代码；如果报错，则生成调试后的代码。
迭代：重复步骤 2-4。LLM 在每次新调用时都可以生成更多代码行或修改已有代码。最终，当任务完成或满足停止条件时，LLM可以输出最终答案或报告。
输出最终答案：通常 LLM 会以解释性文字形式总结结果，比如"每列均值已计算完成：X, Y, Z"。

流程图如下：

示例伪代码：

复制代码

context = "任务描述：读取 data.csv 并计算每列均值。"while True: code = LLM.generate(context) # 模型生成代码 result, error = execute_python(code) # 执行代码，返回输出或错误 if error: context += f"\nError: {error}" continue # 让模型根据错误继续调试 else: context += f"\nResult: {result}" if task_complete(result): answer = LLM.generate(context) # 根据结果生成总结 break

复制代码

适用场景

CodeAct 模式适用于以下场景：

数据分析 与可视化：需要处理表格数据、统计分析、绘图等。CodeAct让 Agent 用 pandas、matplotlib 等库编写代码，如自动生成图表并解释结果。
自动化编程：编写并执行脚本解决问题，例如自动化测试、批量文件处理、自动文档生成等。Agent生成脚本后可以即时运行检验。
复杂工具组合：任务需要组合多个操作，如"下载数据 → 调用机器学习库训练模型 → 输出结果"。在 CodeAct 中可以直接在一段代码中调动多种库和函数（利用控制流完成多步骤操作）。
科学计算与实验：需要精确数学计算或科学试验模拟，Agent可编写数学代码（SciPy、NumPy）直接执行，消除了自然语言表达的限制。
接口编程：需要调用复杂 API 或自定义库时（例如自动化软件界面、数据库操作），Agent将其转化为 Python 函数调用。
问答辅助：在需要 LLM 结果和精确计算结合的场景，如"请计算2023年1月1日至今的天数"，LLM生成计算代码并得到精确答案。

优点与局限

优点：
灵活的动作空间：由于代码几乎可以调用任何库，CodeAct 的行动空间远大于预定义工具，在复杂任务中可组合多种工具，大幅拓展能力。
自动调试与反馈：Python 解释器会返回错误信息，可供模型使用，支持自动"自我调试"，提升求解准确性。
利用预训练知识：现代 LLM 在训练时已经暴露了大量代码知识，熟悉编程模式，因此将任务转化为代码具有成本效益。
控制流程和存储结果：代码支持控制流（循环、条件）与变量存储，可以处理重复数据、存储中间结果，适合多步复杂逻辑。
局限：
安全性和隔离：执行代码带来安全风险，必须在严格的沙箱环境中运行，防止恶意代码访问敏感资源或造成破坏。
执行环境 依赖：需要预先配置运行环境（安装库、依赖管理），并确保不同环境的一致性（版本冲突可能导致错误）。
资源消耗：复杂计算或长时间运行的代码任务会消耗大量计算资源和时间，可能需要专门硬件或异步执行策略。
延迟较高：相比直接输出答案，CodeAct需要执行代码，增加了延迟。对于需要快速响应的应用，需要评估是否能接受这种额外开销。
调试难度：如果模型生成的代码结构复杂，自动调试和解析可能变得困难，需要设计良好的异常捕获和提示机制。

常见失败点 / 风险点

执行错误：模型生成的代码可能语法错误、调用不存在的函数或使用错误的参数，导致执行失败。必须解析错误并反馈给 LLM 自动修正，否则 Agent 会停滞。
环境漂移：训练时未遇到的新库或依赖可能导致代码在实际执行时出错。应保证执行环境与模型可访问到的库版本兼容。
无限循环：生成代码可能包含无限循环或耗时操作，需设置执行超时时间，避免 Agent 无响应。
输出语义漂移：模型在生成代码后再生成答案时可能忽略代码输出，而仅仅凭"思考"输出答案，需要在提示中清楚要求利用计算结果。
安全隐患：恶意利用代码执行功能（如删除文件、发送网络请求），需要严格限制所用库和系统调用权限。

工程实践建议

沙箱执行：将代码执行隔离在一个受限环境（如 Docker 容器或独立子进程），限制访问权限，避免写入或外部通信。
超时与重试：对每段代码设置最大执行时间，超时后中断并让模型简化逻辑；出错后可自动重新生成或手动审查关键部分。
输入验证：对模型输入的参数或外部文件路径进行验证，避免注入安全漏洞；尽可能只允许访问必要的数据资源。
逐步提示：向模型提供分步提示，引导它先完成基础操作（如"先导入库并读取数据"），再进行后续计算，降低一次性错误率。
定制代码 范式：建立统一的代码风格与变量命名提示，例如使用特定的模板开头import并打印结果，帮助模型生成易于解析的代码。
监控与日志：记录代码生成与执行的全过程，包括错误和输出，便于快速定位问题，并分析模型行为改进提示。
适度缓存：如果多个用户或任务共享相似操作（如使用相同的数据集），可缓存中间计算结果，加速处理和降低重复开销。
小结：CodeAct将 Agent 行动上升到代码层面，使得复杂任务可通过编程灵活完成，但对执行环境和安全要求很高，适用时需周全考虑隔离和监控等工程手段。

Agentic RAG 模式

模式定义

Agentic RAG 是将 "智能体" 引入传统 RAG 管道的框架。简单定义：Agentic RAG 允许 Agent 在检索增强生成流程中主动进行策略选择、多轮检索和结果验证，而不仅仅是一次性检索。 与传统 RAG 由静态的嵌入检索和生成组成不同，Agentic RAG 系统中，LLM Agent 可以根据查询决定检索策略（例如应该从哪些知识库检索）、改写查询、多轮检索并过滤结果，从而提高检索的灵活性和准确性。

一句话选型建议：当需要在 RAG 流程中增加自适应检索、多轮过滤或任务规划能力，或结合多种知识源时，Agentic RAG 模式是更强大的选择。

核心组成

Agentic RAG 模式主要包括以下模块：

LLM （大语言模型）：作为智能体的"大脑"，负责生成检索策略和回答内容。Agentic RAG 通常会将 LLM 用于多角色，例如生成检索查询、评估答案。
检索组件（Retriever）：包括一个或多个检索机制，如向量检索、关键词搜索、浏览器或数据库查询等。与传统 RAG 相同，用于在知识库中查找相关内容。
知识库/文档库：外部数据源，可以是企业内部文档、数据库、网络资源等。Agentic RAG 可以同时访问多个知识库，实现多源检索。
工具调用（Tools）：Agentic RAG 允许 Agent 通过函数调用或 API 获取信息，不限于文本检索。例如调用外部接口、打开文件、运行脚本等都是可能的动作。
记忆/缓存（Memory）：Agent 可能维护查询历史、检索结果缓存或交互日志，用于多轮会话中复用信息、避免重复检索。
规划器（Planner）：在复杂任务下，Agentic RAG 的 LLM 可以执行任务拆解或策略规划，例如确定要分几轮检索，每轮检索关键词如何生成等。
反馈循环：与 ReAct 类似，Agentic RAG 的 LLM 可以迭代决策。在生成初步答案后，Agent可根据需要再次检索或修改答案，直到满足准确度要求。

Agentic RAG 的模块关系示意如下：

这里 LLM 连接多个知识源和工具，通过 Retriever 从知识库中获取信息，通过 Tools 调用其他API，并将结果与 Memory 交互，用于支持下一步判断。

执行流程

Agentic RAG 模式的执行流程通常如下：

用户输入：接收自然语言查询。
Agent 规划检索：LLM根据用户意图生成检索策略。这可能包括生成查询语句、决定从哪些数据库或 API 检索等。例如：Plan: 从内部文档库和网络搜索中分别检索信息。
多源检索 ：根据策略调用 Retriever 工具，同时或分步骤地进行查询。Agentic RAG 支持从多个知识库检索，比如既搜索企业知识库，也查询网络。
合并与筛选结果：Agent将多个来源的检索结果合并，必要时进一步过滤或分析。例如，LLM可以检查返回的文档是否真正回答了问题，可能会丢弃不相关内容。
答案生成：使用 LLM 将检索到的上下文整合并生成初步回答。
验证与迭代：检查答案完整性和准确性。如果发现缺漏或错误，Agent可以重新生成查询（改写query）再次检索，或者使用工具确认事实。例如，若答案需要最新数据但检索得到的是旧信息，可触发新的检索请求。
反馈循环：与用户交互式任务中，Agent可能多轮接受新需求、检索数据并更新答案。

流程图示例：

示例伪代码：

复制代码

query = user_inputfor _ in range(max_iter): strategy = LLM.generate(f"规划检索策略: {query}") documents = retrieve(strategy) # 调用多源检索 answer = LLM.generate(f"利用以下文档回答问题: {documents}\n问题: {query}") if evaluate_answer(answer): break else: query = LLM.generate(f"重新组织检索查询: {query}")

复制代码

适用场景

Agentic RAG 常见应用场景包括：

企业知识库 QA：需要搜索内部文档、报告甚至多部门知识库时。例如查询公司政策、项目文档等，Agentic RAG 能智能从多个数据源并行检索。
动态信息获取：场景需要访问不断更新的数据源，如新闻、市场行情。Agent可规划检索流程，从不同渠道获取最新资料。
研究型问答：需要深入挖掘信息的任务，如市场调研、法律法规解读。Agent可能需要多轮检索并进行摘要整合。
智能客服：面对用户提出的综合问题，客服机器人可以动态选择从知识库检索答案，同时调用后台系统接口查询订单或记录，形成复合回答。
领域垂直应用：如医疗诊断助手，需从医学文献、病例数据库检索相关信息，Agentic RAG 可以针对不同领域知识库使用不同检索策略。

优点与局限

优点：
灵活性高：Agentic RAG 支持多源数据检索和工具调用，能更灵活地应对各种知识获取需求。
自适应性：相比静态查询，Agentic RAG 可以根据检索结果调整策略（改写查询、增加检索范围），从而提升结果准确率。
增强准确度：通过迭代检索和答案优化，Agentic RAG 系统在生成答案前可以多次校验并优化上下文，理论上比单次 RAG 准确。
可扩展性：添加新的数据源（知识库）或工具时，只需在 Agent 中配置即可，提高系统拓展灵活性。
适应多模态：现代多模态模型可同时处理文本、图像等，Agentic RAG 可以检索包括图像、音频等多媒体信息，为答案提供更丰富的背景。
局限：
计算和经济成本：引入 Agent 规划和多轮 LLM 调用显著增加了计算负担和使用成本。多Agent协作架构更是需要大量 tokens。
延迟：多次检索-生成循环增加响应时间，不适合对延迟敏感的应用场景。
可靠性挑战：复杂的多Agent交互容易出现协调失败、资源竞争（例如多个 Agent 同时访问同一数据源）等问题。
实现复杂度高：系统需要管理多个知识库、缓存、查询逻辑，开发和维护成本较高，尤其需要良好的检索和缓存策略设计。
幻觉风险：虽然多次检索有助于减少幻觉，但依旧无法完全避免，系统依赖模型正确地判断检索结果的相关性和准确性。

常见失败点 / 风险点

检索污染：Agent可能检索到与问题无关或误导性的文档，特别是在查询改写不完善时。需要对检索结果做严格评估和筛选。
上下文膨胀：多轮检索和对话积累会产生大量文本，超出模型上下文窗口，必须使用精心设计的策略（如精简提示、历史摘要）管理上下文。
过度依赖模型判断：Agent在每轮需要判断检索是否充分并自发修改查询，这些决策依赖模型产生。若模型判断不当（例如认为答案已充分但其实不全），可能提前终止循环，影响结果质量。
系统复杂度：多Agent或多阶段管线更容易出错。例如一个专门的检索 Agent 可能产生分歧，或者协作架构中 Agent 之间通信失败。
成本失控：没有合适控制时，多轮检索和生成可能消耗过多tokens，造成费用激增。工程上要设置预算和监控。

工程实践建议

检索策略设计：根据业务场景设计检索策略，如先本地知识库再外部网络、或按主题分阶段检索。可在提示中明确要求检索范围和数量限制。
查询改写与多轮检索：在初始检索基础上，对未回答的部分自动改写查询，再做深度检索；同时避免不必要的重复检索。
语义缓存：实现检索结果缓存，对重复或相似查询直接复用结果，提高效率并减少成本。结合长短期记忆，保留对话历史中的有效信息。
工具和 Agent 分工：大型系统可采用多智能体协作，将检索任务分配给专门的检索子Agent，规划任务由主 Agent 负责，避免单一 Agent 过度负载。
并行 化检索：当需要多个来源信息时，可并行进行检索，然后在结果汇总阶段使用 LLM 做整合或评估。
人工评估阈值：对于关键答案，可设定可信度阈值，低于阈值时启用人类审核环节，尤其在法律、医疗等敏感领域要确保安全。
小结：Agentic RAG 通过让 Agent 在 RAG 流程中主动规划和迭代，显著增强了检索的灵活性和答案质量。但其复杂度和成本也高，需要工程上精心设计查询策略、缓存机制以及成本控制。

Self-Reflection 模式

模式定义

Self-Reflection （自我反思）模式指的是让 Agent 在初次生成答案后，对自己的输出进行检验、评估，并根据反馈修正答案的一种机制。一句话定义：Self-Reflection 模式中，Agent 在完成一轮输出后"冷静审视"自己的回答，将其作为输入再进行评估和优化。与普通的单次推理不同，这种模式引入额外的"反思"阶段，帮助模型找到并修正潜在的错误、遗漏或不严谨之处。

一句话选型建议：在对结果质量和准确性要求很高的场景（如法律问答、 技术报告 、代码生成等）中，加入自我反思可以显著提升最终答案的严谨度。

核心组成

Self-Reflection 模式通常包括以下模块：

LLM 生成器（Generator）：生成初步答案或输出。这一角色可以是和普通对话模式相同的模型调用。
评审器 / 反思器（Reflector/Critic）：负责检查和评估生成器的输出。这可以是另一个 LLM 实例（不同 prompt 下扮演"审查员"角色），也可以是同一个模型通过特殊提示来进行自问自答。
记忆/上下文：至少包含初步生成的内容，以及与之相关的提示或检索到的信息，供评审器参考。评审器有时也会访问外部工具验证事实（如搜索数据库、用正则检查语法等）。
反馈循环：评审器对初步输出进行反馈后，Generator根据评审结果再次生成答案或修改部分内容。这个过程可以多轮进行，直到满足停止条件。
终止决策：评审器一般会判断当前版本是否达到质量标准，当达到或超过预设轮次时停止循环。

模式结构示意图如下：

执行流程

Self-Reflection 模式典型的执行步骤为：

用户输入：接收用户的查询或任务。
第一次生成：Generator LLM 根据输入生成初步答案（草稿）。例如回答问题、写一段文档、生成代码片段等。
自我评审：将该初稿作为评审输入传给 Reflector LLM，要求它扮演"审阅者"，批判性地审查答案的各个方面，指出错误、不足或可改进之处。评审过程中可以要求列出"错误/缺失的要点"或"可能的证据"。
生成改进：Reflector输出反馈后，将反馈内容和原答案一同作为新提示，再次调用 Generator LLM 进行修改或重写，生成改进版答案。
迭代：可选择继续多轮反思，如果需要进一步提高质量，则Generator再次产出新答案，然后再让 Reflector 审查。循环直到满足质量要求或达到预设轮数。
输出最终答案：将最后一次 Generator 的输出作为结果返回给用户。

流程图示例：

示例伪代码：

复制代码

draft = LLM.generate(user_input) # 第一次生成初稿for i in range(max_iter): feedback = LLM_reflector.generate(f"请审查以下回答并指出错误: {draft}") new_answer = LLM.generate(f"根据反馈优化答案: {draft}\n反馈: {feedback}") draft = new_answer if not need_more_reflection(feedback): breakanswer = draft

复制代码

适用场景

Self-Reflection 模式适合以下场景：

内容生成与校对：如写文章、报告、产品说明时，初稿生成后让模型自我校对，用更严谨的语言或加入遗漏的观点。
技术代码生成：生成代码后，让模型检查潜在错误、边界情况、最佳实践等，自动改进；或者先生成代码框架，再审查逻辑完整性。
复杂推理答题：在回答数学、逻辑题或专业问答时，让模型检查其思路的合理性与结果的正确性，避免简单"错误+自信"。
法律/医学领域问答：要求准确无误的答案时，通过自检减少错误；或者生成初步解释后让模型指出论据不足的部分。
多模态校验：可以让模型审查生成的图片描述、一段对话等是否符合事实或上下文一致性，依赖额外信息做理性判断。

优点与局限

优点：
提高质量和准确性：反思可以修正初稿中疏漏或错误，从而显著提升最终输出的可靠性。
应对偏差：模型在检索到噪声或知识不足时，反思阶段可以扮演"质疑者"角色，帮助排除幻觉信息，提高答案可信度。
灵活多样的反馈来源：反思不仅限于同一模型内部，可以调用其他工具/知识库验证事实（例如再检索一次事实），增加答案严谨性。
扮演多角色：通过不同的提示，反思者可以扮演老师、专家、批评者等角色，以不同视角审视答案，提高改进效果。
局限：
计算开销：多一轮 Generator+Reflector 意味着至少两次模型调用，若设多轮，成本迅速上升，不适合高并发或低延迟需求场景。
反馈质量不一定可信：模型自身的反思可能也会有偏差。如果模型的自我评估能力不足（可能倾向自我肯定），反思效果有限，有时甚至误导。
过度反思风险：无限迭代可能导致所谓"模型思考循环"，并不一定每次都有效提升，反而可能使输出漂移或耗时过长。
复杂度增加：需要额外设计评估提示，判断何时停止反思，同时维护两套角色可能增加系统复杂度。

常见失败点 / 风险点

自我评估不准确：模型可能对自己的错误视而不见，尤其是缺乏外部知识时，反思环节可能会强化错误的结论而非纠正。
迭代无终点：没有有效终止标准时，可能出现无限迭代；需要通过设置反思次数上限或质量判断机制来防止"死循环"。
反馈引入新错误：模型在尝试修改输出时可能引入新的错误或逻辑不一致，需要监控改进后的答案是否实际改进了质量。
成本失控：在关键任务中盲目开启多轮反思会消耗大量token，需结合经济评估决定反思轮次。
提示误导：若反思提示（Prompt）设计不合理，可能引导模型关注错误的方向。例如，让模型"找出错误"时反而可能遗漏要点，需仔细设计评估标准。

工程实践建议

限制反思轮数：通常设置 1-2 轮足矣，避免过度迭代。可根据答案改进情况自动决定是否继续（如通过评分机制判断是否需要再反思）。
多样化提示和角色：可以让反思者扮演不同角色，如"审稿人"、"专家"或使用不同的视角来检验结果，多角度反馈往往更有价值。
结合外部信息：在反思过程中尽量给模型提供事实来源或检索能力，避免纯粹凭空批判。例如让模型查询知识库确认事实后再评估答案。
自动评估函数：对反思结果应用自动评分（如BLEU、事实正确性检验）帮助判断是否真的改进，避免主观性过强。
人工审核：对于关键输出，可把反思结果作为建议，再经人工快速过目，利用人机结合保证质量。
小结：Self-Reflection通过让模型审视自己的输出大幅提升了回答精度，但需要平衡好质量收益与额外成本，同时谨慎设计评价和结束策略。

Multi-Agent Planner 模式

模式定义

Multi-Agent Planner 模式是将一个复杂任务拆分给多个智能体协同完成，并通过一个"主控"或"协同者"统一调度的架构。定义：多智能体规划模式将任务分解为多个子任务，分配给多个具有不同职责的 Agent（执行者、检查者等） 并行 处理，同时使用调度 Agent（Orchestrator/Planner）来整合结果和反馈。简单来说，它通过分工合作将大问题变为小问题，各个智能体（可视为具有专门工具和知识的 LLM）并行运行，再由统筹智能体汇总和最终决策。

一句话选型建议：当单一 Agent 难以应对任务规模（需要大规模搜索或 并行 执行）或任务本身需要不同角色协作时，就需要使用多 智能体 架构。

核心组成

Multi-Agent Planner 架构典型包括以下组件：

Orchestrator/Planner（主调度Agent）：全局负责规划和分配任务，对用户请求进行解读、生成子任务，然后将子任务下发给不同子Agent。它还负责收集各子 Agent 的结果、整合输出并做最终决策。
Sub-Agents（子 智能体 ）：多个并行工作的Agent，每个 Agent 可能有不同能力或工具集。常见角色包括：
执行Agent（Executor）：具体完成某一子任务的Agent，如特定领域 QA Agent、代码执行 Agent 等。
检索 Agent：专门负责信息检索的Agent，可能针对某个知识源。
评估/批判Agent（Critic）：检查其他 Agent 输出的正确性和质量，或作为纠错者存在。
技能Agent/子系统：具备特定技能的Agent，如数据分析Agent、图像处理Agent、写作 Agent 等。
通信机制（Communication）：Agent之间的信息传递方式，如消息传递、共享记忆库、API调用等，用于传递任务、结果和反馈。
共享/独立记忆 ：不同 Agent 可能有各自的短期记忆，也可能访问共享知识库或上下文。记忆帮助 Agent 记住任务进展、上下文和历史，以便协同工作。
工具与环境：各 Agent 可以使用自己的工具集合，视其角色而定。例如，研究型 Agent 可以调用搜索工具，代码 Agent 使用 Python 环境，数据 Agent 使用统计库等。
反馈循环：多 Agent 系统通过通信和反馈实现迭代。主 Agent 可以根据子 Agent 的反馈调整策略，子 Agent 之间也可以通过中介交流信息。

一个典型多智能体系统的架构示意图（三个Agent，带监督）如下：

用户请求由 Orchestrator 接收并下发。
Orchestrator 将子任务交给 Executor (执行Agent)。
Executor 调用 Tools 完成子任务，并结果交给 Critic 。
Critic 将评审或补充信息反馈给 Orchestrator。
Orchestrator 汇总信息后输出结果。Memory可以供 Orchestrator 和 Executor 共享，以保存任务状态或上下文。

执行流程

Multi-Agent 模式的执行流程可以描述为：

任务分解：Orchestrator 接收用户请求后，分析任务需求并分解成多个子任务。通常根据任务规模、功能模块化原则，可能分为检索、分析、决策等不同子任务。示例：对于"调研公司竞争对手"这样的任务，Orchestrator 可能分配一个 Agent 去爬取竞争对手网站信息，一个 Agent 去分析社交媒体数据，另一个 Agent 去撰写报告。
任务分配：Orchestrator将子任务指派给对应的Sub-Agents，每个 Agent 负责自己的任务域。这些 Agents 可以同时运行，使用各自的工具和知识库。
并行执行：各 Sub-Agents 并行执行自己的任务。例如一个搜索 Agent 在后台并行搜索查询，另一个数据 Agent 同时分析表格数据。
结果收集：Sub-Agents完成任务后，将结果返回给Orchestrator。这可能是答案、文档摘要、数据可视化等。
整合与反馈：Orchestrator收集各 Agent 的输出，对结果进行汇总、决策或进一步加工。根据需要，它还可以决定是否生成新的子任务或要求某个 Agent 重新运行（例如发现信息不足时）。
最终输出：整合后的结果即为系统回答或完成的任务输出，返回给用户。

示意流程图：

适用场景

多智能体规划模式适用于以下情形：

大规模知识探索：如科研自动化（Anthropic 研究系统）、市场调研等场景，需要并行检索多个主题、搜索渠道，单个Agent无法在有限上下文同时完成。通过子Agent并行工作，加速处理。
多领域协作 ：任务包含多种性质的子任务，比如一个项目包括需求分析、设计、编码和测试，可由需求Agent、设计Agent、开发Agent、测试 Agent 各自负责，然后统筹Agent整合成果。
高并发任务：批量化或流程化任务，比如同时处理多用户请求或并行执行不同流程时，Agent并行执行可显著提升吞吐量。
分布式 团队开发：不同团队维护不同Agent，使得开发协作更加模块化和并行化，维护边界清晰。
复杂交互任务：如智能对话系统中，一个任务需要同时获取图像、文本和知识库信息，可以让多种专家型Agent分别处理不同模态的数据，再由 Orchestrator 整合。
创作协同：多名创作者协同写作时，不同 Agent 分工（故事大纲、角色对话、文风润色）也可类比多智能体协作。

优点与局限

优点：
高并行性能：通过并行子 Agent，可以在多个上下文窗口同时工作，克服单个 LLM 的上下文容量限制。
分工合作：不同 Agent 拥有不同专长（工具、知识、策略等），完成任务更高效。系统本质上模拟了人类团队协作。
可扩展性：新增功能只需添加新Agent，易于扩展系统功能或服务更多场景。
弹性与 鲁棒：一个 Agent 失败时其它 Agent 仍可继续，降低单点故障；可以动态调整子任务或增减 Agent。
应用价值：在 Anthropic 等内部评测中，多 Agent 系统在复杂研究任务上效果远超单 Agent。
局限：
成本极高：运行多个 LLM 实例并发工作需要大量算力和 Token，令成本成倍增长。
复杂度与协调难度：设计合适的角色分工、消息格式、同步机制极具挑战性，通信不畅可能导致结果不一致或丢失。
延迟问题：尽管并行减少了串行步骤时间，但需要协调和合并结果，控制逻辑复杂也可能带来不确定延迟。
过度拆分风险：并非所有任务都适合并行拆分。过度细分可能反而增加总计算（重复工作）和沟通开销。
数据一致性：多个 Agent 访问共享资源时需协调，防止冲突；Agent间的知识共享和记忆管理复杂，需要额外基础设施（如共享数据库）。

常见失败点 / 风险点

协作成本过高：如 Anthropic 所述，多 Agent 模式耗费 ~15× 的 Token，经济成本显著。如果任务价值低于成本，就不划算。
角色重叠或冲突：不同 Agent 可能做相似事情或产生竞争，如两个检索 Agent 同时查相同内容浪费资源。需要清晰的角色定义和资源锁机制。
通信冗余与延迟：频繁的信息交换（提问-回答-反馈）带来通信延迟和同步难题。设计时需精简通信协议，只传必需的信息。
集中化故障：Orchestrator作为大脑，如果设计不当会成为瓶颈，一旦崩溃或逻辑出错将导致整个系统失效。
监控和调试困难：多 Agent 系统运行轨迹复杂，可观测性降低。必须有完善的日志和可视化工具帮助跟踪各 Agent 的行为。

工程实践建议

从单 Agent 开始：任务初期可先用单 Agent 验证基本逻辑，待需求增长或单 Agent 无法满足时，再考虑逐步拆分成多 Agent。
明确分工：在设计阶段明确每个子 Agent 的职责和接口，避免重复功能。可采用"技能树"方式，每个 Agent 有明确的工具集和服务领域。
层次化管理：如果任务特别复杂，考虑层次化Agent，顶层 Agent 规划总体策略，叶子 Agent 处理具体子任务。层次结构可减少单层Agent数量和通信量。
轻量通信协议：使用结构化消息（如JSON）在 Agent 之间通信，标准化输入输出格式，便于数据解析和错误检测。
并行 执行与 批处理：尽量利用并发技术，将独立子任务并行执行，减少总体延迟。对结果合并阶段也可并行地进行初步预处理。
监控与限流：对多 Agent 系统应做好资源监控，必要时限流或垂直扩展。可以对 Agent 数量、Token使用进行上限设置，防止意外暴涨。
容错设计：为关键子 Agent 提供重试机制或降级方案，一个子任务失败时可以由其它 Agent 接管或由 Orchestrator 手动介入。
小结：多智能体模式在应对大规模并行和团队式任务时优势明显，但复杂度和成本也是最夸张的。工程上要权衡收益，确保任务价值能够 justify 多 Agent 的开销。

第三部分：5种模式横向对比

以下对比表从多个维度总结了 5 种模式的核心特点和差异。可以帮助读者快速判断不同模式在特定场景下的适用性和权衡。

|---------------------|-----------|-----------|--------|--------|------|--------|----------------------|----------------------|-------|---------|---------------------|
| 模式 | 核心思想 | 依赖工具 | 依赖代码执行 | 依赖知识检索 | 反思机制 | 多智能体协作 | 典型优点 | 典型缺点 | 实现复杂度 | 系统成本 | 适合任务类型 |
| ReAct | 思考-行动闭环 | 有工具 | 否 | 可选 | 否 | 否 | 简洁灵活，可解释；支持工具调用 | 链长延迟高，错误传播；单上下文 | 中 | 中等 | 多步骤决策、工具调用任务（查询+行动） |
| CodeAct | 代码即行动 | 代码执行环境 | 是 | 可通过代码 | 否 | 否 | 行动空间大，可组合工具和控制流；自动调试 | 安全风险大，环境依赖，延迟高；实现复杂 | 高 | 高（计算资源） | 复杂计算/数据分析、自动化编程任务 |
| Agentic RAG | 智能体主动检索 | 有工具 | 可选 | 强依赖 | 部分 | 单Agent | 检索灵活可多源，多轮优化；自适应查询 | 成本高、延迟高；实现复杂；可能冗余检索 | 高 | 中高 | 高质量知识问答、动态信息检索任务 |
| Self-Reflection | 自我评审和修正 | 否（或可用外检索） | 否 | 可选 | 是 | 否 | 提高答案质量；可捕获细节错误 | 成本高（多次LLM调用）；自评可信度问题 | 中 | 中高 | 要求高准确性/严谨性的输出任务 |
| Multi-Agent Planner | 任务拆分+并行协作 | 有工具 | 可选 | 可选 | 可选 | 是 | 并行处理，大规模扩展；分工协作 | 极高复杂度和成本；协调难度大 | 非常高 | 非常高 | 规模巨大或复杂流程任务（研究、项目） |

是否依赖工具：指是否需要调用外部工具/API。例如，ReAct、Agentic RAG 和多智能体模式中各Agent通常会调用工具。
是否依赖代码执行：CodeAct明显依赖 Python 代码执行，其它模式一般不强制需要。
是否依赖知识检索：Agentic RAG 强调检索（尤其多源）；ReAct可选用检索工具；Self-Reflect、CodeAct可结合检索或不依赖。
是否有反思机制：Self-Reflection模式本身强调反思；其他模式通常没有独立的反思模块，但也可以结合。
是否多 智能体 协作：只有 Multi-Agent 需要多个Agent协作，其它模式基本是单Agent循环体系。
实现复杂度、系统成本：由简单到复杂排序可近似为 ReAct < Self-Reflect < CodeAct/Agentic RAG < Multi-Agent；成本亦是类似趋势。

第四部分：这些模式如何组合

在实际工程中，往往需要将多种模式的优点结合起来，形成复合式 Agent 架构。常见的组合方式包括：

ReAct + Agentic RAG：在 Agentic RAG 的基础上，Agent不仅进行多轮智能检索，还在每次检索后插入思考-行动循环。即每当需要获取外部信息，Agent先思考应该执行什么操作，再通过工具获取数据，再回到思考。这个组合可以让检索更加智能。例如，对复杂查询使用 ReAct 思维决定搜索关键词，然后执行检索工具获取结果。
CodeAct + Self-Reflection：先用 CodeAct 生成和执行代码，得到初步计算结果后，引入 Self-Reflection 让 Agent 审查代码输出的合理性。若评审发现偏差，Agent可自动调整代码。例如数据分析 Agent 先写统计代码，再检验结果是否符合预期，最后输出解释。
Agentic RAG + Self-Reflection：在多轮检索生成答案后，再让 Agent 反思答案的质量。这可以减少 RAG 过程中的幻觉，例如检索到的信息可能有矛盾，反思者能够标注并剔除错误片段，最终输出更干净可靠的答案。
Multi-Agent + RAG + Tool Use + Memory：实际多智能体系统通常需要检索、工具调用和记忆支持。例如研究型 Agent 体系中，多个检索 Agent、分析 Agent 并行工作，Orchestrator 调用知识库（Memory）和计算工具（Tools），结合 Agentic RAG 机制不断迭代。
Planner Agent + Executor Agent + Critic Agent 协作：如前面架构图所示，规划者生成任务和分配子任务，执行者完成子任务并产生输出，审查者检查输出的正确性，形成一个端到端闭环。

每种组合的优劣：结合了多个模式的优势，但也带来了更大的复杂度和成本。例如 ReAct+RAG 能更灵活地检索，但实现时需要让 Agent 同时处理多轮思考和检索；CodeAct+Reflection提高了代码结果可信度，但每步代码生成都伴随一次额外的审查；多模式混合通常需要更复杂的 Orchestrator 控制逻辑。

下图给出了一个典型的复合式 Agent 架构示意，结合了规划Agent、执行 Agent 与审查Agent，以及知识库和执行工具。该架构整合了上述多种模式：调度器负责整体规划（类似 Agentic RAG 中的规划功能），执行者可使用 ReAct/CodeAct 调用工具或执行代码，审查者则执行自我反思和质量控制。

组合收益：

系统更加智能和可靠，能针对不同子任务使用最适合的模式和工具。
减少单一模式盲区，例如 ReAct+RAG 可覆盖多源检索又保留细粒度思考。
通过审查 Agent 增强质量控制。

组合代价：

设计和实现极其复杂，需要精心协调各模块接口和交互协议。
需要更大算力和更多 API 调用，成本显著提高。
调试困难，需要完善监控和日志来跟踪每个子系统的运行状态。

第五部分：如何做技术选型

在实际项目中，如何决定采用哪种模式？下面给出一个模式选型决策表和流程示意，帮助做出权衡。

模式选型决策表

|-------------------|------|-------|---------|-----------------|-------------|---|---|---|---|---|---|
| 场景/需求 | RAG | ReAct | CodeAct | Self-Reflection | Multi-Agent | | | | | | |
| 只需返回单条事实答案（非复杂流程） | ✅ 推荐 | ✅ 可选 | ❌ | ❌ | ❌ | | | | | | |
| 需要调用外部工具或 API | ❌ | ✅ 推荐 | ✅ 推荐 | ✅ 辅助 | ❌ | | | | | | |
| 需要编写/执行代码或复杂数据处理 | ❌ | ❌ | ✅ 推荐 | ✅ 辅助 | ❌ | | | | | | |
| 需要多轮查询、多源检索或知识库集成 | ✅ 可行 | ✅ 可行 | ❌ | ✅ 可辅助 | ✅ 可组合 | | | | | | |
| 对答案准确性要求极高（错误成本大） | ❌ | ✅ 可辅助 | ✅ 可辅助 | ✅ 推荐 | ✅ 可组合 | | | | | | |
| 任务高度复杂、可分解或需要并行处理 | ❌ | ❌ | ❌ | ❌ | ✅ 推荐 | | | | | | |
| 预算有限、延迟敏感 | ✅ 推荐 | ✅ 可选 | ❌ | ❌ | ❌ | | | | | | |
| 高实时性与低成本优先 | ✅ 推荐 | ✅ 可选 | ❌ | ❌ | ❌ | | | | | | |

说明：

RAG：场景简单、单一查询或知识问答时成本最低、延迟最低，是首选。
ReAct：适合需要工具调用、适度交互的任务，预算充足时使用效果好。
CodeAct：适合需要大量计算或代码操作的任务，对延迟和资源要求高时才选择。
Self-Reflection：适用于质量要求极高的输出，可在其他模式基础上添加，用来提升精度。
Multi-Agent：只有在任务本身足够大、收益远超成本时才使用，否则复杂度过高。

选型流程图

以下流程图引导在不同条件下选择合适模式：

该流程逻辑为：1. 首先判断是否需要外部知识检索 。如果不需要，则视作纯推理或工具调用。2. 若需要检索，则问是否需要多轮或多源检索 。如果不需要，可以选传统RAG，否则进入工具调用判断。3. 判断是否需要调用工具或代码执行 。如果不需要，则选 RAG/Agentic RAG；若需要，则进一步判断是否需要生成或执行代码 。4. 如果需要编写代码，则使用CodeAct；否则使用 ReAct/Agentic RAG（依赖工具和检索）。5. 根据精度要求决定是否加入自我反思环节（Self-Reflection）。6. 最后，评估任务是否足够复杂且并行需求高，如果是，则考虑升级到Multi-Agent。否则单智能体即可。

第六部分：完整 Agent 系统案例

下面以一个企业知识问答 + 数据分析 + 报告生成的复合 Agent 系统为例，说明如何综合应用上述模式。假设用户询问："帮我分析上季度销售数据并生成报告，包括对业绩的总结和下一季度的预测。"

系统架构

系统由一个**主调度Agent（Orchestrator）**控制，下面有多个子系统：

知识检索 Agent（使用 RAG/Agentic RAG）：查询企业知识库中关于产品、市场的相关文档。
数据分析 Agent（使用CodeAct）：读取公司销售数据库，使用 Python 执行数据汇总、统计和简单预测。
报告生成 Agent（LLM）：综合前两者结果，生成自然语言报告。
自我评审 Agent（Self-Reflection）：对初步报告进行校对和完善。
共享记忆/知识库：用于存储策略、上下文和用户偏好。
工具与环境：包括企业内部数据库、文档系统、Python执行环境等。

下图展示该系统的总体架构：

流程说明：
用户发起请求后，Orchestrator首先将查询路由给知识检索 Agent 和数据分析 Agent。
知识检索 Agent：以关键词检索内部知识库（Agentic RAG），获取产品信息、市场趋势等支持信息。
数据分析 Agent：进入 Python 环境，执行代码加载销售数据库 (DB)，计算如总销售额、增长率、热门产品等，并尝试简单预测模型（CodeAct）。
Orchestrator 收到两个 Agent 的中期结果后，将它们合并作为上下文，交给报告生成 Agent。
报告生成 Agent：基于检索文本和分析数据撰写报告草稿（ReAct/RAG结合）。
审查 Agent：接着对报告草稿进行自我审查（Self-Reflection），指出不准确或遗漏之处，并让生成 Agent 改进。
最终，Orchestrator收到完善后的报告，进行最终审阅并输出给用户。

端到端执行流程

下面是一个序列图示例，说明上述步骤的具体执行：

知识检索阶段：调度Agent触发检索Agent，后者从知识库中获取必要文档摘要，帮助回答市场相关问题。
数据分析 阶段：调度Agent调用数据Agent，Agent在 Python 环境执行代码（CodeAct），计算销售数据指标。
报告生成阶段：结合市场信息和数据分析结果，报告Agent生成文本报告草稿。
审查完善阶段：审查Agent对草稿进行反思检查（自我反思），提出修正，最终生成改进报告。
输出：调度Agent将最终版报告返回给用户。

这种复合 Agent 系统使用了多种模式组合：Agentic RAG + CodeAct + ReAct + Self-Reflection，利用它们各自优势来满足综合需求，难以由单一模式完成。例如：知识查阅用 Agentic RAG，多数据分析用 CodeAct，报告撰写用 ReAct，最终质量保证用 Self-Reflection。

结语

本篇文章系统梳理了五种主流的 AI Agent 设计模式：ReAct、CodeAct、Agentic RAG、Self-Reflection 以及 Multi-Agent Planner。它们的本质区别在于控制结构和行动空间：ReAct强调"思考---行动"闭环，CodeAct将行动升华为可编程代码，Agentic RAG 在检索上引入智能规划，Self-Reflection通过自评与修正提高输出质量，多智能体通过分工并行扩展处理能力。

我们强调，Agent设计的核心不是简单地"堆叠功能"，而是围绕任务设计闭环的控制结构。如同软件架构，模式决定了信息和决策流向。实际系统中往往需要混合这些模式，以在准确性、效率、成本之间取得平衡。对于未来，可以预见 Agent 系统将更多集成长期记忆 与上下文管理、多样化工具库、模型上下文协议（如MCP）、长运行任务支持以及多 智能体 编排等能力，使其更贴近复杂现实问题的需求。