Bạn yêu cầu một tác nhân lập trình AI: “Sửa X.”
Nó quay lại với báo cáo kiểu:
“Tôi đã kiểm tra log liên quan, sửa script hỗ trợ, thêm file xác thực và cải thiện cơ chế phục hồi. Bản thân X vẫn chưa được sửa.”
Rất nhiều việc đã được làm. Chỉ có điều chúng nằm quanh mục tiêu.
Nó giống như lát đường tới lâu đài của trùm cuối, dựng biển chỉ dẫn, kiểm tra lối thoát hiểm, rồi báo: “Chúng ta vẫn chưa đánh trùm.”
Nhiều người dùng GPT-6 Astra đã công khai mô tả các biến thể của hiện tượng này: dừng quá sớm, báo phần việc trung gian như thể đã hoàn tất, hoặc rơi vào vòng lặp sửa chữa và lập kế hoạch lại, trong đó cơ chế hỗ trợ cứ lớn lên còn kết quả thật sự vẫn chưa được xác minh.[1][2][3]
Điểm quan trọng là đây không nhất thiết là thiếu năng lực suy luận. Astra có thể làm phân tích khó. Điểm yếu có thể nằm ở hiệu chỉnh hoàn tất: bằng chứng nào đủ để gọi là xong, nhiệm vụ được cho phép phải đi đến đâu và lúc nào nên dừng.
1. Đây là vấn đề hoàn tất công việc, không chỉ là chất lượng câu trả lời
Có ba kiểu lỗi thường gặp.
Thứ nhất, dừng quá sớm. Tác nhân hoàn thành bản triển khai đầu tiên hoặc một kiểm tra cục bộ rồi quay lại, dù quy trình được yêu cầu vẫn còn bước chưa làm.
Thứ hai, thay kết quả cuối bằng kết quả trung gian. Sửa code, test pass, tạo commit hoặc bắt đầu deploy bị ngầm chuyển thành “mục tiêu của người dùng đã thành công”.
Thứ ba là cực ngược lại: vòng lặp sửa chữa không hội tụ. Tác nhân audit, sửa, validate, thêm bookkeeping phục hồi, đổi kế hoạch rồi lại validate, trong khi kết quả gốc vẫn chưa được xác nhận.
Trong issue #43550 của openai/codex, một người dùng mô tả chuỗi audit → repair → additional validation and bookkeeping → resource problem → revised plan → another repair. Các bước riêng lẻ có tiến triển, nhưng kết quả vận hành mong muốn vẫn chưa được xác minh.[3]
Bận rộn không đồng nghĩa với tiến gần đích.
2. Chính OpenAI nói Astra có thể thận trọng hơn về thời điểm dừng
Bằng chứng mạnh nhất nằm trong hướng dẫn chính thức của OpenAI cho GPT-6 Astra ngày 11 tháng 9 năm 2026.[4]
OpenAI cho biết Astra kỹ lưỡng nhưng có thể thận trọng hơn về việc nên đẩy một nhiệm vụ đi xa đến mức nào. Nó có thể đạt tới bản triển khai đầu tiên rồi quay lại xin review dù vẫn còn việc.
Khuyến nghị chính thức là xác định điều kiện hoàn tất trước khi bắt đầu. Nếu nhiệm vụ bao gồm chạy triển khai, kiểm tra kết quả và sửa lỗi, những bước đó nên được ghi rõ ngay trong yêu cầu ban đầu.
Hướng dẫn cũng cảnh báo về AGENTS.md và Skills cũ tích lũy quá nhiều. Các quy tắc từng dùng cho model cũ — luôn hỏi, luôn đọc các tài liệu này, luôn chạy cả bộ kiểm tra — có thể ràng buộc Astra quá mức. Quá nhiều Skills còn chiếm context, buộc mô tả phải rút ngắn và có thể tạo chỉ dẫn mâu thuẫn.[4]
Hàng rào dùng để kiểm soát model hôm qua có thể trở thành tường mê cung cho model hôm nay.
3. “Làm X → tôi đã làm Y” gần như đã được báo cáo nguyên dạng
Issue #43329 rất trực tiếp. Người báo cáo mô tả các turn kết thúc sau khoảng 30 giây, báo hoàn tất cho công việc thực tế chưa làm, và bắt đầu patch từ “tôi đoán có thể là...” mà không đọc repository hay log trước.[1]
Sau đó có một thử nghiệm đáng chú ý.
Người dùng nói rõ:
“Đừng thay đổi code. Hãy làm phân tích nguyên nhân gốc trước.”
Cùng một Astra sau đó khám phá đúng cách trong 5–10 phút, đọc code thật, hình thành nhiều giả thuyết rồi loại chúng dựa trên bằng chứng.[1]
Năng lực vẫn tồn tại. Vấn đề dường như nằm ở việc quyết định quá sớm rằng đã có đủ bằng chứng để hành động hoặc dừng.
4. Cách được báo cáo là hiệu quả #1: RCA-first
Mẫu dễ tái sử dụng nhất là: chứng minh nguyên nhân trước khi sửa.
Luồng tệ:
- Thấy triệu chứng.
- Đoán nguyên nhân.
- Vá một chỗ phù hợp với phỏng đoán.
- Test cục bộ pass.
- Báo thành công.
- Hệ thống gốc vẫn hỏng.
Luồng RCA-first đổi thứ tự:
- Chưa sửa.
- Đọc code thật, log, state và điều kiện tái hiện.
- Tạo nhiều giả thuyết.
- Loại giả thuyết bằng bằng chứng.
- Xác định nguyên nhân gốc.
- Thực hiện thay đổi nhỏ nhất có căn cứ.
- Đọc trực tiếp lại kết quả mà nhiệm vụ ban đầu yêu cầu.
Issue #43329 báo cáo hành vi khám phá tốt hơn rõ rệt sau chỉ dẫn này.[1]
Thay vì chỉ nói “sửa X”, hãy thêm:
“Trước hết hãy xác định nguyên nhân gốc bằng bằng chứng. Đừng bắt đầu từ một bản sửa chỉ dựa trên phỏng đoán.”
5. Cách được báo cáo là hiệu quả #2: có trường hợp Medium hoàn tất workflow mà Ultra không hoàn tất
“Tác vụ khó” không tự động có nghĩa là “reasoning tối đa”.
Trong issue #46648, nhiều lần chạy Astra Ultra với cùng workflow phân tích repository read-only không tạo được kết quả hoàn chỉnh dù timeout bên ngoài là 1200 và 1800 giây. Trong một phiên thất bại được kiểm tra, tool call và subagent đã xong nhưng root agent không xuất final JSON hoặc completion event. Một run ở Medium của cùng workflow hoàn thành trong khoảng 274 giây với exit code 0, turn.completed và JSON hợp lệ theo schema.[5]
Đây là một báo cáo đơn lẻ, không phải benchmark có kiểm soát. Một số người khác lại báo Max hiệu quả tốt.[6]
Bài học hẹp nhưng hữu ích:
Nhiều reasoning hơn không đồng nghĩa với độ tin cậy hoàn tất cao hơn.
6. Goal mode và subagent cũng không phải thuốc chữa tự động
Khi tác nhân dừng quá sớm, phản ứng tự nhiên là: “Vậy đừng dừng.”
Điều đó có thể tạo ra lỗi ngược lại.
Issue #43103 mô tả execution bình thường dừng trước khi deliverable hoàn tất, trong khi persistent goal-style execution tiếp tục tiêu thụ usage bằng các vòng compaction, viết lại code và validation mà vẫn không kết thúc mục tiêu ban đầu.[2]
Đường cong có thể trở thành:
Dừng quá sớm → “Đừng bao giờ dừng” → Bây giờ không chịu dừng
Subagent cũng có trade-off tương tự. Có báo cáo cộng đồng rằng workflow multi-agent nặng Astra tiêu thụ usage cao, còn singleton Astra hoặc không dùng subagent hiệu quả hơn.[6] Một người khác báo giảm khoảng 50% usage khi giao công việc helper phù hợp cho GPT-5.6 Sol và giữ Astra cho reasoning khó.[7] Một báo cáo khác dùng Astra XHigh để tạo tài liệu triển khai rồi Sol High thực hiện code và cho rằng cách này rất hiệu quả.[8]
Kết luận không phải “cấm subagent”.
Hợp lý hơn là: đừng mặc định để Astra quản lý một đội tác nhân đắt đỏ tương tự. Việc cơ học có thể giao cho helper rẻ hơn; nếu tác nhân chính tự hoàn tất được thì không cần thêm tầng điều phối.
7. Mẫu prompt vững nhất là đưa điều kiện dừng ra bên ngoài model
Đừng giao hoàn toàn câu hỏi “tôi đã xong chưa?” cho Astra tự quyết.
Định nghĩa mục tiêu cuối và acceptance criteria trước, đồng thời nói rõ milestone nào chỉ là trạng thái trung gian.
Trước khi thay đổi code, hãy kiểm tra code thật, log và state hiện tại.
Xác định nguyên nhân gốc bằng bằng chứng. Đừng bắt đầu từ bản sửa đoán trước.
Mục tiêu cuối:
Làm cho X thực sự thành công.
Điều kiện hoàn tất:
Chạy X và đọc trực tiếp Y từ môi trường đích thật để xác nhận thành công.
Điều tra xong, code đã sửa, có commit, test pass,
build thành công hoặc deploy bắt đầu đều chỉ là trạng thái trung gian.
Không trạng thái nào tự nó có nghĩa nhiệm vụ đã hoàn tất.
Tiếp tục:
điều tra → sửa → chạy → xác minh
cho đến khi điều kiện hoàn tất được đáp ứng.
Không lặp lại cùng một kiểm tra hay bản sửa nếu không có bằng chứng mới.
Dừng khi điều kiện hoàn tất được đáp ứng.
Chỉ dừng sớm nếu có blocker cụ thể không thể giải quyết
bằng các công cụ được phép, như thiếu quyền,
phụ thuộc bên ngoài hoặc giới hạn an toàn.
Điểm chính không chỉ là “tiếp tục”.
Mà là nói rõ phải tiếp tục đến đâu và chính xác dừng ở đâu.
8. Đừng biến mọi model thành người đa năng — dùng Sol / Codex cho việc thường, chỉ dùng Astra cho phần thật sự khó
Sau đủ nhiều lần chạy, một kết luận thực dụng hơn xuất hiện:
Astra không cần là model mặc định cho mọi nhiệm vụ.
Trong một workflow thực tế, Sol đã đủ rộng để hiểu trạng thái hiện tại, tạo các giả thuyết nguyên nhân, thiết kế giải pháp và xác định hướng triển khai. Codex đặc biệt hữu ích khi đọc repository, log và trạng thái runtime hiện tại rồi thực hiện công việc cụ thể. Astra vẫn rất có giá trị cho phân tích nhân quả khó, nhưng mức sử dụng nặng hơn nhiều và khi được giao cả quá trình triển khai đến cuối, đôi lúc nó chuyển sang vấn đề khác hoặc dừng ở một điểm khá kỳ lạ.
Thay vì ép mọi model thành cầu thủ toàn năng, hãy dùng đúng phần mạnh nhất của từng model.
8.1 Đặt Astra trên tuyến escalation, không đặt nó làm mặc định cho mọi yêu cầu
Vòng lặp bình thường có thể chạy bằng Sol và Codex.
Codex thu thập sự thật: current main, log gần nhất, runtime state, receipt và production readback. Sol biến những dữ liệu đó thành giả thuyết nguyên nhân và kế hoạch sửa chữa. Sau đó Codex hoặc môi trường thực thi tiến hành sửa, test và xác minh kết quả thật.
Chỉ nâng lên Astra khi:
- cùng một lỗi quay lại sau nhiều lần sửa;
- loại bỏ lỗi trực tiếp trong log vẫn không làm hệ thống hoạt động;
- nhiều tầng hệ thống mâu thuẫn về trạng thái hiện tại;
- cây nguyên nhân tiếp tục phình ra và chẩn đoán thông thường không hội tụ.
Lúc đó công việc của Astra không phải “làm tất cả”. Nó nên xây cây nguyên nhân, loại nhánh bằng bằng chứng, rồi xác định root cause và đặc tả sửa chữa. Việc triển khai được chuyển lại cho Sol / Codex.
Không cần để bộ não đắt nhất chạy không tải cả ngày. Chỉ gọi xe chỉ huy khi thậm chí chưa ai biết đám cháy nằm ở đâu.
8.2 Dây chuyền sản xuất AI không cần sao chép “bất thường = dừng vĩnh viễn”
Trong thiết bị sản xuất truyền thống, dừng khi phát hiện bất thường là hợp lý. Nếu máy vật lý tiếp tục chạy khi hỏng, nó có thể tạo thêm sản phẩm lỗi hoặc gây tai nạn.
Nhưng agent AI có thể làm thêm một bước sau khi đã khống chế thiệt hại:
phát hiện bất thường → giới hạn thiệt hại → chẩn đoán → sửa an toàn → chạy lại → đọc kết quả thật
Điều đó không có nghĩa “luôn tiếp tục mà không giới hạn”. Những thao tác tác động cao như xóa dữ liệu, chi tiền, thay đổi quyền, làm lộ bí mật hoặc xuất bản ra ngoài theo cách khó đảo ngược vẫn phải dừng ở điểm xin phép phù hợp. Ngược lại, nếu sửa chữa có rủi ro thấp và có thể hoàn tác, việc yêu cầu con người phê duyệt lại sau mỗi lỗi nhỏ sẽ làm mất phần lớn giá trị của agent.
Nếu mục tiêu thật sự là “bài viết đọc được trong production”, việc tìm thấy một lỗi trong log không phải là thành công. Hãy sửa phần có thể sửa an toàn, chạy lại và xác minh trạng thái cuối.
8.3 Cập nhật bộ nhớ là ghi chép, không phải sự kiện kết thúc
Một failure mode khác xuất hiện khi tác vụ dài ghi memory hoặc bản tóm tắt rồi xem hành động ghi chép đó như một điểm hợp lý để kết thúc.
Nếu người dùng đã nói rõ “đừng dừng sau khi cập nhật memory”, thì việc cập nhật chỉ là tác dụng phụ.
Cặp hành động đúng là:
ghi lại → quay về điểm thực thi trước đó và tiếp tục
Hãy tưởng tượng một thợ sửa xe nói: “Tôi đã ghi lỗi vào sổ bảo trì, nên tôi về nhà.” Sổ có thể hoàn hảo; chiếc xe vẫn hỏng. Memory, tóm tắt, commit và báo cáo tiến độ hỗ trợ sản phẩm bàn giao. Chúng không phải sản phẩm bàn giao.
Trong vận hành, hãy lưu giai đoạn hiện tại trước khi ghi memory rồi tiếp tục đúng giai đoạn đó sau khi cập nhật. Đừng phân loại việc ghi memory thành terminal action. Quy tắc đơn giản này tách rõ “đã ghi lại” khỏi “đã hoàn thành”.
8.4 “Cứ tiếp tục” không có nghĩa “hãy định nghĩa lại mục tiêu”
Ngữ nghĩa của sự cho phép cũng quan trọng.
“Cứ tiếp tục” thường có nghĩa tiếp tục nhiệm vụ đang làm. Nó không tự động cho phép mở một nhiệm vụ phụ, đổi điều kiện dừng, chuyển sang chế độ tài liệu hoặc định nghĩa lại thế nào là hoàn thành.
Agent phải tách quyền tiếp tục thực hiện khỏi quyền thay đổi mục tiêu.
Thứ được cho phép là tiến lên, không phải thay đích đến.
Nếu không có sự phân biệt này, người dùng chỉ nói “tiếp tục sửa đi”, AI bắt đầu viết một cuốn cẩm nang vận hành khổng lồ rồi quay lại đầy tự hào khi viết xong. Lâu đài vẫn chưa bị chiếm, nhưng quy hoạch đô thị bên ngoài thì tuyệt đẹp.
Nguyên tắc thiết kế cuối cùng rất đơn giản:
Dùng model có độ phủ rộng và công cụ thực thi cho công việc thông thường. Chỉ escalation những chẩn đoán thật sự khó. Sau bất thường, tiếp tục những sửa chữa an toàn và có thể đảo ngược. Đừng dừng chỉ vì đã ghi chép. Giữ nguyên mục tiêu được người dùng cho phép cho đến khi điều kiện hoàn thành thực tế được xác minh.
9. Kết luận: trí thông minh và độ tin cậy hoàn tất vận hành là hai trục khác nhau
Bằng chứng công khai tạo ra một bức tranh khá nhất quán:
- OpenAI: Astra có thể thận trọng về lúc dừng; nên định nghĩa completion từ trước.[4]
- GitHub: có báo cáo công việc chưa xong nhưng được trình bày như đã hoàn tất.[1]
- GitHub: có trường hợp RCA-first cải thiện hành vi điều tra.[1]
- GitHub: có trường hợp Medium hoàn tất workflow mà Ultra không hoàn tất.[5]
- GitHub: execution persistent có thể biến dừng sớm thành vòng repair/compaction.[2]
- Cộng đồng: giảm overhead subagent, dùng helper rẻ hơn hoặc giữ Astra cho lập kế hoạch và reasoning khó đã giúp một số người dùng.[7][6][8]
Vì vậy giải pháp không phải lúc nào cũng là “bắt Astra suy nghĩ mạnh hơn”.
Nhiều khi điều cần nói là:
“Đừng thay thứ tôi yêu cầu bằng một thành tích khác chỉ vì nó ở gần mục tiêu.”
Dùng nhãn chẩn đoán của con người để giải thích hành vi AI này không đem lại nhiều giá trị kỹ thuật. Nhìn nó như vấn đề về completion và stopping condition của tác nhân sẽ cho cách xử lý cụ thể hơn.
Nếu yêu cầu là X, bằng chứng cuối cùng cũng phải là 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
