会话恢复才是 Harness 的本职：能 resume、能 fork，才谈得上生产

很多团队把 Harness 理解成「能调用工具的聊天框」。真正把 Agent 嵌进产品之后，最先暴露的缺口通常不是工具不够多，而是会话断了接不上：进程重启、终端关掉、审批弹窗超时、人切走十分钟，回来发现上下文没了，只能从头再跑。

Codex App Server 把 Thread 做成可持久化容器，能 start、resume、fork、archive；DeepSeek Harness 的 ACP 服务也把 session/load、session/resume、session/list 写成一等协议。这不是产品彩蛋，而是 Harness 相对框架和 MCP 真正该交付的能力。

一、恢复不是重放聊天记录

把历史消息再喂一遍，看起来像 resume，其实经常已经偏了。缺的是三类状态：

• 决策状态：当前目标、未完成、禁止事项
• 副作用状态：文件改到哪一版、哪些命令已经跑过
• 权限状态：哪些动作已被批准、哪些仍在闸门后

少任何一类，恢复后的 Agent 都会用笃定语气继续，但脚下的世界已经变了。这就是长任务里最贵的一类故障：看起来在工作，其实在空转。

二、Thread 模型为什么比「一个 session id」更稳

把一次任务看成 Thread，里面是若干 Turn。Turn 可以因审批、超时、用户打断而停住；Thread 本身还在，下次从边界接着跑。

fork 的价值在分叉而不是复制闲聊：同一个已完成的前置工作，可以派生出两条路径做对比，而不必把已付过的上下文成本再付一遍。archive 则是承认：有些会话该被冻结，而不是永远占着热路径。

跨进程恢复（session/load）还要求有一份只追加的事件日志。没有事件流，所谓恢复只能靠猜「当时大概说到哪」。

三、客户端该守的最小生命周期

嵌产品时，更稳的做法通常不是 fork 一份 Core，而是固定一版经过验证的 App Server / ACP 进程，差异化放在界面、业务上下文、MCP 工具和审批规则里。

最小闭环也很朴素：

1. initialize 协商能力（是否支持 load / resume / list）
2. thread/start 或 session/new 创建容器
3. turn/start 提交输入，持续消费流式更新
4. 遇到审批就停，客户端回决定后 Turn 才继续
5. 进程挂了，用 resume / load 按 cwd 或 session id 接回来

协议 Schema 至少要覆盖：初始化、恢复、派生、审批拒绝、工具超时、Turn 中断、历史迁移。这些测过，升级才不会把线上会话变成孤儿。

四、恢复必须配检查点，否则会把错误一起恢复

resume 只保证「还能说话」，不保证「还在正确的世界里」。文件检查点、幂等工具、独立验收，都是恢复的配套。

一个可用的自检是：关掉聊天窗口，只留日志、进度文件和验收结果，你能不能判断任务成败、该从哪一步接。如果不能，系统还停留在聊天，而不是交付。

五、落地顺序

1. 先把会话落盘成可按 id 加载的 Thread，而不是只存在内存
2. 再把审批、取消做成 Turn 边界，而不是直接杀掉整个会话
3. 然后补文件检查点和外置进度，避免恢复后文件世界不一致
4. 最后才做 fork 和多会话列表

没有前三步，fork 只会把混乱复制一份。

结语

MCP 不负责记住你跑到哪，框架的 checkpointer 也不自动等于业务可恢复。Harness 的本职之一，就是让任务在中断之后仍然接得上：会话在、副作用可核对、审批可续上。能 resume、能 fork，生产才从「演示能跑」变成「无人值守也敢跑」。