目录1、什么背名词必然翻车2、第一层ReAct 单循环——一切 Agent 的原型3、第二层Plan-and-Execute——把想和做拆开4、第三层Self-Reflection——给执行加一道校验闸5、第四层Multi-Agent——一个人干不完就拆角色模式一横向平级Peer-to-Peer模式二纵向层级Orchestrator-Worker6、面试官真正在考的三件事7、深度洞察演进的第一性原理7.1 架构不是四个选项而是一条补丁链7.2 什么时候不该升级架构7.3 工程落地的四个真实坑8、总结与展望1、什么背名词必然翻车面试对白面试官问说说现在 Agent 有哪些主流架构候选人答我知道 ReAct还有 Multi-Agent别的记不太清了。追问那能讲清楚各自的适用场景吗得到的回答是好像简单任务用单 Agent复杂任务用多 Agent——然后就是那句熟悉的你先回去等通知吧。这个回答的问题不在名字记得少而在它没有结构。名词是一堆平铺的点点是无法被评价的架构是一条有方向的线线才能体现你的判断力。视频给出的核心判断非常准确这道题看着是考名词背诵实际是在考你能不能把架构分层捋顺。很多人只会背框架名称分不清架构之间的层级区别面试官一眼就能看出来你只会调用现成模板没有梳理过整套执行逻辑。所以正确的回答姿势不是列举而是分层递进从最简单的一层开始每往上走一层先说清楚上一层出了什么问题再说这一层用什么手段解决了它。四层讲完你等于顺手把 Agent 的演进史讲了一遍——这才是吃透底层设计和套用现成模板的分水岭。面试对白也是大多数人的真实水平只记住了简单用单 Agent、复杂用多 Agent。题目的本质误区是只会背框架名称答法是逐层划分讲清边界。2、第一层ReAct 单循环——一切 Agent 的原型1、ReAct · Reason ActReAct 是所有 Agent 的根基没有任何额外分层。整个任务从头到尾只靠一个智能体完成不断循环三个动作思考Reason拿到问题先做推理判断当前信息够不够、要不要调用工具行动Act需要外部信息就发起一次工具调用搜索、查库、执行代码观察Observe把工具返回的结果读回来作为下一轮推理的输入。这个循环一直转到信息足够模型自己输出最终答案流程结束。用伪代码表示它的骨架其实短得惊人ReAct Loop骨架history [system_prompt, user_query] while not done: thought, action llm(history) # 思考这一步该干什么 if action is final_answer: return thought # 观察信息已足够收口 observation run_tool(action) # 行动真的去调工具 history.append((thought, action, observation)) if step MAX_STEPS: break # 唯一的保险丝它的适用场景是步骤少、路径清晰的简单查询——帮我查一下这家公司的融资轮次并总结这类任务 3~5 步就能收口。坑点也很致命任务步骤一多模型很容易越跑越偏陷入来回反复调用同一个工具的死循环。原因在于 ReAct 的每一步都是局部最优决策——它没有全局视野只能看见上一轮的观察结果于是很容易在同一个错误上反复打转或者跑到第十步时已经完全忘记最初的目标。第一层级 ReAct思考 → 行动 → 观察无任何额外分层适合步骤少、路径清晰的简单查询。3、第二层Plan-and-Execute——把想和做拆开Plan-and-Execute · 规划执行分离为了解决单循环容易跑偏的问题第二层做了一个非常朴素的架构动作把思考和执行拆成两个角色。规划模块Planner先把大任务拆成一条条清晰的子步骤一次性生成完整的执行方案——这一步是全局俯视模型必须先把终点想清楚执行模块Executor再一步步照着计划落地每走完一步还能对照实际结果回来重新调整方案Re-plan。适合步骤较长、有明确先后顺序的任务比如调研三家竞品 → 对比功能矩阵 → 输出选型建议这种天然有依赖链的工作。核心优势是不会跑着跑着忘记初始目标大任务拆碎之后单步的正确率要求降低整体出错概率大幅下降。这里藏着一个常被忽略的细节视频提到每走完一步还能对照结果重新调整方案。这句重新调整其实就是 Plan-and-Execute 与写死工作流Workflow的分界线——固定 DAG 的工作流不会 re-plan一旦第 2 步的现实与假设不符后面全错。真正的 Plan-and-Execute 必须带重规划回路。第二层级 Plan-and-Execute规划模块拆分任务生成方案执行模块逐步落地并对照结果调整。4、第三层Self-Reflection——给执行加一道校验闸Self-Reflection · 带自我校验的反思型架构在规划和执行之外第三层额外增加了一轮复盘环节每完成一轮动作Agent 会回头自查。视频把这个自查总结成三问非常实用可以直接当成 Prompt 模板来用刚才的操作有没有出错——校验动作层面的正确性工具参数、返回格式、边界条件拿到的信息能不能支撑结论——校验逻辑层面的充分性证据是否真的推出了结论有没有遗漏关键条件——校验完整性的一旦发现问题立刻回退重新执行。适合对结果准确度要求很高的场景比如数据核对、内容校验、合规审查。关键作用是主动修正幻觉避免一步错、步步错。Reflection 校验闸可直接用作 Prompt你在完成每一步后必须先自检再继续 1. 这一步的操作是否符合预期有无参数错误、格式错误 2. 得到的证据是否足以支撑你的结论若不足缺什么 3. 是否遗漏了约束条件时间范围、口径、边界值 → 任一答案为否立即回退不要带着错误往下走。但要说清楚它的代价反思不是免费的。它至少让 token 消耗翻倍、延迟显著上升而且反思本身也可能是错的——一个过度自我怀疑的 Agent 会把正确答案改错。工程上通常要限制最大反思轮数1~2 轮并只在高风险节点触发而不是每步都开。第三层级 Self-Reflection每轮动作后回头自查三问发现问题立即回退重执行。5、第四层Multi-Agent——一个人干不完就拆角色第四层级Multi-Agent · 多智能体协作单个 Agent 兼顾所有工作很容易顾此失彼——上下文被塞满、指令互相冲突、专业深度不够。于是就有了第四层拆分角色分工干活。视频给出了两种拓扑这是最有价值的分类模式一横向平级Peer-to-Peer多个专业 Agent 各司其职有人负责检索信息、有人负责整理数据、有人负责输出文案彼此互相交换信息、协同完成任务。它的本质是专业分工 消息传递适合流程本身就比较并行、角色边界清晰的场景。风险是通信开销大容易出现互相等对方或者信息在传递中被稀释。模式二纵向层级Orchestrator-Worker设立一个总调度 Agent负责拆解任务、分配工作底下多个执行 Agent分头落地最后由调度者统一汇总结果。这是目前工业界最常用的形态也是各家Deep Research类产品的典型结构。它的优点是控制流集中、可观测性好缺点是调度者本身成为瓶颈与单点且对调度者的拆解能力要求极高。适用场景体量庞大、环节繁杂、需要不同专业能力的复杂任务。第四层级 Multi-Agent横向平级专业分工互换信息与纵向层级总调度拆解 执行 Agent 分头落地。6、面试官真正在考的三件事四层讲完视频最后把评分标准直接摊开了——这部分比架构本身更值得记因为它解释了什么样的回答算及格考察点不及格的回答及格的回答① 由浅入深分层讲解零散地报名字ReAct、Plan-Execute、Multi-Agent……按单 Agent → 分阶段执行 → 自我反思 → 多智能体协作逐层递进逻辑一目了然② 讲清每种架构的适用边界笼统地说复杂任务就用多 Agent要分清短任务用单循环、长流程用规划执行、高准确度需求加反思、多专业协同才用多智能体③ 看清架构迭代的本质把四层当成四套并列的可选项所有升级都是为了解决上一层出现的问题是一条病因—药方链第三点尤其关键。视频用一句话把它压缩到了极致序号病因药方对应手段1单循环容易跑偏拆分规划与执行先定目标和方案再动手执行避免边做边偏2执行容易出错加上反思校验每步执行后自检 / 复盘发现偏差及时纠正3单人能力有限拆分成多角色协作分工协作各司其职发挥多角色专长面试评分视角分层讲解、适用边界、迭代本质——三条标准对应结构 / 判断 / 洞察三种能力。视频结尾那句总结也在这张表里只会背架构名称只能应付基础提问讲清每层解决了什么痛点、适配什么任务才算真正吃透底层设计。7、深度洞察演进的第一性原理视频给出了很好的骨架但作为工程视角的补充还有三层东西值得往下挖。7.1 架构不是四个选项而是一条补丁链把四层架构理解成四种可选的方案是初学者最容易掉进去的陷阱。更准确的模型是它们是一层层叠加的补丁后一层默认包含前一层。Plan-and-Execute 里的执行模块本质上还是 ReAct 循环Self-Reflection 是在这个循环外面套了一个校验器Multi-Agent 则是把多个带反思的 Plan-and-Execute组合起来。这解释了一个很实际的现象你不需要选择某个架构你需要叠加到刚好够用的层级。真实系统的配置往往长这样真实系统的分层叠加示意Orchestrator总调度 ├── 任务拆解Plan-and-Execute ├── 每个子任务ReAct 循环 工具集 ├── 关键节点Self-Reflection 校验仅高风险处触发 └── 汇总层一致性检查跨 Agent 的结果对账7.2 什么时候不该升级架构面试里能把架构讲全是一回事工程里敢说这里不需要升级是另一回事。判断标准其实只有一个当前层级暴露的问题是不是真的在伤害你的业务指标任务平均 3 步内收敛、准确率已经 95% —— 上 Plan-and-Execute 只会增加延迟不会增加价值输出是一次性文案、错了人工一眼能改 —— 每步反思的收益远小于成本任务本身是串行强依赖、无法并行拆分 —— 拆成 Multi-Agent 只会引入通信损耗与协调失败单 Agent 上下文放得下、指令不冲突 —— 多 Agent 带来的主要是调试复杂度。一条经验法则能用固定工作流Workflow解决的就别上 Agent能用单 Agent 解决的就别上 Multi-Agent。架构复杂度是负债只有在它换来的收益明确可衡量时才值得背。7.3 工程落地的四个真实坑坑一幻觉在架构里会被放大而不是被抵消。Plan-and-Execute 中规划器编造了一个不存在的子任务执行器会老老实实把它做完Multi-Agent 中一个 Agent 的错误结论会被下游当成事实继续推理。这也是为什么 Self-Reflection 必须在跨 Agent 的边界上也设一道校验而不只是在单 Agent 内部。坑二上下文管理与架构同等重要。四层架构解决的是控制流但真正决定长任务成败的往往是上下文怎么裁剪、怎么压缩、怎么持久化。一个 ReAct 循环如果每轮都把完整历史塞进去第 20 步就会超出窗口或注意力涣散——效果等同于跑偏。坑三可观测性决定你能不能用。层级越深出错定位越难。生产系统必须记录每一步的思考、工具入参出参、耗时与 token 消耗否则 Multi-Agent 一旦跑歪你连是哪一层出的问题都说不清。坑四评估比架构更稀缺。哪种架构更好这个问题只有在你有稳定评测集任务集 判定标准时才有答案。没有评测架构选型就只是审美偏好——这也是很多团队把 Agent 做得越来越复杂、效果却越来越玄学的原因。层级核心机制解决的问题代价 / 新病典型场景L1 ReAct思考-行动-观察单循环让模型能调工具、拿外部信息步骤一多就跑偏、死循环简单查询、3~5 步任务L2 Plan-and-Execute规划与执行分离 重规划长任务丢失初始目标规划质量即上限多一次串行开销多步骤、强依赖的研究/处理类任务L3 Self-Reflection每轮自查三问 回退重执行错误累积、幻觉传播成本翻倍、延迟上升、可能过度自我怀疑数据核对、合规校验、高准确度输出L4 Multi-Agent角色拆分平级/层级单 Agent 能力与上下文上限通信开销、协调失败、调试困难体量大、环节多、需多专业能力8、总结与展望核心要点回顾四层是一条链不是四个选项ReAct → Plan-and-Execute → Self-Reflection → Multi-Agent每层都是对上一层缺陷的针对性修补后一层通常包含前一层。每层都要能说出病因 药方跑偏→拆规划出错→加反思能力有限→拆角色。这句话就是整套架构的压缩包。边界比名词重要短任务用单循环、长流程用规划执行、高准确度加反思、多专业协同才用多智能体——笼统说复杂就用 Multi-Agent直接减分。复杂度是负债能用固定工作流就别上 Agent能用单 Agent 就别上 Multi-Agent收益必须可衡量。真正的分水岭是工程能力上下文管理、可观测性、评测体系这三件事对最终效果的影响往往大于架构选型本身。趋势预判架构本身正在下沉。早期需要靠 Prompt 编排显式实现的规划、反思、协作正在被模型的原生推理能力更长的思维链、内建的自我校验和框架层DAG 编排、状态机、检查点恢复逐步吸收。未来的差异不会体现在你用了哪一层架构而会体现在你如何定义任务的正确性、如何组织上下文、如何做可验证的评估——这些恰恰是模型替代不了的部分。给开发者的一句话建议不要问我该用哪种 Agent 架构要问我的任务在哪一步会失败、失败的代价有多大。答案会自己把架构选出来——这比背四个名词有用得多。 
长河君 · 2026/11/2 1:55:03 · 阅读 1.2k Agent 架构的四层递进：从 ReAct 到多智能体，别只记住名词
目录1、什么背名词必然翻车2、第一层ReAct 单循环——一切 Agent 的原型3、第二层Plan-and-Execute——把想和做拆开4、第三层Self-Reflection——给执行加一道校验闸5、第四层Multi-Agent——一个人干不完就拆角色模式一横向平级Peer-to-Peer模式二纵向层级Orchestrator-Worker6、面试官真正在考的三件事7、深度洞察演进的第一性原理7.1 架构不是四个选项而是一条补丁链7.2 什么时候不该升级架构7.3 工程落地的四个真实坑8、总结与展望1、什么背名词必然翻车面试对白面试官问说说现在 Agent 有哪些主流架构候选人答我知道 ReAct还有 Multi-Agent别的记不太清了。追问那能讲清楚各自的适用场景吗得到的回答是好像简单任务用单 Agent复杂任务用多 Agent——然后就是那句熟悉的你先回去等通知吧。这个回答的问题不在名字记得少而在它没有结构。名词是一堆平铺的点点是无法被评价的架构是一条有方向的线线才能体现你的判断力。视频给出的核心判断非常准确这道题看着是考名词背诵实际是在考你能不能把架构分层捋顺。很多人只会背框架名称分不清架构之间的层级区别面试官一眼就能看出来你只会调用现成模板没有梳理过整套执行逻辑。所以正确的回答姿势不是列举而是分层递进从最简单的一层开始每往上走一层先说清楚上一层出了什么问题再说这一层用什么手段解决了它。四层讲完你等于顺手把 Agent 的演进史讲了一遍——这才是吃透底层设计和套用现成模板的分水岭。面试对白也是大多数人的真实水平只记住了简单用单 Agent、复杂用多 Agent。题目的本质误区是只会背框架名称答法是逐层划分讲清边界。2、第一层ReAct 单循环——一切 Agent 的原型1、ReAct · Reason ActReAct 是所有 Agent 的根基没有任何额外分层。整个任务从头到尾只靠一个智能体完成不断循环三个动作思考Reason拿到问题先做推理判断当前信息够不够、要不要调用工具行动Act需要外部信息就发起一次工具调用搜索、查库、执行代码观察Observe把工具返回的结果读回来作为下一轮推理的输入。这个循环一直转到信息足够模型自己输出最终答案流程结束。用伪代码表示它的骨架其实短得惊人ReAct Loop骨架history [system_prompt, user_query] while not done: thought, action llm(history) # 思考这一步该干什么 if action is final_answer: return thought # 观察信息已足够收口 observation run_tool(action) # 行动真的去调工具 history.append((thought, action, observation)) if step MAX_STEPS: break # 唯一的保险丝它的适用场景是步骤少、路径清晰的简单查询——帮我查一下这家公司的融资轮次并总结这类任务 3~5 步就能收口。坑点也很致命任务步骤一多模型很容易越跑越偏陷入来回反复调用同一个工具的死循环。原因在于 ReAct 的每一步都是局部最优决策——它没有全局视野只能看见上一轮的观察结果于是很容易在同一个错误上反复打转或者跑到第十步时已经完全忘记最初的目标。第一层级 ReAct思考 → 行动 → 观察无任何额外分层适合步骤少、路径清晰的简单查询。3、第二层Plan-and-Execute——把想和做拆开Plan-and-Execute · 规划执行分离为了解决单循环容易跑偏的问题第二层做了一个非常朴素的架构动作把思考和执行拆成两个角色。规划模块Planner先把大任务拆成一条条清晰的子步骤一次性生成完整的执行方案——这一步是全局俯视模型必须先把终点想清楚执行模块Executor再一步步照着计划落地每走完一步还能对照实际结果回来重新调整方案Re-plan。适合步骤较长、有明确先后顺序的任务比如调研三家竞品 → 对比功能矩阵 → 输出选型建议这种天然有依赖链的工作。核心优势是不会跑着跑着忘记初始目标大任务拆碎之后单步的正确率要求降低整体出错概率大幅下降。这里藏着一个常被忽略的细节视频提到每走完一步还能对照结果重新调整方案。这句重新调整其实就是 Plan-and-Execute 与写死工作流Workflow的分界线——固定 DAG 的工作流不会 re-plan一旦第 2 步的现实与假设不符后面全错。真正的 Plan-and-Execute 必须带重规划回路。第二层级 Plan-and-Execute规划模块拆分任务生成方案执行模块逐步落地并对照结果调整。4、第三层Self-Reflection——给执行加一道校验闸Self-Reflection · 带自我校验的反思型架构在规划和执行之外第三层额外增加了一轮复盘环节每完成一轮动作Agent 会回头自查。视频把这个自查总结成三问非常实用可以直接当成 Prompt 模板来用刚才的操作有没有出错——校验动作层面的正确性工具参数、返回格式、边界条件拿到的信息能不能支撑结论——校验逻辑层面的充分性证据是否真的推出了结论有没有遗漏关键条件——校验完整性的一旦发现问题立刻回退重新执行。适合对结果准确度要求很高的场景比如数据核对、内容校验、合规审查。关键作用是主动修正幻觉避免一步错、步步错。Reflection 校验闸可直接用作 Prompt你在完成每一步后必须先自检再继续 1. 这一步的操作是否符合预期有无参数错误、格式错误 2. 得到的证据是否足以支撑你的结论若不足缺什么 3. 是否遗漏了约束条件时间范围、口径、边界值 → 任一答案为否立即回退不要带着错误往下走。但要说清楚它的代价反思不是免费的。它至少让 token 消耗翻倍、延迟显著上升而且反思本身也可能是错的——一个过度自我怀疑的 Agent 会把正确答案改错。工程上通常要限制最大反思轮数1~2 轮并只在高风险节点触发而不是每步都开。第三层级 Self-Reflection每轮动作后回头自查三问发现问题立即回退重执行。5、第四层Multi-Agent——一个人干不完就拆角色第四层级Multi-Agent · 多智能体协作单个 Agent 兼顾所有工作很容易顾此失彼——上下文被塞满、指令互相冲突、专业深度不够。于是就有了第四层拆分角色分工干活。视频给出了两种拓扑这是最有价值的分类模式一横向平级Peer-to-Peer多个专业 Agent 各司其职有人负责检索信息、有人负责整理数据、有人负责输出文案彼此互相交换信息、协同完成任务。它的本质是专业分工 消息传递适合流程本身就比较并行、角色边界清晰的场景。风险是通信开销大容易出现互相等对方或者信息在传递中被稀释。模式二纵向层级Orchestrator-Worker设立一个总调度 Agent负责拆解任务、分配工作底下多个执行 Agent分头落地最后由调度者统一汇总结果。这是目前工业界最常用的形态也是各家Deep Research类产品的典型结构。它的优点是控制流集中、可观测性好缺点是调度者本身成为瓶颈与单点且对调度者的拆解能力要求极高。适用场景体量庞大、环节繁杂、需要不同专业能力的复杂任务。第四层级 Multi-Agent横向平级专业分工互换信息与纵向层级总调度拆解 执行 Agent 分头落地。6、面试官真正在考的三件事四层讲完视频最后把评分标准直接摊开了——这部分比架构本身更值得记因为它解释了什么样的回答算及格考察点不及格的回答及格的回答① 由浅入深分层讲解零散地报名字ReAct、Plan-Execute、Multi-Agent……按单 Agent → 分阶段执行 → 自我反思 → 多智能体协作逐层递进逻辑一目了然② 讲清每种架构的适用边界笼统地说复杂任务就用多 Agent要分清短任务用单循环、长流程用规划执行、高准确度需求加反思、多专业协同才用多智能体③ 看清架构迭代的本质把四层当成四套并列的可选项所有升级都是为了解决上一层出现的问题是一条病因—药方链第三点尤其关键。视频用一句话把它压缩到了极致序号病因药方对应手段1单循环容易跑偏拆分规划与执行先定目标和方案再动手执行避免边做边偏2执行容易出错加上反思校验每步执行后自检 / 复盘发现偏差及时纠正3单人能力有限拆分成多角色协作分工协作各司其职发挥多角色专长面试评分视角分层讲解、适用边界、迭代本质——三条标准对应结构 / 判断 / 洞察三种能力。视频结尾那句总结也在这张表里只会背架构名称只能应付基础提问讲清每层解决了什么痛点、适配什么任务才算真正吃透底层设计。7、深度洞察演进的第一性原理视频给出了很好的骨架但作为工程视角的补充还有三层东西值得往下挖。7.1 架构不是四个选项而是一条补丁链把四层架构理解成四种可选的方案是初学者最容易掉进去的陷阱。更准确的模型是它们是一层层叠加的补丁后一层默认包含前一层。Plan-and-Execute 里的执行模块本质上还是 ReAct 循环Self-Reflection 是在这个循环外面套了一个校验器Multi-Agent 则是把多个带反思的 Plan-and-Execute组合起来。这解释了一个很实际的现象你不需要选择某个架构你需要叠加到刚好够用的层级。真实系统的配置往往长这样真实系统的分层叠加示意Orchestrator总调度 ├── 任务拆解Plan-and-Execute ├── 每个子任务ReAct 循环 工具集 ├── 关键节点Self-Reflection 校验仅高风险处触发 └── 汇总层一致性检查跨 Agent 的结果对账7.2 什么时候不该升级架构面试里能把架构讲全是一回事工程里敢说这里不需要升级是另一回事。判断标准其实只有一个当前层级暴露的问题是不是真的在伤害你的业务指标任务平均 3 步内收敛、准确率已经 95% —— 上 Plan-and-Execute 只会增加延迟不会增加价值输出是一次性文案、错了人工一眼能改 —— 每步反思的收益远小于成本任务本身是串行强依赖、无法并行拆分 —— 拆成 Multi-Agent 只会引入通信损耗与协调失败单 Agent 上下文放得下、指令不冲突 —— 多 Agent 带来的主要是调试复杂度。一条经验法则能用固定工作流Workflow解决的就别上 Agent能用单 Agent 解决的就别上 Multi-Agent。架构复杂度是负债只有在它换来的收益明确可衡量时才值得背。7.3 工程落地的四个真实坑坑一幻觉在架构里会被放大而不是被抵消。Plan-and-Execute 中规划器编造了一个不存在的子任务执行器会老老实实把它做完Multi-Agent 中一个 Agent 的错误结论会被下游当成事实继续推理。这也是为什么 Self-Reflection 必须在跨 Agent 的边界上也设一道校验而不只是在单 Agent 内部。坑二上下文管理与架构同等重要。四层架构解决的是控制流但真正决定长任务成败的往往是上下文怎么裁剪、怎么压缩、怎么持久化。一个 ReAct 循环如果每轮都把完整历史塞进去第 20 步就会超出窗口或注意力涣散——效果等同于跑偏。坑三可观测性决定你能不能用。层级越深出错定位越难。生产系统必须记录每一步的思考、工具入参出参、耗时与 token 消耗否则 Multi-Agent 一旦跑歪你连是哪一层出的问题都说不清。坑四评估比架构更稀缺。哪种架构更好这个问题只有在你有稳定评测集任务集 判定标准时才有答案。没有评测架构选型就只是审美偏好——这也是很多团队把 Agent 做得越来越复杂、效果却越来越玄学的原因。层级核心机制解决的问题代价 / 新病典型场景L1 ReAct思考-行动-观察单循环让模型能调工具、拿外部信息步骤一多就跑偏、死循环简单查询、3~5 步任务L2 Plan-and-Execute规划与执行分离 重规划长任务丢失初始目标规划质量即上限多一次串行开销多步骤、强依赖的研究/处理类任务L3 Self-Reflection每轮自查三问 回退重执行错误累积、幻觉传播成本翻倍、延迟上升、可能过度自我怀疑数据核对、合规校验、高准确度输出L4 Multi-Agent角色拆分平级/层级单 Agent 能力与上下文上限通信开销、协调失败、调试困难体量大、环节多、需多专业能力8、总结与展望核心要点回顾四层是一条链不是四个选项ReAct → Plan-and-Execute → Self-Reflection → Multi-Agent每层都是对上一层缺陷的针对性修补后一层通常包含前一层。每层都要能说出病因 药方跑偏→拆规划出错→加反思能力有限→拆角色。这句话就是整套架构的压缩包。边界比名词重要短任务用单循环、长流程用规划执行、高准确度加反思、多专业协同才用多智能体——笼统说复杂就用 Multi-Agent直接减分。复杂度是负债能用固定工作流就别上 Agent能用单 Agent 就别上 Multi-Agent收益必须可衡量。真正的分水岭是工程能力上下文管理、可观测性、评测体系这三件事对最终效果的影响往往大于架构选型本身。趋势预判架构本身正在下沉。早期需要靠 Prompt 编排显式实现的规划、反思、协作正在被模型的原生推理能力更长的思维链、内建的自我校验和框架层DAG 编排、状态机、检查点恢复逐步吸收。未来的差异不会体现在你用了哪一层架构而会体现在你如何定义任务的正确性、如何组织上下文、如何做可验证的评估——这些恰恰是模型替代不了的部分。给开发者的一句话建议不要问我该用哪种 Agent 架构要问我的任务在哪一步会失败、失败的代价有多大。答案会自己把架构选出来——这比背四个名词有用得多。