Goals trong Codex và Claude Code: Vì sao một model thứ hai mới quyết định khi nào bạn đã xong

Hầu hết các cuộc trò chuyện với một coding agent đều theo cùng một nhịp: bạn yêu cầu, nó làm việc, nó trả về kết quả, rồi chờ bạn. Chính khoảng dừng đó là cái giá phải trả. Với bất kỳ tác vụ nào cần thử mười lần mới đúng — truy tìm một flaky test, tối ưu một endpoint chậm, migrate hàng trăm call site — thì bạn trở thành vòng lặp. Bạn đọc output, quyết định là chưa xong, và gõ "làm tiếp đi" hết lần này đến lần khác.

Vài tuần gần đây, cả Codex của OpenAI và Claude Code của Anthropic đều ra mắt cùng một ý tưởng để xóa bỏ cái giá đó: một Goal (Mục tiêu) bền vững. Bạn nêu ra vạch đích một lần duy nhất, và agent tiếp tục làm việc qua nhiều lượt cho đến khi vạch đích được vượt qua một cách có thể kiểm chứng. Điểm tinh tế khiến nó đáng tin cậy: một model thứ hai, tách biệt, sẽ quyết định khi nào bạn đã xong — chứ không phải model đang làm việc.

1. Sự dịch chuyển thực sự: từ "Hỏi → Chờ" sang "Làm → Kiểm tra → Tiếp tục"

Một prompt thông thường là một giao dịch đơn lẻ. Một Goal là một mục tiêu thường trực gắn với phiên làm việc của bạn. Như OpenAI diễn giải trong cookbook của Codex, điều này thay đổi mô hình làm việc từ "hỏi, làm, kết quả, chờ" thành "làm, kiểm tra, tiếp tục hoặc hoàn thành."

Cơ chế là một vòng lặp có một bộ đánh giá (evaluator) bên trong:

•Agent hoàn thành một lượt.
•Bộ kiểm tra nhìn vào goal và mọi thứ agent đã đưa ra cho đến giờ.
•Nếu điều kiện thỏa mãn → goal được xóa và quyền điều khiển trở lại với bạn.
•Nếu chưa → agent lập tức bắt đầu một lượt mới, dùng lý do của bộ kiểm tra làm định hướng.

Cơ chế này được thiết kế cho những tác vụ mà bước tiếp theo phụ thuộc vào những gì agent học được trên đường đi: tối ưu hiệu năng, điều tra bug, refactor lan tỏa, kiểm chứng nghiên cứu. Bạn không biết trước con đường, nhưng bạn biết vạch đích — vậy nên hãy chỉ định vạch đích và để agent tự tìm đường.

2. Vì sao một model thứ hai mới là người chấm điểm

Đây là quyết định thiết kế đáng "học lỏm" cho chính agent của bạn. Trong Claude Code, sau mỗi lượt, điều kiện goal cùng toàn bộ cuộc trò chuyện được gửi tới một model nhỏ, nhanh (mặc định là Haiku), model này trả về phán quyết có/không kèm một lý do ngắn. "Không" bảo agent chính làm tiếp và đưa luôn lý do làm gợi ý. "Có" thì xóa goal.

Tại sao không để model đang làm tự chấm điểm mình? Vì một model đã bỏ ra mười lượt cố sửa một thứ gì đó thì có động cơ để tuyên bố chiến thắng. Tách người làm khỏi người chấm là một pattern độ tin cậy kinh điển — bộ đánh giá đến với con mắt tươi mới và không mang định kiến "chi phí chìm" (sunk-cost). Codex áp dụng đúng nguyên tắc đó từ hướng ngược lại: khi chạm ngưỡng ngân sách (budget), nó được yêu cầu tóm tắt tiến độ và các điểm nghẽn thay vì tuyên bố thành công.

Một giới hạn cần khắc cốt ghi tâm: bộ đánh giá không tự chạy lệnh hay đọc file. Nó chỉ phán xét những gì agent đã đưa vào cuộc trò chuyện. Chính ràng buộc duy nhất đó quy định cách bạn phải viết goal.

3. Cách viết một Goal thực sự "trụ" được

Vì người chấm chỉ thấy transcript, vạch đích của bạn phải là thứ mà output của chính agent có thể chứng minh. "Code tốt hơn" là không thể kiểm chứng. "npm test thoát với mã 0 và transcript cho thấy điều đó" là kiểm tra được.

Goal yếu: "Cải thiện hiệu năng checkout."

Goal mạnh: "Giảm p95 latency của checkout xuống dưới 120 ms, được xác minh bằng checkout benchmark, đồng thời giữ correctness suite luôn xanh."

Phiên bản mạnh nêu tên bốn thứ mà người chấm có thể kiểm toán. Đội Codex đúc kết một goal tốt gồm sáu thành phần — dưới đây là checklist cô đọng:

