GPT-6 长任务指南：让智能体持续取得有效进展

GPT-6 Astra 能推进持续较长时间的项目，但只有不断接近合格成果，长时间运行才有价值。应给智能体一个具体里程碑、验证进度的方法，以及足够的已保存状态，方便中断后恢复。完成一个有意义的阶段后，再扩大范围。

网站、研究资料包、仓库迁移或多文档交付都需要这样管理。每类项目都可能运行数小时，却没有解决核心需求。真正应问的是：最新的工作是否让最终成果更可用？

来源: Matt Shumer 的评测; Codex 问题 #43193; OpenAI 发布说明。核验日期：2026 年 9 月 7 日。下文中的测试结果和体验均注明作者。

早期体验说明了什么

Matt Shumer 的 Astra 评测描述了一些宏大项目：模型过度投入细节后，整体进展逐渐放缓。他发现协调机制有助于保持方向，同时也承认长时间自主工作仍未彻底解决。

一个公开的 Codex 编排与指令遵循问题描述了大量用量消耗与反复流程失败并存的情况。这是用户报告，不是测得的失败率，但说明不能将更多智能体活动误当成进展。

这些经验提示了一种操作习惯：评估上个检查点之后究竟改变了什么。如果没有任何验收项更接近完成，增加时间或智能体之前，应先检查计划。

判断中断属于哪一类

长任务可能因模型需要决策、工具故障、应用结束运行，或工作偏离方向而停止。每种情况都需要不同处理。反复说“继续”，通常无法解决缺少文件或指令冲突的问题。

OpenAI 的 GPT-6 指南提到，模型更倾向于提出澄清问题，也更敏感于可访问文件中的指令。指南还介绍了轮次内引导和异步工具调用。这些能力帮助应用协调工作，但不保证任意会话都能无限持续执行。

一则早期文档审查讨论描述了即便有检查点和协调者，任务仍会停滞。这只是单个用户的体验，但揭示了实际限制：检查点可以保存进度，却不会自动提供调度器，也无法修复已停止的执行环境。

完整示例：审查大批量文档

假设团队需要比较多份文档中的要求。这个示例适合分批处理，因为可以边推进边核查覆盖率和发现。应从文件清单开始，而不是立即要求最终报告。

第一阶段：确认有哪些资料

为每份文档指定标识符、版本、日期和审核状态，记录无法读取的文件与缺失引用。先确定审查必须回答的问题，避免模型将预算花在不影响决策的材料摘要上。

第二阶段：审查有代表性的一批资料

选择结构与复杂度各不相同的几份文档，要求发现关联到页码、章节或来源标识符。在用同样方法处理全集之前，先审核首批结果。存在缺陷的提取格式如果重复数百次，代价会很高。

第三阶段：跨批次核对

最终综合分析应比较各文档的主张、定义和要求。记录相互矛盾的来源，并解释哪个版本优先。不能仅因后续智能体拿到的是首份摘要而非原文件，就把摘要视为权威。

第四阶段：验证是否完成

将最终报告与文档清单逐项对应。每份必需文档都应处于已审核、有理由地排除，或仍待处理的状态。即便已完成章节准确，一份覆盖不全的精美报告仍是不完整的成果。

文档 ID | 版本 | 审核状态 | 发现文件     | 待解决问题
A-01    | 3    | 已审核   | findings-a01 | 无
A-02    | 2    | 受阻     | findings-a02 | 缺少附录
A-03    | 1    | 待处理   | -            | 尚未审核

这样既让接替的会话知道从哪里开始，也让人工审核者无需重放整个对话就能检查覆盖情况。

决定检查点必须保留什么

有效的检查点既要记录工作状态，也要提供状态正确的证据。如果没人能找到输出，只写“第二阶段完成”还不够。应包含成果路径、输入版本、已完成验收项，以及剩余差异。

代码任务记录工作版本和相关测试结果；研究任务保留来源链接和检索日期；表格任务保留输入工作簿及已应用改动。如果其他人编辑了成果，继续前先更新检查点，避免智能体基于过时假设工作。

在自然阶段边界保存检查点。每句话都保存会增加管理负担；数小时运行结束后才保存，又会让恢复代价很高。完成一批任务、验证一个改动，或解决一个设计决策，通常都是合适时机。

恢复任务时避免重复工作

根据已保存的任务记录恢复当前里程碑。
修改前先检查现有成果。
识别已完成的验收项，不要重复执行。
核查此前尝试过的外部操作究竟有何结果。
继续完成下一个未满足的标准。
如果记录与文件冲突，先说明并核对清楚。

