5.3 架构模式：ReAct、Reflexion、AutoGPT 与多智能体

5.3 架构模式：ReAct、Reflexion、AutoGPT 与多智能体

本节摘要：把前几章的零件装在一起，业界沉淀出四种成型的架构模式。它们不是并列的选项，而是一条"自主度递增、人工介入递减、失控风险递增"的演化链。本节沿这条链逐个拆解每种模式治什么病、付什么代价，帮你找到与业务风险匹配的那个档位。

最早的智能体尝试都很收敛：给模型配几个工具，走一步看一步——这就是 ReAct，第 2 章已经手写过完整实现。但很快人们发现它有三种典型的"不够用"：失败了不会总结、长任务撑不住全局、复杂任务一个人忙不过来。三种不够用，分别催生了三个后继模式：Reflexion、AutoGPT 式自主循环、多智能体协作。每种模式都是对前一种某块短板的补丁，同时也引入了新的失控面。

四种模式逐个过堂

ReAct：走一步看一步的基线。思考、行动、观察循环，每步基于最新观察决策。它的最大美德是可控——每一步都留痕、可中断、可插人工。短板是全局感稀薄（第 4 章已分析）与不会从失败中学习：这次任务摔的跟头，下个任务原样再摔。

Reflexion：给循环装上复盘。在 ReAct 之上加一层"事后总结"：任务失败（或评测不通过）后，让模型用语言把教训写下来（"上次失败因为没有先确认文件存在就读取"），存进记忆，下次同类任务开始前先读教训。它的洞察在于：语言化的反思本身就是一种学习，不需要改模型权重。代价是每次失败都要多付一轮总结调用的成本，且教训质量取决于反思提示词的水平。

def run_with_reflexion(goal: str) -> dict:
    lessons = memory.recall(f"任务教训：{goal}", top_k=3)   # 先读过去的跟头
    result = react_agent.run(goal + "\n历史教训：\n" + render(lessons))
    if result.status != "done":                              # 失败触发复盘
        lesson = llm.summarize(result.trace, instruction=
            "用两三句话总结失败根因，写成对下次执行有操作性的教训")
        memory.write(lesson, kind="lesson")                  # 教训入长期记忆
    return result
​

AutoGPT 式：把方向盘完全交给模型。这一脉的激进之处在于去掉外部循环控制：给定一个长期目标，模型自己规划、自己执行、自己决定何时做什么，外层程序只提供工具与存储。早期项目的兴奋与翻车都源于此——目标定得笼统时，它可能循环几百轮却原地打转，账单烧穿而产出为零。今天它的合理遗产是长时自治任务的形态：目标必须拆解得足够具体、预算与止损必须外置硬编码（第 4 章的兜底在这里不是可选项而是保命项）、关键节点强制回报进度。

多智能体系统：把一个过载的上下文拆成一支队伍。第 5.1、5.2 节刚讲完，不赘述。放在这条演化链上看，它的本质是用空间换质量——以多份上下文和通信成本为代价，换每个上下文的专注与干净。

模式对照与选档

选档的判断依据只有一条：业务能承受哪种失控。客服场景每个动作都影响真实用户，ReAct 档位的人工介入点恰恰是资产；内部批处理任务跑错可以重来，才轮得到 AutoGPT 式的长时自治；中间档的 Reflexion 适合那些"反复在同一个地方摔倒"的任务——每失败一次，系统就比上次聪明一点。

案例：同一任务在三个档位下的表现

背景：目标"监控竞品价格并每周输出调价建议"，团队先后用过三档实现。

操作与结果：ReAct 档位每次人工触发、单轮执行，稳定但依赖人盯，漏了两次数价；换 Reflexion 后，前一个月它把"价格页需要滚动加载才能看到完整报价"这一教训固化，抓取完整率明显上升，但每周仍要人发起；最终形态是 AutoGPT 式的定时自治——每周一自动执行，带步数与预算硬上限，产出先落内部报告再由人审核后外发。

解读：三档不是升级关系，是介入密度的选择。注意最终形态的每个激进设计都配了外置缰绳：预算硬上限防跑飞，人工审核把输出风险拦在对外之前——自治度提高的同时，护栏（第 7 章）的权重同步提高，这是全册反复出现的对偶。

变式：模式可以局部混搭。整条流水线按 Plan-and-Execute 走，其中易错的抽取步骤单独套 Reflexion 复盘；全局是受控的，学习发生在局部——这是生产系统里常见的折中。

⚠️ 常见坑：把"自主度"当 KPI 追。有团队以"人工介入次数最少"为目标迭代智能体，结果介入点被一个个优化掉，直到一次静默的错误执行引发客诉才回头。介入点的正确演化方向是"更精准"（只在低置信度与高风险动作时触发），而不是"更稀少"。

本节要点回顾

• 演化链：ReAct 打地基，Reflexion 治"不会复盘"，AutoGPT 式放自治，多智能体拆过载——每档都以前档的短板为靶子。
• 语言化反思即学习：教训写成可操作的短句入记忆，下次执行前召回，不改权重也能进步。
• 自治必须有外置缰绳：预算与止损硬编码、里程碑强制回报、产出先内审后外发。
• 选档看业务容错：能承受的失控程度决定自主度档位，介入点求精准不求数量少。

模式讲完，最后一节回答选型落地的问题：这些模式在主流框架里分别长什么样，以及什么时候连框架都不需要。

混合模式的组装实例

四种模式在真实系统里很少单选，常见的组装思路是"骨架与插件"：以一种模式做骨架，其他模式做局部插件。几个经过验证的组合——Plan-and-Execute 做骨架、易错步骤套 Reflexion：全局路径可预见，个别环节（如数据抽取）历史失败率高，给它单独配复盘与教训召回；ReAct 做骨架、关键节点配人工闸：执行链受控，只有高风险动作处停下等确认；多智能体做骨架、每个队员内部是 ReAct：队伍负责分工与传递，队员各自在自己的工具域里循环，互不越界。

组装的判断依据始终是同一条：在失控风险最大的位置，放最重的管控；在成本最敏感的位置，放最轻的模式。反过来——全局套重型模式、局部裸奔——是最常见的架构倒挂。

从模式看能力边界

模式选择还有一层隐含信息值得向相关方明说：每种模式对应着不同的可承诺边界。ReAct 模式可以承诺"每个动作有人工选项"，AutoGPT 式只能承诺"预算内自治、超限上报"，多智能体可以承诺"分工透明可审计"。立项时把模式的可承诺边界写进方案，后续的验收标准就有了共同的锚点——很多分歧的根源，是相关方拿着 A 模式的期望验收 B 模式的系统。