要求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形成過度約束。Skill太多也會擠壓context，使描述被壓縮或互相衝突。[4]
以前的安全護欄，對新模型可能變成迷宮牆壁。
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中，同一個read-only repository analysis workflow使用Astra Ultra多次執行，在1200秒與1800秒timeout下仍未產生完成結果。一次失敗中tool call與subagent都已結束，但root agent沒有輸出最終JSON，也沒有completion event。相同workflow改用Medium後約274秒完成，exit code 0，出現turn.completed，且JSON符合schema。[5]
這只是一個Issue，不是控制實驗。另一些使用者反而覺得Max設定很有效率。[6]
合理結論不是「Medium永遠比較好」，而是：
增加推理量，不等於增加完成可靠性。
6. Goal mode與subagent也不是自動解藥
看到提早停止，很自然會想說：「那就不要停，一直做。」
但Issue #43103回報了另一個極端：一般執行會在成果完成前停止，persistent goal-style execution則持續消耗額度，反覆context compaction、重寫程式、再驗證，原始目標仍沒有完成。[2]
於是可能變成：
停太早 →「永遠不要停」 → 現在真的不會停了
subagent也有類似取捨。社群有人回報Astra-heavy的multi-agent會大量消耗使用量，而singleton Astra或不使用subagent更有效率。[6] 也有人把適合的輔助工作交給GPT-5.6 Sol，回報使用量約下降50%且品質沒有明顯差異。[7] 還有人用Astra XHigh寫實作文件，再由Sol High負責實作，稱效果很好。[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、log與目前runtime狀態，再去做實際修改。Astra在複雜因果分析上仍然很有價值，但它使用量較重，而且一旦讓它從分析一路做到實作，有時會轉去追別的論點，或在奇怪的節點停下來。
與其要求每個模型都成為全能選手，不如只用它最凸出的那一塊。
8.1 把Astra放在升級診斷的位置，而不是每次都預設呼叫
日常循環用Sol和Codex。
讓Codex蒐集current main、最近log、runtime state、receipt、production readback等事實。讓Sol根據這些事實形成原因假設與修復方案。接著由Codex或執行環境真正修改、測試，並讀取實際結果。
只有出現以下情況時才升級到Astra：
- 同一個故障修了幾次仍然復發；
- 清掉log裡最直接的錯誤後系統還是沒修好；
- 多個層級對「目前狀態」的描述互相衝突；
- 原因候選越來越多，一般診斷無法收斂。
這時Astra的工作不是「全部做完」，而是建立原因樹，用證據剪掉錯誤分支，確定根因與修復規格。真正實作再交回Sol / Codex。
沒必要讓最昂貴的大腦整天怠速。只有連火到底在哪裡都不知道時，才需要把指揮車叫來。
8.2 AI生產線不必照搬「異常 = 永久停機」
傳統生產設備發現異常時先停機是合理的。物理設備帶病運轉，可能繼續製造不良品，甚至擴大事故。
但AI代理在先把損害停住之後，還可以多做一層：
發現異常 → 控制損害 → 分析原因 → 安全修復 → 重新執行 → 讀取真實結果
這不是「任何事情都自動繼續」。資料刪除、花錢、權限變更、秘密外洩、難以撤銷的外部發布等高影響操作，仍應在適當的授權點停下來。但低風險、可逆的修復與驗證如果每次都等人類重新批准，使用代理的價值就會被削弱。
如果真正目標是「文章在正式環境裡真的能打開」，那麼在log裡找到一個錯誤不叫完成。能安全修的就修，重新跑，再驗證最後狀態。
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]
因此需要的未必是「想得更用力」。
更重要的是：
「不要把接近目標的其他成果，替換成我真正要求的目標。」
用人的診斷名稱去形容這種AI行為，工程上幫助不大。把它視為代理系統的完成條件與停止條件問題，改善方法才會清楚。
要求是X，最後的證據也應該是X。
資料來源
- 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
