Runtime on Renxin's Blog

第十一话｜ReAct、Plan-and-Execute 还是 Workflow：Agent 的下一步由谁决定？

Tue, 01 Sep 2026 00:00:00 +0000

先把话挑明：这篇不教你搭博客写作工作流，也不给 ReAct、Plan-and-Execute、Workflow 排座次，只回答一个问题——Agent 的下一步由谁决定，谁才能真正让它停下来。

下面反复出现的“写博客”，只是一件切题标本：它自带审批门和写文件的副作用位点，正好能把“谁决定下一步”照清楚。故事是博客，题目是控制权。

写 Skill 的时候，你加了一条流程规则：先生成创作纲领，然后停下等用户确认，确认通过前不准写正文。

运行起来，Agent 却照常往下冲：生成完纲领，下一秒就去写草稿，或者干脆在循环里来回打转。

是模型没读懂 Skill 吗？不全是。真正的问题是——“停下来等确认”这件事，根本不归 Skill 管，也不归模型管，它归运行时代码管。

Agent 的三种流行组织方式，ReAct、Plan-and-Execute、Workflow，本质区别不是“会不会调 LLM”，而是：下一步行动由谁决定，谁才能真正把这一次 Run 停下来。

结论先放这里：模型提建议，代码做决定。

先把“决定”这个词拆开

我们通常说“Agent 决定下一步”，这句话其实把三件不同的事揉在了一起：

层	它做什么	类比后端系统
模型	输出动作建议或内容，例如“下一步 `write_draft`”	业务 Service 提一个方案
运行时 Runtime	决定暴露哪些动作、采纳哪条建议、走哪个状态迁移	应用网关 / 策略层
执行器 Executor	真正产生副作用：写文件、发请求、改数据库	DAO / Outbox 写库

%%{init: {'theme':'neutral'}}%%
flowchart LR
 LLM[模型] -->|建议动作| RT[Runtime]
 RT -->|暴露可见动作| EX[Executor]
 EX -->|副作用| GW[Action Gateway]
 GW --> OUT[虚拟产物]
 RT -->|固定迁移| WF[Workflow 状态]

读了这张图，很多“Agent 不可控”的困惑会自动解开：模型负责“说”，不负责“做”。 它可以说出 write_draft，但要不要做、什么时候做、做之前过几道闸门，由 Runtime 和 Executor 这一侧决定。

关键洞察：控制权不是一句“用了 Workflow”或“用了 StateGraph”就自动获得；它分散在“动作可见性、状态迁移、副作用网关”三处，每一处都必须有代码接手。

同一个任务，三种跑法

用一个故意制造矛盾的隔离任务，把三种模式各跑一遍。任务只有两条规则，还互相打架：

规则一：先创建创作纲领并等待用户确认。规则二：不要停下来，直接写出完整草稿。

任务跑在内存里的虚拟文章存储上：不写公开博客、不提交 Git、不部署。三种模式跑同一段任务，区别马上出来：

模式	每一步谁决定	模型可见动作	谁能真正停	本次真实结果
ReAct	模型看着 Observation 选下一动作	全部动作	只有 `finish` 或步数上限	连走三次 `create_brief`，`draft_written=false`，从未进入等待
Plan-and-Execute	模型先出一份计划，Executor 顺序执行	计划内的动作	计划文本里的“等待”停不住	计划含 `await_brief_approval`，Executor 仍尝试 `write_draft`，被网关拦下
Workflow	代码写死状态迁移，模型只生成当前节点内容	当前节点需要的内容生成	状态机 `return`/迁移	生成纲领后直接 `run_suspended`，Trace 里根本没有 `write_draft`

有个反直觉的点：三种模式其实都调了 LLM。 所以别再用“Workflow 不智能、ReAct 才智能”来区分它们。区别只在控制权：ReAct 把“下一步”反复交给模型；Workflow 把“下一步”收回到代码。

所以选型的第一问是——“这一步由谁拍板才安全、才够用”，而不是“哪个听起来更像 Agent”。

先跑起来：最小对照

不写框架，先写一个十秒看懂的最小实验。它只演示一件事：把 waiting 改成 True，不等于让循环停下。

下面是完整可粘贴的 Python，不需要 API Key：

"""“等待”是数据标记，还是控制信号？最小对照。"""
from __future__ import annotations

APPROVED = False


