ReAct推理行动交替的Prompt模板设计

可视化演示

展示ReAct模式中Thought-Action-Observation循环机制，Prompt模板设计流程，以及AutoGPT/BabyAGI框架应用，通过流动粒子直观理解推理与行动交替的核心思想。

ReAct原理：边想边做才能破案

老刑警语重心长地告诉你：破案最忌讳两件事——“闭门造车”和“无头乱撞”。只推理不行动，你会被自己的想象带偏，对着错误的方向编出整套故事；只行动不推理，你会在现场跑来跑去，却不知道每一条线索意味着什么。真正的高手，是在笔记本上写下一句有依据的推测，然后立刻出门验证它，回来把看到的结果记下来，再根据结果写下一句推测。

ReAct 论文（Reasoning + Acting）正是把这种“边想边做”写进了大模型的行为模式。它要求模型每一步的输出都包含三个部分：Thought（推理笔记）、Action（行动指令）、Observation（观察结果）。模型不再一口气吐完整个答案，而是与环境交替互动，用真实的工具反馈来校准自己的推理。这条完整的交替轨迹，就是 Agent 的“办案记录”：

这个设计最直接的收益是解决幻觉问题。纯 CoT（Chain-of-Thought）让模型一路推理到底，如果中途某个前提是错的，后面全是空中楼阁；而 ReAct 每推一步就用工具反馈验证一步，就像侦探每次猜测都有目击证人或物证兜底。现在各大 Agent 框架的底层逻辑，几乎都是这条轨迹的变体。

模板结构：一本三栏式的办案记录表

你翻开老刑警的笔记本，每一页都印着整齐的三栏表格：第一栏写想法，第二栏写动作，第三栏写结果。他告诉你，这表格不是随便画的——栏目的顺序就是思维的顺序，每一行都是一次完整的“想-做-看”循环。Prompt 模板的作用，就是给大模型也发一本这样的空白记录表，并告诉它每栏该写什么、按什么顺序写。

一份标准的 ReAct Prompt 模板由三个段落组成。系统段负责定义角色和格式规则，比如“你是一个会用工具的助手，必须按 Thought/Action/Observation 的格式输出”；任务段把用户的问题注入到模板里，相当于在表格抬头写下案件名称；循环段最关键，它把模型过去所有的 Thought、Action、Observation 拼接成历史上下文，让模型在每一轮都能看到自己之前的办案记录。

模型在每一轮看到的上下文，可以用一个简单的式子表达：

理解了循环段的拼接逻辑，你就知道模板设计的一条铁律：每一轮的 Action 必须以“可被下一轮观察”的方式结束。如果 Action 写得含糊，工具无法执行，Observation 就无从产生，整条链就断了。这也是为什么三个栏目的设计必须环环相扣。

Thought提示词：写好侦探的推理笔记

老刑警给你看了他的笔记示范：“昨晚死者手机最后一条消息是发给妻子的，但妻子说手机当晚不在身边——这两条口供矛盾，所以我下一步要查手机信号的基站记录。”注意，他没有写“我觉得很奇怪”这种废话，而是写了已知事实（两条口供矛盾）和行动动机（所以要查基站）。Thought 的设计，就是训练模型写出这样有用的笔记。

在 Prompt 模板里，Thought 部分通常用一两句指令来约束。效果拔群的写法是这样的：

这套提示词背后的设计智慧有四点。表达思考动机：要求模型说明“为什么这一步值得做”，避免随机行动；引用事实依据：强制模型把 Thought 挂在 Observation 的事实上，而不是凭空捏造；控制推理节奏：要求“先复述再行动”，让推理步骤短而密，每步只推进一点点；避免空想：明确禁止无关联想，把模型从“脑内小剧场”拉回案件本身。

Template 里 Thought 设计得越克制，模型就越不会“自言自语”。很多初版模板失败，都是因为 Thought 指令写得太开放，模型吐出一大段感慨，却不指向任何一个具体动作——就像侦探在笔记本上写了一整页“人心难测”，却没有写下要去查哪个证人。记住：Thought 的唯一使命，是为下一行的 Action 提供理由。

Thought: 基于上一条 Observation，先复述你掌握的关键事实，再说明你打算做什么、为什么这么做。不要重复已知信息，不要展开无关联想。

Action提示词：发出标准化行动指令

老刑警又翻开本子，指着“动作”一栏：上面永远写着格式化的命令，比如“调取监控：昨晚 9 点到 10 点，案发街道东侧摄像头”，而不是“我去看看有啥线索”。标准化的好处是，任何人都能立刻执行，执行结果也能准确对应到这一条动作上。Action 的设计，就是让模型的行动命令像警用调度单一样规范。

Prompt 模板对 Action 的格式必须做硬性规定，常见的写法是：

