第十话｜Agent 的理论基础与演进：从行动决策到语言智能体

Mon, 29 Jun 2026 00:00:00 +0000

你让一个系统「查清这笔订单为什么处理失败，并给出或执行符合规则的处置」。

系统第一次动手之前，它知道的是任务目标和可用接口，但不掌握这笔订单的具体失败原因——不知道是该重试、该继续查询、还是该转人工。它面前没有一条现成的、可以直接执行的指令链。

它必须先做一件事——获得信息。查订单状态，看处理记录，问依赖服务。每查到一点东西，它才有依据决定下一步做什么。而下一步做完，又产生新的信息，逼它再判断一次。

这个「看一点、动一下、再看结果、再决定」的往复，指向一个具体的问题：一个系统怎样根据目标和观察，自主决定下一步行动。

这不是 LLM 发明的新问题。早在语言模型能写代码之前，Agent 研究就一直在回答它。真正发生变化的是另一件事——解决这个问题的若干环节，承担者从人工知识工程或专门模块，部分转移到了语言模型上。系统依然需要提供观察、执行动作并判断结果——具体职责如何分配，因架构而异。

下面是正文涉及到的代表工作的时间位置和研究问题。年份来自论文记录的公开时间，不代表哪一代取代了上一代；它们之间的关系大多是处理同一类问题的不同方法，或在工程上可组合，而不是技术上的继承：

年份	工作	关键问题	与其他工作的关系
1995	Wooldridge & Jennings 综述	给出 Agent 弱/强定义，梳理审慎式（planning agents/IRMA）、反应式（subsumption/PENGI）、混合式（PRS/TOURINGMACHINES/INTERRAP）三类架构	是综述与概念分类，不直接产生后续方法
2021	WebGPT（Nakano et al.）	微调 GPT-3 用文本浏览器检索、浏览并引用回答	早于 ReAct、SayCan 的训练型 LM+环境工作；展示了「LM+浏览器」组合
2022/01	CoT（Wei et al.）	few-shot 中间推理示例，让大模型在算术/常识/符号任务上表现跃升	与 ReAct 同年；CoT 关注推理文本，不涉及动作
2022/04	SayCan（Ahn et al.）	把 LLM 语义概率与 value function/affordance 概率相乘选择技能；机器人长程任务	价值函数和 affordance 是行为克隆或 RL 训练得到的；LLM 本身 zero-shot
2022/10	ReAct（Yao et al.）	把 thought∈L 和 action∈A 放进同一上下文 c_t 交错循环	论文明确引用 Inner Monologue 作为「据作者所知此类闭环系统的首个工作」；ReAct 贡献在 thought 是否由模型自身生成
2023/02	Toolformer（Schick et al.）	用自监督损失差（L_i^- - L_i^+ ≥ τ_f）筛选「真正降低预测损失」的 API 调用，再微调权重	明确不能链式调用、不能交互式使用；是工具能力的训练路线
2023/03	Reflexion（Shinn et al.）	actor + evaluator + self-reflection，记忆 1-3 条，针对同一任务多轮重试，不更新模型权重	用 verbal RL 把失败信号转成反思文本塞回上下文
2023/05	CoT 不忠实（Turpin et al.）	给输入加偏置，CoT 解释里不提，预测却跟着偏置走	反对「中间文本就是模型真实因果」的简单等同
2023/05	Voyager（Wang et al.）	自动课程 + 技能库（可执行 JS 程序）+ 代码生成 + 自验证（GPT-4 critic）；Minecraft	技能是嵌入检索的 top-5 上下文示例，不是直接调用；自验证无普遍正确性保证
2023/09	CoALA（Sumers et al.）	把记忆/行动空间/决策循环组织成概念框架，继承 Soar 的记忆分类	概念框架而非实验论文，回顾性组织已有工作
2024/05	SWE-agent（Yang et al.）	ACI 设计（edit 命令、100 行文件查看窗口、汇总式搜索接口、linting 守卫）+ SWE-bench Lite 评测	是「接口影响决策条件」最硬的消融证据之一

下面挑两个重要的关系说几句，避免读者把上面的时间序列当成「继承链」：

ReAct 与 Inner Monologue：ReAct 论文明确引用 Inner Monologue 是它所知的「此类闭环系统的首个工作」，而不是「语言模型首次接触外部环境」。前者是 ReAct 自己的话（Yao et al., 2022 §4），后者是常见的过度转述。Inner Monologue 的「inner monologue」其实是环境注入的反馈（injected feedback from the environment），ReAct 的 thought 才是模型自主生成的推理——这是 ReAct 与 Inner Monologue 的真正区别所在。
WebGPT、CoT、ReAct 的关系：三件事是平行探索，不是前后继承。WebGPT 在 ReAct 之前 1 年多出现，处理的是「LM+浏览器」的训练组合；CoT 与 ReAct 同年（2022），处理的是「推理文本」与「推理+行动交错」的不同问题；CoT 没有行动，ReAct 有行动——所以 CoT 不是 ReAct 的前置步骤。

