Cách sử dụng Goals trong Codex

• Goals là tính năng mục tiêu bền vững (persistent objective) giúp một luồng Codex tiếp tục làm việc qua nhiều lượt để hướng tới một kết quả đã được xác định
• Phù hợp với các tác vụ khó xử lý bằng một prompt đơn lẻ như profiling, vá lỗi, benchmarking, tái hiện bài test flaky, kiểm toán dựa trên bằng chứng
• Khi định nghĩa kết quả (outcome), phương thức xác minh (verification surface) và ràng buộc (constraints), Codex có thể tự đánh giá việc hoàn tất dựa trên bằng chứng
• Có thể điều khiển vòng đời bằng các lệnh /goal, /goal pause, /goal resume, /goal clear, được hỗ trợ từ Codex 0.128.0
• Đây là cấu trúc hợp đồng hoàn tất (completion contract) bị giới hạn trong phạm vi luồng, và trọng tâm là tính bền vững dưới sự kiểm soát của người dùng, chứ không phải thực thi tự động vô hạn

---

Định nghĩa Goals và bối cảnh ra đời

• Goals là tính năng trao cho Codex một điều kiện hoàn tất (completion condition), định nghĩa điều gì phải đúng, cách kiểm tra thành công và những ràng buộc nào cần được giữ nguyên
• Codex vốn đã hoạt động tốt với các tác vụ lập trình có phạm vi rõ ràng như kiểm tra kho mã, sửa lỗi, thêm test, giải thích lỗi thất bại, hoặc triển khai các thay đổi tập trung
• Goals phù hợp với các tác vụ mà bước tiếp theo thay đổi tùy theo những gì Codex học được trong quá trình thực hiện
  • profiling, vá lỗi, benchmarking, tái hiện bài test flaky, hoặc chuyển một câu hỏi nghiên cứu thành kiểm toán dựa trên bằng chứng
• Những tác vụ này không cần prompt dài hơn mà cần một mục tiêu bền vững
• Khi Goal được kích hoạt, Codex sẽ giữ mục tiêu, đánh giá xem đã hoàn tất chưa và chọn hành động tiếp theo mà không cần phải nhắc lại mục tiêu ở mỗi kết quả trung gian
• Goal không phải là cơ chế tự trị nền không có ranh giới, mà là một hợp đồng hoàn tất có phạm vi xác định và nằm dưới sự kiểm soát của người dùng

Quickstart: Cách dùng Goals

• Hãy dùng Goal cho những tác vụ mà đích đến rõ ràng nhưng con đường đi tới đó chưa chắc chắn
  • Ứng viên phù hợp: tối ưu hiệu năng, điều tra test flaky, di chuyển phụ thuộc, truy lỗi cần tái hiện, refactor nhiều bước, tuning dựa trên benchmark, tác vụ nghiên cứu cần đầu ra cuối cùng
  • Các chỉnh sửa một lần phù hợp hơn với prompt thông thường

• Cài đặt và kiểm tra phiên bản

  • Goals có từ Codex 0.128.0
  • npm: npm install -g @openai/codex@latest rồi codex --version
  • Homebrew: brew update && brew upgrade --cask codex rồi codex --version

• Thiết lập Goal và các lệnh vòng đời

  • Thiết lập theo dạng /goal <kết quả>, ví dụ: /goal Reduce p95 latency below 120 ms without regressing correctness tests
  • /goal: xem Goal hiện tại
  • /goal pause: tạm dừng Goal đang hoạt động
  • /goal resume: tiếp tục Goal đã tạm dừng
  • /goal clear: xóa Goal hiện tại

• Điều kiện dừng (stopping condition)

  • Dừng khi thành công, tạm dừng, xóa bỏ, bị gián đoạn, chạm giới hạn ngân sách, hoặc xuất hiện blocker cần người dùng cung cấp thêm đầu vào
• Goal giúp biểu đạt rõ ý định trong các tình huống mà bình thường bạn phải lặp lại chỉ thị ở mỗi lượt như “tiếp tục đi”, “thử bản sửa tiếp theo có thể làm được”, “chạy benchmark lại”, hoặc “giờ kiểm tra test này đi”

Goals so với prompt

• Prompt thông thường: “hãy làm tác vụ tiếp theo này”
• Goal: “hãy tiếp tục làm việc cho tới khi kết quả này trở thành sự thật”

