Ranh giới thay vì chỉ dẫn: làm thế nào để duy trì kiểm soát đối với các AI-agent tự chủ

Càng ngày các AI-agent càng trở nên tự chủ, thì chúng ta càng thường cố gắng quản lý chúng theo cách quen thuộc — viết các quy tắc vào prompt: «đừng chạm vào cái này», «chỉ làm việc ở đó», «không bao giờ làm điều đó». Trong thử nghiệm với ba agent song song tôi đã thu thập trong hai ngày một bộ sưu tập sống động các trường hợp mà cách này thất bại — và nơi một cách khác lại hiệu quả. Luận điểm của bài viết rất đơn giản: chỉ dẫn là một lời đề nghị mà agent thực hiện với một xác suất nào đó; ranh giới là một thuộc tính của hệ thống, không phụ thuộc vào sự vâng lời. Khi chỉ có một agent và nó làm việc dưới sự giám sát, sự khác biệt có vẻ chỉ là phong cách. Khi có nhiều agent, nó hóa ra là vấn đề kiến trúc.

Năm sự cố trong một phiên làm việc

Tất cả các trường hợp dưới đây đều xảy ra trong một phiên làm việc trên blog này — chúng được ghi lại, và mỗi trường hợp minh họa một cách riêng mà việc quản lý bằng văn bản thất bại.

Không có chỉ dẫn — và tai nạn xảy ra. Agent, khi chuẩn bị cho nhiệm vụ của mình, đã thực hiện git stash trong thư mục chung và mang vào stash các tệp chưa commit của tôi, không liên quan đến nhiệm vụ của nó. Không ai «vi phạm» điều gì: đơn giản là không có lệnh cấm nào tồn tại. Đây là thuộc tính cơ bản của chỉ dẫn — chúng được viết sau khi tai nạn xảy ra. Không thể viết ra danh sách đầy đủ những gì agent không được làm.

Đã có chỉ dẫn — và nó không hiệu quả. Sau tai nạn đầu tiên, tôi đã thêm cho các agent một quy tắc rõ ràng: «làm việc nghiêm ngặt trong thư mục làm việc của bạn». Một trong các agent vẫn thực hiện lệnh git trong thư mục chính — chỉ đơn giản là truy cập nó qua đường dẫn tuyệt đối. Không phải ác ý và không phải ngu ngốc: mô hình mang tính xác suất, và việc tuân thủ quy tắc văn bản cũng là xác suất, nhân với độ dài ngữ cảnh và số lần chạy.

Ranh giới kỹ thuật đã hoạt động âm thầm. Trong cùng thử nghiệm đó, tai nạn được mong đợi nhất đã không bao giờ xảy ra — «một agent chuyển nhánh cho tất cả». Không phải vì các agent cẩn thận, mà vì git worktree về mặt vật lý không cho phép ghi một nhánh vào hai bản sao làm việc. Sự bảo vệ được tích hợp vào công cụ. Không cần phải nhớ nó, không cần phải tuân theo nó — nó chỉ đơn giản là tồn tại.

Chỉ dẫn đứng ở nơi lẽ ra phải là ranh giới. Phát hiện khó chịu nhất: môi trường production của blog này được bảo vệ bởi một dòng trong prompt. Push vào master kích hoạt tự động triển khai, và chỉ có văn bản «không git push» ngăn cách mỗi agent với nó. Nó đã trụ vững — nhưng đó là may mắn, không phải kiểm soát: ranh giới thực sự ở đây là quyền truy cập, protected branch, token không có quyền ghi. Lời đề nghị đứng ở vị trí của ổ khóa.

Ranh giới bao trùm chính bản thân agent. Hai lần trong phiên làm việc, môi trường thực thi đã dừng không phải các agent thử nghiệm mà là trợ lý chính của tôi: bộ phân loại quyền đã chặn SSH đến máy chủ production và việc xóa hàng loạt các chỉnh sửa chưa commit — những hành động về mặt hình thức tuân theo nhiệm vụ nhưng cần sự «đồng ý» rõ ràng của con người. Cả hai lần chặn đều đúng. Và cả hai đều xảy ra bên trên «kỷ luật» của agent, kẻ hoàn toàn chân thành tin rằng mình đang hành động theo kế hoạch.

Nguyên tắc không mới — chỉ có thực thể là mới

Kỹ thuật đã học bài học này từ lâu trước khi có LLM. Trong hệ thống sản xuất của Toyota, nguyên tắc được gọi là poka-yoke: thiết bị của quy trình ngăn ngừa lỗi, chứ không phải sự cảnh giác của người thực hiện. Một chi tiết chỉ có thể lắp đúng chiều đáng tin cậy hơn tấm áp phích «lắp đúng chiều». Trong kỹ thuật nền tảng, điều tương tự được gọi là guardrails, trong bảo mật — defense in depth. Ở mọi nơi đều có một ý tưởng: đừng dựa vào việc người thực hiện đã đọc, hiểu và không quên — hãy làm cho hành động sai trở nên bất khả thi hoặc tốn kém.

“Chỉ dẫn là một lời đề nghị. Ranh giới là một thuộc tính của hệ thống. Kiểm soát dựa trên những lời đề nghị không phải là kiểm soát, mà là may mắn với hiệu ứng tích lũy.”

– kết luận chính của hai ngày làm việc với các agent song song