工具名必须来自本模板声明的工具清单，参数必须按该工具的规范填写。比如 Action: calculator[15 * 23]，而不是 Action: 帮我算一下。这里还有三条设计要点：单动作聚焦——每一轮只允许输出一个动作，不能同时调两个工具，否则 Observation 无法判断结果对应哪个动作；参数格式规范——模板里要给每个工具的参数示例，就像给新手侦探展示“证物袋标签怎么填”；终止条件判断——模板必须声明一个特殊动作 Action: Finish[最终答案]，模型一旦确认答案就调用它结束循环，否则 Agent 会永远查下去。

模型如何决定选哪个动作？从数学上看，每一轮的动作都是在一个条件概率分布中采样得到的：

在设计模板时，你可以让这个“动作概率”变得更稳：把工具清单和每个工具的示例写清楚，模型选择正确工具的概率就会显著上升。不少工程师把模板里的工具说明写得像说明书一样详尽，效果反而好过放手让模型自由发挥——因为标准化的指令减少了歧义，也就减少了采样时的摇摆。

Action: 工具名[参数]

Observation反馈：把卷宗读成线索

侦探查案最耗时的一步，是坐在档案室里翻卷宗。卷宗里堆满了冗长的证词、监控截图、法医报告的原始文本，老刑警的做法是：只把与当前问题相关的两三句话摘出来，抄到记录表第三栏，其余的翻过不记。Observation 的设计正是这个“摘抄”动作——不要让模型把工具返回的一大段原文都吞进去，而是把关键信息提炼成下一轮可用的线索。

模板里可以这样引导模型处理 Observation：

这段指令涵盖了三个关键设计。结果摘要改写：模板告诉模型“只引用相关事实”，避免模型被无效信息带偏；错误信息容错：工具报错不等于任务失败，模板把报错包装成“此路不通”的线索，让模型有机会换一条路；观察驱动决策：Observation 永远排在下一轮 Thought 之前，让决策严格建立在事实基础上。如果信息缺失，模板还应引导模型发起补查，比如“结果不完整时，请再次调用工具获取缺失字段”。

一个常见的模板缺陷，是 Observation 环节没有任何说明，导致模型面对工具报错时直接崩溃或重复同一个失败的 Action。好的 Observation 设计，让 Agent 拥有“从失败中学习”的能力——就像侦探发现一条线索断了，会平静地在第三栏写下“此路不通”，然后翻到下一页继续写新的推测。这种容错能力，正是 ReAct Agent 比一次生成式回答稳健得多的重要原因。

Observation: （系统自动填入工具返回结果）你的任务：阅读上面的原始结果，在下一轮 Thought 中只引用与当前目标相关的事实。若结果报错，把错误信息视为"此路不通"的信号，换个工具或换个方向继续。

完整模板实战：一张能直接上手的记录表

前面四节拆开了讲，现在把它们拼成一张能直接使用的完整模板。以单工具（计算器）为例，一份最小可用的 ReAct Prompt 长这样：

模板的最后一个词是“Thought:“，这是给模型的起手式——告诉它从思考开始，而不是直接输出答案。任务注入方式就是替换 {用户问题} 这个占位符，系统段和循环段的格式保持不变。多工具模板在此基础上扩展：在系统段声明工具清单，并给每个工具配一行使用说明和参数示例，Action 的”工具名”一栏就只能在清单里选。

设计多工具模板时要注意“选择路径”的清晰度。比如同时有 web_search 和 calculator，模板里应写明“需要事实信息用 web_search，需要数值计算用 calculator”。这样模型在 Action 一步就不容易选错工具。整套模板最终形成这样的效果：Thought 决定方向，Action 执行动作，Observation 反馈结果，周而复始，直到出现 Finish。

模板拼好后，你可以先用一两个小任务做冒烟测试。若模型频繁输出非法格式，就在系统段加一句“不允许输出任何除上述格式以外的内容”，或用 Few-shot 示例把正确格式演示一遍。记住：模板是给模型看的“行为规范”，措辞越像规章条例，模型的输出就越守规矩。

你是一个擅长数学计算的助手，只能使用计算器工具。每轮必须严格按以下格式输出： Thought: 你的推理笔记（引用已知事实，说明下一步动机）Action: calculator[表达式] 表达式必须是四则运算式，例如 calculator[15 * 23]。系统会返回结果，你在下一轮继续输出 Thought。当你已经得到最终答案时，输出： Thought: 我已得到最终答案Action: Finish[答案] Question: {用户问题}Thought:

自主Agent应用：无人值守的侦探团队

老刑警办案时，助手会替他跑腿、查档案、整理线索；而 AutoGPT 这样的自主 Agent，等于把“侦探 + 助手”全交给了大模型——给它一个目标，它自己拆解、自己执行、自己验证。这套机制的内核正是 ReAct 模板，只是把它放进了循环：模型生成的 Action 不是一句话，而是真实的函数调用、文件读写、网络请求，Observation 是这些操作的真实返回。

