最近长期使用 Codex 一类 AI 编程工具时，我碰到一个挺具体的问题。
前一天，我用 AI 完成了一个比较完整的功能排查和修改。
第二天，我想继续修改这个功能。
我知道昨天做的是什么，也记得大概讨论过什么，甚至还记得其中某个关键词，但真正重新定位到昨天那个任务并继续下去，并没有我想象中那么自然。
这件事情后来让我意识到：
找回历史聊天，可能并不等于继续原来的任务。
对于一个复杂 AI 编程任务来说，真正有价值的往往不只是聊天文本，还包括：
- 需求是怎么一步步变化的
- 用户纠正过 AI 哪些理解偏差
- 哪些方案已经试过并失败
- 修改过哪些文件
- 执行过哪些命令
- 得到过哪些运行结果
- 当前任务停在什么位置
- 下一步原本准备做什么
如果重新打开一个新会话，然后通过搜索、RAG、摘要，把历史信息重新灌进去，它当然可以恢复一部分上下文。
但我越来越觉得：
Context reconstruction 和 Task continuation 可能不是同一件事情。
前者更像是在重建：
关于过去发生了什么的知识。
后者更像是在恢复：
一个仍然存在、并且可以继续执行的任务状态。
1. Conversation 可能不是长期 AI 任务最合适的抽象
现在很多 AI 产品的基础抽象仍然是：
Conversation
└── Message
└── Message
└── Message
这个模型用于聊天完全合理。
但当 AI 开始承担越来越复杂的任务，例如：
- 多轮代码修改
- 调试
- 文件操作
- 命令执行
- 多步骤排查
- 工具调用
- 多 Agent 协作
问题就开始出现。
因为任务状态实际上被隐含在一长串 Conversation 中。
用户第二天回来之后，需要从过去的对话里重新推导：
昨天做到哪里了？
为什么这么改？
哪个方案已经失败？
哪些文件已经被修改？
运行结果是什么？
下一步应该做什么？
也就是说，Conversation 在同时承担“交流记录”和“任务状态容器”两个角色。
我开始怀疑：
对于长期 AI 任务来说，这两个概念是不是应该被拆开？
2. Session persistence ≠ Task continuation
一个直接的反问可能是：
这不就是 Session 保存吗？
我觉得未必。
Session persistence 解决的通常是：
这个会话还在。
但 Task continuation 真正需要回答的是：
这个任务现在是什么状态？
两者之间可能存在明显差异。
比如一个任务过程中可能经历：
需求 A
↓
方案 1
↓
运行失败
↓
用户纠正
↓
方案 2
↓
修改 file1 / file2
↓
执行命令
↓
得到结果
↓
发现新问题
↓
任务暂停
如果只保留 Conversation，我们仍然需要从文本中重新推导：
Current State = ?
而如果 Task 本身是一个独立资源，它就可以显式拥有状态。
3. RAG ≠ Execution continuity
另一个很自然的方案是：
把历史记录向量化，需要的时候 RAG 回来不就行了？
RAG 非常适合解决：
过去有没有出现过与当前问题相关的信息？
但我觉得它和 Task continuation 的目标仍然不完全一样。
RAG 更像：
Retrieve relevant knowledge
Task continuation 更像：
Restore execution state
一个系统即使能准确搜索到：
昨天我们讨论过方案 B。
也未必意味着它知道：
方案 B 已经执行到了第 4 步，
fileA 已修改，
fileB 还没修改，
测试 2 已失败，
下一步原本应该重新跑测试 3。
所以我现在倾向于认为：
RAG ≠ Task State
Chat History ≠ Execution State
Session Persistence ≠ Task Continuation
4. 如果 Task 成为一等资源呢？
于是我开始想：
AI 平台是不是可以把 Task 本身作为一种一等资源，而不是仅仅把任务隐含在 Conversation 里？
例如：
Task
├── task_id
├── state
├── artifacts
├── decisions
├── execution_results
├── checkpoints
├── continuation_context
└── relationships
这里的重点不是字段本身。
而是抽象层级发生变化。
今天可能是：
User
↓
Conversation
↓
Messages
未来对于复杂 Agent 系统，也许会变成：
User
↓
Task
├── Conversation
├── State
├── Artifacts
├── Execution
└── Checkpoints
Conversation 只是 Task 的一个组成部分。
而不是 Task 本身。
5. resume task X
如果这个抽象成立，那么用户第二天回来的动作也会发生变化。
现在更像：
打开历史会话
↓
重新阅读
↓
重新告诉 AI 昨天发生了什么
↓
AI 重建上下文
↓
继续工作
理想情况下，也许可以变成：
resume task X
系统恢复：
Task identity
Current state
Relevant artifacts
Past decisions
Execution results
Checkpoint
Continuation context
然后继续执行。
这里我说的“恢复状态”，并不是要求保存模型私有的内部推理过程。
我更关心的是用户和系统共同形成的、可观察和可管理的任务状态，例如：
- 用户需求
- 文件变化
- 工具调用
- 执行结果
- 检查点
- 已尝试方案
- 当前阶段
- 可续接上下文
6. 为什么我觉得这个问题可能会越来越明显
早期 ChatGPT 主要还是聊天工具。
一个会话几十轮，重新开一个窗口问题不大。
但 AI Coding Agent 正在快速把单个任务拉长。
一个任务可能持续：
几个小时
↓
一天
↓
几天
↓
甚至更长
同时它操作的对象也越来越多：
代码
文件
终端
浏览器
数据库
API
外部工具
多个 Agent
这时候“历史聊天”与“任务本身”的差异就会越来越明显。
尤其未来多 Agent 系统里，一个 Task 甚至可能同时包含：
Agent A 的执行状态
Agent B 的验证状态
Agent C 的研究结果
共享 Artifact
Task-level checkpoint
Human approval
如果所有东西最后仍然只能还原成一串 messages，我感觉系统复杂度会越来越高。
7. 当然，这里面还有很多问题
这个想法目前只是一个 Draft，我并不认为它已经成立。
实际上还有很多明显问题需要回答。
比如：
Task 到底应该保存多少状态？
全部保存肯定不现实。
哪些状态值得长期保存，哪些只是临时上下文？
Task state 会不会越来越大？
如果一个任务持续几个月，状态膨胀怎么办？
需要：
Checkpoint
Compaction
Summary
Artifact GC
吗？
Task 和 Conversation 怎么划分？
一个 Conversation 可以对应多个 Task 吗？
一个 Task 可以跨多个 Conversation 吗？
Task continuation 和 Workflow checkpoint 有什么区别？
现有的：
- LangGraph checkpoint
- Agent memory
- workflow persistence
- session persistence
是否已经能够覆盖这个问题？
如果可以，那么是否根本不需要平台级 Task 抽象？
隐私和权限怎么办？
长期任务可能包含：
代码
文件
终端输出
数据库结构
业务数据
用户决策
如果 Task 长期存在，就必须有清晰的数据生命周期和权限模型。
8. 我现在真正想验证的问题
我现在更想验证的并不是：
我设计的这个方案是不是正确。
而是：
“长期 AI 任务的原生续接”到底是不是一个值得独立讨论的问题？
也就是说：
Context Reconstruction
和：
Task Continuation
到底是不是两个不同层级的问题？
如果现有的：
Session + RAG + Memory + Checkpoint
已经能够完整解决，那么这个构想可能就是多余的。
但如果未来 AI Agent 真正开始承担长期、复杂、跨工具的任务，我感觉 Task 可能会逐渐从一个隐含概念，变成一个需要显式建模的系统资源。
我把目前的思考整理成了一份非常早期的 Draft：
Native Stateful AI Task Continuation
GitHub：
目前只是个人构想，不是成熟方案。
非常欢迎直接挑战。
尤其想听听大家对下面几个问题的看法：
- 这是不是已经被现有 checkpoint / memory / session 机制解决了？
- Task 有没有必要成为平台级抽象？
- Conversation + RAG 是否已经足够？
- Task state 最小应该保存什么？
- AI Coding Agent 的任务到底应该如何定义生命周期？
如果这个问题本身就是伪需求，也欢迎直接拍砖。
一句话总结：
我开始怀疑，未来 AI Agent 真正需要保存的，可能不只是“我们聊过什么”，而是“这个任务现在进行到了哪里”。
