Blog / Series AI Agents Thực Chiến

Agent Sandbox 2026: coding agents đã cần một lớp workspace chuẩn thay vì ghép tool thủ công

Vấn đề thật: vì sao mô hình “cứ thêm shell tool là xong” bắt đầu gãy

Trong giai đoạn đầu của AI agents, nhiều đội ngũ chỉ cần cho model vài khả năng cơ bản như đọc file, gọi shell, sửa patch và thế là có cảm giác agent đã “biết làm việc”. Cách này đủ để tạo demo ấn tượng. Nhưng khi bước sang production, hệ nhanh chóng lộ ra điểm yếu.

Vấn đề không chỉ là model có làm đúng hay không. Vấn đề là toàn bộ môi trường làm việc của agent có được mô tả, giới hạn và phục hồi một cách nhất quán hay không. Nếu mỗi lần chạy agent là một tổ hợp chắp vá giữa thư mục tạm, biến môi trường, quyền gọi lệnh, file mount thủ công và vài quy tắc nằm trong prompt, độ tin cậy sẽ tụt rất nhanh khi task dài hơn hoặc liên quan dữ liệu nhạy cảm.

Đây là lý do chủ đề sandbox runtime đang nóng lên. Nó nối trực tiếp vào các bài toán mà AIWiki đã theo dõi trước đó như độ tin cậy của agent, workflow, memory, approval và runtime security. Khi agent chuyển từ chat sang hành động, môi trường thực thi không còn là chi tiết phụ. Nó trở thành một lớp kiến trúc lõi.

Agent sandbox là gì, và khác gì với một bộ tool rời?

Một agent sandbox không chỉ là chỗ để agent chạy lệnh. Nó là môi trường thực thi có biên giới rõ ràng, trong đó agent biết file đầu vào nằm ở đâu, được phép ghi ra đâu, dùng công cụ nào, có quyền gì, và nếu container chết giữa chừng thì run sẽ tiếp tục như thế nào.

Nói cách khác, sandbox thêm cho hệ agent bốn thứ mà bộ tool rời thường thiếu:

1. Workspace chuẩn hóa: agent không phải đoán cấu trúc thư mục, mount file hay nơi ghi output.
2. Isolation: credentials, dữ liệu nhạy cảm và code sinh bởi model không trôi lẫn trong cùng một vùng tin cậy.
3. Durability: run dài nhiều bước có checkpoint, snapshot hoặc khả năng rehydrate khi môi trường bị mất.
4. Portability: từ local prototype lên cloud sandbox, hình dạng workspace và contract thực thi vẫn giữ được logic chung.

Điểm này cũng lý giải vì sao các cập nhật mới quanh Agents SDK đang thu hút chú ý. Câu chuyện không còn là “có thêm tool mới”, mà là một bước dịch chuyển sang model-native harness có sandbox-aware orchestration. Đây là góc khác với bài MCP. MCP giúp agent nói chuyện với tool và service tốt hơn; còn sandbox giúp agent sống trong một môi trường làm việc có cấu trúc và blast radius được khoanh vùng.

Use case end-to-end: coding agent xử lý bug nhiều repo và tài liệu liên quan

Hãy lấy một bài toán rất thực tế. Một đội vận hành có agent chuyên xử lý bug hồi quy sau deploy. Khi nhận ticket, agent phải đọc log từ hệ observability, mở hai repo liên quan, so diff với commit gần nhất, tìm chỗ gọi API thay đổi, sửa patch thử nghiệm, chạy test chọn lọc và cuối cùng tạo báo cáo cho kỹ sư trực ca.

Nếu hệ chỉ có các tool rời, chuỗi này thường gặp năm vấn đề:

• Agent không chắc repo nào là nguồn sự thật, branch nào được phép sửa.
• Output sinh ra nằm rải rác, khó gom lại thành artifact có thể review.
• Lệnh cài dependency hoặc chạy test dễ đụng môi trường host.
• Nếu container chết ở bước 17 trên 30, agent gần như phải làm lại từ đầu.
• Rất khó audit chính xác agent đã đọc file nào, ghi file nào và gọi lệnh gì.

