长程任务 Agent 的工程化生存术 ——状态终端续跑、记忆分层、千步上下文不丢、分布式集群部署与优雅升级的深度研究

作者：DeepThink 研究院 · 2026-07-19
摘要 / Abstract：当 Agent 从「一问一答」走向「数千步、跨数小时、横跨多个工具与子任务的自主作业」，工程挑战从"模型能力"转移到"运行时基础设施"。本文围绕五个核心问题——(1) 中断后如何从断点续跑；(2) 记忆如何分层管理以突破上下文窗口；(3) 跑到几千步之后上下文如何不丢、不漂移；(4) 如何在分布式集群上调度、隔离、伸缩；(5) 运行中如何优雅升级而不打断在跑的长程任务——系统梳理当前公开实践（Temporal/Restate/DBOS、MemGPT/Letta/mem0/Zep、Anthropic Context Engineering、LangGraph Platform 等），提炼一套可落地的工程范式，并给出 DeepThink 平台的实施建议。

---

DeepThink 是你的私有AI 操作系统 (AI Agent Platform)，在安全隔离的沙箱环境中，自主执行代码、管理文件、完成超复杂长程任务。自托管的多用户本地 AI Agent Loop Engineering 系统 (支持桌面端+浏览器+移动端) —— 让 DeepThink 成为你的全能数字助手。
—— Powered By AI Genius Institute & 光剑AI

DeepThink 项目开源代码：
Gitcode: https://gitcode.com/AIGeniusInstitute/deepthink
Github: https://github.com/AIGeniusInstitute/deepthink

---

0. 引言：长程 Agent 的新工程地平线

传统 LLM 应用的工程模型是无状态请求—响应：一次 prompt in、一次 completion out，上下文即生即灭。长程任务 Agent（Long-Horizon Task Agent）彻底改变了这个假设：

• 状态生命周期远超进程生命周期：一个任务可能跨数小时甚至数天，期间进程必然重启、worker 必然被替换、机器必然故障。状态不能死在内存里。
• 上下文是稀缺且有界的资源：即便 200K~1M token 窗口，数千步累积的工具输出、子任务轨迹、反思记录也会撑爆窗口，且越长越漂移。
• 执行天然分布式：单机扛不住并发、隔离、多租户、弹性伸缩；长程任务必须在集群上被调度。
• 代码与状态强耦合：升级 worker 代码时，已写入的事件历史用新代码回放可能产生非确定性错误，把"升级"变成高危操作。

这五条共同把"长程 Agent"从一个模型问题，变成了一个分布式持久化执行系统问题。本文逐一拆解。

---

1. 状态终端续跑：让 Agent 像 JVM 一样可崩溃恢复

1.1 问题定义

「终端续跑」= 进程在任意一步被杀（OOM、部署、断电、panic），系统恢复后能从最近一次 checkpoint 精确续跑，且不重复副作用（exactly-once 语义）。这要求三件事：

1. 状态外置：所有决定下一步走向的状态不能只活在进程内存，必须落到可恢复存储。
2. 幂等步骤：崩溃前可能执行了一半的步骤，恢复后重做不能产生重复副作用。
3. 确定性回放：恢复时若需重算某段，相同输入必须产生相同分支。

1.2 Durable Execution：从工作流引擎借来的成熟范式

长程 Agent 的续跑问题，本质就是工作流引擎几十年前解决的问题——Durable Execution（持久化执行）。当前最成熟的实践来自：

Temporal：事件溯源 + 确定性回放

Temporal 把工作流执行建模为事件历史日志（event-sourced history）：

• 每一步（Activity 调用、Timer、Signal、状态变更）都作为不可变事件写入历史日志，落库于 Cassandra/Postgres/MySQL。
• 崩溃后，任意 worker 拉起同一 workflow，从历史日志回放工作流代码。回放时，已记录的 Activity 结果直接从历史读取，不重新执行；只有未执行的步骤才真正运行。
• 这天然实现了 exactly-once：消息层 at-least-once（worker 崩溃会重投任务），业务层靠"已完成步骤读历史跳过"达成 exactly-once。

关键约束——确定性回放要求工作流代码是纯函数：所有非确定性来源（系统时间、随机数、HTTP、LLM 调用）必须走 SDK 拦截入口（Activity / workflow.Now / workflow.SideEffect），回放时返回历史值而非重算。一旦在 workflow 体内直接调用 datetime.now() 或裸 LLM API，回放必然发散。

来源：Temporal — How Temporal Works https://docs.temporal.io/encyclopedia/how-temporal-works；Workflow Determinism https://docs.temporal.io/workflows/determinism；Build AI Agents with Temporal https://temporal.io/blog/build-ai-agents-with-temporal

Restate：journal-first 模型

Restate 用 typed journal entry 替代自由对象序列化。SDK 拦截 ctx.run / ctx.call / ctx.sleep 等非确定性操作，先写 journal 再执行；崩溃回放时，已完成条目直接返回缓存结果，未执行的再跑。awakeable entry 给外部异步完成一个 resume token，调用方持有 token 后随时 resume——这是"人工审核后继续"这类 human-in-the-loop 场景的天然载体。