AutoGPT 的循环里，Thought 升级成了“自我任务规划”：模型每完成一步，会问自己“离目标还差什么、下一步该做什么”，然后把子任务排进队列。BabyAGI 则把 ReAct 模板和任务队列管理结合得更明确：先有一个大目标，Agent 把它拆成若干子任务，逐个执行，每完成一个子任务，就根据它的结果生成新的子任务。新任务不是凭空冒出来的，而是对已完成任务及其结果的函数：

这套自主循环有一个必须提防的隐患：失控。如果任务永远能生成新任务，Agent 就会陷入无限循环烧光 token。所以工程上一定要给 Agent 套上“受限执行环境”：限制最大步数（比如最多 20 轮）、要求每个子任务必须声明验收标准、把生成新任务的动作也做成一个受限的 Action。这些约束写进模板，等于给侦探团队定了一条铁律——破不了案也得回来汇报，不许在外面无限查下去。

模板调优：让记录表越用越顺手

老刑警的笔记本不是印出来就完事的，他会根据每次失败的案子在表格旁添批注：“下次记得查不在场证明”“这条街的监控要写清编号”。ReAct 模板同样需要迭代调优。第一阶段是建立评测指标：任务成功率（Agent 是否在限制步数内给出正确答案）、工具调用准确率（Action 选对工具且参数合法）、平均步数（效率如何）。没有这三项数字，优化就是盲人摸象。

第二阶段是分析错误类型，常见的有四类：幻觉工具名——模型调用了一个不存在的工具，说明工具清单不够醒目或示例不足；参数格式错——工具选对了但参数写错，说明参数示例不够具体；重复循环——模型反复执行同一个失败的 Action，说明 Observation 没有引导它从错误中学习；提前终止——模型过早输出 Finish，说明终止条件写得太宽松。每一种错误都对应一个模板修改动作。

调优的具体手段包括：加 Few-shot 示例（把一次成功的完整轨迹贴进模板当示范）；强化格式约束（用“必须”“禁止”等强指令收窄输出空间）；精简冗余措辞（模板越长，模型越容易忽略关键指令）；以及采样参数——把温度调到 0 附近，让输出更确定、更守格式，等基础跑通后再逐步升温提升灵活性。每一次修改后重新跑评测集，用数字说话，而不是凭感觉。

模板调优的本质，是让模型的“行为规范”越来越贴合真实任务。就像老刑警的笔记本越写越厚、批注越来越多，最终成为一本破案宝典。你的 ReAct 模板也是一样：它是活的文档，会随着你在真实 Agent 任务中的每一次踩坑而进化，最终成为团队里最高效的“推理-行动”引擎。

AI 应用场景

Python 演示

import re class ReActAgent:    def __init__(self):        self.tools = {            "calculator": lambda expr: str(eval(expr)),            "get_weather": lambda city: "晴,25度" if city == "北京" else "多云,22度"        }        self.trajectory = []     def think(self, obs):        if obs is None:            return "需要数值计算,先调用计算器工具"        if "345" in obs:            return "得到最终答案 345,不需要再行动"        return "观察未达预期,继续推理"     def act(self, thought):        if "天气" in thought:            return "get_weather", "北京"        return "calculator", "15 * 23"     def observe(self, tool, arg):        return self.tools[tool](arg)     def run(self, max_steps=3):        obs = None        for i in range(max_steps):            thought = self.think(obs)            print("Thought {}: {}".format(i + 1, thought))            if "最终答案" in thought:                print("Answer: {}".format(thought))                return            tool, arg = self.act(thought)            print("Action {}: {}({})".format(i + 1, tool, arg))            obs = self.observe(tool, arg)            print("Observation {}: {}".format(i + 1, obs))            self.trajectory.append((thought, tool, arg, obs))        print("达到最大步数,停止") if __name__ == "__main__":    ReActAgent().run()

1. self.tools = {...}注册工具清单，对应模板里 Action 的可选工具范围，是“Action: 工具名[参数]”的合法集合。
2. def think(self, obs):生成 Thought 的核心函数，根据上轮 Observation 决定下一步推理，对应模板中的 Thought 指令。
3. if "345" in obs:Observation 驱动终止判断，工具返回结果满足条件时，Thought 转向收尾，不再发起新行动。
4. def act(self, thought):从思考内容里解析出工具和参数，对应模板要求的结构化 Action 输出。
5. obs = self.observe(tool, arg)真正执行工具并拿到返回结果，这一行完成后，循环回到 think，形成闭环。
6. self.trajectory.append((thought, tool, arg, obs))把每轮三元组追加进历史，对应模板循环段拼接上下文的设计。
7. if __name__ == "__main__":可执行入口，保证脚本能直接运行演示完整的 ReAct 循环。

常见误区

面试题