Khi đưa sandbox chuẩn vào, flow sẽ khác hẳn:

1. Orchestrator dựng workspace từ một manifest: mount repo A ở thư mục này, repo B ở thư mục kia, log được copy vào thư mục evidence, output phải đi vào thư mục artifacts.
2. Agent bắt đầu ở chế độ read-first: đọc log, xem code, lập kế hoạch sửa.
3. Khi cần thay đổi file, quyền của agent chỉ mở ở vùng đã chỉ định, thay vì toàn máy.
4. Mỗi chặng quan trọng đều có snapshot, để nếu sandbox chết agent có thể rehydrate và đi tiếp.
5. Artifact cuối cùng gồm patch, test result, nhận định root cause và khuyến nghị rollback hoặc merge.

Điểm hay ở đây là sandbox không làm agent thông minh hơn theo nghĩa benchmark. Nó làm agent ít vỡ hơn khi phải xử lý công việc dài và nhiều bề mặt tiếp xúc. Trong production, đó mới là giá trị thực.

Kiến trúc hệ thống: manifest workspace, orchestration, checkpoint và isolation

Một lớp agent sandbox đủ dùng cho production thường có ít nhất năm mảnh ghép.

1. Workspace manifest

Đây là bản mô tả chính thức cho run: input nào sẽ được mount, thư mục nào được ghi, output nào cần thu hồi, secrets đi qua đường nào và đâu là ranh giới giữa read-only với read-write. Khi không có manifest, mọi quy ước đều trôi vào prompt hoặc code glue, rất dễ drift giữa các môi trường.

2. Harness đứng ngoài model

Model không nên vừa lập kế hoạch vừa tự quyết định toàn bộ điều kiện môi trường. Harness cần đứng ngoài để quản lý tool lifecycle, chuẩn hóa I/O, quan sát command và nối agent với policy hoặc approval layer. Đây là chỗ giao nhau rất tự nhiên với runtime governance.

3. Checkpoint và rehydration

Nếu run dài hàng chục phút hoặc hàng trăm bước, chuyện sandbox hết hạn, mạng lỗi hoặc subprocess treo không còn là ngoại lệ. Hệ cần biết lưu trạng thái đủ để agent tiếp tục thay vì lặp lại toàn bộ chuỗi suy luận và tool-use. Phần này liên quan trực tiếp đến memory, nhưng là memory ở tầng execution state, không chỉ ở tầng hội thoại.

4. Tách compute khỏi secrets

Nếu code do model sinh ra chạy trong cùng một môi trường chứa credential thật, bạn đang đặt niềm tin sai chỗ. Thiết kế tốt sẽ tách sandbox nơi agent chạy command khỏi nơi lưu khóa truy cập nhạy cảm, hoặc chỉ cấp token ngắn hạn theo từng hành động. Bài toán này đụng ngay tới identity và ủy quyền của agent.

5. Artifact contract

Đầu ra của agent không nên là một đống file ngẫu nhiên. Nó nên có contract rõ: patch ở đâu, log test ở đâu, summary ở đâu, file nào phục vụ con người review, file nào dành cho bước tự động kế tiếp. Khi artifact có cấu trúc, bạn mới có thể nối agent với CI, code review hoặc downstream workflow mà không bị rối.

Trade-off và failure mode khi đưa agent sandbox vào production

Sandbox là hướng đi đúng, nhưng không phải viên đạn bạc. Làm nửa vời còn có thể tạo thêm độ phức tạp.

1. Sandbox theater

Trên giấy có container, có manifest, có log. Nhưng thực tế agent vẫn chạy với quyền quá rộng, mount cả workspace nội bộ và không có ranh giới giữa code sinh bởi model với dữ liệu nhạy cảm. Khi đó sandbox chỉ là vỏ bọc ngôn ngữ cho một môi trường chưa thật sự an toàn.

2. Checkpoint sai mức