来源：Restate Durable Execution https://docs.restate.dev/concepts/durable-execution；The Journal https://docs.restate.dev/concepts/journal；Journal Entries https://docs.restate.dev/references/journal-entries

DBOS：Postgres 即真相源

DBOS 把 Postgres 当作唯一真相源，@DBOS.step() 装饰器把每步完成写入 dbos_workflow_status / dbos_steps 表，且与业务表写入同事务——这意味着"步骤完成"与"业务副作用"原子绑定。恢复时跳过已完成步骤、从断点续跑。

来源：DBOS 文档 https://docs.dbos.dev/

其他：Cadence（Temporal 前身）、Windmill（ctx.pause() + webhook resume）、Inngest（step.run()/step.sleep() 为 checkpoint 边界，失败从最近成功 step 重启）。

1.3 LLM Agent 框架的 Checkpointer

将 durable execution 引入 LLM Agent 的代表是 LangGraph Checkpointer：

• 一类 BaseCheckpointSaver 接口，实现 MemorySaver / SqliteSaver / PostgresSaver / RedisSaver。
• thread_id 标识会话，checkpoint 含：当前图节点位置、channel/变量值、pending writes、versions_seen（幂等与一致性用）。
• 支持 time-travel（从任意 checkpoint 重放）与 human-in-the-loop 中断。

来源：LangGraph Persistence https://langchain-ai.github.io/langgraph/concepts/persistence/；LangChain Blog — Checkpointing long-running agents https://blog.langchain.dev/checkpointing-long-running-agents

1.4 核心矛盾：LLM 非确定性 vs 确定性回放

这是 LLM Agent 比传统工作流多出来的一层硬骨头：Workflow 的 deterministic replay 要求相同输入产生相同输出；LLM 本质非确定。 若把 LLM 调用直接写在 workflow 体内，回放会得到不同结果，破坏一致性。

通用解法——把 LLM 调用包装成 Activity / ctx.run() / side_effect 这类非确定性边界：

• 首次执行真正调用模型，结果写入 journal/event history。
• 回放时直接读历史返回，不再请求模型。

次级技巧：

1. 响应缓存：按 prompt hash 缓存 LLM 输出（prompt cache 也是同构思路）。
2. 逼近确定性：temperature=0 / 固定 seed（仅降低不消除）。
3. 版本快照：checkpoint 中存模型版本与采样参数，避免跨版本回放失配。
4. 文件系统 checkpoint：把已生成但未提交的中间产物写到磁盘（Anthropic 推荐），崩溃后从文件而非上下文重建。

来源：Anthropic — Effective context engineering for AI agents https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents；Claude Code Sub-agents https://docs.claude.com/en/docs/claude-code/sub-agents

结论：durable execution 引擎提供了"机制上的确定性回放框架"；LLM 的非确定性被降级为 Activity / side_effect 这种"被日志捕获的非确定性点"。两者通过先持久化结果、回放只读不重算对齐——这正是长程 Agent 续跑的可工程化范式。

---

2. 记忆分层管理：把 OS 虚拟内存思想搬进 LLM

2.1 为什么需要分层

模型上下文窗口有物理上限（即便 1M token 也是有限的），但长程 Agent 需要记住的"有效记忆"远超窗口。唯一出路是分层 + 按需召回注入，让上下文窗口从"记忆容器"变成"寄存器/CPU cache"，把大容量记忆外置到"内存/磁盘"。

2.2 主流分层模型（CoALA / 认知科学映射）

层级	类比	内容	访问
Working memory	寄存器 / CPU cache	LLM 当前上下文窗口：系统指令 + 最近对话 + 召回注入的 top-k 片段 + 活跃推理	模型直接读
Short-term	RAM	当前会话/线程状态，由 checkpoint 持久化	每轮可见
Episodic	页缓存	按时间记录的交互/轨迹	相似度+时间召回
Semantic	索引文件系统	事实/知识，常用知识图谱或向量库承载	语义检索
Procedural	可执行库	可复用工作流、工具调用模式、prompt 模板（Voyager 技能库）	按需调用
Archival	冷归档磁盘	跨会话冷存储，容量最大访问最慢	显式 function call 召回

来源：CoALA（Sumers 等，Princeton，2023）https://arxiv.org/abs/2309.02427；A Survey on the Memory Mechanism of LLM-based Agents（Wang 等，2024）https://arxiv.org/abs/2404.13501

2.3 代表性项目

• MemGPT / Letta（UC Berkeley 2023）：把 LLM 视为操作系统，引入 OS 式分层内存——main context（RAM）/ recall context（cache）/ external context（swap）/ archival memory（disk）；通过 function call 在层间 paging。这是"突破固定窗口"的奠基性工作。
  • arXiv:2310.08560 https://arxiv.org/abs/2310.08560；商业公司 https://www.letta.com
