这是 AI 开发入门系列 的第一篇，讲四种主流的 Agent 架构全景。第二篇 function call 与 tool call 的区别 讲工具调用的设计思路，第三篇 用 Python 从零写一个 LLM Agent 用 ReAct 架构手写实现，第四篇 Understanding RAG 讲检索增强生成。
为什么要有 Agent
Agent 不是一个单一概念，而是一套解决"LLM 如何在不确定环境中做出多步决策"这个问题的方案家族。
先想一个问题：你把一个 GPT-4 放在那里，它能直接帮你定机票、查天气、写代码然后跑通吗？
不能。一个裸的 LLM，从它被设计出来的第一天起，能做的事情就只有一件：接收一段文本（prompt），输出一段文本（response）。 除此之外它什么都做不了。它不能点一个按钮，不能调一个 API，不能读一个文件，不能打开一个网页。它的整个世界就是 prompt 进来、token 出去。
这个根本约束直接决定了它能做什么、不能做什么。它不知道今天几号（训练数据有截止日期），不知道北京现在到底下没下雨（没有实时信息入口），不知道你的项目里到底依赖了哪些库（它看不到你的文件系统）。它写出来的代码是对是错，它自己没法验证——因为它没有执行环境。
把这个缺口列出来，大概有三类事情 LLM 自己干不了：
- 访问外部世界。查天气、搜网页、读数据库、调 API——LLM 不存在任何输入通道，只有你喂给它的 prompt。
- 验证自己的输出。它不知道刚才写的 SQL 能不能跑通，不知道刚才建议的航班号是否还存在于航司系统中。它没有"执行并观察结果"的回路。
- 多步规划与纠错。一个复杂任务通常需要"做一步 → 看到结果 → 决定下一步"。LLM 如果只被调用一次，它输出完就结束了，没有机会根据中间结果调整方向。
Agent 的本质，就是在 LLM 外面包了一层循环，把这三个缺口补上。这层循环给 LLM 装了"手脚"（工具调用）和"眼睛"（观察工具执行结果），让它从"一次提问一次回答"变成"多步交互直到任务完成"。
不同 Agent 架构的差异，就在于这层循环是怎么设计的。
不同方案的核心差异，在于Agent 的循环里多了一步什么。
有些在循环之前多了一步规划（Plan-Execute）。有些在循环之后多了一步反思（Reflexion）。有些把循环拆成了多个角色分别跑（Multi-Agent）。而在第三篇我们手写的 30 行循环，是其中最基础也最通用的一种——ReAct。
除了 ReAct，常用的还有三种架构。我们一个一个看。
ReAct：基座架构
ReAct 的全称是 Reasoning + Acting，来自 Yao et al. 2022 年的论文，本质就是把 LLM 的"思考"和"行动"放在同一个循环里交替执行。
它的循环只有三步：
思考 → 行动 → 观察 → 思考 → 行动 → ... → 结束
每一步 LLM 看到当前的完整上下文（用户原始问题 + 之前所有工具调用结果），输出一个动作。这个动作要么是"调某个工具 + 参数"，要么是"直接回答并结束循环"。
这是四种架构里最基础的一种。Plan-Execute 在它前面加了一步"计划"，Reflexion 在它后面加了一步"反思"，Multi-Agent 把它的循环拆给了多个角色。
ReAct 最适合的场景是：问题不需要事前规划，LLM 边走边看就能解决。 比如调一个天气查询工具回答"北京明天热不热"——不需要计划，一问就能决策。
它的代价也是基座级的：如果任务需要多步推理，ReAct 容易在半路走偏。没有事前的全局规划，每一步的决策只依赖当前 step 的上下文，LLM 可能在第三步才发现第一步的方向不对——但前两步的 token 和工具调用成本已经花了。
Plan-Execute：多了计划，但也多了一层计划错了的风险
如果一个任务的步骤是明确的、需要按顺序执行的，ReAct 边走边看的模式就可能不够高效。
Plan-Execute 的做法是：先完整规划，再逐步执行。
规划（Plan） → 执行步骤1 → 执行步骤2 → ... → 汇总
第一轮，LLM 不被要求做任何工具调用，而是被要求输出一份完整的行动规划——列出每一步要调什么工具、用什么参数、步与步之间有什么依赖。
规划产出后，用一个执行器按顺序执行。每一步的结果累积进上下文，LLM 只在规划阶段介入一次，执行阶段由程序调度。
举例，用户要"比较北京和上海今天的天气"，ReAct 的做法是：
第1轮: 调 get_weather("北京") → 拿到结果
第2轮: 意识到还要查上海 → 调 get_weather("上海") → 拿到结果
第3轮: 对比 → 回答
Plan-Execute 的做法是：
第1轮: 规划 → [查北京天气, 查上海天气, 对比并回答]
第2轮: 执行查北京
第3轮: 执行查上海
第4轮: LLM 拿到两个结果 → 生成对比回答
Plan-Execute 的优势在于省 LLM 调用。ReAct 每走一步都要调一次 LLM，如果任务有 10 个步骤就需要 10 次 LLM 调用。Plan-Execute 只调一次 LLM 来生成计划，后续执行阶段不需要 LLM 参与（或者只在汇总阶段再调一次），大幅降低了 token 消耗和等待时间。
如果想让执行阶段更快，Plan-Execute 有一个进阶变体叫 LLMCompiler（Kim et al.），它能把计划中彼此没有依赖的步骤并行执行。"查北京"和"查上海"互不依赖，就可以同时调两个工具，而不是一个一个来。这不是基本 Plan-Execute 的能力，但实际落地时经常会往这个方向扩展。
但它也有代价：计划如果错了，代价比 ReAct 大。 ReAct 走错一步，最多浪费一轮 tokens；Plan-Execute 的计划如果一开始就偏了，可能要把整个计划废弃重来。
所以 Plan-Execute 适合"步骤之间依赖关系清晰、数量可预判"的任务。不适合"需要灵活动态判断下一步做什么、新信息会改变计划方向"的任务。
Reflexion：跑完一整个任务再回头看
ReAct 和 Plan-Execute 的共同弱点是：它们只管"往前做"，不会主动回头看自己做的是不是对的。
Reflexion（Shinn et al., NeurIPS 2023）的思路不一样：它不是每一步都反思，而是让 Agent 跑完一整个任务（一个完整 trial），跑完之后让 LLM 复盘整个 trial 为什么成功或失败，把复盘结论存进一段持久记忆里，下一次再跑同一个任务时把这段记忆注入进去作为指导。
Trial 1（完整的 ReAct 循环，直到结束或超时）
↓
反思：LLM 复盘整个 trial 的成败原因 → 存入 episodic memory
↓
Trial 2（完整的 ReAct 循环，但这次 system prompt 里多了一段"上次失败的原因是..."）
↓
反思：LLM 再次复盘 → 更新 episodic memory
↓
... 直到成功或达到最大 trial 数
和前面两种架构最大的不同是：Reflexion 不是在单次 ReAct 循环内部加步骤，而是在多次 ReAct trial 之间加了一个学习机制。
反思产生的是一段"经验总结"，比如：
第 1 次尝试：Agent 连续 3 轮都调了 search_web，返回的都是一些不相关的房地产广告。
反思结果："上次搜索 '北京房价 2026' 返回的都是广告。下次搜索时加上 site:gov.cn 限制到官方数据源。"
→ 这段总结存入 episodic memory
第 2 次尝试：Agent 的 system prompt 里多了上面这段记忆。这次它一开始就用了 site:gov.cn，搜索返回了统计局官网数据。
反思结果："加上 site:gov.cn 后能搜到官方数据了。但如果用户问的是学区房价格，还需要进一步搜索教育政策。"
→ 更新 episodic memory
第 3 次尝试：Agent 结合前两次的经验，一步到位。
这个机制让 Agent 有了一个关键能力：在不改变模型参数的情况下，通过反复试错和经验积累来提升表现。 论文中 Reflexion 在 HumanEval 编程基准上把 GPT-4 的准确率从 80% 提升到 91%。普通的 ReAct 如果在一个任务上第三次调用同一个工具还没成功，它可能会继续调用第四、第五次——因为它不知道"刚才失败的原因"。Reflexion 知道——因为上次整个 trial 失败后它停下来总结了原因。
记忆容量有限，论文中通常只保留 1-3 条最近的经验。所以 Reflexion 更准确的定位是"在同一个任务上反复尝试时记住上次哪儿错了"，而不是"跨不同任务积累可迁移经验"。
Reflexion 的代价是每个 trial 之后多了一轮 LLM 调用（复盘总结），如果一个任务需要 3 个 trial 才能成功，那就多了 3 次反思。它适合"同一个任务值得反复尝试、做错的代价比多跑几轮更大"的场景——代码生成、数学推理、复杂分析，而不是简单事实查询。
Multi-Agent：把循环拆给多个角色
前面三种架构都是一个 Agent 在跑循环。Multi-Agent 的思路不同：把任务拆给多个 Agent，每个 Agent 有自己的角色、工具和视角，彼此通信协作。
用户任务 → 调度器分配
├── Agent A（研究员）：负责收集信息
├── Agent B（分析师）：负责分析、对比、得出结论
└── Agent C（审核员）：检查 A+B 的输出是否有逻辑漏洞或事实错误
→ 汇总 → 最终输出
每个 Agent 内部仍然是一个完整的 ReAct（或 Reflexion）循环——只是它的工具集被限定在自己的角色范围内。研究员只负责搜资料，不负责回答；分析师不搜资料，只负责推理；审核员不动手做事，只负责挑刺。
这带来的最大好处是：每个 Agent 的 prompt 可以极度专注。 研究员不用考虑"我的回答是否严谨"，审核员不用考虑"我该去哪找信息"。三个 Agent 各司其职，整体质量通常优于一个全能的 Agent 同时解决所有事。
但代价也很明显：通信成本。 Agent 之间如何传递信息？传太多，context 膨胀；传太少，信息丢失。调度器怎么判断"该把任务交给谁"？这一步本身就是一个小型决策问题。Multi-Agent 的工程复杂度不会线性增长——每加一个新角色，通信网络的复杂度都在膨胀。
目前业界最常用的 Multi-Agent 框架是 LangGraph 和 CrewAI，它们做的本质就是帮你把这套"各司其职 + 消息传递 + 结果汇聚"的调度层标准化。
Multi-Agent 适合"任务的子目标之间异构性高、需要不同专长的角色分别处理"的场景——比如你想让一个 Agent 专门写代码、另一个专门写测试、再一个做代码审查。但如果任务本质上是一个人可以闭环完成的（调个天气、算个数），Multi-Agent 就是多余的开销。
你该选哪种
回到最实际的问题：你手上的任务，用哪种架构？
这四种不是互相排斥的——实际上很多生产级 Agent 系统会混用。用 Plan-Execute 做粗粒度规划，子步骤用 ReAct 执行；或者用 Multi-Agent 框架拆任务，每个子 Agent 内部跑 Reflexion 做自我纠错。
如果你刚开始接触 Agent，最好的起点是先彻底搞清楚 ReAct——因为它是另外三种架构的基座。你在第三篇手写的 30 行 ReAct 循环，就是所有复杂 Agent 的最小原子单元。