AI agent tự trị: cách để agent làm việc hàng giờ mà không tạo ra rác

AI agent tự trị là gì và khác gì một yêu cầu thông thường

Làm việc với agent thông thường diễn ra từng bước: bạn viết prompt, agent thực hiện một bước, bạn xem kết quả rồi quyết định làm gì tiếp theo. AI agent tự trị chạy theo vòng lặp: bạn mô tả một lần trạng thái cuối cùng trông như thế nào, sau đó agent tự lặp lại chu trình «làm — kiểm tra — sửa» cho đến khi đạt mục tiêu hoặc hết ngân sách. Từ lúc khởi chạy, bạn có thể rời đi.

Nghe thì đơn giản, nhưng trải nghiệm đầu tiên thường diễn ra thế này: sáng bạn giao việc cho agent, tối quay lại thì thấy nó đã mất vài tiếng để sửa một lỗi đã được sửa rồi, vì nó quên mất việc đã làm một giờ trước. Không ai nói với nó khi nào nên dừng và khi nào nên gọi người. Dưới đây là cách thiết kế vòng lặp để tránh điều đó.

Một lưu ý quan trọng: vòng lặp không thay thế harness. Harness giúp một lần chạy đáng tin cậy, còn vòng lặp giúp các lần chạy liên tục. Vòng lặp đặt trên một harness kém chỉ tạo ra rác nhanh hơn.

Nhiệm vụ có phù hợp với agent tự trị không

Câu hỏi đầu tiên là công việc có đích đến nào mà máy có thể kiểm chứng không. «Mọi test trong thư mục tests/payments đều pass», «mọi tính năng trong danh sách đều ở trạng thái passing», «chỉ số tăng so với mốc ban đầu» — phù hợp. «Làm code tốt hơn» hoặc «tiếp tục cải thiện phần thanh toán» — không phù hợp: mục tiêu như vậy không có điểm kết thúc, vòng lặp sẽ quay mãi cho đến khi ăn hết ngân sách.

Nên phân biệt bốn loại vòng lặp:

• Từng bước — bạn nhập từng prompt; đây là công việc tương tác thông thường.
• Theo mục tiêu — bạn đặt mục tiêu, việc dừng do kiểm tra độc lập hoặc ngân sách quyết định. Đây chính là agent tự trị chạy hàng giờ.
• Theo thời gian — chạy theo lịch (ví dụ, sáng sớm phân tích các build CI bị lỗi), bạn dừng bằng tay.
• Theo sự kiện — một tác động bên ngoài (issue mới, lần deploy lỗi) kích hoạt, và việc dừng do xử lý xong sự kiện hoặc giới hạn số lần thử lại.

Lỗi hay gặp là nhầm vòng lặp theo thời gian với vòng lặp theo mục tiêu: «cứ mỗi 10 phút hãy tiếp tục làm phần thanh toán». Vòng lặp theo lịch mỗi lần bắt đầu chỉ dẫn từ đầu và không biết đã làm được gì. Nếu nhiệm vụ có điểm kết thúc, bạn cần vòng lặp theo mục tiêu có bộ nhớ về tiến độ.

Bước 1. Hộp cát: nơi agent được phép làm hỏng

Agent làm việc không cần giám sát sớm muộn cũng sẽ làm điều sai: xóa một file, viết lại một migration, chạy một lệnh nặng. Vì vậy câu hỏi không phải «làm sao để nó không bao giờ sai», mà là «làm sao để lỗi không gây ra hậu quả gì».

• Bản sao làm việc riêng. git worktree cho agent một thư mục và một nhánh riêng trên cùng repository. Nhánh chính không bị đụng đến, nhiều agent không cản trở nhau, và một lần chạy hỏng được xóa bằng một lệnh.
• Container hoặc máy ảo. Nếu agent cần quyền đầy đủ với các lệnh, hãy chạy nó trong container không có quyền truy cập thư mục home, khóa bí mật và cơ sở dữ liệu production.
• Dữ liệu thử nghiệm. Cơ sở dữ liệu local, sandbox của các cổng thanh toán, khóa giả. Không có một bí mật production nào trong môi trường của agent.

# nhánh và thư mục riêng cho lần chạy tự trị
git worktree add ../shop-agent -b agent/f03-refunds

# sau khi chạy: xem kết quả hoặc bỏ đi
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

Bước 2. Quyền truy cập: tối thiểu để đủ làm nhiệm vụ

Agent làm việc càng lâu một mình, quyền của nó càng phải hẹp. Trong Claude Code, quyền được cấu hình trong settings.json (danh sách allow và deny cho công cụ và lệnh): hãy cho phép rõ ràng những gì nhiệm vụ cần — chạy test, linter, sửa file trong bản sao làm việc — và chặn những thứ nguy hiểm: push lên nhánh chính, làm việc với bí mật, lệnh mạng nếu không cần thiết.