• Letta sleep-time agents（2025）：提出 “sleep-time compute”——Agent 在用户离线时进行记忆固化、反思、预计算，类比人脑睡眠期的 memory consolidation。
• mem0：通用 LLM 记忆层，混合向量+图存储；用 LLM-as-judge 决定 add/update/delete，避免冗余；支持按 user/agent/session 多租户隔离。https://github.com/mem0ai/mem0
• Zep / Graphiti：核心是时间感知知识图谱（bi-temporal），节点/边带 valid_from/valid_to，新事实可覆盖或失效旧事实，结合向量+图+关键词混合检索，底层 Neo4j。https://github.com/getzep/graphiti
• LangMem / LangGraph Store：checkpointer 存线程短期状态，Store 存跨线程长期语义记忆，PostgresStore+pgvector 启用语义召回。https://langchain-ai.github.io/langgraph/concepts/memory/
• A-MEM（2025）：受 Zettelkasten 启发，记忆条目自动互相链接、自我重组织。arXiv:2502.14024

2.4 写入 / 检索 / 遗忘三大操作

Consolidation（短期→长期固化）

1. 摘要式固化：上下文满时将旧消息 summary 后写入 archival（MemGPT/Letta）。
2. 反思固化：周期性 reflection 把事件序列抽象成高层洞察，reflection 本身又写入 memory stream，形成多层抽象（Generative Agents）。
3. 图谱固化：用 LLM 抽取实体与关系写入图，新事实可更新/失效旧事实（Zep/mem0/Cognee）。

Retrieval（检索）——已成事实标准的三因子公式

$$\text{Score}=\alpha \cdot \text{Recency}+\beta \cdot \text{Relevance}+\gamma \cdot \text{Importance}$$

• Recency：0.99^(hours_since_last_access) 指数衰减。
• Relevance：query 与 memory embedding 余弦相似度。
• Importance：LLM 在记忆创建时打分（1–10）。

来源：Generative Agents（Park 等，Stanford，UIST 2023）https://arxiv.org/abs/2304.03442

混合检索进阶：Zep/Graphiti 用 vector + graph traversal + keyword 三路融合并重排。

Forgetting（遗忘）

• MemoryBank：Ebbinghaus 遗忘曲线 R = e^{-t/S}，频繁召回的记忆 S 增大、衰减变慢；低分记忆剪枝。
• mem0：LLM-as-judge 检测重复/矛盾后 delete/update，避免无界增长。
• MemGPT：靠 paging 把冷数据移出 main context，但不真正删除（archival 永久）。

2.5 存储后端分工

类型	代表	适用
向量库	Qdrant / Pinecone / Weaviate / pgvector / Chroma	语义相似度召回（episodic/semantic）
图数据库	Neo4j / Memgraph	实体关系 / 时间感知（Zep/mem0 graph/Cognee）
关系库	Postgres（+pgvector）	LangGraph checkpointer + Store，兼顾短期线程状态与长期语义召回
时序记忆	Graphiti bi-temporal	跟踪事实有效时间区间，处理"曾经为真"查询

2.6 与上下文窗口的关系（核心工程价值）

MemGPT 的核心贡献是把 OS 虚拟内存思想映射到 LLM context：

• 放 context 内：系统指令、当前轮、最近若干轮、召回注入的 top-k 片段（page in）。
• 外置：完整历史、归档事实、知识图谱——存到 archival/向量/图，按需召回。
• 召回注入：Agent 通过 function call（archival_memory_search / core_memory_replace）自主决定何时把外部记忆 paging 进 main context；满时再 page out。

这样 Agent 的"有效记忆"远大于模型 context 窗口，同时保持召回精度。

---

3. 千步上下文不丢：上下文工程（Context Engineering）

3.1 从 Prompt Engineering 到 Context Engineering

“Prompt engineering 关注单次输入质量；context engineering 关注 agent 长程运行中上下文如何演化。后者决定 agent 能否走完数千步。”
—— Anthropic Engineering

Anthropic 把上下文当工程对象来管理，提出四件套：Write context → Select context → Compress & Isolate → Tool execution。核心论点：上下文窗口是稀缺资源，需要像内存管理一样主动管理；被动"全量保留"必然导致 lost-in-the-middle 与漂移。

来源：Anthropic — Effective context engineering for AI agents https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents；Context engineering for AI agents https://www.anthropic.com/engineering/context-engineering-for-ai-agents；How to do time-consuming tasks with agents（“agents don’t write code that crashes at 2am”）https://www.anthropic.com/engineering/how-to-do-time-consuming-tasks-with-agents

3.2 长程下的三类典型失败

1. Lost-in-the-middle：长上下文中段信息召回率显著低于首尾。https://arxiv.org/abs/2307.03172
2. Context drift（漂移）：早期约束随轮次增加被稀释，agent 偏向最近消息（recency bias），逐步偏离原目标。
3. Retrieval failure：即便 RAG，长程下 query 与目标 chunk 语义距离变化，召回率衰减。

基准佐证：τ-bench（政策漂移是主要失败模式）https://arxiv.org/abs/2406.12045；SWE-bench 多步（agent 容易忘记早期失败原因而重复犯错）https://arxiv.org/abs/2310.06770；LongBench（揭示 lost-in-the-middle）https://arxiv.org/abs/2308.14508；AgentBench / WebArena。

3.3 工程化对策（落地清单）

(1) 上下文压缩与摘要