• Khác biệt trong cách hoạt động

  • Với yêu cầu thông thường, Codex thực hiện chỉ thị ngay lập tức, báo kết quả rồi chờ
  • Với Goal, một mục tiêu bền vững (durable target) được gắn vào luồng; sau khi kết thúc lượt, Codex kiểm tra bằng chứng hiện có và quyết định mục tiêu đã được đáp ứng hay chưa
  • Nếu chưa đáp ứng, Goal vẫn đang hoạt động và còn trong ngân sách, Codex có thể tiếp tục làm việc từ trạng thái mới nhất

• Ví dụ: /goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

  • Goal này cung cấp một kết quả có thể đo lường, phương thức xác minh và các ràng buộc
  • Codex có thể lặp lại chu trình chạy benchmark → kiểm tra hot path → thay đổi có chủ đích → chạy lại benchmark → chạy bộ kiểm tra tính đúng đắn, và tiếp tục nếu kết quả vẫn chưa đạt

• Mô hình tư duy

  • Prompt: ask → work → result → wait
  • Goal: work → check → continue or complete
• Goal cung cấp vạch đích, nhưng công việc vẫn phải được kiểm toán theo bằng chứng (audited against evidence)

Cách viết Goal

• Một Goal tốt không phải là prompt dài hơn, mà là một hợp đồng ngắn gọn về cách Codex cần làm việc, thế nào là thành công và phải làm gì nếu chưa đạt được thành công

• 6 yếu tố mà một Goal mạnh cần định nghĩa

  • Outcome: điều phải đúng khi công việc hoàn tất
  • Verification surface: test, benchmark, báo cáo, artifact, đầu ra lệnh hoặc tư liệu nguồn dùng để chứng minh điều đó
  • Constraints: những thứ không được bị hồi quy (regress) trong quá trình Codex làm việc
  • Boundaries: file, công cụ, dữ liệu, kho mã hoặc tài nguyên được phép sử dụng
  • Iteration policy: cách quyết định phải làm gì tiếp theo sau mỗi lần thử
  • Blocked stop condition: thời điểm cần báo cáo và dừng lại khi không còn lộ trình nào có thể biện hộ trong giới hạn hiện tại

• Mẫu viết

  • /goal <trạng thái kết thúc mong muốn> verified by <bằng chứng cụ thể> while preserving <ràng buộc>. Use <đầu vào/công cụ/ranh giới được phép>. Between iterations, <cách chọn hành động tốt nhất tiếp theo>. If blocked or no valid paths remain, <nội dung cần báo cáo và đầu vào cần thiết để tiếp tục tiến triển>.

• Ví dụ yếu và ví dụ mạnh

  • Yếu: /goal Reduce p95 checkout latency below 120 ms without regressing correctness tests
  • Mạnh: nêu rõ phương thức xác minh (checkout benchmark), phạm vi sử dụng (dịch vụ checkout, benchmark fixtures, các test liên quan), chính sách lặp (ghi lại thay đổi, kết quả benchmark, thử nghiệm tiếp theo), và cả điều kiện báo blocker

• Goal cho nghiên cứu/điều tra

  • Nếu không thể có chứng minh chính xác, hãy định nghĩa chuẩn bằng chứng (evidence standard) trước khi bắt đầu
  • Ví dụ: /goal Produce the strongest evidence-backed reproduction of the paper using the available materials and local resources. Attempt the headline results where feasible, verify outputs where possible, and end with a report that separates confirmed findings, approximate reconstructions, blocked claims, and remaining uncertainty.

• Giao việc viết Goal cho Codex

  • Khuyến nghị quy trình 2 bước: mô tả tác vụ bằng ngôn ngữ thường → yêu cầu Codex viết Goal nháp → tinh chỉnh điều kiện thành công, phương thức xác minh, ràng buộc và điều kiện dừng khi bị chặn rồi mới kích hoạt

Điều gì thay đổi khi Goal được kích hoạt

• Mục tiêu luôn hiện diện

  • Dù test thất bại, luồng vẫn giữ nguyên mục tiêu ban đầu
  • Nếu benchmark được cải thiện nhưng chưa chạm ngưỡng, Codex sẽ tiếp tục
  • Nếu hướng nghiên cứu gặp thiếu dữ liệu, Codex điều chỉnh kế hoạch bằng chứng mà không đánh mất chuẩn nghiên cứu

