Dùng /goal hiệu quả: autonomous agent là hợp đồng vận hành, không phải nút thần kỳ (2026)

- /goal là tính năng của Codex, đang ở dạng feature-flag và đổi nhanh; cú pháp và hành vi nêu ở đây đã đối chiếu với tài liệu chính thức tại thời điểm viết, hãy kiểm tra lại docs live trước khi phụ thuộc.

/goal là gì (và không phải là gì)?

/goal là chế độ goal mode của Codex (OpenAI Codex CLI) cho một mục tiêu dài, mang tính cơ học, có điều kiện dừng verify được. Bạn bật nó qua /experimental hoặc thêm goals = true trong mục [features] của config.toml, rồi chạy /goal <mục tiêu>. Trong lúc chạy, gõ /goal để xem trạng thái; điều khiển bằng /goal pause, /goal resume, /goal clear.

Và đây là phần quan trọng nhất: /goal không phải một safety boundary, không thay quyết định sản phẩm, và không phải chỗ để chạy một backlog vô hạn. Nó là một vòng lặp bền bỉ, không hơn. (Lưu ý: /goal là của Codex, không phải lệnh native của Claude Code - đừng nhầm hai thứ.) Chi tiết cú pháp xem hướng dẫn goal mode chính thức.

Sự thật phũ: /goal chỉ khiến agent "lì" hơn, không "khôn" hơn

Nhiều người tung hô /goal như nút "bấm một phát app tự build". Mình lạm dụng nó một tuần và ăn tát sạch. Kết luận đơn giản: /goal không làm agent thông minh hơn, nó làm agent kiên trì hơn. Kiên trì đúng hướng thì tuyệt vời; kiên trì sai hướng thì cực kỳ mệt - vì nó sẽ lao mãi theo hướng sai mà không dừng lại tự hỏi.

Ba "cái tát" dưới đây là ba kiểu sai hay gặp nhất, và bài học rút ra.

Cái tát #1 - Boundary trôi sau auto-compact (deploy nhầm production)

Mình ghi goal rất rõ: chỉ deploy lên staging. Nhưng sau vài lần auto-compact, agent trôi khỏi ngữ cảnh, quên mất ranh giới, và deploy thẳng lên production - dù đã có một hook nhắc lại task sau mỗi lần compact.

Bài học đau: đừng bao giờ cấp cho agent quyền truy cập production. Đừng tin vào câu "nó sẽ nhớ". Không - nó không nhớ đáng tin như bạn nghĩ đâu. Đây đúng là lý do vì sao goal mode không phải một safety boundary: ranh giới an toàn phải nằm ở phân quyền, không nằm ở lời dặn trong prompt. Xem thêm cách siết quyền ở bài permissions & an toàn trong Claude Code và bảo mật AI coding thực chiến.

Cái tát #2 - Goal mơ hồ = giấy phép đi lạc

"Làm đẹp hơn đi." "Cải thiện UX." Nghe rất người. Nhưng với một agent, đó là giấy phép để đi lạc. Nó sửa một chỗ, làm hỏng chỗ khác, hallucinate một tí, và đôi khi dừng sớm trong khi chẳng có gì rõ ràng tốt lên.

Bài học: một goal phải định nghĩa được "tốt hơn" nghĩa là gì. Đẹp hơn kiểu nào?

• Spacing chặt hơn?
• Contrast dễ đọc hơn?
• Responsive tốt hơn trên mobile?
• Ít bước checkout hơn?
• Completion rate cao hơn?

Nếu bạn còn chưa biết mình muốn gì, đừng quăng cho agent rồi chạy /goal. Hãy brainstorm trước, plan, viết acceptance criteria. Chưa rõ yêu cầu thì một cuộc hỏi cố vấn để làm rõ (advisor/kongming) đáng giá hơn là bật autonomous. Cách viết plan có tiêu chí kiểm tra rõ ràng nằm ở bài lập kế hoạch cho Claude Code.

Cái tát #3 - Thiếu verify (agent tự tin báo "done" giả)

Mình đặt goal cho một trang frontend mới, nhưng quên bảo agent dùng agent-browser để verify hình ảnh. Kết quả? Nó bỏ qua bước verify thật và tự tin báo "completed successfully". Rồi mình mở ra xem và nhớ ra đời không như mơ.

Bài học: đừng tin ai cả. Cấp đúng công cụ, và bắt buộc agent phải dùng chúng trước khi kết thúc. Test xanh là chưa đủ:

• Frontend phải được nhìn (screenshot/agent-browser).
• Workflow phải được click chạy thử.
• Deploy phải kiểm tra môi trường.
• PR phải soi diff.

Operating contract - công thức cho một /goal tốt

Tóm lại: một /goal tốt không phải là một prompt khôn khéo. Nó là một hợp đồng vận hành, gồm năm phần:

Đây cũng khớp với "bài test khi nào nên dùng goal": chỉ dùng khi tác vụ (1) dài hơn một lượt và mang tính cơ học, (2) có điều kiện dừng verify được, và (3) scope đủ rõ để tiến mà không cần quyết định sản phẩm ở mỗi checkpoint. Đừng dùng /goal cho việc thăm dò, yêu cầu mơ hồ, đổi credential production, phá hạ tầng chung, hay một backlog hổ lốn.

