ReAct 轨迹逐行拆解：从 Thought/Action/Observation 到 tool_call_id

先亮对象：一条 ReAct 原始格式的六行轨迹，问的是加纳的首都。它出自 ReAct: Synergizing Reasoning and Acting in Language Models（Yao 等，Princeton 与 Google Brain，ICLR 2023）。

本篇逐行拆这条轨迹，一次看清三件事：论文思想怎么落进今天的消息列表，harness 在中间干了什么活，轨迹上哪几行决定成败。

一、轨迹原件：Thought / Action / Observation 三件套

ReAct 的核心主张一句话讲完：让模型交替生成推理痕迹（Thought）与面向任务的动作（Action），再把环境返回的观测（Observation）接回上下文。推理指导行动，行动为推理取证。

关键的机制细节是：推理痕迹不会用完即弃，它留在上下文里，持续引导后续的工具调用。第一步想的是为什么检索。到了第三步，问题变成证据够不够、要不要换打法，第一步的思考仍在发挥作用。

整条轨迹就是决策依据本身。也正因为只是文本格式 + 循环，小模型靠 few-shot 示范就能超越当时的大模型。几乎所有现代 agent loop 都是它的思想后代。

用课程的例子跑一遍（slides L2 p.8-11），问的是加纳的首都：

最后一行最容易被忽略：finish (text) 是 harness 控制的调用，不是外部程序。模型显式发出它，循环才终止，harness 用其中的文本向用户归纳（slides L2 p.8-11）。

同一组幻灯片给出五类接口的光谱，finish 之外：

• search_web(‘site:cmu.edu 今日公告’)，取新鲜证据。
• execute_code (‘sum ([18,23,41,54])/4’)，做精确计算。
• generate_image (query)，产出图像。
• create_grocery_cart (items) 是真正的外部动作，购物车返回 ‘Cart C17・3 items・$31.42’。

二、词元层：text continuation 与 tool continuation

在 ReAct 的年代，上面整条轨迹是塞进一条提示词里的文本续写。今天的 API 把它拆成带角色的消息，但拼装逻辑没变（slides L2 p.18-25）。

请求中的 system/user/assistant 消息经 chat template 串成单条模型输入，Qwen 用 <|im_start|> 序列分隔消息，工具清单也随请求注入：

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "parameters": {
          "type": "object",
          "properties": {
            "location": { "type": "string" },
            "units": { "enum": ["C", "F"] }
          }
        }
      }
    }
  ]
}

到了该行动的时刻，模型有两个续写方向：text continuation 接着说话，tool continuation 吐出结构化调用：

<tool_call>{"name": "get_weather", "arguments": {"location": "上海", "units": "F"}}</tool_call>

API 层解析这段输出并附上唯一 call ID。执行结果不写进 assistant 消息，而是按 tool_call_id 回填一条 role 为 tool 的新消息。

一轮并行发出多个调用时，同样靠 ID 一一配对，谁也不会认错观测。

你以为自己在传消息列表，模型实际看到的仍是 chat template 拼出来的一条长文本。ReAct 时代的整段轨迹输入，和今天的 messages 数组，在词元层面是同一种东西，只是切分与角色标注变成了 API 的合同。

把两个时代放进同一张图：

三、harness 两阶段：轨迹背后的调度机

轨迹的每一步背后都有 harness 在调度。OpenHands 的 dispatch（官方 references，源码级）把这件事拆成两阶段：

初始化时，工具注册成一张表：名字 → schema + 动作 + 执行器。模型每次输出 tool_call，harness 先解析、再查表、再按 schema 校验参数，最后交给 executor，观测打包成带 call_id 的事件回填。首尾相接，就是完整的循环：

四、决断点：同一份观测，两种命运

轨迹的质量取决于几个关键行怎么写。文采无关。

另外两个高频决断点。检索返回 0 条结果时，该换 query 重搜，不该原样重发；工具报错时，把错误消息原样回灌往往是最优解，模型能自纠：

三个决断点位置不同，都发生在观测之后的那一行。Observation 回填之后，模型显式收尾、换个打法，还是无视报错原样重发，基本决定了这条轨迹收敛得好不好，会不会一路空转到 max_turns。

与本讲的连接

本篇是讲次页「ReAct：推理与行动的交替」一节的下钻。几处线索在本文里各有落点：

• 伴读的范式三级跳（prompt 示范 → Toolformer 自监督 → 原生 function calling），中段对应本文第一节，现代段对应第二节。
• 概念卡里的 harness 与 Function Calling 两条，落到地上就是第三阶段的 tools_map 与 tools 注入。
• 实践视角那句「工具描述是给模型看的 UI」，机制版就是 tools 清单里的 JSON Schema 与报错回灌。

做完讲次页 quiz 里「ReAct 循环的核心结构」一题，再回看第一个 trace 块。六个前缀本身就是答案。