文章目录
- [AI Agent 架构详解：从 ReAct、规划执行到多智能体协作](#AI Agent 架构详解：从 ReAct、规划执行到多智能体协作)
-
- [一、概念边界：Agent 与 Workflow 怎样区分？](#一、概念边界：Agent 与 Workflow 怎样区分？)
- [二、执行范式：ReAct 与 Plan-and-Execute](#二、执行范式：ReAct 与 Plan-and-Execute)
-
- [2.1 ReAct：根据观察结果逐步推进](#2.1 ReAct：根据观察结果逐步推进)
- [2.2 Plan-and-Execute：显式规划，并根据反馈调整](#2.2 Plan-and-Execute：显式规划，并根据反馈调整)
- [三、协作方式：Multi-Agent 如何分工？](#三、协作方式：Multi-Agent 如何分工？)
- 四、架构扩展：叠加能力后形成哪些组合？
- 五、选型：新增结构要解决什么问题？
- [六、OpsArk 运维智能体(https://blog.csdn.net/weixin_44431812/article/details/167039023?fromshare=blogdetail\&sharetype=blogdetail\&sharerId=167039023\&sharerefer=PC\&sharesource=weixin_44431812\&sharefrom=from_link) 案例：规划、执行控制与证据如何配合？](#六、OpsArk 运维智能体 案例：规划、执行控制与证据如何配合？)
AI Agent 架构详解：从 ReAct、规划执行到多智能体协作
介绍 Agent 架构，最需要回答四个问题：谁决定下一步、谁执行动作、信息怎样保存、什么条件允许任务结束。
ReAct、Plan-and-Execute 和 Multi-Agent 经常被并列介绍，但前两者主要描述任务如何推进，后者描述多个 Agent 如何协作。工具、记忆和反思则可以与它们组合。
本文聚焦大模型驱动的 Agent，先建立分类框架，再结合运维产品 OpsArk 解释工程实现。各节视频直接展示完整结构，再用快速高亮说明路径；静态封面也能独立阅读。
了解OpsArk ，请看这篇文章：设计 OpsArk 运维智能体：从一句需求，到一项可验收的任务
体验OpsArk ，请到官网：OpsArk官网
一、概念边界：Agent 与 Workflow 怎样区分？
Agent 围绕目标，在授权范围内根据环境反馈动态决定后续行动。模型提出行动，运行时执行获准操作，再把实际结果带回决策过程。
Workflow 主要通过预定义代码路径组织模型与工具；Agent 则更多由模型决定过程和工具使用。这是 Anthropic 提出的一种实用区分，不是全行业唯一标准。参考：Building effective agents
例如，"检查配置 → 审批 → 部署 → 健康检查"可以是工作流；根据异常自主选择查日志、端口或依赖，则体现了 Agent 的动态决策。工作流也能嵌入 Agent，Agent 外层也需要代码管理状态。判断重点是决策权的范围，不能只看有没有模型或分支。
图 1：执行范式、协作方式和能力机制可以组合。Workflow 单独作为对照与组合方式。
二、执行范式：ReAct 与 Plan-and-Execute
2.1 ReAct：根据观察结果逐步推进
ReAct 将推理与行动交替组织，通过外部观察更新后续判断。工程介绍中常用以下循环概括它，但采用相似循环不代表完整复现原论文的提示方法。ReAct 原论文
决策 → 工具执行 → 观察结果 → 再决策，直到完成或触发停止条件。
图2：观察返回决策环节，目标达成后输出结果；权限、预算等其他停止分支在视频中省略。
Agent框架-ReAct：根据观察结果逐步推进
以"检查服务无法访问的原因，先排查，不修改配置"为例：先查服务状态，再根据结果选择检查端口或请求链路。下一步由新信息决定。
这种模式适合路径不确定、需要现场探索的任务，不限于简单查询，也不排斥子目标和长期记忆。代价是可能重复尝试、陷入局部修复或积累过多上下文，需要记录已完成工作，控制预算与停止条件。
可观测性应提供动作依据、参数、执行回执和状态变化；是否展示完整推理文字，不是判断这种架构的标准。
2.2 Plan-and-Execute：显式规划，并根据反馈调整
规划执行将"制订计划"和"落实步骤"分成两个职责。计划可以覆盖完整任务，也可以只覆盖当前信息足够支持的阶段；执行后根据反馈选择完成、继续或重新规划。参考：Plan-and-Execute Agents
目标 → 规划 → 执行 → 检查反馈 → 完成、继续执行或重规划。
Agent框架-Plan-and-Execute规划执行架构
图 3：反馈决定后续路径。规划器与执行器是职责划分，不要求由不同 Agent 承担。
例如部署前检查发现端口已有监听：检查命令可能成功运行，但仍需核对绑定地址、资源归属和复用条件，必要时调整剩余计划。动作成功不等于目标达成，规划执行也不意味着计划不可修改。
它适合有阶段依赖或计划审阅需求的任务，代价是维护计划与实际状态的一致性。重规划应保留用户约束、已执行事实和未完成目标；新计划不能改写历史，也不能自动扩展操作授权。执行阶段内部仍可使用 ReAct 循环。
三、协作方式：Multi-Agent 如何分工？
Multi-Agent 描述多个 Agent 之间的职责、信息和控制权关系。各参与者可以有自己的上下文、工具与决策过程，再通过委派、消息或共享状态协作；不要求使用不同的基础模型。
图 3：左侧以单 Agent 多工具作为对照，中间展示主控委派与结果回传，右侧展示任务状态和控制权的交接。对等协作等其他方式见下表。
Agent框架-Multi-Agent多Agent架构
| 方式 | 运行机制 | 设计重点 |
|---|---|---|
| 主控---子 Agent | 主控委派，子 Agent 返回结果，由主控综合判断 | 子任务边界、证据、失败传播 |
| 对等协作 | 多个 Agent 按协议交换信息、共同推进 | 决策归属、冲突处理、终止条件 |
| 交接 | 当前 Agent 将任务和必要状态交给下一 Agent | 交接契约、权限、信息完整性 |
主控---子 Agent 是多 Agent 的一种分层组织方式；并行是一种执行安排，单 Agent 也能并行调用工具。路由负责选择处理者，路由到固定工具或模型本身不必然构成多 Agent。
拆分前应确认：子任务边界是否清晰，上下文是否需要隔离，结果能否核对与汇总。如果每个角色都依赖完整历史、不断同步同一状态，协作成本可能超过收益。AutoGen 支持可定制、可编程的多 Agent 对话，不能简单归为固定轮流发言。
四、架构扩展：叠加能力后形成哪些组合？
前文分别介绍了任务如何推进、多个 Agent 如何协作。在这些基础上加入记忆、知识检索或评价反馈，就会形成常见的增强型架构。下面是可以叠加的架构描述，不是与 ReAct、Plan-and-Execute、Multi-Agent 互斥的新分类。
| 基础模式与扩展机制 | 形成的架构模式 | 主要变化 |
|---|---|---|
| ReAct / 规划执行 + 记忆管理 | 记忆增强型 Agent（Memory-Augmented） | 保存并调用任务经验、用户偏好或历史状态，支持持续交互 |
| ReAct / 规划执行 + 知识检索 | 检索增强型 Agent；模型主导检索时可形成 Agentic RAG | 将外部知识引入决策，需要时继续检索或调整查询 |
| 单 Agent / 多 Agent + 评价与策略修订 | 评价或反思增强型 Agent | 根据检查反馈修订结果、计划或后续策略 |
记忆增强型：让历史信息参与后续任务。 例如，规划执行 Agent 可以读取先前确认的偏好，再安排本次任务。关键在于写入、筛选、更新和使用记忆的机制；文件、关系库与向量库只是存储选择。MemGPT 是管理有限上下文与外部记忆的一种具体设计。MemGPT 原论文
检索增强型：让决策能够使用外部知识。 例如，诊断 Agent 按需检索运维手册，并在资料不足时改变查询。如果何时、如何检索由 Agent 决定，可称为 Agentic RAG；固定的"检索 → 生成"流程则不因此成为 Agent。记忆也可以通过检索读取，两类增强并不互斥。LangChain 检索架构文档
评价或反思增强型：让反馈进入修订过程。 评价判断是否满足标准，反思根据反馈形成调整策略；两者可以分别存在，也可以组合成"执行 → 评价 → 修订 → 再执行"的闭环。Critic 不一定是独立 Agent。Reflexion 则是将语言反思保存到情景记忆、影响后续尝试的具体方法，不是所有自检流程的统称，也不更新模型权重。[
另一类是Workflow--Agent 混合架构，属于控制方式的组合。例如，用预定义流程组织工单、审批和发布，在诊断节点嵌入自主选择排查路径的 Agent。流程约束关键节点，Agent 处理路径不确定的子任务；也可以由 Agent 调用预定义子流程。
Tool-use 常用来强调工具使用能力；ReAct 和规划执行通常已经包含工具交互，因此本文不再将它列为互斥的主架构。Function Calling 是表达调用请求的接口，不能单凭这一接口判断系统具有自主决策循环。
这些组合都需要衡量代价：记忆可能过时，检索可能引入不适用资料，评价与反思会增加调用且不保证纠错。新增机制应解决具体任务问题，并通过实际评估决定是否保留。
五、选型：新增结构要解决什么问题？
| 任务特点 | 可以优先验证的设计 | 主要代价 |
|---|---|---|
| 路径明确、规则稳定 | Workflow，必要节点嵌入 Agent | 异常覆盖、流程维护 |
| 需要根据现场信息探索 | 单 Agent 反馈行动循环 | 重复尝试、上下文增长 |
| 存在阶段依赖或计划审阅 | 规划执行与反馈重规划 | 计划与实际状态同步 |
| 子任务可分离、上下文差异明显 | 多 Agent 委派或协作 | 沟通、汇总、状态冲突 |
这些是选型假设，需要在实际任务集上验证。比较时尽量控制模型、工具、环境与验收标准，观察目标达成、约束遵守、人工接管、耗时和总成本。费用应包含失败、重试和协作调用，结果未知应单独统计。
六、OpsArk 运维智能体 案例：规划、执行控制与证据如何配合？
OpsArk Core 是面向运维任务的桌面工作台。按照前文的分类，当前主链路可以归纳为：以 Plan-and-Execute 为主，通过阶段规划与反馈重规划推进任务，并由程序控制实际执行。
这里的依据是明确的职责分离：模型提出当前阶段的计划，执行器落实获准步骤，系统再结合实际结果组织下一次决策。计划会随现场信息调整，因此属于带反馈的规划执行。
| 架构或机制 | 在 OpsArk 中怎样体现 |
|---|---|
| Plan-and-Execute | 核心执行范式：生成阶段计划、执行步骤，再决定完成、继续或重规划 |
| ReAct 的反馈思想 | 执行产生观察，观察影响后续决策；与 ReAct 的反馈方式相通，但不能据此认定执行器内部还有一个独立 ReAct Agent |
| Workflow 的程序化控制 | 工具可用性、授权、必要审批和执行状态由代码管理，与模型主导的计划调整组合 |
| Multi-Agent | 当前主链路按中心化任务编排理解；规划、执行和验收是职责划分，不据此称为多个 Agent 协作 |
| 共同能力与增强机制 | Skill、可选知识检索、任务上下文和执行记录，为规划与验收提供方法、参考和事实 |
图 4：OpsArk 运维智能体 的规划依据、执行控制与结果反馈架构。
以"在指定服务器部署服务，使用指定端口，不影响现有业务"为例，这种架构可以通过三个环节理解。
**规划（Plan）：**系统组织目标、约束、服务器状态、可用工具和已有结果，模型提出当前阶段的步骤。现场信息不足时，可以先安排必要检查。Skill 提供方法，知识检索提供参考；是否适用仍需结合当前环境判断。
**执行（Execute）：**程序检查步骤的协议、工具可用性和授权，必要时等待审批，再通过工具或命令执行器访问目标环境。模型负责提出方案，执行权限通过运行控制落实。
**反馈与重规划（Feedback / Replan）：**如果检查发现端口已有监听，实际观察会参与后续变更前提的复核，进而决定继续取证、调整剩余方案或请求必要输入。当前阶段执行结束，也要结合证据判断整体目标是否完成；命令成功退出不能直接替代目标验收。已完成且仍有效的结果应继续复用。
OpsArk 显式维护阶段计划、步骤与需求验收关系，因此本文以 Plan-and-Execute 作为主架构描述。观察驱动的反馈不意味着每执行一个动作都必须重新规划。
对于信息逐步暴露、变更需要确认、完成需要证据的运维任务，这种组合既保留阶段计划，也允许根据现场调整。相应代价是持续维护计划、执行状态与验收依据的一致性；结果未知时，还需要通过执行记录和适用的核对机制决定后续处理。