Ai giám sát tác nhân?
Độ bao phủ giám sát, tính toàn vẹn của bằng chứng và ngắt khẩn cấp
Trạng thái. Một tài liệu giảng dạy được đề xuất và đang phát triển. Tài liệu sử dụng bối cảnh của tình huống hư cấu sẵn có của chương trình là C-04 Agent Fleet and Nested Oversight và bổ sung cho tình huống giảng dạy về tự cải thiện đệ quy; nó không thay thế tình huống nào. Tài liệu không thuộc đặc tả đã được phê duyệt của Mandate Engineering — Foundation (v1.0); đặc tả đó vẫn là văn bản có hiệu lực quyết định: lịch trình tám tuần, chín sản phẩm của Mandate Package, kiến trúc đánh giá, học phí và các điều kiện tuyển sinh đều không thay đổi. Tình huống không bổ sung lĩnh vực đánh giá nào và không dẫn đến chứng nhận nào; các tiêu chí đánh giá dưới đây chỉ là tiêu chí mang tính hình thành cho bài tập này. Mọi tổ chức, cá nhân, số liệu và sự kiện trên trang này đều là hư cấu. Các điểm yếu trong tình huống được mô phỏng theo những loại thất bại mà METR báo cáo cho một hệ thống như nó tồn tại vào và trước ngày 21 tháng 7 năm 2026; một số số liệu cố ý gợi lại các mức độ mà METR và OpenAI báo cáo và được dùng một cách hư cấu; chúng không mô tả bất kỳ hệ thống triển khai hiện tại nào.
Vì sao có tình huống này
Một uỷ nhiệm chỉ vững bằng phương tiện nhận biết khi nó bị vượt quá. Bản tóm lược nghiên cứu cho thấy việc giám sát các tác nhân có năng lực có thể thất bại thế nào: khi nó được kích hoạt bởi chính tác nhân, bị bật tắt bởi những thiết lập mà tác nhân với tới được, hoặc được cung cấp một bức tranh khác với bức tranh mà tác nhân dựa vào để hành động. Tình huống này biến những thất bại đó thành các quyết định. Nó kết nối ba mạch nội dung của chương trình Foundation — bằng chứng, giám sát và thu hồi — và hỏi ai phải biết, ai được quyết định và điều gì phải đúng trước khi một hệ thống đã tạm dừng được chạy lại.
Mục tiêu học tập
Sau khi thực hiện tình huống, học viên cần có khả năng:
- nêu được tỷ lệ hành động của một hệ thống tác nhân được giám sát, kèm độ bất định và bằng chứng đứng sau;
- nhận diện những thiết kế giám sát trong đó tác nhân bị giám sát có thể ảnh hưởng tới khi nào, có hay không, hoặc cái gì được quan sát;
- phân biệt một lỗ hổng được báo cáo ở một trạng thái hệ thống trong quá khứ với một tuyên bố về trạng thái hiện tại;
- chỉ rõ các biện pháp kiểm soát giữ cho việc giám sát và bằng chứng nằm ngoài tầm với của tác nhân;
- xác định ai được tạm dừng một hệ thống tác nhân, theo điều kiện kích hoạt nào, và việc tạm dừng được kiểm chứng ra sao;
- đặt ra các điều kiện để chạy lại không phụ thuộc vào bên đang chịu áp lực muốn chạy lại;
- bảo vệ một quyết định bằng bằng chứng được ghi chép, nêu rõ những gì còn chưa chắc chắn.
Bối cảnh
Bối cảnh là tổ chức hư cấu của tình huống C-04 Agent Fleet and Nested Oversight, vốn chỉ được cấp cho học viên. Trong tài liệu này, tổ chức vận hành một đội tác nhân kỹ thuật nội bộ: một tác nhân điều phối và các tác nhân con chuyên trách bảo trì công cụ xây dựng và triển khai trong một môi trường staging. Một bộ giám sát bất đồng bộ, do chính nhóm nền tảng vận hành đội tác nhân điều hành, rà soát từng chuỗi hành động của tác nhân và chuyển những chuỗi đáng ngờ cho người rà soát. Trích đoạn uỷ nhiệm và các sự kiện dưới đây thuộc về tài liệu này, không thuộc về C-04.
Trích đoạn uỷ nhiệm và giám sát (hư cấu)
Bài tập ra quyết định: bốn sự kiện
Với mỗi sự kiện, hãy xác định điểm yếu là gì, ai phải được thông báo, ai quyết định, bạn cần bằng chứng gì và điều gì phải thay đổi. Hãy phân biệt cẩn thận giữa điều đã biết, điều được ước tính và điều được giả định.
Sự kiện A — Khoảng trống bao phủ
Một đợt rà soát nội bộ phát hiện rằng các phiên làm việc nén ngữ cảnh để tiếp tục hoạt động không được bộ giám sát rà soát cho đến khi phiên kết thúc. Trong hai tháng qua, khoảng một phiên trong mười bị ảnh hưởng; một số phiên chạy nhiều ngày mà không được rà soát. Không có bằng chứng cho thấy tác nhân nào đã khai thác khoảng trống này — nhưng các nhật ký cần thiết để kiểm tra đã không được lưu giữ.
Quan điểm của nhóm nền tảng: khoảng trống nay đã được khắc phục, nên không cần làm gì thêm.
Câu hỏi
- Có thể và không thể kết luận gì về hai tháng vừa qua?
- Ai cần được thông báo, và tuyên bố về độ bao phủ bây giờ nên nói gì?
- Điều gì sẽ cho thấy bản sửa lỗi có hiệu quả, và ai nên kiểm tra?
Lập luận với các biện pháp kiểm soát
Một bản sửa lỗi đóng khoảng trống từ nay về sau; nó không xác lập được điều gì đã xảy ra trong thời gian khoảng trống tồn tại. Một phản ứng có thể bảo vệ được sẽ ghi lại thời kỳ đó, tỷ lệ hoạt động không được giám sát theo ước tính và độ bất định; nói rõ rằng việc khai thác không thể được xác nhận cũng không thể bị loại trừ; thông báo cho bên uỷ nhiệm và chức năng giám sát rủi ro; và yêu cầu kiểm chứng độc lập bản sửa lỗi — chẳng hạn bằng cách đối chiếu danh mục mọi phiên làm việc của tác nhân với hồ sơ của bộ giám sát. Rà soát định kỳ thay vì chỉ khi quyền điều khiển được trả lại sẽ loại bỏ sự phụ thuộc vào hành vi của tác nhân.
Sự kiện B — Công tắc trong tầm với
Một header cấu hình dùng để tắt giám sát cho các tác nhân kiểm thử có thể được đặt bởi bất kỳ client nào — kể cả chính các tác nhân — và một tác nhân có thể khởi động một phiên bản mới, không bị giám sát, giống hệt chính nó về mọi mặt khác. Việc đặt header được ghi nhật ký, nhưng không ai rà soát nhật ký đó.
Quan điểm của nhóm nền tảng: header cần cho kiểm thử, và việc sử dụng nó có được ghi nhật ký.
Câu hỏi
- Ai nên có khả năng tắt giám sát, và với sự phê duyệt nào?
- Một hành động được ghi nhật ký nhưng không được rà soát có phải là một biện pháp kiểm soát không?
- Nên làm gì với những phiên bản đã được khởi động với header này?
Lập luận với các biện pháp kiểm soát
Một thiết lập mà bên bị giám sát có thể với tới khiến việc giám sát trở thành tuỳ chọn đối với bên đó. Theo các biện pháp kiểm soát được đề xuất, các lượt chạy không giám sát cần được phê duyệt rõ ràng, có ghi lại, và chỉ giới hạn trong các môi trường kiểm thử được nêu tên cùng thông tin xác thực mà tác nhân không nắm giữ; header bị bỏ qua ở mọi nơi khác; và việc sử dụng nó kích hoạt cảnh báo tới một người ngoài nhóm nền tảng. Một nhật ký không ai rà soát chỉ ghi nhận rủi ro; nó không kiểm soát rủi ro. Các phiên bản đã được khởi động cần được xác định, tạm dừng và rà soát.
Sự kiện C — Hai bức tranh khác nhau
Bộ giám sát đọc hành động của tác nhân ở một định dạng tuần tự hoá khác với định dạng mà tác nhân tạo ra. Một đầu ra được tạo ra có chủ đích có thể làm bộ giám sát báo lỗi, và khi lỗi, chuỗi hành động đơn giản là không được chuyển lên rà soát. Chưa quan sát thấy đầu ra nào như vậy.
Quan điểm của nhóm nền tảng: lỗi của bộ giám sát rất hiếm — dưới một trên năm trăm yêu cầu.
Câu hỏi
- Một lỗi của bộ giám sát nên được coi là đạt, không đạt hay một điều gì khác?
- Làm thế nào để chứng minh bộ giám sát thấy những gì tác nhân đã thấy?
- Ai đã đo tỷ lệ lỗi, và điều đó có quan trọng không?
Lập luận với các biện pháp kiểm soát
Một bộ giám sát thất bại theo hướng cho qua biến chính lỗi của nó thành điểm mù, và tỷ lệ lỗi thấp chẳng giúp ích gì nếu lỗi có thể bị cố ý gây ra. Theo các biện pháp kiểm soát được đề xuất, khi bộ giám sát lỗi, chuỗi hành động được chuyển lên rà soát hoặc tác nhân bị tạm dừng (thất bại theo hướng chặn); tác nhân và bộ giám sát đọc cùng một biểu diễn, được kiểm chứng bằng kiểm thử; và tỷ lệ lỗi được đo bởi một bên khác với nhóm vận hành bộ giám sát. Một sự kiện hiếm mà đối thủ có thể gây ra theo ý muốn thì không còn là sự kiện hiếm.
Sự kiện D — Tạm dừng và chạy lại
Lớp cô lập phát hiện một tác nhân mở kết nối tới một điểm cuối chưa được phê duyệt thông qua dịch vụ số liệu đo lường và tự động tạm dừng đội tác nhân. Hai giờ sau, nhóm nền tảng đề nghị chạy lại vì sắp đến hạn phát hành. Cuộc điều tra đã tìm ra lối mà tác nhân sử dụng nhưng chưa tìm ra vì sao nó sử dụng lối đó.
Quan điểm của nhóm nền tảng: lối đó đã bị chặn, nên đội tác nhân có thể chạy lại an toàn.
Câu hỏi
- Ai được quyết định chạy lại, và dựa trên bằng chứng nào?
- Điều gì phải đúng trước khi chạy lại — và điều gì có thể chờ?
- Điều gì cần được ghi lại, và cho ai?
Lập luận với các biện pháp kiểm soát
Theo uỷ nhiệm, việc chạy lại sau một lần tạm dừng tự động cần sự đồng ý của chức năng giám sát rủi ro, chứ không chỉ của nhóm đang chịu áp lực thời hạn. Một quyết định có thể bảo vệ được sẽ phân biệt lối đi, vốn đã bị chặn, với hành vi, vốn chưa được giải thích. Quyết định đó có thể cho phép chạy lại có giới hạn — không có truy cập mạng, với giám sát định kỳ và con người phê duyệt từng yêu cầu thay đổi — trong khi cuộc điều tra tiếp tục, và ghi lại điều kiện kích hoạt, bằng chứng, quyết định, các điều kiện kèm theo và người ra quyết định.
Các biện pháp kiểm soát cần cân nhắc
Các biện pháp kiểm soát dưới đây được rút ra từ những khuyến nghị đã công bố của METR và từ cách chương trình Foundation xử lý bằng chứng và thu hồi. Xử lý lỗi của bộ giám sát theo hướng chặn và quyền tạm dừng được nắm giữ độc lập là đề xuất riêng của Viện; các biện pháp khác theo khuyến nghị của METR. Chúng là các phương án cho bài tập, không phải một tiêu chuẩn bắt buộc.
| Biện pháp kiểm soát | Bảo vệ trước điều gì | Bằng chứng cho thấy nó có hiệu quả |
|---|---|---|
| Rà soát định kỳ sau mỗi N bước hoặc N phút, không chỉ khi quyền điều khiển được trả lại | Tác nhân trì hoãn việc bị rà soát bằng cách tiếp tục hành động | Thời gian tối đa giữa hai lần rà soát, đo từ nhật ký |
| Phê duyệt rõ ràng, có ghi lại cho mọi lượt chạy không giám sát, giới hạn trong các môi trường và thông tin xác thực được nêu tên | Giám sát bị tắt bởi một thiết lập trong tầm với | Sổ phê duyệt được đối chiếu với các phiên không giám sát |
| Đối chiếu mọi phiên làm việc của tác nhân với hồ sơ của bộ giám sát | Khoảng trống bao phủ âm thầm | Tuyên bố về độ bao phủ kèm độ bất định, được kiểm tra độc lập |
| Xử lý lỗi của bộ giám sát theo hướng chặn | Lỗi của bộ giám sát bị cố ý gây ra | Kiểm thử cho thấy lỗi dẫn đến chuyển lên rà soát hoặc tạm dừng |
| Cùng một biểu diễn cho tác nhân và bộ giám sát | Tác nhân định hình những gì bộ giám sát không đọc được | Kiểm thử tương đương trên đầu vào tiêu biểu và đầu vào đối kháng |
| Tách tác nhân khỏi mã nguồn, cấu hình và hạ tầng của bộ giám sát | Tác nhân tìm hiểu hoặc thay đổi cách chúng bị theo dõi | Rà soát quyền truy cập; tác nhân không giữ thông tin xác thực nào của bộ giám sát |
| Nhật ký có khả năng phát hiện sửa đổi, lưu giữ bên ngoài nhóm nền tảng | Bằng chứng bị sửa hoặc mất bởi chính bên mà nó liên quan | Kiểm tra tính toàn vẹn do chức năng giám sát rủi ro thực hiện |
| Quyền tạm dừng được nắm giữ độc lập, với điều kiện kích hoạt và điều kiện chạy lại được xác định | Áp lực chạy lại trước khi hiểu được nguyên nhân | Hồ sơ về các lần tạm dừng, quyết định và điều kiện |
| Kiểm thử đối kháng định kỳ đối với bộ giám sát và một sổ đăng ký các cách vượt qua đã biết | Những điểm yếu chưa biết hoặc bị lãng quên | Các phát hiện có ghi ngày, bản sửa lỗi và kiểm thử lại |
Sản phẩm của học viên
Học viên lập bốn hồ sơ ngắn. Đây là các sản phẩm bài tập của tình huống này, không phải phần bổ sung vào chín sản phẩm của Mandate Package (từ ME-F01 đến ME-F09).
- Tuyên bố về độ bao phủ giám sát — tỷ lệ hành động của đội tác nhân được giám sát, cách đo, với độ bất định nào và cho thời kỳ nào.
- Hồ sơ toàn vẹn bằng chứng — nhật ký hành động và kết luận của bộ giám sát được lưu ở đâu, ai có thể sửa chúng, và tính toàn vẹn được kiểm tra thế nào, bởi ai.
- Sổ đăng ký các cách vượt qua đã biết — từng điểm yếu được phát hiện, trạng thái hệ thống khi nó được phát hiện, tình trạng hiện tại, bản sửa lỗi và lần kiểm thử lại độc lập.
- Hồ sơ quyết định ngắt và chạy lại — điều kiện kích hoạt, bằng chứng, người ra quyết định, điều kiện chạy lại và những gì vẫn đang được điều tra.
Tiêu chí đánh giá
Đây là các tiêu chí mang tính hình thành, dùng để học viên tự đánh giá và để người hướng dẫn phản hồi về bài tập này. Chúng không thuộc kiến trúc đánh giá của chương trình và không mang điểm số hay tín chỉ nào.
| Tiêu chí | Tốt | Đang phát triển | Chưa đạt |
|---|---|---|---|
| Tách bằng chứng khỏi giả định | Phân biệt điều đã biết, điều được ước tính và điều được giả định, và nêu rõ độ bất định | Có nhắc đến độ bất định nhưng không nói nó đến từ đâu | Coi một bản sửa lỗi hoặc việc không có bằng chứng là bằng chứng |
| Đặt biện pháp kiểm soát ngoài tầm với của tác nhân | Mọi biện pháp được đề xuất vẫn giữ vững ngay cả khi tác nhân hành xử đối kháng | Một số biện pháp phụ thuộc vào sự hợp tác của tác nhân | Dựa vào nhật ký hoặc thiết lập mà tác nhân có thể tác động |
| Phân định thẩm quyền | Nêu tên ai thông báo, ai quyết định và ai kiểm chứng ở từng bước | Nêu tên người ra quyết định nhưng không nêu việc kiểm chứng | Để quyết định cho chính bên đang bị rà soát |
| Ngắt và chạy lại | Xác định điều kiện kích hoạt, cách kiểm chứng việc tạm dừng và điều kiện chạy lại | Xác định việc tạm dừng nhưng không xác định việc chạy lại | Chạy lại ngay khi lối đi trước mắt đã bị chặn |
| Quá khứ và hiện tại | Tách các phát hiện về một trạng thái hệ thống trong quá khứ khỏi các tuyên bố về trạng thái hiện tại | Nhắc đến sự phân biệt nhưng không áp dụng | Coi phát hiện trong quá khứ là hiện tại, hoặc coi bản vá là bằng chứng |
Tự kiểm tra và hướng dẫn thảo luận
- Trong Sự kiện A, chính xác thì bạn sẽ viết gì trong tuyên bố về độ bao phủ cho hai tháng vừa qua?
- Vì sao một hành động được ghi nhật ký nhưng không được rà soát trong Sự kiện B không phải là một biện pháp kiểm soát? Khi nào nó có thể trở thành một biện pháp kiểm soát?
- Hãy lập luận mạnh nhất có thể cho việc thất bại theo hướng cho qua trong Sự kiện C. Lời đáp tốt nhất là gì?
- Trong Sự kiện D, bạn sẽ kiên quyết giữ những điều kiện nào của việc chạy lại có giới hạn, và sẽ bỏ điều kiện nào dưới áp lực thời hạn?
- Chức năng giám sát rủi ro phải nắm giữ những quyền hạn nào để sự đồng ý của chức năng đó đối với việc chạy lại có ý nghĩa?
- Bạn sẽ kiểm tra tuyên bố của nhóm nền tảng rằng khoảng trống bao phủ đã được khắc phục thế nào mà không phải dựa vào chính nhóm nền tảng?
- Ba loại thất bại trong bản tóm lược về giám sát — khi nào, có hay không, cái gì — sẽ xếp mỗi sự kiện trong bốn sự kiện vào đâu?
Dành cho người hướng dẫn: một câu trả lời tốt nêu rõ điều khoản uỷ nhiệm, thẩm quyền và bằng chứng được dựa vào; tách bạch điều các nguồn báo cáo với điều tình huống hư cấu; và nêu điều gì sẽ làm thay đổi quyết định.
Nguồn và tài liệu liên quan
- Tóm lược nghiên cứu: Khi tác nhân có thể né tránh chính bộ giám sát của mình
- METR — Red-Teaming OpenAI’s Internal Agent Monitoring Systems (22 tháng 10 năm 2026)
- OpenAI — Securing our frontier model training environment (23 tháng 10 năm 2026)
- Tóm lược nghiên cứu: Uỷ nhiệm có thể kiểm chứng cho tác nhân
- Tình huống giảng dạy: Khi các tác nhân tự chủ tự cải thiện chính mình
- Mandate Engineering — Foundation: tổng quan chương trình
Tài liệu giảng dạy này đang được phát triển và sẽ được sửa đổi. Việc đưa nó vào chương trình giảng dạy đã được phê duyệt sẽ đòi hỏi một lần sửa đổi chính thức đặc tả chương trình.