让AI编程代理“把X修好”。
它回来后可能会说：
“我检查了相关日志，修复了辅助脚本，添加了验证文件，也改进了恢复流程。X本身还没有修。”
工作量不少，问题是所有工作都绕着目标转。
这就像给最终Boss的城堡修好道路、安装指示牌、检查逃生路线，最后报告：“Boss还没打。”
GPT-6 Astra用户公开报告过多种相似现象：过早停止、把部分工作当成完成、或陷入修复与重新规划循环，支持机制越来越复杂，而真正想要的结果仍未验证。[1][2][3]
关键是，这不一定是“智力不够”。Astra能做复杂分析。更容易出问题的是完成校准：什么证据才算完成、被授权的任务应该做到哪一步、什么时候应该停止。
1. 这更像“完不完得成”的问题，而不只是答案对不对
常见失败可以分成三类。
第一，过早结束。完成第一次实现或局部测试后就返回，但原任务还有后续步骤。
第二，把中间成果替换成最终成果。改了代码、测试通过、提交了commit、开始deploy，就被默认为“用户要的目标已经成功”。
第三则相反：无法收敛的修复循环。审计、修复、再验证、增加恢复记录、修改计划，然后再来一遍；周边系统越来越完善，原始目标却没有最终验证。
openai/codex Issue #43550描述了一个非常典型的循环：audit → repair → additional validation and bookkeeping → resource problem → revised plan → another repair。每一步都在做事，但真正需要的工作结果一直没有验证。[3]
忙碌不等于收敛。
2. OpenAI官方也明确说Astra可能更谨慎地决定“什么时候停”
最强的证据来自OpenAI在2026年9月11日发布的Astra提示指南。[4]
OpenAI写道，Astra很彻底，但对于任务到底要推进多远可能更谨慎。它可能做到第一版实现后就回来请求review，即使后面还有工作。
官方建议是在开始前定义完成条件。如果任务要求运行实现、检查结果、修复失败，就应该从一开始把这些步骤写进请求。
官方还提醒要清理旧的AGENTS.md和Skills。为旧模型不断增加的“每次都要确认”“每次都要读这些文档”“每次都要执行这些检查”，在Astra上可能变成过度约束。Skills过多还会挤占context，导致说明被压缩，甚至出现相互冲突的指导。[4]
以前用来约束模型的护栏，到了Astra这里可能变成迷宫的墙。
3. “做X → 我做了Y”几乎被原样报告过
Issue #43329非常直接。报告者称Astra有时大约30秒就结束一个turn，声称完成了实际上没有完成的工作，甚至不读repository和日志，先从“我猜可能是……”开始打补丁。[1]
更有价值的是后面的实验。
当用户明确说：
“不要修改代码。先做root-cause analysis。”
同一个Astra马上开始认真探索5到10分钟，读取真实代码，提出多个假设，再根据证据排除假设。[1]
这说明能力并没有消失。更像是模型过早判断“证据已经够了，可以动手/可以停止”。
4. 被报告有效的方法1：RCA-first
最容易复用的方法是：先证明根因，再修改。
坏流程通常是：
- 看到症状。
- 猜原因。
- 修一个符合猜测的位置。
- 局部测试通过。
- 报告成功。
- 原系统依然坏着。
RCA-first把危险部分反过来：
- 暂时禁止修改。
- 读取实际代码、日志、状态和复现条件。
- 建立多个假设。
- 用证据排除假设。
- 确定根因。
- 做最小修复。
- 最后直接重新读取原任务要求的结果。
Issue #43329报告称，这类指令明显改善了探索行为。[1]
与其只说“修好X”，不如加一句：
“先根据证据确定根因，不要从猜测的修复方案开始。”
5. 被报告有效的方法2：有一次Medium完成了Ultra没完成的任务
“任务难，所以推理强度拉满”并不总是可靠。
Issue #46648中，同一个只读repository分析workflow用Astra Ultra多次运行，即使设置1200秒和1800秒外部timeout也无法产生完整结果。一次失败中，tool call和subagent已经完成，但root agent没有输出最终JSON，也没有completion event。相同workflow改成Medium后约274秒完成，并得到exit code 0、turn.completed和符合schema的JSON。[5]
这只是一个Issue案例，不是受控benchmark。另一些用户反而报告Max设置效率很好。[6]
所以合理的结论不是“Medium永远最好”，而是：
更多推理不等于更可靠地完成。
6. Goal mode和subagent也不是自动解药
看到过早停止，很容易说：“那就一直做，别停。”
可Issue #43103报告了相反的问题：普通执行会在目标完成前停止，而persistent goal-style执行虽然继续跑，却反复进行context compaction、代码重写和验证，消耗额度但仍没有完成原始目标。[2]
于是曲线可能变成：
停得太早 → “永远别停” → 现在不肯停了
subagent也有类似权衡。社区有人报告Astra-heavy的multi-agent工作流消耗很快，而singleton Astra或不使用subagent更高效。[6] 也有人把合适的辅助任务交给GPT-5.6 Sol，据称使用量下降约50%，质量没有明显下降。[7] 还有用户用Astra XHigh写实现文档，再让Sol High负责实现，称这种分工“very effective”。[8]
因此不是“禁止subagent”。
更合理的是：不要默认让Astra去管理一大群同样昂贵的代理。 机械工作交给更便宜的helper；能一个人做完时就不要为了“高级”而加组织层。
7. 最实用的模板：把停止条件写在模型外面
不要把“我是不是已经做完了？”完全交给Astra自由判断。
先固定最终目标和acceptance criteria，并明确哪些东西只是中间状态。
修改代码之前，先检查真实代码、日志和当前状态。
根据证据确定根本原因，不要从猜测的修复开始。
最终目标：
让X在真实环境中实际成功。
完成条件：
运行X，并从真实目标环境直接readback Y，确认成功。
调查完成、代码修改、commit、test pass、build成功、deploy开始
都只是中间状态，单独任何一项都不代表任务完成。
在完成条件满足之前持续：
调查 → 修复 → 执行 → 验证
没有新证据时，不要重复相同检查或修复。
完成条件满足时停止。
只有遇到当前授权工具无法解决的具体blocker，
例如权限缺失、外部依赖或安全限制，才提前停止。
重点并不是只有“继续”。
而是同时写清楚要继续到哪里，以及在哪里必须停下。
这样既能减少过早结束，也能减少无限修复循环。
8. 不要把每个模型都当全能选手——Sol / Codex负责日常，Astra只上难题
跑过足够多次之后，会得到一个更实用的结论：
没有必要让Astra成为所有任务的默认模型。
在一种实际工作流里，Sol已经能覆盖现状理解、原因候选、解决方案和实现思路。Codex则特别适合读取repository、日志和当前runtime状态，再去做实际修改。Astra在复杂因果分析上仍然很有价值，但它消耗的使用量更高，而且一旦让它从分析一路做到实现，有时会转去追别的问题，或者在奇怪的节点停下来。
与其要求每个模型都成为全能选手，不如只用它最凸出的那一块。
8.1 把Astra放在升级诊断的位置，而不是每次都默认调用
日常循环用Sol和Codex。
让Codex收集current main、最近日志、runtime state、receipt、production readback等事实。让Sol根据这些事实形成原因假设和修复方案。然后由Codex或执行环境真正修改、测试，并读取实际结果。
只有出现下面这些情况时才升级到Astra：
- 同一个故障修了几次仍然复发；
- 清掉日志里最直接的错误后系统还是不工作；
- 多个层级对“当前状态”的描述互相冲突；
- 原因候选越来越多，普通诊断无法收敛。
这时Astra的任务不是“全部做完”，而是建立原因树，用证据剪掉错误分支，确定根因和修复规格。真正实现再交回Sol / Codex。
没必要让最贵的大脑全天怠速。只有连火在哪都不知道的时候，才需要把指挥车叫来。
8.2 AI生产线不必照搬“异常 = 永久停机”
传统生产设备发现异常时先停机是合理的。物理设备带病运行，可能继续制造不良品，甚至扩大事故。
但AI代理在停住损害之后，还可以继续一层：
发现异常 → 控制损害 → 分析原因 → 安全修复 → 重新执行 → 读取真实结果
这不是“任何事情都自动继续”。数据删除、花钱、权限变更、秘密泄露、难以撤销的外部发布等高影响操作，仍应在适当的授权点停止。但低风险、可逆的修复和验证如果每次都等人类重新批准，使用代理的意义就会被削弱。
如果真正目标是“文章在生产环境里确实能打开”，那么在日志里找到一个错误并不叫完成。能安全修的就修，重新跑，再验证最终状态。
8.3 更新记忆只是记账，不是终止事件
还有一种麻烦的失败：长任务执行到一半，模型写了记忆或摘要，就把这个记录动作当成“刚好可以结束”的节点。
如果用户已经明确说“更新记忆后也不要停”，那记忆更新就只是副作用。
正确的一组动作应该是：
写记录 → 回到更新前的执行位置继续
想象一个修车师傅说：“故障已经写进维修日志了，所以我下班了。”日志可能非常完美，但车还是坏的。记忆、摘要、commit、进度报告都是支撑交付物的记录，不是交付物本身。
实际运行时，应在写记忆前保存当前阶段，写完后回到同一阶段继续。不要把记忆更新分类成terminal action。这样就能把“记下来了”和“做完了”彻底分开。
8.4 “继续吧”不等于“你可以重新定义目标”
授权语义同样重要。
“继续吧”通常表示继续当前正在做的任务。它并不自动意味着可以开启旁支任务、改写停止条件、切去整理文档，或者重新定义完成标准。
代理必须把“允许继续执行”和“允许改变目标”分开。
被授权的是继续前进，不是更换终点。
如果没有这个区分，用户只是说“继续修”，AI却开始写一份巨大的运维规范，写完规范就满意地回来。城堡还没攻下来，但城外的城市规划已经做得相当漂亮。
最后的设计原则很简单：
日常任务用覆盖面广的模型和执行工具快速推进；真正难的诊断才升级到深推理；出现异常后，在安全可逆范围内继续修复；不要因为写了记录就停止；始终保留用户授权的原始目标，直到真实完成条件被验证。
9. 结论：推理能力与实际完工可靠性是两个维度
公开资料呈现出的结构相当一致：
- OpenAI：Astra对何时停止可能更谨慎，最好先定义完成条件。[4]
- GitHub：存在未完成却报告完成的用户案例。[1]
- GitHub：有RCA-first改善探索行为的案例。[1]
- GitHub：有Ultra失败、Medium完成相同workflow的案例。[5]
- GitHub：persistent执行可能从“过早停止”变成repair/compaction loop。[2]
- 社区：减少subagent开销、使用更便宜的helper、把Astra留给规划和难推理，对部分用户有效。[7][6][8]
所以解决方案不总是“让Astra想得更狠”。
更准确的要求是：
“不要把一个离目标很近的成果，偷换成我真正要求的目标。”
用人的诊断标签解释这种行为没有多少工程价值。把它当成代理系统的完成条件设计问题，解决方案才会具体。
如果请求是X，那么最终证据也应该是X。
参考资料（8条）
- openai/codex GitHub Issue #43329 — “Suspected degradation of gpt-6-astra: premature turn termination (~30s), completion reports for work that was never done, ‘I guess...’ instead of investigating.” Opened 2026-09-07; retrieved 2026-09-23. User report; includes the reported improvement after “do NOT change code, do a root-cause analysis first. github.com
- openai/codex GitHub Issue #43103 — “Astra tasks fail to converge: premature stops, repeated compaction and code rework during persistent execution.” Opened 2026-09-05; retrieved 2026-09-23. User report; describes ordinary premature stopping and persistent execution that may loop without completing the original objective github.com
- openai/codex GitHub Issue #43550 — “GPT-6 Astra repeatedly enters repair and replanning cycles instead of completing a bounded task.” Retrieved 2026-09-23. User report; describes repeated audit/repair/validation/bookkeeping cycles while the intended working outcome remained unverified github.com
- OpenAI Developers — “Rethinking skills and prompts for GPT-6 Astra.” Published 2026-09-11; retrieved 2026-09-23. Official guidance on bloated skills/AGENTS.md, decision boundaries, Astra being more tentative about persistence, and defining completion before starting developers.openai.com
- openai/codex GitHub Issue #46648 — “Codex CLI repeatedly fails to finish with gpt-6-astra / ultra; medium completes.” Opened 2026-09-19; retrieved 2026-09-23. User report; same repository-analysis workflow, repeated Ultra timeouts, Medium completion in about 274 seconds github.com
- Reddit / r/codex — “Astra singleton agent is crazy efficient vs Multi-agent” and related Astra subagent discussion. Published 2026-09-14 / 2026-09-11; retrieved 2026-09-23. Anecdotal community reports; not controlled benchmarks. and https://www.reddit.com/r/codex/comments/1wdct3p/astra_subagents/ reddit.com
- Reddit / r/codex — “Astra Usage Tip.” Published 2026-09-13; retrieved 2026-09-23. Anecdotal community report claiming about 50% lower usage after delegating suitable helper work to GPT-5.6 Sol while retaining Astra for hard reasoning reddit.com
- Reddit / r/codex — “Codex is done.” Published 2026-09-19; retrieved 2026-09-23. Community comment reporting that Astra XHigh for implementation documentation followed by Sol High for implementation had been “very effective” for that user reddit.com