“尝试过”与“完成了”的区别很重要。工具可能已创建记录，随后才超时。重试前应读取目标系统，确认实际结果。对于本地成果，检查上一轮是否保存了可以接着完善的半成品，避免直接覆盖。

围绕有效进展安排预算

通过限定范围的试运行，了解任务实际需要多少工作量。文档审查记录已核验文档和已修正发现；编程记录已验收行为。也要计算人工审核时间，因为需要花数小时修复的大量输出，未必提高效率。

预算接近用尽时，应明确要求：保存当前成果、更新任务记录，并返回下一项待决策问题。单纯的 token 上限可以防止继续花费，但不能保证交接有用。交接必须写进任务契约。

如果连续检查点之间不再改善进度，应暂停扩展并检查瓶颈。下一步可能是补齐来源、缩小里程碑、更换工具，或让人作出决策。提高推理强度只是可能的干预之一。

定义第一个完成目标

“构建整个产品”包含过多隐含决策。先从可以检查的一部分开始：一条可运行的用户流程、一项经过验证的分析，或一个迁移后的组件。这部分应足够有用，能揭示模型是否理解项目。

运行开始前设定里程碑。每次看到中间结果就改目标，会让修正方向与范围膨胀难以区分。

Matt Shumer 的评测准备进度页面。清单数量记录进展，不等同于独立验证。

保留精简任务记录

模型需要当前目标、已定决策、工作文件、失败方案和待完成检查。长对话记录并不总是恢复这些信息的最佳位置。应维护一份容易检查和修正的简短记录。

当前里程碑：
验收标准：
成果和来源位置：
已经作出的决策：
排除的方案及原因：
已验证结果：
待解决问题：
下一步操作：

取得有意义的结果或发生重要方向调整后，更新记录。不要把它写成每次工具调用的流水账，其目的是让下一个决策更容易。

识别三类停滞

重复无效方案

询问是否有新证据支持再次尝试。临时工具故障后重试可能合理；没有新信息却重复相同推理，通常价值有限。保存失败尝试，避免下一次会话重新走一遍弯路。

核心任务未完成就开始打磨

关键流程还不能用，智能体却可能一直润色措辞或视觉细节。应回到验收标准，找出最重要的未满足要求，先完成它，再增加精细度。

用扩大范围代替澄清歧义

任务不清晰时，模型可能继续搭建基础设施，而不是解决缺失的选择。让它指出会改变设计的最小不确定因素，先解决这个决策，再允许大范围重写。

用检查点支持中断恢复

OpenAI 的 Astra 公告提到，安全防护可能打断正常任务。网络故障、应用崩溃和用户修改要求也会停止运行。工作过程中持续保存有用成果，恢复前先验证当前状态。

恢复的任务应读取现有文件和任务记录，识别已完成内容，再继续下一个未满足标准。如果上一轮可能执行过外部操作，重复之前先检查结果。

长任务提示词模板

完成这个里程碑：[具体成果]。
验收标准：[可观察检查]。
使用以下材料和工具：[范围]。
维护简短任务记录，包含决策和已验证进展。
先完成未满足的核心要求，再进行润色。
如果进度停滞，解释阻碍和需要补充的证据。
达到预算上限时，返回可用成果及下一步操作。

并非每个项目都需要多个智能体。只有某个独立角色具有可单独审核的明确输出时，才增加它。协调本身也会成为工作，尤其是多个智能体编辑同一成果时。

同时衡量进度和成本

记录已完成标准、审核修正、耗时和总用量。有效的检查点可以说明：三条流程中两条已通过，第三条有可复现故障，补丁已准备好等待审核。仅说“还在处理”，不足以判断再投入一小时是否值得。

将简报、来源、草稿和审核决策集中放在 Ottermind 中。较短的入门任务可使用如何使用 GPT-6中的模板；集成层面的预算设置可参考 API 指南。

常见问题

GPT-6 可以用一条提示词完成项目吗？

有创作者描述过这样启动的项目，但运行环境、工具、前期设置和后续审核仍很重要。先从具体里程碑开始。

应让智能体运行多久？

根据任务设定预算，在有意义的检查点查看进展。不存在适用于所有任务的有效时长。

智能体一直打磨小细节怎么办？

重新说明最重要的未完成标准，在满足它之前暂缓可选的润色工作。

进展变慢时应增加智能体吗？

先查明原因。需求缺失和方案错误需要澄清或修正，而不是更多并行工作。

停止的运行应该返回什么？

可用成果、已验证结果、待解决问题，以及明确的下一步操作，让后续无需重复已完成步骤就能恢复。