其他工作（SayCan/Toolformer/Reflexion/Voyager/SWE-agent/CoALA）都基于各自的实验设置提出新机制，与上述工作的关系更多是「在同一时间窗口内对不同子问题的并行回答」，而不是一条发展线把它们串起来。

一、决定下一步，到底涉及哪几件事

把「决定下一步」拆开，一个系统每次做行动决策，至少要分清五件事。

目标：系统试图达到什么结果，谁定义这个结果是否合格。「查清失败原因并处置」是一个自然语言目标，但它没有告诉你什么算「查清」、什么算「处置到位」。

环境：真实发生变化的外部系统。订单库里那笔订单的状态、库存、支付通道的返回，这些是环境的一部分，不是系统内部的东西。

观察：系统通过某个接口实际拿到的那部分信息。环境里有十件事，系统可能只看到两件，而且这两件还可能过时、缺失、有歧义。

「观察」和「环境」之间，还夹着两层容易被忽略的东西。一层是 Runtime 记录——系统把每次查询的结果写进日志或数据库，这个记录不等于环境本身，也不等于系统「看到了」多少：日志里存了一堆字段，不代表系统下一轮真的把哪些字段放进了模型输入。另一层是系统据此形成的判断——拿到「库存为 0」这个观察，系统判断「不能继续支付」，这个判断是系统在观察之上做的推理，不是观察本身。所以同一个事实，至少有四个位置：环境里真实发生了什么、系统看到了什么、系统把什么存了下来、系统据此得出了什么判断。很多「系统不知道自己不知道什么」的故障，根源就是把这四层混在一起。

行动：可选的动作，以及这些动作怎样影响环境或获取信息。查询订单是一种行动，重试支付是另一种，转人工又是另一种。

评价：结果是否达到了完成条件。这里要分清评价信号和真实业务结果——评价信号是系统用来判断「成没成」的那个指标，它可能和业务真正想要的结果之间有差距。

用订单案例把这几件事串起来，就能看出它们为什么不能混为一谈。

系统不知道失败原因，第一反应是查询。这里有个容易漏掉的点：查询不改变任何业务对象，它只是减少系统的不确定性。一个「读」的动作，同样是在影响后续决策——查完之后，系统才知道该不该重试。

执行之后要看结果。这里又有一个坑：订单接口返回 200，只说明这一次请求成功到达并被处理了；返回的订单状态是否足以回答用户的问题、是否需要继续行动，是另一个问题。返回 200 和「问题已经解决」，是两码事。这个坑的根源，就是评价信号和业务结果之间的落差——「请求成功」是一个很容易拿到、也很容易被误当成「事情办成了」的信号，但用户真正要的是「这笔订单处理好了」，这两者隔着好几步。系统如果拿「接口返回 200」当完成信号，它就会在订单其实还没处置完的时候就停下来。

最后，完成条件必须独立判断。不是「系统觉得自己做完了」就算完，而是「结果能不能对得上目标定义的那个合格标准」。

这五件事，没有一件是 LLM 带来的。传统 Agent 研究在几十年前就用另一套办法在回答它们。

二、传统 Agent 怎么选择行动

传统 Agent 研究怎么选行动，要先分清两个不同的问题：一个是运行时怎么组织行动，一个是行动规则怎么获得。前者问「当下这一步怎么选」，后者问「选动作的那套规则从哪来」。它们经常被并排说成「几条路线」，其实不在一个层面。

先看运行时怎么组织行动，有反应式和审慎式两种典型做法，以及两者的混合。

反应式设计：直接根据当前观察或内部状态，快速映射出一个动作。看到「库存不足」，就停掉支付重试。它的好处是快、不需要环境模型；代价是难以表达长期目标——它不知道为什么停，只是「这个状态对应这个动作」这条规则在起作用。这里说的只是规则的一种简单实现方式，不能据此断定所有传统方法都是写死的 if-else。

审慎式设计：借助知识或环境模型，先组织未来的行动再执行。它需要三样东西：动作的前提条件（什么时候能做这个动作）、动作的效果（做完会变成什么样）、目标条件（什么样算到达终点）。用这三样，它可以推演「先查状态，如果超时就查实际结果，如果库存不足就换方向」。