Nếu snapshot quá ít, agent mất môi trường là mất gần hết tiến trình. Nếu snapshot quá dày, chi phí tăng mạnh và thời gian phục hồi chậm. Đội ngũ phải chọn checkpoint theo rủi ro và giá trị của từng chặng, không nên coi mọi bước là như nhau.

3. Workspace chuẩn nhưng không chuẩn tới cùng

Nhiều hệ có manifest cho input nhưng lại không chuẩn hóa output. Kết quả là agent đọc rất trật tự nhưng khi ghi artifact thì quay về kiểu tự phát. Đây là nguyên nhân phổ biến khiến run nhìn có vẻ thành công nhưng downstream pipeline không dùng được.

4. Đồng nhất hóa mọi task

Không phải task nào cũng cần sandbox đắt tiền. Một agent chỉ tóm tắt email và một coding agent sửa nhiều repo không nên đi chung một profile thực thi. Nếu áp cùng một lớp sandbox nặng cho mọi trường hợp, latency và chi phí sẽ nhanh chóng ăn mòn lợi ích.

5. Quên yếu tố con người

Sandbox tốt đến đâu cũng không thay thế review tại các điểm có blast radius cao. Nếu patch do agent tạo đi thẳng ra production mà không có lớp xác minh phù hợp, bạn chỉ đang dời rủi ro từ prompt sang runtime mà chưa giải quyết nó.

Checklist rollout thực tế

Nếu đang muốn đưa coding agent hoặc document agent vào production, rollout nên đi theo lộ trình tăng dần mức kiểm soát.

Giai đoạn 1: phân loại task theo blast radius

• Tách task đọc, phân tích, sửa file, chạy test, deploy thành các nhóm quyền khác nhau.
• Chỉ đưa sandbox nặng vào nơi task có nhiều bước hoặc đụng tài nguyên thật.
• Đừng bắt đầu từ use case nguy hiểm nhất.

Giai đoạn 2: chuẩn hóa workspace contract

• Quy định input mount ở đâu, output ghi ở đâu, file nào là artifact chính thức.
• Dùng manifest hoặc cấu hình tương đương thay vì để prompt mô tả bằng lời.
• Chuẩn hóa read-only và read-write path từ đầu.

Giai đoạn 3: thêm checkpoint cho long-running run

• Chọn các mốc như sau khi discovery, sau khi plan, sau khi patch, sau khi test.
• Đo tỷ lệ run phải resume để biết checkpoint có đáng tiền hay không.
• Theo dõi thời gian rehydrate và chất lượng run sau khi resume.

Giai đoạn 4: nối sandbox với approval và observability

• Action rủi ro cao phải đòi approval ở ngoài model.
• Ghi lại command, file write, artifact và lý do chặn.
• Nối log sandbox với lớp reliability để thấy nguyên nhân vỡ thật, không chỉ thấy token usage.

Giai đoạn 5: tối ưu theo profile công việc

• Tạo profile nhẹ cho document agent, profile nặng cho coding agent, profile tách biệt cho security review.
• Kết hợp với model routing để chỉ dùng model đắt khi task thực sự cần.
• Đo chi phí theo artifact hữu ích, không chỉ theo số run thành công.

Insight cuối cùng: cuộc đua agent đang chuyển từ “có thêm tool” sang “có runtime sống sót được ngoài demo”

Trong 2025, chúng ta nói nhiều về tool use, MCP và khả năng hành động. Sang 2026, mặt trận bắt đầu dịch xuống thấp hơn, vào chính hạ tầng mà agent dùng để làm việc. Đội ngũ thắng cuộc sẽ không chỉ là đội có model mạnh hơn, mà là đội biết biến môi trường thực thi thành một sản phẩm hạ tầng, không phải một đống glue code tạm bợ.

Đó là lý do agent sandbox đang nóng. Nó không hào nhoáng bằng benchmark mới, nhưng nó giải quyết đúng điểm đau của production: agent có thể làm việc nhiều bước trong một môi trường đủ chuẩn, đủ cô lập và đủ bền để kết quả còn dùng được sau khi demo kết thúc.