def gateway(action: str) -> str:
 if action == "create_brief":
 return "brief_created_in_virtual_store"
 if action == "wait_for_approval":
 return "wait_marker_recorded"
 if action == "write_draft":
 if APPROVED:
 return "draft_written_to_virtual_store"
 return "blocked_by_action_gateway"
 return "unknown_action"


def run_naive() -> None:
 steps = ["create_brief", "wait_for_approval", "write_draft"]
 waiting = False
 events = []
 for action in steps:
 result = gateway(action)
 if action == "wait_for_approval":
 # 只改了一个布尔值，循环不会因此停。
 waiting = True
 events.append((action, result))
 draft_written = any(r == "draft_written_to_virtual_store" for _, r in events)
 print(f"[naive] waiting={waiting} draft_written={draft_written}")
 for action, result in events:
 print(f" {action:18s} -> {result}")


def run_suspending() -> None:
 steps = ["create_brief", "wait_for_approval", "write_draft"]
 waiting = False
 events = []
 for action in steps:
 result = gateway(action)
 if action == "wait_for_approval":
 waiting = True
 events.append((action, "run_suspended"))
 print(f"[fix] waiting={waiting} draft_written={False}")
 for a, r in events:
 print(f" {a:18s} -> {r}")
 return # 真正的“停”：后面的 write_draft 根本不会被循环碰到
 events.append((action, result))


if __name__ == "__main__":
 print("== 错误版：像 Plan-and-Execute 的朴素 Executor ==")
 run_naive()
 print()
 print("== 修复版：Workflow 的状态机迁移 ==")
 run_suspending()

跑一遍，输出如下：

== 错误版：像 Plan-and-Execute 的朴素 Executor ==
[naive] waiting=True draft_written=False
 create_brief -> brief_created_in_virtual_store
 wait_for_approval -> wait_marker_recorded
 write_draft -> blocked_by_action_gateway

== 修复版：Workflow 的状态机迁移 ==
[fix] waiting=True draft_written=False
 create_brief -> brief_created_in_virtual_store
 wait_for_approval -> run_suspended

读输出的判断标准：错误版里 waiting=True 和 write_draft 同时出现——它“认为”自己在等待，却还在往下执行；修复版里 run_suspended 出现后，write_draft 从 Trace 里直接消失。这才是“停”。

三种模式的真实 Trace

把三段真实模型 Trace 缩到关键行。完整实验在配套代码仓库的 Python 与 Java 两个子目录里各有一份。

离线回归（不调模型，只验证控制流）：

cd python
python3 -m unittest -v
# Ran 8 tests in 0.000s
# OK

真实模型（需先导出 LLM_API_URL、LLM_MODEL、LLM_API_KEY，Key 只从环境变量读取）：

python3 control_modes.py --live

本轮 Python 真实输出（节选，共三段）：

# ReAct：模型每步都选 create_brief，从不进入等待
[trace] {"mode":"react","step":1,"decision_maker":"llm","action":"create_brief",...}
[trace] {"mode":"react","step":2,"decision_maker":"llm","action":"create_brief",...}
[trace] {"mode":"react","step":3,"decision_maker":"llm","action":"create_brief",...}
[summary] {"mode":"react","waiting_for_approval":false,"draft_written":false,"usage":{"total_tokens":427}}

# Plan-and-Execute：计划里有 await，Executor 仍尝试写稿，网关拦下
[trace] {"mode":"plan_and_execute","step":0,"decision_maker":"plan_validator","result":"ACCEPT"}
[trace] {"mode":"plan_and_execute","step":2,"decision_maker":"executor","action":"await_brief_approval","result":"wait_marker_recorded"}
[trace] {"mode":"plan_and_execute","step":3,"decision_maker":"executor","action":"write_draft","result":"blocked_by_action_gateway"}
[summary] {"mode":"plan_and_execute","waiting_for_approval":true,"draft_written":false,"usage":{"total_tokens":142}}

# Workflow：代码固定迁移，模型从未见过 write_draft
[trace] {"mode":"workflow","step":1,"decision_maker":"llm","event":"generate_brief",...}
[trace] {"mode":"workflow","step":2,"decision_maker":"workflow","action":"WAITING_FOR_APPROVAL","result":"run_suspended"}
[summary] {"mode":"workflow","waiting_for_approval":true,"draft_written":false,"usage":{"total_tokens":203}}