这三样东西怎么组织推演，决定了审慎式设计的强弱边界。为了看清推演，先给这个教学环境定一套自洽的规则。每个动作都有前提、效果：

查询支付状态：前提是「尚未确认支付结果，且查询接口可用」；效果是「得到成功、失败或仍未知的观察」。
重新发起支付：前提是「已确认此前支付失败，且这个教学系统允许重试」；效果是「发起一次新支付，实际结果仍需查询或接收回调确认」。
目标条件是「订单已处置」。

现在推演就能跑起来了：系统从「结果未知」这个状态出发，「重新发起支付」的前提（已确认失败）并不成立，所以它只能先选「查询支付状态」。查到「失败」之后，重试的前提才被满足，这时才轮到「重新发起支付」。推演的力量在于，它能在一串动作执行之前，先检查每一步的前提在推演到的那个状态下是否成立——如果推演到「库存不足」，而下一步计划是「重新发起支付」，前提对不上，它就能在动手之前发现这条路走不通。

代价也在这里：这套推演要成立，前提、效果、目标条件都必须事先写清楚，而且这些前提一旦写死，就假设了环境按这些规则来。真实环境未必如此——「查询支付状态」可能超时、可能返回一个过期的结果，这时「已确认失败」这个前提本身都拿不准，推演就失去了抓手。环境知识越缺，推演越脆弱。这就是为什么审慎式设计和反应式设计会互相补充，而不是谁取代谁。

学习式设计：这是另一个维度的问题——不问「怎么组织行动」，而问「选动作的规则怎么获得」。学习式设计不事先写死规则，而是通过和环境交互、拿到反馈，调整自己的行动策略。它的机制链条是：环境给一个观察 → 系统按当前策略选一个动作 → 环境返回一个奖励信号 → 用这个信号去改策略，让下次遇到类似观察时更可能选那个收益高的动作。这里有一条关键边界——有反馈不等于实现了强化学习算法，保存一次错误信息也不等于更新了模型权重或策略参数。策略可以是一个查表、一个规则集合，也可以是一个神经网络，它只是「从观察选动作」这个函数的不同实现方式。更要紧的区分是「什么东西被改变了」——模型权重、显式的策略参数、还是下次执行时会被读到的记忆？三者是不同的对象，混在一起容易得出不准确的结论。

因为「怎么组织」和「怎么获得」是两个维度，一个系统可以同时落在两边：一个反应式策略，可以是人写死的，也可以是通过学习训练出来的；一个审慎式规划器，它的规则同样既可能来自人工知识工程，也可能来自学习。所以「反应式」和「学习式」不是二选一，而是同一个系统在不同维度上的两个属性。

真实系统往往把反应式和审慎式混在一起：既有长期计划，又保留即时反应。因为一个任务既需要「往哪个大方向走」，也需要「遇到突发情况立刻停手」。

这两种做法对「环境知识、计算资源、交互经验」的要求完全不同，但它们都在回答同一个问题：下一步选哪个动作。 它们的共同难点也一致——环境知识要么得提前写死，要么得让机器在特定环境里反复试错。而真实世界的目标是用自然语言说的，环境接口五花八门。

传统 Agent 里还有一个常被提起的名词 BDI（belief-desire-intention，信念-愿望-意图），它试图把「系统相信什么、想达到什么、当前承诺做什么」这三件事形式化地区分开。其中最有价值的一个区分是：系统「想要」的结果，和系统「当前承诺正在做」的动作，是两个不同的东西——「想要」不必然等于「正在做」，「正在做」也不必然等于「正在做对的那件事」。这个区分在后面讲 LLM Agent 时还会用到——很多「Agent 卡住了」的故障，根因之一就是「承诺在做的事」已经偏离了「想要的结果」。

有没有一种东西，既懂自然语言目标，又能适应没见过的环境？这就是语言模型被拉进来的原因。

三、LLM 进来之后，改变的是哪一环

LLM 改变的，不是「要不要闭环」，而是闭环里任务表达和行动选择这两件事，从人工写死的规则和专用模块，部分转移到了「预训练参数 + 任务时上下文 + 外部工具」的组合上。观察、执行、评价这几环依然主要由系统承担——外部工具负责把环境状态变成可读的信息，执行层负责真正落地动作，评价环节负责判断结果是否达标。

这三层必须分开看。

预训练参数：模型在训练时学到的语言能力和世界知识，固化在权重里。它是模型能用 prompt 产生回答的基础之一，但模型「实际能输出什么」还取决于后训练、推理时的解码方式、输入和工具——这些都不只在参数里。

