工具都齐了,AI为什么还是办不好事?

AI江湖那些事儿

第三回：工具都齐了，AI为什么还是办不好事？

ReAct的诞生：让大模型在行动中修正判断

技术史·从工具调用到任务执行｜第三篇

一、张主任抢走B205之后，AI该怎么办？

上一回，我们讲到一件不大不小的麻烦。

一位员工让AI帮忙预约会议室：下午三点到四点，八个人参加，需要投影仪。

AI已经通过MCP连接了会议室管理系统。它会查询会议室，也知道怎样调用预约接口。

查出来的B205，时间合适、人数合适、设备也符合要求。

眼看事情就要办成，张主任突然抢先一步，把B205订走了。

系统返回一条消息：

SLOT_TAKEN：会议室已被占用。

这时候，AI应该怎么办？

如果它回答：“预约失败，请自行重新选择。”

那它确实调用了工具，却没有真正替人把事情办完。

如果它一声不吭地把会议改到明天，又显然越过了用户的授权。

比较合适的做法，是保留原来的会议时间、人数和设备要求，重新寻找其他符合条件的会议室。如果确实没有，再向用户询问是否允许调整条件。

这些判断，对于一个有经验的行政人员来说，几乎是下意识完成的。

但对于大模型，这里面有一个非常重要的技术变化。

它不只是回答用户的问题，还要根据刚刚执行的动作和得到的新信息，判断下一步该做什么。

这一回，我们要认识的技术叫ReAct。

它的名字来自两个英语单词：

Reasoning，推理。

Acting，行动。

两者放在一起，便是ReAct。

这个名字看起来很简单，却回应了大语言模型研究中的一个实际难题：模型可以分析问题，也可以产生行动指令，怎样才能让分析指导行动，又让行动获得的真实信息反过来修正分析？

二、2022年，研究人员发现：会想与会做，原来是两件事

2022年，大语言模型已经展示出相当不错的语言理解和问题求解能力。

其中一项受到关注的研究方向，是Chain-of-Thought，简称CoT，通常称为思维链。

过去，用户向模型提出一个问题，模型可能直接给出答案。

CoT则通过示例或提示，引导模型生成一系列中间分析步骤，再得出结论。

例如：

“甲比乙年长三岁，乙今年十二岁，甲多大？”

模型可以先写出：

乙今年十二岁。

甲比乙大三岁。

因此甲十五岁。

对于某些算术、逻辑和多步骤问题，这种方法可以改善模型表现。

但它存在一个明显的局限。

模型可以一直分析，却未必知道外面究竟发生了什么。

假设有人问：“某位科学家获得奖项时，他所在研究机构的负责人是谁？”

模型可能先根据已有知识猜测获奖年份，再猜测当时的负责人，最后写出一段看似严密的分析。

问题是，中间某一步如果猜错，后面的推理可能建立在错误事实上。

即使分析过程看起来很完整，也不等于答案有可靠依据。

这是一类“只推理”的问题。

另一边，也有研究让语言模型根据文字环境直接选择行动。

例如，在一个模拟房间里，模型接到“把苹果放到冰箱里”的任务。

它需要依次选择打开门、寻找苹果、拿起苹果、打开冰箱等动作。

这种方法让模型能够与环境交互，但如果只是不断根据当前文字选择下一个动作，它可能缺少对整体目标和已完成步骤的有效管理。

于是出现两种不同的不足。

只推理：容易脱离外部事实，在错误信息上继续分析。

只行动：能够操作环境，却可能迷失在一连串动作中。

2022年10月6日，Shunyu Yao等研究人员公开论文《ReAct: Synergizing Reasoning and Acting in Language Models》。

论文后来被ICLR 2023接收。

研究人员来自普林斯顿大学与Google Research。他们提出的问题，并不是怎样训练一个全新的超级模型，而是能否让现有语言模型以新的方式组织任务求解过程。

他们想到，把推理和行动交织起来。

需要判断时，生成分析。

需要事实时，执行查询。