• Có thể tiếp tục (continuation) trong luồng nhàn rỗi

  • Sẽ không tiếp tục nếu đang có lượt khác hoạt động, có đầu vào người dùng trong hàng đợi, hoặc công việc của luồng khác đang chờ
  • Chỉ tiếp tục khi luồng đang nhàn rỗi, Goal đang hoạt động và còn trong ngân sách

• Việc hoàn tất phải dựa trên bằng chứng

  • Việc mô hình “nghĩ rằng có lẽ đã xong” không đủ để đánh dấu hoàn tất
  • Chỉ hoàn tất sau khi kiểm tra mục tiêu dựa trên file liên quan, test, log, đầu ra benchmark, artifact đã tạo và các bằng chứng cụ thể khác
• Điểm cốt lõi trong thiết kế: Codex có thể tiếp tục di chuyển, nhưng bằng chứng mới là thứ quyết định đã hoàn tất hay chưa

Cấu trúc thiết kế của Goals trong Codex

• Goals được triển khai dưới dạng trạng thái bền vững ở phạm vi luồng (persisted thread state), không phải bộ nhớ toàn cục hay chỉ thị cấp dự án
  • Mục tiêu thuộc về luồng chứa ngữ cảnh liên quan như file đã kiểm tra, lệnh đã chạy, diff đã tạo, log đã xem và dấu vết suy luận

• Các lớp kiến trúc

  • Ghi lại mục tiêu, vòng đời, ngân sách và hạch toán tiến độ dưới dạng trạng thái bền vững trong phạm vi luồng
  • Trạng thái Goal: active, paused, complete, budget-limited
  • Tùy theo trạng thái, Codex quyết định tiếp tục, chờ người dùng hay tóm tắt tiến độ thay vì bắt đầu việc mới

• Tiếp tục (continuation) dựa trên sự kiện

  • Đây không phải vòng lặp đơn giản; chỉ kiểm tra ở những ranh giới an toàn: sau khi kết thúc lượt, không có việc đang chờ, không có đầu vào người dùng trong hàng đợi và luồng đang nhàn rỗi
  • Cách hoạt động của dispatcher mang tính bảo thủ: tác vụ chỉ lập kế hoạch sẽ không kích hoạt continuation; khi bị gián đoạn thì tạm dừng mục tiêu; khi luồng được khôi phục thì Goal được phục hồi nếu phù hợp; nếu một lượt continuation không gọi công cụ nào thì lần tự tiếp tục tiếp theo sẽ bị chặn để tránh quay vòng vô ích

• Lớp prompting

  • Prompt cho continuation giúp Codex luôn bám vào Goal đang hoạt động, nhưng vẫn yêu cầu kiểm toán trước khi tuyên bố hoàn tất
  • Mục tiêu được đối chiếu với bằng chứng cụ thể như file đã thay đổi, lệnh đã chạy, test đã qua, đầu ra benchmark, artifact được tạo và bằng chứng nghiên cứu

• Xử lý ngân sách (budget)

  • Khi chạm ngân sách, công việc thực chất sẽ dừng lại, tiến độ và blocker được tóm tắt, đồng thời xác định bước tiếp theo hữu ích nhất
  • Chạm giới hạn ngân sách không đồng nghĩa với việc Goal đã hoàn tất

• Hợp đồng công cụ (tool contract)

  • Mô hình có thể khởi động Goal, nhưng chỉ được đánh dấu Goal hiện tại là hoàn tất khi bằng chứng hỗ trợ điều đó
  • Việc tạm dừng, tiếp tục, xóa bỏ và chuyển sang trạng thái giới hạn ngân sách vẫn nằm dưới sự kiểm soát của người dùng hoặc hệ thống

Chuyển Goal yếu thành Goal mạnh

• Ví dụ tuning hiệu năng

  • Yếu: /goal Improve performance
  • Mạnh: /goal Reduce p95 latency below 120 ms on the checkout benchmark while keeping the correctness test suite green
  • Phiên bản mạnh cung cấp kết quả, cách xác minh và ràng buộc, nên có thể nhận biết khi nào không được phép dừng
    • Nếu p95 cải thiện từ 180ms xuống 135ms thì Goal vẫn chưa hoàn tất
    • Nếu độ trễ xuống dưới 120ms nhưng test tính đúng đắn thất bại thì vẫn chưa hoàn tất
    • Nếu không chạy được benchmark thì phải nêu blocker thay vì tuyên bố thành công