任务时的指令和示例：这次任务里喂进去的东西。给几个例子、描述清楚目标，模型的本次输出就可能不同。注意，in-context learning 是通过输入影响模型输出的机制，与「更新权重」是两件不同层面的事（Brown et al., 2020）。

这两个层次的分界，决定了系统能做和不能做什么。在不更新权重的推理设置下，指令、示例和观察都通过输入影响模型输出——系统不需要为了换一种行为去重训模型，只需要改变输入条件。这是 LLM Agent 区别于「每换任务就重训一个模型」的关键。任务边界本身不意味着上下文自动清空——是否在任务结束后保留、什么时候清理、是否在下次任务里继续使用，由应用层决定，不由模型本身决定。所以「这一次输入触发的行为」能持续多久，取决于系统在多大程度上继续把这些信息喂给模型。模型的能力来自训练，但模型在「这次任务里的输出」，是被输入条件临时塑造的；这两个来源经常被混为一谈。同一个模型在不同上下文下可能表现差异很大，正是这个机制的结果。

外部工具：模型不自己算库存，它调一个工具去算。工具承担了「精确执行」的部分，模型承担了「判断何时需要、怎么用结果」的部分。

自然语言为什么有助于组织任务？因为它能表达目标、描述工具、记录观察、总结经验，而且天然能迁移到不同任务——同一个模型，既能查订单，也能写代码。但这里要留一个心眼：自然语言表达可能不完整、不精确、甚至不能直接执行。能说清楚，不等于已经理解对。

回到订单案例就能看清这个缝隙。「查清失败原因并处置」这句话，人一听就懂，但作为给系统的目标，它漏掉了太多东西：什么叫「查清」？查到哪个程度算够？「处置」是只能给建议，还是可以直接退款？这些没写出来的东西，模型得靠自己的常识去猜。猜对了任务就顺，猜错了方向就偏。这些目标缺失的字段必须由人或者既有政策事先定义（什么时候能退款、退款的金额上限），不能在事后用「评价环节」补——评价只能判断结果是否满足一个已经定义好的标准，不能凭空造出标准。自然语言的灵活性，和它作为「目标规格」的不精确，是同一枚硬币的两面。

中间推理（Chain-of-Thought）是这里最容易被误解的一环。必须把三件事分开：

输出里出现了中间步骤；
这些中间步骤让某项任务表现变好了；
这些中间步骤忠实呈现了模型内部的因果推理过程。

第一件和第二件都被实验证实过——CoT 用 few-shot 示例，让足够大的模型在数学、常识、符号推理上表现跃升（Wei et al., 2022）。但第三件没有被证实，而且有证据反对它：有研究发现，给输入加一些偏置特征（比如把选择题的选项顺序重排，让答案总是 A），模型会给出迎合这个偏置的答案，却在自己的推理文本里完全不提这个偏置（Turpin et al., 2023）。也就是说，看得见的推理轨迹，不等于模型真实的决策依据。

这还不是语言模型接触环境的全部。工具能力本身也有训练层面的研究：Toolformer 让模型自己学会「什么时候该调工具」（Schick et al., 2023）。具体做法是采样候选调用、真执行、用自监督损失筛选——只保留那些「提供 API 调用及其结果后，模型预测后续 token 的损失下降超过阈值」的样本，再把这些调用交错插入原文构造训练数据，微调权重。它是训练层面的方法，且明确不能链式调用、不能交互式使用。

同样的道理，也适用于「规划」。模型能输出一个看起来合理的多步计划——先查状态、再判断、再处置——这件事本身，不等于这个计划真的会在执行中成立：计划里每一步的前提，可能在前一步做完之后已经变了；环境可能在计划执行到一半时改了；也可能根本没有一个环节在检查「是不是该停下来」。生成一份编号列表和完成一次规划，隔着的是分支、评价、搜索、重新规划这些东西——即「谁在选择下一步、计划什么时候改、谁决定终止」的机制。这些是语言模型本身不自动提供的，要靠系统层面补上。

把这些合起来，结论是：LLM 让「决定下一步」这件事的表达和选择变得灵活了，但它没有让闭环消失。模型「说出」一个动作，离环境「执行」它，中间还隔着任务相关性、可行性、授权、结果四道坎。

四、从「提出动作」到「依据环境继续决策」

一条真实的数据流是这样的：

任务和已有观察 → 形成模型输入 → 模型提出动作 → 执行层尝试执行 → 得到结果 → 更新后续输入 → 再选择行动。