获得新事实以后，再决定下一步。

研究论文的引言甚至使用了一个厨房里的例子：做菜的人会一边准备食材，一边想下一步；发现没有盐，便考虑替代调料；不知道怎么做面团，就去查食谱。

人类的行动与判断，本来就经常这样交替发生。

研究者想知道，语言模型能否利用类似的组织方式解决任务。

这便是ReAct的出发点。

三、ReAct究竟是什么？先看它最核心的三个词

要理解ReAct，不需要先了解复杂的算法。

只需要记住三个词。

Thought：任务分析。

Action：行动指令。

Observation：环境观察。

它们分别做不同的事情。

Thought是模型生成的一段语言分析。例如：“现在还没有确认会议室预约成功，需要检查执行结果。”

Action是模型提出的具体行动，例如调用预约接口、查询数据库或者搜索网页。

Observation则来自外部环境。例如，工具返回“会议室已被占用”。

这里有个细节特别重要。

Thought和Action可以由模型生成，但Observation必须由真实的工具或任务环境返回，才具有外部观察的意义。

模型自己编造一句“会议室预约成功”，那仍然只是模型生成的文字。

只有业务系统返回了有效的预约结果，才能成为真正的执行依据。

我们可以用一段简化的任务记录，观察ReAct如何运行。

首先，用户提出要求：

帮我预约下午三点到四点的会议室，八个人，需要投影仪。

系统已经查询到B205符合条件。

模型开始处理下一步：

Thought 1：

B205当前符合要求，可以尝试提交预约。任务尚未完成，需要等待预约结果。

Action 1：

book_room("B205")

外部程序接到这个指令，调用会议室管理系统。

系统返回：

Observation 1：

SLOT_TAKEN：B205已被其他人预约。

如果这只是一次性的工具调用，AI可能到这里就结束了。

但是，在ReAct式过程中，Observation会被加入下一轮模型能够读取的上下文。

于是模型有机会继续处理：

Thought 2：

B205无法预约。用户没有要求必须使用B205，原来的时间、人数和投影设备要求也没有改变。需要寻找其他符合条件的会议室。

Action 2：

find_rooms(time="15:00-16:00", capacity=8, projector=true)

工具返回：

Observation 2：

B206：10人，有投影仪，空闲。

C301：12人，无投影仪，空闲。

D108：6人，有投影仪，空闲。

模型获得了新的信息。

它可以判断B206符合原始要求，而另外两间存在明确缺陷。

接下来：

Thought 3：

B206符合全部条件，可以尝试预约。提交成功后仍需核验预约状态。

Action 3：

book_room("B206")

Observation 3：

CONFIRMED：B206预约成功，预约编号BK-1029。

在这个假设案例中，业务系统确认了一条有效预约记录，系统可以据此结束任务。

请留意整个过程。

同一个模型，前后提出了三次不同的行动。

第二次行动并不是在最初回答时就确定好的，而是受到第一次预约失败这一新观察的影响。

这便是ReAct最直观的特点：

行动不是推理的终点。行动得到的结果，会成为下一次判断的依据。

需要说明的是，这段B205过程是为了理解原理构造的教学案例，并非论文中的实验。论文所说的Thought也是模型生成的可见语言轨迹，不能直接等同于模型全部真实的内部计算过程。

四、秘密在哪里？模型到底是怎样做到的？

读到这里，可能会产生一个疑问。

既然ReAct能够不断调整行动，研究人员是不是重新训练了一种专门负责做事的模型？

事情比想象中有趣。

在论文的主要大模型实验里，研究人员使用的是当时已有的PaLM-540B，并没有为了实现ReAct而修改这个大模型的参数。

他们主要使用一种叫Few-shot Prompting的方法，也就是在提示上下文中放入少量示范。

示范不只是普通问答，而是展示了完整的任务处理轨迹：

什么时候分析。

什么时候选择动作。

执行动作后，会得到什么观察。

观察返回后，下一步怎样继续。

