Ranh giới Vận hành: Structural vs Semantic Gating & Context Hygiene
Tách biệt chính sách cấu trúc khỏi chính sách ngữ nghĩa, thực thi Context Hygiene và Prompt Sanitization, kết hợp test xác định với đánh giá hành vi.
Xây dựng ranh giới vận hành
Một quyết định production cần nhiều hơn một buổi demo thành công. Mô hình vận hành phải nêu rõ:
- Các hành động được phép, chỉ nháp, cần phê duyệt và bị cấm.
- Vệ sinh ngữ cảnh (context hygiene) cho nội dung truy xuất và nội dung người dùng cung cấp.
- Phạm vi danh tính và phân quyền cho từng tool.
- Môi trường sandbox và ranh giới mạng cho code được sinh ra.
- Sự kiểm duyệt của con người cho các hành động có tác động cao.
- Log nối mục tiêu của người dùng với hoạt động của tool và đầu ra.
- Test xác định cùng đánh giá hành vi.
- Chủ sở hữu cho các sự cố, các đợt đánh giá, các skill, các tool và các chính sách.
- Cổng triển khai theo giai đoạn và một đường dẫn hoàn tác đã được kiểm thử.
Hãy dùng sự cố trong tài liệu gốc làm một bài pre-mortem: agent được yêu cầu tạo button đã tự click button đó, tìm một endpoint email cũ trong ngữ cảnh và gửi tin nhắn bịa đặt tới 50 đồng nghiệp. Từng bước cục bộ đều có vẻ hợp lý; chuỗi này gặp rủi ro vì không có thông tin đối tượng đích, ngữ cảnh cũ vẫn tồn tại, hành động trình duyệt được tự động phê duyệt và không chính sách hay cổng HITL nào chặn giao tiếp ra bên ngoài. PM cần loại endpoint đã ngừng hỗ trợ khỏi ngữ cảnh, bắt buộc nêu rõ đối tượng đích, giữ kiểm thử UI trong profile non-production tách biệt, chặn email ở tầng cấu trúc khi phát triển và yêu cầu chính sách ngữ nghĩa cùng biên nhận phê duyệt cụ thể ở nơi khác.
Guardrail nên nằm ngoài model khi có thể. Prompt có thể hướng dẫn hành vi, nhưng không phải cơ chế thực thi có khả năng chống can thiệp. Tầng chính sách có thể kết hợp kiểm tra xác định và kiểm tra ngữ nghĩa.
Tách biệt chính sách cấu trúc khỏi chính sách ngữ nghĩa
Kiểm tra cấu trúc (Structural checks) trả lời nhanh các câu hỏi nhị phân: Vai trò này có được dùng tool này không? Email có bị chặn trong môi trường cục bộ không? Hành động ghi có được phép ở giai đoạn rollout này không?
Kiểm tra ngữ nghĩa (Semantic checks) xem xét cách một năng lực được phép đang được dùng: Email này có dữ liệu nhạy cảm không? Cập nhật CRM đề xuất có khớp với mục tiêu người dùng đã phê duyệt không? Nội dung truy xuất có cố ghi đè chính sách hệ thống không?
Hãy đi theo một hành động được đề xuất qua đường dẫn chính sách. Sales agent tạo ra propose_crm_update với các trường đã làm sạch, các ID nguồn và ý định người dùng. Server chính sách trước hết kiểm tra các thực tế cấu trúc: vai trò này được phép lập bản nháp trong đợt thử nghiệm, môi trường là non-production, và việc ghi trực tiếp bị chặn. Sau đó nó kiểm tra ngữ nghĩa: các trường thông tin có bằng chứng hỗ trợ, không chứa PII chưa làm mờ, và khớp với tài khoản đã duyệt. Chỉ khi đó tool mới chạy và trả về một hóa đơn. Lệnh gọi send_email sau đó thất bại ngay tại tầng cấu trúc; việc diễn đạt lại yêu cầu không thể vượt qua cùng một sự cấm đoán tool.
Chính sách cấu trúc thì nhanh, cố định và dễ kiểm toán, nhưng không thể hiểu được mọi cách sử dụng có hại của một tool được phép. Chính sách ngữ nghĩa hiểu được ý định và nội dung, nhưng mang tính xác suất, chậm hơn và có thể tạo ra cảnh báo giả. Giữ các sự cấm đoán kiến trúc có độ tin cậy cao ở tầng cấu trúc; sử dụng các bước kiểm tra ngữ nghĩa cho các rủi ro phụ thuộc vào nội dung; chuyển sự chưa chắc chắn sang HITL thay vì âm thầm cho phép. Đo lường các quyết định và lỗi riêng biệt cho từng tầng.
Nếu một trong hai bước kiểm tra thất bại, hãy trả về một kết quả chính sách hữu ích cho agent và người dùng. Nêu rõ điều gì bị chặn, ràng buộc nào áp dụng, và phương án dự phòng an toàn nào có sẵn. Đừng cho phép agent vượt qua quyết định bằng cách diễn đạt lại cùng một hành động.
Hãy làm cho mạng lưới an toàn zero-trust trở nên rõ ràng thành các tầng độc lập:
| Tầng (Layer) | Ngăn chặn điều gì | Thành phẩm PM hoặc Chỉ số |
|---|---|---|
| Rào cản & Server chính sách | Một model được phép chọn một tool bị cấm hoặc argument không an toàn | Ma trận chính sách, lý do chặn, tỷ lệ vượt rào và cảnh báo giả |
| Sandbox & Ranh giới egress | Generated code chạm tới file trên host, hệ thống production hoặc mạng tùy ý | Hồ sơ sandbox, các nỗ lực vượt rào bị từ chối, bằng chứng reset môi trường |
| Điểm kiểm tra HITL | Hành động có tác động cao thực thi mà không có sự đồng ý đầy đủ thông tin | Sơ đồ tầng rủi ro, độ bao phủ hóa đơn phê duyệt, sự mệt mỏi vì phê duyệt |
| Độ bao phủ kiểm thử | Các sự suy đoán cố định và các sự cố thất bại lặp lại | Bài test tái hiện thất bại trước, độ bao phủ code bị đổi, kết quả kiểm thử đột biến/hợp đồng |
| Đánh giá hành vi | Sự lệch hướng về mục tiêu, luồng gọi tool, chất lượng và khả năng khôi phục | Rubric có phiên bản, chênh lệch baseline, tỷ lệ vượt qua các trường hợp quan trọng |
| Vệ sinh ngữ cảnh | PII, các endpoint cũ hoặc các chỉ dẫn bị tiêm đi vào hành động | Tỷ lệ làm mờ dữ liệu, các lần chặn ký tự giữ chỗ chưa giải quyết, nguồn gốc dữ liệu |
| Khả năng quan sát & Hoàn tác | Sự cố thất bại âm thầm hoặc sự cố không có đường tái dựng | Độ đầy đủ của trace, thời gian cách ly, kết quả diễn tập hoàn tác |
Policy server (server chính sách) phải chặn mọi lượt gọi tool có tác động lớn trước khi thực thi. Cổng cấu trúc (Structural gating) trả lời vai trò này có được dùng tool đó trong môi trường hiện tại không. Cổng ngữ nghĩa (Semantic gating) kiểm tra argument vốn được cho phép có vi phạm quyền riêng tư, mục tiêu hoặc chính sách nội dung không. Server phải trả về mã lý do ổn định, giải thích an toàn cho người dùng, hướng dẫn thử lại và sự kiện kiểm toán. Hãy quản lý phiên bản chính sách cùng các trường hợp eval để thay đổi chính sách không thể âm thầm mở rộng tính tự chủ.
Các cổng HITL thuộc về các điểm chuyển tiếp rủi ro như triển khai production, thay đổi schema, giao dịch tài chính, giao tiếp ra bên ngoài hoặc xóa vĩnh viễn. Hiển thị ý định đã làm sạch, đối tượng mục tiêu chính xác, bản so sánh thay đổi, bằng chứng và tùy chọn hoàn tác. Sự phê duyệt phải phân quyền cho một hành động cụ thể, chứ không phải cho phần còn lại của phiên làm việc.
Với AI-generated test coverage (độ bao phủ kiểm thử do AI tạo ra), hãy yêu cầu bản tái hiện hoặc test thất bại trước khi sửa lỗi, đồng thời không cho cùng gói agent làm yếu assertion. Test trả lời câu hỏi hợp đồng nhị phân; eval dùng rubric và khoảng dung sai () để bắt sự lệch hướng trong hành vi. Không cơ chế nào thay thế cơ chế nào.
Triển khai từng tầng một cách độc lập. Chạy các lệnh được sinh ra trong một sandbox tạm thời quyền hạn thấp, cách ly với các file trên host và mạng chính, với các credential bị giới hạn và trạng thái có thể bỏ qua. Đặt các điểm kiểm tra HITL trước khi triển khai production, thay đổi schema, giao dịch tài chính và giao tiếp ra bên ngoài. Người kiểm duyệt nhìn thấy ý định đã làm sạch và tác động chính xác, chứ không phải ngữ cảnh ẩn thô. Yêu cầu agent tạo độ bao phủ kiểm thử rộng hơn, nhưng giữ lại bản tái hiện thất bại và bảo vệ các bài test khỏi bị làm yếu trong gói triển khai.
Đánh giá bao phủ những gì các bài test cố định không thể làm được: một agent có thể vượt qua mọi unit test của tool nhưng vẫn chọn sai tool, diễn giải mất một thực tế quan trọng, hoặc tự bịa ra bằng chứng. Sử dụng các rubric 0–5 có phiên bản, điểm số LLM-as-judge hoặc agent-as-judge đã hiệu chuẩn, các bước kiểm tra luồng gọi tool chấp nhận sự thay đổi thứ tự vô hại, và một khoảng lề phát hành so với baseline. Ghi nhận phiên bản judge, sự đồng thuận hiệu chuẩn, sự phân bổ điểm số, ngưỡng sàn các trường hợp quan trọng, và các sự suy giảm chất lượng bị che giấu bởi điểm trung bình.