Tôi gần đây bắt đầu sử dụng Visual Studio Code Dev Containers cùng với các agent lập trình LLM và muốn chia sẻ điều này vì, theo quan điểm của tôi, đây là một trong những cách đơn giản nhất để việc phát triển với agent trở nên an toàn hơn.
* * *
Các agent LLM cực kỳ hữu ích, nhưng lần đầu tiên bạn chạy một agent với quyền truy cập đầy đủ vào laptop, bạn có thể có cùng một suy nghĩ mà tôi đã từng:
> “Tôi có thực sự muốn thứ này thấy toàn bộ hệ thống tệp của mình, khóa SSH, thông tin xác thực đám mây và tất cả các dự án ngẫu nhiên mà tôi có trên máy không?”
### Trải Nghiệm Lập Trình Viên (Developer Experience)
Trải nghiệm lập trình viên tốt nhất không chỉ về tốc độ. Nó còn về việc có một môi trường mà bạn có thể thử nghiệm mà không ngừng lo lắng về những gì công cụ có thể chạm vào.
Đây là nơi Dev Containers cực kỳ hữu ích: bạn có thể cung cấp cho agent một không gian làm việc sạch sẽ, chính xác các phụ thuộc nó cần, và không gì khác.
### Visual Studio Code Dev Containers
[Extension Visual Studio Code Dev Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) cho phép bạn sử dụng một Docker container làm môi trường phát triển đầy đủ tính năng. Nó cho phép bạn mở bất kỳ thư mục hoặc kho lưu trữ nào bên trong một container và tận dụng đầy đủ bộ tính năng của Visual Studio Code.
Đối với các agent LLM, điều này có nghĩa là bạn có thể chạy trình soạn thảo, terminal, các công cụ và agent bên trong một container thay vì trực tiếp trên máy của mình.
Agent vẫn có thể chỉnh sửa tệp, chạy thử nghiệm, cài đặt gói và thực thi lệnh, nhưng chỉ bên trong môi trường mà bạn đã chuẩn bị cho nó.
### Tại Sao Điều Này Quan Trọng Với Các Agent LLM
Khi bạn chạy agent trên máy cục bộ, rủi ro không chỉ là nó viết code sai.
Mối quan tâm lớn hơn là **quyền truy cập**. Nếu toàn bộ thư mục home của bạn khả dụng, agent có thể vô tình đọc các tệp không liên quan đến dự án. Nếu shell của bạn có quyền truy cập vào thông tin xác thực, token, CLI đám mây, cấu hình SSH hoặc các script production, **phạm vi tác động (blast radius)** sẽ lớn hơn nhiều.
Với Dev Container, bạn có thể tránh chia sẻ toàn bộ hệ thống và thông tin xác thực của mình. Bạn chỉ gắn kết (mount) các thư mục dự án mà bạn muốn làm việc, cài đặt chỉ những công cụ cần thiết cho môi trường đó, và quyết định rõ ràng哪些 thông tin xác thực, nếu có, được cung cấp.
### Chế Độ YOLO
Nhiều công cụ lập trình LLM có chế độ mà agent có thể chạy lệnh và chỉnh sửa tệp mà không cần xác nhận mỗi lần. Đôi khi người ta gọi đây là **”chế độ YOLO”**.
Nó tiện lợi, nhưng trên máy host của bạn thì có thể đáng sợ. Bên trong một Dev Container, nó trở nên hợp lý hơn nhiều: nếu agent cài đặt sai package, phá vỡ môi trường, hoặc gây ra sự hỗn loạn, bạn có thể **rebuild container và bắt đầu lại**. Bạn không đang cho nó toàn bộ laptop của mình. Bạn đang cho nó một **hộp phát triển dùng một lần (disposable development box)**.
### Thiết Lập Của Tôi
Thay vì thêm thư mục `.devcontainer` vào mỗi dự án, tôi giữ một thư mục riêng biệt chỉ mô tả môi trường agent. Cấu trúc giống như sau:
.
|– devcontainer
| |– devcontainer.json
| `– Dockerfile
|– project-a
|– project-b
`– project-c
“`
Tôi xây dựng và khởi chạy container từ thư mục `devcontainer`. Sau đó, khi muốn làm việc trên một dự án, tôi gắn kết thư mục dự án đó vào container đang chạy và kết nối VS Code với container.
Điều này cho tôi một môi trường có thể tái sử dụng cho các agent LLM, mà không cần sao chép cùng một cấu hình Dev Container vào mỗi kho lưu trữ.
### Cấu Hình
#### devcontainer.json
Tệp `devcontainer.json` mô tả môi trường container có thể tái sử dụng. Đây là một ví dụ đơn giản:
“`json
{
“name”: “agent-safe-workspace”,
“build”: { “dockerfile”: “Dockerfile” },
“workspaceFolder”: “/workspaces”,
“remoteUser”: “node”
}
“`
Ý tưởng quan trọng là thư mục này mô tả **hộp agent**, không phải một ứng dụng cụ thể. Các dự án của bạn có thể vẫn tách biệt, và bạn quyết định dự án nào được gắn kết vào container đang chạy.
#### Dockerfile
Dockerfile định nghĩa những gì được cài đặt bên trong container. Ví dụ, đối với môi trường dựa trên Node.js:
“`dockerfile
FROM mcr.microsoft.com/devcontainers/javascript-node:1-22-bookworm
RUN apt-get update && apt-get install -y \
ripgrep \
jq \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /workspaces
“`
Bạn có thể điều chỉnh tùy theo stack của mình: Python, Go, Rust, Java, hoặc bất kỳ thứ gì khác. Phần quan trọng là các phụ thuộc được cài đặt trong container, không trực tiếp trên máy host của bạn.
### Khởi Chạy Container
Từ thư mục chứa cấu hình Dev Container, bạn khởi chạy container riêng biệt. Ví dụ, bạn có thể sử dụng extension Dev Containers để mở chỉ thư mục `devcontainer` đó, hoặc bạn có thể tự xây dựng và chạy image Docker.
Sau khi container chạy, gắn kết VS Code với nó bằng lệnh:
`Dev Containers: Attach to Running Container`
Tại thời điểm đó, bạn đang ở bên trong môi trường bị cô lập. Sau đó, bạn gắn kết hoặc gắn (mount) thư mục dự án bạn muốn làm việc vào container và mở nó từ đó.
Quy trình trở thành:
- Khởi chạy container agent có thể tái sử dụng
- Gắn kết dự án của bạn vào container đang chạy với VS Code
- Chạy agent LLM bên trong container
Điều này khác với quy trình thông thường mà mỗi dự án sở hữu thư mục `.devcontainer` riêng. Trong thiết lập này, **container là môi trường công cụ ổn định**, và các thư mục dự án là các đầu vào mà bạn chọn để hiển thị cho nó.
### Thông Tin Xác Thực (Credentials)
Hãy **cố ý** với bí mật (secrets). Đừng gắn kết toàn bộ `~/.ssh`, `~/.aws`, `~/.config`, hoặc thư mục home theo mặc định.
Nếu agent cần một token, hãy tạo một token hạn chế cho nhiệm vụ đó. Nếu nó cần quyền truy cập GitHub, hãy ưu tiên một token với phạm vi hữu ích nhỏ nhất. Nếu nó không cần thông tin xác thực, đừng cung cấp.
Điểm mấu chốt của container là làm cho quyền truy cập trở nên **rõ ràng và hiển nhiên**.
### Docker
Rõ ràng, bạn cần **Docker đang chạy** trên máy của mình. Sau đó, VS Code có thể kết nối với container và cung cấp cho bạn trải nghiệm trình soạn thảo quen thường bên trong môi trường bị cô lập.
### Extension VS Code
Để sử dụng quy trình này, hãy cài đặt extension [Dev Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers). Lệnh tôi sử dụng nhiều nhất trong thiết lập này là:
`Dev Containers: Attach to Running Container`
Điều này cho phép tôi giữ vòng đời container tách biệt với vòng đời dự án.
### Sẵn Sàng Khởi Hành
Khi container đang chạy và thư mục dự án đã được gắn kết, hãy khởi chạy agent LLM từ terminal VS Code bên trong container.
Bây giờ agent thấy workspace dự án và các công cụ bạn đã cài đặt ở đó. Đó là lợi thế chính: bạn có thể để agent di chuyển nhanh hơn, thậm chí ở chế độ YOLO, trong khi giữ ranh giới rõ ràng giữa thử nghiệm và phần còn lại của máy bạn.
Đây không phải là giải pháp bảo mật ma thuật, nhưng nó là **một cải tiến thực tế rất lớn**. Phần duy nhất tẻ nhạt là viết Dockerfile chính xác, nhưng khi đã hoàn thành, môi trường trở nên có thể tái sử dụng, có thể dự đoán và an toàn để sử dụng.
Đối với việc lập trình hàng ngày với agent, một **Dev Container dùng một lần có thể tái sử dụng** là một trong những cách dễ dàng nhất để giảm thiểu rủi ro mà không làm cho quy trình trở nên đau đớn.
* * *
Bạn có thể [theo dõi tôi trên GitHub](https://github.com/gioboa), nơi tôi đang tạo ra các dự án thú vị.
Tôi hy vọng bạn thích bài viết này, hẹn gặp lại lần sau 👋