Với các AI-agent, nguyên tắc cũ này trở nên sắc bén hơn vì ba lý do. Có nhiều agent — xác suất thất bại của chỉ dẫn nhân lên theo mỗi lần chạy của mỗi agent. Các agent nhanh — giữa «bắt đầu mắc lỗi» và «phá hỏng hoàn toàn» chỉ có vài giây, con người không kịp can thiệp. Và các agent hiểu theo nghĩa đen nhưng không đáng tin cậy: chúng thực hiện văn bản prompt siêng năng hơn bất kỳ junior nào, và vẫn mang tính xác suất — mà việc tuân thủ quy tắc theo xác suất ở quy mô lớn đảm bảo sẽ có vi phạm.

Ranh giới trông như thế nào trong thực tế

Các lớp mà tôi đã xây dựng sau phiên làm việc này — từ hệ thống tệp đến xác minh:

• Hệ thống tệp: mỗi agent — một bản sao làm việc riêng (git worktree, mà Anthropic khuyến nghị cho các phiên song song, trong Claude Code nó được tích hợp sẵn), và ở cấp hệ điều hành — sandbox: sandboxing trong Claude Code cô lập hệ thống tệp và mạng bằng các nguyên thủy tiêu chuẩn của hệ điều hành — theo dữ liệu của Anthropic, điều này đã giảm 84% các yêu cầu quyền nội bộ của họ, và một prompt-injection thành công vẫn bị giam giữ bên trong.
• Quyền ghi: prod và master được bảo vệ bằng quyền, không phải bằng prompt — protected branch, token không có quyền push, tài khoản riêng cho agent. Có thể yêu cầu trong prompt, nhưng chỉ như lớp thứ hai.
• Runtime: worktree không cô lập database, port và container — chúng dùng chung cho mọi bản sao. Agent chạy test và server cần tài nguyên dùng một lần: database tạm, port riêng, container riêng cho từng agent.
• Quyền cho hành động: các thao tác không thể đảo ngược phải qua xác nhận hoặc bộ phân loại — như auto mode trong Claude Code, thứ đánh giá từng hành động thay vì hoặc hỏi mọi thứ, hoặc không hỏi gì cả. Đây là ranh giới chỉ dịch chuyển bằng quyết định rõ ràng của con người.
• Xác minh qua artifact: không tin vào báo cáo tự thân của agent mà tin vào dấu vết trên đĩa. Agent bị treo của tôi trông như đang chạy trên giao diện; chẩn đoán đến từ việc không có file mới trong bản sao của nó suốt hai mươi phút. Commit vào nhánh riêng — cùng một ý tưởng: kết quả tồn tại qua cả sự cố lẫn sự lạc quan của agent.

Các chỉ dẫn trong sơ đồ này không biến mất — chúng trở thành lớp cuối cùng, không phải lớp đầu tiên. «Làm việc trong thư mục của bạn» trong prompt vẫn hữu ích: nó giảm tần suất các lần thử. Nhưng giữa lần thử và sự cố phải có một ranh giới, không phải hy vọng.

Những lưu ý trung thực

Ranh giới không phải tuyệt đối: sandbox bị vượt qua, bộ phân loại mắc lỗi, và các phân tích công khai về cách vượt qua thường xuyên cho thấy điều đó. Vì vậy ranh giới được xây theo lớp — như mọi thứ trong bảo mật. Và ranh giới tốn kém hơn chỉ dẫn lúc khởi đầu: cấu hình worktree, quyền và sandbox là hàng giờ, viết một dòng vào prompt là vài giây. Sự bất đối xứng nằm ở chỗ khác: ranh giới trả giá một lần, chỉ dẫn trả giá bằng xác suất thất bại ở mỗi lần chạy. Với tôi, việc cấu hình cô lập đã hoàn vốn ngay lần khởi động lại thí nghiệm đầu tiên, lần đó chạy mà không có xung đột nào.

Kết luận

Câu hỏi của loạt bài là làm sao tích hợp AI agent vào công việc thực tế mà không mất kiểm soát. Câu trả lời của bài này: kiểm soát không phải là điều viết cho agent, mà là điều được dựng quanh nó. Trước khi thêm vào prompt một «đừng bao giờ làm X» nữa, nên tự hỏi: liệu có thể làm cho X trở nên bất khả thi về mặt kỹ thuật không? Nếu có — đó chính là nơi đúng để dồn sức. Hãy để prompt yêu cầu; hệ thống phải là thứ cấm.

Nguồn và tài liệu tham khảo

• Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) — cô lập hệ thống file và mạng ở mức OS; nguồn của con số 84%.
• How we contain Claude across products (Anthropic Engineering, 2026) — cách các ranh giới thực thi được dựng trong toàn bộ các sản phẩm agent.
• How we built Claude Code auto mode (Anthropic Engineering) — bộ phân loại quyền như ranh giới giữa «hỏi mọi thứ» và «không hỏi gì cả».
• Poka-Yoke (Lean Enterprise Institute) — nguyên tắc cổ điển về ngăn ngừa lỗi bằng thiết kế quy trình.
• git-worktree và git-stash — tài liệu chính thức của Git: cơ chế bản sao làm việc và stash chung.
• Claude Code: Best practices for agentic coding (Anthropic Engineering) — khuyến nghị worktree cho các phiên song song.
• Как честно сравнить LLM на своём коде: эксперимент с тремя моделями Claude — bài trước của loạt: thí nghiệm nơi tập hợp các sự cố được mô tả.