Tại sao nên chạy AI coding agent trên máy ảo dùng một lần

Tại sao một máy ảo dùng một lần lại tốt hơn laptop của bạn

Hãy cấp cho một coding agent một máy ảo dùng một lần, điều tồi tệ nhất nó có thể làm là phá hủy một cỗ máy mà bạn có thể dựng lại trong mười phút. Agent đó vẫn có quyền root, vẫn cài đặt các gói, vẫn chạy bộ test suite mà không cần xin phép cho từng bước. Sự khác biệt nằm ở chỗ thiệt hại xảy ra ở đâu. Trên laptop, agent dùng chung thư mục home với các SSH key, profile trình duyệt, các tệp .env của bạn và mọi repository khác mà bạn từng clone. Trên một server dùng một lần, nó chỉ có một shell, một bản checkout và không có gì khác đáng giá để lấy.

Đó là toàn bộ lập luận, và đây là lập luận về sự bất đối xứng thay vì xác suất. Một agent cẩn thận trên một chiếc laptop được bảo vệ kỹ lưỡng gần như luôn ổn. Nhưng lần duy nhất nó không ổn, cái giá phải trả không chỉ là một commit lỗi. Đó là việc phải khôi phục từ bản backup, nếu bạn có.

Xác định phạm vi ảnh hưởng trước khi tranh luận về nó

Phạm vi ảnh hưởng (blast radius) là tập hợp các tài nguyên mà một tiến trình có thể truy cập. Đối với một agent chạy dưới quyền người dùng thông thường trên máy tính của bạn, tập hợp đó lớn hơn mức mà hầu hết mọi người hình dung.

Nó bao gồm ~/.ssh/id_ed25519, thường không được mã hóa vì bạn đã quá mệt mỏi với việc nhập passphrase. Nó bao gồm ~/.aws/credentials và ~/.config/gh/hosts.yml, vốn là văn bản thuần túy theo thiết kế. Nó bao gồm mọi repository nằm cùng cấp trong ~/code, kể cả những repository chứa chuỗi kết nối production trong file env cục bộ. Nó bao gồm lịch sử shell của bạn, nơi lưu trữ các token mà bạn đã từng dán vào. Nó cũng bao gồm mạng mà laptop của bạn đang kết nối, thường là mạng gia đình hoặc văn phòng với các dịch vụ không yêu cầu xác thực.

Không điều nào trong số đó đòi hỏi một agent độc hại. Nó chỉ cần một lệnh sai lầm đầy tự tin. rm -rf với một biến chưa được thiết lập mở rộng thành /, một lệnh git clean -xfd trong thư mục sai, một lệnh docker system prune -af --volumes xóa sạch cơ sở dữ liệu cục bộ của bạn, một lệnh chmod -R 777 "hữu ích" trên thư mục home. Các agent được huấn luyện trên cùng một internet đã dạy những lệnh đó cho tất cả mọi người.

Cơ chế cứu bạn không phải là khả năng phán đoán của agent. Đó là việc máy tính chứa rủi ro là máy tính mà bạn sẵn sàng chấp nhận mất mát.

Phép tính chi phí rất nhàm chán, và đó chính là vấn đề

Một VPS nhỏ chỉ tốn vài đô la mỗi tháng. Việc khôi phục một chiếc laptop của lập trình viên tốn mất một ngày, đó là trường hợp tốt nhất khi bạn nhận ra ngay lập tức và đã có bản sao lưu.

Hãy tự tính toán với các con số của riêng bạn. Lấy mức lương theo giờ của bạn, nhân với số giờ cần thiết để cài đặt lại hệ điều hành, khôi phục thư mục home, thay đổi SSH key, thay đổi personal access token và clone lại hai mươi repository. So sánh con số đó với chi phí mười hai tháng cho gói server nhỏ nhất mà nhà cung cấp của bạn bán. Điểm hòa vốn nằm ở mức dưới một sự cố mỗi vài năm, và sự cố đó không cần phải quá nghiêm trọng để vượt qua ngưỡng này. Chỉ cần một buổi chiều bị mất do môi trường cục bộ bị lỗi là đã đủ chi trả cho cả năm.

