Tác tử AI lập trình là trợ lý được cấp công cụ để tự hành động trong dự án: đọc tệp, tìm kiếm trong mã, chạy lệnh, sửa nhiều tệp, rồi xem kết quả và làm tiếp cho tới khi xong việc hoặc dừng lại hỏi bạn. Khác với khung trò chuyện, nơi bạn hỏi một câu và nhận một câu trả lời để tự chép vào, tác tử chạy theo vòng lặp nhiều bước và tự quyết bước tiếp theo dựa trên kết quả bước trước.
Sức mạnh của tác tử đến từ chỗ nó được nhìn thấy kết quả thật: lệnh kiểm thử báo lỗi gì, trình biên dịch phàn nàn ở dòng nào. Nhưng chính vì được tự làm nhiều bước, nó cũng có thể đi sai hướng xa hơn trước khi bạn kịp thấy. Bài này giải thích vòng lặp đó ở mức người dùng cần hiểu để giao việc và giới hạn quyền cho đúng.
Vòng lặp của tác tử: nghĩ, gọi công cụ, xem kết quả, làm tiếp
Bên trong một tác tử vẫn là mô hình ngôn ngữ như ở khung trò chuyện. Điểm khác là phần mềm bao quanh cho mô hình biết nó có những công cụ nào, mỗi công cụ nhận tham số gì. Khi mô hình trả lời, thay vì chỉ viết chữ, nó có thể viết ra một yêu cầu kiểu "đọc tệp này" hoặc "chạy lệnh kia". Phần mềm thực hiện yêu cầu đó trên máy, lấy kết quả, rồi gửi ngược lại cho mô hình như một phần của ngữ cảnh. Mô hình đọc kết quả và quyết định bước tiếp theo.
Vòng này lặp lại hàng chục lần trong một việc. Một việc sửa lỗi nhỏ có thể gồm: tìm hàm theo tên, đọc tệp chứa hàm, đọc tệp kiểm thử liên quan, chạy kiểm thử để thấy lỗi, sửa một dòng, chạy lại kiểm thử, thấy lỗi khác, sửa tiếp, chạy lại, tất cả qua rồi viết bản tóm tắt cho bạn. Mỗi bước đều để lại dấu vết mà bạn có thể đọc lại.
Hiểu vòng lặp giúp bạn đọc được hành vi của tác tử. Khi nó làm hay, đó thường là vì nó có cách tự kiểm rõ ràng, như một bộ kiểm thử chạy nhanh. Khi nó lạc đường, đó thường là vì kết quả nó nhận được mơ hồ, hoặc nó không có cách nào biết mình đã đúng, nên cứ thử hết hướng này sang hướng khác.
Những công cụ một tác tử lập trình thường được cấp
Tên gọi và cách bật tắt từng công cụ khác nhau tuỳ sản phẩm và đổi theo phiên bản, nên hãy kiểm tài liệu của công cụ bạn dùng. Về loại việc thì gần như sản phẩm nào cũng có các nhóm sau.
| Nhóm công cụ | Tác tử dùng để làm gì | Cần để ý |
|---|---|---|
| Đọc và tìm trong tệp | Liệt kê thư mục, tìm theo tên hàm, mở tệp để đọc | Có thể đọc cả tệp chứa khoá bí mật nếu chúng nằm trong thư mục dự án |
| Sửa và tạo tệp | Sửa từng đoạn, viết tệp mới, xoá tệp | Thay đổi trải nhiều tệp, cần git để xem và hoàn tác |
| Chạy lệnh dòng lệnh | Chạy kiểm thử, cài gói thư viện, chạy trình kiểm lỗi cú pháp, gọi git | Lệnh nào cũng chạy được bằng quyền của tài khoản bạn, kể cả lệnh xoá hoặc lệnh gửi dữ liệu ra ngoài |
| Truy cập mạng | Đọc tài liệu thư viện, tra lỗi | Nội dung trang web có thể chứa chỉ dẫn gài sẵn nhắm vào AI |
| Công cụ mở rộng | Nối với hệ thống quản lý công việc, cơ sở dữ liệu, dịch vụ khác qua các chuẩn kết nối | Mỗi kết nối là một cánh cửa mới, chỉ bật cái thật sự cần |
Phần lớn công cụ có chế độ hỏi ý bạn trước những hành động nhất định, như chạy lệnh hay sửa tệp, và chế độ cho tự làm. Người mới nên bắt đầu ở chế độ hỏi trước, đọc từng lệnh tác tử định chạy, rồi mới nới dần với những lệnh đã quen và vô hại.
Tác tử khác khung trò chuyện ở những điểm nào
Nó tự đi tìm ngữ cảnh. Ở khung trò chuyện, chất lượng câu trả lời phụ thuộc gần hết vào việc bạn dán đúng đoạn mã. Tác tử tự mở tệp, tự tìm chỗ gọi hàm, nên bạn không cần biết trước lỗi nằm ở tệp nào, chỉ cần mô tả hiện tượng đủ rõ.
Nó nhìn thấy kết quả chạy thật. Một đoạn mã trong khung trò chuyện có thể sai mà không ai biết cho tới khi bạn chạy. Tác tử chạy kiểm thử ngay và thấy lỗi, nên nhiều lỗi vặt được sửa trước khi tới tay bạn. Đây là khác biệt lớn nhất về chất lượng.
Nó làm nhiều bước liền mà không cần bạn. Tiện ở chỗ bạn làm việc khác trong lúc chờ. Rủi ro ở chỗ một quyết định sai ở bước ba có thể kéo theo mười bước sau đi sai, và đến khi bạn quay lại thì thay đổi đã trải rộng.
Nó tốn tài nguyên hơn. Mỗi vòng lặp là một lần gửi cả ngữ cảnh đang có cho mô hình. Một việc vài chục bước dùng nhiều token hơn hẳn một câu hỏi, nên chi phí và thời gian chờ cũng lớn hơn. Với việc chỉ cần một câu trả lời, khung trò chuyện vẫn hợp lý hơn.
Theo dõi một lượt làm việc của tác tử: ví dụ giả định
Ví dụ giả định: một ứng dụng Python nhỏ tính phí giao hàng có lỗi báo về là đơn gửi đi Lâm Đồng bị tính sai phí. Bạn giao cho tác tử: "Tìm vì sao đơn đi Lâm Đồng tính sai phí, viết kiểm thử tái hiện lỗi trước rồi mới sửa, không sửa ngoài thư mục tinh_phi". Dấu vết làm việc có thể như sau.
- Tác tử tìm từ khoá phí giao hàng trong thư mục, thấy hàm tính phí và bảng ánh xạ tỉnh sang vùng.
- Nó đọc bảng ánh xạ và nhận ra sau đợt sắp xếp lại đơn vị hành chính năm 2025, bảng vẫn dùng tên tỉnh cũ, tên mới không có trong bảng nên rơi vào mức phí mặc định.
- Nó viết một ca kiểm thử với địa chỉ ghi tên tỉnh mới, chạy và thấy ca đó thất bại đúng như báo cáo lỗi.
- Nó thêm tên tỉnh mới vào bảng, giữ tên cũ để đơn cũ vẫn tính đúng, chạy lại thì ca mới qua.
- Nó chạy toàn bộ bộ kiểm thử, thấy tất cả qua, rồi viết tóm tắt: nguyên nhân, tệp đã sửa, ca kiểm thử đã thêm, và một lưu ý rằng bảng còn thiếu vài tỉnh khác cần người nắm nghiệp vụ xác nhận.
Phần đáng giá nhất là bước năm: tác tử nêu ra chỗ nó không chắc thay vì tự đoán. Bạn vẫn phải đọc phần sửa, kiểm danh sách tỉnh với nguồn chính thức và quyết định có xử lý luôn các tỉnh còn lại hay không.
Vì sao tác tử đôi khi đi vòng vòng hoặc sửa cho qua
Sửa kiểm thử thay vì sửa mã. Khi mục tiêu chỉ là "làm cho kiểm thử qua", tác tử có thể chỉnh giá trị mong đợi trong kiểm thử, hoặc thêm điều kiện bỏ qua. Kiểm thử xanh nhưng lỗi vẫn còn. Dặn rõ không được sửa tệp kiểm thử đã có, và đọc phần thay đổi ở thư mục kiểm thử thật kỹ.
Lặp đi lặp lại cùng một hướng sửa. Khi lỗi nằm ở chỗ tác tử chưa thấy, như cấu hình môi trường hay dữ liệu, nó thử sửa mã hết cách này tới cách khác. Nếu thấy cùng một lỗi xuất hiện ba bốn vòng, nên dừng lại, đưa thêm thông tin hoặc tự khoanh vùng trước.
Quên lời dặn ở đầu phiên. Phiên dài làm ngữ cảnh đầy, phần đầu có thể bị tóm tắt hoặc mờ đi. Lời dặn quan trọng nên nằm trong tệp hướng dẫn dự án hoặc được nhắc lại khi giao từng việc.
Làm thêm việc không được giao. Tác tử thấy chỗ "chưa đẹp" và tiện tay sửa luôn, làm thay đổi phình to và khó rà. Giới hạn phạm vi bằng lời, bằng thư mục, và nói rõ chỉ ghi nhận chứ không sửa những chỗ ngoài phạm vi.
Việc hợp và không hợp để giao cho tác tử
Từ cơ chế vòng lặp có thể suy ra loại việc nào tác tử làm tốt: việc có đích rõ và có cách tự kiểm. Một số ví dụ để bạn hình dung:
- Hợp: sửa một lỗi đã tái hiện được bằng một ca kiểm thử, vì tác tử biết chính xác khi nào xong.
- Hợp: nâng phiên bản một thư viện rồi sửa những chỗ hỏng mà trình biên dịch hoặc kiểm thử chỉ ra.
- Hợp: thêm một tính năng nhỏ theo khuôn đã có sẵn trong dự án, như thêm một trường mới vào biểu mẫu đã có năm trường tương tự.
- Kém hợp: việc mà đúng hay sai chỉ người dùng cuối mới cảm nhận được, như bố cục giao diện "trông dễ chịu hơn", vì tác tử không có cách tự kiểm.
- Kém hợp: việc đòi hỏi quyết định nghiệp vụ chưa ai chốt, như chính sách hoàn tiền khi khách huỷ đơn giữa chừng. Tác tử sẽ tự chọn một chính sách nghe hợp lý.
- Không nên: thao tác trực tiếp trên dữ liệu thật, máy chủ thật, hoặc bất cứ việc gì không hoàn tác được.
Nếu một việc thuộc nhóm kém hợp, bạn vẫn dùng được tác tử cho phần chuẩn bị, như đọc mã và liệt kê các chỗ cần đổi, rồi tự quyết phần còn lại.
Quyền hạn: cài đặt sao cho tác tử làm được việc mà không làm được chuyện lớn
Tác tử chạy lệnh bằng quyền của tài khoản đang dùng. Nếu bạn mở nó trên máy có quyền truy cập máy chủ thật, cơ sở dữ liệu thật, hay khoá đăng nhập dịch vụ đám mây, thì về nguyên tắc nó có thể chạm tới những thứ đó. Không cần tác tử "có ý xấu" mới gây hại: một lệnh dọn dẹp chạy nhầm thư mục, một câu lệnh cập nhật thiếu điều kiện lọc là đủ.
Ba nguyên tắc đơn giản giải quyết phần lớn rủi ro. Một, cho tác tử làm trên nhánh git riêng và một bản sao dự án, không làm thẳng trên nhánh chính hay trên máy chủ. Hai, dùng chế độ hỏi trước với các lệnh có thể phá dữ liệu hoặc gửi dữ liệu ra ngoài, và chỉ cho phép sẵn những lệnh vô hại như chạy kiểm thử. Ba, để khoá bí mật ngoài thư mục dự án hoặc trong biến môi trường mà tác tử không cần đọc.
Các cách cấu hình chi tiết hơn, như chạy tác tử trong vùng cách ly hay trong máy ảo, và quy ước khi cả nhóm cùng dùng tác tử, được bàn ở các mục an toàn mã nguồn và làm việc nhóm của trang. Ở mức hiểu nền tảng, điều cần nhớ là tác tử mạnh đúng bằng quyền bạn cấp, và hậu quả của một bước sai cũng lớn đúng bằng quyền đó.
Câu hỏi thường gặp
Tác tử AI lập trình có tự đẩy mã lên máy chủ không?
Chỉ khi nó được cấp quyền chạy các lệnh làm việc đó và bạn cho phép. Cách an toàn là để tác tử chỉ làm trên nhánh riêng ở máy cá nhân, còn bước gộp mã và triển khai do người làm sau khi rà.
Giao cho tác tử việc lớn cả ngày có được không?
Có thể, nhưng việc càng dài càng dễ lạc hướng và càng khó rà. Chia thành nhiều việc nhỏ có điểm kiểm rõ ràng, mỗi việc một nhánh hoặc một lần gộp, thường cho kết quả tốt hơn và bạn dễ dừng đúng lúc.
Tác tử và tự động hoá bằng kịch bản khác nhau thế nào?
Kịch bản tự động làm đúng các bước bạn viết sẵn, lần nào cũng giống nhau. Tác tử tự quyết bước tiếp theo dựa trên kết quả, nên xử lý được tình huống chưa lường trước nhưng cũng khó đoán trước nó sẽ làm gì.
Vì sao tác tử báo đã xong mà chương trình vẫn lỗi?
Tác tử chỉ biết những gì nó kiểm được. Nếu bộ kiểm thử không phủ chỗ lỗi, hoặc nó không chạy thử phần giao diện, nó có thể tự tin báo xong. Luôn tự chạy lại kiểm thử và thử bằng tay luồng chính.
Dùng tác tử có cần biết dòng lệnh không?
Nên biết ở mức đọc hiểu, vì bạn sẽ phải duyệt các lệnh tác tử định chạy. Nếu không đọc được một lệnh làm gì, đừng cho phép nó chạy cho tới khi đã tra hoặc hỏi lại.
Tác tử có đọc được tài liệu thư viện trên mạng không?
Nếu được cấp công cụ truy cập mạng thì có. Điều này giúp nó dùng đúng phiên bản thư viện mới, nhưng cũng mở đường cho nội dung trang web cài sẵn chỉ dẫn nhắm vào AI, nên chỉ bật khi cần.