大语言模型本来就是根据已有上下文生成后续内容。

如果上下文中给出的例子，是一个交替出现Thought、Action、Observation的任务过程，模型就可能沿着这种结构继续生成。

不过，这里还有一部分工作，不能由模型独自完成。

假设模型输出：

Action: book_room("B205")

这仍然是一段文本。

它本身不会改变会议室数据库。

必须有一个外部执行程序，识别模型提出的行动，检查是否允许调用这个工具，并按照接口要求实际发出请求。

随后，外部程序把业务系统返回的结果，整理成一条Observation，再提供给模型。

整个过程可以理解为：

模型生成下一步行动 → 执行程序调用工具 → 工具返回观察结果 → 观察进入新上下文 → 模型继续生成。

如果用极简的伪代码表达：

while not finished:    output = model.generate(context)    if output.is_action:        result = execute_tool(output.action)        context.append(result)    elif output.is_finish:        finished = verify_result(output)

这不是ReAct论文中的原始代码，而是帮助理解其运行方式的简化表示。真实系统还必须处理工具权限、参数校验、循环次数、超时与任务终止等问题。

现在就可以解释一个经常被混淆的概念。

ReAct不是模型，不是工具协议，也不是一套完整的Agent平台。

它是一种组织语言模型任务分析与外部行动的方法。

模型负责根据上下文提出分析和行动。

外部程序负责真实执行。

环境反馈再进入下一轮上下文。

另外，ReAct也不要求模型每次行动之前，都必须写出一大段Thought。

原论文指出，对于行动步骤较多的交互任务，语言分析可以只在重要位置出现，而不是机械地每一步都重复一次。

研究人员后来还探索过利用成功的ReAct任务轨迹，微调较小模型。

因此，ReAct既可以通过提示示范引导，也可以与模型训练结合。

它的核心并非某一种提示格式，而是让语言分析与环境行动在任务求解过程中相互配合。

五、真正的实验：加入推理之后，机器确实更会做事了吗？

一个技术思想听起来合理，并不等于它真的有效。

ReAct论文很值得读的地方，在于研究者设计了不同任务来进行比较。

其中两个实验尤其适合理解。

第一个叫ALFWorld。

它是一个文字交互的家庭环境。

系统可能要求智能体找到某件物品，把它清洗、加热或者放到指定位置。

模型必须不断接收环境描述，选择下一步动作。

有时候，目标物品不在预期的位置。

有时候，需要先完成另一个操作，后面的动作才可能成功。

第二个叫WebShop。

它是一个模拟网上购物的环境。

智能体需要根据用户提出的商品要求，在网页中搜索、查看详情、筛选条件，并完成符合任务要求的购物流程。

这类任务不只需要回答问题，还需要与环境进行多轮交互。

研究人员将只生成行动的Act-only方法，与ReAct进行比较。

在论文报告的PaLM-540B少样本提示实验中，结果如下：

ALFWorld提高了约26个百分点，WebShop提高了约9.9个百分点。

要注意，这些数字对应的是2022年前后的特定模型、实验环境和提示设置，并不能理解为ReAct在所有企业项目中都会带来同样的提升。

但实验至少支持了一个重要判断。

在需要多次行动、环境观察和目标跟踪的任务中，加入适当的语言分析，能够改善行动效果。

为什么？

因为模型不仅要回答“眼前有什么动作可以执行”，还可以根据任务目标判断：

刚刚完成了什么？

现在距离目标还差什么？

是不是走错了方向？

是否需要从环境中获取新的信息？

这使语言模型的分析能力，参与了连续行动的过程。

而论文还有一个反过来的发现。

在HotpotQA问答实验里，单独使用ReAct的准确匹配率为27.4%，反而略低于只使用思维链CoT的29.4%。

将ReAct与CoT方法结合后，其中一种组合方式达到35.1%。

研究人员还发现，ReAct可能因为生成重复的分析和行动而陷入循环。有些失败来自搜索结果不理想，有些则来自模型未能正确选择下一步。