Chế độ mà agent thực hiện mọi thứ mà không cần xác nhận chỉ được phép trong hộp cát cô lập, nơi tệ nhất là bỏ đi một container. Trên máy làm việc có khóa và repository của bạn thì tuyệt đối không được làm vậy.

Những cấm đoán không được vi phạm cần được đảm bảo bằng cơ chế chứ không chỉ bằng văn bản. Dòng «đừng động vào migrations/» trong hướng dẫn chỉ là mong muốn; một hook chặn việc sửa thư mục này hoặc quyền của hệ thống file mới là đảm bảo.

Bước 3. Mục tiêu, kiểm chứng, dừng — ba dòng trước khi chạy

Vòng lặp làm việc đơn giản nhất dựa trên ba thứ, và nên ghi chúng lại trước khi chạy chứ không phải giữa chừng:

1. Mục tiêu — trạng thái cuối cùng trông như thế nào.
2. Kiểm chứng — cách kiểm tra bằng máy xem mục tiêu đã đạt chưa: một lệnh trả về thành công hoặc lỗi.
3. Điều kiện dừng — giới hạn số lần thử, thời gian hoặc chi phí, sau đó vòng lặp dừng lại ngay cả khi mục tiêu chưa đạt.

Tiện nhất là giữ những thứ này trong một file phương pháp riêng, chỉ người được sửa. Ví dụ cho backend thanh toán:

# program.md — phương pháp cho lần chạy tự trị

## Mục tiêu
Mọi tính năng trong .agent/feature_list.json ở trạng thái passing.

## Chỉ số
Số tính năng ở trạng thái passing. Chỉ tăng. Hồi quy = hoàn tác ngay.

## Ràng buộc
- Một tính năng đang làm tại một thời điểm.
- Không sửa migrations/ và infra/.
- Không đổi dependency nếu chưa ghi vào nhật ký.

## Thứ tự làm việc
1. Lấy tính năng đầu tiên chưa ở trạng thái passing.
2. Triển khai, chạy pytest và linter.
3. Xanh — commit và ghi vào .agent/progress.md. Đỏ — sửa tiếp.

## Dừng và chuyển giao
- 3 lần thử thất bại cho một tính năng — đánh dấu blocked, chuyển sang tính năng tiếp theo.
- Tất cả tính năng còn lại đều blocked — dừng và viết báo cáo.
- Mọi việc liên quan đến tiền của khách hàng, quyền truy cập, xóa dữ liệu — không làm, mà chuyển cho người.

Bước 4. Vòng kiểm tra-sửa với bộ nhớ trên đĩa

Cửa sổ ngữ cảnh không tồn tại qua một công việc dài: nó đầy lên, bị nén lại, phiên bị khởi động lại. Vì vậy tiến độ phải nằm trong file chứ không nằm trong «đầu» của agent: danh sách việc với trạng thái, nhật ký những gì đã làm và những gì không hoạt động, lịch sử git.

Một mô hình tốt là «cái cóc chỉ tiến về phía trước», như trong dự án autoresearch của Andrej Karpathy, nơi agent chạy hàng trăm thí nghiệm ML qua đêm. Mỗi vòng lặp: đọc phương pháp, đưa ra giả thuyết, thay đổi, chạy thí nghiệm với ngân sách thời gian cố định, so sánh với mốc ban đầu. Nếu tốt hơn — commit, nếu không — hoàn tác. Kết quả được ghi vào nhật ký, sau đó chuyển sang giả thuyết tiếp theo.

Có hai quyết định nên lấy từ mô hình này:

• Ngân sách cố định cho mỗi lần thử. Các lần thử trở nên so sánh được, và một giả thuyết thất bại không ăn hết cả đêm.
• Nhánh chính chỉ chứa cải tiến. Mọi thứ không hiệu quả đều được hoàn tác chứ không bị bỏ nằm cạnh. git log trở thành nhật ký đã được kiểm chứng về công việc đã làm, dễ đọc vào buổi sáng.

Mô hình đó cũng cho thấy việc phân vai theo file: hạ tầng và cách đánh giá không ai được sửa, mã của thí nghiệm chỉ agent sửa, còn phương pháp chỉ người sửa. Agent không thể «cải thiện» kết quả bằng cách chỉnh cách đo nó.

Bước 5. Ai quyết định là xong: bộ đánh giá riêng

Khi không có người trong vòng lặp, việc agent tự đánh giá là hãm duy nhất — và hãm này không hoạt động. Agent vừa viết code thường tin rằng code của mình đúng: nó thấy lập luận của chính mình và «biết» điều nó muốn làm.

