业务Task

Task是业务工作持续存在的身份，Session是交互容器，Run是某次执行尝试。任务输入、动作范围和验收规则在任务合同中统一定义；本页关注这份合同确认之后，工作如何跨会话、重试和人工等待保持一致状态。

同一个Task可以由多个Session查询，也可以先后产生多个Run。用户换设备或新开聊天，不应自动创建重复业务工作；另一位参与者继续处理时则必须重新鉴权。关闭Session只结束交互，不等同取消后台Task。删除聊天、删除产物和撤回记忆也应依据各自策略执行，不能用一个按钮含混处理所有对象。

Task的主要状态可以包括draft、queued、running、waiting_input、waiting_approval、verifying、succeeded、failed和cancelled。短暂网络错误与retrying更适合放在Run或Attempt，避免业务任务每遇到一次429就在成功失败之间反复跳转。每次转换保存原因和事件来源，让用户知道等待的具体对象。

模型返回结果候选后，Task进入verifying；只有规定验证通过后才succeeded。工具返回accepted只说明动作被接收，不应直接使Task成功；外部操作unknown时，任务需要等待对账或明确部分结果。取消阻止新行动，却不自动撤销已发生效果，因此最终状态应保留已完成和仍未知的操作。

Run绑定执行版本、预算和checkpoint，Task持有长期业务状态及最终产物。一个Run因基础设施故障恢复，通常不改变业务动作身份；如果用户实质修改目标或验收，则记录合同新版本并决定重开Run。Task ID、Run ID和operation_id分别服务工作归属、执行归因与副作用去重，不能互相替代。

队列消息至少一次投递时，Task领取和状态更新需要事务、版本或租约控制。旧worker的结果不能覆盖新owner已经确认的状态。事件回放应从已提交意图、回执和验证重建进度，不从模型自然语言推断事实。任务清单可以展示当前owner、等待原因、已验证进展和产物，而无需暴露私有思维链。

验证重点是生命周期：重复创建请求是否去重，换Session能否继续且不会扩权，worker重启是否复用正确Run，审批或deadline变化是否正确阻止旧工作，最终成功能否回到验收记录。只有这些映射稳定，平台才可以安全增加模型、子Agent或执行入口。

OpenAI托管架构中的应用与执行边界；长期任务的持久产物与增量工作。