Phần thứ hai của phép tính là snapshot. Một bản snapshot trước khi thực hiện một thao tác rủi ro sẽ biến kết quả tồi tệ từ "khôi phục lại toàn bộ cuộc sống của tôi" thành "roll back và thử một prompt khác". Tùy chọn đó không tồn tại trên chiếc laptop mà bạn đang dùng để gõ những dòng này, vì bạn không thể snapshot một cỗ máy trong khi đang sử dụng nó làm bàn làm việc.

Bối cảnh tính đến tháng 7 năm 2026

Có ba câu trả lời trung thực cho câu hỏi "agent nên chạy ở đâu", và chúng đánh đổi giữa hai yếu tố: độ mạnh của ranh giới bảo mật và mức độ thiết lập mà bạn chấp nhận.

Một micro VM cục bộ. Các công cụ trong danh mục này khởi động một máy ảo thực trên phần cứng của bạn, mount repository của bạn vào đó và cho phép agent có quyền root bên trong. clawk là ví dụ hiện tại, và luận điểm của nó chính xác là luận điểm của bài viết này: hãy cung cấp cho các coding agent một Linux VM dùng một lần, thay vì dùng laptop của bạn. Tính đến tháng 7 năm 2026, nó nhắm đến macOS 14 trở lên trên Apple silicon, với hỗ trợ Linux thử nghiệm thông qua Firecracker, và nó được cài đặt bằng brew install clawkwork/tap/clawk. Bạn chạy clawk bên trong một repository để khởi động sandbox và gắn agent vào, clawk down để dừng nó, và clawk destroy để xóa nó. Ranh giới ở đây là hypervisor, vốn rất mạnh. Hạn chế là VM nằm trên máy bạn mang theo, vì vậy nó cạnh tranh tài nguyên bộ nhớ và sẽ dừng khi bạn gập máy.

Một container. Docker là câu trả lời mà hầu hết mọi người đã cài đặt sẵn, và nó thực sự hữu ích.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm loại bỏ container khi thoát và --network none không cấp cho nó bất kỳ kết nối mạng nào, đây là thiết lập mặc định tốt cho một bản build hoặc một lần chạy test. Hãy hiểu rõ những gì nó không làm được: một container chia sẻ kernel của host, vì vậy một lỗi kernel là một cách để thoát ra ngoài, và ranh giới sẽ biến mất ngay khi bạn thêm --privileged hoặc mount /var/run/docker.sock để agent có thể "sử dụng Docker". Việc mount Docker socket vào một container tương đương với việc cấp cho container đó quyền root trên host.

Một VPS thông thường mà bạn có thể rebuild. Không cần công cụ mới, có ranh giới kernel thực sự, có tính năng snapshot từ nhà cung cấp, và nó vẫn tiếp tục chạy khi bạn tắt laptop. Đây là mô hình mà phần còn lại của hướng dẫn này mô tả, và đây là mô hình tồn tại được qua các phiên chạy agent dài, bởi vì một công việc mất bốn giờ không quan tâm đến việc bạn đã đi về nhà.

Mô hình VPS: cấp cho agent một user riêng

Bắt đầu từ một máy chủ đã được bảo mật. Bài viết mười phút đầu tiên trên một VPS mới bao gồm các phần không dành riêng cho agent: cập nhật, đăng nhập bằng user không phải root, SSH chỉ dùng key, và firewall.

