Agent 架构不是段位，而是工具。本文拆解八种架构地图，从 ReAct 到 Hierarchical，直击 PM 在架构会议中必须拍板的五个决策点，帮你避开两百万冤枉钱，让 Agent 系统真正扛住业务。

这两年”Agent”三个字被用烂了。调个 Function Calling 叫 Agent，套个 RAG 也叫Agent，堆三个角色互相喊话还叫Agent。但真要把一个能上线、能扛业务、老板愿意继续投钱的 Agent 系统做出来，你会发现——模型选哪家只是入场券，架构怎么搭才决定你半夜会不会被报警电话叫醒。

我把自己做企业智能化项目时反复用的那张”八架构地图”拆开讲一遍，顺手把 PM 在架构会议里该拍板、却常被工程师代签的五个决策点列出来。看完你能少花两百万冤枉钱。

0. 先泼冷水：Agent 架构不是段位，是扳手和螺丝刀

很多人心里有个隐性排行榜：ReAct < Plan-and-Execute < Reflection < Multi-Agent < Hierarchical，越往后越”高级”。

错。大错特错。

这八种（ReAct / Plan-and-Execute / Reflection / Tool Use / RAG / Multi-Agent / Hierarchical / Memory-Augmented）不是进阶关系，是针对不同类型问题形状的工具。就像你不会拿锤子拧螺丝，也不会拿扳手钉钉子。

我见过最典型的反面教材：

• 某客服场景（平均 2 步搞定）硬上 5-Agent 协作，响应从 2s 变 20s，用户留存直接掉 15%。
• 某财务对账（必须先验流水再验凭证再轧差）用 ReAct 硬撑，模型在第 4 跳推理跑偏，反复调工具打转，跑了一下午没出数。

PM 第一课：架构没有绝对好坏，只有合不合适。这句话很老套，但 90% 的 Agent 项目死在这句话没被写进 PRD。

1. 单 Agent 的三种内核：ReAct、Plan-and-Execute、Reflection

大部分业务，其实在”单 Agent + 外部能力”这一层就能解决 70%。别急着上天。

1.1 ReAct：走一步看一步的行动派

原理一句话：Thought → Action → Observation → Thought…，边想边干。

PM 视角看优势

• 灵活，适合”任务长啥样事先说不清”的场景。
• 工程简单，LangChain / OpenAI Agents SDK 里开箱即用。
• 用户感知快：查天气→给建议，一轮搞定。

软肋（必须写进风险评估）

• 链路一长就”局部最优全局失控”。我踩过：连续调 6 个工具，第 4 跳返回歧义，模型自己没察觉，后面全错。
• Token 消耗和延迟随跳数线性涨。客服 SLA 5 秒，ReAct 跳数必须压到 3 跳以内，否则别用。

落点：通用问答、信息查询、多步但每步独立的小任务。三步以内闭眼用，五步以上要警惕。

1.2 Plan-and-Execute：先列 To-do 再动手

原理一句话：先让 LLM 把大目标拆成子任务清单，再顺序/并行执行，最后汇总。

PM 视角看优势

• 可控、可审计。计划阶段产品经理想改范围，直接改清单，不用扒代码。
• 长流程自动化（竞品分析、周报生成、数据 pipeline）的亲儿子。

最容易踩的坑

只做”一次性规划 + 顺序执行”，不允许多次重规划。计划错一步，后面全歪。

正确做法：规划节点独立化，每执行完一个子任务让模型判断”要不要重规划”。

落点：步骤清晰、有依赖、可回溯的项目管理类任务。复杂但确定性中等的场景首选。

1.3 Reflection：自己给自个儿挑刺

原理一句话：生成 → 自评 → 修订 → 再生成，可多轮。

代码生成里最香。我们内部测过，加一轮自我 review，前端函数一次通过率肉眼提升。

但 PM 必须知道的两件事：

1. 反思改的是”逻辑漏洞和表达质量”，改不了知识性硬伤——模型以为 1+1=3，反思十遍还是 3。硬伤归 RAG。
2. 每多一轮反思多一次完整调用。质量换钱换延迟，客服别用，代码助手/方案撰写值得用。

落点：代码、文案、分析报告、复杂推理——容错率低、输出要脸的场景。

2. 让 Agent 从”会说”变”会办”：Tool Use 与 RAG

这两个一般不单独存在，但任何企业级 Agent 都绕不开。

2.1 Tool Use：装手脚，不是装脑子

模型决定”调哪个工具”，执行交给外部系统。查库、算账、发消息、建单，全靠它。

PM 最容易低估的成本——不是技术，是边界。

• 某团队客服 Agent 接了”下单工具”，用户问”这单能退吗”，模型理解成”再下一单”，真创建了订单。
• 凡是写操作（建单/扣款/发送/删除），必须：参数 schema 校验 + 意图白名单 + 高危动作人工确认或异步审核。别把”模型应该不会乱来”写进安全方案，那是事故说明书。

落点：实时数据、精确计算、业务系统打通。和企业 Agent 几乎绑定存在。

2.2 RAG：给模型接外部大脑，但锅常在检索端

原理不讲了，企业知识问答的默认答案。

PM 要盯的不是 Embedding 模型多牛，是知识治理：

