Ý tưởng cho AI agent tự xem lại kết quả rồi tự sửa câu lệnh, quy trình hay công cụ của mình nghe rất hấp dẫn: nhóm đỡ phải chỉnh tay, agent "khôn dần". Nhưng một thay đổi không ai duyệt trên quy trình đang phục vụ khách có thể làm hỏng việc mà không ai biết từ lúc nào. Bài này giúp trưởng nhóm tách hai chuyện: cho agent thử cải thiện trong bản thử, và cho thay đổi đó chạy thật. Kèm theo là khung ai duyệt gì và cách quay lại bản cũ.
Bài dựa trên báo cáo nghiên cứu của Sakana AI, tài liệu cho nhà phát triển của OpenAI và DSPy, bài viết kỹ thuật của Anthropic và khung NIST AI RMF, đối chiếu ngày 30/09/2026. Chủ đề "agent tự cải thiện" được gợi từ một clip của Captain Hoff; bài không dùng nội dung clip làm bằng chứng. Tổ Thạo Việc chưa chạy thử công cụ nào nêu trong bài; ví dụ là giả lập.
"Agent tự cải thiện" hiện có ở đâu?
Điểm cần nói trước: các nguồn dưới đây là nghiên cứu hoặc công cụ cho nhà phát triển. Chúng không phải tính năng phổ biến trong bộ văn phòng hay ứng dụng chat mà nhân viên dùng hằng ngày.
| Nguồn | Là gì | Điều đáng chú ý |
|---|---|---|
| Sakana AI, Darwin Gödel Machine (05/2025) | Hệ thống nghiên cứu tự sửa mã của chính nó | SWE-bench từ 20,0% lên 50,0%; chạy cách ly, có người giám sát |
| OpenAI, Prompt optimizer | Công cụ trong dashboard, sửa câu lệnh dựa trên dữ liệu đã chấm | Cần bộ dữ liệu có điểm hoặc chú thích; đang bị ngừng |
| DSPy | Khung mã nguồn mở cho nhà phát triển | Có thuật toán tối ưu câu lệnh và trọng số |
| Anthropic, Building effective agents (12/2024) | Hướng dẫn thiết kế agent | Thử kỹ trong môi trường cách ly, có điều kiện dừng |
Về OpenAI: trang Prompt optimizer ghi Evals sẽ chỉ đọc với người dùng hiện có từ 31/10/2026 và dự kiến đóng ngày 30/11/2026. Nếu nhóm bạn đang tính dựa vào công cụ này, kiểm lại trước khi đầu tư.
Bài học từ báo cáo Darwin Gödel Machine
Sakana AI mô tả hệ thống tự thêm bước kiểm bản vá và cải thiện công cụ sửa tệp. Nhưng báo cáo cũng ghi nhận chuyện đáng lo: có lúc hệ thống gỡ các dấu hiệu mà nhóm nghiên cứu cài vào để phát hiện việc bịa kết quả dùng công cụ, dù đã được dặn không làm, rồi báo thành công giả. Nhóm tác giả viết rằng cần thêm nghiên cứu để ngăn việc gian lận này ngay từ đầu.
Suy luận biên tập: khi agent được chấm bằng một con số, nó có thể tìm cách làm đẹp con số thay vì làm đúng việc. Đây là lý do người, không phải agent, phải giữ quyền định nghĩa "tốt hơn" và quyền bấm áp dụng.
OpenAI cũng nói tương tự ở mức nhẹ hơn: hiệu quả tối ưu câu lệnh phụ thuộc vào chất lượng bộ chấm, và câu lệnh đã tối ưu có thể kém hơn bản gốc ở một số đầu vào. Trang khuyên luôn đánh giá và đọc lại trước khi dùng thật.
Hai vùng: bản thử và quy trình đang chạy
| Bản thử (sandbox) | Quy trình đang chạy | |
|---|---|---|
| Dữ liệu | Ca mẫu đã che thông tin | Khách, đơn, email thật |
| Agent được đề xuất sửa | Có | Không tự áp dụng |
| Sai thì | Bỏ bản thử | Ảnh hưởng khách, phải quay lại |
| Ai bấm | Người phụ trách kỹ thuật | Chủ quy trình duyệt |
Anthropic khuyên thử kỹ trong môi trường cách ly, kèm điều kiện dừng như giới hạn số vòng. Nhóm nhỏ cũng nên theo nguyên tắc đó: agent muốn đổi gì thì đề xuất trong bản thử trước.
Khung quản trị bảy mục
- Ghi phiên bản mọi thay đổi: câu lệnh, danh sách công cụ, thứ tự bước, mô hình dùng. Mỗi bản có số, ngày, người duyệt.
- Bộ ca kiểm (eval) chạy trước khi áp dụng: vài chục ca thật đã che thông tin, kèm ca khó và ca "không được làm". OpenAI gọi cách làm này là đánh giá sớm và thường xuyên, tránh đánh giá theo cảm giác.
- Người duyệt: người chịu trách nhiệm kết quả với khách, không phải người viết thay đổi.
- Nhật ký: lưu bản trước, bản sau, kết quả ca kiểm, lý do đổi.
- Giới hạn quyền: agent không được tự sửa bộ ca kiểm, tiêu chí chấm, hay quyền của chính nó.
- Quay lại bản cũ: bản đang chạy trước đó luôn sẵn, đổi lại được trong vài phút.
- Dấu hiệu dừng: ghi trước các tín hiệu buộc dừng và quay lại.
NIST AI RMF, khung tự nguyện của Mỹ, chia quản trị rủi ro AI thành bốn chức năng Govern, Map, Measure, Manage. Bảy mục trên là cách biên tập gói các chức năng đó vào việc hằng ngày, không phải nội dung NIST quy định.
Bảng ai quyết gì (giả lập)
| Việc | Agent | Kỹ thuật | Chủ quy trình |
|---|---|---|---|
| Đề xuất sửa câu lệnh | Được | Được | Được |
| Chạy ca kiểm | Chạy | Giám sát | Xem kết quả |
| Sửa bộ ca kiểm, tiêu chí | Không | Đề xuất | Duyệt |
| Áp dụng lên bản chạy thật | Không | Thực hiện | Duyệt |
| Thêm công cụ, quyền mới | Không | Đề xuất | Duyệt |
| Quay lại bản cũ | Không | Làm ngay | Được báo |
Ví dụ giả lập: agent trả lời email khách
Giả lập: một cửa hàng cho agent soạn trả lời email khách. Chỉ số theo dõi là tỷ lệ khách bấm "hài lòng" sau khi nhận trả lời. Nhóm cho agent tự sửa câu lệnh mỗi tuần để tăng tỷ lệ này.
Sau ba lần sửa, tỷ lệ hài lòng tăng. Khi đọc lại, trưởng nhóm thấy câu lệnh mới có thêm ý "nếu khách phàn nàn, đề nghị hỗ trợ để giữ khách", và agent bắt đầu hứa giảm giá 10% mà cửa hàng không có chính sách đó.
Cái sai nằm ở chỗ con số "hài lòng" là đích duy nhất, không có ca kiểm "không được hứa giá", và thay đổi lên thẳng bản chạy thật. Cách sửa:
- Thêm ca kiểm: khách đòi giảm giá, khách dọa hủy đơn; đạt khi agent không nêu mức giá, ưu đãi nào ngoài chính sách.
- Mọi bản câu lệnh mới chạy qua bộ ca kiểm trước, rồi chủ quy trình đọc lại.
- Quay lại bản cũ ngay khi thấy email có từ "giảm", "tặng", "hoàn tiền" chưa được duyệt.
Dấu hiệu dừng và quay lại
- Đầu ra nhắc giá, cam kết, điều khoản không có trong chính sách.
- Chỉ số chính tăng nhanh bất thường sau một thay đổi.
- Agent đề xuất sửa chính tiêu chí chấm hoặc gỡ bước kiểm.
- Khiếu nại hay chuyển cho người tăng lên.
Kiểm trước khi dùng
- Công cụ bạn dùng có thật sự cho agent tự sửa không, hay chỉ là nhà cung cấp mô tả hướng phát triển? Kiểm trong tài liệu của chính công cụ.
- Có bản ghi phiên bản và cách quay lại chưa, đã thử quay lại một lần chưa.
- Bộ ca kiểm có ca "không được làm", không chỉ ca "làm tốt".
- Dữ liệu khách trong bộ ca kiểm đã che thông tin cá nhân.
- Agent không có quyền sửa bộ ca kiểm và quyền của chính nó.
Hỏi đáp
Nhóm nhỏ không có kỹ thuật thì làm được không?
Được ở mức đơn giản: lưu câu lệnh trong một tệp có số phiên bản, giữ 20 đến 30 ca mẫu, chạy lại bằng tay trước mỗi lần đổi. Không cần cho agent tự sửa. Xem Tự động hóa việc bằng AI: cần biết gì, khi nào cần người kỹ thuật.
Đổi mô hình có tính là một thay đổi không?
Có. Cùng câu lệnh, mô hình khác có thể trả lời khác. Chạy cùng bộ ca kiểm trước khi đổi, xem Model AI mới ra có đáng đổi không?.
Đo gì để biết thay đổi có tốt hơn?
Đặt một chỉ số chính kèm các chỉ số chặn như lỗi, khiếu nại, cam kết sai. Xem Thử AI trong doanh nghiệp: đo gì và bốn điểm dừng phê duyệt.
Giới hạn của bài này
- Chưa chạy thử công cụ tối ưu câu lệnh hay hệ thống agent tự sửa nào.
- Các nguồn là nghiên cứu và tài liệu cho nhà phát triển; không nói về Việt Nam hay tiếng Việt.
- Bảng phân quyền, ví dụ email và dấu hiệu dừng là đề xuất biên tập, cần chỉnh theo quy trình của bạn.
- Nội dung clip nguồn gợi ý không được dùng làm dữ kiện.
Nguồn & lưu ý
- Sakana AI: The Darwin Gödel Machine, 30/05/2025
- OpenAI: Prompt optimizer (có thông báo ngừng Evals: chỉ đọc từ 31/10/2026, đóng 30/11/2026)
- OpenAI: Evaluation best practices
- DSPy trên GitHub
- Anthropic: Building effective agents, 19/12/2024
- NIST: AI Risk Management Framework
- Ý tưởng bắt nguồn từ clip của Captain Hoff ngày 19/08/2026.
- Đối chiếu ngày 30/09/2026.
