上一期我用一辆奥迪Q5的「刹车异响」走完了接车到交车的六站编排；这一期回答一个更底层的问题——那个编排，到底该是一个 Agent 从头干到尾，还是多个 Agent 分工协作？

一、开篇：从「六站编排」到「三个灵魂拷问」

上一期《从接车到交车》里，我用一辆 2022 款奥迪 Q5 的「低速刹车异响」案例，把一次 4S 店售后服务拆成了六个站点：

<span leaf="">接车倾听 → 历史查询 → 开单派工 → 诊断检测 → 维修执行 → 质检交车</span>

当时我给了你一张漂亮的「编排全景图」和一段 200 行的 Java 代码。但如果你真的拿着这段代码去上线，产品经理和技术负责人一定会追着你问三个问题：

① 我的 SA 脑子里其实是「听客户说 → 想一下 → 查个系统 → 再想一下 → 再查」这种反复循环，你上一期写的却是一根筋往下跑的固定流程。到底哪种才对？

② 售后经理管车间，从来不是「走一步看一步」，而是先「开单」把项目、工时、配件、工位一次规划好，再「派工」执行。这种「先规划后执行」在代码里怎么表达？

③ 客服那边一个简单的「首保邀约电话」也要我上一套六站编排吗？售后全流程这么长，让一个 Agent 全干会不会顾此失彼？什么时候一个人干，什么时候一群人干？

这三个问题，正是今天要拆解的 Agent 架构设计三大模式：

ReAct（推理+行动） —— 对应 SA 的「倾听→思考→行动」循环
Plan-and-Execute（先规划后执行） —— 对应「开单→派工→执行」的管理流程
Single-Agent vs Multi-Agent —— 一个「全科医生」还是「专家会诊」

图片

我会继续用那辆 Q5，但这次不讲「用了哪些 Skill」，而是讲「这些 Skill 被组织成什么结构」。结构，才是架构师和调包侠的分水岭。

二、ReAct 模式：把 SA 的「倾听→思考→行动」写成循环

2.1 场景还原：SA 脑子里的真实循环

回到上一期的上午 9:15。张先生说完「低速刹车有异响，倒车更明显，马上跑长途」，我脑子里其实不是线性地走流程，而是这样一个循环：

  1. 听（Observation）：客户说「低速异响」「倒车更明显」「要跑长途」。

  2. 想（Thought）：刹车异响 + 倒车更明显，大概率不是刹车片本身，而是分泵/导向销/制动盘相关；「跑长途」说明要尽快给结论。

  3. 做（Action）：先查维保档案——「查这车刹车片换过没有」。

  4. 再看（Observation）：去年 8 月换过，还是副厂件。

  5. 再想（Thought）：副厂件 + 这个里程数，导向销润滑不到位的概率很大；需要上举升机看制动盘磨损。

  6. 再做（Action）：让李师傅路试 + 读 OBD + 拍制动盘照片。

  7. 再看（Observation）：左后分泵响应延迟 0.3 秒，制动盘磨损 1.2mm 超标。

  8. 结论（Final Answer）：更换左后制动盘 + 分泵导向销维修包。

这个「听→想→做→再看→再想→再做」的循环，就是 ReAct 模式的原型。一个有经验的 SA，从来不是一次性拿到所有信息再下结论，而是「每做一步，观察结果，再决定下一步」。这正是大模型最擅长、也是传统固定流程最做不到的事。

2.2 ReAct 的原理：Thought → Action → Observation

ReAct（Reasoning +Acting）来自 2023 年的一篇经典论文（Yao et al., ICLR 2023）。核心思想一句话：让 LLM 在「推理」和「调用工具」之间交替，直到得出答案。

<span leaf="">┌──────────────────────────────────────────────────┐</span>

三个关键角色：

| ReAct 术语

|

售后含义

|

谁来干

Thought（思考）

|

判断故障方向、决定查什么、排除什么

|

LLM 推理

