一个 Agent 任务暂停后，团队常会问：“把上下文保存下来，之后继续不就行了？”真正恢复时却会发现，当前节点、用户偏好和上次工具返回值并不是同一类信息。它们的保存时机、保留期限和使用方式不同，混在一个大对象里，既难排错，也容易把旧资料带回新任务。
Agent Runtime 可以把一次执行拆成可追踪的运行实例。以 ZGI 这类可自托管 Agent Runtime 为例，Agent 可以绑定模型、记忆、知识、文件输入、技能和工作流；工作流再承接模型调用、工具、审批、分支与循环。理解这些能力时，先把状态、记忆和运行记录放在三条线上看。
先分清三种东西各自保存什么
状态回答的是“这一次任务现在到哪一步”。它至少要能说明运行 ID、当前节点、等待条件、重试次数、待处理动作和任务状态。暂停审批时，状态要把流程停在可恢复的位置；恢复时，Runtime 依据同一个运行实例继续，而不是重新猜一遍已经完成的步骤。
记忆回答的是“后续交互可以带上哪些信息”。用户偏好、已经确认的称呼、长期有效的工作习惯，可能适合进入记忆；某次上传的合同全文、一次工具报错或一个临时审批意见，则更适合留在当前任务或运行记录里。记忆需要范围和失效条件，不能把所有历史对话都当成永久事实。
运行记录回答的是“这次到底发生了什么”。它记录开始条件、节点顺序、模型与工具调用、输入输出摘要、耗时、异常和最终结果，服务于排错、复核和批量测试。运行记录可以很详细，却不等于下一轮对话的上下文；把日志原样塞回模型，反而可能引入无关信息或敏感字段。
再用一次任务检查它们如何协作
拿“从制度文件整理一份待确认清单”做小范围验证。任务开始时，状态保存本次运行的输入版本和起始节点；模型从绑定的知识范围取资料，用户已经确认的格式偏好进入记忆；每个检索、生成和人工确认节点，则把结果写进运行记录。三者一起工作，才能知道“为什么得到这个结果”，以及“下一次是否应该继续沿用这个偏好”。
恢复测试要故意制造三个变化：在审批等待期间替换一份制度文件，修改用户的输出偏好，再让服务重启。文件版本变化应触发重新核对，偏好变化要按团队规则决定是否覆盖本次任务，服务重启后应能从保存的状态回到正确节点。运行记录要保留这些变化和处理决定，避免页面只显示一个模糊的“已完成”。
在 ZGI 中配置这类任务时，可以把知识和文件输入限定在明确范围，把记忆用于跨次交互，把 Workflow 节点和运行结果用于执行状态与复核。公开资料还列出运行状态、耗时、步骤、结构化输出、运行日志和批量测试入口；这些能力能提供观察位置，但具体的字段、保留时间、权限和恢复规则仍要按部署环境验收。设计时还要给三类信息设定不同的访问权限：业务用户查看结果，流程负责人查看状态，排障人员查看必要日志；记忆中的长期信息则应有修改和清除入口。
验收时只问四个问题：任务停下后能否指出当前节点，恢复时能否回到同一个运行实例，下一次对话会带上哪些记忆，事后能否从记录还原模型和工具做过什么。四个答案都清楚，Agent Runtime 才真正具备承接长任务的基础。
GitHub：github.com/zgiai/zgi
Gitee：gitee.com/zgiai/zgi
