摘要：我们基于 ReAct、Plan-and-Execute、Reflection 三种经典 Agent 架构，构建了一个”论文词汇提取”工具，并用一篇 DeepSeek 新发布的论文做了端到端实测。结果验证了我们的判断：ReAct 在当前场景下几乎不可用，Plan-and-Execute 稳定但抓取精度一般，Reflection 在提取核心术语上表现最佳但存在指令遵循偏差。本文记录这次实战的完整过程、结果对比，以及我们对 Agent 选型与提示词设计的反思。
1. 背景：从理论到实战
上一期我们讨论了三种不同的 Agent 实现方式——ReAct、Plan-and-Execute 和 Reflection——以及它们各自适用的场景。理论归理论，我们决定用一个真实的任务来验证这些方法的差异。
我们选择的任务是：给定一篇学术论文，自动提取出值得背诵的核心词汇。这个任务足够简单（不需要复杂的工具调用），又足够真实（我们确实有背单词的需求），而且它天然适合对比不同 Agent 架构的表现——因为每种架构对”如何完成任务”的路径控制方式完全不同。
代码由 Kimi 生成，我们负责提需求和调试。整个工具是一个命令行交互程序，支持四种模式：直接问答（Direct LLM）、ReAct、Plan-and-Execute 和 Reflection。用户输入论文 ID，选择要运行的 Agent 模式，工具会现场从网上获取论文内容并执行提取流程。
dudu学姐的观察：这个命令行工具虽然没做 GUI，但用键盘交互做出了类似 DOS 时代的排版效果，花花绿绿的字体和表情符号——用 AI 写代码就会有这种风格，它会在界面设计上给你一些”惊喜”。
2. 核心内容：三种 Agent 的实战表现
2.1 测试设置
我们选择了一篇 DeepSeek 上周刚发布的论文（DualPass，arXiv ID 2602.1548）作为测试对象。选择它的原因有两个：一是它足够新，我们都没有预先测试过，能真实检验工具的稳健性；二是它涉及大量工程架构术语（如 PD 分离、KV Cache、Prefetch 等），对背单词工具来说是一个很好的压力测试。
我们运行了全部四种模式（包括 Direct LLM 作为基线），每种模式使用相同的提示词模板，API 配置为 Kimi 的 K2 模型（纯文本版本，成本更低，翻译质量也不错）。
2.2 ReAct：目标不可衡量时的失败
ReAct 的核心逻辑是”思考→行动→观察→再思考”的循环，它本质上是在搜索一条通往目标的路径。但问题在于：词汇提取任务没有一个明确的”对错判定”——你无法告诉模型”你找到的这个词不对，再试一次”。
结果也验证了我们的判断：ReAct 模式返回了 0 个术语。它并不是因为 bug 而失败，而是这个任务本身就不适合 ReAct 的运作方式。ReAct 更适合目标可衡量、有明确反馈信号的场景（比如游戏寻路），而词汇提取更像是一个”过程管理”任务——你需要的是对每一步行动进行精细控制，而不是让模型自己去探索。
dudu学姐的观察：ReAct 在当前场景下就是不太行。提取单词的话，你没法给它一个判断”对还是错”的标准，所以它执行出来的结果基本上都不太行。但理论上 React 也可以，只是需要精挑细选地做提示词——不过当你发现 Plan-and-Execute 能做这件事的时候，你可能就会放弃去精细调 ReAct 了。
2.3 Plan-and-Execute：稳定但精度一般
Plan-and-Execute 的表现符合预期：它先制定计划（确定论文核心主题→扫描摘要→标记技术名词→生成中文定义→设计记忆技巧→整合结果），然后逐步执行。整个过程稳定跑完，返回了 10 个术语。
但问题在于精度：它提取的词有些偏简单（比如 “authentic”、“determine” 这类通用词汇），对一篇充满工程术语的论文来说，这些词并不是”最值得背”的。它更像是一个忠实的执行者——你让它做什么它就做什么，但它对”什么才是重要的”缺乏判断力。
2.4 Reflection：精度最高但指令遵循有偏差
Reflection 模式在 Plan-and-Execute 的基础上增加了一个反思步骤：先跑一轮结果，然后基于第一轮结果进行反思和修正。它返回了 9 个术语，但质量明显更高——它抓到了 PD 分离、KV Cache、DualPass、Storage NIC、Global Scheduler 这些真正核心的架构概念。
不过它也有自己的问题：指令遵循不如 Plan-and-Execute 严格。比如我们要求 context 字段返回英文原文，但 Reflection 给的是中文翻译——虽然内容上可能更”有用”，但如果你需要精确定位原文段落，这种偏差就会带来麻烦。
【图1：四种模式的结果对比表格——展示 React（0个术语）、Plan-and-Execute（10个）、Reflection（9个）、Direct LLM（9个）的返回数量、执行时间、速度评级，以及各自提取的代表性术语】
2.5 一个有趣的发现：记忆技巧的”幻觉价值”
Reflection 模式有一个我们没想到的设计：它为每个术语生成记忆技巧（memory tip）。比如把 “prefill” 比喻成”准背”，把 PD 分离想象成某种生产车间的流水线。这些比喻有些是错的（比如 PD 分离的解释明显有幻觉），但有趣的是，即使比喻是错的，它确实能帮你记住这个词。
这引出一个值得思考的问题：对于一个完全陌生的领域，你是希望 AI 给你一个严谨但抽象的技术解释，还是一个可能不准确但能帮你”先迈过门槛”的比喻？
我的判断是：取决于你的目标。如果是为了快速建立对一个新领域的初步认知，比喻（即使有幻觉）能显著降低认知负载——尤其是英文术语，它们不像中文那样带有象形信息，一个具象的比喻能帮你先记住这个词，之后再慢慢修正理解。但如果是为了精确理解概念，那还是需要回到原文去核实。
3. 反思：Agent 选型的核心原则
这次实战验证了几个我们在理论篇中的判断，也带来了一些新的思考：
第一，Agent 架构的选择取决于任务的可衡量性。 ReAct 适合目标明确、有反馈信号的任务；Plan-and-Execute 适合步骤清晰、可预先拆解的任务；Reflection 适合需要迭代优化的任务。词汇提取本质上是一个”过程管理”任务，Plan-and-Execute 和 Reflection 天然更合适。
第二，Reflection 的”多走一步”是双刃剑。 它确实能提升结果质量（抓取更核心的术语），但每一步额外的推理都会引入偏差——比如把英文 context 变成中文翻译。这种偏差在单步任务中可能不明显，但在多步任务中会累积。
第三，提示词的设计空间比我们想象的大。 我们当前的实现是”每一步给一个写死的提示词”，这本质上是在用原生大模型模拟一个微调模型的行为。如果这个任务是我们经常使用的，完全可以把这些提示词蒸馏到一个更小的模型（比如 14B 级别），成本会大幅降低。
第四，作为”PM”的调试体验。 整个开发过程中，我们遇到的主要问题是超时和静默失败——程序在某个步骤卡住后既不报错也不退出。这提醒我们：Agent 工具的输出日志和错误报告设计，和 Agent 本身的算法同样重要。下次迭代应该让 Agent 在每一步都输出运行报告（发了什么请求、收到什么响应），否则调试就像在黑箱里摸索。
dudu学姐的观察：你每次跟 Kimi 交互都会烧钱，但如果不把运行过程存档，这些钱就白花了。让 Agent 输出运行报告不仅是为了调试，也是为了让你花的每一分钱都有迹可循。
4. 展望：下一步迭代方向
这次 demo 验证了基本可行性，但离”好用”还有距离。我们接下来的计划包括：
- 优化提示词：当前提示词是固定的，我们留出了修改空间。可以对比英文提示词和中文提示词的效果差异，也可以尝试更精细的指令（比如明确要求 context 返回英文原文并标注章节位置）。
- 改进 context 的可追溯性：当前 context 字段要么是总结要么是翻译，不方便定位原文。更好的设计是返回”这个词出现在哪一章哪一节”，这样用户可以快速回到原文核实。
- 尝试更多 Agent 架构：我们只测了三种经典方法，后续可以尝试其他变体，比如带自我纠错的 Plan-and-Execute、多 Agent 协作等。
- 开源代码：代码会开源，包括一个 Archive 的报告（记录我们如何用三种方式实现背单词 Agent）和工具本身。欢迎大家对比不同提示词的效果，也欢迎提出改进建议。
最后，给这次测试打个分：Reflection 我给 8 分（抓取核心术语的能力最强），其他模式 7 分左右，ReAct 弃权——不是它不行，是我们没把它用在合适的场景上。
工具选型没有银弹，只有适不适合。 理解每种 Agent 架构的运作逻辑和适用边界，比盲目追求”最先进”的方法更重要。
References
- ReAct: Synergizing Reasoning and Acting in Language Models
- Plan-and-Solve Prompting
- Self-Refine: Iterative Refinement with Self-Feedback
- DeepSeek DualPass (arXiv: 2602.1548)
- Kimi K2 / K2.5 (API 模型)
- 爱宾豪斯遗忘曲线（学习计划设计参考）