| |

Action（行动）

|

查 DMS、读 OBD、看配件历史、拍照检测

|

Skill + MCP

| |

Observation（观察）

|

工具返回的数据（档案、故障码、图片识别结果）

|

Skill 返回值

|

循环的本质：把「不知道下一步该干什么」这件事，交给 LLM 动态决定。只要工具（Skill）给得够全、观察（Observation）喂得够准，Agent 就能像老 SA 一样「边查边想」。

2.3 售后映射：ReAct 就是「诊断型」任务的天然骨架

| 售后能力

|

ReAct 环节

|

说明

倾听客户描述

|

Observation（初始输入）

|

客户原话 + 语气 = 第一条观察

| |

判断故障方向

|

Thought

|

「异响在倒车更明显 → 优先怀疑制动系统」

| |

查历史/读故障码

|

Action + Observation

|

每调一个 Skill，结果回填

| |

排除法收敛

|

多轮 Thought

|

副厂件、分泵延迟、盘磨损 → 逐步锁定根因

| |

给最终结论

|

Final Answer

|

不再调用工具，直接输出诊断报告

|

共情力提升点：ReAct 的「每一步观察都拼回上下文」，恰好模拟了 SA 的「带着上一轮信息继续聊」。客户不会感觉你在重复问，而是觉得你「一直在跟进他的问题」——这正是张先生最在意的「被认真对待」的感觉。

2.4 Java 代码骨架：一个真实的 ReAct 循环

<span leaf=""><span>import</span>&nbsp;java.util.ArrayList;</span>

这段代码跑出来的真实轨迹，就是 2.1 里 SA 脑子里的循环：

<span leaf=""><span>Thought</span>: 低速+倒车异响，先查这车刹车片更换历史，排除副厂件因素</span>

2.5 踩坑指南：ReAct 的三大坑

| 坑

|

现象

|

解法

死循环

|

LLM 反复调用同一个 Skill，一直不收敛

|

设 MAX_STEPS，超过转人工或降级到固定流程

| |

工具选错

|

该查 OBD 却去查库存，浪费 token 和延迟

|

工具描述写清楚 + Few-shot 示例 + 收敛时给明确提示

| |

Observation 爆上下文

|

每步都拼历史，长任务把 context 撑爆

|

对 Observation 做摘要/截断，只保留关键结论

|

一句话记住 ReAct：「边走边想」，适合诊断、排查、探索这类「下一步不确定」的任务。 但如果流程是固定的、可预期的，ReAct 就有点浪费——因为它每一步都要重新「思考」，慢而且贵。这时候该换 Plan-and-Execute 上场。

三、Plan-and-Execute 模式：把「开单→派工→执行」写成管理流程

3.1 场景还原：售后经理的「先规划后执行」

回到那辆 Q5。真正在车间里，SA 不会「走一步想一步」地瞎转，因为售后流程是被 SOP（标准作业流程）锁死的：

  1. 开单（Plan）：一次规划好工单——项目「制动系统异响诊断」、工时 45 分钟、预估费用「诊断免费、维修另报」、优先级「高」。

  2. 派工（Dispatch）：把计划拆成可执行子任务——快保工位、擅长制动系统的李师傅、需要举升机。

  3. 执行（Execute）：李师傅按工单逐项做——路试 → 上架 → 读 OBD → 拍照。

  4. 质检/重规划（Re-plan）：如果质检发现「右后轮也有隐患」，就回炉改计划，追加一个「右后轮专项润滑检查」。

这个流程和 ReAct 最大的区别是：计划和执行是分离的。先一次性把「要干什么」想清楚、写下来（开单），再让执行环节机械地往下跑（派工+执行），中间除非有重大偏差，否则不回头重新规划。

3.2 Plan-and-Execute 的原理：Planner → Executor → Re-planner

Plan-and-Execute（先规划后执行）把 Agent 拆成三个角色：