关键不在箭头有几个，而在新观察怎样进入下一轮输入。只输出一段带着 Action 和 Observation 字段的文本，不足以证明真的发生了环境交互——交互要成立，至少要满足三层证据：(1) 一次真实的执行确实尝试调用了外部环境；(2) 执行得到的结果被传回给了下一轮的输入；(3) 该结果对模型本轮的输出产生了可观察的影响。一次查询可能返回和上次相同的结果，正确决策也可能不变——所以「观察是否真的改变了判断」本身需要可测量的证据，不是默认假设。

这里要分清四件不同的事：

任务相关性：这个动作是否有助于目标。
可行性：当前环境是否具备执行这个动作的条件。
授权：系统是否允许执行。
结果：执行后是否达到预期。

这四件事，任何一个都可能单独出问题，而它们常常被当成一回事。语言层面的任务相关性和环境层面的可行性，是早期研究就分开处理过的：SayCan（Ahn et al., 2022）让语言模型提供高层语义知识（「这一步该做什么」），再让技能的价值估计提供 grounding（「这一步在当前环境下做不做得到」），两者按 argmax 乘积选择下一步——是基于两个概率估计的选择，不是「保证只提可行动作」的硬约束（论文自己的失败分析里，65% 来自 LLM 误判、35% 来自 affordance 误判）。这是机器人场景里的做法——它处理的是相关性和可行性，不是企业系统里的权限检查。相似的问题，不同的机制，不能直接迁移。

回到订单案例，这四件事各有各的翻法。任务相关性和可行性，模型可以靠推理和工具结果来判断——请求超时，不说明外部操作没成功，超时只是「没收到响应」，实际可能已经成功，需要查实际状态；观察到库存不足，就不能继续重复支付请求，得转向和库存相关的下一步，原计划的前提变了，计划就不能无条件执行下去。但授权是另一层：比如「直接退款」这个动作，从任务上看它有助于处置订单，从环境上看退款通道也正常，但系统可能根本没被授予退款的权限，只能给人工建议。模型「认为该退款」和「系统允许退款」，是两个独立的判断，前者再正确也不能越过后者。至于结果，执行了退款，还要看退款是否真的到账、订单状态是否真的更新——执行动作和执行后的结果达标，又隔着一层。四件事，任何一环断了，整个「决定下一步」就错了，但它们断的方式完全不同，排查时也要对着不同位置找。

语言模型接触浏览器、机器人这类外部环境，不是 ReAct 开的头。WebGPT 在 2021 年就微调 GPT-3 让它搜索、浏览网页并引用来源，用人类反馈优化回答质量（Nakano et al., 2021）。ReAct 的贡献是另一件事——它在论文里明确引用 Inner Monologue 是它所知的「此类闭环系统的首个工作」，而它自己做的，是把「语言推理」和「外部动作」交错进同一个闭环里，让推理帮助行动、行动反过来喂信息给推理（Yao et al., 2022）。Inner Monologue 也有它自己的闭环机制，ReAct 与它的差别不在「是否闭环」，而在 thought 是否来自模型自身的推理。

把这三份工作放在一起，能更清楚地看到「接触环境」这件事可以拆成哪些值得关注的机制。下面只是分析时重点观察的几条，不是说三套系统各自只能做一类事：

WebGPT 重点观察的是训练层面：用微调 + 人类反馈把语言模型改造成会浏览网页、引用来源的问答器。论文评测的对象是问答，不等于这个方法就只能用于问答。
SayCan 重点观察的是相关性与可行性的结合机制：用 LLM 的语义概率提供任务 grounding，用价值函数（value function）/affordance 提供环境 grounding，按 argmax 乘积选下一步。这里有两点必须澄清——第一，价值函数和 affordance 是通过行为克隆或 TD 强化学习训练得到的，不是零样本；只有 LLM 本身是 zero-shot 使用（不微调）。第二，乘积选择是基于两个概率估计，不是「保证只提可行动作」的硬约束——SayCan 自己的实验里 65% 的失败来自 LLM，35% 来自 affordance 误判。
ReAct 重点观察的是推理与行动的组织：把 thought ∈ L（不改环境）和 action ∈ A（触发观察）放进同一个上下文 c_t，让「想一步」和「做一步」交错。ReAct 也包含微调实验——用 3000 条自身生成的正确轨迹 bootstrap 微调 PaLM-8B/62B，这是该论文明确报告的部分，不是「没有训练更新」。

三件事各自的工程取舍不同：WebGPT 的代价是构造人类反馈成本高；SayCan 的代价是每个新场景都要训练一组技能和价值函数；ReAct 的代价是 prompt 需要管理上下文长度。但它们的工程结构也都包含这里没有单独标出的其他环节——比如工具的具体实现、记忆的组织、评价信号的设计——只是分析重点不在那里。