•Outcome — trạng thái kết thúc bạn muốn.
•Verification surface — bằng chứng cụ thể: một test, một benchmark, một mã thoát build, một artifact.
•Constraints — thứ không được suy giảm trên đường đi.
•Boundaries — tool và tài nguyên nào được phép dùng.
•Iteration policy — cách quyết định giữa các lần thử.
•Stop condition — khi nào dừng lại và báo cáo điểm nghẽn thay vì cày mãi.

Trong Claude Code, điều kiện có thể dài tới 4.000 ký tự, và bạn được khuyến khích chặn nó bằng một mệnh đề như "hoặc dừng sau 20 lượt" để một goal không "chạy hoang". Hãy nêu rõ cách kiểm tra ("git status sạch", "hàng đợi rỗng") — đó chính là câu mà bộ đánh giá thực sự đọc.

4. Goal vs. Loop vs. Hook — chọn đúng "cò súng"

Goal không phải cách duy nhất để giữ một phiên chạy tiếp. Khác biệt chỉ nằm ở điều gì khởi động lượt kế tiếp:

•Goal — lượt kế tiếp bắt đầu khi lượt trước kết thúc, và dừng khi một model xác nhận điều kiện. Tốt nhất cho công việc lớn có trạng thái kết thúc kiểm chứng được.
•Loop (ví dụ /loop) — lượt kế tiếp bắt đầu khi một khoảng thời gian trôi qua. Tốt nhất cho việc polling và kiểm tra định kỳ ("chạy lại mỗi 5 phút").
•Stop hook — cũng kích hoạt sau mỗi lượt, nhưng nằm trong settings, áp dụng cho mọi phiên, và có thể chạy một script tất định thay vì phán quyết của model.

Thực tế, /goal của Claude Code là một lớp bọc mỏng quanh một prompt-based Stop hook phạm vi phiên — phiên bản "sản phẩm hóa" của một pattern mà power user đã tự tay dựng từ trước. Nó cũng kết hợp gọn gàng với auto mode: auto mode bỏ prompt phê duyệt theo từng tool, còn goal bỏ prompt theo từng lượt. Kết hợp lại, chúng cho phép một mục tiêu được định phạm vi tốt chạy tới đích mà không cần trông chừng.

5. Nơi Goal phát huy giá trị — và nơi thì không

Hãy dùng goal khi:

•Tác vụ có vạch đích rõ ràng nhưng con đường không chắc chắn (debug, tối ưu hiệu năng, migration).
•Thành công chứng minh được từ transcript: test, benchmark, một lần compile, một backlog rỗng.
•Công việc thực sự cần nhiều vòng lặp được dẫn dắt bởi những gì phát hiện ra.

Bỏ qua khi:

•Đó là một chỉnh sửa một lần hay một lời giải thích đơn giản — bạn muốn một câu trả lời và dừng ngay.
•Vạch đích mơ hồ hoặc không đo được ("làm cho đẹp hơn"). Một goal không có bề mặt kiểm chứng chỉ lặp đi lặp lại theo cảm tính.

Riêng với nghiên cứu, hướng dẫn của Codex rất sắc: định nghĩa chuẩn bằng chứng trước khi bắt đầu, và tách bạch cơ chế đã tái hiện được với kết quả gần đúng với phần bị chặn/không kiểm chứng được với phần còn bất định. Chính cấu trúc đó ngăn một agent hăng hái khỏi việc "nói quá" — cũng chính là lý do ta giao việc chấm điểm cho một model thứ hai ngay từ đầu.

Kết luận: Hãy nêu vạch đích, đừng nêu từng bước

Bài học lặng lẽ xuyên suốt cả hai công cụ là một sự dịch chuyển về đơn vị chỉ dẫn. Bạn ngừng quản lý vi mô từng bước và bắt đầu tuyên bố kết quả kèm một bề mặt kiểm chứng — rồi để một người làm và một người chấm độc lập tự chạy vòng lặp giữa họ. Đó chính xác là cách bạn giao việc cho một kỹ sư giỏi: thống nhất thế nào là "xong", thống nhất "xong" được chứng minh ra sao, rồi tránh sang một bên.

Nếu bạn đang tự xây agent của mình, hãy lấy pattern này ngay cả khi không bao giờ đụng tới các lệnh đó: hãy làm cho vạch đích của bạn kiểm tra được, và đừng bao giờ để người làm tự làm trọng tài cho chính mình.

Nguồn tham khảo:

•OpenAI Cookbook — Using Goals in Codex
•Claude Code Docs — Keep Claude working toward a goal

#AIAgents #Codex #ClaudeCode #DeveloperTools #LLM #AgenticWorkflows #SoftwareEngineering

✍️ Tác giả: Do Ngoc Hoan Founder of CookConnects.ca & Wizy.ca. Kết nối khoảng cách giữa thuật toán tiên tiến và thực thi kinh doanh. Tôi viết cho những founder kỹ thuật muốn mở rộng tầm ảnh hưởng bằng AI và kỹ thuật vững chắc.