<span leaf="">┌─────────────────────────────────────────────┐</span>

| Plan-and-Execute 术语

|

售后含义

|

谁来干

Planner（规划器）

|

生成完整工单计划（项目/工时/配件/依赖关系）

|

LLM 一次生成

| |

Executor（执行器）

|

按计划逐项执行，可串行可并行

|

确定性循环调用 Skill

| |

Re-planner（重规划器）

|

结果偏差时，修改剩余计划

|

LLM 条件触发

|

本质：把「思考」集中在前端（一次规划），把「执行」变成确定性的后端流水线。好处是：可预测、可审计、可并行、成本低（不需要每步都调用 LLM 思考）。

3.3 售后映射：Plan-and-Execute 就是「流程型」任务的骨架

| 售后流程

|

Plan-and-Execute 环节

|

说明

开单

|

Planner 生成计划

|

一次性输出维修项目、工时、费用、优先级

| |

派工

|

计划拆解 + 资源分配

|

工位/技师/配件按依赖关系排队

| |

执行

|

Executor 逐项执行

|

路试→读OBD→拍照→锁配件→维修，按顺序跑

| |

质检

|

Re-planner 条件触发

|

发现新问题才回炉，否则一路到底

|

共情力提升点：固定流程对客户体验反而是加分项——客户要的是「可预期的等待」和「靠谱的进度」。Plan-and-Execute 把流程锁死，进度条就能实时推给客户：「您的车已进入诊断环节，预计 45 分钟后出结果」。确定性，本身就是一种共情。

3.4 Java 代码骨架：Planner + Executor + Re-planner