• Rolling Summary / Progressive Summarization：每 N 轮把最旧 K 条消息压成一段摘要，摘要本身可被再次压缩。
• 陷阱：多轮压缩会"稀释"低频但关键的事实（如"用户明确要求用 PostgreSQL 而非 MySQL"）。对策：关键事实白名单 + 每轮 re-injection。
• Context compaction：阈值触发（如 80% 满），保留段白名单（system / 重要 todo / 最近工具调用），摘要质量回读校验。

(2) 子 Agent 隔离上下文（最有效的防漂移手段）

• 子 agent 启动时拿到干净上下文 + 任务描述，跑完只把"结论 + 关键证据"回传主线程，主线程不继承子 agent 的中间 token。
• 价值：把"探索 1000 步"的上下文成本封装在子 agent 内部，主线程只付出"结论长度"的 token。
• 反模式：把子 agent 完整 trace 拉回主线程 = 等于没隔离，上下文仍会爆炸。

来源：Anthropic — Building Effective Agents https://www.anthropic.com/research/building-effective-agents；How we built our multi-agent research system https://www.anthropic.com/engineering/multi-agent-research-system；Claude Code Sub-agents https://docs.claude.com/en/docs/claude-code/sub-agents

(3) 文件系统作为外部记忆

把"全局计划、当前进度、关键决策、不可变约束"写进 todo.md / state.json / PLAN.md，主上下文只放一个"读 state.json"的指针：

• todo.md：checkbox 列表，每完成一项打勾，主线程每轮重读以重锚定目标（防漂移）。
• state.json：结构化状态机（当前阶段、上次失败原因、待重试项）。
• scratchpad.md：临时推理草稿，跨步保留但可随时清理。

主对话窗口是"寄存器"，文件系统是"内存 + 磁盘"——把大对象落到文件，对话里只留 <path> 与一行摘要，主上下文可压到恒定体积。

(4) Context Budget + Eviction Policy

• 为每个 agent run 设定 token 预算（如 60% 历史 / 20% 工具输出 / 20% 余量），超阈值触发压缩。
• 淘汰策略 = 按 (重要性 × 时效性 × 是否在白名单) 综合打分 evict，而非纯 LRU；工具调用的大块输出优先落地文件、对话内只留指针。

(5) Re-injection of Critical Facts

每 N 步把"不可变约束 / 用户硬性要求 / 当前 todo"重新注入一次，对抗 recency bias 与漂移。

(6) Checkpoint & Resume + Verification Loop

• 每个子任务结束写 checkpoint（已完成 / 失败原因 / 下一步），失败可从最近 checkpoint 恢复而非从零重跑。
• 退出条件必须客观验证（测试通过 / 截图 / 日志），禁止主观"应该可以"——这正是 Supervisor Agent 范式的精神。

“不要让 agent 在凌晨 2 点无人值守地写会崩溃的代码”——验证闭环优先于自主性扩张。

3.4 小结：千步不丢的本质

千步上下文不丢，不是靠"更大的窗口"，而是靠把上下文从"容器"变成"寄存器"：主线程恒定体积（只放目标+指针+最近 K 轮+白名单约束），子 agent 隔离探索上下文，大对象落盘，关键事实每 N 步 re-injection，子任务带 checkpoint 可断点续跑。这正是 §2 记忆分层在"防漂移"维度的工程落地。

---

4. 分布式集群部署：长程任务在集群上的调度与隔离

4.1 长程任务的分布式难点

普通无状态服务的伸缩假设："请求是短时的，实例增减即可。"长程任务破坏这个假设：

• 会话亲和（session affinity）：一个任务跑几小时，中间状态散落在某实例，不能随意迁移。
• 反伸缩性：一个长程任务本身可能不可拆，靠加 worker 不能加速单个任务。
• 状态外部化：worker 必须无状态，所有决定下一步的状态落库，任何 worker 都能从 checkpoint 续跑。
• 隔离与多租户：Agent 执行的代码不可信，必须沙箱隔离；多租户下配额、计费、噪声要隔离。

4.2 控制面 / 数据面分离的典型架构

┌──────────────────────────────────────────────────────┐
│  Control Plane（调度 / 编排 / 多租户 / 计费 / 观测）  │
│   - API Gateway / Tenant Router / Quota              │
│   - Scheduler + Task Queue (Kafka/NATS/Redis Streams) │
│   - Checkpoint Store (Postgres + 对象存储)            │
│   - Memory Store (pgvector / 图库 / 向量库)           │
└──────────────────────────────────────────────────────┘
              │ task dispatch (sticky by thread_id)
              ▼
┌──────────────────────────────────────────────────────┐
│  Data Plane（无状态 worker pool, K8s 自动伸缩）       │
│   worker: poll task → load checkpoint → step → write │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐          │
│   │ worker A │  │ worker B │  │ worker C │ ...       │
│   └──────────┘  └──────────┘  └──────────┘          │
└──────────────────────────────────────────────────────┘
              │ code execution
              ▼
┌──────────────────────────────────────────────────────┐
│  Sandbox Plane（microVM / gVisor / Docker 隔离）      │
│   每个 Agent invocation → 独立沙箱 → 代码执行         │
└──────────────────────────────────────────────────────┘

4.3 代表性平台对照

