- Các tác nhân lập trình như Claude Code của Anthropic và Codex CLI của OpenAI cải thiện một cách căn bản tính hữu dụng của LLM trong việc tạo ra mã chạy được, vì chúng có thể trực tiếp chạy mã, sửa lỗi, khám phá các triển khai hiện có và tìm ra giải pháp hiệu quả thông qua thử nghiệm
- Kỹ thuật cốt lõi để khai thác tối đa tiềm năng của những công cụ này là thiết kế vòng lặp tác nhân; nếu thu hẹp bài toán cho tác nhân lập trình bằng một mục tiêu rõ ràng và một bộ công cụ cụ thể, ta có thể hiểu nó như một công cụ có khả năng tìm ra lời giải hiệu quả theo kiểu vét cạn
- Định nghĩa của tác nhân LLM là thực thi công cụ bên trong một vòng lặp để đạt được mục tiêu, và kỹ năng để sử dụng tốt là thiết kế cẩn thận các công cụ và vòng lặp mà tác nhân sẽ dùng
- Chế độ YOLO (mọi lệnh đều được phê duyệt mặc định) tuy rủi ro nhưng là yếu tố then chốt để đạt kết quả năng suất nhất thông qua phương pháp vét cạn; để chạy an toàn có thể chọn sandbox Docker, một môi trường máy tính khác như GitHub Codespaces, hoặc chấp nhận rủi ro
- Việc chọn đúng công cụ (lệnh shell và gói), cấp thông tin xác thực với phạm vi bị giới hạn nghiêm ngặt (môi trường kiểm thử, giới hạn ngân sách), và áp dụng cho các bài toán có tiêu chí thành công rõ ràng nhưng cần thử-sai (debug, tối ưu hiệu năng, nâng cấp dependency, tối ưu container) là những nguyên tắc cốt lõi của thiết kế vòng lặp tác nhân
Niềm vui của chế độ YOLO
-
Rủi ro của tác nhân
- Tác nhân về bản chất là rủi ro
- Có thể đưa ra quyết định sai hoặc trở thành nạn nhân của tấn công prompt injection ác ý
- Có thể gây ra hậu quả có hại thông qua việc gọi công cụ
- Công cụ tác nhân lập trình mạnh nhất là “chạy lệnh này trong shell”, nên một tác nhân mất kiểm soát có thể làm mọi thứ mà người dùng có thể tự làm bằng cách trực tiếp chạy lệnh
- Trích dẫn của Solomon Hykes:
> AI agent là LLM phá hủy môi trường trong một vòng lặp
-
Giới hạn của chế độ phê duyệt mặc định
- Các tác nhân lập trình như Claude Code đối phó bằng cách mặc định yêu cầu phê duyệt cho gần như mọi lệnh mà chúng chạy
- Điều này hơi phiền, nhưng quan trọng hơn là nó làm giảm mạnh hiệu quả giải quyết vấn đề bằng phương pháp vét cạn
-
Chế độ YOLO
- Mỗi công cụ đều cung cấp phiên bản riêng của chế độ YOLO, nơi mọi thứ đều được phê duyệt mặc định
- Cực kỳ rủi ro nhưng cũng là chìa khóa để đạt được kết quả năng suất nhất
-
Ba rủi ro chính của chế độ YOLO không giám sát
- 1. Lệnh shell xấu: xóa hoặc phá hỏng thứ gì đó quan trọng
- 2. Tấn công rò rỉ: đánh cắp tệp hoặc dữ liệu mà tác nhân có thể nhìn thấy (mã nguồn hoặc bí mật được lưu trong biến môi trường)
- 3. Tấn công proxy: dùng máy làm proxy để ngụy trang nguồn gốc của DDoS hoặc các cuộc tấn công hack khác nhắm vào mục tiêu khác
Các lựa chọn để chạy chế độ YOLO
-
Lựa chọn 1: sandbox bảo mật
- Chạy tác nhân trong sandbox bảo mật để giới hạn các tệp và bí mật mà nó có thể truy cập, cũng như các kết nối mạng mà nó có thể tạo ra
- Dù vẫn có khả năng thoát container, việc dùng Docker hoặc công cụ container mới của Apple là mức rủi ro chấp nhận được với đa số người dùng
- Tài liệu Safe YOLO mode của Anthropic:
- dùng
--dangerously-skip-permissions trong container không có truy cập Internet
- cung cấp triển khai tham chiếu bằng Docker Dev Containers
- giới hạn truy cập Internet vào danh sách host đáng tin cậy là cách tốt để ngăn mã nguồn riêng tư bị đánh cắp
-
Lựa chọn 2: dùng máy tính của người khác (ưu tiên)
- Kể cả khi tác nhân mất kiểm soát thì thiệt hại cũng bị giới hạn
- Khuyến nghị dùng GitHub Codespaces:
- cung cấp môi trường container đầy đủ theo yêu cầu, có thể truy cập qua trình duyệt
- có gói miễn phí khá hào phóng
- nếu có sự cố, tệ nhất là một máy Microsoft Azure ở đâu đó tiêu tốn CPU, môi trường có thể bị lộ mã đã checkout cho kẻ tấn công, hoặc mã xấu có thể bị push vào repository GitHub đã kết nối
- Các công cụ kiểu tác nhân khác chạy mã trên máy của người khác:
- chế độ Code Interpreter của ChatGPT và Claude
- Codex Cloud của OpenAI
-
Lựa chọn 3: chấp nhận rủi ro
- Cố tránh để lộ trước các nguồn chỉ dẫn có khả năng ác ý và hy vọng sẽ phát hiện sai sót trước khi chúng gây thiệt hại
- Đây là lựa chọn mà phần lớn mọi người dùng
Chọn công cụ phù hợp cho vòng lặp
-
Sau khi đã có chế độ YOLO an toàn
- Bước tiếp theo là quyết định những công cụ nào nên được cung cấp cho tác nhân lập trình
-
Ưu tiên lệnh shell
- Ở giai đoạn này có thể trộn thêm MCP (Model Context Protocol), nhưng nhìn từ góc độ lệnh shell thường sẽ hiệu quả hơn
- Các tác nhân lập trình thực sự rất giỏi trong việc chạy lệnh shell
- Nếu môi trường cho phép truy cập mạng cần thiết, chúng cũng có thể lấy thêm package từ NPM, PyPI và các nguồn khác
- Một điểm quan trọng khác là đảm bảo tác nhân chạy trong môi trường mà việc cài package ngẫu nhiên không thể làm hỏng các thứ trên máy chính của bạn
-
Tận dụng tệp AGENTS.md
-
Tận dụng công cụ sẵn có
- Các LLM giỏi đã biết cách dùng một dải công cụ sẵn có nhiều đến mức đáng kinh ngạc
- Chỉ cần nói “dùng playwright python” hoặc “dùng ffmpeg”, đa số mô hình sẽ sử dụng hiệu quả
- Vì chạy trong vòng lặp, chúng thường có thể phục hồi sau những sai lầm ban đầu và tự tìm ra thứ tự đúng mà không cần chỉ dẫn thêm
Cấp thông tin xác thực với phạm vi giới hạn nghiêm ngặt
-
Sự cần thiết của thông tin xác thực
- Ngoài việc phơi bày đúng lệnh, còn cần cân nhắc thông tin xác thực nào nên được cấp cho các lệnh đó
- Lý tưởng nhất là không cần thông tin xác thực nào cả (nhiều việc có thể làm mà không cần đăng nhập hay API key), nhưng một số bài toán nhất định đòi hỏi truy cập đã xác thực
-
Hai khuyến nghị cốt lõi
- 1. Cấp thông tin xác thực cho môi trường kiểm thử hoặc staging
- nơi thiệt hại có thể được giới hạn tốt
- 2. Đặt giới hạn ngân sách
- nếu thông tin xác thực có thể dùng để tiêu tiền, hãy đặt giới hạn ngân sách nghiêm ngặt
-
Ví dụ thực tế: điều tra trên Fly.io
- Điều tra thời gian cold start chậm của một ứng dụng scale-to-zero đang chạy trên Fly.io
- Cho phép Claude Code trực tiếp chỉnh sửa Dockerfile, triển khai lên tài khoản Fly và đo thời gian khởi động
-
Thiết lập an toàn
- Trên Fly có thể tạo một tổ chức, đặt giới hạn ngân sách cho tổ chức đó và phát hành Fly API key chỉ có thể tạo hoặc sửa ứng dụng bên trong tổ chức đó
- Tạo một tổ chức chuyên dụng chỉ cho cuộc điều tra này
- đặt ngân sách $5
- phát hành API key và thả Claude Code vào làm việc
- Dù trong trường hợp cụ thể này kết quả không đủ hữu ích, đây là dự án đầu tiên khiến tác giả nhận ra rằng “thiết kế vòng lặp tác nhân” là một kỹ năng quan trọng cần phát triển
Khi nào nên thiết kế vòng lặp tác nhân
-
Mẫu bài toán phù hợp
- Không phải bài toán nào cũng phù hợp với kiểu làm việc này
- Điều cần tìm là các bài toán có tiêu chí thành công rõ ràng và nhiều khả năng cần thử-sai (có thể hơi nhàm chán) để tìm ra lời giải tốt
- Mỗi khi bạn nghĩ “hừm, chắc ở đây phải thử rất nhiều biến thể”, đó là tín hiệu mạnh cho thấy đáng để thử một vòng lặp tác nhân
-
Ví dụ cụ thể
-
Debug
- Test đang fail và cần điều tra nguyên nhân gốc rễ
- Một tác nhân lập trình đã có thể chạy test thì có thể làm việc này mà không cần thiết lập bổ sung
-
Tối ưu hiệu năng
- Truy vấn SQL quá chậm, thêm index có giúp không?
- Tác nhân có thể benchmark truy vấn và (trong môi trường phát triển được cô lập!) thêm rồi xóa index để đo tác động
-
Nâng cấp dependency
- Bạn đang tụt lại phía sau ở nhiều dependency cần nâng cấp
- Nếu test suite đủ vững, vòng lặp tác nhân có thể nâng cấp tất cả và thực hiện những cập nhật nhỏ cần thiết để thích ứng với các thay đổi breaking
- Hãy đảm bảo có bản sao release note liên quan hoặc tác nhân biết nơi tự tìm chúng
-
Tối ưu kích thước container
- Docker container quá lớn đến mức bất tiện
- Tác nhân có thể thử các base image khác nhau và lặp lại trên Dockerfile để giảm kích thước trong khi vẫn giữ cho test pass
-
Chủ đề chung: kiểm thử tự động
- Điểm chung của tất cả các trường hợp này là kiểm thử tự động
- Giá trị bạn nhận được từ tác nhân lập trình và các công cụ lập trình LLM khác được khuếch đại rất mạnh khi có một test suite tốt, pass sạch
- May mắn là LLM cũng rất giỏi trong việc tăng tốc quá trình xây dựng test suite nếu bạn chưa có
Đây vẫn là một lĩnh vực còn rất mới
- Thiết kế vòng lặp tác nhân là một kỹ năng rất mới
- Claude Code mới được phát hành lần đầu vào tháng 2 năm 2025
- Tác giả hy vọng rằng việc đặt cho nó một cái tên rõ ràng sẽ giúp tạo ra những cuộc trao đổi hiệu quả hơn về chủ đề này
- Vẫn còn rất nhiều điều cần khám phá về cách sử dụng những công cụ này hiệu quả nhất có thể
Chưa có bình luận nào.