本文主线认出瓶颈 → 对照机制 → 手算成本与耗时 → 检查失败边界 → 设计公平比较。阅读目录1. 先问你缺的是事实还是步骤2. ReWOO 省的是什么先把“未知值”和“未知路线”分开3. LLMCompiler 解决的是依赖和等待4. 自我修改、反思和搜索究竟改进了什么5. STORM 的提醒内容更全面关系也可能写错6. 怎样比较才不会把“花更多钱”误当成“设计更好”7. 把九篇论文落回一张选择表原文与继续阅读把模型接上工具之后下一步是什么很多方案会继续添加规划器、反思器、多角色和搜索树。流程图越来越完整真正运行时却可能更慢、更贵也更难知道错误从哪一步开始。问题不在于这些机制没有用而在于它们解决的是不同困难。缺少事实、步骤安排不好、等待太长、判断信号不可靠需要的是四类不同的改进。这篇文章把九篇代表论文放回同一条问题线上先认出任务里的瓶颈再决定需要增加哪一种机制。文中的计算是教学算例论文实验的模型、任务和预算不同不把它们当成同场排行榜。教学整理示意图同一方法可能涉及多个问题图中突出它在本文里的主要作用。1. 先问你缺的是事实还是步骤假设用户要求“查明一家公司某一年度的营收、员工数和业务结构并解释与上一年度的差异。”这是一个用于说明流程的例子。第一步不是让模型写出更长的分析而是找到年份正确、来源可靠的报告。报告没找对后面再多次反思也只会围绕错误材料润色。系统让模型提出下一步动作由程序执行查询再把真实返回内容交给模型继续判断这种能够根据中间结果调整行动的系统通常称为Agent也就是智能体。在 ReAct 中语言推理与外部行动交替发生。它有用的地方在于刚查到的事实可以改变下一步。例如报告提到某业务已被重新分类下一次查询就应该寻找调整后的对比口径而不是照旧把两年的数字相减。但如果题目所需的信息已经全部给出模型只是容易漏掉中间步骤主要困难就变了。Plan-and-Solve 通过先形成计划、再执行来处理这类问题Self-Discover 则研究如何选择、改写并组合适合一类任务的推理结构。两者都不能代替查证。更完整的步骤可以减少遗漏它不会凭空补上缺失的事实。同样模型能写出一个正确的计划也不保证执行时每个数都算对。2. ReWOO 省的是什么先把“未知值”和“未知路线”分开有时我们暂时不知道某个结果却已经知道拿到结果后要做什么。例如要查询某位研究者的导师出生在哪里暂时不知道导师姓名但后续处理方式很清楚先查导师是谁再用这个姓名查出生地。未知的是一个值不一定是整条路线。ReWOO 利用这一点先把步骤和结果引用安排好再执行工具最后结合证据形成答案。前一步的返回结果可以保存在一个位置例如E1后一步需要姓名时再把E1的实际内容填进去。这不等于“不需要观察”。真实工具结果仍然被使用只是不必每取得一个结果就让主规划过程重读全部历史、重新决定后续步骤。为什么可能节省输入成本看一个简化算例。假设完成任务需要四轮规划。每轮都重新发送 1000 个单位的固定说明每一轮新增 200 个单位的历史材料并在之后的轮次中重复发送。仅计算四次规划请求读入的材料固定说明4 × 1000 4000 历史重读0 200 400 600 1200 合计5200如果某个分离规划与汇总的方案两次固定输入分别为 1000最终一次读入四份合计 800 的证据则这部分是 2800。这里的单位可以理解为模型处理的文本片段数也就是 token数字只是用于解释重复计算。这不是一个完整成本比较更不是论文实测的节省倍数。输出长度、工具中的额外模型调用、失败重试、缓存折扣和汇总开销都还没有计入。这套设计的适用边界也很清楚如果工具返回“目标不存在”或者返回结果会改变后续任务类型系统就需要分支处理或重新规划。给未知结果起一个变量名不能消除未知路线。3. LLMCompiler 解决的是依赖和等待减少模型重复读材料与减少工具等待是两个不同问题。继续看报告查询例子。找到报告后营收、员工数和业务结构可以分别读取解释差异需要等这些结果回来。把“哪一步必须等哪一步”写清楚程序才能安排并行。这种带方向、没有循环依赖的关系图叫有向无环图通常缩写为 DAG。LLMCompiler 的核心之一就是显式表达工具任务及依赖让程序调度已具备输入条件的任务。假设各步耗时如下忽略规划和调度开销步骤必须等什么教学设定耗时找到报告用户问题2 秒读取营收报告4 秒读取员工数报告3 秒读取业务结构报告5 秒统一核对口径三项读取结果1 秒全部串行需要 2 4 3 5 1 15 秒。若三项读取确实独立理想情况下只等其中最慢的一项需要 2 5 1 8 秒比例为 15 / 8 1.875。三个任务同时跑并不等于整体快了三倍。前置查询和最终核对仍然要做最慢的依赖路线决定了完成时间。这条决定完成时间的路线叫关键路径。现实里还要补上服务限流、连接数量、失败重试和新依赖。如果“读取营收”发现必须另外下载重述文件关键路径就变了如果三个工具都会修改同一份数据就不能仅凭“看起来独立”把它们同时发出去。因此ReWOO 和 LLMCompiler 的区别可以落到两个问题是不是重复请模型规划了是不是让本来可以独立的工具白白排队了先知道浪费在哪里再谈优化。4. 自我修改、反思和搜索究竟改进了什么生成了一段答案以后常见的下一句提示是“请检查并改进”。但不同方法保存的对象、看到的反馈、重新尝试的范围并不一样。Self-Refine 研究的是“生成答案—提出反馈—修改答案”。它主要围绕当前产物进行改进。反馈如果只是“再准确一点”下一轮很难知道该改变什么指出“结论没有来源”或“漏掉了空输入”才对应具体动作。Reflexion 则把一次尝试得到的反馈整理成可供后续尝试使用的文字经验。这种记忆通常进入后续上下文并不等于模型权重发生了更新。假设代码在空字符串上报错。一次有用的经验应该说明触发条件、失败行为和下一次该检查的地方。只写“要更加小心”几乎没有提供新的判断依据。更关键的问题是反馈本身是否可靠如果测试遗漏了大小写规则错误实现通过了测试系统可能把错误保存成“成功经验”。反思能够传播有效经验也可能传播错误结论。增加反思轮数之前应先检查它依据什么来判断好坏。LATS 又多做了一步保留多条候选行动路线用价值估计和访问次数来分配后续搜索。它不只是把同一个答案改十遍而是在不同可能之间探索、比较和回退。这里有个经常被忽略的前提环境能不能回退在隔离环境里运行候选代码可以重新开始已经发出的邮件、实际完成的交易却不能像树上的一个节点那样被丢弃。搜索算法中的“尝试”与现实世界中的“执行”必须有清楚的边界。5. STORM 的提醒内容更全面关系也可能写错长文生成还会遇到另一种困难一个问题最初被理解得太窄搜到的材料集中在同一个角度。STORM 把重点放在写作前的调查通过不同视角拓展问题再搜集材料、组织提纲和生成文章。它帮助我们看到写作质量不仅取决于最后一段生成提示还取决于前面究竟问过哪些问题。但材料齐全与结论可靠不是同一件事。来源一说“业务被重新分类”来源二说“某个分部收入下降”不能直接拼成“经营恶化导致收入下降”。两句话可能各有出处连接它们的因果关系却没有证据。检查生成报告时除了确认引用是否存在还要检查引用真的支持这一句话吗一句话里的事实和因果是不是被分别验证了这是对写作系统的设计启发不是声称 STORM 已解决事实核验。6. 怎样比较才不会把“花更多钱”误当成“设计更好”一种方法生成一次另一种搜索五十次再比较最终正确率可以回答“完整系统最后谁更好”却不能单独证明组织方式更有效。我更关心下面两种比较同样预算下谁完成更多任务达到相近质量时谁花的时间与费用更少。真正做实验时至少固定模型版本、任务集合、可用工具和可见资料。预算不同可以设置几个档位但要记录总输入输出、工具次数、失败请求、整体时间以及用户真正关心的结果。例如“成功”应明确为报告中的指定字段正确、有可核对的来源、没有越权操作而不能只看最终文字是否流畅。首次成功率、允许多次重试后的成功率也不能混称为一个“准确率”。这是一套建议的实验设计本文没有据此运行新的综合实验。7. 把九篇论文落回一张选择表当前主要困难优先考虑的机制最先检查的代价或前提新事实会改变下一步ReAct 的行动与观察循环工具是否可靠、何时停止信息已给出却经常漏步骤Plan-and-SolveSelf-Discover计划是否真的被正确执行未来步骤大致已知历史反复重读ReWOO 的结果引用与分离规划分支变化后怎样恢复独立工具串行等待LLMCompiler 的依赖调度限流、共享资源、关键路径当前答案有可描述的具体缺点Self-Refine 的反馈与修改反馈是否增加了有效信息重复尝试仍犯同类错误Reflexion 的尝试间经验反馈是否可信、记忆是否过期有多条值得比较的路线LATS 的候选搜索预算、状态回退、答案选择规则调查角度太少长文覆盖不足STORM 的写作前调查引用支持与事实关系核验把这张表用于自己的任务时最好再写一句可检验的选择理由因为当前主要问题是三个独立只读查询排队等待我先把依赖关系显式化在相同工具、相同问题和相同正确性要求下比较整体耗时与失败率。如果并行后限流重试更多就重新判断调度方案。这比“我们用了多 Agent、记忆、反思和树搜索”更容易指导下一步实现也更容易知道什么时候该停。原文与继续阅读上文各方法名称均链接到原论文。九篇原论文的机制、实验与限制可以沿上文链接继续阅读。这里的跨论文连接是阅读整理与设计分析不是新的实测结论。如果这篇文章帮你少加了一个没有必要的组件欢迎收藏本文。也欢迎带着一个具体任务讨论它究竟缺少事实、缺少步骤还是缺少可信的判断依据完整讲义、论文精读与阅读路线见 GitHubAI 工程学习手册。欢迎 Star 收藏或通过 Issue 讨论具体的证据与反例。