Dùng GitLab Duo `/goal`: viết tiêu chí hoàn tất trước khi giao quyền sửa mã

Cách dùng GitLab Duo CLI `/goal` an toàn là viết mục tiêu như một hợp đồng hoàn tất: nêu kết quả cần đạt, giới hạn tệp được sửa, lệnh dùng để xác minh và tình huống buộc agent dừng chờ duyệt. Hãy khảo sát công việc trong Plan trước, rồi chỉ chuyển sang Build khi các ranh giới này đã rõ.

Cú pháp cơ bản là `/goal <nhiệm vụ>. <done when...>`. Hướng dẫn `/goal` của GitLab cho biết lệnh chạy ở chế độ tương tác, yêu cầu GitLab 19.3 trở lên và GitLab Duo CLI 9.17.0 trở lên; tính năng dành cho Premium hoặc Ultimate và cần bật GitLab Duo Agent Platform.

Kiểm tra môi trường và tách Plan khỏi Build

Trước tiên, cài đặt và thiết lập Duo CLI, sau đó đặt namespace GitLab Duo mặc định hoặc mở một dự án có quyền truy cập. Tùy cách cài, phiên tương tác được khởi động bằng `glab duo cli` hoặc `duo`.

Tài liệu sử dụng GitLab Duo CLI xác định Plan là chế độ chỉ đọc, còn Build có quyền đọc–ghi và có thể thay đổi dự án; phím Tab dùng để chuyển giữa hai chế độ. Trong phiên tương tác, CLI yêu cầu phê duyệt trước khi dùng công cụ, với lựa chọn cho phép một lần, cho phép cùng đối số trong phiên hoặc từ chối; lựa chọn theo phiên phải được quản trị viên bật. Ngược lại, chế độ headless qua `glab duo cli run --goal` hoặc `duo run --goal` tự động phê duyệt mọi công cụ và bắt đầu ngữ cảnh mới ở mỗi lần chạy.

1. Khởi động CLI và chuyển sang Plan.
2. Yêu cầu agent xác định tệp liên quan, phép kiểm thử, phụ thuộc và rủi ro mà chưa sửa mã.
3. Thu hẹp kế hoạch thành phạm vi có thể review.
4. Chuyển sang Build và chạy `/goal` với điều kiện hoàn tất cùng yêu cầu dừng đã chốt.

Viết mục tiêu theo bốn thành phần

Một mục tiêu hữu ích phải trả lời bốn câu hỏi: trạng thái cuối cùng là gì, agent được chạm vào đâu, kết quả được kiểm tra thế nào và khi nào agent không được tự tiếp tục. Cấu trúc ngắn gọn là kết quả + phạm vi + phép xác minh + điểm dừng.

• Kết quả: mô tả trạng thái quan sát được, chẳng hạn một nhóm test vượt qua hoặc job lint không còn lỗi.
• Phạm vi: chỉ rõ tệp, thư mục hay module được phép thay đổi, đồng thời nêu vùng phải giữ nguyên.
• Xác minh: ghi chính xác lệnh test, lint, build hoặc kiểm tra kiểu mà agent cần chạy.
• Điểm dừng: yêu cầu dừng nếu phải đổi API công khai, schema, dependency, secret, runner hay cấu hình triển khai.

Đừng biến số vòng thử lại thành một “tham số” không tồn tại của cú pháp `/goal`. Bạn có thể ghi giới hạn mong muốn vào chính mục tiêu như một điều kiện kiểm soát, trong khi giới hạn kỹ thuật của luồng do hệ thống cấu hình. Thông báo GitLab 19.4 xác nhận `/goal` đang ở public beta: agent thực hiện công việc, một mô hình riêng đánh giá mục tiêu sau mỗi bước, và luồng kết thúc khi đạt yêu cầu hoặc chạm giới hạn; người dùng cũng có thể dừng để sửa mục tiêu rồi chạy lại.

Ba mẫu mục tiêu có hàng rào rõ ràng

Sửa test thất bại

