主流Agent框架详解

当下主流的 Agent 架构盘点

Agent 不是「换一个更会聊天的模型」，而是一套决策 + 行动 + 记忆的组织方式。模型负责在不确定条件下推理；架构负责约束系统行为：什么时候停、能调用什么、上下文怎么传、失败怎么收敛、结果如何验收。

可以把 Agent 理解成一个带反馈的控制系统：

目标 / 用户意图 │ ▼ ┌─────────┐ 行动(Action) ┌─────────┐ │ 决策器 │ ─────────────► │ 环境 │ │ (LLM等) │ ◄───────────── │ 工具/世界│ └─────────┘ 观察(Obs) └─────────┘ │ └── 停止条件 / 交付产物

不同架构的差别，主要在于：谁做计划、谁执行、反馈从哪来、状态存在哪、协作如何发生。下面按目前论文、开源框架与工业落地里最常见的几类，尽量展开说明。

先分清三个容易混的概念

在读具体架构前，先对齐术语：

另外还有两个正交维度，几乎每种架构都会碰到：

1. 同步 vs 异步：一步一步等工具返回，还是允许多工具并行、多工人并行
2. 确定性编排 vs 模型编排：流程边由代码写死，还是由 LLM 动态决定下一步

生产系统里，往往外层偏确定性，内层才把决策交给模型。

1. ReAct：推理与行动交替

1.1 它在解决什么问题

早期「一次生成答案」的方式，无法在中途查资料、跑代码、读文件。ReAct（Reason + Act）提出：让模型在同一条轨迹里交替产出推理痕迹与可执行动作，再用环境反馈修正后续推理。这样，模型不必把世界全部装进参数，而是按需查询。

1.2 基本循环

Thought → Action → Observation → Thought → … → Final Answer

• Thought：对当前目标、已知信息、缺口的自然语言推理
• Action：选一个工具并填参数（搜索、SQL、shell、HTTP…）
• Observation：工具返回的结果（成功输出或错误信息）

工业界更常见的是Tool Calling / Function Calling：模型直接输出结构化tool_calls（JSON），宿主执行后再把结果以tool角色塞回对话。表面上少了「Thought:」前缀，但循环结构仍是 ReAct 的近亲——很多实现仍会保留隐藏的推理或把推理写进 content。

1.3 关键组件

1.4 常见工程增强

• Nudge：模型只输出文字不调工具时，发提醒而不是立刻结束
• 输出截断：搜索结果、大文件、长日志进入上下文前做头尾截断
• 并行工具调用：一轮里同时调多个无依赖工具，缩短墙钟时间
• 错误可恢复：把 stderr / 退出码原样回传，让模型改参数或换策略
• 工具白名单：按场景裁剪可用工具，降低误用概率

1.5 典型失败模式

• 目标漂移：越做越偏，忘记原始问题
• 重复试错：同一错误参数连试多次
• 上下文膨胀：后期模型开始省略、摘要、编造「已完成」
• 工具选择错误：该读文件却去搜索，该结束却继续探索
• 幻觉行动：声称已调用工具但实际上没有（在纯文本 ReAct 里更常见）

1.6 何时使用

适合任务边界清晰、工具数量有限、单次会话能完成的场景：检索增强问答、轻量运维、带编译/测试反馈的小范围改代码、表单填充类助手。

不适合：超长多阶段工程、强合规审计、必须严格复现路径的任务（除非外面再套状态机）。

2. Plan-and-Execute：先规划再执行

2.1 动机

ReAct 是「边走边想」，在局部很强，但全局容易近视。Plan-and-Execute 把过程拆成两段：

1. Plan：先产出步骤列表或依赖图
2. Execute：逐步执行；执行器可以是同一模型，也可以是更便宜、更克制的模型

这样可以把「战略」和「战术」分开：规划关注依赖与顺序，执行关注单步成功率。

2.2 结构示意

Goal │ ▼ Planner ──► Plan = [s1, s2, s3, …] │ ▼ Executor(s1) → obs1 Executor(s2) → obs2 … │ └──（可选）Replanner：根据失败更新剩余计划

2.3 变体

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.3 与「同对话里请再检查」的差别

这也是为什么很多系统会单独做 Reviewer Agent，而不是让生成者兼任法官。

3.4 停止条件很重要

没有封顶的反思会空转。常见策略：

• 最大迭代次数（如 2～3 轮）
• 分数阈值或「无 MUST_FIX」
• 外部测试全绿
• 连续两轮改动极小（近似收敛）

3.5 何时使用

适合有可检查标准的任务：代码生成、格式化文档、数据变换、需要风格一致性的写作。

不适合：纯主观审美且无稳定评价器的任务（除非接受「贵且不稳定」）。

4. Multi-Agent：多智能体协作

4.1 为什么要拆多个 Agent

单 Agent 的 Prompt 会膨胀，角色互相打架（既要大胆生成又要严格审查）。多智能体把能力拆成角色，每个角色：

• 更短的目标描述
• 更窄的工具集
• 更清晰的成功标准

收益是专业化与并行；代价是协议、调度与费用。

4.2 流水线（Pipeline）

Agent A → 产物/消息 → Agent B → 产物/消息 → Agent C → 交付

• 优点：顺序固定，日志好读，易做阶段门禁（Stage Gate）
• 缺点：上游错了会污染下游；并行度低
• 适用：内容生产流水线、审批流、固定 ETL/运营流程

