Part 0.5 Agent 模式全景：30 种模式其实是同一棵树的枝
墨叔：老哥，你在 Part 1 看到的 ReAct，是我故意先给你看的最朴素一支。它简单、好懂，但如果你以为”agent 就是 ReAct”，就像以为”做菜就是一口锅煮到底”——能熟，但永远做不出宴席。这一 Part 把镜头拉远，让你看全：市面上成名的 agent 模式，认真数有 30 种上下，但它们根本不是 30 个独立东西，而是几个控制流旋钮拧出来的不同组合。看懂这张图，你以后再听到任何新”模式”名词，都能三秒归位。
0.1 为什么模式这么多：都是控制流旋钮的组合
老哥，你先停一下，别去背名字。我问你一个更根本的问题：一个 agent 跑起来，本质上在控制什么？
你写 Go 服务时，一段业务逻辑跑起来，你其实也在控制几件事：是先查库再算（顺序），还是几个 goroutine 一起查（并行）？出错是立刻返回，还是重试几次（容错）？一个请求交给一个 handler，还是按类型路由到不同 handler（分发）？这些不就是”控制流”吗？你 day one 就在想这些。
agent 也一样。所谓”模式”，剥掉花哨的名字，就是在调下面这四个旋钮：
| 旋钮 | 问的是 | 常见档位 |
|---|---|---|
| 怎么想（推理结构） | 一步续写，还是先规划，还是多路径搜？ | 单链 / 显式规划 / 树·图搜索 / 双系统 |
| 怎么看（反馈机制） | 一次成型，还是自己复盘，还是别人挑刺？ | 一次性 / 自我反思 / 外部批评 |
| 怎么做（行动结构） | 串行调一个工具，还是并行、路由、链式？ | 串行 / 并行 / 路由 / 链式 |
| 怎么协作（多体） | 单打，还是分工种，还是互相辩论？ | 单一 / 编排 / 辩论 / 角色扮演 |
你品一下这个类比。agent 模式，本质上就像做菜的流程设计：备料顺序怎么排（怎么想）、尝一口咸淡再调（怎么看）、几个灶台同时开火（怎么做）、后厨几个人分工（怎么协作）。不同的菜，只是这几件事的组合不同。没有哪个厨师会发明”30 种完全不同的做菜哲学”，他只是在调这几根旋钮。
那 ReAct 在这张图里是什么位置？它是四个旋钮全拧到”最简单一档”的默认组合：
- 怎么想 = 单链（走一步看一步，不提前规划）
- 怎么看 = 一次性（模型说完了就完了，不回头反思）
- 怎么做 = 串行（一次调一个工具，等结果再想）
- 怎么协作 = 无（就它自己一个）
所以 ReAct 不是”一种模式”，它是基准点。后面你会看到，Reflexion 只是把”怎么看”从一次性拧到了”自我反思”；ReWOO / Plan-and-Execute 把”怎么想”从单链拧到了”先规划”；ToT 把”怎么想”拧到了”树状搜索”；Orchestrator-Workers 把”怎么协作”拧到了”分工种”。每一个”新模式”，几乎都能描述成”在 ReAct 基础上改了哪个旋钮”。
为了让你彻底建立这个直觉，我给你一张”旋钮坐标矩阵”——把几种代表模式直接标到坐标上，你就知道它们差在哪了：
| 模式 | 怎么想 | 怎么看 | 怎么做 | 怎么协作 |
|---|---|---|---|---|
| ReAct | 单链 | 一次性 | 串行 | 无 |
| ReWOO | 先规划 | 一次性 | 批量填空 | 无 |
| Plan-and-Execute | 先规划 | 一次性 | 串行 | 无 |
| Reflexion | 单链 | 自我反思 | 串行 | 无 |
| ToT | 树搜索 | 评估剪枝 | 分支探索 | 无 |
| Parallelization | 单链 | 一次性 | 并行 | 无 |
| Orchestrator-Workers | 中心规划 | 一次性 | 派活 | 分工种 |
| Evaluator-Optimizer | 单链 | 外部批评 | 迭代 | 生成+评估 |
你看，这张表里每个模式就是一行坐标。新名词来了，你往表里填四个格子，立刻知道它和谁近、改了哪根线。这就是”旋钮视角”的威力——30 种模式，坍缩成 4 个维度的取值组合。
这就解释了为什么模式这么多——因为旋钮组合爆炸。但你一旦有了”旋钮视角”，任何新名词扔过来，你先问”它拧了哪个旋钮”，立刻就归位了，根本不用背。
老哥，你再想想你自己的经验。你接需求时，是不是也先判断”这个需求是 IO 密集还是 CPU 密集、要不要并发、失败要不要重试”？你其实一直在做”模式选择”，只不过对象是你自己的代码。agent 模式选择，和这个一模一样，只不过决策源从你变成了模型。
【思考题】
- 你说 ReAct 是”四个旋钮全取最简档”。如果只把”怎么做”从串行拧成并行，但其他三档不变，这会解决什么新问题、又带来什么新麻烦？
- 为什么”怎么看”（反馈机制）这个旋钮特别重要？一个”怎么看=一次性”的 agent，哪怕是多 agent 协作，还可能犯什么错？
- 你写代码时做过哪些”控制流旋钮”的选择？举一个，并对应到上面四个旋钮里的哪一个。
【参考答案】
- 把”怎么做”从串行拧成并行（这就是后面 0.5 节会讲的 Parallelization 模式），能解决”子任务彼此独立、串行太慢”的问题——比如同时查 5 个 API 再汇总，串行要 5 倍耗时，并行只受最慢那个限制。但新麻烦是：并行任务之间如果有依赖（A 的结果喂给 B），就不能真并行，得先做依赖分析（LLMCompiler 就是在解决这个）；而且并行意味着更多 token、更多并发调用、更难的错误处理（一个挂了其他怎么办）。旋钮每拧一档，都同时带来能力和代价，没有免费午餐。
- “怎么看”决定 agent 能不能自我纠错。一个”一次性”的 agent，哪怕它人多（多 agent），也可能集体犯同一个错——因为没人回头检查。比如几个 agent 基于同一个错误前提各自分工，最后汇总出一个看起来很完整、但前提就错了的结论。这就是为什么 Evaluator-Optimizer（生成+挑刺）和 Reflexion（反思）这种模式独立存在：它们专门补”看”这一档。多 agent 解决的是”分工与并行”，不自动解决”质量校验”。
- 例子很多。比如你”根据请求类型路由到不同 handler”——对应”怎么做=路由”（Routing 模式）；“几个微服务并发调用再聚合”——对应”怎么做=并行”；“先出技术方案文档、再按文档写代码”——对应”怎么想=显式规划”（Plan-and-Execute）；“CI 跑挂了读错误日志重试”——对应”怎么看=自我反思”（Reflexion 的微缩版）。你会发现，你早就在用这些模式的思想，只是决策是你写死的，而 agent 把决策交给了模型。
老哥，这一节的“旋钮视角”有个立竿见影的用处：你以后读任何 agent 框架的文档（LangChain、LangGraph、AutoGen、CrewAI、甚至 Claude Code 自己），别被它的名词和示意图吓住，先问一句“它在调哪根旋钮”。比如 LangGraph 本质是把“怎么做（行动结构）”这个旋钮做成了可视化状态机——你画一张图，规定“在这个节点调哪个工具、下一步去哪”，把控制流从“模型临时决定”变成“你预先画死、但图里可以条件分支”；AutoGen 是把“怎么协作”做成“多个 agent 对话”，让“谁调谁”在对话里自然涌现；而 Reflexion 那类则是把“怎么看”做成了独立的一跳。你一旦会拆，市面上的框架就不再是 30 个黑盒，而是 4 个旋钮的不同封装——你甚至能反过来想：“我这个需求，现有框架的哪个旋钮露出得不够，我得自己补一层。”到这一步，你读框架文档的速度和判断力会脱胎换骨。
老哥，你可能会担心：四个旋钮组合爆炸，我记不住怎么办？我的答案很反直觉——你恰恰不该去记。你记的不是 30 种模式，而是那四个旋钮和“ReAct 是基准点”这件事。新人最容易犯的错，就是拿到需求先翻“模式清单”对号入座，结果被清单绑架。正确肌肉记忆是反过来的：拿到需求，先问“它卡在哪个旋钮”，答案自己浮现，你再去查那个旋钮下的代表模式长什么样。久而久之，你看到任何新名词，第一反应不是“这又是什么新东西”，而是“它拧了哪根旋钮”——这一瞬间，30 种模式在你脑子里就坍缩成了 4 个维度，记忆负担归零。这和你学设计模式一个道理：记 23 个 GoF 模式不如记“创建/结构/行为”三大类加几条原则。
小结：agent 模式 = 四个控制流旋钮（想/看/做/协作）的不同组合；ReAct 是全部取最简档的基准点，多数”新模式”只是拧动了其中某个旋钮。有了旋钮视角，再多的模式名词都能三秒归位，无需死记。
0.2 基础推理零件：最底层的”怎么想”
在讲那些花哨的 agent 模式之前，得先认识几个最底层的推理零件。它们本身不算完整的 agent，但几乎被嵌进所有复杂模式里当”脑子”用。你把它们理解成”怎么想”这一旋钮的几种基础档位。
CoT 思维链（Chain of Thought）。2022 年 Google 那篇论文发现的：只要让模型把推理过程”一步步写出来”，而不是憋一个最终答案，数学题、逻辑题的准确率会大幅跳升。机制朴素到可笑——你提示里加一句”让我们一步步思考”，模型就真的会先写中间步骤，再给结论。老哥你品一下：这不就是你写复杂函数前，先在注释里把逻辑捋一遍吗？模型没有”注释”这个概念，CoT 就是强迫它把那个”注释”显式说出来，好让后面的推理踩在前面可靠的台阶上。
为什么 CoT 有效，值得你深想一层。长推理链里，模型每一步都依赖前一步的输出当上下文，CoT 把”中间状态”显式留在了 token 流里，让后续推理踩在可见的台阶上，而不是在模型的隐藏状态里”凭空跃迁”。相当于把”工作记忆”外化成了文字。一旦跳过中间步骤直接要答案，模型就得在内部一次性完成所有推理，错误会累积且无法自检。所以 CoT 本质是”给推理过程一个可观察、可纠错的工作台”——这和你写代码时”把中间变量打出来看”是一个道理。
Zero-shot CoT。就是 CoT 的零样本版——不需要给例子，光一句”let’s think step by step”就能触发。说明这能力模型本来就藏着，只是默认不吐出来，得你戳一下。这也给了一个工程启示：很多”模型不会”其实是”你没让它展示”，一句提示就能唤醒，未必需要改架构。
Self-Consistency 自洽。这是 CoT 的加强：同一个问题，让模型用不同随机种子跑好几遍推理链，每条链各自给个答案，最后投票取多数。本质是用”数量换稳健”——单条链可能走偏，但多条链同时走偏的概率低。老哥，这不就是你对关键计算结果”跑两次单测取一致”的思路吗？只不过模型这边的”单测”就是多次采样。它真正管用的区间是：有离散可验证答案、且单条链容易因随机性走偏的任务（如数学、多选推理）。对主观题、创意题、连续答案空间，投票救不了。
Chain of Code。这个有意思：遇到需要精确计算或模拟的问题，不让模型用文字推理，而是让它写一段代码、交给解释器跑，用代码执行的结果代替文字推理。比如”篮子里有 3 个苹果，又放进去 2 个，吃掉 1 个，剩几个”——模型与其在文字里绕，不如直接写 print(3+2-1)。这恰恰点破了 agent 的一个真相：模型最不擅长的精确算术和状态追踪，恰恰是代码最擅长的。Chain of Code 是把”该用代码的地方交给代码”这件事，从 agent 的工具调用层面制度化了。你做后端时早已这么干了：用代码管状态，用业务逻辑描述意图，只是没意识到这和 agent 的设计哲学同源。
这四个零件，单独用不算 agent（没有循环、没有工具、没有持续行动），但它们是”怎么想”这一旋钮的地基。你后面看到的 ReAct 用的是单链推理，Plan-and-Execute 用的是显式规划，ToT 用的是树状搜索——而这些更花哨的”怎么想”，底层往往就是 CoT 或 Self-Consistency 在撑着。理解零件，你才不会把”模式”当成黑盒。
老哥，这里有个你肯定有共鸣的连接。你在 Go 里写业务逻辑，是不是也分”拍脑袋直接写”和”先画流程图再写”？CoT 就是前者（边写边想），Plan-and-Execute 就是后者。而 Self-Consistency，就是你不敢确定一段并发逻辑对不对时，多跑几遍压测看结果稳不稳。模型用的招，和你用的招，根上是同一套工程直觉。
【思考题】
- CoT 为什么有效？仅仅是”模型多写了几句话”而已吗，还是有更深的机制？
- Self-Consistency 用”投票取多数”来提升准确率，这个思路在什么情况下会失效？
- Chain of Code 主张”该用代码的地方交给代码”。结合你做后端的经验，模型（LLM）和代码（传统程序）各自最擅长什么、最不擅长什么？
【参考答案】
- 有效不止是因为”多写了话”。更深的机制是：长推理链里，模型每一步都依赖前一步的输出当上下文，CoT 把”中间状态”显式留在了 token 流里，让后续推理踩在可见的台阶上，而不是在模型的隐藏状态里”凭空跃迁”。相当于把”工作记忆”外化成了文字。一旦跳过中间步骤直接要答案，模型就得在内部一次性完成所有推理，错误会累积且无法自检。所以 CoT 本质是”给推理过程一个可观察、可纠错的工作台”。
- 失效场景：一是问题本身没有稳定正确答案（主观题、创意题），多数票不代表更好；二是所有采样都基于同一个错误前提，那么”多数”也只是错得更一致而已，投票救不了；三是答案空间是连续的或极大的（如生成一个数值、一段长文本），根本没法简单”投票”。Self-Consistency 真正管用的区间是：有离散可验证答案、且单条链容易因随机性走偏的任务（如数学、多选推理）。
- 模型最擅长：模糊输入理解、自然语言、开放生成、跨领域类比、从少量例子归纳。最不擅长：精确算术、严格状态追踪、确定性逻辑、长链条不犯错。代码（传统程序）正好反过来：最擅长精确计算、状态管理、确定性执行、可复现；最不擅长理解”人到底想干嘛”、处理模糊和非结构化输入。所以 Chain of Code 的精髓是”扬长避短”——用模型理解意图并生成代码，用代码做它不擅长的精确部分。你做后端时早已这么干了：用代码管状态，用配置和 Prompt 式的业务逻辑描述意图，只是没意识到这和 agent 的设计哲学同源。
老哥，这几个零件你别以为只是“玩具”，它们其实是后面所有模式的“发动机”。具体怎么嵌进去的，我点破几处你就通透了：ReAct 的每一轮 Thought，底层就是一段 CoT 推理——模型“边想边说”才决定调哪个工具；ToT 里对每个节点打分，本质就是 Self-Consistency 思路的“节点版”；而 Chain of Code，在 agent 里就是“让模型写一段代码、把代码本身当成一个工具来调”，等于把“代码”升级成了一等公民工具。但零件也有坑：CoT 不是越长越好，超长推理链会出现“中途改主意”——前半段推导出一个结论，后半段又悄悄推翻，前后矛盾，而模型自己发现不了。所以工程里常把中间结论固化成变量（就像你代码里把计算结果赋给一个 const，不让后面再算一遍），避免它在长链里“重算变卦”。这也是为什么复杂模式往往要“先规划、把计划固化成文档”，而不是纯靠一条自由生长的 CoT——固化和自由生长之间，永远要找个平衡点。
老哥，零件也有翻车的时候，得给你提个醒。CoT 不是万能药：在超长推理链上，模型会“走着走着忘了开头”，中间结论还可能前后打架，所以复杂任务里常要把中间结论固化成“变量”而不是让它自由生长。Self-Consistency 的成本现实是：跑 5 次就是 5 倍钱和延迟，只在“错不起且能投票”的题上划算，日常别滥用。Chain of Code 最容易被忽略的是安全边界——让模型写代码并执行，等于把执行权交出去，这些代码必须跑在沙箱里（你 lab06 就用的是内存沙箱，不是真磁盘），否则一句 os.remove(’/’) 就完蛋。你看，每个零件优雅的背后都挂着一根安全绳，这正是你 Part 2/Part 5 反复讲的“工具执行的副作用要兜住”。
小结：CoT / Zero-shot CoT / Self-Consistency / Chain of Code 是最底层的推理零件，单独不算 agent，但几乎所有复杂模式都拿它们当”怎么想”的地基。核心启示是——模型的强项是理解与生成，精确与确定性的活该交给代码。
0.3 单 agent 行动-推理：从 ReAct 到它的变体
这一节是重头戏。前面说了 ReAct 是基准点，现在把它周围那一圈”拧了某个旋钮”的变体摊开看。你记住一句话：它们解决的全是 ReAct 的同一类毛病——“走一步看一步”导致的 token 浪费、容易迷路、不会纠错。
ReAct（Reason + Act）。再确认一次它的形状：Thought（想）→ Action（调工具）→ Observation（看结果）→ 循环，直到模型觉得完了。优点贼明显：简单、能实时适应新信息、调试时一步步看得清。缺点也明显：长任务容易”迷路”（没有全局计划），且每轮都要把上下文重读一遍，token 蹭蹭涨。它是动态、未知环境任务的默认首选。举个具体剧本：你让它”查北京今天天气，如果下雨提醒我带伞”。ReAct 第一轮想”先查天气”，调 get_weather("北京")，看到”小雨”，第二轮想”下雨了，发提醒”，调 send_reminder("带伞")，结束。干净利落。
ReWOO（Reasoning WithOut Observation）。Xu 等 2023 年提出，专门治 ReAct 的”token 浪费”病。思路很巧：先让模型一次性规划好所有要调的工具和参数（一份”计划书”），然后再批量去执行、把结果填空进去。这样模型不用在”调一个工具→看结果→再想下一步”之间反复横跳，上下文里少了一大堆中间观察。论文报在 HotpotQA 上约 5 倍 token 效率。代价是：它假设计划能提前定好，遇到执行中发现”哎呀情况变了”的动态任务，就不如 ReAct 灵活。你可以把它理解成”把想和看彻底解耦”。剧本对比：同样查 5 个公司财报汇总，ReAct 是”查A→看A→查B→看B→…”每轮都带全量历史；ReWOO 是”先列 A/B/C/D/E 五个查询→一次性执行→填空→汇总”，中间观察不回灌推理循环。
Plan-and-Execute（Plan-then-Act）。你 Part 3 会重点写它。和 ReWOO 同源但更彻底：先让一个”规划器”产出完整步骤列表（可检查的中间产物），再由”执行器”逐条落地，每步还能回写状态。它解决的是”长任务迷路”——因为有张地图在前，agent 知道自己在第几步、还剩什么。代价是计划可能过时（现实中途变了），且对模型的规划能力要求高（小模型经常规划得稀烂）。这就像你写大需求：先出技术方案评审，再按文档实现，比边写边想稳得多。
LLMCompiler。2024 年的活儿，想法很工程化：把规划的结果编译成一张带依赖关系的并行任务 DAG，像编译器排指令那样，能并行的并行、有依赖的串行。它其实是 Plan-and-Execute 的高并发版——你前面规划出 10 个工具调用，其中 7 个互不依赖，那就同时打出去，而不是一个个等。高并发工具调用的场景（实时系统、批量检索）用它最爽。它补的是”规划了但不并行”的效率漏洞。
Self-Ask。Press 等 2022 年，专治”多跳问题”。比如”爱因斯坦得诺贝尔奖那年，美国总统是谁？“——模型自己意识到得先拆成子问题（爱因斯坦哪年得奖？那年总统是谁？），自问自答、连续搜索。它本质是”把大问题自动拆成依赖链小问题再查”，是后来所有规划模式的雏形。
Reflexion。Shinn 等 2023 年，在 ReAct 上加了”记忆 + 自我反思”。流程是：行动 → 用自然语言反思自己哪错了 → 把这条反思存进记忆 → 下一轮带着教训重来。这是”语言反馈式强化学习”——不需要重新训练模型，靠把反思写进上下文来自我改进。你 lab01 里那个”模型看到 TOOL_ERROR 后改参数重试”的微缩版，就是这个思想。它最适合”能自动验证对错”的任务（有单测、有规则判对错）。代价是多轮调用、成本翻倍，而且反思本身可能反思错（往错误方向迭代）。
Self-RAG。Asai 等 2023 年，让模型在生成时自己打分”这段话该不该去检索""这段检索结果靠不靠谱/有没有用”，按需检索、按需采纳。它把 RAG（你 Part 4 会学）从”无脑先检索”变成”模型自主判断要不要检索”，显著控幻觉。
CRITIC。Gou 等 2023 年，思路更直接：模型说完一段话，调外部工具（如搜索引擎）逐条验证自己说的陈述是不是真的，错的就改。适合事实核查、新闻验证这类”说错一句话就出事”的场景。
LATS（Language Agent Tree Search）。Zhou 等 2023 年，把 ToT（树搜索，下节讲）和 Reflexion（反思）和蒙特卡洛树搜索（MCTS）揉一起，统一了推理-行动-规划，是目前最强推理/代码生成范式之一。它把”怎么想”这一旋钮拧到了极致：不仅多路径搜，还用反思来剪枝、用搜索来选最优。
老哥，你把这些往四个旋钮上一放，立刻清楚：ReWOO / Plan-and-Execute / LLMCompiler 拧的是”怎么想”（从单链到规划）；Reflexion / Self-RAG / CRITIC 拧的是”怎么看”（从一次性到自我/外部反思）；Self-Ask 是”怎么想+怎么做”的早期混合；LATS 是”怎么想”拧到顶配。它们没发明新东西，只是把你已知的 ReAct 某一档换掉了。
给你一个落到后端的连接，这节特别好用：Plan-and-Execute 像”先出技术方案文档、评审通过再写代码”；LLMCompiler 像”把一堆独立任务丢进 worker 池并发跑，有依赖的用 channel 串起来”；Reflexion 像”CI 跑挂了，读错误日志，把教训写进下次构建的缓存，重试”；CRITIC 像”上线前用监控/对账工具核查每个对外承诺的数字”。你看，没有一个是你没见过的套路。而且注意一个工程铁律在这些模式里反复出现：反思/重试必须带上限和客观判据，否则”往错误方向迭代”比不迭代更糟——这和你给重试加熔断、给循环加退出条件，完全是同一句忠告。
【思考题】
- ReWOO 和 ReAct 的核心区别在”想”和”看结果”是否解耦。请用自己的话说明：什么场景下 ReWOO 比 ReAct 省 token？什么场景下 ReAct 反而更合适？
- Reflexion 把”反思”存进记忆再重试。如果反思本身方向错了（比如模型误以为错在 A，其实是 B），会发生什么？这给你什么启发？
- 这一节的模式，几乎都在”修 ReAct 的某一项短板”。如果让你设计一个”全能模式”，你会把哪几个模式的优点组合进来？为什么？
【参考答案】
- ReWOO 省 token 的场景：任务能提前规划、工具调用彼此独立、且中间结果不用反复喂回推理（如”查 5 个公司的财报并汇总”——一次规划 5 个查询，批量执行填空）。这时 ReAct 每轮都要把前面所有观察塞回上下文，token 线性膨胀。ReAct 更合适的场景：任务动态、执行中发现的新信息会改变后续计划（如”调试一个 bug，看到报错才知道下一步查哪个文件”）——ReWOO 那种”一次性定死计划”在这里会僵，因为它假设计划不变。一句话：静态可规划用 ReWOO，动态需适应用 ReAct。
- 如果反思方向错了，Reflexion 会”带着错误的教训”去重试，结果可能离正确更远——这就是”往错误方向迭代”。这给两个启发：一是反思必须有客观判据兜底（单测通过/规则校验），不能只靠模型主观觉得”我错了”，否则错误反思比不反思更危险；二是 retries 必须设上限，避免”越反思越偏”的死循环。这也呼应了你 Part 5 工程化里”重试要带熔断”的原则——反思循环也是要限流的。
- 一个合理组合：用 Plan-and-Execute 提供全局地图（治迷路）+ LLMCompiler 的并行 DAG 加速独立步骤（治慢）+ Reflexion/Evaluator 在关键节点做质量校验（治错）+ Self-RAG 式的按需检索（治幻觉）。其实 Anthropic 的 Orchestrator-Workers 模式就常这么干：编排层规划，worker 并行执行，worker 内部套一个 evaluator-optimizer。所以”全能模式”不是发明新名词，而是把现有旋钮的强档组合到一个任务流里——这正是你后面学多 agent 编排时会看到的真相。
老哥，这一节最容易犯的错是“一步到位”——上来就挑最复杂的模式，结果又贵又难调。真实的工程路径是渐进式加码：先用 ReAct 跑通主链路（它最简单、最好调）；跑着跑着你发现“长任务它老迷路”→ 加 Plan-and-Execute 给它一张地图；又发现“质量不稳定、同一任务时好时坏”→ 在关键节点套 Reflexion 或 Evaluator；再发现“太慢、几个独立查询在串行等”→ 上 LLMCompiler 并行。每一步都是被真实痛点逼出来的，不是提前设计的。我给你一个反例纪实：有个团队做编码 agent，听说 ReWOO 省 token，一上来就上，结果调试场景全崩——因为调试是“看报错才知道查哪个文件”的动态活，而 ReWOO 把计划定死在第一步，报错出来它已经没法改路线了。这就是“不看任务形态、盲目追新”的代价。记住：模式没有高低，只有“合不合适你的任务形态”，合适的才是对的。
老哥，挑变体我给你一个速查判断树，比背名字好用：① 任务动态、执行中才知道下一步？→ ReAct（别的都僵）。② 任务能提前规划、工具调用独立？→ ReWOO 省 token，或 Plan-and-Execute 要可检查地图。③ 生成物质量红线高、能自动判对错？→ 套 Reflexion 或 Evaluator-Optimizer。④ 子任务能并行？→ LLMCompiler 上 DAG。⑤ 子任务事先未知、要动态拆？→ Orchestrator-Workers。注意一个现实约束：模型越小，规划能力越差。你若用一个小模型硬上 Plan-and-Execute，它生成的计划经常漏步骤、依赖理不清，反而比 ReAct 更糟。所以选型还受“你用啥模型”制约——大厂爱用大模型跑 agent，小模型跑跑分类路由还行，跑复杂规划就露怯。
小结：单 agent 行动-推理模式，几乎都是 ReAct 的”修短板变体”——ReWOO/Plan/LLMCompiler 修”怎么想”（加规划），Reflexion/Self-RAG/CRITIC 修”怎么看”（加反思/验证），LATS 把”怎么想”拧到顶配。理解它们拧了哪个旋钮，就理解了全部。
0.4 搜索形状升级：树、图、双系统
前面那些模式，“怎么想”基本还是”一条线”。这一节把这一旋钮再往上拧——从单链到多路径搜索，专门对付”一步走错满盘皆输”的难任务。
ToT 思维树（Tree of Thoughts）。Yao 等 2023 年。CoT 是一条链，走错了没法回头；ToT 改成树：每一步生成多个候选”思路节点”，用一个评估（可以是模型自评，也可以是规则）给每个节点打分，剪掉差的，从好的继续往下长，还能回溯。这就像下棋——你不只走一步，而是在脑子里演算好几步、比较哪个局面好，再落子。它特别适合数学、博弈、创意生成这类”有多个可能解、需要比较”的任务。代价也很直白：token 消耗爆炸、延迟高，对简单任务纯属杀鸡用牛刀。给你一段伪代码感受它的形状：
def tot_solve(problem):
root = Node(problem)
frontier = [root]
for depth in range(MAX_DEPTH):
candidates = []
for node in frontier:
thoughts = llm_generate_thoughts(node, k=3) # 每节点生 3 个候选
for t in thoughts:
score = evaluator(t) # 评估打分
candidates.append(Node(t, score))
candidates.sort(by_score)
frontier = candidates[:BEAM] # 只留高分，剪枝
if frontier[0].is_solved(): return frontier[0]
return best_effort(frontier)
你看，这就是 BFS + 剪枝 + 回溯，只不过”节点”是模型的推理步骤，“评估”是模型或规则。
GoT 图思维（Graph of Thoughts）。Besta 等 2023 年，在 ToT 的树上加了”聚合”能力，变成图：不同的思路节点可以合并（比如两条推理链得出同一中间结论，就汇成一条），也能循环。树只能分叉不能合流，图能分能合，更贴近人真实 brainstorming——好几个想法撞出同一个洞见，然后一起往前推。适合极复杂的逻辑网、头脑风暴。
SwiftSage。Lin 等 2024 年，借了认知科学里的”双系统”：快思考（System 1，直觉、快、不费力）和慢思考（System 2，逻辑、慢、费力）。SwiftSage 让 agent 平时用轻量快模型快速反应，遇到卡住或需要深推理时，才请重量级慢模型出马做规划。这像你写代码：大部分 CRUD 靠直觉顺手写（快），遇到并发死锁才停下来画时序图仔细推（慢）。既保速度又保深度。
Self-Discovery。让 agent 先分析任务结构、识别关键环节、再决定用哪套策略，带点”元认知”——它不是上来就做，而是先想”我面对的是个什么类型的任务、该用哪套打法”。这拧的是”怎么想”里更上游的那一档：不是想步骤，而是想”我该怎么想”。
老哥，这里有个特别适合你的类比。ToT 那一套，你在算法课里全见过——它就是把搜索算法（DFS/BFS + 剪枝 + 回溯）搬到了 LLM 的推理上。CoT 是贪心一条路走到黑；ToT 是带评估的 BFS/DFS；MCTS（LATS 用的）是带随机模拟的搜索；GoT 是允许合并的图搜索。所以”思维树”不是魔法，是把你已经熟稔的搜索算法，作用在”模型的推理路径”这个搜索空间上。你缺的从来不是这些算法思想，只是没意识到它们能这么用。
再给个 Go 连接：SwiftSage 的双系统，像你服务里的”缓存命中走快路径、未命中走慢路径重算”；Self-Discovery 像框架启动时的”自动探测环境、选择最优配置策略”。系统设计的智慧，和 agent 模式设计的智慧，又一次同源。
但你要注意一个坑：ToT 的”评估函数”是命门。如果评估由模型自己打分，它会给”流畅但错误”的节点高分（语言流畅≠逻辑正确），也会低估冷门但正确的思路。更稳的方式是用外部客观判据（单测是否通过、答案是否可验证），或多模型交叉打分。这又回到算法课老道理：搜索的质量上限不取决于分多少叉，而取决于评估函数准不准——和你写 A* 时选启发函数一模一样。
【思考题】
- ToT 用”评估+剪枝”来探索多路径。这个”评估”如果由模型自己打分，可能有什么问题？有没有更稳的评估方式？
- 为什么 ToT / GoT 这种多路径搜索，对”简单任务”反而是浪费？请结合 token 成本说。
- SwiftSage 的”快/慢双系统”，在你做后端时有没有对应的设计？描述一个。
【参考答案】
- 模型自评的”评估”可能不准——它会给看似流畅但错误的节点高分（语言流畅≠逻辑正确），也会低估冷门但正确的思路。更稳的方式：用外部客观判据当评估（如单元测试是否通过、数学题答案是否可验证、检索结果是否命中）；或者多模型交叉打分（不同模型各自评，取一致）；再不济也该是”评估+回溯”并用——即使评估错杀了一个好节点，只要保留若干候选就不至于满盘皆输。核心教训：搜索的质量上限往往不取决于”分多少叉”，而取决于”评估函数准不准”，这和你在算法里做 A* 时选启发函数一模一样。
- 简单任务本身一条链就能对，ToT 却要生成多个候选、逐个评估、剪枝——这些额外步骤全是纯开销。假设简单任务单链 1 次调用搞定，ToT 可能要 5 个候选×2 轮评估 = 10 倍 token，结果准确率没差别。这就是”杀鸡用牛刀”：搜索的威力在于”单条链容易错”的任务（多解、易迷路），对单条链就够好的任务，多路径只是烧钱。所以选型要问：“这个任务，单链失败率高吗？“不高就别上树。
- 太多对应了。比如你 API 网关：“简单请求（白名单内、已鉴权）直接快路径转发，不进复杂策略引擎；异常请求才进慢路径做完整风控校验”——正是 SwiftSage 的快/慢双系统。再比如”读多写少用本地缓存做快系统、缓存未命中才查库并回填”——也是同一思想。本质都是”大部分情况用便宜方案，只在必要时付出昂贵成本”，是工程里最朴素的性价比权衡，被 agent 领域用”双系统”重新包装了一遍。
老哥，ToT / GoT 这族听着很美，但你得心里有本账：它贵，而且不是所有任务都值这个价。给你一个判断尺——只有当“单条链容易错、且错的成本高”时，才上树。代码生成里 ToT 真有用：一个函数有 3 种写法，树搜帮你比较哪个通过测试，值得；但客服问答用 ToT 纯属烧钱——用户问“我的订单到哪了”，单链查一下就完事，你生成 5 个候选路径评估，用户等得花儿都谢了。再给你一个真坑：评估函数若用模型自评，会出现“自嗨”——它给一段流畅但错误的推理打高分（语言流畅≠逻辑正确），然后剪掉了一条冷门但正确的路。所以我反复说：树的威力上限在评估函数，不在分多少叉；能上客观判据（单测过没过、答案可验证）就别用模型自评，这和你在 A* 里选对启发函数是一个道理。
老哥，ToT 真要落地，有几个工程旋钮得你设：beam width（每步留几个候选，太大烧钱太小没用）、搜索深度（搜几层，深了爆炸）、评估预算（每个节点评估花多少）。这些和你在算法课调 BFS 参数一模一样，没有银值，得压测。SwiftSage 的快/慢模型怎么选？一般快模型用便宜小模型扛 80% 流量，只在“卡住/需深推理”时调用贵的大模型——成本能压到纯大模型方案的零头，代价是延迟偶尔波动。你作为 Go 程序员，其实对这套有肌肉记忆：ToT 的剪枝评估 = 你写搜索时的启发函数；SwiftSage 的快慢分流 = 你服务的缓存命中快路径。别被“思维树”这种词唬住，剥开皮全是你已经会的算法与系统工程。
小结：把”怎么想”从单链拧到多路径搜索，就有了 ToT（树）/ GoT（图）/ SwiftSage（快慢双系统）/ Self-Discovery（元认知）。本质是把你熟悉的搜索算法作用在模型的推理空间上，专治”一步错满盘输”的难任务，但对简单任务纯属烧钱。
0.5 多 agent 协作：从”一个人”到”一个团队”
前面都是”一个 agent 自己玩”。这一节把”怎么协作”这个旋钮拧开——从单一，到分工种、到辩论、到角色扮演。这里我特别要给你一棵生产级的”最小集”：Anthropic 在《Building Effective Agents》里跟几十个团队踩坑后，总结出 5 个可组合的工作流模式，建议你先记住这 5 个，别一上来就整花活。
Prompt Chaining（提示链）。线性的步骤流：上一步输出喂下一步，中间可加校验关卡。适合”任务能干净拆成固定阶段”——比如”先列大纲→再写初稿→再润色”。每步只负责一件小事，自由度小、出错少。成本上是五个里最便宜的（只要链深可控）。注意它和 ReAct 的区别：ReAct 是”想一步做一步看结果再想”，循环由模型动态决定；Prompt Chaining 是”步骤固化、顺序固定、关卡是预设的”，更像一条流水线。
Routing（路由）。先分类，再分发到专门的 handler。比如 FAQ 丢给便宜小模型、复杂推理题丢给大模型、边界 case 转人工。它实现”关注点分离”——你不会用一套提示去优化两种截然不同的输入（那样两头不讨好）。成本上：多一次分类调用，但只要大多数输入能路由到便宜 handler，总体反而省。关键工程点：分类器可以是 LLM 也可以是确定性规则，高吞吐场景能用规则就别用 LLM 分类。
Parallelization（并行）。扇形展开多个独立调用再汇总，两种口味：分段（把一个大任务拆成独立子任务并行做）和投票（同一任务跑多次取共识）。适合”子任务彼此独立”或”多视角交叉验证更稳”。成本是 N 倍调用，但延迟只受最慢那个限制，不累加。——这是它和串行最大的体验差异。
Orchestrator-Workers（编排-工人）。一个中心 LLM 动态拆解任务、派给多个 worker、再汇总。和 Routing 的区别是：Routing 的分发规则是事先定好的（输入分几类就几路），而 Orchestrator 是运行时才决定怎么拆（因为子任务事先未知）。你 Part 7 会重点写它。代价是五个里最贵的——编排器容易”过度拆解”，记得给 worker 数量和预算封顶。
Evaluator-Optimizer（评估-优化）。一个生成、一个挑刺、循环迭代直到达标。适合”有明确质量标准、且迭代能带来明显提升”的任务（代码、写作）。成本是”迭代次数×2”，所以必须给迭代次数封顶。
这五个模式是可组合的：Routing 的输出常喂进 Prompt Chaining；Orchestrator-Workers 常在 worker 层套一个 Evaluator-Optimizer；Parallelization 能嵌进任意一个。Anthropic 反复强调一个态度：先找最简单的方案，只在真需要时才加复杂度。很多应用其实单次调用+检索+几个例子就够，根本用不上 agent，更别说图编排。
除了这五个生产级模式，社区里还有一批”多 agent”变体，你知道名字、知道归哪类就行：
- Multi-Agent Teams：泛指”路由→专家→批评/审批”的组合阵型。
- Debate 多体辩论（Du 等 2023）：几个 agent 互相辩，趋近真理，对抗性任务好用。
- CAMEL（Li 等 2023）：角色扮演（用户+助手）自动对齐目标，看协作怎么自然涌现。
- MetaGPT（Hong 等 2023）：给 agent 套 SOP + 角色，模拟软件工程团队产出。
- Generative Agents（Park 等 2023）：斯坦福小镇，记忆流+反思+规划的社会模拟，25 个 agent 活出日常。
- AutoGen（Microsoft）：可对话、可嵌套的多 agent 编排框架。
老哥，这一节你一定有爆棚的共鸣。Orchestrator-Workers 不就是”技术 leader 把需求拆成 ticket、派给组员、收工汇总”？Evaluator-Optimizer 不就是”作者 + 编辑”？Routing 不就是”客服分诊台”？你做后端时的服务拆分、API 网关、编排引擎（Temporal / 工作流引擎），全是对应的东西。唯一区别：传统系统里谁调谁是你写死的，多 agent 里谁调谁、拆多细，是模型现想的。 你把”动态编排”这层加上去，就得到了多 agent。
但这里必须给你泼盆冷水——多 agent 的协作成本。你 Part 7 会深讲，我先点破：① token 爆炸，N 个 agent 各带一份上下文，成本线性×N；② 错误传播，worker 错了 orchestrator 跟着错，且你很难定位是哪一层传错的（调试地狱）；③ 延迟堆叠，层层嵌套调用用户等到花儿谢；④ 为了用模式而用模式，明明单次调用+检索能解决，偏要上五 agent 编排，更贵更慢更脆。所以”多 agent”不是银弹，是当你单 agent 真碰到”上下文爆 / 任务异构 / 需并行隔离”的天花板时，才掏出来的重武器。
【思考题】
- Routing 和 Orchestrator-Workers 都涉及”分发任务”，它们的根本区别在哪？各举一个只有用其中一个才合理的场景。
- Evaluator-Optimizer 要求”有明确的质量标准”。如果一个任务没有客观标准（比如”写一首感人的诗”），这个模式还成立吗？为什么？
- Anthropic 强调”先找最简单的方案”。结合你做后端的经验，谈谈”过度设计”在多 agent 系统里会怎样显形？
【参考答案】
- 根本区别：分发规则是事先定好的，还是运行时动态决定的。Routing 的分发是静态的——输入分 N 类就 N 路 handler，分类器（哪怕是 LLM）只是把输入塞进预设通道；Orchestrator 的分发是动态的——它得先”看懂这个任务”，再临时决定拆成哪几个子任务、派给谁，子任务的结构事先未知。场景：① 客服系统（退款/物流/套餐咨询各走专门流程）——分类固定，用 Routing 即可，上 Orchestrator 是过度设计；② “帮我基于这份模糊的需求文档，搭一个能跑的微服务原型”——连该拆几个服务都不知道，必须运行时动态拆解，只能用 Orchestrator。一句话：分发结构已知用 Routing，未知用 Orchestrator。
- “写一首感人的诗”没有客观标准，Evaluator-Optimizer 不会凭空成立——因为”评估者”没有可判定的接受条件，容易陷入”两个模型互相吹捧”或”越改越平庸”。但这不意味着彻底无效：可以把模糊标准** operationalize（操作化）**成可评的代理指标，比如”是否符合指定意象""意象密度是否够""是否避免了陈词滥调”，让 evaluator 按这些维度打分。所以模式本身成立的前提，是要有人把”质量”翻译成 agent 能判定的信号——这又回到你 Part 9 评测里的核心难题：没有可测信号，任何”优化循环”都是空转。
- 过度设计在多 agent 里会这样显形：① token 爆炸——N 个 agent 各带一份上下文，成本线性×N；② 错误传播——worker 错了，orchestrator 跟着错，且你很难定位是哪一层传错的（调试地狱）；③ 延迟堆叠——层层嵌套调用，用户等到花儿都谢了；④ 为了用模式而用模式——明明单次调用+检索能解决，偏要上五 agent 编排，结果更贵更慢更脆。你做后端时最讨厌的”为了微服务而微服务”在此完全复刻。Anthropic 的忠告和你架构师的直觉一致：能单不强上多，能简单不堆复杂。先用 ReAct 或单个工作流试水，真碰到天花板再加编排。
老哥，这五个生产级模式，真实项目里是组合着用的，不是单选。给你一个我见过的真实客服 agent 架构：进来先 Routing（分是物流问题还是退款问题还是套餐咨询）→ 物流类走 Prompt Chaining（先查单号→再查物流状态→再组织话术）→ 生成回复前过一道 Evaluator-Optimizer（生成候选回复，质检 agent 挑刺，迭代到合规）。你看，静态分流用 Routing，线性流程用 Chaining，质量红线用 Evaluator，一套组合拳。但踩坑也在组合里：Orchestrator-Workers 最容易”过度拆解”——编排器一兴奋，把一个简单任务拆成 20 个 worker，token 直接爆 20 倍。所以生产里一定给 orchestrator 加 worker 数量上限 + 单次任务预算上限（就像你给 goroutine 池设 max worker、给批处理设 timeout），否则它比你还会造坑。多 agent 是重武器，不是银弹，掏出来前先问”单 agent 真扛不住吗”。
老哥，这五个生产级模式，真实项目里是组合着用的，不是单选。给你一个我见过的真实客服 agent 架构：进来先 Routing（分是物流问题还是退款问题还是套餐咨询）→物流类走 Prompt Chaining（先查单号→再查物流状态→再组织话术）→ 生成回复前过一道Evaluator-Optimizer（生成候选回复，质检 agent 挑刺，迭代到合规）。你看，静态分流用 Routing，线性流程用 Chaining，质量红线用 Evaluator，一套组合拳。但踩坑也在组合里：Orchestrator-Workers最容易“过度拆解”——编排器一兴奋，把一个简单任务拆成 20 个 worker，token 直接爆 20 倍。所以生产里一定给 orchestrator 加 worker 数量上限 + 单次任务预算上限（就像你给 goroutine 池设max worker、给批处理设 timeout），否则它比你还会造坑。多 agent 是重武器，不是银弹，掏出来前先问“单 agent 真扛不住吗”。
老哥，再给你一个五模式的组合实例，巩固一下。假设做一个“长文写作 agent”：进来先 Routing（这是技术文、营销文还是小说？）→ 技术文走 Prompt Chaining（大纲→初稿→润色三段流水线）→ 每段生成后过Evaluator-Optimizer（编辑 agent 挑刺，迭代到事实准确、语气对）。你看，又是“静态分类 + 线性流程 + 质量闭环”的经典组合。反例也得记：① 别用 Orchestrator 去处理“输入分类”这种结构已知的事，Routing 就够了；② 别给每步都套 Evaluator，只在质量红线处套，否则延迟翻倍；③ 别一上来多 agent，先单 agent + ReAct 跑通再说。这些“不该用”和“该用”同样重要，甚至更重要——因为过度设计的代价你最清楚。
小结：多 agent 协作把”怎么协作”旋钮拧开。Anthropic 五模式（Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer）是生产级最小集、可任意组合；社区还有 Debate / CAMEL / MetaGPT / Generative Agents / AutoGen 等变体。它们和你后端的服务拆分、网关、编排引擎同源，区别只是”谁调谁”由模型动态决定；但多 agent 有 token 爆炸、错误传播、调试地狱等真实协作成本，是重武器不是银弹。
0.6 自主长程与记忆架构
最后一节补两类模式：一类是”目标进来、自己跑完”的自主长程 agent，一类是专门解决”记性”问题的记忆架构。它们往往跨多个旋钮，是前面零件的组合体。
自主长程 agent：
- AutoGPT（2023）：目标驱动自主循环的早期代表。你给个目标（“调研竞品并写一份报告”），它自己拆、自己调工具、自己循环，直到觉得完成。听着很美，但 famously 容易跑飞——没有”什么时候停”的清晰边界，经常花了几十刀还在兜圈子。它是”自主 agent”这个想法的引爆点，也是”自主度是把双刃剑”的活教材。从旋钮看，它把”自主/协作”拧到极致，却忽略了”怎么看”（自我校验）和”终止条件”——没有退出条件的循环，就是 bug。
- BabyAGI：在 AutoGPT 思路上更结构化——维护一个任务队列，每完成一个任务就生成新任务、排优先级，像一个有目标的待办清单无限滚动。适合开放式探索，比 AutoGPT 少了点”乱转”，多了点”有清单”。
- Voyager（Wang 等 2023）：在 Minecraft 里终身学习，把”会做的事”写成技能库（可复用的代码技能）存起来，下次遇到类似任务直接调用，而不是从头学。这是”程序性记忆”的典范——agent 越用越会。
- HuggingGPT（Shen 等 2023）：让 LLM 当控制器，把子任务分发给各种专精小模型（处理图/文/音），自己只做编排。多模态任务的早期范式，思想是”大模型管调度，小模型管执行”。
记忆架构（常作为其他模式的”记忆子系统”被单独命名）：
- MemGPT（Packer 等 2023）：像操作系统管理内存一样管理上下文——把超长对话分页，需要时换入换出，突破上下文窗口的物理限制。你 Part 4 会学到，这是”短期记忆外化”的工程化极致。
- Generative Agents 记忆流：Park 等那套小镇的核心，记忆分三层——观察（当下感知）、检索（按需调出相关记忆）、反思（把零散记忆升华成更高层结论），再喂给规划。这是目前最完整的”记忆如何驱动行为”的设计。
- Voyager 技能库：上面提过，是”程序性记忆”——记”怎么做”而非”是什么”。
- Reflexion 情景记忆：把每次反思当一条 episodic note 存着，下次同类型任务直接复用教训。
这三类记忆解决不同层，且可以叠加：一个长程 agent 可以既有 MemGPT 管当下上下文分页（短期），又有 Reflexion 记每次踩坑教训（情景），还像 Voyager 一样把沉淀出的通用技能存库（程序性）——三层一起，才接近”又记得住、又学得会”的完整记忆系统。给你一张叠加示意：
┌─────────────────────────────────────────────┐
│ 程序性记忆（Voyager 技能库） 跨任务长期有效 │ "怎么做"
├─────────────────────────────────────────────┤
│ 情景记忆（Reflexion） 同类型任务复用 │ "我踩过的坑"
├─────────────────────────────────────────────┤
│ 工作记忆（MemGPT 分页） 会话内上下文管理 │ "现在在想啥"
└─────────────────────────────────────────────┘
↑ 全部汇入 Generative Agents 的"记忆流"（观察→检索→反思）
老哥，这两个方向，一个讲”野心”（自主跑完长任务），一个讲”记性”（跨会话记得住）。它们戳中的是你做系统时的两个老命题：长事务的可恢复性（agent 跑半天崩了怎么续？对应你 Part 5 的 checkpoint）和状态的生命周期（什么该跨请求记得、什么该忘？对应你 Part 4 的短期/长期记忆边界）。
生活化类比给你：AutoGPT 像个”你给了目标就撒手不管的实习生”——热情但容易跑偏，你得时不时瞄一眼；Voyager 像”每次通关都记笔记、下次不踩同一个坑的老员工”；MemGPT 像”人脑记不住就写便利贴、需要时翻出来”的操作系统版。记忆架构解决的，就是 agent 的”健忘症”——而健忘，恰恰是 LLM 天生的最大短板（上下文窗口一满，前面的话它就真忘了）。
Go 连接也很直接：BabyAGI 的任务队列+优先级，就是你的任务队列 / 优先级调度器；Voyager 技能库像你项目里沉淀的可复用 util / 中间件；MemGPT 像虚拟内存/分页——物理内存不够就换页，上下文窗口不够就换记忆页。你看，又是你早已烂熟的工程概念，只是作用在”agent 的记忆”这个新对象上。
【思考题】
- AutoGPT 为什么容易”跑飞”？从”旋钮视角”看，它把哪个旋钮拧到了极致，又忽略了什么？
- Voyager 的”技能库”和 Reflexion 的”情景记忆”、MemGPT 的”分页记忆”，分别解决哪一类”记”的问题？它们能叠加用吗？
- 你做后端时的”长事务/状态生命周期”经验，对设计 agent 的”自主长程 + 记忆”有什么可直接迁移的教训？
【参考答案】
- AutoGPT 把”怎么协作/怎么想”的自主度拧到极致（自己拆、自己循环、没有外部刹车），但忽略了”终止条件”和”怎么看”（自我校验）这个旋钮——它没有明确”什么时候算完成""怎么判断自己跑偏了”。结果就是：目标模糊时它不停生成新子目标，token 烧光还在兜圈。教训是：自主度越高，“停止信号”和”质量护栏”越要设计得硬，否则自主变成失控。这和你写”无限重试/无限递归”的惨痛经历同理——没有退出条件的循环就是 bug。
- 三类记忆解决不同层：Voyager 技能库是程序性记忆（记”怎么做”，可复用的能力，跨任务长期有效）；Reflexion 情景记忆是** episodic（情景）记忆**（记”某次具体任务里我犯过的错/教训”，偏短期复用）；MemGPT 分页是工作记忆的外化（解决”当下上下文装不下”的工程问题，偏短期/会话内）。它们完全可以叠加：一个长程 agent 可以既有 MemGPT 管当下上下文分页（短期），又有 Reflexion 记每次踩坑教训（情景），还像 Voyager 一样把沉淀出的通用技能存库（程序性）——三层一起，才接近”又记得住、又学得会”的完整记忆系统。
- 直接迁移的教训：① 长事务必须可恢复（你 Part 5 的 checkpoint 思想）——agent 跑长任务中途崩了，要能从最后状态续，而不是从头来；② 状态要分生命周期（会话内 vs 跨会话 vs 跨用户），不该跨请求记得东西别塞进记忆，否则上下文被垃圾淹没（呼应你 Part 4 的”记忆膨胀”）；③ 分布式里”幂等""重试""熔断”那套，在自主 agent 里一一对应——自主循环里的每一步动作都该幂等、有重试上限、有熔断。你二十年的后端直觉，几乎能直接翻译成 agent 的可靠性设计原则。
老哥，记忆架构听着浪漫，落地全是脏活。给你几个真坑：MemGPT 式分页，如果检索策略做得差，会出现“该想起来的关键时刻没想起来”——就像你代码里缓存命中率太低，频繁回源还慢；Voyager 式技能库，如果不做去重和质检，会越滚越大、还塞进一堆垃圾技能，下次检索反而被噪声带偏；Reflexion 式情景记忆，如果不设清理和衰减，每次的反思全堆进上下文，最后把窗口撑爆（你 Part 4 讲的“记忆膨胀”在这里就应验了）。这些坑和你后端的“缓存击穿、缓存污染、内存泄漏”完全是同一个故事的换皮——记忆本质就是 agent 的缓存与存储，你那套缓存/存储的工程纪律（命中率、淘汰策略、容量上限）原样搬过来就能用。别被“记忆”这个拟人词迷惑，它底层就是状态管理；状态管理你早就是老手了，换个对象而已。
老哥，自主长程 agent 听着性感，生产里全是账单和事故。AutoGPT 跑飞的真正成本不是那几十刀，而是你发现它在兜圈子时已经过去半小时，用户早走了。Voyager 的技能库听着美好，但维护成本被严重低估：技能要去重、要版本化、要防止互相冲突，否则库越滚越乱，检索反而被旧技能带偏——和你项目里“utils 包越攒越臭”是同一出戏。记忆系统更残酷：检索质量决定记忆上限。MemGPT 分页再花哨，如果检索策略拉胯，关键时刻想不起该想的，等于没记忆。所以做记忆架构，功夫全在“怎么存、怎么索、怎么淘汰”，而不在那个浪漫的名字。你后端的缓存/索引/生命周期管理经验，在这里一字不差地复用。
小结：自主长程 agent（AutoGPT / BabyAGI / Voyager / HuggingGPT）把”野心”旋钮拧到极致，代价是容易跑飞、需要硬终止条件；记忆架构（MemGPT / 记忆流 / 技能库 / 情景记忆）专治 agent 的健忘症，分程序性、情景性、工作记忆三层，可叠加。它们对应的正是你后端里的长事务可恢复性与状态生命周期。
0.7 怎么选：诊断任务，而不是选模式
老哥，全讲完了，我把你从”背 30 个名字”的焦虑里捞出来，给你一把真正能用的尺子：别从”我要用哪个模式”出发，先从任务诊断开始。诊断完，模式自己跳出来。
怎么诊断？回到那四个旋钮，对着你的任务逐个问：
| 你的任务…… | 说明它复杂在 | 该优先拧的旋钮 / 模式 |
|---|---|---|
| 推理步骤深、容易一步错 | 怎么想 | 加规划（Plan-and-Execute）或树搜索（ToT / LATS） |
| 子任务彼此独立、串行太慢 | 怎么做 | 并行（Parallelization / LLMCompiler） |
| 跑得长、跨会话要记得住 | 怎么记（贯穿） | 加记忆（MemGPT / 记忆流）+ 计划可恢复 |
| 质量红线严、错不起 | 怎么看 | 评估-优化（Evaluator-Optimizer）/ 反思（Reflexion） |
| 输入种类杂、一套提示顾不过来 | 怎么做 | 路由（Routing） |
| 子任务事先未知、需动态拆解 | 怎么协作 | 编排（Orchestrator-Workers） |
| 需要多视角交叉验证更稳 | 怎么协作/怎么看 | 辩论（Debate）/ 投票并行 |
| 只是线性多步转换 | 怎么做 | 提示链（Prompt Chaining） |
你看，这不就是一张”症状→药”的表吗？你面对一个需求，先判断它”卡在哪个维度”，对应的模式自然浮现。大多数普通业务——Anthropic 五模式挑一两个 + 一个 ReAct 兜底，就够了。那 30 种研究型模式，是你的工具箱，不是让你全用上。
为了让你真的会选，我带你走一遍完整的 walkthrough。假设需求是：“基于一份模糊的需求文档，自动生成一个能跑的微服务原型，并写测试。”
第一步，诊断各维度：
- 子任务事先未知、得读懂文档才知道要拆几个服务 → 怎么协作拧到 Orchestrator-Workers；
- 跑得长、多步、要记得前面定的技术约束（不能后面生成的代码违反前面的约定）→ 加项目级记忆；
- 生成的代码质量红线高（要能跑、要合规）→ 怎么看拧到 Evaluator-Optimizer（生成代码→跑测试→critic 改）；
- 各微服务之间独立 → worker 层可并行（Parallelization）。
第二步，组合成型：Orchestrator-Workers 为骨架，worker 内部套 Evaluator-Optimizer，配项目记忆 + 适度并行。
第三步，主动做减法：我不会一上来就加 ToT 树搜索——因为”生成原型”不是”单链易错的多解推理题”，上树纯属烧钱；也不会给每个 worker 都配反思循环，只在”生成代码”这种错不起的 worker 上配。这就是”诊断优先、能简不繁”。
我得再强调 Anthropic 那句忠告，因为它和你做架构师的本能完全一致：先找最简单的方案，只在真需要时才加复杂度。 你现在回头看 Part 1 的 ReAct——它不是”过时了”，它是”默认款、兜底款”。你该把它当成地基，而不是天花板。当某个旋钮的短板真把你卡住了，再去对应的变体里找解药，而不是一上来就堆 Orchestrator + ToT + Reflexion 的豪华套餐（那只会更贵、更慢、更脆）。
老哥，还记得开篇你那个焦虑吗——“大模型没法逻辑”。我当时说，逻辑不在模型里，在模型外面那层循环里。现在你站到了更高一层：连”循环”都有很多种写法，而选哪种，取决于你的任务在哪根旋钮上别扭。 你从”看不见循环”走到”看得全模式谱系”，这一步，才是真正从”会用 agent”跨向”能设计 agent”的分水岭。
给你一个收尾的连接。你做后端选架构，不也是这套逻辑吗？先问”这业务 IO 密集还是 CPU 密集、要不要并发、数据要不要持久、失败怎么兜底”，然后架构自然长出来。agent 模式选择，是同一套工程判断，只不过决策源从你变成了模型、对象从”服务”变成了”推理循环”。你早就是个模式选择高手了，只是之前没意识到那本事能直接平移过来。
最后，给你一把”归位任何新名词”的钥匙。未来你听到一个从没见过的 agent 模式，只要连问三句，10 秒内它就乖乖就位：① 它主要改了哪个旋钮（想/看/做/协作）？② 它解决 ReAct 的哪块短板（迷路/烧 token/不会纠错/慢/单打乏力）？③ 它适合什么任务形态（静态可规划/动态需适应/多解需搜索/跨会话需记忆/质量红线严）？三问下来，任何新名词都会掉进”某旋钮的某档、治某短板、适某场景”的坐标里，瞬间不神秘。
【思考题】
- 用这一节的”诊断表”，给你手头某个真实需求（比如”基于需求文档自动生成可运行微服务原型”）做一次模式选型，并说明你为什么这么选。
- 为什么”先用 ReAct 兜底、遇短板再上变体”比”一上来就上最复杂模式”更稳？从成本和可调试性两个角度说。
- 如果未来出现一个你从没听过的新”agent 模式”名词，你准备用哪 three 个问题在 10 秒内把它归位？
【参考答案】
- 以”基于需求文档自动生成可运行微服务原型”为例诊断：① 子任务事先未知、需动态拆解 → 怎么协作拧到 Orchestrator-Workers；② 跑得长、跨多步、要记得住前面定的技术约束 → 加记忆（项目级约定）；③ 生成的代码质量红线高（要能跑、要合规） → 怎么看拧到 Evaluator-Optimizer（生成代码→跑测试→critic 改）；④ 各微服务之间独立 → worker 层可并行（Parallelization）。所以选型是：Orchestrator-Workers 为骨架，worker 内部套 Evaluator-Optimizer，配项目记忆 + 适度并行。注意：我不会一上来就加 ToT 树搜索——因为”生成原型”不是”单链易错的多解推理题”，上树纯属烧钱。这正是”诊断优先”的体现。
- 成本角度：复杂模式（多 agent + 树搜索 + 反思）token 和延迟都是数量级上升，先用 ReAct 试水，能解决就不花这份钱，避免”为不存在的问题付溢价”。可调试性角度：ReAct 每步可见、链路短，出问题一眼定位；豪华套餐里 N 个 agent 嵌套、错误层层传播，定位一个 bug 要顺着调用树爬，调试地狱。先简单后加复杂，等于”先让系统跑通再针对性加固”，和你”先撸通主链路再补边缘 case”的开发节奏一模一样。更重要的是：你往往不知道短板在哪，先跑 ReAct 才能暴露真实瓶颈，再对症下药——而不是凭空想象”我要防所有问题”把系统堆成铁桶。
- 三个归位问题（对应四个旋钮）：①”它主要改了哪个旋钮？“——想（推理结构）、看（反馈）、做（行动）、协作（多体）？②”它解决 ReAct 的哪块短板？“——迷路（加规划）、烧 token（解耦想看）、不会纠错（加反思）、慢（加并行）、单打乏力（加协作）？③”它适合什么任务形态？“——静态可规划 / 动态需适应 / 多解需搜索 / 跨会话需记忆 / 质量红线严？三问下来，任何新名词都会掉进”某旋钮的某档、治某短板、适某场景”的坐标里，瞬间不神秘。
老哥，选型最容易掉进两个坑，我点破你绕着走。一是“模式崇拜”——哪个名词火就上哪个，不问自己需不需要；二是“全都要”——诊断表看一圈，觉得每个维度都该拧一下，于是 ReAct+Plan+ToT+Reflexion+Orchestrator全堆上，造出一个贵得离谱、调不动的巨兽。正确的姿势，我给你一条可操作的：先用单次调用 + ReAct 兜底把主链路跑通，埋好 trace（你 Part 5 学的可观测性），然后盯着 trace 看哪一步最痛——是经常迷路（加规划）？还是质量飘（加反思）？还是太慢（加并行）？只给最痛的那根旋钮加码。这和你“先撸通主链路、再按压测瓶颈逐个优化”的节奏一模一样。选型不是设计出来的，是从 trace 里长出来的；你越急着“顶层设计”一套完美架构，越容易造出自己调不动的怪物。
老哥，诊断表你别当 Checklist 死填，我给你一个更顺手的用法：先假设用 ReAct，然后找它哪里会痛。ReAct 跑长任务会迷路→加规划；质量飘→加反思；慢→加并行；输入杂→加路由；子任务未知→加编排。这套“默认最简、按需加码”的节奏，和你写服务“先单体、扛不住再拆微服务”完全同构。最后送你一条铁律：当你拿不准用哪个模式时，永远选更简单的那个。简单模式失败了，trace 短、好定位、好修；复杂模式失败了，你先花三天搞清楚是哪一层传错的。在 agent 这片还年轻的领域，能跑、能调、能解释，比“架构高大上”值钱得多。
小结：选型心法是”诊断任务而非选模式”——对着四旋钮判断任务卡在哪个维度，对应模式自然浮现；多数业务用 Anthropic 五模式 + ReAct 兜底即可，研究型模式是工具箱不是必选项。你从”看不见循环”走到”看得全模式谱系”，正是从”会用 agent”跨向”能设计 agent”的分水岭，而这套选型判断和你做后端架构的本事完全同源。
墨叔收个尾：老哥，这一 Part 你拿走一句话就值了——模式是旋钮的组合，ReAct 是基准点，选型是诊断而非背诵。 带着这张全景图回 Part 1，你看 ReAct 的眼神都会不一样：它不再是”agent 的全部”，而是”你可以在上面拧旋钮的起点”。后面九章，你随时拿这四个旋钮当放大镜，看每个机制到底在调哪根线。