这个反例十分重要。

它说明ReAct有价值，但并不是每多调用一次工具、每多增加一次Thought，效果就必然更好。

在某些以推理为主的问题中，过于频繁的行动反而可能打断分析。

在另一些需要外部事实的问题中，缺乏行动又容易使模型依靠不可靠的记忆继续回答。

合理安排什么时候分析、什么时候行动，本身就是技术设计的一部分。

这也解释了为什么现代Agent系统有不同的实现方式，而不是所有任务都机械套用同一个ReAct循环。

六、既然ReAct这么有用，为什么企业还需要Workflow？

这里必须回到B205。

我们仔细想想。

会议室被张主任抢走以后，重新查询其他符合条件的房间，真的需要ReAct吗？

不需要。

普通软件完全可以写出这样的规则：

如果预约失败的原因是会议室被占用，就重新查询。

如果查询到其他满足全部条件的房间，就按既定规则选择。

如果没有，则请用户确认是否修改条件。

这是一套明确、可预测的流程。

不论有没有大模型，它都可以运行。

因此，真正有意义的问题不是：

“ReAct能不能处理B205？”

而是：

“什么情况下，提前写好的流程已经不足以决定下一步？”

例如，用户提出更复杂的要求：

这次会议主要是协调项目延期，张主任必须参加，另外几个部门负责人尽量到场。如果大家实在凑不齐，就先安排能拍板的人。会议形式可以灵活一点，但不要影响最终决策。

现在，系统不仅需要查会议室，还需要处理许多不那么明确的条件。

“能拍板的人”是谁？

如果有人只能线上参会，是否仍满足会议目标？

如果某位负责人无法参加，是否应该优先调整时间？

这些判断可以部分依赖企业已有的规则和优化算法，但也可能需要结合邮件、人员职责、组织关系和用户最新要求，动态提出方案。

这时，语言模型参与下一步行动选择，才可能体现更明显的价值。

例如，模型先查询人员日程，发现关键负责人冲突，再进一步查阅会议背景，提出两个备选方案，最后向用户询问需要授权的变更。

在这样的任务中，每一次新信息都可能改变后续行动。

而这些变化不一定都适合提前写成大量固定分支。

不过，ReAct也不会让所有复杂判断自动正确。

模型可能误判谁拥有决策权，可能忽略组织规定，也可能自行提出不合适的安排。

所以，真实系统往往需要把两种能力结合起来。

让模型处理开放式判断。

让规则和业务系统处理明确的硬性约束。

让外部执行程序控制哪些动作能够真正发生。

Workflow可以组织这样的过程，Agent也可以在其中承担动态决策。

两者没有必要互相排斥。

七、ReAct让模型有了行动反馈，但没有替它解决现实世界的所有麻烦

ReAct带来的重要变化，是让模型有机会在执行过程中获得新信息，并据此调整行动。

可是，能够根据观察继续行动，与能够可靠地完成业务，仍有距离。

先看一个简单的例子。

预约B205返回：

SLOT_TAKEN

这表示此次预约因为资源冲突而失败。

模型可以据此重新寻找会议室。

但如果工具返回：

TIMEOUT

事情就不同了。

超时可能意味着业务系统没有收到请求，也可能意味着请求已经成功，只是响应未能及时返回。

如果模型看到TIMEOUT就反复调用预约接口，可能造成重复操作。

解决这种问题，通常需要查询原请求状态、使用服务端支持的幂等机制，或者在结果不明时转交人工处理。

仅仅增加ReAct循环，不能消除这类风险。

再看权限。

模型可能根据会议安排推断：“取消另一间会议室的预约，可以释放资源。”

这并不意味着它拥有取消别人预约的权力。

工具权限和动作边界，应当由执行程序及业务系统控制。

最后，还有一个经常被忽略的问题：

模型认为任务完成了，业务系统是否也认为完成了？

如果模型生成：

“会议室已经帮您预约成功。”

但预约接口实际上只是返回“申请已提交”，那任务并没有达到用户最初希望的结果。