平台	定位	关键机制
LangGraph Platform / Cloud	LangGraph 部署平台	checkpointer 持久化 + Server/Cron/Streaming + deployment revision + 多租户
Dify / Coze	应用层 Agent 平台	worker 队列 + Redis/消息队列编排 + 多租户工作区隔离
Temporal cluster	通用 durable execution	match→worker 分层，task queue 路由，事件历史落库，worker 无状态可任意伸缩
Restate cluster	durable functions	virtual objects 提供 keyed 单线程语义，invocation 级 pin，deployment drain
Ray / Ray Serve	通用分布式 Python	actor 模型 + autoscaling，适合 LLM serving 与 Agent 编排
E2B / Daytona / Modal	代码执行沙箱	firecracker microVM / gVisor，毫秒级启动，Agent 安全隔离
火山引擎 AgentKit	企业 Agent Ready 基础设施	Identity/Runtime/Evaluation/Sandbox/Memory/Knowledge 模块化

4.4 关键工程要点

(1) 会话亲和与状态外部化

长程任务对同一 thread_id 的连续 step 必须能被任意 worker 续跑。解法是彻底状态外置：worker 只持 checkpoint in-memory cache，真相在 Postgres/对象存储。sticky routing 仅为性能优化（命中 cache），不是正确性依赖——任何 worker 都能从库恢复。

(2) 沙箱与代码执行隔离

Agent 生成的代码不可信，必须隔离执行：

• Firecracker microVM：独立内核，毫秒级启动，AWS Lambda 同款。E2B、CubeSandbox 等采用。
• gVisor：用户态内核，兼容性好但性能损耗略高。
• Docker：共享内核，启动快但隔离弱，适合可信度较高场景。
• Docker-in-Docker：Claude Code 等本地 Agent 常用。

来源：claude-code-ultimate-guide sandbox-isolation https://github.com/FlorianBruniaux/claude-code-ultimate-guide

(3) 多租户隔离

• 命名空间隔离：tenant_id 贯穿 checkpoint / memory / sandbox 全链路。
• 配额与计费：按 invocation 数、step 数、token 数、沙箱时长计量。
• 噪声隔离：沙箱级资源限制（CPU/mem/pids），防止"邻居"互相干扰。

(4) 弹性伸缩与 scale-to-zero

• worker pool 按 task queue backlog 自动伸缩。
• scale-to-zero 适合 idle 场景，但长程任务的反伸缩性要求：单任务不可拆，靠并发槽位（concurrency slots）控制，而非对单任务加机器。
• lease/heartbeat：worker 持有任务期间发心跳，死了 lease 过期后由调度器再分配（zombie 防护）。

来源：Ray Serve autoscaling https://github.com/ray-project/ray；火山引擎 AgentKit（FORCE 大会 2026）Agent Ready 基础设施三层架构。

---

5. 优雅升级：运行中如何不打断在跑的长程任务

5.1 问题本质

长程 Agent 的代码是事件溯源（event-sourced）的——状态由历史事件回放得出。一旦 worker 代码在执行中途被替换，回放就会产生非确定性错误（non-deterministic error）：同一份历史事件在新代码上回放不出原来的分支/活动顺序。所以"升级"必须回答三件事：

1. 旧 workflow 在哪份代码上继续跑？
2. 新 workflow 走哪份代码？
3. 持久化的状态/checkpoint 如何与新代码兼容？

5.2 蓝绿 / 滚动 / Canary 对长程任务的特殊问题

普通无状态服务的滚动更新假设"请求短时，老实例 drain 完即可"。长程任务破坏这个假设：

• 任务跑一半 worker 被换：历史事件用新代码回放失败（分支编号/活动变了）。
• Schema 漂移：旧 worker 写入的状态字段在新 worker 里被重命名/删除，反序列化失败。
• Prompt/模型版本耦合：v1 agent 的中间推理（thought/plan/scratchpad）被 v2 prompt 读到，语义错位。
• Canary 比例失真：长程任务一旦路由到 canary 会"长期黏在 canary 上"，比例随时间漂移，需按"任务数"而非"启动速率"控制。

通用缓解模式：

1. 每个 invocation/workflow 绑定一个"代码版本"（build id / deployment id / revision），跨进程生命周期不变。
2. 新版本只承接新启动，旧版本继续服务存量，存量自然 drain。
3. 不做破坏性 schema 变更；破坏性变更走"新 workflow type / 新函数名"。
4. drain 完毕前不移除旧 deployment。

5.3 Temporal 的 Workflow Versioning（最成熟的一套）

概念

• Build ID：worker 代码构建的唯一标识（git sha / image tag）。
• Version Set（compatibility set）：一组互相兼容的 Build ID，集合内任一 worker 可回放彼此的 workflow 历史。
• Default Version：task queue 上新 workflow 默认绑定的 Build ID。
• Pinned Version：某个 workflow execution 锁定到的具体 Build ID，整个生命周期不被切走，保证确定性回放。

Worker Versioning Strategy

• Compatible：新 Build ID 加入既有 compatibility set，存量 workflow 可平滑迁到新 worker（向后兼容的小改动/bug fix）。
• Pinned：新 Build ID 与旧集合不兼容，新 worker 只跑新启动的 workflow；旧 workflow 留在旧 worker 上直到自然结束。
• task queue 按 workflow 的 pinned version 把任务路由给匹配的 worker；匹配不到就排队等旧 worker 上线，避免回放错乱。

