长任务怎样持续运行、吸收新事件并恢复

当任务会跨会话、等待外部结果、接受用户修改或调用有副作用的系统时，单个模型循环已不足以表示工作。需要回答：离开页面后谁保留任务；新事件如何改变已有计划；重启后从哪里继续；哪些结果可以告知用户完成。本专题围绕合成任务合同解释，不要求小型草稿工具先建设平台。

四种状态应分开保存

一项合成招聘任务SYN-H07已找到候选人，正在核对必备条件。用户关闭网页后要求变更工作城市；外联工具恰好提交超时。此时“模型已结束”“消息已投递”“候选已评估”“邮件已发送”没有共同真值。建议把以下对象分开：

聊天历史可以辅助解释，但不能替代这些合同。历史中写了“准备发送”不证明邮件已经发送；界面上一次显示的进度也可能落后于后台状态。

LinkedIn的公开平台将消息交付、历史、FIFO和持久重试提供为共用能力，应用层的GraphQL与SDK把结果变成带显示信息的视图模型和实时事件。同步快速路径绕过异步队列，同时旁路创建消息，存在最终一致窗口。这些披露说明交互快慢和持久记录的一致性需要分别设计；没有公开的延迟分位数、去重协议和补偿参数不能自行补成产品承诺。平台工程，Messaging orchestration与Final thoughts、应用工程，Client integration

一笔可恢复工作的原创合同

以下JSON只用于教学讨论，不是LinkedIn或SAP接口。身份由服务端认证传入，不能相信请求正文自报的租户或权限。

{
  "task_id": "SYN-H07", "entity": {"type": "hiring_project", "id": "SYN-P7"},
  "state_revision": 11, "requirements_revision": 4,
  "state": "waiting_result_check",
  "completed": [{"step": "evaluate_candidate", "result_ref": "SYN-E12",
                 "requirements_revision": 3, "needs_recheck": true}],
  "pending_events": ["SYN-EVT38"],
  "actions": [{"action_key": "SYN-P7:C12:contact:v2",
               "status": "unknown", "receipt": null}],
  "next_step": "query_contact_receipt",
  "resume_after": "action_status_resolved"
}

状态版本用于拒绝并发覆盖，条件版本让旧成果可识别，动作键用于关联查询和重试。状态必须由确定性服务更新：模型可建议下一步，但不能绕过授权、版本比较和动作系统的实际状态。跨系统无法保证原子提交时，保留unknown是有用结果；先记录成功文字会迫使运营事后猜测。

一种迁移协议是：

接收事件 → 持久化event_id → 校验实体与允许范围 → 判断新建/合并
读取task.state_revision → 形成候选变化 → 校验Schema/业务约束
比较并更新状态；冲突则重读，不覆盖他人的更新
在可停止点吸收pending_events → 重验受影响结果 → 执行允许的下一步
副作用结果未知 → 按action_key查询回执 → 确认/恢复/人工接续
发布新状态投影；客户端重连先取快照，再接续未见事件

这里的“先持久化”不承诺任意队列具有恰好一次语义。必须测试重复事件、崩溃前后状态和动作回执是否可能脱节。读查询通常可有界重试；外发、改价和设备操作必须使用各自业务恢复协议。不存在可靠回查接口时，应改变任务范围或引入人工核对，不能靠模型判断超时是否意味着没发生。

新事件：合并、重规划还是抢占

SAP作者的研究将事件管理放在确定性待办层：模型提出新建/合并/忽略及优先级，Schema与配置约束检查之后才更新队列。已有任务保存累计结果与恢复状态，相关事件进入待吸收上下文；ReAct在调用返回、下一轮推理之前检查，DAG路径在重规划检查点检查。抢占保存状态后再切换，恢复可以保留已完成节点。SAP研究v1 §2.1–2.4

迁移时先试三条合成事件：设备07压力告警、设备07温度升级、设备08压力告警。第一与第二是否同一故障仍需确认，设备08至少不能因描述相似就混入设备07。实体ID、发生窗口和业务关联提供判断依据；模型建议只能在已授权对象内比较。论文的模拟专业Agent用LLM检查实体，并非真实权限机制。

选择固定流程适合依赖稳定、动作有限的工作；固定流程加人工异常处理适合低频变化；增量重规划适合新信息经常改变取数和分析步骤。只有持续事件竞争同一资源、优先级差异真实且可安全暂停时，才考虑抢占。论文队列加入等待时长与已完成进度，避免低优先级任务饿死和频繁切换；具体权重取决于响应目标，不能照搬为所有企业的默认配置。

模型运行检查点不等于设备安全中断点。正在提交采购或写设备状态时，先解决正在发生的动作；紧急安全响应应独立于通用Agent。也不要把更多专业能力当成更可靠：论文发现注册规模增加后发现噪声成为瓶颈，实验是模拟能力集合，不代表必须上200个Agent。

如何判断协议是否成立

使用合成夹具逐步推进，而非只看最终聊天：

先做状态转换与回放检查，再用隔离业务系统验证写入和回查合同。通过纸面或离线状态例只说明协议逻辑可检验，不能说明生产交付可靠；模型推理、消息基础设施及外部系统仍有不同失败模式。

参考资料

• LinkedIn平台工程（2025-09-10）及应用工程（2025-10-21）：消息持久化、客户端同步与结果投影；未运行内部消息平台。
• SAP作者论文2606.20058v1，2026-06-18，§2–4：事件管理与停止点；208个业务衍生情境使用模拟专业Agent，不是208次生产事故复现。
• 全部字段、招聘/设备事件与恢复协议为原创教学设计。未复制源代码、原图或业务资料。

接入主线

产品交互决定用户怎样看见并控制工作；工具集成定义动作合同；持续运行分配恢复责任；反馈决定经验怎样变成下一版。可用运行复盘模板记录一次未知结果与恢复证据。