必须继续查看业务系统的真实状态，确认预约是否生效。

这些问题不属于ReAct单独能够解决的范围。

这恰好揭示了现代AI任务执行的一个重要边界。

ReAct可以帮助模型根据反馈调整行动。

但真实系统仍需要可靠的接口、权限机制、异常处理与结果验证。

让模型知道下一步可以做什么，与保证这一步执行正确，是两个不同的技术责任。

八、从2022年的ReAct，再看今天的Agent

现在我们已经可以理解，为什么ReAct会在大模型技术发展过程中受到关注。

此前，大模型主要通过生成文字来展示能力。

用户提出问题，模型生成答案。

即使加入思维链，它仍可能只是在原有上下文中展开分析。

工具让模型可以接触外部信息与系统。

而ReAct进一步展示了，模型可以在任务分析与外部行动之间交替运行，利用工具返回的新信息修正后续行为。

这使得大模型有机会从一次性的问答，参与连续的任务求解。

但ReAct并不是Agent的全部，更不能将今天各种Agent框架简单理解为ReAct改了一个名字。

有的系统先制定整体计划，再分步执行。

有的让模型只负责少数不确定的决策。

有的通过固定Workflow管理整个过程。

还有的系统把不同的模型、搜索算法、工具与业务规则组合起来。

它们都可能借鉴ReAct的思想，却不一定完全按照原论文的方式实现。

2024年，Anthropic在《Building effective agents》中也强调，对于路径明确的任务，应优先考虑简单、可组合的实现方式；需要灵活决策时，再考虑更复杂的Agent系统。

这与ReAct的实验结果并不矛盾。

ReAct告诉我们，语言模型的分析与外部行动能够互相促进。

工程实践则提醒我们，这种能力有成本、有误差，也有适用范围。

对于企业来说，不能只问“这个场景能不能做Agent”。

还要问：

任务中究竟有哪些判断无法提前写死？

这些判断是否需要外部事实支持？

模型参与以后，能否比确定性方法取得更好的效果？

哪些执行结果需要业务系统最终确认？

如果这些问题没有回答清楚，即使给AI连接再多工具，增加再多行动循环，也不代表它就更会办事。

九、机器开始边做边判断，但它真的懂业务吗？

回到故事最初。

张主任抢走了B205。

如果AI只是一次性调用工具，它可能只会告诉我们预约失败。

如果采用ReAct式的方法，它可以利用新的观察，重新判断行动，继续寻找符合目标的会议室。

但我们已经知道，重新预约这件简单的事，并不需要大模型才能处理。

ReAct真正值得关注的，是它提供了一种让语言模型在外部环境中逐步求解任务的方法。

模型不必在最初一次回答中确定全部行动。

它可以利用执行过程中的新信息，对后续行动作出调整。

2022年的研究通过模拟交互任务、网页购物和知识问答等实验，说明了这种方法的潜力，也暴露了重复行动、推理错误和环境信息不充分等问题。

这项研究最值得记住的，不是Thought、Action、Observation三个单词本身。

而是它们之间的联系。

模型分析下一步，行动改变或查询外部环境，环境反馈再影响模型的下一次分析。

这正是ReAct所研究的推理与行动协同。

不过，这离真正的专业工作还有一步距离。

假如用户让AI审核一份招标文件。

它能够读取文件。

能够查询制度。

能够调用工具。

遇到问题，也能够继续查找资料。

可经验丰富的审核人员，往往知道哪些条款最容易出风险，哪些条件需要跨文件核对，哪些错误会导致投标被否决。

这些判断并不会因为AI具备ReAct式行动循环，就自动出现在它的工作过程中。

会根据反馈决定下一步，不等于知道专业人员应该怎样做。

如果把专家的工作方法、检查步骤、参考资料和质量要求封装起来，能不能让AI更加稳定地完成专业任务？

这又涉及另一项技术。

下一回，我们继续研究。

把经验写成Skill，AI就真的学会了吗？