• Phạm vi phù hợp của Goal

  • Cần đủ hẹp để có thể kiểm toán, nhưng cũng đủ rộng để chọn hành động tiếp theo
  • “Fix the failing checkout test” là quá hẹp nếu phụ thuộc upstream mới là vấn đề thực sự
  • “Improve the whole system” là quá rộng vì không có bề mặt kiểm toán
  • “Make the checkout test suite pass on the current branch without changing public API behavior” là hợp lý

• Áp dụng nguyên tắc tương tự cho artifact được tạo ra

  • Yếu: /goal Write docs for this feature
  • Mạnh: /goal Produce a docs page for Goals that explains the lifecycle, command surface, and two examples. Verify that the page builds locally and that all referenced commands match the current CLI behavior.
  • Phiên bản mạnh đưa ra một trang có thể kiểm tra được, lệnh build và hành vi lệnh cần khớp

• Chuẩn bằng chứng cho Goal nghiên cứu

  • Xác định trước khi điều tra: đâu là tái hiện chính xác, tái dựng một phần, bằng chứng thay thế hỗ trợ, và đâu là hạng mục cần coi là blocker
  • Một Goal nghiên cứu mạnh yêu cầu lập bảng kê các phát biểu, ánh xạ phát biểu với bằng chứng, triển khai những phần có thể chạy, gắn nhãn blocker, và tạo kiểm toán tách riêng các phát biểu đã xác nhận, bằng chứng chỉ mang tính hỗ trợ, phát biểu bị chặn và phần bất định còn lại

Dùng Goals cho nghiên cứu phức hợp: ví dụ tái hiện bài báo định lượng

• Tổng quan ví dụ

  • Đối tượng: bài báo Deep Hedging của Buehler, Gonon, Teichmann và Wood
  • Chủ đề bài báo: liệu chiến lược giao dịch bằng mạng nơ-ron có thể tái hiện phòng hộ dựa trên mô hình trong bối cảnh sở thích rủi ro, chi phí giao dịch và thị trường nhiều chiều hay không
  • Goal đúng không phải là “tái hiện bài báo” một cách trừu tượng, mà là thử tái tạo các con số chính, tách bạch cơ chế chính xác với các phương án học gần đúng, và nêu rõ phần nào không thể tái hiện chính xác bằng tư liệu hiện có

• Goal nghiên cứu yếu và mạnh

  • Yếu: /goal Reproduce Buehler et al., "Deep Hedging"
    • Không xác định phần nào quan trọng, thế nào được coi là tái hiện, cách xử lý khi thiếu trạng thái huấn luyện, hay cách phân biệt giữa khớp gần đúng và phát lại chính xác
  • Mạnh: /goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging," using the available paper materials and local resources. Attempt every headline result, verify the outputs, and end with a report that separates reproduced mechanics, approximate trained results, blocked exact replay, and remaining uncertainty.

• Công việc thực tế mà Codex làm

  • Tách các phát biểu chính và phát biểu hỗ trợ
  • Ánh xạ từng phát biểu với bằng chứng sẵn có
  • Tái dựng các phần có thể kiểm thử cục bộ
  • Gắn nhãn các phát biểu không thể tái hiện chính xác bằng tư liệu hiện có

• Những phần có thể thực hiện

  • Tái dựng cơ chế định giá và phòng hộ
  • Tái hiện mức giá tham chiếu Heston
  • Huấn luyện chính sách cho thí nghiệm phòng hộ CVaR
  • Tái dựng các histogram chính và artifact bề mặt phòng hộ
  • Tái hiện độ dốc chi phí giao dịch của Black-Scholes
  • Chạy các kiểm tra đã huấn luyện cho ví dụ chi phí giao dịch Heston và ví dụ nhiều chiều

• Những phần vẫn là blocker

  • Bài báo không cung cấp random seed chính xác, các đường huấn luyện đã sinh, đồ thị TensorFlow, trạng thái optimizer, checkpoint hay toàn bộ trạng thái mô phỏng gốc
  • Kết quả trung thực nhất là tái hiện một phần và gần đúng, chứ không phải tái tạo chính xác mạng nơ-ron gốc