Mẫu có điều kiện: `/goal Sửa các test thất bại trong spec/models/user_spec.rb. Chỉ sửa tệp test này và app/models/user.rb; không đổi schema hoặc dependency. Done when: bundle exec rspec spec/models/user_spec.rb thành công và không xuất hiện cảnh báo mới. Nếu vẫn thất bại sau tối đa 3 vòng sửa, dừng, tóm tắt nguyên nhân và chờ duyệt.`

Ở đây, việc tạo ra một diff chưa được coi là hoàn tất. Kết quả phải được chứng minh bằng một lệnh cụ thể, còn giới hạn ba vòng là yêu cầu do người giao việc đặt ra để agent không tiếp tục theo đuổi một giả thuyết kém hiệu quả.

Refactor nhưng giữ nguyên hành vi

Mẫu có điều kiện: `/goal Refactor bộ phân tích trong src/parser/ để loại bỏ logic lặp. Giữ nguyên API công khai và định dạng đầu ra; không sửa ngoài src/parser/ và tests/parser/. Done when: npm test -- tests/parser và npm run typecheck đều thành công. Nếu cần đổi interface được export hoặc thêm package, dừng và trình bày phương án trước khi sửa.`

“Mã sạch hơn” là nhận xét khó kiểm chứng. Giới hạn thư mục, giữ nguyên API và yêu cầu hai lệnh xác minh giúp phân biệt một refactor đúng phạm vi với thay đổi kiến trúc cần được review riêng.

Xử lý pipeline

Mẫu có điều kiện: `/goal Khắc phục job lint đang thất bại trong pipeline hiện tại. Chỉ sửa cấu hình lint và các tệp gây lỗi được job liệt kê; không thay đổi quy tắc bảo vệ nhánh, secret hoặc bước deploy. Done when: lệnh lint cục bộ thành công và cấu hình CI hợp lệ. Nếu cần truy cập secret, thay đổi runner hoặc thực hiện thao tác triển khai, dừng và báo dữ liệu còn thiếu.`

Một pipeline có thể phụ thuộc vào runner, secret hoặc dịch vụ nằm ngoài repository. Vì vậy, tiêu chí nên tách phần agent có thể xác minh cục bộ khỏi phần chỉ CI mới xác nhận được, thay vì cho phép agent nới quy tắc để làm lỗi biến mất.

Phê duyệt công cụ theo phạm vi rủi ro

Trong Build, chỉ nên cho phép theo phiên đối với thao tác đã hiểu rõ và có đối số đủ hẹp, chẳng hạn đọc đúng thư mục đã khoanh vùng hoặc chạy một lệnh test cố định. Với thao tác ghi ngoài phạm vi, cài dependency, truy cập mạng, thay đổi trạng thái Git hay tác động tới môi trường, hãy duyệt từng lần.

Nếu agent yêu cầu một công cụ không phục vụ trực tiếp tiêu chí hoàn tất, hãy từ chối và sửa lại mục tiêu thay vì âm thầm mở rộng quyền. Đối với headless, hàng rào phải được dựng bên ngoài CLI bằng sandbox, token có quyền tối thiểu và giới hạn mạng, vì phiên chạy không chờ người dùng phê duyệt từng công cụ.

Điểm dừng trước và sau khi chạy

Trước khi gửi lệnh trong Build, kiểm tra lại năm yếu tố: đường dẫn hoặc module cụ thể, vùng cấm thay đổi, lệnh xác minh có thể chạy, giới hạn thử lại và tình huống phải dừng. Nếu agent lệch khỏi phạm vi trong lúc chạy, dừng lượt hiện tại rồi sửa mục tiêu; không cần chờ luồng dùng hết số vòng.

Khi `/goal` kết thúc, vẫn cần xem diff, kết quả test và nội dung mà bộ xác minh đã đánh giá. Lệnh này giúp agent theo đuổi một kết quả được định nghĩa trước, nhưng không thay thế review mã, kiểm tra bảo mật hoặc quy trình phê duyệt merge của nhóm.

Đọc thêm:

• F5 chặn lệnh của AI agent trước khi chạy: tháng 10 mới có
• Chi tiêu AI của nhóm doanh nghiệp dẫn đầu giảm 9,7% trong tháng 8
• Gemini Enterprise thêm trần chi tiêu: AI agent hết ngân sách sẽ tự dừng