Quy tắc tách người thực hiện và người đánh giá:

• Người đánh giá không phải là phiên đã làm công việc. Trong Claude Code, subagent rất tiện cho việc này: mỗi cái có ngữ cảnh riêng.
• Người đánh giá nhận ngữ cảnh sạch: yêu cầu, diff và kết quả chạy — và không có gì từ lập luận của người thực hiện.
• Nếu có thể, người đánh giá là một mô hình khác, hoặc ít nhất là một prompt khác với vai trò khác.
• Kết luận được đưa ra theo một bảng tiêu chí, và mỗi mục dẫn tới bằng chứng: dòng test, đầu ra của lệnh, vị trí trong diff.

Kiểm tra bằng máy vẫn là ưu tiên hàng đầu. Bộ đánh giá cần thiết cho những thứ test không bắt được: yêu cầu bị hiểu sai, test được chỉnh cho khớp với code, thay đổi vượt ra ngoài phạm vi nhiệm vụ.

Điều kiện dừng: khi nào agent phải bỏ cuộc

Vòng lặp không có điều kiện dừng sẽ quay vòng — chỉ là vấn đề thời gian. Bộ tối thiểu:

Hãy kiểm tra tiến triển theo thực chất, không theo số lần thử: «đã làm 40 vòng» không nói lên gì, còn «số tính năng xanh tăng từ 5 lên 9» thì có ý nghĩa. Nếu nhiệm vụ mắc kẹt, đó là lúc chuyển nó cho người, chứ không phải cho vòng lặp chạy thêm lần nữa.

Rủi ro của agent tự trị không lộ ra ngay

Những rủi ro rõ ràng — file bị xóa và build bị vỡ — được xử lý bằng hộp cát và quyền truy cập. Nguy hiểm hơn là những chi phí âm thầm tích lũy trong nhiều tuần:

• Nợ kiểm chứng. «Trông có vẻ ổn» thay vì «đã được máy xác nhận». Thuốc giải duy nhất là các điều kiện dừng kiểm chứng được bằng máy, không ngoại lệ.
• Suy giảm hiểu biết. Bạn ngày càng hiểu ít code của chính mình hơn. Thuốc giải là bắt buộc đọc diff: tốc độ vòng lặp không được vượt quá tốc độ bạn đọc.
• Đầu hàng về nhận thức. Bạn không còn ý kiến về kết quả và chấp nhận mọi thứ. Hãy trung thực đếm những lần «để xem sau» mà rồi không xem.
• Phình ngữ cảnh. Một lần chạy dài tích lũy lịch sử, và mỗi bước tiếp theo đắt hơn và kém chính xác hơn. Nén ngữ cảnh và bộ nhớ bên ngoài cần có ngay từ vòng đầu tiên, chứ không phải khi mọi thứ đã trôi đi.

Cách chạy vòng lặp tự trị đầu tiên trong một buổi tối

Đừng bắt đầu với «agent sẽ tự tìm và làm việc». Mức độ tự trị tăng dần từng bậc: đầu tiên là một nhiệm vụ với mục tiêu và điều kiện dừng, sau đó là một tự động hóa theo lịch, rồi đến người thực hiện và người kiểm tra được tách riêng trong một bản sao làm việc cô lập, và chỉ sau đó mới đến các vòng lặp tự tìm việc và chạy song song.

1. Tìm một việc bạn làm bằng tay ít nhất hai lần mỗi tuần và có điểm kết thúc kiểm chứng được.
2. Ghi mục tiêu, cách kiểm chứng và điều kiện dừng — ba dòng.
3. Tạo worktree riêng và cấu hình quyền: cho phép chạy test và sửa file, không cho push và bí mật.
4. Tạo file tiến độ và yêu cầu agent cập nhật nó sau mỗi vòng.
5. Tách vai: người thực hiện viết code, người kiểm tra trong ngữ cảnh riêng đánh giá diff.
6. Đặt một giới hạn chung và lần đầu tiên kiểm tra kết quả sau một giờ, không phải đến sáng.

Tổng kết

AI agent tự trị đáng tin cậy đúng bằng mức độ đáng tin của khung giới hạn quanh nó: hộp cát nơi lỗi không gây hậu quả, quyền tối thiểu, mục tiêu kiểm chứng được bằng máy, bộ nhớ trên đĩa, bộ đánh giá riêng, và các điều kiện dừng nghiêm ngặt kèm chuyển giao cho người. Không có những thứ này, một lần chạy dài không phải là tiết kiệm thời gian mà là việc dọn đống lộn xộn bị trì hoãn. Cách xây một vòng lặp như vậy trên một dự án xuyên suốt — từ program.md đến bộ đánh giá độc lập — được trình bày thực hành trong khóa học về harness engineering.