Patch API：在既有 workflow 上做安全变更

• workflow.Patched(patchID) -> bool：返回 true 表示该 workflow 是在新代码（已带 patch）上启动的；false 表示 patch 之前启动的存量 workflow 在回放。据此分支判断走新逻辑还是旧逻辑。
• workflow.Deprecated(patchID) -> bool：返回 true 表示 patch 已废弃（旧分支已从代码中移除），用于过渡期结束后清理。

标准五步生命周期：

1. 部署带 Patched("p1") 的新代码；存量 workflow 见 false 走旧路，新启动见 true 走新路。
2. 等待所有存量 workflow 自然结束。
3. 把旧分支删掉，Patched 换成 Deprecated 作为哨兵，防止遗留存量误走新路。
4. 再等一段时间兜底。
5. 把 Deprecated 调用也删掉。

来源：Temporal Worker Versioning https://docs.temporal.io/workers/worker-versioning；Patching Workflow Code https://docs.temporal.io/workflows/patching-workflow-code

5.4 持久化状态的 Schema Migration

checkpoint 不仅是"恢复点"，还是"代码契约的物化"。升级时要处理：

• Backward compatibility：新代码能读旧 checkpoint（最常见）。
• Forward compatibility：旧代码能读新 checkpoint（滚动回滚/双向并存时需要）。
• Schema registry：给 checkpoint 打 schema 版本号，反序列化时按版本路由到迁移函数。

通用做法：

1. checkpoint 结构 = { schema_version, agent_code_version, model_version, prompt_version, payload }。
2. payload 用支持增删可选字段的格式（protobuf / avro / pydantic with defaults），避免硬删字段。
3. 写"迁移链"：migrate(v1→v2)、migrate(v2→v3)，反序列化时按 schema_version 顺序应用。
4. 任何"破坏性语义变更"不原地迁移，而是新建独立 workflow / 独立 state key。

5.5 滚动升级时的 Drain（两阶段）

1. 停止接新任务：worker 收到 SIGTERM 立即停止 poll task queue；新 workflow 自然路由到新 deployment。
2. 处理在跑任务：短任务让它跑完；长任务"先 checkpoint 再迁移"。

关键实现细节：

• SIGTERM 优先于 SIGKILL：K8s 默认 terminationGracePeriodSeconds=30s，长程任务务必调大；drain 必须在 grace period 内完成或显式持久化。
• on-shutdown checkpoint：信号处理里对所有 in-flight invocation 做一次显式 checkpoint，写完才退出。
• 原子写：checkpoint 用 CAS / versioned write，避免写一半被 SIGKILL 留下损坏状态。
• 再入安全（idempotent resume）：另一实例拉起后从 checkpoint 续跑，已完成步骤不重复副作用。
• 队列退回：无法续跑的，把任务 nack 回队列由别的消费者重做（at-least-once + 幂等）。
• Zombie 防护：lease/heartbeat，worker 死了 lease 过期后由调度器再分配。

5.6 代码版本与 Prompt / 模型版本耦合（"model-dependent state"问题）

这是 LLM agent 比传统 workflow 多出来的一层：

• v1 agent 跑到一半，中间状态存着 v1 模型生成的 thought / tool_args / pending plan。
• 升级到 v2 prompt + v2 模型，直接续跑会出错：v2 prompt 期望的字段、推理风格、工具协议可能和 v1 留下的不一致。
• 即使字段兼容，语义不兼容：v1 的 “plan: A then B” 在 v2 模型眼里可能不是最优甚至错误的前置。

推荐做法：

1. 把 model+prompt 版本绑定到 workflow pinned version（Build ID 里直接包含模型版本，如 worker-v3+gpt-5.2+prompt-r7）。
2. 存量 workflow 不跨模型版本续跑：要么在旧模型上跑完，要么显式"重启点"——把当前状态快照成输入，启动新 workflow 实例走新模型。
3. checkpoint 元数据强制校验：反序列化时若 model_version 不在当前 worker 兼容集内，宁可 fail-fast 也不静默续跑。
4. Prompt 变更走 Patch API 模式：用 Patched("prompt-r7") 分支，旧存量走旧 prompt，新启动走新路径，等 drain 再清理。
5. 避免 v1 状态污染 v2：scratchpad / memory / open tool handles 等模型相关字段，跨版本时优先"清洗 + 重写"而非直接复用。

5.7 系统对照

系统	版本锚定单位	旧实例如何继续在旧代码上跑	schema 迁移责任方	drain 机制
Temporal	Build ID + Version Set + Pinned	按 pinned version 路由；Patch API 分支过渡	用户自管	worker 退出即停接新 task，server 端 workflow 不丢
Restate	Deployment ID，invocation 级 pin	invocation 启动时绑定，生命周期不切	用户自管（additive）	restate deployments drain
Inngest	无原生 invocation 级 pin	resume 时调当前端点（总跑新代码）	step ID 稳定性	无内建 drain，靠 step ID + 新函数并存
DBOS	workflow version + 显式 migration	按 version 路由/迁移	提供 migration API	进程退出后从 checkpoint 自动恢复
LangGraph	checkpoint + 部署侧 revision	checkpointer 持久化，新进程续跑	用户自管	靠 platform revision + sleep 唤醒