<span leaf=""><span>/**</span></span>

这段代码跑出来的计划，就是售后经理开的那张工单：

<span leaf="">{</span>

注意看 parallel: true 的两个任务——读 OBD 和查配件历史互不依赖，可以并行。这就是 Plan-and-Execute 相对 ReAct 的核心优势之一：它能发现「可并行」的环节，而 ReAct 天然是串行的。

3.5 ReAct vs Plan-and-Execute：一张表讲清区别

| 维度

|

ReAct（边走边想）

|

Plan-and-Execute（先规划后执行）

思考方式

|

每一步都推理

|

只在规划时推理一次

| |

执行方式

|

严格串行

|

可串行 + 可并行

| |

适用任务

|

诊断、排查、探索（下一步不确定）

|

流程、SOP、批量（步骤固定）

| |

延迟

|

高（每步都调 LLM）

|

低（执行阶段不调 LLM）

| |

成本

|

高

|

低

| |

可审计性

|

弱（路径动态）

|

强（计划先固化，可回溯）

| |

灵活性

|

高（可随时改方向）

|

低（改方向需重规划）

| |

售后类比

|

SA 现场诊断

|

售后经理开单派工

|

关键认知：二者不是二选一，而是嵌套关系。真实生产里最常见的做法是——外层用 Plan-and-Execute 把流程锁死，内层的某个「诊断」子任务内部，再嵌一个 ReAct 循环去动态探索。这就像售后经理开好单（Plan），但李师傅诊断那一步（Execute 的一个子任务）还是要「边查边想」（ReAct）。

四、Single-Agent vs Multi-Agent：一个「全科医生」还是「专家会诊」

4.1 场景还原：两个截然不同的任务

还是这家 4S 店，我把两个真实任务摆在一起：

任务 A：客服打首保邀约电话。客户：「我这个月该做首保了吗？」客服小妹查一下保养记录，回一句「您这周六上午 10 点有工位，要不要帮您约？」——一条线，一个角色，几秒钟搞定。

任务 B：售后全流程。从张先生进店那一刻起，涉及接车、诊断、配件、维修、质检、交车六个环节，每个环节需要不同的专业知识、不同的系统权限、不同的判断标准。让一个「什么都会」的 Agent 从头干到尾，prompt 会写到 3000 字，上下文会爆，工具列表会乱，最后哪个环节都做不精。

这两个任务，就是 Single-Agent 和 Multi-Agent 的分野。

4.2 两种模式的本质

| | Single-Agent（单智能体）

|

Multi-Agent（多智能体）

角色

|

一个 Agent 干所有事

|

多个专家 Agent 分工

| |

上下文

|

一个 context 装下所有工具/prompt

|

每个 Agent 只带自己的工具/prompt

| |

协调

|

无需协调

|

需要通信/编排机制

| |

优点

|

简单、低延迟、低成本

|

职责清晰、context 隔离、可并行、可扩展

| |

缺点

|

任务复杂时 prompt 臃肿、能力稀释

|

协调开销、通信成本、调试复杂

| |

售后类比

|

全科医生（全流程 SA）

|

专家会诊（接车/诊断/配件/交车各司其职）

|

核心洞察：Multi-Agent 最大的价值不是「能力更强」，而是「上下文隔离 + 责任边界」。诊断 Agent 的 prompt 里不需要知道「交车话术怎么写」，配件 Agent 的工具列表里也不需要「OBD 读取」这个 Skill。每个 Agent 都更小、更专、更不容易出错——就像 4S 店里，接车 SA 和车间技师各司其职，谁也不用懂对方全部的话术。

4.3 Multi-Agent 的三种协作形态

Multi-Agent 不是「多开几个 Agent」那么简单，组织方式决定了它能解决什么问题：

<span leaf="">① Supervisor（监督者/调度者）模式 —— 售后经理式</span>

| 模式

|

售后场景

|

特点

|

适用

Supervisor

|

售后经理统一调度各环节

|

中心化，可控性强

|

有明确「总指挥」的全流程

| |

Pipeline

|

接车→诊断→维修→交车串行流水线

|

简单、顺序固定

|

流程固定、无需分支

| |

Collaborative

|

疑难杂症多方会诊

|

容错强、可交叉验证

|

复杂诊断、需要多视角

|

4.4 Java 代码骨架：一个 Supervisor 编排的多 Agent 售后系统

<span leaf=""><span>/**</span></span>

注意这段代码里最关键的一行：diagnosisAgent.run(intent, vin) 内部可以是上一节写的ReAct 循环。这正好呼应了前面的结论——Multi-Agent 是「骨架」，每个 Agent 内部用 ReAct 还是 Plan-and-Execute 是「血肉」，二者可以自由组合。

共情力提升点：Multi-Agent 的「责任边界」映射到售后，就是「该谁说话谁说话」。接车时是接车 SA 的温柔安抚，诊断时是技师的权威解释，交车时是服务顾问的贴心总结。客户在每个环节都听到「对的人说对的话」，这才是最高级的服务体验。

五、选型决策框架：一张图 + 一张表，从此不再纠结

5.1 决策树（先问三个问题）

<span leaf="">你的任务，下一步确定吗？</span>

5.2 选型矩阵（六维度打分）

| 维度

|

Single-Agent + ReAct

|

Single-Agent + Plan-and-Execute

|

Multi-Agent

任务复杂度

|

低-中

|

中

|

高

| |

流程确定性

|

低（动态探索）

|

高（固定流程）

|

中-高

| |

延迟要求

|

中

|

低（可并行）

|

中（有协调开销）

| |

成本预算

|

中

|

低

|

高（多 Agent 多调用）

| |

可解释/审计

|

弱

|

强

|

强（边界清晰）

| |

可扩展性

|

差

|

中

|

好（可增删专家）

|

5.3 售后场景的落地对照表（直接抄作业）

| 4S 售后场景

|

推荐模式

|

理由

客服首保邀约 / 简单咨询

|

Single-Agent + ReAct

|

单步、低延迟、够用

| |

事故车责任认定引导

|

Single-Agent + ReAct

|

多轮问答、动态引导

| |

工单开单 + 派工调度

|

Single-Agent + Plan-and-Execute

|

流程固定、需并行调度

| |

刹车异响诊断

|

Single-Agent + ReAct（或嵌套在 Plan 内）

|

探索型、边查边想

| |

售后全流程（接车→交车）

|

Multi-Agent + Supervisor

|

多环节、需责任隔离

| |

疑难故障会诊

|

Multi-Agent + Collaborative

|

多视角交叉验证

|

六、落地建议 + 避坑指南

6.1 给 4S 店售后的「最小可落地」推荐路径

别一上来就上 Multi-Agent。按这个顺序走，每一步都有增量价值：

  1. 第一步：客服场景上 Single-Agent + ReAct，先解决「单点、高频、低风险」的邀约和咨询。跑通 ReAct 循环，积累 Prompt 和工具设计经验。

  2. 第二步：工单开单场景上 Plan-and-Execute，把「开单→派工」流程固化，享受可并行、可审计的红利。

  3. 第三步：等前两步稳定了，再上 Multi-Agent + Supervisor，把接车、诊断、配件、交车拆成专家 Agent，逐步替换原来的单一编排。

架构演进，而不是架构跃迁。这跟我当年做政企项目一个道理——先单点验证，再横向复制，最后才做平台化拆分。

6.2 五大避坑清单

| 坑

|

说明

|

解法

过早 Multi-Agent

|

任务简单也拆一堆 Agent，调试地狱

|

先用 Single-Agent 跑通，复杂度上来再拆

| |

ReAct 无兜底

|

死循环、工具错选、超步数

| MAX_STEPS

 + 转人工 + 工具描述写清楚

| |

Plan 不设依赖

|

计划里的任务全串行，浪费并行机会

|

明确 deps 和 parallel 标记

| |

Context 无限膨胀

|

ReAct 每步都拼历史，长任务爆窗口

|

Observation 做摘要/截断，只留关键结论

| |

忽略可观测性

|

Agent 的「思考轨迹」是黑盒，出错查不到

|

每一步 Thought/Action/Observation 落日志，可回放

|

七、总结 & 下期预告

今天我把上一期那套「六站编排」往底层再挖了一层，回答了三个灵魂拷问：

① ReAct = SA 的「倾听→思考→行动」循环——边走边想，适合诊断、排查这类「下一步不确定」的任务；
② Plan-and-Execute = 「开单→派工→执行」的管理流程——先规划后执行，适合流程固定、需要审计和并行的任务；
③ Single vs Multi-Agent = 全科医生 vs 专家会诊——任务简单就一个 Agent 干，复杂了就拆成专家分工，核心是「上下文隔离 + 责任边界」。

三者不是竞争关系，而是组合关系：外层 Multi-Agent 搭骨架，中层 Plan-and-Execute 锁流程，内层 ReAct 做动态探索。真正的架构能力，是知道在每一层该放什么。

第3期预告：Java Agent 框架选型指南——Spring AI vs LangChain4J vs AgentScope Java 2.0，三维度对比（生态 / 学习曲线 / Java 贴合度），给出可落地的决策矩阵。同样是写 Agent，用哪个框架能少踩 80% 的坑？

互动话题：你们店里的售后流程，是「边走边想」多，还是「先开单再执行」多？有没有那种「流程太死，遇到特殊情况反而卡住」的瞬间？评论区聊聊，我下期拆解里面的架构问题！

📎 本文配套资源：

  • ReAct / Plan-and-Execute / Multi-Agent 三模式对比全景图（高清 PDF）

  • 完整代码仓库：agent-in-action/chapter-02-architecture-patterns

  • Spring AI + MCP 三大模式最小可运行 Demo

关于作者：34 岁，汽车电子技术专业出身，4 年奥迪/奔驰售后服务顾问 + 9 年 Java 架构与 AI Agent 开发经验，深谙汽车售后市场与车险理赔业务。用 Java 的确定性，驾驭 AI 的不确定性。在这里，Agent 不是概念，是车间里正在发生的事。