Agent Runtime 的分水岭：断线续传、检查点与轨迹分支怎样支撑长任务
长任务 Agent 最常见的故障并不是“模型答错”，而是运行了二十分钟后浏览器断线、容器迁移、OAuth 过期，或者人工审批隔了一夜才返回。若 Runtime 只能把 prompt 发给模型，它会在恢复时丢失执行位置；若只是保存聊天记录，它又无法判断某个外部动作到底有没有成功。
Google 在 2026 年公开的 Agent Executor 把 Agent Runtime 定义为执行、恢复和分布式部署层，并明确支持持久执行、断线回放、检查点与轨迹分支。OpenAI 与 AWS 公布的 Stateful Runtime Environment 也把 working context、工具与工作流状态、环境、身份和权限边界列为长任务的基础。这说明行业正在形成共识：Runtime 的竞争不在 loop 写法，而在恢复语义。
事件流比“当前状态”更重要
可靠 Runtime 应把一次运行表示成单调追加的事件序列：
连接属于传输通道，事件日志才保存事实；恢复过程应回放缺失事件，而不是重新猜测外部动作是否执行。
客户端只保存最后看到的序号，重连后由 Runtime 回放缺失事件。这样“界面没收到结果”不会被误判成“工具没执行”。事件日志负责事实，WebSocket 或 SSE 只负责传输；连接可以丢，事实不能丢。
工具调用需要独立的 call_id 和幂等键。Runtime 在崩溃后查询工具网关：若调用已提交，就读取 receipt；若明确未开始，才重试；若状态未知，进入人工或补偿流程。对付款、发货、权限变更等不可逆动作，绝不能用“超时就再调一次”。
检查点保存什么
检查点不是完整内存 dump，也不等于把所有消息塞回模型。合理的检查点至少包含：
- Agent 版本、模型与工具 schema 的内容哈希；
- 当前状态机节点、待完成动作和并发分支；
- 已提交工具调用及其 receipt；
- 可重建的工作上下文引用，而非无限增长的 prompt；
- 身份、授权范围、策略版本和预算快照；
- 最后事件序号与恢复代数。
恢复代数决定哪些东西可以重算。模型生成的计划可以重算，但已经发送的邮件不能；搜索结果可以按 TTL 重取，审批决定必须引用原记录；临时推理草稿可以丢弃，业务事实必须可追溯。
轨迹分支不是“多跑几次模型”
Agent Executor 提到的 trajectory branching 允许从检查点复制执行路径，比较不同模型、提示或工具策略。这对评测和高价值决策很有用，但分支必须隔离副作用。
建议把工具分成三级：
| 级别 | 示例 | 分支策略 |
|---|---|---|
| Pure | 计算、格式转换、本地检索 | 任意并发重放 |
| Read | 搜索、查询库存、读取工单 | 带快照时间与速率限制 |
| Write | 发信、付款、改配置 | 仅胜出分支进入提交阶段 |
所有探索分支都运行在 dry-run 或影子资源中，控制面选择胜出路径后，再产生一份独立的 commit intent，由策略引擎重新授权。否则“并行思考”会变成“并行写生产”。
为什么普通 Kubernetes 不够
Kubernetes 很擅长维护服务副本，却不知道 Agent 正在等待用户、工具还是预算。Google 的 Agent Substrate 尝试在 Kubernetes 之上增加面向海量 Agent 的轻量控制层，使等待中的 Agent 脱离计算资源，需要执行时再恢复。关键不是抛弃 Kubernetes，而是把 Agent 生命周期与 Pod 生命周期解耦。
企业可以先实现一个朴素版本：PostgreSQL 追加事件表、对象存储检查点、队列调度、短时 Sandbox、工具网关和 OTel trace。只要协议稳定，将来可以替换为云厂商 Runtime；若一开始把状态绑进某个框架进程，迁移成本会非常高。
必须量化的运行指标
除了成功率，还要观测恢复正确性：
duplicate_side_effect_rate必须接近零；resume_latency_p95衡量从中断到继续工作的时间；orphan_run_age发现无人管理的等待任务；checkpoint_restore_failure_rate暴露版本不兼容；approval_wait_time区分系统慢和人在等待；cost_per_completed_outcome避免只优化 token 单价。
真正成熟的 Agent Runtime 允许连接中断、进程消失、模型切换和人类迟到，但不会丢任务身份、扩大权限或重复外部动作。这才是长任务从 Demo 进入生产的分水岭。