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 |
| 重试对象 | task/activity | model call、tool call、context build、checkpoint |
| 失败处理 | 预设分支或补偿 | 结构化 observation，可能重新规划 |
| 权限 | 多是业务审批 | 每个工具调用都可能审批 |
| 可观测 | state transition、activity log | model span、tool span、permission、context、checkpoint |
| 测试 | 固定输入输出和状态分支 | 行为断言、tool path、must-not-call、eval replay |
| 风险 | 分布式流程失败 | 模型误判、工具误调、越权、爆 token、幻觉 observation |
看起来像同一类系统，是因为它们都要处理状态和失败。
真正不同的是：谁决定下一步。
Workflow 可以包 Agent
生产系统里，一个常见形态是 workflow 包 agent。
比如客服工单：
收到工单
↓
Workflow: 分类和鉴权
↓
Agent: 阅读上下文，提出处理建议
↓
Workflow: 人工审核
↓
Workflow: 发送回复或升级
↓
Workflow: 记录 SLA
这里 workflow 负责业务主流程。
Agent 只负责某个开放判断环节。
这很健康。
因为客服工单不应该完全交给 Agent 自由发挥。SLA、权限、通知、归档、审计，这些都适合 workflow。
Agent Runtime 在中间管理模型和工具行动。
Agent Runtime 也可以调用 Workflow
反过来也常见。
Agent 可能在排查后决定触发一个固定流程：
Agent 诊断：需要创建发布审批
↓
Tool call: start_release_approval_workflow
↓
Workflow Engine: 走固定审批链
这种时候，workflow 是 Agent 的一个高阶工具。
但要注意：
Agent 只能请求启动 workflow。
Runtime 仍要校验：
这个 workflow 是否存在
输入是否合法
当前用户是否有权限
是否需要确认
是否幂等
启动后 workflowId 是什么
失败后是否能查询状态
不要因为工具名字叫 start_workflow，就让模型随便触发企业流程。
Workflow 一旦启动，副作用可能比普通工具更大。
Durable Execution 不能替代 Tool Governance
Temporal 这类系统擅长 durable execution。
但 durable execution 不等于 Agent 安全。
假设你把一个 Agent run 放进 Temporal workflow：
workflow:
activity: call_model
activity: execute_tool
activity: append_message
loop until final
这会让执行更可靠。
但它不会自动回答：
模型返回的工具参数是否合法？
read_file 路径是否越界？
run_command 是否危险？
工具结果能不能进入上下文？
MCP Server 是否可信？
tool ledger 是否记录不可重放副作用？
permission denied 后模型能不能绕路？
这些还是 Agent Runtime 的责任。
Workflow Engine 提供可靠执行底座。
Agent Runtime 提供模型行动治理。
Agent Runtime 也不要重新造所有 Workflow 能力
另一边也要克制。
Agent Runtime 不应该把自己写成一个半吊子的 Temporal。
如果你需要：
跨天、跨月、跨年的业务流程
复杂补偿
外部系统回调
定时器
多服务协同
强 SLA
大规模状态机
业务审批链
直接接成熟 Workflow Engine。
不要在 Agent Runtime 里自己写一个隐形工作流平台。
Runtime 应该专注：
模型调用
上下文预算
工具治理
权限审批
trace
checkpoint
eval
成本控制
业务长流程交给 Workflow Engine，通常更稳。
一个真实的混合架构
可以这样设计：
Product Request
↓
Workflow Engine
├─ Step: validate user / tenant
├─ Step: load business context
├─ Step: run Agent Runtime
│ ├─ ContextBuilder
│ ├─ ModelProvider
│ ├─ ToolRegistry
│ ├─ PermissionGate
│ ├─ ToolExecutor
│ ├─ TraceSink
│ └─ CheckpointStore
├─ Step: human approval
├─ Step: commit business action
└─ Step: notify / audit
Workflow 管业务骨架。
Runtime 管 Agent 行动。
这样系统既有确定性，也有开放判断。
这比'全部 Agent 化'靠谱得多。
判断边界的四个问题
设计时可以问四个问题：
第一，下一步能不能提前枚举？
能，优先 workflow。不能，可能需要 Agent。
第二，失败补偿是否有固定路径？
有，workflow 很适合。没有，需要 Agent 重新规划，但 Runtime 要留证据。
第三，是否涉及模型选择工具？
涉及，就必须进 Agent Runtime 的工具治理。
第四，状态是否要跨业务系统长期存在？
是，workflow 或业务系统更合适。Runtime checkpoint 只负责 Agent run 的恢复，不应承担整个业务流程状态。
这四个问题比'用不用某框架'更有用。
Eval 也不同
Workflow 的测试通常是：
给定输入
走到某个 state
调用某个 activity
输出某个结果
Agent Runtime 的 eval 要看行为证据：
是否调用了正确工具
是否避免危险工具
是否读了必要文件
是否在权限拒绝后停止
是否控制 step 和 token
是否从 checkpoint 恢复后没有重复副作用
本书 demo 里的 eval harness 就不是比最终回答逐字一致，而是检查 tool ledger、final answer、denied tool、changed file。
因为 Agent 的风险在路径里。
不是只在答案里。
最后的结论
Agent Runtime 和 Workflow Engine 有什么区别？
Workflow Engine 管预先定义的流程。
Agent Runtime 管模型参与决策后的行动边界。
两者不是替代关系。
正确用法通常是：
确定性业务流程交给 Workflow。
开放判断交给 Agent。
所有工具行动进入 Runtime。
长期业务状态留在业务系统。
可恢复执行可以借 Workflow Engine 做底座。