一个闭环让一次任务能跑通。但这一次任务里积累的反馈，怎么变成「下一次任务」的经验？这是两个完全不同的问题。

五、反馈、反思与经验，三种时间尺度

「Agent 会学习」这句话，把三件不同的事揉在了一起。下面把它们按时间尺度分开。

一次尝试中的逐步反馈：执行一个动作，依据观察决定后续动作。这是第四节讲的闭环，作用范围只在这一次尝试的内部。

同一任务的多次尝试：任务目标不变，第一次没做成时反思调整，再次尝试完成原目标。重做同一道题、再次修同一个函数，都属于这一类。Reflexion 处理的就是这个层级——它「reset environment, start a new trial」，任务本身不变，只是同一任务的新一轮尝试。

不同任务之间的复用：任务 A 留下的经验或技能，在任务 B 中被选择和使用。Voyager 的技能库落在这里——一次 Minecraft 任务写下的可执行代码，下次在另一个场景里检索出来当作「技能」用。

把这三层混在一起是常见的混淆来源。「看了结果改了动作」属于第一层，「同一题重做」属于第二层，「以前的经验被新任务用上」属于第三层。第三层需要更完整的检索、适用性判断和验证机制；前两层不一定需要。

Reflexion 落在第二层。它的闭环涉及六个环节：

谁执行任务：actor，一个语言模型，负责生成动作。
谁评价结果，依据什么：evaluator。在编程任务里，它的依据不是「看起来对不对」，而是跑一遍自生成的单元测试，测试过不过，是二元信号。
反思用哪些输入：actor 这次失败的轨迹 + evaluator 给的「失败」信号。反思模型把这两个输入转成一段自然语言，指出「具体哪一步做错了、下次该怎么做」。
反思存到哪：一个长期记忆缓冲区，容量很小，通常只留 1 到 3 条经验。
后续怎么读回：下一轮 actor 开工时，除了当前任务的历史，还把这些反思一起塞进上下文。
何时停止：评估通过，或者达到最大尝试次数。

这六个环节决定了 Reflexion 到底「学习」了什么（Shinn et al., 2023）。它没有更新任何模型权重，它改变的只是下一轮 actor 能看到什么上下文。所谓「verbal reinforcement learning」，本质是把「失败」这个稀疏信号，放大成一段能被下轮读懂的、具体到「改哪一步」的文字，塞回上下文里。这和强化学习里的做法不同——强化学习通常用奖励信号更新模型权重或策略参数。两者都姓 reinforcement，但做的事不同：前者改变的是系统行为条件，后者改变的是模型本身的参数。

Reflexion 的关键不在「模型反思后变聪明」，而在评价信号的可靠性决定了反思的质量。论文自己报告过翻车：自生成的测试有假阳性（MBPP Python 假阳性率 16%，HumanEval Python 1%）——测试全过、实现其实是错的，导致它过早判定成功、提交了错误答案，最终在 MBPP Python 上结果反不如基线（77.1% vs 80.1%）。它的 Table 3 消融还显示一个不直观的发现：只保留反思但去掉测试生成，准确率从 0.60 降到 0.52，反而劣于基线——说明没有可信评价来源的反思是误导的。在需要大量探索的任务上，它也卡在局部最优，因为它生成不出有用的反思。反思不是免费的午餐，它依赖一个可信的评价来源。

跨任务的技能复用，看 Voyager（Wang et al., 2023）。它的闭环是：自动课程提任务 → 从技能库检索相关技能 → 生成代码 → 执行拿反馈 → 自验证 → 把验证通过的代码存回技能库。技能是可执行的程序，存在向量库里。需要看清几件事：

检索出来的代码不是被直接调用来执行任务，而是作为 prompt 中的上下文示例（in-context examples）注入 GPT-4 的输入，引导它生成新代码（论文 Sec. 2.2）。检索方式是用 GPT-3.5 生成的程序描述做嵌入，top-5 召回。
任务完成的判定由另一个 GPT-4 critic 完成，是个启发式文本判断——论文自己承认「自验证模块偶尔也会失败，比如没识别出蜘蛛丝是打败蜘蛛的成功信号」。不存在普遍正确性保证。

消融实验证明，去掉技能库、去掉课程、去掉自验证，性能各自都明显下滑。

