当下主流的 Agent 架构盘点Agent 不是「换一个更会聊天的模型」而是一套决策 行动 记忆的组织方式。模型负责在不确定条件下推理架构负责约束系统行为什么时候停、能调用什么、上下文怎么传、失败怎么收敛、结果如何验收。可以把 Agent 理解成一个带反馈的控制系统目标 / 用户意图 │ ▼ ┌─────────┐ 行动(Action) ┌─────────┐ │ 决策器 │ ─────────────► │ 环境 │ │ (LLM等) │ ◄───────────── │ 工具/世界│ └─────────┘ 观察(Obs) └─────────┘ │ └── 停止条件 / 交付产物不同架构的差别主要在于谁做计划、谁执行、反馈从哪来、状态存在哪、协作如何发生。下面按目前论文、开源框架与工业落地里最常见的几类尽量展开说明。先分清三个容易混的概念在读具体架构前先对齐术语概念含义常见误解Chatbot多轮对话生成文本有记忆、会调工具也不等于 AgentTool-using LLM能调用函数的模型调用只是 Agent 的「手脚」不是完整架构Agent在循环中感知—决策—行动并朝目标推进「多智能体」不是默认更强另外还有两个正交维度几乎每种架构都会碰到同步 vs 异步一步一步等工具返回还是允许多工具并行、多工人并行确定性编排 vs 模型编排流程边由代码写死还是由 LLM 动态决定下一步生产系统里往往外层偏确定性内层才把决策交给模型。1. ReAct推理与行动交替1.1 它在解决什么问题早期「一次生成答案」的方式无法在中途查资料、跑代码、读文件。ReActReason Act提出让模型在同一条轨迹里交替产出推理痕迹与可执行动作再用环境反馈修正后续推理。这样模型不必把世界全部装进参数而是按需查询。1.2 基本循环Thought → Action → Observation → Thought → … → Final AnswerThought对当前目标、已知信息、缺口的自然语言推理Action选一个工具并填参数搜索、SQL、shell、HTTP…Observation工具返回的结果成功输出或错误信息工业界更常见的是Tool Calling / Function Calling模型直接输出结构化tool_callsJSON宿主执行后再把结果以tool角色塞回对话。表面上少了「Thought:」前缀但循环结构仍是 ReAct 的近亲——很多实现仍会保留隐藏的推理或把推理写进 content。1.3 关键组件组件作用System Prompt定义目标、工具契约、停止规则、安全边界Tool Schema告诉模型每个工具的名字、参数类型、用途Message History累积 assistant / tool 往返形成短期记忆Step Budgetmax_steps防止无限循环Stop Condition显式finish、最终答案格式、或「无工具可调」1.4 常见工程增强Nudge模型只输出文字不调工具时发提醒而不是立刻结束输出截断搜索结果、大文件、长日志进入上下文前做头尾截断并行工具调用一轮里同时调多个无依赖工具缩短墙钟时间错误可恢复把 stderr / 退出码原样回传让模型改参数或换策略工具白名单按场景裁剪可用工具降低误用概率1.5 典型失败模式目标漂移越做越偏忘记原始问题重复试错同一错误参数连试多次上下文膨胀后期模型开始省略、摘要、编造「已完成」工具选择错误该读文件却去搜索该结束却继续探索幻觉行动声称已调用工具但实际上没有在纯文本 ReAct 里更常见1.6 何时使用适合任务边界清晰、工具数量有限、单次会话能完成的场景检索增强问答、轻量运维、带编译/测试反馈的小范围改代码、表单填充类助手。不适合超长多阶段工程、强合规审计、必须严格复现路径的任务除非外面再套状态机。2. Plan-and-Execute先规划再执行2.1 动机ReAct 是「边走边想」在局部很强但全局容易近视。Plan-and-Execute 把过程拆成两段Plan先产出步骤列表或依赖图Execute逐步执行执行器可以是同一模型也可以是更便宜、更克制的模型这样可以把「战略」和「战术」分开规划关注依赖与顺序执行关注单步成功率。2.2 结构示意Goal │ ▼ Planner ──► Plan [s1, s2, s3, …] │ ▼ Executor(s1) → obs1 Executor(s2) → obs2 … │ └──可选Replanner根据失败更新剩余计划2.3 变体变体说明优缺点静态计划计划一次定死执行中不改简单可控遇意外易崩动态重规划某步失败或观测异常后重写后续计划更韧可能反复重规划耗成本分层计划先粗计划再对每步细化适合复杂目标实现更重计划即代码把计划写成伪代码 / 工作流 DSL可校验、可执行要求模型会「编程式规划」2.4 好计划长什么样一个可用的计划通常满足可执行每步对应明确动作或子目标而不是空话可验证每步有完成判据文件存在、测试通过、字段齐全粒度合适过粗等于没计划过细会浪费 token 且脆弱含依赖标明哪些步骤可并行、哪些必须串行2.5 风险计划幻觉列出不存在的 API、数据源或权限过度承诺计划看起来完美执行第一步就发现前提不成立重规划震荡不断改计划却不推进实质工作缓解手段用规则校验计划 schema执行前做「前置条件检查」限制重规划次数让执行失败信息结构化回流。2.6 何时使用适合步骤可枚举、依赖明显、希望减少中途跑偏的任务调研报告、多源数据汇总、多文件改造的软件任务前半段。若环境高度不确定探索性调试纯静态计划反而笨拙更适合「粗计划 ReAct 执行」。3. Reflexion / Self-Refine反思与迭代改稿3.1 核心思想一次生成的质量有上限。Reflexion、Self-Refine 一类方法认为应把「产出」和「评价」拆开用评价信号驱动改写。Draft → Evaluate / Critique → Revise → Evaluate → … → Accept关键不在于「请模型再想想」而在于独立的评价轮次 明确标准 最好有外部真值。3.2 反馈从哪里来反馈源例子可靠性模型自评「请列出 3 个问题」弱易自我开脱专用评判模型打分、挑 MUST_FIX中取决于评判提示程序化检查单测、类型检查、lint、schema 校验强环境反馈编译失败、页面截图、业务指标强人类反馈抽检、标注最强但贵工程上常见组合程序化检查做硬门槛模型批判做软建议。3.3 与「同对话里请再检查」的差别做法效果倾向同一条回复末尾自检容易合理化已有答案新一轮、换角色 Prompt 批判更容易提反对意见批判者工具集只读 / 受限减少「改着改着跑题」修复者只根据报告改变更更可控这也是为什么很多系统会单独做 Reviewer Agent而不是让生成者兼任法官。3.4 停止条件很重要没有封顶的反思会空转。常见策略最大迭代次数如 23 轮分数阈值或「无 MUST_FIX」外部测试全绿连续两轮改动极小近似收敛3.5 何时使用适合有可检查标准的任务代码生成、格式化文档、数据变换、需要风格一致性的写作。不适合纯主观审美且无稳定评价器的任务除非接受「贵且不稳定」。4. Multi-Agent多智能体协作4.1 为什么要拆多个 Agent单 Agent 的 Prompt 会膨胀角色互相打架既要大胆生成又要严格审查。多智能体把能力拆成角色每个角色更短的目标描述更窄的工具集更清晰的成功标准收益是专业化与并行代价是协议、调度与费用。4.2 流水线PipelineAgent A → 产物/消息 → Agent B → 产物/消息 → Agent C → 交付优点顺序固定日志好读易做阶段门禁Stage Gate缺点上游错了会污染下游并行度低适用内容生产流水线、审批流、固定 ETL/运营流程流水线的关键设计是阶段契约每段输出必须满足 schema否则不允许进入下一段。4.3 主管调度Supervisor / Orchestrator┌────────────┐ │ Supervisor │ └─────┬──────┘ ┌────────┼────────┐ ▼ ▼ ▼ Worker1 Worker2 Worker3主管负责任务分解、选择工人、汇总结果、决定重试或结束。实现上有两条路LLM 主管灵活但可能乱派活、重复派活代码 / 规则主管稳、可测灵活性靠预置分支很多人说「多智能体」落地其实是确定性编排器 多个 LLM 工人。这通常比「LLM 管 LLM」更适合生产。4.4 辩论与投票Debate / EnsembleProposer A ⇄ Critic B │ ▼ Judge / Vote → 最终答案多个对等 Agent 给出不同答案或互相质疑再由仲裁者或投票聚合。优点对事实性问题、推理题有时更稳缺点成本近似线性上升仲裁者本身会偏置不保证收敛到真理更工程化的近亲是Best-of-N同一提示采样多个候选用验证器选最优不一定需要「对话式辩论」。4.5 多智能体的共性难题消息协议传原文、传摘要、还是传结构化状态共享状态共享文件系统 / 数据库还是只靠消息终止谁有权宣布完成如何避免永续会议责任归属出错时要能指出哪个角色、哪一步成本控制角色一多token 与延迟陡增一条实用原则能用数据契约传递就少用自由聊天传递。5. Hierarchical Agents分层与子目标5.1 与 Supervisor 的细微差别Supervisor 强调「调度谁干活」Hierarchical 更强调目标树与权限层级Root Goal ├─ Subgoal A经理 A │ ├─ Task A1专员 │ └─ Task A2专员 └─ Subgoal B经理 B └─ Task B1上层负责任务分解与验收下层只在受限动作空间里完成子目标通常不能直接改全局策略或越权调高危工具。5.2 为什么分层有用长程任务数小时的研究、大型仓库改造若全压在一个扁平 ReAct 上上下文装不下全过程局部最优破坏全局约束难以做进度可视化与断点续跑分层后每一层只看见自己的子目标与摘要上层用验收标准决定是否重开下层。5.3 设计要点目标表达子目标要可验证避免「尽量做好」这类软目标汇报格式下层返回结构化结果成功/失败/产物路径/置信度升级机制下层多次失败后把问题上报而不是无限重试权限帽API 密钥、生产写权限、删除操作只留在高层或人工确认层5.4 何时使用研究型助手、软件工程 Agent、企业流程自动化中「总控 专业模块」的拆分。若任务本身很短分层只会增加空转。6. Memory-Augmented记忆增强6.1 为什么需要外挂记忆对话窗口是有限的工作记忆。跨会话个性化、企业知识库、历史失败经验都必须落到模型参数之外。6.2 记忆类型工程视角类型存什么典型介质读写频率短期记忆当前对话 messages上下文窗口每步工作记忆任务状态、待办、中间变量状态机 / JSON / scratchpad每步语义记忆知识条目、文档块向量库 / 搜索引擎按需检索情景记忆过去轨迹、成功案例、失败原因日志库 检索任务开始或失败时程序记忆可复用技能、工具编排片段代码 / 提示模板库匹配到相似任务时6.3 RAG AgentRAG检索增强生成解决「事实从哪来」Agent 解决「何时检索、检索不够怎么办、如何行动」。典型闭环是否需要检索 → 检索 → 阅读 → 仍不够 → 再检索 / 换查询 → 行动或作答进阶形态包括Agentic RAG由 Agent 决定检索策略而不是固定 Top-KCorrective RAG发现检索内容不相关时纠正查询或放弃检索Graph RAG用知识图谱约束实体关系而不只靠向量相似度6.4 记忆系统最难的部分不是「接入向量数据库」而是写什么全存会噪声爆炸乱摘要会丢关键约束何时写任务成功后每次工具调用后仅用户确认后如何更新覆盖、追加、还是冲突合并如何防污染错误结论写进长期记忆会长期害人权限与隐私用户级 / 租户级隔离一句话记忆是产品能力也是事故来源。7. Code-as-Action / Computer-Use把环境当接口7.1 行动空间升级前面的架构默认「工具是有限 API」。这一类把行动空间扩成形态行动是什么典型能力Code Interpreter写代码并在沙箱执行计算、数据分析、画图、文件转换Browser / GUI Agent点击、输入、滚动、读 DOM/截图操作网站与桌面软件Software Engineering Agent改仓库、跑测试、看 CI 日志端到端修 bug / 加功能模型不再只「说话」而是通过代码或键鼠改变外部世界。7.2 架构重点转移到环境契约这类系统里模型智力仍重要但更常翻车在环境侧沙箱隔离网络、文件系统、权限默认拒绝可观测性截图、DOM、终端输出、测试报告要结构化回传动作原子性一次点击失败如何重试避免重复下单回滚与补偿错误提交如何撤销数据库写如何事务化非确定性页面改版、动画、验证码会破坏脚本式假设7.3 常见控制策略高风险动作二次确认支付、删除、发信允许列表域名 / 路径时间预算与步数预算双限制「先只读探索再写入」的两阶段策略用测试/断言作为完成定义而不是模型自称完成7.4 何时使用需要真实世界副作用、且 API 封装不全的场景。若已有稳定 API优先薄工具封装而不是一上来 Computer-Use——后者更强也更贵、更脆。8. Graph / State-Machine Orchestration图与状态机编排8.1 核心主张把流程画成图节点是步骤可以是 LLM、规则、人工、工具边是转移条件。LLM 是部分节点的实现不是整个系统的唯一控制面。[Start] → [校验输入] → [LLM 起草] → [规则检查] │失败 ▼ [LLM 修复] ──► [人工审核?] → [End]开源与云厂商里常被称为 Workflow、Graph、StateGraph、Orchestration。8.2 为什么生产系统偏爱它能力说明可控合规步骤无法被模型跳过可测节点可单测边可模拟可观测天然对应 tracing span可恢复失败节点可从检查点重跑可混搭LLM、规则、人工审批共存8.3 与「纯 Agent」的关系不是对立而是嵌套图的某个节点内部可以是完整的 ReAct 循环某个节点可以是 Multi-Agent 子图边条件可以是规则也可以是分类 LLM因此更准确的说法是用图管全局用 Agent 填局部智能。8.4 设计时要注意节点粒度太大难测太小图会爆炸状态 schema跨节点传递的状态要显式类型化避免「假图真聊天」若边条件全交给 LLM 自由发挥可控性会退化人机回路审核节点、超时升级、拒绝路径要预先设计9. 其他常见相关范式简表这些不一定每次都被单列为「架构」但常与上面组合出现名称一句话Tree-of-Thoughts在推理时展开多条思路树再搜索/剪枝Graph-of-Thoughts把中间想法建成图允许合并与回流Least-to-Most先解决子问题再组合偏提示策略Router / Gateway先分类意图再路由到不同 Agent 或工作流Human-in-the-loop关键节点必须人批架构上是显式暂停态Swarm 风格多个小 Agent 通过交接handoff传递控制权它们解决的是「怎么想」或「怎么交接」通常要挂在 ReAct、图编排或多智能体骨架上才完整。10. 横向对比架构决策中心状态主要在哪强项主要风险成本形态ReAct / Tool Loop单模型边想边做对话上下文灵活、好上手漂移、上下文膨胀随步数涨Plan-and-ExecutePlanner Executor计划表 逐步观测全局更稳计划幻觉、僵化规划 执行两次开销Reflexion生成器 评价器草稿与批评文本提质量无真值时空转迭代倍数Multi-Agent Pipeline预先顺序阶段产物清晰可审计上游污染下游角色数 × 轮次Supervisor主管任务队列 / 汇总动态分工主管乱调度主管 工人Debate / Ensemble多候选 仲裁多份答案鲁棒性贵、慢、仲裁偏差近似 ×NHierarchical目标树各级子目标与汇报长任务可管通信与权限复杂层级深度相关Memory-Augmented决策器 检索外挂库跨会话 / 知识脏记忆、噪声检索 生成Code / Computer-Use模型 环境环境真实状态能力上限高安全、脆弱、难复现环境时间主导Graph / State Machine图转移条件显式状态对象工程可控灵活性需预埋分支相对可预测11. 当前业界的务实叠层2024–2026 年真正上线的系统很少自称「我们只用一种纯架构」。更常见的是叠层外层状态机 / 工作流——保证阶段、合规、重试与审计内层ReAct 工具循环——在单阶段内完成探索与行动关键点Reflexion 或独立 Reviewer——用检查清单或测试卡质量跨会话RAG / 轨迹记忆——复用知识与历史经验高风险动作沙箱 允许列表 人工确认可选并行互不依赖的工人 Agent 由编排器并发调度一句话概括用图管流程用 Agent 填智能用工具碰世界用记忆跨时间用验证关质量。12. 选型清单可以按问题直接选型你的情况更合适的方向任务短、工具少、要快速上线ReAct步骤固定、要可审计可重放Graph / Pipeline容易一步生成但不稳定Reflexion 自动验真角色差异大、可并行Multi-Agent优先代码编排任务很长、需拆解验收Hierarchical需要企业知识或跨会话Memory / Agentic RAG缺少 API、必须点界面Computer-Use控风险已有稳定 API / 代码接口薄工具 ReAct不必上 GUI既要灵活又要合规外层图 内层 Agent评估时优先看三件事失败能否定位到阶段、角色、工具调用重试是否浪费有没有可复用的中间产物权限是否收敛模型能不能做不该做的事这三件事往往比「是不是最新多智能体框架」更能决定系统能不能稳定上线。13. 结语Agent 架构的演进并不是一条「ReAct 过时了必须上多智能体」的单行道而是工具箱的扩容需要灵活性时用 ReAct需要全局观时用计划或分层需要质量时用反思与验真需要协作时用多智能体但先把契约与编排写清楚需要落地时用图与状态机把 LLM 关进可观测的节点里选架构时先写清目标、工具、状态、失败与验收再决定模型在图中的位置。顺序反了就容易做出「会聊天、不稳定、不可运维」的演示系统。