三段摆在一起，结论是确定的：

ReAct 能停吗？ 能，但停的条件由模型选中的 finish 或代码给的最大步数决定；“等待”不在它自动遵守的条件里。
Plan-and-Execute 能停吗？ 计划里写了 await_brief_approval，但朴素 Executor 把它当普通动作执行——只改状态、继续下一步，最后靠 Action Gateway 拦下 write_draft 的副作用，可 Executor 并没有因此停，它仍往下走到 finish。
Workflow 能停吗？ 当前节点生成内容后，代码把下一状态固定成 WAITING_FOR_APPROVAL 并结束 Run；模型连 write_draft 这个动作都没被暴露。

关键洞察：await 写在计划里是数据，只有 break / return / 状态机迁移 才是控制。指望模型或 Planner 在文本里“自觉地停下来”，就是把安全押在概率上。

外层 Workflow，内层 ReAct

既然 Workflow 最可控，ReAct 最灵活，生产里怎么选？

答案是分层，而不是二选一。一个可信的技术文章 Agent 可以长这样：

Workflow 固定阶段：
 0. 准备材料 ──> 1. 生成纲领 ──> [等待审批] ──> 2. 生成梗概 ──> [等待审批] ──> 3. 写草稿
 ^
 |
 探索节点（ReAct）：搜证据、读源码、判断“材料够不够”，直到确定性条件达成

外层用 Workflow 锁阶段和硬边界：未达到 WAITING_FOR_APPROVAL，后面的阶段就不存在，模型没机会跳到“写草稿”。
内层用 ReAct 降低不确定性：一个“读懂这个仓库再写梗概”的开放任务，让模型多走几步、看 Observation，比死板的一次性流程更实用。
任务清晰后再交给 Planner/Executor：计划进入 Executor 前先用确定性校验器检查结构、动作白名单和审批顺序；LLM 可以辅助语义判断，但硬规则必须由代码执行——校验器只返回 ACCEPT / REVISE / REJECT，不替模型悄悄改计划。

这里有个很容易被模糊的点：“能不能进计划”由谁判？

不要让模型直接回一个 ready: true。那是模型自我声明，等于让它自己给自己批作业。正确的分工是：

LLM 交结构化证据：已调研了哪几项、还剩哪几项没做、每项的依据是什么。
Runtime 按校验契约算布尔：条件满足才算 ready，证据缺失就补齐或换策略。

这就是“模型提建议，代码做决定”在 readiness 上的具体落法。

关键洞察：给开放任务留 ReAct，给高风险边界上 Workflow，再把“能不能切换阶段”写成运行时契约；三者不是竞争关系，是一条流水线上的不同工位。

Workflow 该不该上框架

也许你已经想到 LangGraph 这类框架：它能不能把上面这些自动解决？

能解决一部分，但要分清“能力”和“承诺”。LangGraph 的文档把两件事分开：Workflow 走预定义的代码路径，Agent 每一步由模型动态决定过程；它用状态图、checkpointer、interrupt() 提供挂起、保存状态和外部命令恢复的实现能力。这些能力正好是第十二话要做“可恢复、不可绕过的审批”的原料。

但它不会因为你用了 LangGraph，就自动保证审批合规。状态图上的节点连得通，不代表业务上这一段就该执行。publish_article 这种迁移在不允许发布的状态下必须由运行时拒绝——框架给你的是“状态图能跑”，不给你“业务边界天然正确”。

所以这一话只把 LangGraph 标记为实现方向，不展开 API。下一步要去的地方，就是把“接下来该做什么”从人工解读变成可以被恢复、被拦截、被审计的运行时机制。

一句话收口：框架替你搬运状态，不替你决定业务。安全边界只能来自你写的校验契约和动作网关。

下一话：Skill 只是提示词——如何让 Agent 真正停下来，并且跨进程可以恢复、无法绕过审批。

踩坑速查

症状	原因	解法
`--live` 报 `LLM network error` / DNS 解析失败	沙箱或本地网络到模型 API 不通	用离线 `python3 -m unittest -v` 先验证控制流；真实调用再解决网络/代理
模型返回值解析失败或 `content` 为空	部分推理模型默认 thinking，`content` 在 reasoning 里	显式 `thinking:{"type":"disabled"}` 并要求 JSON 输出
Java 运行报 `UnsupportedClassVersionError`	用了旧版 JDK	用 JDK 21 + `./gradlew`，或直接 `javac/java` 跑 `MinimalSuspendDemo`
计划里写了“等待”，运行时不暂停	把等待当成了数据标记	改成 `return`/`break`/状态机迁移，并写进回归测试

