AI Agent 架构详解：从 ReAct、规划执行到多智能体协作

文章目录AI Agent 架构详解从 ReAct、规划执行到多智能体协作一、概念边界Agent 与 Workflow 怎样区分二、执行范式ReAct 与 Plan-and-Execute2.1 ReAct根据观察结果逐步推进2.2 Plan-and-Execute显式规划并根据反馈调整三、协作方式Multi-Agent 如何分工四、架构扩展叠加能力后形成哪些组合五、选型新增结构要解决什么问题六、[OpsArk 运维智能体](https://blog.csdn.net/weixin_44431812/article/details/167039023?fromshareblogdetailsharetypeblogdetailsharerId167039023sharereferPCsharesourceweixin_44431812sharefromfrom_link) 案例规划、执行控制与证据如何配合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 的动态决策。工作流也能嵌入 AgentAgent 外层也需要代码管理状态。判断重点是决策权的范围不能只看有没有模型或分支。图 1执行范式、协作方式和能力机制可以组合。Workflow 单独作为对照与组合方式。二、执行范式ReAct 与 Plan-and-Execute2.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 / 规划执行 记忆管理记忆增强型 AgentMemory-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 AgentWorkflow 的程序化控制工具可用性、授权、必要审批和执行状态由代码管理与模型主导的计划调整组合Multi-Agent当前主链路按中心化任务编排理解规划、执行和验收是职责划分不据此称为多个 Agent 协作共同能力与增强机制Skill、可选知识检索、任务上下文和执行记录为规划与验收提供方法、参考和事实图 4OpsArk 运维智能体 的规划依据、执行控制与结果反馈架构。以“在指定服务器部署服务使用指定端口不影响现有业务”为例这种架构可以通过三个环节理解。**规划Plan**系统组织目标、约束、服务器状态、可用工具和已有结果模型提出当前阶段的步骤。现场信息不足时可以先安排必要检查。Skill 提供方法知识检索提供参考是否适用仍需结合当前环境判断。**执行Execute**程序检查步骤的协议、工具可用性和授权必要时等待审批再通过工具或命令执行器访问目标环境。模型负责提出方案执行权限通过运行控制落实。**反馈与重规划Feedback / Replan**如果检查发现端口已有监听实际观察会参与后续变更前提的复核进而决定继续取证、调整剩余方案或请求必要输入。当前阶段执行结束也要结合证据判断整体目标是否完成命令成功退出不能直接替代目标验收。已完成且仍有效的结果应继续复用。OpsArk 显式维护阶段计划、步骤与需求验收关系因此本文以 Plan-and-Execute 作为主架构描述。观察驱动的反馈不意味着每执行一个动作都必须重新规划。对于信息逐步暴露、变更需要确认、完成需要证据的运维任务这种组合既保留阶段计划也允许根据现场调整。相应代价是持续维护计划、执行状态与验收依据的一致性结果未知时还需要通过执行记录和适用的核对机制决定后续处理。