Agent Runtime 和 Workflow Engine 有什么区别？
很多人第一次做 Agent 系统，会问：
既然 Temporal、Step Functions、Airflow、Dagster 这类 workflow engine 已经能编排任务、保存状态、重试失败，为什么还要 Agent Runtime？
这个问题很好。
因为 Agent Runtime 里确实有一部分东西，看起来很像 Workflow Engine：
step
state
retry
timeout
checkpoint
trace
human approval
resume
但它们处理的'不确定性'不是同一种。
Workflow Engine 管确定路径。
Agent Runtime 管开放行动。
Workflow Engine 很强
先别急着贬低 workflow。
Temporal 官方把 durable execution 讲成 crash-proof execution：应用可以在崩溃、网络失败、基础设施中断后继续。AWS Step Functions 把工作流定义成 state machine，用一系列 event-driven steps 编排分布式应用。
这些系统解决的问题非常硬：
长流程状态持久化
任务重试
超时
补偿
人机审批
分布式步骤编排
可视化状态
失败恢复
生产系统离不开它们。
下订单、审批报销、发票处理、数据同步、风控流程、CI pipeline，都很适合 workflow。
只要路径能提前写清楚，workflow 往往比 Agent 更可靠、更便宜、更可测。
这也是我一直强调的：能用 workflow 解决的，不要硬塞 Agent。
Agent Runtime 多了一个麻烦东西：模型决策
Agent Runtime 的麻烦在于，下一步不总是工程师提前写死的。
用户说：
帮我修复这个测试失败。
你不知道模型下一步会：
读哪个文件
搜索哪个符号
跑哪个测试
是否修改代码
是否请求更多上下文
是否换一个排查路径
这不是普通 workflow 的 Choice state。
Workflow 的 Choice 通常基于确定字段：
if order.status == "paid" -> ship
if score < 60 -> manual_review
if retry_count > 3 -> fail
Agent 的下一步常常来自模型对当前上下文的判断：
这个错误可能来自 ToolRegistry。
先读 runtime.ts。
再搜索 ToolResult。
然后运行 npm test。
Runtime 要做的是把这个开放决策放进可控边界：
模型提出计划
Runtime 校验工具
Runtime 判断权限
Runtime 执行工具
Runtime 记录观察
Runtime 决定是否继续
所以 Agent Runtime 不是 workflow engine 的重复发明。
它是在模型参与行动选择后，对行动进行治理。
一个表说清区别
| 问题 | Workflow Engine | Agent Runtime |
|---|---|---|
| 下一步来自哪里 | 工程师预定义 | 模型根据上下文选择 |
| 状态是什么 | 业务流程状态 | run state、messages、tool ledger、context digest |
| 重试对象 |