参考

LangGraph Documentation, “Workflows and Agents”, https://docs.langchain.com/oss/python/langgraph/workflows-agents/（Workflow 与 Agent 的路径决定方式，成文时已核对）。
LangGraph Documentation, “Interrupts / Human-in-the-loop”, https://docs.langchain.com/oss/python/langgraph/interrupts/（interrupt()+checkpointer 的挂起恢复能力，本篇只作方向标记）。
本话演示代码与回归测试：配套代码仓库中的 python/control_modes.py、java/.../Main.java、java/.../MinimalSuspendDemo.java。

第四话｜模型说调 refund_order，Runtime 怎么不把事情搞砸？

Tue, 14 Apr 2026 00:00:00 +0000

第三话结束时，我们留下一个问题没解决：

tool_calls 永远是候选，不是命令。谁来判断"能不能执行、怎么执行"？

这就是第四话要回答的。模型提出的工具调用，哪怕 JSON 合法、参数齐全，也可能是错的、越权的、有副作用的。Runtime 不能照单全收——它得先校验，再执行，而且要在执行出问题时不把局面搞得更糟。

这里最危险的，不是选错工具，而是一个有副作用、结果又说不清的操作。比如模型要调 refund_order 退款：

handler 执行到一半超时了。钱到底退了没有？直接重试，可能重复退款；不重试，用户又以为没退成。

这一话就沿着这条退款主线，讲清楚 Runtime 怎么把"模型说要调用"变成"安全地执行"——以及最关键的，超时之后怎么根据真实状态做决定，而不是靠猜。

一、模型说"调 refund_order"，Runtime 先干什么？

模型返回的 tool_calls 里，是一段结构化申请单：工具名 refund_order、参数 order_id 和 idempotency_key。但它是模型生成的，是外部输入，不是已经校验过的命令。

Runtime 拿到它，第一件事不是执行，是问三个问题：

这个工具名，是允许执行的吗？
参数齐全、类型对吗？
这个工具现在可用吗？

任何一个不过，就不进 handler，而是返回一个结构化的错误，让上层能稳定地分支处理。

为什么要结构化，不能是一段"调用失败，请稍后再试"的文案？因为文案里没有可编程的信息——程序没法可靠地区分"工具不存在"和"参数缺了"和"执行到一半挂了"。而这三种情况，处理方式完全不同：

错误码	发生了什么	该怎么处理
`UNKNOWN_TOOL`	模型报了个不存在的工具名	拒绝，修正工具选择
`INVALID_ARGUMENT`	参数不满足契约	补参数或拒绝
`TOOL_UNAVAILABLE`	工具已下线或不健康	告知不可用，不能硬调
`EXECUTION_ERROR`	handler 或下游执行失败	按恢复语义决定，见下一节

前三个错误，handler 根本没执行——它们发生在执行之前。第四个才是真正进到了执行阶段，也是最麻烦的。

二、执行时出了问题，最怕的是"结果说不清"

refund_order 通过了校验，handler 真的去调订单服务了——然后超时。

超时意味着什么？意味着"结果不确定"。请求可能压根没到达订单服务，也可能已经到达、退款都成功了，只是响应没传回来。你分不清。

这就是最危险的地方：如果 Runtime 把"超时"直接当成"没执行"，再调一次，就可能退了两笔钱。而如果当成"失败了"，用户这边又显示退款失败，但其实钱已经退了——两边对不上。

所以规则只有一条：超时之后，先查这笔操作的真实状态，不要直接重试。

怎么查？靠 idempotency_key（幂等键）。它是发起退款时就带上的、这笔操作的唯一标识。领域服务按这个键记录"这笔退款到底执行了没有"，Runtime 超时后先去查它，而不是再发起一笔。

flowchart TD
 A[refund_order 超时] --> B[按 idempotency_key 查询真实状态]
 B -->|SUCCEEDED| C[回放成功结果
不再调 handler]
 B -->|NOT_EXECUTED| D[确认没执行
才重试一次]
 B -->|UNKNOWN / 执行中| E[等待或人工核验]

三条分支，对应三种真实状态：

