一轮 ReAct Loop 到底发生什么
一句话收获：模型提出下一步，控制器决定是否合法、是否执行以及是否继续。
这个场景在解决什么问题
这个场景讲的是 ReAct Loop（"推理 + 行动"循环）里，一轮循环内部到底发生了什么。目标（goal）是实现五样东西：Observation（观测）、行动候选、Harness 决定、工具结果、停止检查。观察点（observation）很关键：只逐步播放"一轮循环"，不展示模型内部的思维链（chain-of-thought）。
为什么值得单独学？因为很多人以为"Agent 就是模型自己干活"，其实错了——模型只负责"提建议"，真正决定"能不能执行、要不要继续"的是一个叫控制器的东西。这个场景告诉你：模型提下一步，控制器（Harness）决定三件事：合不合法、执不执行、继不继续。
先理清这条判断链（文字版）
这个场景的四步是一轮循环的完整转动，本质是"观测 → 提候选 → 校验执行 → 检查出口"：
- 先形成 Observation——控制器读取任务状态、业务状态、知识依据和最近工具结果，拼成"当前事实快照"。
- 让模型基于这个观测，提出"行动候选"——可能是解释、工具候选或完成候选。
- 由 Harness 校验（白名单、参数、对象、权限、状态）通过后，才真正调用工具。
- 最后检查进展与出口——比较状态变化、预算、重复动作、完成证据，决定要不要继续下一轮。
这条链的核心逻辑是：模型只负责"想和提议"，控制器负责"把关和执行"，两者分开。
逐层详解
第 1 步：形成 Observation
原文：控制器读取任务状态、业务状态、知识依据和最近工具结果。
白话：每轮循环开始，控制器先"看现场"——读取四样东西：任务状态（跑到哪了）、业务状态（外部现实是什么）、知识依据（凭什么这么判断）、最近工具结果（上一步做了啥）。这些拼成一次"观测"（Observation）。
类比：像司机每个路口先扫一眼——车速（任务状态）、路况（业务状态）、导航提示（知识依据）、刚过的那个路口结果（最近工具结果），然后才决定下一步怎么开。
举例：一个 Agent 要"给订单退款"，这一轮开始控制器读：任务状态"第 2 轮、等待退款结果"、业务状态"订单当前是已支付"、知识依据"退款规则要求先查支付渠道"、最近工具结果"上一步查询返回了支付渠道是微信"。
为什么重要：每轮判断基于当前可观察事实。也就是说，每一轮都要基于"当下能观察到的事实"来做判断，而不是基于旧记忆或旧对话。
怎么验证（证据点）：
- 状态当前：读到的状态是当前的。
- 证据完整：知识依据和工具结果齐全。
- 预算可用：还剩可用预算。
别踩的坑（边界）：Observation 不等于完整历史。意思是，观测只是"当前快照"，不是把整个历史都搬进来——它是有选择的。
落地检查：只装载影响下一步的信息。也就是说，落地时观测里只放"会影响下一步"的信息，别把无关历史全塞进来。
第 2 步：模型提出行动候选
原文：模型返回解释、工具候选或完成候选。
白话：模型拿到观测后，返回"下一步建议"，可能是三类之一：解释（说说当前看法）、工具候选（建议调某个工具）、完成候选（建议"我做完了"）。这三类会走向完全不同的后续路径。
类比：像开会讨论，员工发言可能是三类——"我解释一下现状"、"我建议去联系某人"、"我认为这事可以结案了"，主持人会按不同类型分别处理。
举例：模型基于观测返回一个工具候选 {tool: refund, args: {order_id: 123}}，标记为"未执行"。如果模型返回"完成候选"，则进入独立的验收流程，而不是直接更新状态。
为什么重要：三类输出进入不同后续路径。也就是说，解释、工具候选、完成候选要分流处理，不能混在一起——尤其"完成候选"要走独立验收。
怎么验证（证据点）：
- 候选类型明确：能分清是解释/工具/完成哪一类。
- 参数候选：工具候选的参数作为候选存在。
- 尚未执行：候选还没被真正执行。
别踩的坑（边界）：模型说完成不能更新正式状态。意思是，模型返回"完成候选"，不等于任务真的完成了——不能因此就更新正式状态。
落地检查：完成候选进入独立验收。也就是说，落地时"完成候选"必须走一条独立的验收流程去确认，而不是模型说了算。
第 3 步：Harness 校验并执行
原文：白名单、参数、对象、权限和状态通过后才调用工具。
白话：模型提出工具候选后，不是直接执行，而是由 Harness（执行控制器）做层层校验：工具在不在白名单、参数合不合法、对象存不存在、有没有权限、状态允不允许。全通过了，才真正调用工具。
类比：像财务审批——员工提交付款申请（工具候选），要过"是否在授权清单、金额对不对、收款方真实吗、权限够不够、当前流程状态允不允许"层层审批，全过了财务才真的打款。
举例：模型建议调 refund 工具，Harness 先查 refund 是否在白名单、order_id 参数是否合法、订单对象是否存在、当前账号有无退款权限、订单状态是否允许退款，全部通过后才调用，拿到工具回执并更新状态。
为什么重要：模型外机制控制真实副作用。也就是说，真实世界里的副作用（退款、发消息等）由模型之外的 Harness 来控制，不能让模型直接触发。
怎么验证（证据点）：
- 策略通过：白名单/权限等策略校验通过。
- 工具回执：拿到了工具执行的回执。
- 状态更新：任务/业务状态随之更新。
别踩的坑（边界）：工具成功不证明整个任务完成。意思是，一次工具调用成功了，不代表整个任务就完成了——可能还有后续步骤。
落地检查：结果进入下一轮 Observation。也就是说，落地时工具执行的结果要回流到下一轮的 Observation，作为新的判断依据。
第 4 步：检查进展与出口
原文：控制器比较状态变化、预算、重复动作和完成证据。
白话：工具执行完后，控制器做"是否继续"的检查：状态有没有变化（有进展吗）、预算够不够（还能跑几轮）、有没有重复动作（是不是在兜圈子）、有没有完成证据（能不能结案）。据此决定继续还是退出。
类比：像打游戏每回合结束的"战况评估"——血条涨了没、还有没有蓝、是不是在原地打转、BOSS 到底死了没，决定是继续打还是撤退。
举例：这轮退款工具返回"成功、订单已退款"，控制器看到状态从"已支付"变成"已退款"（有新证据），判断任务完成，触发完成验收出口；如果状态没变、又在重复调用同一个工具，则可能触发停止。
为什么重要：Loop 每轮都要判断继续是否仍合理。也就是说，循环不能无脑转，每轮都要停下来问一句"继续还值不值得"，防止空转。
怎么验证（证据点）：
- 有新证据：状态出现了新的变化/证据。
- 预算足够：还剩足够预算。
- 出口未触发：还没有触发停止/完成等出口。
别踩的坑（边界）：轮次未用完不代表必须继续。意思是，预算还有剩余，不代表就一定要继续跑——没有进展时该停就停。
落地检查：进展和风险决定下一步。也就是说，落地时下一步由"有没有进展 + 风险多大"共同决定，而不是"还能不能跑"。
落地可行性小结
本场景涉及的技术栈和落地要点：ReAct Loop（推理行动循环）、Observation（观测）、行动候选、Harness（执行控制器）、白名单、工具回执、停止检查、思维链（chain-of-thought，不展示）。
真实落地时要注意：Observation 要"有选择地"装载当前事实，而不是全量历史；模型的三类输出（解释/工具候选/完成候选）要分流处理；工具执行必须经过 Harness 的白名单、参数、对象、权限、状态五重校验；每轮结束要做进展与出口检查。常见坑是：让模型直接触发真实副作用（跳过 Harness）；以及把"模型说完成"当成"任务真完成"，漏掉独立验收。
回顾
- 一轮 ReAct Loop 是"观测 → 提候选 → 校验执行 → 检查出口"。
- 模型只负责提下一步，控制器负责决定合法、执行、继续。
- Observation 是当前事实快照，不等于完整历史。
- 工具执行必须过 Harness 的白名单、参数、对象、权限、状态校验。
- 每轮都要检查进展和出口，预算没用完不代表必须继续。