Sau đó, hãy tạo một tài khoản chỉ dành riêng cho agent, để một sai sót bên trong đó không thể ảnh hưởng đến bất kỳ thứ gì khác trên server.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password có nghĩa là không có mật khẩu để đoán, và bạn truy cập tài khoản bằng sudo -u agent hoặc SSH key. Lưu ý rằng agent cố tình không nằm trong nhóm sudo. Một agent có sudo sẽ có quyền root, và root có thể đọc file của mọi user khác, vì vậy sự phân tách bạn vừa tạo chỉ mang tính hình thức. Nếu agent thực sự cần cài đặt các gói phần mềm, đó là lý do để dùng một server riêng biệt, chứ không phải cấp sudo trên một server dùng chung. Các quy tắc chung nằm trong nguyên tắc đặc quyền tối thiểu cho Linux user trên VPS.

Kiểm tra ranh giới trước khi bạn tin tưởng nó. Với tư cách là user agent, hãy thử đọc một file thuộc về tài khoản của chính bạn:

sudo -u agent cat /home/you/.ssh/id_ed25519

Bạn sẽ thấy cat: /home/you/.ssh/id_ed25519: Permission denied. Nếu bạn thấy nội dung key, thư mục home của bạn đang ở mode 755 và sự cô lập chưa thực sự tồn tại. Hãy sửa nó bằng sudo chmod 700 /home/you.

Giữ thông tin xác thực hoàn toàn bên ngoài máy chủ

Mục đích của một máy chủ dùng một lần sẽ mất đi nếu bạn sao chép các bí mật sản xuất (production secrets) vào đó. Quy tắc rất đơn giản: không được để bất kỳ thông tin xác thực nào trên máy đó mà bạn sẽ thấy phiền nếu phải thay đổi (rotate) ngay trong chiều nay.

Đối với git, hãy chuyển tiếp SSH agent thay vì sao chép key. Private key vẫn nằm trên laptop của bạn và chỉ các yêu cầu chữ ký mới đi qua kết nối.

ssh -A agent@203.0.113.10
ssh -T git@github.com

Lệnh thứ hai sẽ trả về Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Điều đó chứng minh git push sẽ hoạt động mà không cần tệp key nào trên máy chủ. Hãy chạy ls -la ~/.ssh trên máy đó sau đó và xác nhận rằng không có private key nào trong đó.

Chuyển tiếp agent có một lưu ý thực sự, cần nêu rõ: khi bạn đang kết nối, bất kỳ ai có quyền root trên máy chủ đó đều có thể sử dụng socket được chuyển tiếp để xác thực dưới danh nghĩa của bạn. Trên một máy chủ mà người dùng duy nhất là bạn, đó là một sự đánh đổi chấp nhận được. Trên một máy chủ dùng chung thì không, và một deploy key giới hạn cho một repository là giải pháp tốt hơn. Các lựa chọn này được đề cập trong các kiến thức cơ bản về quản lý SSH key.

Đối với API key, hãy cấp cho agent một key riêng với hạn mức chi tiêu riêng, được lưu trong một tệp mà người dùng agent sở hữu với mode 600. Khi máy bị hủy, hãy thu hồi key đó thay vì phải băn khoăn liệu nó có bị rò rỉ hay không. Việc giữ cho chi phí mô hình hiển thị theo từng key cũng là cách để các con số trong kiểm soát chi phí AI agent trên VPS duy trì sự ổn định.

Giới hạn phạm vi truy cập mạng của agent

Cô lập hệ thống tệp chỉ là một nửa của ranh giới bảo mật. Nửa còn lại là egress: những gì tiến trình được phép kết nối tới. Linux có thể lọc lưu lượng truy cập đi dựa trên người dùng đã tạo ra nó, điều này hoàn toàn phù hợp với mô hình này.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

Các quy tắc được đọc theo thứ tự, vì vậy REJECT cuối cùng sẽ chặn mọi thứ mà các dòng trước đó không cho phép. Hãy kiểm tra với tư cách là agent:

sudo -u agent curl -sS -m 5 http://example.com

Lệnh đó sẽ thất bại với curl: (7) Failed to connect to example.com port 80: Connection refused, vì quy tắc từ chối phản hồi ngay lập tức thay vì để kết nối bị treo. Một yêu cầu HTTPS tới cùng máy chủ đó vẫn sẽ thành công.