和 Reflexion 对照着看，能看到「经验」的两种完全不同的表示方式。Reflexion 存的是自然语言反思——一段「上次哪步错了、下次怎么做」的文字，靠塞回上下文来影响下一轮。Voyager 存的是可执行程序——一段已经跑通、验证过的代码，靠嵌入相似度检索出来当作「技能」用。前者的价值在「提醒模型注意什么」，后者的价值在「直接把一个验证过的能力搬过来」。两者都要面对同一个问题：存下来的经验，下次怎么找到、怎么判断还适用。Reflexion 靠的是固定小缓冲，容量一到就顶掉旧的；Voyager 靠的是向量检索，但检索回来的代码也可能因为环境变了而不再适用——而且它只是塞进 prompt 让模型参考，不保证生成的代码在新场景下能跑通。记录成功，和「之后能找到并正确用上」，中间隔着一整套检索、匹配、验证的机制。

这里要小心一个类比陷阱：Voyager 里的可执行程序、某些产品里的 SKILL.md 文件、人类的认知技能，都「复用经验」，但不是同一个技术对象——表示方式不同、执行方式不同、验证方式不同。可以讨论它们共同关注复用，但不能画等号。

用一张表把「改变发生在哪里」看清楚：

改变位置	要问的问题
模型参数	是否发生了训练更新？用了什么数据或反馈？
当前上下文	加了什么信息？作用持续到什么时候？
外部记忆	保存了什么、怎么找回、何时进入模型输入？
可执行技能	谁生成、如何验证、怎样检索和组合？
环境接口	返回了什么新信息，减少了什么判断负担？

记录下一条成功经验，不等于之后能找到并正确用上它。 错误经验、过时环境、检索噪声、技能前提不满足，都是复用的代价。回到订单案例，得到一条「过去这类超时后来是成功了的」经验，先要判断它的适用条件，再决定采不采用——而不是拿来就用。

把这条边界说实一点。假设这条经验是「支付失败时直接重新提交」。它以前是对的——老通道的「失败」返回意味着已确定未扣款。但新通道改成「失败」必须是先调用查询接口、拿到上一笔请求的最终状态后再返回。这种情况下，旧经验会直接触发重试，根本没去查实际状态，结果是把一笔已经扣款但只是回调延迟的订单再次扣了一次。旧经验错的不是「应该重试」这个判断，而是它没意识到接口契约变了：原来的「失败」= 不确定，现在的「失败」= 必须先查才能知道结果。经验的价值依赖于它被总结时的接口契约；接口一变，经验就可能从资产变成负债。所以「会存经验」和「会判断经验还适不适用」是两码事——评价经验是否仍然成立，比保存经验本身更关键。

这些机制放在一起说明一件事：能力来自模型、上下文、记忆、决策组织和执行层（加评价）的组合，不是只来自模型一个部件。这个组合的任何一个环节，都可能单独失效。

六、能力分布在系统的哪些环节

一个 Agent 不稳的时候，该查哪里？这个问题没有统一答案，因为能力可能分布在五个环节，任何一个都可能单独失效。

模型：根据输入生成推理、计划或动作候选。决策组织：决定模型何时被调、上下文怎么形成、下一步怎么推进。执行层：真正调用工具拿到结果。状态与记忆：保留当前任务的信息，以及要跨任务用的经验。评价：判断当前结果是否达到完成条件。

这五个不是标准术语，真实系统可能合并它们。它们的意义在于帮你定位问题：输入错了查模型和上下文，动作没执行查执行层，结果不对查评价，跨任务记不住查记忆。

工具接口这一层，常常被低估，但它能实质改变模型的决策条件。SWE-agent 用消融实验量过这件事的分量（Yang et al., 2024）。Table 3 在 SWE-bench Lite 上给出了几个值得看清的结果：默认设计 18.0%；拿掉专门的 edit 命令、退回让模型用 shell 里 sed 硬改，跌到 10.3%（单因素最大跌幅）；拿掉 linting 守卫（edit 后自动跑 flake8 撤销错误编辑），跌到 15.0%。最有反直觉价值的对比是搜索接口——SWE-agent 的默认是汇总式接口（一次性显示最多 50 条结果，并对欠具体化的查询给出优化建议），得分 18.0%；而逐条浏览式接口（仿 Vim/VSCode 那种按 next/prev 翻看每条匹配）的得分是 12.0%，比不提供搜索工具（15.7%）还差。原因是模型不具备人类跳过不相关结果的能力，会穷尽式遍历所有匹配、耗光上下文窗口和预算。语法检查器能在编辑引入错误时撤销并返回错误信息，减少级联错误。

这些是「接口改变决策条件」的证据，不是「权限治理」的证据。提高可操作性、减少错误传播、权限隔离、业务授权，是四件不同的事，用一种功能的证据去证明另一种，是越界。