流水线的关键设计是阶段契约：每段输出必须满足 schema，否则不允许进入下一段。

4.3 主管调度（Supervisor / Orchestrator）

┌────────────┐ │ Supervisor │ └─────┬──────┘ ┌────────┼────────┐ ▼ ▼ ▼ Worker1 Worker2 Worker3

主管负责任务分解、选择工人、汇总结果、决定重试或结束。实现上有两条路：

1. LLM 主管：灵活，但可能乱派活、重复派活
2. 代码 / 规则主管：稳、可测，灵活性靠预置分支

很多人说「多智能体」，落地其实是确定性编排器 + 多个 LLM 工人。这通常比「LLM 管 LLM」更适合生产。

4.4 辩论与投票（Debate / Ensemble）

Proposer A ⇄ Critic B │ ▼ Judge / Vote → 最终答案

多个对等 Agent 给出不同答案或互相质疑，再由仲裁者或投票聚合。

• 优点：对事实性问题、推理题有时更稳
• 缺点：成本近似线性上升；仲裁者本身会偏置；不保证收敛到真理

更工程化的近亲是Best-of-N：同一提示采样多个候选，用验证器选最优，不一定需要「对话式辩论」。

4.5 多智能体的共性难题

1. 消息协议：传原文、传摘要、还是传结构化状态？
2. 共享状态：共享文件系统 / 数据库，还是只靠消息？
3. 终止：谁有权宣布完成？如何避免永续会议？
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 记忆类型（工程视角）

6.3 RAG + Agent

RAG（检索增强生成）解决「事实从哪来」；Agent 解决「何时检索、检索不够怎么办、如何行动」。

典型闭环：

是否需要检索？ → 检索 → 阅读 → 仍不够？ → 再检索 / 换查询 → 行动或作答

进阶形态包括：

• Agentic RAG：由 Agent 决定检索策略，而不是固定 Top-K
• Corrective RAG：发现检索内容不相关时纠正查询或放弃检索
• Graph RAG：用知识图谱约束实体关系，而不只靠向量相似度

6.4 记忆系统最难的部分

不是「接入向量数据库」，而是：

1. 写什么：全存会噪声爆炸；乱摘要会丢关键约束
2. 何时写：任务成功后？每次工具调用后？仅用户确认后？
3. 如何更新：覆盖、追加、还是冲突合并？
4. 如何防污染：错误结论写进长期记忆会长期害人
5. 权限与隐私：用户级 / 租户级隔离

一句话：记忆是产品能力，也是事故来源。

7. Code-as-Action / Computer-Use：把环境当接口

7.1 行动空间升级

前面的架构默认「工具是有限 API」。这一类把行动空间扩成：

模型不再只「说话」，而是通过代码或键鼠改变外部世界。

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 为什么生产系统偏爱它

8.3 与「纯 Agent」的关系

不是对立，而是嵌套：

• 图的某个节点内部可以是完整的 ReAct 循环
• 某个节点可以是 Multi-Agent 子图
• 边条件可以是规则，也可以是分类 LLM

因此更准确的说法是：用图管全局，用 Agent 填局部智能。

8.4 设计时要注意

• 节点粒度：太大难测，太小图会爆炸
• 状态 schema：跨节点传递的状态要显式类型化
• 避免「假图真聊天」：若边条件全交给 LLM 自由发挥，可控性会退化
• 人机回路：审核节点、超时升级、拒绝路径要预先设计

9. 其他常见相关范式（简表）

这些不一定每次都被单列为「架构」，但常与上面组合出现：

它们解决的是「怎么想」或「怎么交接」，通常要挂在 ReAct、图编排或多智能体骨架上才完整。

10. 横向对比

11. 当前业界的务实叠层

2024–2026 年真正上线的系统，很少自称「我们只用一种纯架构」。更常见的是叠层：

1. 外层：状态机 / 工作流——保证阶段、合规、重试与审计
2. 内层：ReAct 工具循环——在单阶段内完成探索与行动
3. 关键点：Reflexion 或独立 Reviewer——用检查清单或测试卡质量
4. 跨会话：RAG / 轨迹记忆——复用知识与历史经验
5. 高风险动作：沙箱 + 允许列表 + 人工确认
6. 可选并行：互不依赖的工人 Agent 由编排器并发调度

一句话概括：

用图管流程，用 Agent 填智能，用工具碰世界，用记忆跨时间，用验证关质量。

12. 选型清单

可以按问题直接选型：

评估时优先看三件事：

1. 失败能否定位到阶段、角色、工具调用
2. 重试是否浪费，有没有可复用的中间产物
3. 权限是否收敛，模型能不能做不该做的事

这三件事，往往比「是不是最新多智能体框架」更能决定系统能不能稳定上线。

13. 结语

Agent 架构的演进，并不是一条「ReAct 过时了，必须上多智能体」的单行道，而是工具箱的扩容：

• 需要灵活性时，用 ReAct
• 需要全局观时，用计划或分层
• 需要质量时，用反思与验真
• 需要协作时，用多智能体，但先把契约与编排写清楚
• 需要落地时，用图与状态机把 LLM 关进可观测的节点里

选架构时，先写清目标、工具、状态、失败与验收，再决定模型在图中的位置。顺序反了，就容易做出「会聊天、不稳定、不可运维」的演示系统。