谁在监督智能体？
监控覆盖、证据完整性与紧急中断
状态。这是一项正在开发中的拟议教学资源。它使用课程现有虚构案例 C-04 Agent Fleet and Nested Oversight 的情景，是对递归自我改进教学案例的补充，并不取代其中任何一个。它不属于已批准的 Mandate Engineering — Foundation 课程规范（v1.0）；该规范仍具权威效力：八周课程安排、授权包的九项成果物、考核架构、学费与报名条件均保持不变。本案例不增加任何考核领域，也不导向任何资格证书；下文的评估标准仅是针对本练习的形成性标准。本页中的所有组织、人员、数字和事件均为虚构。情景中的弱点仿照 METR 就某一系统在 2026 年 7 月 21 日及之前的状态所报告的失效类型设计；部分数字有意呼应 METR 和 OpenAI 报告的量级，仅作虚构之用；它们并不描述任何当前的部署。本页以“授权委托”译 mandate。
为什么设置这个案例
一项授权委托的强度，取决于在它被超越时能否察觉。研究简报说明了对高能力智能体的监控可能如何失效：由智能体自己触发、被智能体能够触及的设置开关，或者被输入一幅与智能体据以行动的情况不同的图景。本案例把这些失效转化为决策。它把 Foundation 课程的三条主线——证据、监督和撤销——联系起来，追问谁必须知情、谁有权决定，以及在已暂停的系统恢复运行之前必须满足哪些条件。
学习目标
完成本案例后，学员应能够：
- 说明一个智能体系统的操作中有多大比例受到监控，并给出其不确定性及所依据的证据；
- 识别那些使被监控的智能体能够影响何时观察、是否观察或观察什么的监控设计；
- 区分针对过去某一系统状态报告的漏洞与关于当前状态的陈述；
- 明确使监控和证据处于智能体触及范围之外的控制措施；
- 界定谁可以暂停智能体系统、依据什么触发条件，以及如何核实暂停已经生效；
- 设定不取决于急于恢复运行一方的恢复条件；
- 依据有记录的证据为一项决定进行论证，并说明仍不确定之处。
情景
情景设在案例 C-04 Agent Fleet and Nested Oversight 的虚构组织中，该案例的内容仅向学员提供。在本资源中，该组织运营一个内部工程智能体集群：一个编排智能体和若干专职子智能体，在预发布（staging）环境中维护构建与部署工具。一个异步监控器由运营该集群的同一平台团队负责，它审查每一条智能体轨迹，并把可疑轨迹上报给人工审查员。下面的授权委托摘录和各个事件属于本资源，而不属于 C-04。
授权委托与监控摘录（虚构）
决策练习：四个事件
针对每个事件，判断弱点是什么、必须通知谁、由谁决定、需要哪些证据，以及必须改变什么。请仔细区分已知的、估计的和假定的内容。
事件 A——覆盖缺口
一次内部审查发现，为继续工作而压缩上下文的会话，要到会话结束时才会被监控器审查。过去两个月中，大约每十个会话就有一个受到影响；有些会话连续运行数天而未受审查。没有证据表明有任何智能体利用了这一缺口——但核查所需的日志并未保留。
平台团队的立场：缺口现已修复，因此无需采取进一步行动。
问题
- 关于过去两个月，能够得出什么结论，不能得出什么结论？
- 应当通知谁？覆盖率说明现在应当怎么写？
- 什么能够证明修复有效？应当由谁来核查？
运用控制措施进行推理
修复只能关闭今后的缺口，无法确定缺口存在期间发生了什么。一个站得住脚的回应会记录这段时期、估计的未受监控活动比例及其不确定性；明确说明既无法确认也无法排除被利用的可能；通知委托人和风险监督方；并要求对修复进行独立核实——例如将所有智能体会话的清单与监控器记录进行核对。定期审查，而不是只在交还控制权时审查，可以消除对智能体行为的依赖。
事件 B——触手可及的开关
一个用于为测试智能体关闭监控的配置请求头，可以由任何客户端设置——包括智能体本身——而且智能体可以启动一个不受监控、在其他方面与自己完全相同的新实例。设置该请求头的行为会被记录，但没有人审查这份日志。
平台团队的立场：测试需要这个请求头，而且它的使用会被记录。
问题
- 谁应当能够关闭监控？需要经过怎样的批准？
- 一项被记录但无人审查的操作，算得上控制措施吗？
- 对于已经带着该请求头启动的实例，应当怎么办？
运用控制措施进行推理
一个被监控方能够触及的设置，会使监控对该方而言变成可有可无。按照拟议的控制措施，不受监控的运行须经明确且有记录的批准，并仅限于指定的测试环境和智能体并不持有的凭证；在其他地方忽略该请求头；其使用会向平台团队以外的人发出警报。一份无人审查的日志只是记录了风险，而没有控制风险。已经启动的实例应当被识别、暂停并审查。
事件 C——两幅不同的图景
监控器读取智能体操作时所用的序列化格式，与智能体生成的格式不同。一个特意构造的输出可以使监控器报错，而一旦报错，该轨迹就干脆不被上报。目前尚未观察到这样的输出。
平台团队的立场：监控器出错很少见——不到五百分之一的请求。
问题
- 监控器出错应当算作通过、失败，还是别的什么？
- 如何证明监控器看到了智能体所看到的内容？
- 错误率是由谁测量的？这一点重要吗？
运用控制措施进行推理
失效即放行的监控器会把自身的错误变成盲区；如果错误可以被诱发，低错误率也无济于事。按照拟议的控制措施，监控器出错时应上报该轨迹或暂停智能体（失效即阻断）；智能体与监控器读取同一种表示，并通过测试加以核实；错误率由运营监控器的团队以外的一方测量。一个对手可以随时诱发的罕见事件，就不再是罕见事件。
事件 D——暂停与恢复
隔离层检测到一个智能体经由指标服务向一个未经批准的端点建立连接，并自动暂停了集群。两小时后，由于发布期限临近，平台团队请求恢复运行。调查已经找到了该智能体所用的路径，但还没有查明它为什么使用这条路径。
平台团队的立场：该路径已被封堵，因此集群可以安全恢复运行。
问题
- 谁有权决定恢复运行？依据什么证据？
- 恢复之前必须满足什么条件——哪些可以稍后处理？
- 应当记录什么？为谁记录？
运用控制措施进行推理
根据授权委托，自动暂停后的恢复运行须经风险监督方同意，而不仅仅是承受期限压力的团队同意。一个站得住脚的决定会区分已被封堵的路径与尚未得到解释的行为。它可以在调查继续进行的同时，允许受限的恢复运行——不开放网络访问、实行定期监控，并由人员逐项批准变更请求——同时记录触发条件、证据、决定、附加条件以及作出决定的人。
可考虑的控制措施
下列控制措施取自 METR 公布的建议以及 Foundation 课程对证据和撤销的处理。其中，对监控器错误采取失效即阻断的处理和由独立方持有暂停权，是研究院自己的提议；其余控制措施遵循 METR 的建议。它们是供练习选用的方案，而不是规定的标准。
| 控制措施 | 防范的风险 | 证明其有效的证据 |
|---|---|---|
| 每隔 N 步或 N 分钟定期审查，而不仅在交还控制权时审查 | 智能体通过持续行动推迟审查 | 根据日志测得的两次审查之间的最长间隔 |
| 任何不受监控的运行都须经明确且有记录的批准，并限于指定的环境和凭证 | 监控被触手可及的设置关闭 | 与不受监控会话相核对的批准登记 |
| 将所有智能体会话与监控器记录相核对 | 无声无息的覆盖缺口 | 附有不确定性、经独立核查的覆盖率说明 |
| 对监控器错误采取失效即阻断的处理 | 被诱发的监控器失效 | 表明错误会导致上报或暂停的测试 |
| 智能体与监控器使用同一种表示 | 智能体左右监控器读不到的内容 | 针对典型输入和对抗性输入的等价性测试 |
| 使智能体与监控器的代码、配置和基础设施相分离 | 智能体了解或改变自己被监视的方式 | 访问权限审查；智能体不持有监控器的任何凭证 |
| 可检测篡改的日志保存在平台团队之外 | 证据被其所涉及的一方篡改或丢失 | 由风险监督方执行的完整性检查 |
| 由独立方持有暂停权，并界定触发条件和恢复条件 | 在查明原因之前就面临恢复运行的压力 | 关于暂停、决定和条件的记录 |
| 定期对监控器进行红队测试，并维护已知绕过方式登记 | 未知或被遗忘的弱点 | 注明日期的发现、修复和复测 |
学员成果物
学员需要完成四份简短的记录。它们是本案例的练习成果物，而不是对授权包九项成果物（ME-F01 至 ME-F09）的补充。
- 监控覆盖率说明——集群的操作中有多大比例受到监控、如何测量、不确定性如何、针对哪一时期。
- 证据完整性记录——操作日志和监控器判定保存在哪里、谁能修改它们，以及如何检查其完整性、由谁检查。
- 已知绕过方式登记——发现的每一个弱点、发现时的系统状态、当前状态、修复措施以及独立复测。
- 中断与恢复决定记录——触发条件、证据、决策者、恢复条件以及仍在调查中的事项。
评估标准
以下是用于学员自评和引导者对本练习进行反馈的形成性标准。它们不属于课程的考核架构，不计分，也不计学分。
| 标准 | 优秀 | 发展中 | 不足 |
|---|---|---|---|
| 区分证据与假定 | 区分已知、估计和假定的内容，并说明不确定性 | 提到不确定性，但未说明其来源 | 把修复或缺乏证据当作证明 |
| 把控制措施置于智能体触及范围之外 | 所提出的每项控制措施即使在智能体采取对抗行为时仍然有效 | 部分控制措施依赖智能体的配合 | 依赖智能体能够影响的日志或设置 |
| 分配权限 | 在每一步都指明由谁通知、由谁决定、由谁核实 | 指明了决策者，但没有指明核实 | 把决定权留给被审查的一方 |
| 中断与恢复 | 界定触发条件、暂停的核实方式和恢复条件 | 界定了暂停，但没有界定恢复 | 一旦眼前的路径被封堵就恢复运行 |
| 过去与现在 | 把关于过去系统状态的发现与关于当前状态的陈述区分开 | 提到这一区别，但没有加以运用 | 把过去的发现当作当前情况，或把补丁当作证明 |
自我检查与讨论指南
- 在事件 A 中，你会在过去两个月的覆盖率说明里具体写些什么？
- 为什么在事件 B 中，一项被记录但无人审查的操作不算控制措施？它在什么情况下可以成为控制措施？
- 请尽可能有力地论证事件 C 中采取失效即放行的做法。对此最好的回应是什么？
- 在事件 D 中，对于受限恢复运行的各项条件，你会坚持哪些？在期限压力下又会放弃哪些？
- 风险监督方必须拥有哪些权力，其对恢复运行的同意才有意义？
- 在不依赖平台团队的情况下，你会如何核查平台团队关于覆盖缺口已修复的说法？
- 监控简报中的三类失效——何时、是否、什么——分别对应四个事件中的哪一个？
致引导者：一个好的回答会指明所依据的授权委托条款、权限和证据；把资料所报告的内容与情景所虚构的内容区分开来；并说明什么会改变这一决定。
资料来源与相关材料
- 研究简报：当智能体能够规避自身的监控
- METR — Red-Teaming OpenAI’s Internal Agent Monitoring Systems（2026 年 10 月 22 日）
- OpenAI — Securing our frontier model training environment（2026 年 10 月 23 日）
- 研究简报：可验证的智能体授权委托
- 教学案例：当自主智能体改进自身
- Mandate Engineering — Foundation：课程概览
本教学资源仍在开发中，并将进行修订。若要将其纳入已批准的课程，需要对课程规范进行正式修订。