Có hai giới hạn cần lưu ý. Thứ nhất, các quy tắc này sẽ mất sau lần khởi động lại tiếp theo trừ khi bạn lưu chúng bằng sudo apt install -y iptables-persistent và sau đó là sudo netfilter-persistent save. Thứ hai, cách này lọc theo cổng và địa chỉ, không phải theo tên miền. Một quy tắc cho phép cổng 443 sẽ cho phép mọi máy chủ HTTPS trên internet, đủ để truy cập API của model nhưng cũng đủ để truy cập một trang pastebin. Một danh sách cho phép tên miền thực thụ yêu cầu lưu lượng truy cập phải đi qua một proxy có khả năng đọc hostname được yêu cầu, đây là hệ thống phức tạp hơn mức mà hầu hết các thiết lập của lập trình viên cá nhân mong muốn. Hãy chỉ khẳng định những gì bạn có: kiểm soát egress ở cấp độ cổng, trên một máy chủ mà bạn đã chuẩn bị tâm lý để mất.

Đưa về trạng thái sạch giữa các tác vụ

Trạng thái sạch cho mỗi tác vụ là một lợi ích thường bị đánh giá thấp. Một agent đã dành ba giờ cho ticket trước đó để lại các gói đã cài đặt, các migration mới chạy một nửa, một node_modules cũ, và một git working tree với các thay đổi chưa được ai review. Tác vụ tiếp theo sẽ kế thừa tất cả những thứ đó, và bạn phải tốn thời gian review để xác định mớ hỗn độn nào thuộc về lần chạy nào.

Cách làm rẻ tiền là thực hiện một bản checkout mới cho mỗi tác vụ.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

Cách làm mạnh mẽ hơn là sử dụng snapshot của nhà cung cấp, được thực hiện một lần ngay sau khi máy chủ được thiết lập và trước khi bất kỳ agent nào chạm vào nó. Việc khôi phục snapshot đó sẽ đưa toàn bộ hệ thống, bao gồm cả các gói, về một trạng thái đã biết. Hầu hết các nhà cung cấp đều cung cấp tính năng này trong bảng điều khiển hoặc thông qua API thay vì dưới dạng lệnh trên máy, vì vậy các bước chính xác sẽ phụ thuộc vào nhà cung cấp của bạn. Kỷ luật ở đây là thực hiện snapshot khi máy chủ vẫn còn ở trạng thái mặc định.

Hãy giữ mọi thứ bạn quan tâm bên ngoài máy chủ dùng một lần, điều này chủ yếu có nghĩa là push các branch thay vì lưu trữ chúng cục bộ. Nếu máy chủ thực sự chứa thứ gì đó mà bạn sẽ thấy tiếc nếu mất, hãy sao lưu nó đúng cách với sao lưu restic trên VPS. Một máy chủ mà bạn có thể hủy chỉ hữu ích nếu việc hủy nó thực sự không gây ra vấn đề gì.

Nếu bạn muốn có nhiều môi trường cô lập mà không phải trả tiền cho nhiều máy chủ, một VPS lớn hơn có thể host trực tiếp các máy ảo khách. Ảo hóa lồng nhau trên VPS bao gồm cách thức hoạt động của nó, bao gồm cả cách kiểm tra xem nhà cung cấp của bạn có cho phép hay không.

Khi nào dùng laptop là hoàn toàn ổn

Hãy thành thật về điều này, vì việc thổi phồng quá mức về tính cô lập sẽ khiến mọi người ngừng lắng nghe.

Nếu bạn xem xét kỹ từng lệnh trước khi thực thi, thì dùng laptop là ổn. Prompt cấp quyền là một cơ chế kiểm soát thực sự, và chạy Claude Code an toàn trên server sẽ giải thích chi tiết những gì mỗi cấp độ thực sự chặn lại. Nếu công việc của bạn chỉ nằm trong một repository duy nhất và không chứa bất kỳ thông tin xác thực production nào trên máy, thì phạm vi ảnh hưởng đã nhỏ sẵn rồi. Nếu các phiên làm việc của agent ngắn và có sự giám sát, thì khoảng thời gian rủi ro cũng ngắn.

