作者：刘军
目前，我们可以借助 Agent 框架如 Langchain/AgentScope 等、编码工具如 Codex、Qoder 等构建自己的智能体应用，利用它们提供的 Session 保存与恢复能力保持对话的连续性。但对于需要长期稳定运行在云端的任务，仅仅恢复会话状态还不够，进程崩溃、网络中断或服务重启，都可能发生在模型调用、工具执行或结果保存的过程中。恢复之后，Agent 不仅要记得之前聊过什么，还要知道哪些工作已经完成、哪些仍在等待、哪些结果尚未确认，才能从正确的位置继续，避免错误的重复执行和不必要的资源消耗。
这正是 Durable（持久可恢复执行） 要解决的问题：将任务进度、调用意图和执行结果可靠地保存下来，在模型调用、工具执行等关键环节建立明确的恢复边界。即使原来的进程退出或执行实例被替换，任务也能依据已保存的状态，复用已确认的结果、核实未完成的操作，并继续推进。会话恢复让对话保持连续，Durable 则进一步让任务执行保持连续。
本文使用一个具体的用户任务示例“向五位客户发送通知邮件”，解释为什么保存聊天记录还不够，再以 AgentScope 构建的 Agent 为例，展开任务状态、持久提交和故障恢复的通用设计，最后结合 Alibaba Cloud AgentCore 已有的 Harness 托管与节点恢复能力，讨论共享状态、可靠调度及 Brain / Hands 分离如何支撑更完整的长期托管服务。
Durable 是什么：让任务跨越进程的生命周期
从“能运行”到“中断后仍能推进”
假设用户给助手一个任务：根据已经确认的名单和正文，向五位客户发送通知邮件，并汇总发送结果。
Agent 生成工具调用，工具开始逐封发送。前三封已经确认完成；第四封刚被邮件服务接受，本地还没保存结果，进程就崩溃了。第五封尚未开始。
新进程启动后，真正困难的问题并不是如何再次调用模型，而是如何判断第四封邮件的状态：
- 重新发送，可能让客户收到两封。
- 直接跳过，可能漏发。
- 把整个任务重做，会重复前三封。
- 让用户说一句“继续”，也不会凭空补回丢失的执行事实。
Durable 要把这些判断所依赖的事实保存在进程之外，并定义恢复规则。 恢复程序先读取已提交进度，再决定复用结果、继续等待、核实原操作，还是启动尚未执行的工作。
这不要求一个进程永远在线。进程可以退出，任务可以等待，执行资源可以释放；只要状态仍可访问、兼容的执行者能够被唤醒，工作就有继续推进的依据。
它想保证什么
持久执行通常需要建立四项能力：
1. 输入不因进程退出而消失。 已受理任务有稳定身份，客户端重试可以关联原任务。
2. 已确认工作可以复用。 保存完整的模型结果、工具结果和必要状态，恢复时不必重做已经确认的步骤。
3. 未完成工作有明确去向。 正在执行、等待子任务、等待时间和结果不确定，分别采用对应的恢复方式。
4. 执行过程可以被重新观察。 用户断线后能重新查看进度和结果，观察连接不必一直陪着任务运行。
这里的恢复位置是已提交的逻辑边界。它可能是一次模型响应、一个工具调用、一个任务阶段，也可能是开发者明确保存的一段业务进度。它不是旧进程的某条机器指令，也不是模型推理过程中尚未完成的内部计算。
因此，Durable 不等于“永不失败”，也不自动意味着外部动作恰好执行一次。服务持续不可用、凭据失效、工具结果无法确认时，任务仍可能进入失败或需要处理的状态。它要让失败留下可解释、可恢复的事实。
哪些场景最需要它
当任务持续时间长于一次连接、一次请求或一个实例的寿命时，Durable 的价值会变得明显：
本地交互通常把用户、终端、工作目录和 Agent 进程放在一起，用户可以观察异常并决定如何继续。云上后台服务则会遇到实例替换、滚动发布、连接中断和资源回收，接管任务的实例也未必是原来的实例。任务越长，越不能假设同一个进程和同一条连接会陪它走到结束。
在本地，持久执行可以帮助任务跨越应用重启；在云上，它还需要配合可访问的持久存储、执行调度和环境重建。把本地程序搬进一台有磁盘的 VM，只解决了运行位置和部分文件保留问题，任务恢复仍需单独设计。
为什么很多 Agent 有会话历史，却没有解决任务恢复
普通 Agent 循环把进度留在了调用栈里
常见 Agent 的执行流程很直观：
收到输入 → 请求模型 → 得到 tool call → 执行工具
→ 得到 tool result → 再请求模型 → 输出答案
在一次正常执行中，程序知道当前执行到哪里，因为函数调用栈、局部变量和 Promise 都还在。对于交互式 Coding Agent，这种方式也便于实时展示输出、接受用户修正和继续对话。
但进程崩溃后，这些信息消失了。剩下的会话文件可能只记录：
user: 向五位客户发送这份通知
assistant: send_batch_emails(recipients, body)
tool result: 尚未写入
这份记录足以说明模型提出了什么，却不能证明工具内部完成了什么。send_batch_emails 是一个调用，内部发送了三封、四封还是五封，对外层循环仍可能是不可见的。
一个支持会话恢复的 Agent 产品就是容易理解的例子：它可以用 JSONL 保存带身份与父子关系的会话记录，支持恢复上下文和会话分支。这种能力很有用，但会话记录本身并不自动包含任意业务工具内部的执行检查点。
这里讨论的是以交互循环和会话持久化为主的执行方式，并不意味着所有 Agent 框架都缺少 Durable 能力。部分框架已经引入持久工作流、任务状态机和检查点；关键要看实际使用的执行路径提供了哪些保证。
恢复对话与恢复执行，需要不同的契约
对于以交互为中心的框架，恢复会话的主要目标是让模型重新获得上下文，让用户能够继续工作。工具通常被抽象为一个接收参数、返回结果的函数；函数内部怎样访问服务、保存中间进度，属于工具实现的职责。这种接口容易扩展，却没有要求工具公开“如何从中断中恢复”。
Durable 则需要更强的契约：任务由谁持有执行权，状态在哪个时刻生效，工具是否允许重放，等待怎样跨越重启，代码升级后如何解释旧状态。它会同时影响调度、存储和工具接口，无法只靠给现有循环加一个保存 messages 的开关完成。对于仍在使用普通函数工具的应用，接入持久框架后，也需要继续设计工具内部的恢复边界。
最大的缺口，是外部事实与本地记录之间的空隙
即使把每封邮件拆成独立工具调用，仍然存在一个无法靠聊天记录消除的窗口：
有调用意图、没有结果，只能说明“可能执行过”。请求可能根本没有发出，也可能已被接受但响应丢失，还可能像图中一样已经收到回执，只差最后一次保存。
所以，一套可靠机制必须同时处理两件事：内部状态如何提交，外部动作如何确认。 前者可以通过事务和持久任务解决；后者还需要业务系统提供幂等标识、原操作查询，或者明确的补偿与人工处理路径。
为什么常见补丁还不够
问题也不在于 JSONL 天生不可靠、SQLite 天生可靠。文件和数据库都可以承载持久协议，差别在于保存了什么、何时确认生效，以及崩溃后如何解释它。
要从这些补丁走向 Durable，需要把原本藏在调用栈中的执行进度，变成能够存储、验证和重新调度的数据。
如何把 Agent 执行过程变成可恢复的状态
从 Agent 循环走向持久执行内核
AgentScope 的 HarnessAgent 将模型推理、上下文、工具和会话管理组织在一起，并通过 Durable 执行内核管理整个运行过程。模型生成、工具调用和业务流程都是持久任务，由任务状态驱动 Agent 循环。 上下文、任务阶段和业务数据在同一套提交协议下变化，进程重启后从已保存的阶段继续。
HarnessAgent 管理模型与工具的协作，Session 管理持久状态与提交顺序，任务调度器推进可运行的阶段，Storage 保存执行数据。这几层共同保证：输入有身份，步骤有检查点，等待有条件，结束有结果。
下面以 AgentScope 展开这套机制。其核心是与具体框架无关的持久执行协议，同样适用于其他 Agent 框架。
图中的模型和工具调用发生在提交事务之外。调度器根据已提交状态选择可执行任务，任务处理器运行一个阶段，再提交结果和下一状态。存储、调度与观察因此围绕同一条状态变化序列协作。
Session 保存的不只是消息，还有任务与业务状态
AgentScope 使用 Session 作为统一的状态与提交范围，一个 Session 可以包含多个 Conversation。Conversation 描述一段对话，Session 则同时管理这段对话背后的输入、任务、业务文档和执行关系。
Entry 保留已经发生的记录，Document 保存后续阶段需要读取的数据，Task 决定下一步可以做什么。例如，“第四封邮件已收到回执”是一项业务事实；“回执已经写入对话”和“父任务可以继续汇总”则是需要一起推进的执行状态。
AgentScope 从持久记录中重新构建上下文：按有效的会话范围读取消息、模型响应及对应工具结果，再应用已保存的压缩或上下文调整。内存中的 messages 列表是这些状态的运行时表示；它消失后，恢复程序仍能重建继续推理所需的信息。
AgentScope 的 Document 是带类型和版本的结构化状态，除了业务数据，也保存 Agent 配置、待处理输入、运行中的模型与工具，以及使用量等信息。文档修改通过提交产生增量操作，并在需要时保存完整基线；恢复时使用基线与后续增量重建有效状态。
应用可以注册自己的 Document 和 Task，例如邮件计划、审批阶段或数据处理进度。这些扩展状态与内置任务使用同一套提交机制，无须把所有中间数据都塞进提示词或工具输出。
原子提交，让记录、文档与任务一起生效
如果先写“工具完成”，再保存工具结果，中间崩溃就会留下一个没有结果的完成记录。反过来，先保存结果、再推进任务，也可能让接管者误以为还需要执行。
AgentScope 的一次 Commit 同时支持追加 Entry、修改 Document、创建或推进 Task，以及更新 Submission。以第四封邮件为例，同一批写入可以包含：
追加工具结果 Entry
更新邮件计划 Document 中的发送回执
将发送 Task 置为完成
更新会话中的工具运行状态
提交按以下顺序进行：
取得 Session 的提交顺序
→ 在事务草稿中准备关联变化
→ 校验并冻结写集合
→ Storage 原子保存
→ 采纳已持久化的新状态
→ 更新视图、通知等待者、调度后续任务
AgentScope 串行化同一 Session 内的状态提交，模型请求和工具执行则在提交事务之外推进。调度器可以运行多个已就绪任务，但这些任务的状态变化仍然按序生效。一次外部调用持续十分钟，不会因此占据十分钟的状态提交事务。
普通提交只有持久化后才被内存状态和观察视图采纳。Storage 确认写集合持久化后，Session 一次性采纳新状态，再通知调度器与观察者。准备失败时丢弃草稿；如果存储异常发生在已经持久化之后，已提交变化仍然有效，当前 Session 停止运行，重新打开时以实际保存的状态恢复。
AgentScope 同时支持受限的延迟提交，用于正在生成的文本或运行中的工具输出等可丢失进度。只有满足约束的已有进度文档修改才能延迟保存；一旦提交包含新消息、任务阶段、输入受理或其他关键变化，就按普通提交立即持久化。后续提交读取这些文档时，也会将尚未保存的变化一并纳入持久边界。这样既能控制高频写入，也不会让任务依据尚未确认的事实继续执行。
这一原子性覆盖的是 Harness 管理的数据。 发邮件、访问外部数据库或执行 shell 命令仍然是外部动作，需要单独定义确认和恢复规则。
Task 把调用栈中的进度变成显式阶段
普通函数依靠程序执行到第几行来决定下一步。AgentScope 的 Task 保存任务类型与版本、输入、所属会话或父任务，以及当前状态和 checkpoint。恢复程序用任务类型找到处理代码，用 checkpoint 确定从哪个阶段开始。
Task 的生命周期包含以下状态：
例如第四封邮件正在等待查询确认，其状态可以表示为：
{
"kind": "send-notice",
"version": 1,
"input": {
"operationId": "notice-2026-10-customer-4",
"recipient": "customer-4",
"bodyRef": "approved-notice-body"
},
"state": {
"status": "sleeping",
"until": 1793289600000,
"checkpoint": {
"phase": "confirm"
}
}
}
这条记录同时保存了原操作身份、下一阶段和唤醒时间。等待期间没有需要保留的函数调用或 Promise；时间到达后，AgentScope 调度器重新调用 confirm 阶段。下一阶段需要的数据进入输入、checkpoint 或 Document，阶段之间通过这些持久数据交接。
恢复从已保存阶段的入口重新执行，不会跳回崩溃前的某一行。 一个阶段如果包含多个不可重复的外部动作，就应继续拆分阶段，或者为这些动作保存可确认的操作身份。单纯在函数内部增加更多 await，不会增加持久恢复边界。
模型生成与工具调用，都由持久任务推进
AgentScope 的 Agent 循环由模型生成任务和工具任务组成。一次输入被受理后，先保存 Submission；输入进入当前运行时，写入用户 Entry 并创建模型生成任务。模型提出工具调用时，创建对应工具任务，并保存生成任务的等待关系。
提交输入
→ 保存 Submission 与用户 Entry
→ 创建模型生成 Task
prepare：准备上下文与模型配置
request：保存请求阶段，再调用模型
tools：保存模型响应，创建工具 Task 并持久等待
工具 Task：保存调用意图 → 执行 → 提交结果
工具结束：读取已提交结果，创建下一轮生成 Task
→ 得到最终回答，保存 Entry 并结束 Submission
模型返回 tool call 后，AgentScope 将模型响应、要创建的工具任务和“接下来等待这些任务”的状态一起提交。提交后即使进程退出，重启时仍然知道应该执行哪些调用，不需要让模型重新猜测上次计划。
模型生成任务自身包含 prepare、request、retry、poll 和 tools 等阶段。准备阶段固定上下文位置、模型选择和必要请求选项；请求阶段发生中断时，AgentScope 将它作为一次未完成尝试处理。已保存的部分文本保留为中断记录，不作为完整响应驱动工具执行。
重试次数、退避时间和下一阶段都进入任务状态。对提供异步响应句柄的模型，AgentScope 保存句柄与查询时间，恢复后继续查询原请求。持续在同一阶段崩溃的任务受到重启次数限制，达到上限后记录失败原因并结束，避免每次启动都再次触发同一个错误。
工具结果全部就绪后，生成任务读取原工具记录与结果，完成本轮收尾，再交接给下一轮生成。这里的“继续推理”由持久任务之间的关系决定，原来的函数调用栈已经不再是唯一依据。
普通工具：先记录意图，再决定中断后能否重放
AgentScope 保留工具接收参数、返回结果的使用方式，并由内置工具 Task 管理它的持久生命周期。工具 Task 区分两个阶段：
- call 阶段： 解析工具、校验参数、执行调用前检查，然后保存最终参数、重放策略和执行意图。提交成功后执行工具，最后提交结果。
- execute 阶段： 作为“意图已保存、结果未确认”的恢复入口，判断能否使用保存的参数重新执行。
正常执行在 call 阶段提交意图后直接调用工具；恢复进入 execute 阶段时，AgentScope 按外部动作可能已经发生处理。只有调用时保存的策略和恢复时的工具策略均为 safe，才使用已经确认的参数重新执行，不重新运行可能改变参数的调用前处理。否则保存 interrupted 结果和已提交的部分输出，让后续流程处理不确定性。
完整结果提交时，将结果 Entry、工具运行文档和 Task 的结束状态一起保存。父任务据此判断该工具已经结束，并取得同一份结果。
原子提交调用意图与 execute 阶段
→ 在事务外执行工具
→ 原子提交工具结果与任务结束状态
工具声明“可安全重放”，是工具作者对业务行为的承诺，框架不会自动让发送邮件变得幂等。工具返回明确错误与执行状态无法确认也应分别记录：前者已经取得一次调用的结果，后者还需要核实原动作。
如果只是把一个黑盒 send_batch_emails() 注册成普通工具，执行内核能知道这次调用中断，却不知道内部完成了哪几封邮件。更细的恢复需要把工具自身改造成多阶段任务。
自定义任务：把五封邮件变成可接续的业务流程
AgentScope 通过自定义任务把工具内部的业务阶段纳入同一套持久执行机制。邮件助手注册一个发送任务类型，使用 Document 保存已经确认的收件人计划，为每封邮件建立子任务，并在同一次 Commit 中保存子任务身份和父任务的等待状态。
每个子任务分别处理发送意图、原操作查询、等待与结果确认。父任务的等待不是内存中的 Promise.all，而是一条持久关系：等哪些 Task、采用什么汇合策略、结束后进入哪个阶段。
AgentScope 提供 allSettled 和 failFast 两种等待策略：前者等待全部依赖任务结束后汇总，后者在子任务失败时请求其他所属子任务停止，并等待它们收尾。父任务即使已经决定自己的结果，只要仍有需要收尾的所属子任务，就先处于 completing，等它们结束后才成为真正的终态。进程重启后，调度器从这棵持久任务关系中继续等待或收尾。
为了处理“已经发送但回执未保存”的窗口，本例增加一项明确前提：邮件服务支持按稳定操作标识幂等受理，并能查询原操作。 每封邮件的操作标识在外部调用前保存，并绑定固定的收件人和正文。
在这项任务中，Agent 负责理解用户要求、形成计划和生成汇总，AgentScope 的任务状态机负责发送阶段的持久接续。幂等受理和原操作查询由邮件服务提供，任务处理器据此确认外部动作并提交结果。
现在恢复前面的故障：
子任务创建与父任务等待一起提交，解决的是“进程退出后还记不记得这五项工作”；每封邮件的业务操作标识和查询阶段，解决的是“外部动作发生后如何核实”。两层机制配合，才能恢复到某一封邮件。
如果邮件服务既不支持幂等，也无法查询，第 4 封仍需保留不确定状态并交由业务核实。持久状态机提供明确的处理位置，不会凭空创造外部系统没有保存的事实。
重新打开 Session，调度原任务继续执行
应用使用 AgentScope 时，先配置模型、工具和任务定义，打开持久 Storage，再取得 Session 中原有的 Conversation。输入提交后返回 Submission 身份，应用可以等待结果，也可以稍后重新查询。
进程重启后，主要流程是：
重新打开同一 Storage
→ 恢复 Conversation、Entry、Document、Task 与 Submission
→ 检查任务类型、版本和阶段处理器
→ 启动任务调度器
pending / 中断的 running：从已保存阶段重新进入
waiting：重新检查依赖任务
sleeping：继续等待原时间点，已到期则运行
completing：检查所属子任务是否已经收尾
terminal：直接提供保存的结果
→ 每次状态变化仍通过同一条原子提交序列
AgentScope 通过 Registry 注册任务、工具和扩展定义。存储中保存状态、身份和定义版本，处理代码由 Registry 提供。重新打开时，内核核对任务类型和版本，运行必要的状态迁移；任务定义缺失或无法迁移时，保留原状态并报告阻塞原因，兼容定义就绪后再继续调度。
同一次业务输入重试使用相同的 requestId，AgentScope 返回原 Submission，避免再次创建工作。重新等待一个 Submission，只恢复观察；关闭当前 Harness 停止本次驱动并保留未完成任务。业务取消先持久记录取消意图，再通知活动阶段停止，等待所属子任务结束，最后提交任务终态。
因此，恢复既不要求重放整个 Agent 循环，也不等于再次提交原提示词。它从持久任务图中寻找尚未完成、当前可运行的阶段，复用已经确认的结果，并继续原工作。
Storage、观察视图与宿主唤醒各自负责什么
AgentScope 通过 Storage 接口原子保存和读取执行记录，存储实现与任务语义分离。Document 使用增量操作与定期完整基线保存，任务记录保存完整的当前状态；重新打开时据此恢复有效状态，无须序列化整个进程。应用可以按部署需要选择本地持久存储，或接入平台提供的远程后端。
AgentScope 的会话视图、文档视图和任务图订阅提交后的变化，呈现输入受理、模型输出、工具进度、依赖关系和最终结果。重新连接时先取得当前视图，再接收后续变化。允许延迟保存的预览是明确的例外，不作为恢复的唯一依据。只读打开的 Session 提供查询与观察，不启动任务调度，也不获得写权限。
AgentScope 通过 resume() 启动任务调度器，通过唤醒信息告诉宿主“现在有工作可运行”以及“下一次应在何时继续”。常驻宿主使用本地定时器推进到期任务；云端宿主通过 onWake 接收变化，持久安排下一次唤醒，在进程被回收后重新打开 Session 并调用 resume()。调度器负责判断任务是否可运行，宿主负责提供实际执行机会。
多实例运行还需要共享存储、执行权隔离和兼容环境。任务在 sleeping 或 waiting 中不占据一个活动阶段调用，但正在运行的真实进程和外部工具仍有自己的生命周期。接回这些外部工作，需要下一部分的平台托管与工具执行机制配合。
AgentScope 的 Durable 执行内核让 Entry、Document 和 Task 共同描述一项工作的事实与未来，并通过原子 Commit 保持一致。Agent 循环由持久状态机驱动，宿主与平台则把可运行的工作交给实际执行资源。框架负责“从哪里继续、怎样继续”，平台负责“状态长期保存在哪里、由哪个实例继续”，两者通过存储与唤醒契约连接。
阿里云 AgentCore 的 Durable Agent 设计理念
已有的托管能力，是 Durable 向平台延伸的基础
阿里云 AgentCore 是面向 AI Agent 的云端托管平台，提供 Harness 托管、会话管理、任务中断续接与节点恢复能力，帮助开发者将智能体应用稳定运行在云上。
AgentCore 已经提供托管 Harness 的能力，支持任务中断后继续执行，也支持从指定的已保存执行节点恢复。这让 Agent 的一次运行拥有可以重新接续的状态，业务任务不再只存在于一次交互或一个运行进程中。
托管 Harness（OpenHarness）保留底层内核的推理、上下文和工具使用方式，由平台衔接其状态保存与恢复能力。这里的恢复节点，是内核及其适配机制能够保存和解释的执行位置；节点恢复不会自动撤销已经发生的外部业务动作。不同内核开放的状态与控制接口，也决定了能够恢复到多细的粒度。
在这一基础上，更细粒度的 Durable 可以进一步进入模型生成、工具调用、结果应用和长时间等待等环节。前文的任务状态机回答“这个阶段如何继续”，平台则需要回答“状态保存在哪里、何时安排继续、由哪个实例执行”。
Brain–Hands 分离与更完整的 Agent as a Service，是在已有托管能力之上继续建设的方向。下面从架构设计角度讨论 Durable 如何融入这些方向，以及它们如何与现有的 Harness 托管共同使用一套持久基础。
图中分别展示已有托管能力、后续演进方向，以及两者可以共同依托的状态、调度与环境抽象。它们之间的联系是持久执行契约：既能承接原生 Harness 的恢复节点，也能承接深入内核后的任务阶段和工具交接状态。
共同的 Session Store，连接原生状态与平台执行事实
平台统一的是状态的保存、提交和读取契约。Agent 框架和运行时仍然管理自己的 context、messages 和 checkpoint 格式，适配层将这些原生状态与平台能够理解的任务身份、工具意图、等待条件和结果应用位置连接起来。
Session Store 为这种协作提供共同的持久基础：记录状态版本、保留检查点与结果引用、返回可查询的提交回执，并在恢复时提供一致的状态集合。它与可靠调度、事件流衔接，使任务既能被接续，也能被业务应用重新观察。
这些状态可以分别存储，通过身份与版本建立关系。较大的原生状态和结果可以保存为不可变对象，由提交记录引用；工作区文件由相应环境承载。平台不要求所有内容进入同一份聊天日志。
接入不同框架时，适配层负责声明可保存和恢复的边界。能够参与模型完成、工具授权和结果应用提交的框架，可以提供更细的恢复控制；主要开放会话恢复接口的框架，则按其原生能力确定恢复范围。共同存储可以承接不同载荷，但恢复旧 Session 仍需要匹配的内核和状态格式。
因此，共同的 Session Store 可以同时支撑托管 Harness 与更深度的 Durable 设计。统一存储契约可以减少重复建设，各条接入路径仍然保留自己的恢复语义与粒度。
将恢复节点延伸为执行过程中的一致性边界
从指定节点恢复，进一步走向细粒度 Durable，关键在于定义清楚：哪些事实必须一起保存，保存成功后才允许发生哪些后续动作。
以一次工具调用为例，只有保存“模型想调用工具”还不够。恢复所需的信息还包括 Harness 的继续位置、固定的工具参数、原生调用与平台任务之间的关联，以及等待结果的条件。将这些信息放入同一个一致性边界，才能让恢复者明确判断：调用是否已获准执行、结果属于哪次调用、下一步应当等待还是继续推理。
这一设计可以把第三部分的原子 Commit 延伸到平台协作中。内核提交自身可恢复的状态，平台同时保存对应的执行事实；后续派发以已确认的提交为依据。涉及独立存储与消息系统时，可以将待派发意图与状态一起持久保存，再通过可重试的投递机制完成交接，避免状态已经推进、后续工作却没有执行依据。
这里需要分别表达三个进度：调用已被受理、工具已经完成、结果已经进入 Harness 上下文。 它们之间可能间隔很久，也可能在任何一次交接时发生故障。将进度分别保存，恢复才能定位缺失的一步，而不是重新执行整段流程。
对托管 Harness，这些边界需要结合内核已有的恢复接口建立；对能够深入控制执行过程的内核，则可以直接把模型完成、工具授权和结果应用设计成持久阶段。两种方式共享状态基础，但并不因此自动拥有相同的控制深度。
Brain–Hands 分离：让推理与工具拥有各自的生命周期
Brain–Hands 分离可以看作上述持久交接机制的进一步展开：Brain 管理推理与上下文，Hands 管理工具的实际执行，两者通过已保存的调用身份、状态和结果协作。
这种分离的核心，是让“等待工具”成为可持久表达的状态。Brain 提交调用和等待条件后，理论上就可以释放本次执行资源；工具由独立的执行机制继续推进。结果具备继续条件时，再由兼容的 Brain 实例读取原状态、应用原结果。整个过程不再要求最初的推理进程始终等待。
下面以一个长时间运行的工具为例，推演这种架构中的状态交接：
在这一设计中，工具完成通知只是继续执行的触发器，真正决定下一步的是持久状态。调度需要能够重新发现尚未完成的恢复安排，并约束当前有效的执行者，防止旧实例与接管实例同时推进同一份状态。这样，工具等待、结果交付和推理恢复才不会分别绑定在某个进程或某条连接上。
回到五封邮件的例子，这种分离让推理实例在发送期间退出也不影响已交接的工作；逐封恢复的粒度则仍然来自第三部分的业务任务设计。前三封的回执可以复用，第四封按原操作身份核实，第五封从尚未执行的阶段继续。Brain–Hands 分离提供独立接续的条件，业务检查点与外部系统的确认能力共同决定能够恢复多细。
如果工具本身不支持查询原操作或识别重复请求，分离架构也不能自动消除“动作已经发生、结果尚未确认”的窗口。这类不确定性仍需成为任务状态的一部分，由相应业务规则处理。
Environment 让已保存状态拥有继续执行的条件
无论使用已有的节点恢复，还是进一步采用 Brain–Hands 分离，重新读取状态都只是恢复的一部分。新的执行实例还需要兼容的内核、依赖、模型与
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
By Liu Jun
At present, we can build our AI agent applications using the Agent framework, such as Langchain/AgentScape, coding tools such as Codex, Qoder, etc., and use the Ssession that they provide to preserve and restore continuity of dialogue. However, for tasks that require long-term stability in the cloud, it is not enough to simply restore the session state, and the collapse of the process, the disruption of the network or the resumption of services may occur in the course of model calls, tool execution or the preservation of results. After recovery, Agent not only remembers what he talked about, but also what has been done, what is still waiting, and what has not yet been confirmed in order to continue from the right place, avoiding erroneous duplication and unnecessary resource consumption.
This is precisely the problem to be addressed by Durable (persistent resumption of implementation): the reliable preservation of mission progress, mobilization intent and implementation results, and the establishment of clear restoration boundaries at key points such as model calls, tool implementation, etc. Even if the original process is withdrawn or the execution instance is replaced, the task can re-use the confirmed results, verify the incomplete operation and proceed according to the stored state. The sessions resumed to keep the dialogue continuous, while Durable further kept mandate implementation continuous.
This paper uses a specific user job example, "Send Notification Mail to Five Clients" to explain why it is not enough to keep chat records, and then, using the example of Agent constructed by AgentScope, to develop a universal design for mission status, persistent submission and failure recovery, and finally to discuss how shared status, reliable scheduling and Brain/Hands separation can support a more complete long-term hosting service in conjunction with the existing HanessCore hosting and node resilience.
What is Durable?
From "capable" to "push after break"
It is assumed that the user will give the assistant a task: send a notice message to five clients based on the confirmed list and text and summarize the results of the transmission.
Agent generates tool call, and tools begin to be sent from one to the next. The first three have been confirmed completed; the process collapsed as soon as the fourth was accepted by the mail service and the local results were not preserved. The fifth has not yet begun.
The real challenge after the start of the new process is not how to call the model again, but how to judge the status of the fourth mail:
- Retransmittal, probably get the client two.
- Just skip, probably leak.
- Redo the whole mission, repeat the first three.
- Let the user say “continue” and do not make up for the lost performance.
Durable is to preserve the facts on which these judgements are based outside the process and define the rules of restoration. The resumption process will read the submitted progress before deciding whether to reuse the results, continue to wait, verify the original operation or start the work that has not yet been performed.
This does not require that a process be permanently online. Processes can exit, mandates can wait and implementation resources can be released; as long as accessable and compatible implementers are awakened, there is a basis for moving forward.
What is it trying to guarantee?
Sustained implementation usually requires four capacities:
Inputs do not disappear as a result of process exit. The accepted tasks have a stable identity and the client retry can be associated with the original tasks.
The work has been confirmed as reusable. Complete model results, tool results and state of necessity need not be re-established when restored.
3. There are clear directions for non-completion. Implementation is ongoing, waiting for subtask, waiting time and uncertain results, with corresponding recovery approaches.
4. The implementation process can be revisited. Users are able to re-examine progress and results after disconnection, and the observation connection does not have to run with the mission.
The position here is the logical boundary that has been presented. It may be a model response, a tool call, a mission phase, or a clearly maintained business schedule by the developers. It is not a machine instruction from the old process, nor is it an internal calculation that has not been completed in the model reasoning process.
So, Durable does not mean "never fail" and does not automatically mean that external action happens to happen once. The mission may still be in a state of failure or need to be addressed when the service continues to be unavailable, evidence lapses and the results of the tool cannot be confirmed. It wants to leave the failure open and recoverable.
Which scenes need it most?
When the duration of the mission is longer than the lifetime of a connection, a request or an example, the value of Durable becomes clear:
Local interactions usually bring together users, terminals, working directory and Agent processes, and users can observe anomalies and decide how to proceed. The cloud backstage service is subject to case substitution, rolling publish, disconnection and resource recovery, and the example of taking over tasks is not necessarily the original example. The longer the task is, the more impossible it is to assume that the same process and the same connection will accompany it to the end.
At the local level, sustained implementation can help to reboot missions across applications; on the cloud, it will also need to be accompanied by accessible durable storage, movement control and environmental reconstruction. Moving local programs into a VM with a disk resolves only the operational position and part of the file retention, and the task restoration still needs to be designed separately.
Why is it that Agent has a history of conversation without resolving the resumption of the mission?
Normal Agent loop keeps the progress at the call house. Lee.
The common Agent execution process is intuitive:
Received Input Query Request Model Query Got tool to call Quest
♪ Get tool result ♪
In a normal execution, the program knows where the current execution is, because the function calls the stack, the local variable and Promise. For interactive dialogue, this also facilitates real-time presentation of outputs, acceptance of user corrections and continued dialogue.
But when the process collapsed, the information disappeared. The remaining session files may only be recorded:
User: Send this notice to five clients
assistant: send_batch_emails(recipients, body)
tool result: not written yet
This record is sufficient to show what the model proposes, but does not prove what is done within the tool. Send batch emails is a call that sends three, four or five internally, and the outer circle may still be invisible.
An Agent product that supports the resumption of sessions is an easy example: It can use JSONL to keep records of sessions with paternity and support the restoration of context and session branches. This capability is useful, but the recording of sessions does not automatically include implementation checkpoints within any operational tool.
The discussion here is about an interactive cycle and the sustainability of the conversation, which does not mean that all Agent frameworks lack Durable capabilities. Some of the frameworks have been introduced into the permanent workflow, mission status machines and check points; the key depends on the assurance provided by the actual implementation path.
Restoring dialogue and resuming implementation requires different compacts
For the interactive-centric framework, the main objective of the resumed session was to allow the model to regain context and enable users to continue working. Tools are usually abstracted as a function of receiving parameters and returning results; how services are accessed within the function, and how intermediate progress is saved, is the function of the tool. The interface is easily extended, but the tool is not required to disclose “how to recover from the interruption”.
Durable needs a stronger contract: who holds the enforcement authority for the task, when the status is effective, whether the tool is allowed to be replayed, how to cross the restart, and how to explain the old state when the code is upgraded. It will affect movement, storage and tool interfaces simultaneously and cannot be completed by adding a switch to the existing cycle to save messageages. For applications that still use the generic function tool, access to the durable framework also requires continued design of the restoration boundary within the tool.
The biggest gap is between external facts and local records.
Even if each e-mail is to be broken to stand alone tool call, there is still a window that cannot be removed by chat:
With the intent to call and without results, it can only be said that “may have been carried out”. The request may not have been sent at all, it may have been accepted but the response lost, and it may have received a reply, as in the figure, for the last time.
So a reliable mechanism must deal with two things at once: how the internal state is presented and how external movements are confirmed. The former can be addressed through services and protracted missions; the latter also require operational systems to provide markings, such as tungsten, original operational queries, or clear compensation and manual processing pathways.
Why isn't the usual patch enough?
The problem is not that JSONL was born unreliable, SQLite was born reliable. Documents and databases can carry durable agreements, depending on what is kept, when it is confirmed to be effective, and how it is interpreted after a collapse.
To move from these patches to Durable, progress in implementation, which was originally hidden in the Call Stack, needs to be translated into data that can be stored, validated and reprogrammed.
How to turn Agent execution into a state of recovery
Moving from Agent Cycle to Sustainable Implementation Nuclear
The HarnessAgent of AgentScope brings together model reasoning, context, tools and session management organizations and implements the kernel management process through Durable. Model generation, tool call and business processes are persistent tasks and are mission-driven Agent cycles. context, the mission phase and business data changed under the same submission protocol and the process resumed from the storage phase.
The HarnessAgent management model and tool collaboration, the Session Management Endurance and Submission Order, the operational phase of the task scheduler, and the Manual to save the execution data. These layers of assurance are shared: the entry is identified, the steps are checked, the conditions are awaited and the end results are obtained.
The mechanism is set out below in AgentScope. Its core is a durable implementation agreement unrelated to a specific framework, which applies equally to other Agent frameworks.
The model and tool call in the figure are outside the submission services. The scheduler selects the task according to the status of submission, and the task processor runs a phase before submitting the results and the next state. Storage, movement and observation therefore collaborate around the same state change sequence.
The session saves not just messages, but tasks and operations.
AgentScope uses a session as a unified status and submission range, and a session can contain multiple submissions. Conversion describes a dialogue, while Session manages the input, tasks, business files and execution relationships behind the dialogue.
Entry keeps records of what has happened, Document keeps data that needs to be read at the subsequent stage, and Task decides what next step can do. For example, “fourth e-mail has received a reply” is an operational fact; “return has been included in the dialogue” and “the father's mission can continue to be aggregated” is the state of implementation that needs to be advanced together.
AgentScope re-engineers context from a permanent record: Read messages, model responses and corresponding tool results in a valid session range and apply saved compression or context adjustments. The memory list of messageages is a run-time indication of these states; after it disappears, the resumption process can still rebuild the information needed to continue the reasoning.
AgentScope's Document is a structured state with a type and version that saves information such as Agent's configuration, pending input, active models and tools, and usage, in addition to business data. Document modifications generate incremental operations by submission and preserve the complete baseline as necessary; the baseline and subsequent increments are used for recovery to re-establish the effective state.
Apply to register your own documents and Task, e.g. mail plan, approval phase or data processing progress. These extensions use the same set of submission mechanisms as the built-in tasks, and it is not necessary to place all intermediate data in prompt or tool output.
Atom Submission, for recording, document and task
If the tool is completed and the result is saved, the intermediate crash will leave an inconclusive completion record. In turn, saving results and moving tasks forward may lead to the mistaken assumption by the receiver that implementation is still needed.
A Commit from AgentScope supports the addition of Entry, changes to Document, creation or promotion of Task, and updates of Submission. In the case of the fourth e-mail, the same writing could include:
Add Tool Results Entry
Sendback for update of mail schedule
Send Task to Finish
Update tool running status of session
The submission follows:
Get Session order of submission
• Preparing related changes in draft services
Check and freeze the writing collection
→Storage Atom Save
~ To adopt a new, durable state ~
• Update view, notify waiters, schedule follow-up tasks
AgentScope serializes the status submission in the same session, while model requests and tool execution advance outside the submission. Schedulers can run multiple missions that are ready, but the status changes are still in order. An external call lasted 10 minutes, which did not result in a 10-minute referral status.
Ordinary submissions are accepted in memory status and observation view only after they have been sustained. Following the confirmation that the writing collection is lasting, the Board adopts the new status once and informs the dispatcher and the observer. Discards the draft when you are ready to fail; if the storage anomaly occurs after a protracted process, the submitted change is still valid, the current Session ceases to operate and resumes with the actually saved status when it is reopened.
AgentScope also supports limited late submission for lost progress such as the text being generated or the tool output being run. Only changes to an existing progress document that fulfils the constraint can be delayed; once a submission contains new information, the task phase, input acceptance or other key changes, it is made permanent on a regular basis. Changes that have not been saved will also be incorporated into the persistent boundary when these documents are subsequently submitted for reading. This would allow for the control of HF writing and would not allow the mandate to continue on the basis of unconfirmed facts.
This atomic cover data managed by Harness. The sending of mail, access to external databases or execution of shell commands is still external and requires a separate definition of confirmation and restoration rules.
Task, turn progress in the call house into a visible phase
The normal function depends on which line the program executes to determine next step. Task for AgentScope saves tasks of type and version, input, session or parent, as well as current status and checkpoint. Resumes the task type to find the processing code and checkpoint to determine which stage to start.
The life cycle of Task includes the following:
For example, the status of the fourth e-mail, which is awaiting confirmation of a query, can be expressed as:
{
"kind": "send-notice",
"version": 1,
"input": {
"operationId": "notice-2026-10-customer-4",
"recipient": "customer-4",
"bodyRef": "approved-notice-body"
},
"state": {
"status": "sleeping",
"until": 1793289600000,
"checkpoint": {
"phase": "confirm"
}
}
}
This record preserves the original operational identity, the next phase and the wake-up time. There are no functions to keep during the waiting period to call or Promise; after time has arrived, the AgentScope Scheduler is called back to confirm. The data required for the next phase enters the input, checkpoint or document, and crosses these long-lasting data between phases.
Resumes the re-entry from the saved stage and does not jump back to a line before the crash. A phase containing multiple non-repeatable external actions should continue with the split phase or preserve identifiable operational identities for those actions. Adds more await simply within the function and does not increase the lasting restoration of the boundary.
Model generation and tool call are driven by persistent missions.
AgentScope's Agent Cycle consists of model generation and tool tasks. Once the input is accepted, save the Submission; enter into the current operation, write to the user Entry and create the model generation task. The model creates the corresponding tool task when tool call is proposed and saves the waiting relationship for the resulting task.
Submit Input
Save Submission with User Entry
Create Model Generation
Prepare: prepare context and model configuration
request phase, call the model
tools: save model responses, create tools Task and wait for a long time
Tools: Save call intent → Execute → Submit results
End of tool: Read the submitted results and create the next generation
→ Final answer, save Entry and end Submission
After the model returns the tool call, AgentScope submits the model response, the tool tasks to be created, and the status of the "waiting for these tasks next " status. Even after submission, even if the process is out, the restart will know which calls should be carried out and there will be no need for the model to re-guess the last plan.
The model generation task itself consists of the stages of prepare, request, retry, Poll and tools. Fixed context position, model selection and necessary request options for the preparatory phase; AgentScop treated it as an incomplete attempt when the request phase was interrupted. Part of the saved text is kept as an interrupted record and is not executed as a complete response driver.
The number of retrys, the time of retreat and the next stage are all in mission status. For the model that provides the stept response handle, AgentScope saves the handle and query time and continues to search for the original request after recovery. Mandates that continue to collapse at the same stage are limited in the number of times to restart, to record the cause of failure and to close after reaching the ceiling, and to avoid triggering the same error once and for all.
When the tool results are ready, the task is generated to read the records and results of the original tool, finish the current round and turn over to the next generation. The “continuing reasoning” here is determined by the relationship between persistent missions, and the original function is no longer the sole basis.
Normal tool: Record intent before deciding whether to replay after interruption
AgentScope preserves the receiving parameters of the tool, how to use the return result, and manages its lasting life cycle with the built-in tool Task. Tools Task distinguishes between two stages:
- Call Stage: Parsing tool, checking parameters, performing pre-recall check, then saving final parameters, replay strategy and execution intent. Submission of a successful implementation tool, with final results.
- Execute phase: as a re-entry point for “intentions saved, results not confirmed” to determine whether re-execution can be effected using the parameters of preservation.
Normal execution calls the tool directly after submitting the intent at the call stage; when returning to execute, AgentScope may have been processed by external action. Re-executes using the identified parameters only if the strategies saved at the time of call and the tools used at the time of recovery are safe, without re-runing the pre-reassignment process that may change the parameters. Otherwise, the results and parts of the output that have been submitted will be saved to allow the subsequent process to address uncertainty.
When the full result is submitted, the result Entry, the tool run document and the end state of Task are saved. Based on this, the father ' s mission judged the tool to be over and obtained the same result.
Atomic submission intent and execute phase
• Out-of-service implementation tool
• Atomic submission tool results and end-of-mission status
The tool states that “safe playable” is the author's commitment to business behaviour, and the framework does not automatically make sending e-mail, etc. Returning the tool to a clear error and failure to confirm the performance status should also be recorded separately: the former has obtained the result of a call, while the latter also needs to verify the action.
If only a black box is registered as a regular tool, the inside nuclear power knows about the interruption of the call, but does not know what mail has been completed internally. A more detailed recovery would require the transformation of the tool itself into a multi-phased task.
Custom tasks: transforming five e-mails into business processes that can be carried over
AgentScope integrates the operational phases within the tool into the same set of durable implementation mechanisms through self-defined missions. The mail assistant registers a sending task type, uses Document to save the confirmed recipient plan, creates subtask for each mail, and saves the subtask identity and the waiting status of the parent mission in the same Committee.
Each subtask handles the sending intent, the original operation query, the waiting and confirmation of results. The waiting for the father's mission is not a memory Promise.all, but a lasting relationship: what is waiting for, what kind of convergence strategy, what stage after the end.
AgentScope offers allSettled and failFast waiting strategies: the former waits for full reliance on the end of the mission, and the latter asks the rest of the subtask to stop when subtask fails and waits for their closure. Even if the father's mission has already determined its own outcome, as long as there are still subtasks that need to be closed, he will be in the middle of the process until they are finished. When the process is restarted, the dispatcher continues to wait or close from this permanent mission relationship.
In order to deal with the window that has been sent but has not been saved by a reply, a clear premise has been added to this case: the mail service supports the processing of the SAL and so on, and is able to query the original operation. The operational identifier for each e-mail is saved before an external call is made and a fixed recipient and body is bound.
In this task, Agent is responsible for understanding user requirements, forming plans and generating aggregations, while AgentScope's task-state machine is responsible for the continuity of the delivery phase. The mail service provides reception and original processing queries whereby the task processor identifies external actions and submits the results.
Now restore the problem ahead:
subtask was created with the father's mission waiting to be submitted, which addressed “the five jobs after the process has been withdrawn and can't be remembered”; the operational identification and query phase of each e-mail addressed “how to verify when an external action has occurred”. The two-tier mechanism is working together to restore a particular mail.
If the mail service does not support e.g., nor can it be consulted, the 4th will still need to remain uncertain and be submitted for operational verification. The Enduring Status Machine provides a clear processing location and does not create facts that the external system is not preserved.
Reopen Session and schedule the original assignment to continue
Apply AgentScope to configure models, tools and task definitions, open a permanent Storage, and then get the original version of the session. Enter to return the Submission identity after submission, and apply to either wait for the result or re-examine later.
When the process is restarted, the main processes are:
Reopen Same
• Restore Conversion, Entry, Document, Task and Submission
• Check for task type, version and stage processing Device
Start the task scheduler
Sending / interrupting running: re-entering from the saved stage
waiting: recheck dependent tasks
Slepting: continue waiting for the original point of time and run when due
Completing: Checking if subtask is finished
terminal: directly provide the saved result
• Each state change is still submitted through the same atomic sequence
AgentScope uses the Registry registration tasks, tools and extended definitions. Saves the status, identity and definition version in storage. The processing code is provided by Registry. When reopen, check the type and version of the task internally and run the required state migration; if the task definition is missing or cannot be moved, keep the status quo ante and report the cause of the jamming, and then proceed with the schedule when the definition is compatible.
The same business input retry uses the same requestId, AgentScape returns the original submission and avoids re-creating the job. Waiting again for a submission to resume observation only; closing the current Harness stop this drive and keep the uncompleted task. Business cancellations are preceded by a permanent record of the cancellation of intent, prior to notification of the suspension of the activity phase, pending the end of the subtask of which it belongs, and the final submission of the mission.
The restoration therefore does not require the replay of the entire Agent cycle, nor does it amount to the resubmission of the original prompt. It looks at the unfinished and currently operational phase of the durable task map, replicating the confirmed results and continuing its work.
Storage, view and host wake up to what they are responsible for.
AgentScope saves and reads the execution records through the Storage interface atoms and stores the semantic separation from the task. Document uses the incremental operation and periodic complete baseline to keep the task record in its full state; the current status is restored on re-open without the need to sequence the entire process. Applications can select local durable storage as required by deployment, or access the remote backend provided by the platform.
AgentScope 's session view, document view and taskchart changes after submission, presenting the input acceptance, model output, tool progress, dependency and end result. Reconnect first to the current view and then to receive subsequent changes. The preview, which allows for late saving, is a clear exception and is not the only basis for recovery. Read only open session provides queries and observations, does not start task scheduling and does not get permission.
AgentScope initiates the task scheduler by alerting the host that “there is a job to run” and “when to continue next”. Permanent hosts use local timers to advance expired tasks; cloud-end hosts receive changes through on-Wake, arrange for the next wake-up call to re-open the session after the process has been recycled and call back(). The dispatcher is responsible for determining whether the mission is operational and the host is responsible for providing practical implementation opportunities.
Many examples also require shared storage, segregation of enforcement powers and compatible environments. The task does not occupy an active phase of call in slepting or waiting, but the real processes and external tools that are running still have their own life cycle. Retrieving these external tasks will require the next section of the Platform ' s hosting and tool implementation mechanism.
AgentScope's Durable Implementation kernels Entry, Document and Task describe the fact of a job together with the future, and align it with the Atomic Committee. The Agent cycle is driven by a durability machine, while the host and the platform delegate operational work to actual implementation resources. The framework is responsible for “where to continue and how to continue”, and the platform for “where to keep the status for the long term and where to continue”, which is linked to the compact of storage and awakening.
Dureable Agent design idea for Alibaba Cloud AgentCore
Existing hosting capacity is the basis for the Durable extension to the platform
Alibaba Cloud AgentCore, a cloud hosting platform for AI Agent, provides Harness hosting, session management, interruption and nodal resilience, and helps developers to stabilize AI agent applications on the cloud.
AgentCore has provided hosting capacity to support the continuation of the mandate after its interruption and the restoration of the designated saved implementation node. This allows Agent to run one operation in a state that is renewable, and business assignments no longer exist only in one interactive or one running process.
The hosting of Harness (OpenHarness) retains the reasoning of the lower kernel, context and the use of tools, which are linked by the platform to its status preservation and recovery capability. The restoration node here is the place where the kernel and its adaptation mechanisms can be preserved and explained; the node restoration does not automatically undo the external business actions that have taken place. Different kernel open states and control interfaces also determine the size of the particles that can be restored.
On this basis, a more fine-scale Durable can go further into modelling, tool call, application of results and long waiting periods. The task status machine described above answers “how this phase continues”, while the platform needs to answer “where, when and by which example the status is kept”.
Brain-Hands separation and more completeness is the direction that continues to be built on the already available hosting capacity. Here is a discussion of how Durable can fit into these directions from the point of view of architecture, and how they can share a durable basis with the existing Harness hosting.
The figure shows, respectively, the availability of hosting capacity, the direction of subsequent evolution and the state, movement control and environmental abstraction that can be relied upon together. The link between them is a lasting implementation compact: it can take over both the restoration nodes of the birth of Harness and the post-kernel mission phase and the handover of tools.
Common Session Store, connecting birth status to platform implementation facts
The platform is unified in terms of the preservation, submission and reading of contracts of status. The Agent framework and running still manage its own contact, messages and checkpoint formats, linking these appliance levels to the location where the Platform can understand mission identity, tool intent, waiting conditions and results.
The Session Store provides a common and lasting basis for this collaboration: a state version of the record, retention of the check points and reference to the results, return of searchable submissions and, when restored, provide a consistent set of states. It is linked to reliable movement, event flow, so that tasks can be followed up and reobservated by operational applications.
These states can be stored separately and linked to the version by identity. Larger primary state and results can be kept as non-variable objects, referred to in the submission record; workspace files are carried by the corresponding environment. The platform does not require all content to enter the same chat log.
When entering different frameworks, the appropriate layer is responsible for declaring the boundary to be preserved and restored. The ability to participate in frameworks submitted for model completion, tool authorization and results application provides for more detailed recovery control; the framework for the restoration of the main open session is based on its original capacity. Common storage can carry different payloads, but restoration of old Session still requires matching kernel and state formats.
So a common session store can support both the hosting of Harness and the deeper Durable design. A unified storage contract would reduce duplication of construction, and each access path would retain its own semantic and particle size.
Extension of restoration nodes to coherent boundaries during implementation
The key to recovering from a given node and moving further towards a fine particle size, Durable, is to define what facts must be saved together and what follow-up actions are allowed after the preservation has been successful.
In the case of tool call at a time, it is not enough to keep the "models want to call tools". The information required for recovery also includes the continuing location of Harness, fixed tool parameters, the link between primary call and the Platform ' s mandate, and the conditions for waiting for results. Putting this information into the same coherent border will allow the restorer to make a clear determination as to whether the call has been approved for implementation, which call the result is, and whether next step should wait or continue its reasoning.
This design extends Part Three atom Commit to platform collaboration. The kernel submits its own recoverable state, while the platform keeps the corresponding implementation facts; subsequent dispatch is based on confirmed submissions. When it comes to independent storage and information systems, it is possible to keep the pending intention permanently with the state, and then to complete the handover through a delivery mechanism that allows retry, avoiding a state that has been advanced and that follow-up has no basis for implementation.
Three separate steps are required: the call has been accepted, the tools have been completed and the results have entered Harness context. They may be separated from each other for a long time, or they may fail at any of the crossings. Save the progress separately and restore the missing step instead of re-executing the entire process.
For the hosting of Harness, these boundaries need to be established in conjunction with the existing restoration interface of the kernel; for the kernel, which is able to provide deep control over the implementation process, the model can be designed directly as a durable phase in its completion, tool authorization and application. Both approaches share the state base, but do not automatically have the same control depth.
Brain-Hands Separate: Gives reasoning and tools their own life cycle
The Brain-Hands separation can be seen as a further development of the above-mentioned mechanism of lasting transfer: the Brain Management Logic and the practical implementation of the context, Hands Management Tool, which collaborates through the retained call identities, status and results.
At the heart of this separation is making the “waiting tool” a sustainable state of expression. The resources for this implementation could theoretically be released by the submission of the terms of call and the waiting conditions; the tool would be continued by an independent implementation mechanism. When the result continues, the original state is read and applied by the compatible Brain example. The entire process no longer requires the initial reasoning process to wait.
The following is an example of a tool that has been in operation for a long time, to illustrate the state interface in this structure:
In this design, the tool completion notification is only a trigger to continue, and the real decision on next step is a protracted state. Movement control needs to be able to rediscover outstanding recovery arrangements and constrain current effective implementers to prevent old cases from advancing into the same state as takeover cases. In this way, the tool will not be tied to a process or a connection separately for the purpose of waiting for, delivering results and resuming reasoning.
Returning to the case of five e-mails, this separation does not affect the work that has been handed over during the dispatch of the reasoning case; the particle size of the block-by-block restoration still comes from the operational mission design of part three. The first three returns can be reused, the fourth is verified as originally operated and the fifth continues from the stage where implementation has not yet taken place. Brain-Hands separation provides the conditions for an independent succession, and operational checkpoints, together with the recognition capacity of the external system, determine how detailed it can be restored.
If the tool itself does not support the original search operation or the identification of duplicate requests, the separation structure does not automatically eliminate the window where the action has occurred and the result has not been confirmed. Such uncertainty will still need to be part of the mandate and will be addressed by the corresponding operational rules.
Environment to continue the condition of the saved state
Rereading is only part of the recovery, whether using existing nodes or using further Brain-Hands separation. New examples of implementation also require compatible kernels, dependencies, models and
Auto-fetched and translated by AI Atlas. All rights belong to the original author.