摘要：本文从一个真实的”论文背单词”需求出发，逐步拆解 Agent 设计的演进路径。我们先用 React 的”思考-行动-观察”循环尝试解决，发现它在需要全局规划的任务上力不从心；接着引入 Plan-and-Execute 的”先计划后执行”模式，解决了任务拆解的问题；最后通过 Reflection 的”自我反思+外部反馈”机制，让系统具备了容错和稳健性。文章记录了我们在这一过程中对 Agent 架构的思考、测试和取舍。
1. 背景：一个看似简单却暗藏玄机的需求
故事要从 cici 的一个实际需求说起。她手头有大量 PDF 格式的论文——假设有一百篇——她想从这些论文中提取需要背诵的单词。但需求远不止”提取词表”这么简单：
- 需要推荐：哪些单词值得优先学习
- 需要定时提醒：每天背多少个、某个时间提醒
- 需要区分生词和已背过的词
- 需要解释每个词在论文中的具体含义（关联到论文中的片段）
- 需要生成学习计划：今天背哪几个，还能打卡
这个需求听起来很具体，但当我们试图用 Agent 来实现时，发现它远比想象中复杂。原因在于：这个任务天然需要多步骤、多工具的协作，而且每一步都可能出错。
我们决定从最经典的 Agent 论文开始，看看不同设计模式在这个需求上的表现。这既是一次理论学习，也是一次实战测试。
2. 三种 Agent 设计模式：从”碎碎念”到”有规划”再到”会反思”
2.1 React：一边想一边做，但缺乏全局观
React（2022 年 10 月发表）是 Agent 设计的奠基之作。它的核心创新在于将 Thought → Act → Observation 组成一个循环：模型先思考要做什么，然后调用工具行动，观察结果，再思考下一步。
【图1：React 与传统方法的对比图——左侧是 Act-only 模式（直接调用工具无思考），中间是 CoT 模式（长思考但不调用工具），右侧是 React 的”思考-行动-观察”循环】
对比来看：
- Act-only：直接调用工具，拿到结果就输出，但结果可能不正确
- CoT（Chain-of-Thought）：思考得很长，但不调用任何外部工具
- React：把两者结合——先想再动，动完再想，形成一个循环
论文里有个很直观的例子：在 AlphaWord 数据集上，任务是”把胡椒瓶放在抽屉上”。React 的做法是：先想”胡椒瓶可能在哪”，然后去抽屉里找，观察结果，再决定下一步。这种”边做边想”的方式确实比纯思考或纯行动更有效。
但当我们把这个模式套到背单词需求上时，问题立刻显现了。我们的任务需要：
- 理解：读懂论文内容，判断哪些单词重要
- 规划：制定学习计划，区分优先级
- 行动：读取文件、调用 API、生成词表
在 React 框架里，这些全被归入”思考”范畴。但问题是，思考的东西太多了——它既要理解任务，又要理解论文，还要组织词表。而行动部分反而相对简单（就是 read 文件、调用 API）。React 的线性循环结构（思考→行动→观察→再思考）无法承载这种复杂度。
dudu学姐的观察：React 更像是一个”单线程”的思考者——它每一步只能做一件事，而且每一步都依赖前一步的观察结果。对于需要多工具协作、多步骤规划的任务，这种模式会显得很笨拙。
2.2 Plan-and-Execute：先计划，再执行
第二个方案来自 Plan-and-Solve 论文（2023 年），它后来沉淀为 LangChain 框架中的 Plan-and-Execute 模式。核心思路是：拿到任务后，先写一个全局计划，然后按步骤执行。
【图2：Plan-and-Solve 与 CoT 的对比——A 是 CoT（整体思考但无拆解），B 是 Plan-and-Solve（先拆解成子任务再逐步解决）】
对比来看：
- CoT：把复杂问题当黑盒，一步步推理但缺乏结构
- Plan-and-Solve：先把问题拆解成多个子任务，每个子任务独立解决
在我们的背单词需求上，Plan-and-Execute 的表现明显更好。我们可以给 AI 一个更模糊的指令：“我想背这十篇论文里的单词，给我一个计划，最好每天都能背。“它会生成类似这样的计划：
- 确认背单词的文件来源
- 获取论文（调用 search/API）
- 从论文中提取单词（理解内容）
- 整理成学习词表
关键区别在于：每一步的执行不依赖前一步的观察结果，而是依赖全局计划。这意味着它可以并行处理多个子任务，也可以根据任务特点决定是否调用外部工具。
但 Plan-and-Execute 也有它的局限。它假设计划一旦制定就能顺利执行，但现实是每一步都可能失败。比如获取 PDF 失败、总结质量不高、词表不符合用户预期——这些都是计划外的情况。
2.3 Reflection：让系统学会”自我检查”
第三个方案是 Reflection，它解决的是 React 和 Plan-and-Execute 都忽略的问题：如果第一步就错了怎么办？
在 CoT 中，如果你推理的第一步就错了，后面想得再复杂也是错的。Reflection 的解决方案是：引入一个 checker 或 evaluator，在执行过程中不断检查结果是否正确。
【图3：Reflection 的架构图——包含 actor（执行者）、evaluator（评估者）和 self-reflection（自我反思），同时整合短期轨迹和长期经验】
Reflection 的关键创新在于引入了两种反馈机制：
- Internal feedback：模型自己检查自己的输出（比如用不同的提示词重新审视）
- External feedback：通过外部环境验证结果（比如运行代码看是否通过）
论文里展示了三种不同的 evaluation 方式：
- Decision-making：用规则或 LM-as-judge 来评判
- Programming：用 assert 或测试用例来验证（这是金标准）
- Reasoning：匹配已知答案
dudu学姐的观察：代码任务特别适合 Reflection，因为”能不能运行”是一个客观标准。但推理任务就难多了——你很难判断一个推理过程是否”正确”，除非有标准答案。
3. 反思：三种模式如何组合，才能解决真实需求？
回到我们的背单词需求。经过三种模式的对比，我们得出了一些重要结论：
第一，没有一种模式是万能的。 React 适合”问题难但上下文简单”的场景（比如游戏），Plan-and-Execute 适合”任务复杂但步骤明确”的场景（比如我们的背单词），Reflection 适合”结果可验证”的场景（比如代码生成）。
第二，真实需求往往需要组合使用。 比如在我们的背单词任务中：
- 获取论文这一步，可以用 Plan-and-Execute 来规划
- 理解论文、提取单词这一步，可以用 React 来做内部迭代（因为上下文是单篇论文，适合逐步思考）
- 每一步的结果，都需要 Reflection 来验证
第三，Reflection 可以显著提升系统的稳健性。 比如获取 PDF 这一步经常失败（这是在线 Agent 的常见问题），一个好的 Reflection 机制会让 Agent 自动尝试替代方案——拿不到 PDF 就去找 TXT 或 HTML。它不会因为单次失败就放弃，而是会自我反思并调整策略。
第四，成本控制是实际工程中不可忽视的因素。 处理一百篇 PDF 时，我们不会用最强的模型去扫描所有文件——那太贵了。更经济的做法是：用一个小参数模型做批处理（理解、总结、翻译），再用一个强模型做 evaluator，检查小模型的输出是否正确。这种”弱模型干活、强模型把关”的策略，本质上就是 Reflection 思想在工程上的应用。
dudu学姐的观察：Reflection 的另一个好处是它可以把业务逻辑放在外部。比如背单词的黑白名单——如果名单很长，一次性塞给模型会破坏上下文，不如让模型先输出词表，然后外部系统做匹配，再把结果反馈给模型调整策略。这样既节省 token，又保持上下文干净。
4. 展望：从理论到实战
到这里，我们的理论部分基本完成了。我们梳理了三种经典的 Agent 设计模式，并分析了它们在背单词需求上的适用性。但理论终归是理论——我们还没有真正测试过这些模式在实际代码中的表现。
下一步，我们打算进入实战环节：选一个 AI 编程助手（比如 Kimi），让它用这三种模式分别实现背单词功能，看看哪种模式在真实代码生成中表现最好，哪种模式最容易”翻车”。
我们预期会有不少翻车现场——毕竟 AI 写代码的能力虽然进步很快，但在处理这种需要多步骤、多工具协作的任务时，仍然可能暴露出各种问题。这些测试结果会是我们下一期节目的主要内容。
如果你也在用 Agent 解决类似的需求，欢迎分享你的经验——尤其是那些”翻车”的瞬间，往往是最有价值的学习素材。
References
- ReAct: Synergizing Reasoning and Acting in Language Models - 2022 年 10 月
- Plan-and-Solve Prompting - 2023 年
- Reflexion: Language Agents with Verbal Reinforcement Learning - 2023 年
- LangChain - Plan-and-Execute 的工程实现框架