Câu trả lời sẽ thay đổi ngay khi bạn bỏ qua các prompt. Các tiến trình chạy không giám sát, các tác vụ chạy qua đêm và bất kỳ quy trình làm việc nào mà bạn phê duyệt kế hoạch rồi bỏ đi đều loại bỏ sự kiểm soát của con người vốn đang đóng vai trò ngăn chặn. Đó là lúc máy móc phải tự thực hiện việc đó. Điều tương tự cũng áp dụng cho bất kỳ thứ gì mở rộng phạm vi tiếp cận của agent, bao gồm cả việc chạy coding agent trên VPS cho nhiều repository cùng một lúc.

Quyết định này không thực sự nằm ở việc bạn tin tưởng model đến mức nào. Nó nằm ở những gì đang tồn tại bên cạnh khi model đưa ra kết quả sai.

FAQ

Container có đủ khả năng cô lập cho một coding agent không?

Với hầu hết công việc, câu trả lời là có, với hai điều kiện. Container không được chạy với --privileged và không được mount /var/run/docker.sock vào bên trong, vì cả hai đều cung cấp cho tiến trình một đường dẫn để chiếm quyền root trên host. Container chia sẻ kernel của host, nên ranh giới bảo mật yếu hơn so với virtual machine. Nếu agent chạy code không tin cậy lấy từ internet, hãy ưu tiên dùng VM thực hoặc một server riêng biệt.

Agent có cần sudo trên server không?

Không, và việc cấp sudo sẽ phá vỡ sự cô lập mà bạn đã thiết lập, vì root có thể đọc mọi tài khoản khác trên máy. Hãy tạo user cho agent mà không có sudo và chỉ cấp quyền ghi vào thư mục làm việc của chính nó. Nếu tác vụ thực sự cần cài đặt package, hãy cấp cho agent một máy riêng thay vì quyền root trên một máy dùng chung.

Làm thế nào để agent push code lên git mà không cần đặt SSH key của tôi trên máy?

Hãy forward SSH agent của bạn bằng ssh -A khi kết nối. Các yêu cầu xác thực sẽ truyền qua kết nối trong khi private key vẫn nằm trên laptop của bạn, vì vậy ssh -T git@github.com sẽ xác thực và git push hoạt động mà không cần private key trên server. Lưu ý là root trên server đó có thể sử dụng socket đã forward khi bạn đang kết nối, vì vậy hãy sử dụng deploy key giới hạn phạm vi repository trên bất kỳ máy nào bạn dùng chung với người khác.

Agent cần VPS kích thước bao nhiêu?

Công việc của agent chủ yếu là chỉnh sửa file, chạy build và chạy test, vì vậy hãy chọn kích thước máy dựa trên yêu cầu của quá trình build thay vì model. Model được host chạy trên phần cứng của nhà cung cấp, điều này làm tăng network traffic nhưng hầu như không gây tải cục bộ. Hãy bắt đầu với 2 GB RAM cho các công việc scripting và tăng lên 8 GB nếu repository cần build container hoặc biên dịch các dự án lớn.

Tôi nên hủy và xây dựng lại máy bao lâu một lần?

Hãy xây dựng lại khi trạng thái hệ thống không còn giải thích được, và tối thiểu là bất cứ khi nào một credential trên máy có nguy cơ bị lộ. Việc checkout mới giữa các tác vụ sẽ xử lý được sự sai lệch hàng ngày, và một snapshot được tạo trước lần chạy agent đầu tiên sẽ cung cấp cho bạn một system image sạch để khôi phục. Nếu việc xây dựng lại gây tốn kém, đó là dấu hiệu cho thấy có thứ gì đó quan trọng đang tồn tại trên một máy mà bạn coi là dùng một lần.