来源：Restate Deployments https://docs.restate.dev/operate/deployment/；Inngest Functions multiple versions https://www.inngest.com/docs/functions/multiple-versions；DBOS Versioning https://docs.dbos.dev/；LangGraph Persistence https://langchain-ai.github.io/langgraph/concepts/persistence/

---

6. 统一范式：五要素如何咬合成一个整体

上述五个问题并非孤立——它们共享同一组底层原语。把它们咬合起来，就是长程 Agent 的运行时契约：

五要素的咬合关系：

1. 状态续跑提供"任意时刻可恢复"——是其他四要素的基石。
2. 记忆分层解决"恢复后上下文从哪来"——working memory 从 checkpoint 重建，长期记忆从外部 store 召回注入。
3. 上下文工程解决"主线程不爆不漂"——子 agent 隔离 + 文件系统外部记忆 + re-injection，让主上下文恒定体积。
4. 分布式部署解决"在哪恢复"——任意无状态 worker 都能从 checkpoint 续跑，沙箱隔离不可信代码。
5. 优雅升级解决"换代码后还能恢复"——pinned version 让存量黏在旧三元组上跑完，新启动走新三元组，schema 只增不删 + 迁移链。

三元组绑定（本文核心主张）

把长程 Agent 升级建模为三个正交版本号同时绑定到一个 invocation：

pinned_version = (code_build_id, prompt_version, model_version)

• 存量 invocation 整个生命周期锁在这个三元组上，保证确定性回放 + 语义兼容。
• 新启动走新三元组。
• schema 走"只增不删 + 显式迁移链"。
• drain 走"SIGTERM → 停接新 → on-shutdown checkpoint → 等存量自然结束 → 移除旧 deployment"。

这是当前公开实践中最一致的一套范式。

---

7. DeepThink 平台落地建议

结合 DeepThink 作为"企业级自主 Agent 自进化平台"的定位，给出落地路线：

7.1 运行时底座选型

• 以 Postgres 为唯一真相源（仿 DBOS）：checkpoint、step、memory 状态同事务写入，天然 exactly-once 与 crash-safe；pgvector 兼顾长期语义召回。
• 引入 durable execution 引擎（Temporal 或 Restate）作为长程任务编排底座，LLM 调用一律封装为 Activity / ctx.run，回放只读不重算。
• 三层架构对齐火山引擎 AgentKit 范式：AI 云基础设施（计算/存储/网络/隔离）+ Agent 基础设施（Identity/Runtime/Evaluation/Sandbox/Memory/Knowledge）+ 应用层（Agent 构建/管理/治理）。

7.2 记忆与上下文工程

• 采纳 MemGPT/Letta 分层 + 三因子检索作为记忆子系统骨架。
• 主线程恒定体积策略：todo.md + state.json + scratchpad.md 三件套，主上下文只放指针 + 最近 K 轮 + 白名单约束。
• 子 Agent 隔离上下文（DeepThink 已有 sub-agent 能力），探索类大消耗 token 任务 fork 子 agent 只回传结论。
• 每子任务带 checkpoint，退出条件客观验证（呼应 Supervisor Agent 范式）。

7.3 集群与沙箱

• worker pool 无状态化 + K8s 自动伸缩 + scale-to-zero（idle）。
• Agent 代码执行一律进 microVM 沙箱（firecracker），按 tenant_id 隔离 + 配额计量。
• lease/heartbeat 防 zombie；长程任务用并发槽位控制而非对单任务加机器。

7.4 升级治理

• checkpoint 结构强制带四元元数据：{schema_version, code_build_id, prompt_version, model_version}。
• 实现 Pinned + Patch 范式：存量 pinned 旧三元组，新启动走新三元组。
• schema 只增不删 + 显式迁移链；破坏性变更另起新 workflow type。
• drain：调大 terminationGracePeriodSeconds，SIGTERM 触发 on-shutdown checkpoint，原子写，再入安全。
• model/prompt 跨版本不静默续跑：fail-fast 或显式重启点。

7.5 可观测性

• 全链路 trace（每个 step、每次 LLM 调用、每次 checkpoint 写入、每次 memory paging）。
• time-travel 能力（从任意 checkpoint 重放，便于事故复盘）。
• 长程任务的"漂移监测"：定期校验当前行为与初始目标/约束的对齐度。

---

8. 结论

长程任务 Agent 的工程化生存术，本质是把分布式系统、操作系统、工作流引擎几十年沉淀的成熟范式，嫁接到 LLM 这个新的非确定性执行单元上。其核心可凝练为一句话：

把上下文当寄存器、把记忆当虚拟内存、把执行当事件溯源、把升级当版本绑定——长程 Agent 的可靠性不在模型有多聪明，而在运行时有多工程化。

五个问题的统一答案：