• 文档切得碎不碎？
• 过期政策和现行政策是不是堆一起？
• 召回排序有没有拿”标题相似”糊弄”语义相关”？

我见过调了半个月 Prompt 没用，最后发现知识库里 2023 版和 2025 版制度互相打架。RAG 效果天花板 = 知识库治理水平，不是大模型版本。

落点：客服、制度问答、专业咨询、文档摘要。答案必须有出处时必选。

3. 复杂了怎么办：Multi-Agent 与 Hierarchical

到了这儿，架构复杂度开始反噬。

3.1 Multi-Agent：像项目组，不像流水线

研究员 / 写手 / 审核员各一个 Agent，平级协作。

质量确实能打：我们做过内容生产实验，三 Agent 分工比单 Agent 从头写尾稳定不少。

但生产环境三大鬼故事：

1. 通信成本爆炸（A 传给 B 的上下文比原任务还长）。
2. 意见分歧死循环（A 让改语气，B 让改结构，谁不服谁）。
3. 出错了不知道锅在谁——是研究员素材偏了，还是写手没接住？

经验法则：能一个 Agent + 几个 Tool 解决的，绝不升 Multi-Agent。只有当”不同专业角色独立判断”且”角色间有天然边界”（如法律+税务+代码）才上。

3.2 Hierarchical：有老板，有员工

上层管理 Agent 拆解调度，下层子 Agent 只管执行。

比平级 Multi-Agent 适合”大企业级编排”——市场/产品/技术三个方向汇报给一个总控。

但风险极集中：管理 Agent 拆错任务，下层执行再完美也南辕北辙。对”老板 Agent”的规划能力要求，远高于对打工 Agent 的要求。

落点：大规模、多子域、要统一收口的企业流程。Demo 里看不出好坏，跑万级请求才见分晓。

4. Memory-Augmented：让 Agent 别每次都当陌生人

短期记忆管本轮会话，长期记忆管跨会话偏好/历史/画像。

个性化助手、长期陪伴、客户复访场景的底座。但 PM 的坑在治理不在技术：

• 记多久？过期怎么清？
• 用户说”以后别叫我哥”你记不记？记了算隐私数据吗？
• 记错了（把 A 的偏好贴到 B 身上）怎么回滚？

记忆系统技术是小头，合规和清理是大头。

5. 真实项目里，没人只用一种

原图那张对照表（动态推理→ReAct，复杂清晰→Plan，高质量→Reflection，接系统→Tool，专业支撑→RAG，多角色→Multi，大规模→Hierarchical，长期→Memory）是起点不是终点。

我们跑过的几个真实组合：

• 企业知识助手 = RAG + Tool Use + 轻量 ReAct（检索不到就调接口补）。
• 竞品分析报告 = Plan-and-Execute 套 Reflection（先拆计划，每节初稿后自审）。
• 智能客服 = 规则路由（80% 高频）→ ReAct（15% 复杂）→ 人工（5%），Memory 做用户画像，RAG 做政策问答，不上 Multi-Agent。
• 内部研报工厂 = Hierarchical 管调度，下层三个 Specialist Agent，接 RAG + 代码工具 + Reflection 自审。

组合拳的前提是：每一层你都说得清”为什么这一层必须存在”。说不清的，砍。

6. 架构拍板前，PM 必须亲自签字的五件事

工程师会帮你选框架（LangChain / CrewAI / 自研），但下面这些是产品决策，别外包：

1. 任务边界写死：Agent 能碰哪些工具、能读哪些表、能发什么消息，列清单，不靠模型自觉。
2. 数据质量归 PM 管：RAG 知识库谁更新、Tool 对接的业务表谁校准，要有 SLA。模型背不了数据脏的锅。
3. 权限与审计：写/扣/发/删四类动作，必须 human-in-the-loop 或强校验。出事追责时，”模型干的”不是免责牌。
4. 成本先算再上线：ReAct 几跳、Reflection 几轮、Multi-Agent 几个角色，单次任务 LLM 调用次数 × 单价 = 单次成本。客服一天 10 万次，乘出来老板一看就懂。
5. 评估指标量化：任务成功率、首次响应延迟、人工接管率、用户满意度。没有 baseline 的 Agent 项目，等于没有刹车的高速车。

7. 回到开头那个问题：怎么选？

我把自己的内部决策树缩成四问，比八架构对照表更好用：

1. 任务步骤能不能事前确定？ 能 → Plan-and-Execute；不能 → ReAct。
2. 输出错一点会出事吗？ 会 → 叠 Reflection / RAG；不会 → 裸 ReAct 也行。
3. 要办实事儿吗？ 要查实时/写系统 → Tool Use 必加；要引内部知识 → RAG 必加。
4. 一个 Agent 真不够吗？ 角色天然分立且需独立判断 → Multi/Hierarchical；否则别上。

架构选对，模型是放大器；架构选错，模型是扩音器——把蠢放大给全公司看。

这两年我最深的体会：大模型决定能力上限，架构决定这个上限能不能稳定、可观测、可赔得起地释放出来。简单事别堆复杂架构自嗨，复杂事别靠一轮 Prompt 蒙混。Agent 这东西，拼到最后不是比谁模型新，是比谁原理吃透了、场景认清楚了、边界守住了。