核心 GUIDE
Asynchronous Long-running Work
超过一次请求生命周期的任务需要显式 Job Identity、Durable State、Cancel 与 Result Retrieval；把 HTTP 或模型连接一直保持打开并不是长任务架构。
核心心智模型
Long-running Work 应被建模成围绕 Durable Job 的 State Machine，而不是“特别长的同步请求”。Caller 提交任务、观察 Progress、可以安全取消或重试，并在之后读取经过验证的 Result。
为什么重要
Agent 任务越来越可能持续数十分钟甚至数小时，包含 Research、Tool Execution、Approval 与 Retry。如果生命周期绑定在一个 Connection 上，部署、网络中断或用户离开页面都会变成状态丢失或重复执行。Asynchronous Contract 能让 Ownership、Progress 与 Recovery 变得可观察。
01
拆开 Submission、Execution 与 Observation
提交时先创建 Durable Job ID，保存请求操作和 Idempotency Key，再让 Queue/Scheduler 独立执行。Worker 按边界写 Checkpoint，发布粗粒度 Status，并只在定义好的安全点响应 Cancel。Result Retrieval 应明确区分 Terminal Success、Terminal Failure、Cancelled 与 Still Running。
02
示例：仓库迁移运行四十分钟
Coding Agent 迁移大型 Monorepo 时，UI 立即得到 Job ID，而不是维持一个无限延长的 Streaming Request。Worker 每完成一组 Dependency 就更新 Checkpoint；部署不会抹掉 Progress；用户可在最终写入前取消。之后重新连接时读取的是同一个 Durable Job，而不是新建一次迁移。
常见失败模式
- 把超长 Timeout 当成 Durable Job State 的替代品。
- Client 一重连就创建重复任务。
- UI 提供 Cancel 按钮，但 Worker 没有定义安全取消点。
工程启发
- 每个 Long-running Operation 都要有 Durable Job Identity。
- 在 Protocol Boundary 明确定义 Retry、Resume 与 Cancel 语义。
- Progress 应来自可验证 State，而不是模型猜测式 Narration。
关键结论
- 01长任务需要 Job Protocol。
- 02Connection Lifetime 与 Task Lifetime 应相互独立。
- 03Durable State 让 Recovery、Cancellation 与 Deduplication 成为可能。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。