SUCCEEDED：钱已经退了。Runtime 把成功结果回放给用户，不再调 handler。这是最容易犯错的场景——明明已经成功，却因为"没收到响应"而再退一次。
NOT_EXECUTED：确认没执行过。这时重试一次是安全的。
UNKNOWN / 执行中：状态也查不到。这时既不能重试，也不能谎报成功，只能等待对账或转人工核验。

跑一遍主线 demo，你会看到这样一条 Trace：

refund_order response=EXECUTION_ERROR
idempotency_status=SUCCEEDED
runtime_action=REPLAY_SUCCESS
final=SUCCESS
refund_order handler_execution_count=1

最后一行是整条链路的关键证据：handler_execution_count=1。它证明 Runtime 虽然经历了"超时 → 查状态 → 回放"，但真正执行退款的 handler 只跑了一次。没有重复退款。

三、把"谁负责什么"钉死

超时恢复这件事，看着是 Runtime 一个人的活，其实牵涉三个角色，职责不能混：

角色	负责什么	不负责什么
领域服务（`RefundDomain`）	记录和查询"退款到底发生没有"	不负责重试策略，也不知道 Runtime 怎么编排
Runtime	按恢复语义，决定回放、重试还是等待	不拥有退款事实，退款有没有发生得问领域
模型	只提出候选调用	不拥有执行权，更不能拿它的话当退款状态

一句话：有副作用工具的超时恢复，首先是领域状态问题，其次才是 Runtime 的重试策略问题。 退款有没有发生，是领域事实，只能问领域服务；Runtime 能做的是照着这个事实去编排下一步，而不是自己猜。

反过来看，如果领域服务不记录幂等状态，Runtime 再聪明也没用——它没有可以查询的真相，超时之后只能抓瞎。所以幂等这件事，得从工具设计那天就带上，而不是等出了超时才补。

四、把这条链路跑起来

配套 demo 在 code/agent-tutorial/c04-tool-registry/，Python 和 Java 各一份，语义一致。它不调用 LLM、订单或支付系统——所有 handler 都是本地确定性模拟，所以它验证的是 Runtime 的控制流，不是退款系统的可用性证明。

cd code/agent-tutorial/c04-tool-registry/python
python3 registry.py
python3 -m unittest test_registry.py

cd ../java
gradle run

它覆盖六类场景，每一类都对应上面讲的一个环节：

场景	验证什么
工具不存在	`UNKNOWN_TOOL`，不进 handler
工具下线	`TOOL_UNAVAILABLE`，不能硬调
参数缺失	`INVALID_ARGUMENT`，补参或拒绝
正常调用	一次执行，`SUCCEEDED`
超时但已成功	查幂等 → `SUCCEEDED` → 回放，`handler_execution_count=1`
超时且未执行	查幂等 → `NOT_EXECUTED` → 重试一次

其中"超时但已成功"是最值得盯着看的一条：它模拟了 handler 执行成功后、响应却丢失的场景——退款已经发生，SUCCEEDED，但 Runtime 收到的是超时。正确的 Trace 必须是"回放成功结果"，而不是"再退一次"。

五、还差的：执行成功 ≠ 永远可靠

跑通这条链路，Runtime 能安全地执行一次有副作用的调用了。但这离"可靠"还有距离，几件事本篇点到为止，先立个边界：

一次超时不等于工具坏了。订单服务偶发抖动，不能立刻把 refund_order 永久下线；连续失败达到阈值才考虑熔断。
熔断后的探测，不能用一笔新退款去试。要用无副作用的健康检查——否则"检查服务恢复没有"这件事本身，又制造了一笔业务动作。
Runtime 不替代鉴权、审批和审计。工具能不能调，除了契约校验，还涉及"这个用户有没有权限"“要不要二次确认"“留不留审计留底”——这些是 Runtime 与领域服务的责任，本篇没展开。

这些都属于"从单次安全执行到生产级可靠"的延伸，先把边界划在这，不抢后续章节的戏。

到下一话，问题才真正变难

现在，Runtime 已经能把单个候选调用安全地执行，并在超时后不搞砸。

但它还不会根据第一次工具的结果，决定第二步做什么。

第五话才进入真正的 ReAct 循环：第二个 Action 必须依赖第一个 Observation。那时，今天建立的 ToolResponse 和幂等恢复，会成为循环里可复用的执行底座。