问题	解
状态终端续跑	事件溯源 + 确定性回放 + LLM 调用封装为非确定性边界
记忆分层	OS 式 paging：working→episodic→semantic→archival，三因子检索
千步上下文不丢	主线程恒定体积 + 子 agent 隔离 + 文件系统外部记忆 + re-injection
分布式集群	控制面/数据面/沙箱面三层，worker 无状态化 + microVM 隔离 + lease
优雅升级	(code+prompt+model) 三元组 pinned，新启动走新版本，schema 只增不删

DeepThink 作为面向企业客户的 AI Infra，把这五要素工程化落地，正是从"工具使用者"走向"超级智能体孵化器"的必经之路。

---

参考文献

工作流引擎 / Durable Execution

1. Temporal — What is Durable Execution. https://docs.temporal.io/encyclopedia/what-is-durable-execution
2. Temporal — How Temporal Works. https://docs.temporal.io/encyclopedia/how-temporal-works
3. Temporal — Fault Tolerance. https://docs.temporal.io/encyclopedia/fault-tolerance
4. Temporal — Workflow Determinism. https://docs.temporal.io/workflows/determinism
5. Temporal Blog — Build AI Agents with Temporal. https://temporal.io/blog/build-ai-agents-with-temporal
6. Temporal — Worker Versioning. https://docs.temporal.io/workers/worker-versioning
7. Temporal — Patching Workflow Code. https://docs.temporal.io/workflows/patching-workflow-code
8. Restate — Durable Execution. https://docs.restate.dev/concepts/durable-execution
9. Restate — The Journal. https://docs.restate.dev/concepts/journal
10. Restate — Journal Entries. https://docs.restate.dev/references/journal-entries
11. Restate — Deployments. https://docs.restate.dev/operate/deployment/
12. DBOS 文档. https://docs.dbos.dev/
13. Cadence 仓库. https://github.com/uber/cadence
14. Windmill Flows. https://www.windmill.dev/docs/flows/flows_intro
15. Inngest — Durable Execution. https://www.inngest.com/docs/functions/durable-execution
16. Inngest — Functions multiple versions. https://www.inngest.com/docs/functions/multiple-versions

LLM Agent 框架

17. LangGraph — Persistence. https://langchain-ai.github.io/langgraph/concepts/persistence/
18. LangGraph — Memory / Store. https://langchain-ai.github.io/langgraph/concepts/memory/
19. LangChain Blog — Checkpointing long-running agents. https://blog.langchain.dev/checkpointing-long-running-agents
20. CrewAI — Memory. https://docs.crewai.com/concepts/memory
21. AutoGen — Memory blog. https://microsoft.github.io/autogen/blog/2024-06-20-Memory

记忆系统

22. MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560). https://arxiv.org/abs/2310.08560
23. Generative Agents (arXiv:2304.03442). https://arxiv.org/abs/2304.03442
24. CoALA — Cognitive Architectures for Language Agents (arXiv:2309.02427). https://arxiv.org/abs/2309.02427
25. A Survey on the Memory Mechanism of LLM-based Agents (arXiv:2404.13501). https://arxiv.org/abs/2404.13501
26. Reflexion (arXiv:2303.11366). https://arxiv.org/abs/2303.11366
27. Voyager (arXiv:2305.16291). https://arxiv.org/abs/2305.16291
28. A-MEM (arXiv:2502.14024). https://arxiv.org/abs/2502.14024
29. mem0. https://github.com/mem0ai/mem0
30. Zep / Graphiti. https://github.com/getzep/graphiti
31. Letta. https://www.letta.com

上下文工程

32. Anthropic — Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
33. Anthropic — Context engineering for AI agents. https://www.anthropic.com/engineering/context-engineering-for-ai-agents
34. Anthropic — How to do time-consuming tasks with agents. https://www.anthropic.com/engineering/how-to-do-time-consuming-tasks-with-agents
35. Anthropic — Building Effective Agents. https://www.anthropic.com/research/building-effective-agents
36. Anthropic — How we built our multi-agent research system. https://www.anthropic.com/engineering/multi-agent-research-system
37. Claude Code — Sub-agents. https://docs.claude.com/en/docs/claude-code/sub-agents
38. Lost in the Middle (arXiv:2307.03172). https://arxiv.org/abs/2307.03172

基准与评测

39. τ-bench (arXiv:2406.12045). https://arxiv.org/abs/2406.12045
40. SWE-bench (arXiv:2310.06770). https://arxiv.org/abs/2310.06770
41. LongBench (arXiv:2308.14508). https://arxiv.org/abs/2308.14508
42. AgentBench (arXiv:2308.03668). https://arxiv.org/abs/2308.03668
43. WebArena (arXiv:2307.13854). https://arxiv.org/abs/2307.13854

集群 / 沙箱 / 行业

44. Ray / Ray Serve. https://github.com/ray-project/ray
45. claude-code-ultimate-guide — sandbox isolation. https://github.com/FlorianBruniaux/claude-code-ultimate-guide
46. 火山引擎 AgentKit / Agent Ready 基础设施（FORCE 大会 2026-06）.

来源可信度声明：本文素材来自五路并行联网检索智能体与本机联网检索的综合。部分子代理在受限网络环境下 WebFetch 被安全策略拦截，所列 URL 多为各项目长期稳定的官方文档入口与 arXiv 论文地址，建议读者在浏览器逐一打开复核最新版本与子路径后再作为工程决策依据。