Cách mình dùng /goal: tách "ngày plan" khỏi "đêm execute"

Cách mình thích nhất bây giờ là tách phần tư duy ban ngày khỏi phần thực thi ban đêm.

Ban ngày (tư duy)

1. Tạo GitHub issue cho từng bug / feature / enhancement.
2. Dùng skill brainstorm & plan để làm rõ từng issue.
3. Reply vào issue bản tóm tắt cách làm + link tới plan.md.
4. Gắn nhãn ready to implement.
5. Lặp lại cho tới khi mọi issue đã sẵn sàng.

Ban đêm (thực thi)

Trước khi nghỉ và dành thời gian cho gia đình, mình cho /goal chạy: "Implement mọi issue có nhãn ready-to-implement dựa trên các plan đã định." Vòng lặp cho từng issue:

1. Sắp xếp issue theo độ ưu tiên.
2. Làm một issue mỗi lần.
3. Tạo worktree và branch riêng cho mỗi issue.
4. ak:cook --auto (thực thi liên tục theo plan).
5. ak:code-review.
6. ak:ship beta.
7. ak:review-pr --fix.
8. Gắn nhãn ready to ship, rồi sang issue kế tiếp.

Cách này chạy tốt hơn hẳn. Agent không còn đoán "bạn muốn gì?" nữa - nó thực thi dựa trên một plan đã làm rõ, với branch riêng, review riêng, deploy beta, PR và nhãn. Sáng dậy, pha ly cà phê, mở máy, và có sẵn một chồng PR đang chờ. Việc của mình không còn là gõ "continue" như một ông quản lý vi mô, mà là review bằng mắt người, test lại, rồi merge. Muốn hiểu cách chạy worktree/PR song song, xem orchestrate nhiều subagents; đặt vòng lặp này vào quy trình brainstorm → plan → cook → ship.

Muốn bộ gate dựng sẵn để chạy loop đêm? (AgentKit)

Vòng lặp đêm mạnh nhờ các "gate" chất lượng: ak:cook, ak:code-review, ak:ship, ak:review-pr. AgentKit đóng gói sẵn những gate này và chạy trên cả Claude Code lẫn Codex - nên hợp với /goal của Codex. Nói thẳng: /goal là của Codex và miễn phí; bộ kit chỉ thêm vào bộ quy trình + review dựng sẵn để bạn khỏi tự ghép. Muốn xem chi tiết, đọc review AgentKit hoặc review Engineer Kit.

Giá trị thật của /goal

Đó mới là giá trị thật của /goal: không phải để agent nghĩ hộ bạn, mà để agent gánh phần thực thi lặp lại sau khi bạn đã nghĩ xong. Bạn làm phần tư duy - đặc tả, plan, acceptance criteria - rồi để nó cày. Việc của bạn là review bằng mắt người, test lại, rồi merge.

Câu hỏi thường gặp (FAQ)

/goal là gì và của công cụ nào?

/goal là goal mode của Codex (OpenAI Codex CLI), đang ở dạng feature-flag: bật bằng /experimental hoặc goals = true trong [features] của config.toml. Nó KHÔNG phải lệnh native của Claude Code - đừng nhầm hai thứ.

Khi nào KHÔNG nên dùng /goal?

Với việc thăm dò, yêu cầu mơ hồ, đổi credential production, thao tác phá hạ tầng dùng chung, hoặc một backlog hổ lốn không rõ scope. /goal hợp với tác vụ cơ học, dài, có điều kiện dừng verify được.

Làm sao viết một goal tốt?

Coi nó như một hợp đồng vận hành gồm 5 phần: Outcome (xong nghĩa là gì), Scope (được/không được đụng đâu), Constraints (ranh giới không được phá), Verification (chứng minh xong bằng cách nào), và Stop rules (khi nào dừng/hỏi người).

/goal có tự deploy production an toàn không?

Không nên. Đừng cấp cho agent quyền production; goal mode không phải một safety boundary. Ranh giới an toàn phải đặt ở phân quyền (least-privilege), không nằm ở lời dặn trong prompt - vì sau vài lần auto-compact agent có thể quên ranh giới.

Test xanh có đủ để agent báo "done" không?

Không. Frontend phải được nhìn (screenshot/agent-browser), workflow phải được click chạy thử, deploy phải kiểm tra môi trường, và PR phải soi diff. Hãy cấp đúng công cụ và bắt buộc agent dùng trước khi kết thúc.

Cần AgentKit để dùng /goal không?

Không. /goal là của Codex và miễn phí. AgentKit chỉ thêm bộ gate ak:cook / ak:code-review / ak:ship / ak:review-pr để chạy trong vòng lặp - tiện nếu bạn muốn quy trình dựng sẵn thay vì tự ghép.

Kết luận

Đừng thần thánh hóa /goal. Nó là một vòng lặp lì lợm - hữu ích khi bạn đã nghĩ xong và chỉ cần thực thi lặp lại. Viết goal như một hợp đồng vận hành, siết quyền production, bắt buộc verify, và tách ngày-plan khỏi đêm-execute. Cần làm rõ yêu cầu trước khi chạy? Xem advisor vs kongming. Cần plan có acceptance criteria? Xem lập kế hoạch cho Claude Code.