• Giữ nguyên mức độ hậu thuẫn nhận thức luận trong báo cáo

  • Các phương án thay thế đã huấn luyện có thể hỗ trợ cho phát biểu; sự khớp gần đúng về số liệu có thể làm tăng độ tin cậy; các hình được tái dựng có thể xác minh một phần kết quả; nhưng không điều nào trong số đó cho phép mô tả rằng thí nghiệm gốc đã được khôi phục chính xác
  • Ví dụ một ledger:
    • Claim: Deep hedging approximates complete-market Heston hedge without transaction costs
    • Route: tái dựng cơ chế mô hình, so sánh với phòng hộ tham chiếu, huấn luyện chính sách mạng nơ-ron
    • Evidence surface: kiểm tra giá, histogram, bề mặt phòng hộ
    • Status: Close approximate reproduction
    • Remaining uncertainty: không thể sử dụng đường huấn luyện gốc, seed và checkpoint
• Giá trị minh họa của Goals trong nghiên cứu là giúp công việc tiếp tục tiến lên ngay cả khi có mơ hồ, đồng thời ngăn những đầu ra có vẻ hợp lý bị thổi phồng thành kết luận quá mức; ý nghĩa của “hoàn tất” được định nghĩa bằng kiểm toán từng phát biểu dựa trên bằng chứng, nêu rõ các phần gần đúng và trung thực về ranh giới giữa tái hiện với phát lại

Khi nào không nên dùng Goals

• Không phù hợp cho chỉnh sửa một dòng, giải thích đơn giản, review mã ngắn, hoặc câu hỏi mà bạn muốn dừng sau một câu trả lời → prompt Codex thông thường sẽ phù hợp hơn
• Không phù hợp khi vạch đích còn mơ hồ
  • “Make this better” không cung cấp điều kiện hoàn tất đáng tin cậy
  • “Refactor this code” cũng yếu nếu không định nghĩa trạng thái kết thúc mong đợi, test và ràng buộc
• Không được dùng để che giấu bất định
  • Nếu dữ liệu có thể không dùng được, hãy ghi rõ trong Goal
  • Nếu benchmark có thể flaky, hãy nêu cách xử lý
  • Nếu chấp nhận bằng chứng thay thế, hãy định nghĩa cách gắn nhãn
• Goals mạnh nhất khi ba đặc tính cùng xuất hiện: mục tiêu bền vững, vạch đích dựa trên bằng chứng và lộ trình cần điều tra qua nhiều lượt

Kết luận: duy trì mục tiêu, nhưng bằng chứng quyết định việc hoàn tất

• Goals thay đổi mô hình vận hành của Codex, chuyển luồng từ chuỗi các prompt tách biệt thành vòng lặp công việc dựa trên trạng thái xoay quanh một kết quả đã được định nghĩa
• Kiến trúc này có chủ ý đặt ra ranh giới
  • Goal bị giới hạn trong phạm vi luồng, có trạng thái vòng đời và hạch toán ngân sách, và có thể bị tạm dừng, tiếp tục, xóa bỏ, hoàn tất hoặc dừng vì hết ngân sách
  • Codex có thể tiếp tục di chuyển, nhưng chỉ trong hợp đồng do người dùng định nghĩa
• Nó đặc biệt hữu ích cho những tác vụ Codex vốn tạo ra giá trị cao nhất: debugging, tối ưu hóa, migration, test, nghiên cứu
• Người dùng cung cấp mục tiêu, Codex lần theo bằng chứng, và Goal kết nối hai phía cho tới khi công việc hoàn tất hoặc bị chặn một cách trung thực
• Với nghiên cứu phức hợp, nó tạo ra khác biệt giữa việc sinh ra một câu trả lời và việc tạo ra một kiểm toán (audit)
• Một Goal tốt không chỉ yêu cầu Codex hoàn thành, mà còn cho Codex biết “hoàn tất” thực sự có nghĩa là gì

[hmmhmmhm]

/goal Hãy kiểm tra và tiến hành mọi việc có thể làm dựa trên những công việc tôi đã làm trước đó, trước giờ nghỉ trưa lúc 12 giờ. Không được dừng công việc trước 12 giờ.

[shakespeares]

Một lệnh thật tuyệt.