为什么 Agent 任务不能只存聊天记录？
教学案例：页面关闭时，登录超时任务正在跑测试。用户重新打开后，系统必须知道补丁是否已经写入、测试是否结束、审批是否仍在等待，不能只恢复几条聊天气泡。
可以把 Thread 理解为任务文件夹，Turn 是用户发起的一轮工作，Item 是搜索、读取、审批、Diff、测试等具体事件。客户端负责展示，执行端保存真实状态。
这些名称来自 Codex App Server 的公开产品模型。其他产品可能叫 Session、Run、Step；重要的是三层责任，不是背名字。
在 Codex 的协议里，Thread 保存一段持续工作，Turn 表示一次用户驱动的任务推进，Item 是消息、工具执行、审批或 Diff 等原子事件。这套建模让客户端能重连并恢复一致时间线；其他 Agent 产品可能使用不同名称和协议。
为什么不能只保存聊天消息？
任务线程（Thread）保存长期任务，工作回合（Turn）保存一次用户驱动的工作单元，事件项（Item）保存按序发生的消息、工具、审批与结果。客户端只是渲染这些事实。
- 事件项 01（Item）用户消息
- 事件项 02（Item）搜索工具调用
- 事件项 03（Item）搜索结果
- 事件项 04（Item）写入审批
- 事件项 05（Item）改动对比
- 事件项 06（Item）测试结果
- 客户端 A（Client A）
收到事件 128 后断线
- 运行环境（Runtime）
任务继续等待审批，没有重复启动
- 客户端 B（Client B）
提交事件项 04 的批准结果
- 任务服务（App Server）
持久化事件 129–135 与终态
- 客户端 A（Client A）
用游标 cursor=128 补取缺失事件并恢复
恢复结果：两个客户端看到同一工作回合（Turn）；工具没有重复执行。
先用嵌套关系看懂三个层级
一个 Thread 可以容纳多次 Turn，例如用户先要求修复登录超时，下一轮再要求解释 Diff。一个 Turn 内有搜索、读取、审批、编辑、测试和最终交付等 Items。
Thread 负责长期身份、历史和恢复；Turn 负责一次目标、预算与终态；Item 负责具体事件的类型、输入、状态与产物。三层都需要稳定 ID，才能在重复消息和断线后识别同一事实。
官方事实查看这一结论的依据与边界＋
OpenAI App Server 公开使用 Thread、Turn、Item 建模 Codex 任务，并通过双向 JSON-RPC 传递事件和审批。
OPUnlocking the Codex harness: App Server官方工程文章 · 核验 2026-07-14跟着事件走完一次修复
任务开始、搜索完成、写入待批准、批准完成、补丁写入、测试失败或通过、最终交付，都是不同事件。每条事件都带所属 Turn 和明确状态。
增量事件只负责流式更新同一个 Item；在明确终态到来之前，它随时可能转向失败。客户端必须等待明确终态，不能看到第一段输出就把任务标成成功。
官方事实查看这一结论的依据与边界＋
OpenAI App Server 文档说明 Turn 会产生流式 Item 更新，并允许服务端主动请求审批或补充输入；具体名称属于 Codex 产品协议案例。
OPUnlocking the Codex harness: App Server官方工程文章 · 核验 2026-07-14断线恢复依赖服务端事实与幂等
网页关闭时，测试可能仍在运行。重连后，客户端从最后已见事件继续补齐；未完成审批保持等待，已经写入的补丁和已经结束的测试不能重复执行。
外部写入还需要幂等键，即使网络导致请求重发，业务系统也只产生一个结果。事件去重解决界面一致性，动作幂等解决真实副作用，两者不能互相替代。
本站推演查看这一结论的依据与边界＋
本站的事件 cursor、动作幂等与断线恢复验收是基于服务端事实源整理的产品设计，不是 OpenAI 公布的固定恢复算法。
OPUnlocking the Codex harness: App Server官方工程文章 · 核验 2026-07-14协议事件与诊断日志各管各的
协议事件要稳定、可重放、面向产品状态；内部日志可以更细、更频繁，用于工程诊断。把所有底层日志暴露给客户端会造成强耦合，也会让用户被无关噪声淹没。
兼容性同样是产品需求。新客户端可以理解新 Item，旧客户端至少应忽略未知字段并继续显示已有时间线。
本站推演查看这一结论的依据与边界＋
本站对协议事件、诊断日志与新旧客户端兼容的区分，是依据 App Server 双向协议做出的产品推演。
OPUnlocking the Codex harness: App Server官方工程文章 · 核验 2026-07-14有术语没听懂？在这里用人话再看一遍7 个词＋
- Thread
- 可跨多轮工作持续存在的任务与会话容器；这里主要采用 Codex App Server 案例命名。
- Turn
- 一次用户发起、拥有目标、预算和终态的工作单元。
- Item
- Turn 内可持久、可流式、带生命周期的原子事件。
- Delta
- 同一个 Item 在完成前逐步发送的增量内容。
- Cursor
- 客户端记录最后已处理事件位置，用于断线后补发缺失事件。
- 事件重放
- 根据持久事件重新构建客户端状态，而不是依赖先前页面内存。
- 服务端事实源
- 任务真实状态由执行和持久化所在的服务端决定，客户端不自行猜测。
本章依据与证据边界3 份原始材料＋
下面补充本章的其他依据，并说明每份材料能证明什么、不能证明什么。
查看全部一手材料与源码证据 3 条
这份材料说明 Codex App Server 如何以双向 JSON-RPC/JSONL 协议把同一 Harness 暴露给 CLI、IDE、桌面与 Web 客户端。它定义 Thread、Turn、Item 及流式事件、审批暂停、持久化和重连语义，是课程讲解 Agent 客户端协议与多端复用的直接实现依据。
证据边界：官方文档不能单独证明未公开内部实现、长期可靠性或真实用户收益。固定提交源码 · 核验 2026-07-23Hermes Agent async delegation and turn finalizationNous Research这段源码说明后台 Subagent 的完成结果进入共享队列，并在 Agent 空闲时形成新的 Turn，而不是插进正在进行的工具序列；这样可以保持消息角色顺序与 Prompt Cache 稳定。这是 Hermes 的实现选择，不是行业统一协议。
证据边界：固定提交只能证明该版本的公开实现，不能代表现行私有产品、真实任务质量或行业统一架构。官方产品实现 · 核验 2026-07-14Hermes Agent SessionsNous Research当前文档说明 Hermes 将完整消息与工具历史保存在 SQLite，会话可恢复和跨端检索，但恢复历史不等于把所有旧字节持续塞回模型上下文。
证据边界：持久会话不自动保证恢复无副作用，也不是隐私删除或长期语义记忆。