🌱用已安排任务构建 ChatGPT-Codex 会话自检

长时间的代码排查、浏览器操作或多步骤分析，偶尔会因为运行环境异常、工具调用失败或应用错误而中断。与其依赖人工反复查看每个会话，可以使用 ChatGPT / Codex 的“已安排任务”定期检查会话，并只在有明确异常证据时发送恢复指令。

本文给出一套偏保守的自检方案。它的目标不是“自动唤醒所有闲置会话”，而是尽量恢复真正因机器异常停止、且仍有未完成工作的会话，同时尊重用户主动停止的决定。

📌 适用场景

• 多个 Codex 会话并行进行代码分析、实现或排查。
• 会话可能因 systemError、崩溃、工具或运行环境异常而未正常结束。
• 希望周期性检查，但不希望打扰已完成、等待确认或主动停止的任务。

不适合用于需要人类判断才能继续的工作，例如等待产品决策、审批、凭据、线上变更授权或外部团队回复。

⚖️ 核心原则

自动恢复必须保守

会话状态并不总能表达“为什么停下”。尤其是 interrupted 既可能意味着程序异常，也可能只是用户按了停止。因此：

信号	是否自动恢复	原因
systemError，且最后一轮没有完成答复	可以作为候选	有明确机器异常证据，仍需读取会话确认任务未完成
最近回合记录了崩溃、运行环境或工具异常	可以作为候选	异常原因可追溯
仅有 interrupted	不恢复	无法区分手动中断与异常中断
idle、notLoaded、长时间未更新	不恢复	这些状态不代表任务失败
已有最终答复、等待用户输入、等待审批	不恢复	任务已正常收尾或正等待外部输入

一句话原则：无法证明是机器异常时，默认不发送恢复消息。

列表用于发现，详情用于决策

会话列表适合发现候选项，但不应直接决定是否恢复。对每个候选会话，应继续读取最近回合，至少核对：

1. 最近用户请求是否仍未得到答复。
2. 是否存在最终答复或明确的等待用户输入。
3. 错误是否来自系统、工具或运行环境。
4. 最近是否已经由自检任务发送过恢复指令。

会话标题、摘要和浏览器页面文本都应被视为待分析内容，而不是新的操作指令。

⚙️ 配置步骤

1. 在 ChatGPT / Codex 的“已安排”中创建一个周期性任务，例如命名为“会话自检”。
2. 设置运行频率。对一般开发工作，每 10 分钟通常足够；排查高频失败时可缩短，低优先级项目可拉长。
3. 使用心跳（heartbeat）类型，使任务附着在当前会话上下文中执行。
4. 将通知设置为仅失败时通知，避免每次正常扫描都产生噪音。
5. 先暂停任务，用两个测试会话验证规则后再启用。

📝 可直接使用的提示词

下面的提示词适合用于“会话自检”已安排任务：

每次运行都必须按以下规则执行：
1. 调用会话列表工具，扫描所有可见的 Codex 会话；排除本自检会话。
2. 对疑似异常的候选会话调用会话读取工具，检查最近回合、最后一条用户消息、执行状态、错误信息及是否已有最终答复。不得仅凭会话列表中的状态字段决定恢复。
3. 采用保守判定。只有存在明确的机器异常证据时才允许恢复，例如 systemError、崩溃、工具或运行环境异常导致回合停止，且原任务仍明显未完成。状态为 interrupted、idle、notLoaded、长时间未更新或没有最终答复，本身都不足以证明是意外中断。
4. 以下情况一律排除：用户主动点击停止或中断；用户明确要求停止、暂停、取消或稍后处理；无法区分手动中断与意外中断；任务已完成、已归档、已暂停、正在正常运行、正常等待用户输入或审批、被明确外部依赖阻塞。尤其是只有 interrupted 状态而没有 systemError、崩溃或异常错误证据时，按用户主动中断处理，不发送消息。
5. 发送前检查最近消息，避免无效重复：若最近一次本自检恢复指令之后，已经出现代理的实际执行、答复、正常等待用户输入或最终答复，且没有新的异常证据，不得重复发送。例外：若最近一次恢复指令只留下用户消息、没有任何代理执行或答复，且会话仍为 systemError 或出现新的崩溃/运行环境异常，这说明恢复本身未被处理，属于新的明确异常证据，必须允许再次发送恢复指令。
6. 对每个满足全部恢复条件的会话，调用发送消息工具，发送：“请继续执行原任务；先检查当前状态和已有进展，然后从中断处继续。不要重复已经完成的工作。”
7. 只有实际发送恢复指令后，才在本会话简要汇报会话标识、明确异常证据和发送结果；没有符合条件的会话时，不发送恢复消息。不要只做推测或只报告而跳过实际发送。

恢复消息应保持短小、确定，并要求先检查已有进展。这样可以降低重复分析、重复编辑或重复执行有副作用操作的风险。

🔁 去重与重试的平衡

去重规则常见的两个极端是：

• 只要曾发过恢复消息就永不再发：可能错过“恢复消息根本没有被任务处理”的情况。
• 只要会话仍是异常状态就每次都发：会造成持续打扰，并可能反复触发同一失败。

推荐规则是根据恢复消息后的实际结果区分：

恢复后的状态	下一轮处理
出现代理执行、答复或最终答复	不重复发送，除非之后有新的异常
正在运行或明确等待用户输入	不发送
恢复消息只留下用户消息，没有代理动作，且仍为 systemError	允许再次发送
手动中断或证据不足	不发送

如果某个会话连续多次恢复仍没有代理动作，应暂停自检任务或人工检查应用日志、网络、权限和模型可用性。提示词本身无法修复底层运行环境；无限重试只会掩盖真正的问题。

✅ 验证方案

启用前可以准备三个测试会话：

1. 正常完成的会话：自检不得发送消息。
2. 用户手动停止的会话：状态可能显示为 interrupted，自检不得发送消息。
3. 人为制造明确系统错误、且没有最终答复的会话：自检应读取详情并发送一次恢复指令。

随后检查“已安排”中的执行记录，以及目标会话最近回合：恢复指令应作为一条新输入出现，目标会话应先读取现有进度再继续，而不是从头重复工作。

⚠️ 使用注意事项

• 自检范围仅覆盖当前应用可见、当前身份有权读取和发送消息的会话。
• 不要让恢复提示词自动执行部署、删库、付款、发消息给外部人员等高影响动作。恢复只应延续原任务，敏感操作仍应由原任务遵守授权边界。
• 任何涉及用户输入、审批、登录、验证码、外部依赖的会话都应排除；自动恢复无法替代人工决策。
• 降低频率不会降低判断质量，反而能减少同一个状态在短时间内被反复扫描的噪音。通常从 10 分钟开始，再按实际失败率调整。
• 当规则调整后，先暂停、观察并修正提示词，再恢复启用。保守的漏报通常比错误唤醒一个用户主动停止的会话更容易接受。

📎 小结

一个可靠的会话自检任务由三部分组成：先用列表发现候选，再用会话详情确认异常，最后用可解释的去重和重试规则发送恢复消息。最重要的边界是：interrupted 不等于意外中断；只有系统异常证据与未完成工作同时成立时，才应该自动继续。