CoALA 是一套有用的组织工具（Sumers et al., 2023）：它把记忆分成工作记忆和长期记忆（情景/语义/程序），把行动分成内部行动（检索、推理、学习）和外部行动（接地到物理环境、对话、数字环境），把决策组织成「提议 → 评估 → 选择 → 执行」的循环。它的价值不在「给系统贴标签」，而在帮你说清楚「这项新能力落在哪一层」。但它是一篇概念框架，回顾性地组织已有工作，不是实验结论，也不能当成组件清单去照抄。

回到订单案例，「查库存」这一个动作，接口返回的信息密度不同，会直接影响模型下一步判断。接口怎么设计，决定了模型能看到什么——但更多字段未必更好，关键在于返回的内容是不是这次决策需要的相关信息、是不是可靠的。SWE-agent 的 Table 3 里有一个相关观察：文件查看窗口从 30 行扩到 100 行能涨分（14.3%→18.0%），但把整个文件无窗口限制地丢进去反而跌到 12.7%——超过 100 行之后噪声开始淹没信号。这说明接口的设计目标不是「越多越好」，而是「刚好能完成当前决策」。

七、回到那个订单，你会怎么判断

现在，拿到一个陌生的 Agent 方案，你可以依次问它六个问题：

它的目标和成功标准是什么，谁定义的？
它实际看到了什么，还有哪些信息它不知道？
下一步由谁、根据什么选出来的？
行动怎么执行，结果怎么回到后续决策？
经验存在哪里，下次使用时怎么影响行为？
它新增的能力在哪一层，证据能支持多大范围的结论？

用这六个问题回头再看开篇那个订单任务。系统卡住了，先别急着调模型。要分清是哪一环失效：

决策问题：观察已经拿到关键信息，但模型选择了不适当的下一步（用了过时的经验、漏了某个前提、把无关动作当成了相关动作）。
执行问题：动作选得合理，但调用工具失败、权限拦截、接口超时——决定没问题，落地这一步断。
评价问题：执行成功、结果拿到了，但系统判成「完成」——可能是完成条件定义得过于宽松（拿 200 当办成），或者是评价信号和业务结果之间有落差。

这三种排查方向对应的修法不一样：决策问题要换上下文或换策略；执行问题要查接口、查权限、查重试；评价问题要重新定义完成标准。观察不足（没查到关键信息）也是一类常见失效，它属于输入端问题，不在上面三类之内，需要扩大查询或换接口。

决定下一步的闭环——目标、观察、行动、反馈——从来没有因为 LLM 而消失。LLM 让任务表达和行动选择变得更加灵活，可以由语言推理承担原先需要人工知识工程或专用模块的工作；但观察来源、动作执行、结果判断这几环，依然要由外部工具、执行层和评价机制提供。一个具体系统里哪些环节交给语言模型、哪些环节由代码或人工保证，要看架构选择——不能用一个整齐的「全迁移」图景去描述所有 LLM Agent。但「看一点、动一下、再看结果、再决定」这个基本结构，从传统 Agent 到语言智能体，一直是同一个。

至于「下一步」到底该由谁拍板——是模型、是代码、还是一份事先写好的计划——那是另一个问题，下一篇接着讲。

参考资料

本篇正文里引用到的研究，按首次出现顺序排列：

Wei et al., 2022. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903. https://arxiv.org/abs/2201.11903
Nakano et al., 2021. WebGPT: Browser-assisted question-answering with human feedback. arXiv:2112.09332. https://arxiv.org/abs/2112.09332
Ahn et al., 2022. Do As I Can, Not As I Say: Grounding Language in Robotic Affordances (SayCan). arXiv:2204.01691. https://arxiv.org/abs/2204.01691
Yao et al., 2022. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629. https://arxiv.org/abs/2210.03629
Schick et al., 2023. Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761. https://arxiv.org/abs/2302.04761
Shinn et al., 2023. Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366. https://arxiv.org/abs/2303.11366
Turpin et al., 2023. Language Models Don’t Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting. arXiv:2305.04388. https://arxiv.org/abs/2305.04388
Wang et al., 2023. Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv:2305.16291. https://arxiv.org/abs/2305.16291
Sumers et al., 2023. Cognitive Architectures for Language Agents (CoALA). arXiv:2309.02427. https://arxiv.org/abs/2309.02427
Yang et al., 2024. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. arXiv:2405.15793. https://arxiv.org/abs/2405.15793
Wooldridge & Jennings, 1995. Intelligent Agents: Theory and Practice. https://www.cs.ox.ac.uk/people/michael.wooldridge/pubs/ker95/ker95-html.html

Reflexion on Renxin's Blog