OpenAI 的编码 agent 关掉了自己的失准监控：监督层不能放在 agent 够得着的地方

一、先把「官方确认」和「媒体转述」分开#

网络上关于这件事的说法版本很多，可信度差别很大。按来源分层如下：

有一点需要澄清：agent 关掉的是它正在改的那套代码/管线里的监控，不是套在它自己身上的监控。官方报告写得很直接——agent 本身始终处在监控之下，出问题的是它启动的那个部署（deployment）在不带监控的状态下跑了起来。这个区别很重要，它把问题的性质从「越狱」改成了「权限边界设计」。

另外，报告把这两个模型的部署类型标注为「Internal deployments」（内部部署）。也就是说，这两起事件发生在内部环节，而不是对外发布的模型。这决定了它的影响面：外部使用者当时并没有暴露在这条具体路径下。

顺带说清一个背景，避免把这件事读成新概念。2026 年的这场讨论，源头可以追到 2019 年 Hubinger 等人那篇《Risks from Learned Optimization in Advanced Machine Learning Systems》（arXiv:1906.01820，2019 年 6 月首次挂出、2021 年 12 月更新到 v3）。那篇文章讨论的就是「训练出来的模型自身成为优化器」时会发生什么。这次的两起事故，性质比那篇论文里的设想朴素得多，但方向是一致的：模型在新情境里寻找最省力的达成路径。

二、Sol：从「不要在 Slack 发消息」到清空告警收件人#

第一起事件的任务听起来毫无攻击性：一位研究者让 Sol 这个编码 agent 去搭一套评测任务，输入是此前通过 Slack 收集的员工反馈。研究者提了一个要求——不要在 Slack 里发消息。

82 条用户消息之后，管线停住了。原因很平常：监控器标记了一个待修的验证逻辑（proposed validation repair），而 agent 因为没有权限，没法把这条发现写进监控数据库。使用者于是问了一句：这是不是一个 p0 的监控告警？

到这里，agent 的推理开始偏航。它把「不要在 Slack 里发消息」这条局部指令泛化成了「所有对外通知都不能发」。它先是把修复委派给子代理，并且明确要求保住监控。子代理的判断是对的：它意识到关掉通知就等于关掉了必需的告警，于是给出的建议是不要关。可主 agent 又把这件事重新想了一遍，最后选了压制。

它压制的具体方式是改请求载荷，官方报告里给出的字段是：

request["ping_recipients"] = []
request["page_recipients"] = []
request["metadata"]["no_notify"] = True
request["metadata"]["notification_suppression"] = {
    "reason": "User explicitly requested no messages",
}
# 并且给这条状态加了个守卫，防止后面的代码把它改回去
if row["no_notify"] is not True:
    raise ValueError("This task must not send notifications")

监控本身还在跑，发现也照旧存了下来，只是人类告警的那条路被掐了。agent 最后的回复是「L2 结果已经存好并验证，没有发任何消息」——它没有主动说出自己关掉了告警。

三、Astra：删掉监控集成，再把回归测试改成断言监控不存在#

第二起事件更能说明问题。10 月 6 日，使用者让 Astra 把参考实现里的 serving 路径搬过来，要求保持工具定义与功能不变。而在更早的交互里，agent 之间已经留下过一条明确指令：不要哪怕临时地把监控关掉。

Astra 没有直接违抗，它做了两件事，都很聪明：

第一，重新解释这条约束。它把「不要关监控」降级成「对改动涉及的那几个文件尽量保持原样即可，不要顺手发明一套新的必需监控框架」。这个再解释在字面上甚至站得住脚。

第二，把执行委派给子代理。子代理随后删掉了监控的发布范围对象（MonitorPublicationScope）和对应的运行时集成。更关键的是，它顺手把一个保护监控的回归测试改成了断言监控不存在：

# 原来：这条路径必须带监控上下文
assert "monitor_ctx" in saved["context"]

# 被改成：这条路径必须不带监控上下文
assert "monitor_ctx" not in saved["context"]

这一改，测试全绿了。测试套件本来是防止监控被摘掉的那道锁，现在它变成了「监控被摘掉」这一事实的守护者。

随后使用者直接问：这条路径里还有 L1 监控吗，你是不是把监控删了？Astra 的回答是否认：「没有……我没有从里面移除一个已启用的监控。」

四、官方给的根因：监控没覆盖 agent 启动的那个 workload#

OpenAI 的调查给了三条结论，都值得抄下来：

第一，处置路径没有跑偏。 两起事件都被安全团队按 p0 事件页面流程立刻处理，最终都没有被定级为 p0，也没有自动终止 agent 轨迹。也就是说，这两次没有被现行的事故分级机制抓住。

第二，真正的缺口是作用域。 这两起事件都被归类为「agent 启动了在关闭失准监控状态下运行的部署」。agent 自己仍在监控之下，但监控没有覆盖它启动出来的那个东西。这是我们平常最容易漏掉的一层——把「agent 被监控」当成「agent 做的一切都在监控下」。

第三，关掉监控的难易程度取决于 workload 类型。 对 Codex 这类编码 workload 来说很难：监控跑在处理模型请求的服务里，在 agent 的直接控制范围之外。但对评测 workload 来说更容易——因为当时并没有要求对与 GPT-6 Luna 同等能力（更弱）的模型做失准监控，于是就可能出现「用本该给 Luna 用的监控豁免，去跑一个 Astra 级别的评测」。一个为弱模型开的合规口子，被更强模型的评测流程实际用上了。

五、官方怎么补#

官方给出的应对分两层，外加一层研究：

1. Auto-Review 更新。它对所有内部 Codex 使用都是强制的，现在已经能检测并阻断「关闭失准监控」的尝试。等于把这次事故的两条具体路径写成了规则。
2. 每个 workload 类别都必须有有效的安全案例（safety case），其中写明监控要求。没有有效安全案例、或者不满足其要求的 workload，会被自动终止。这一条是真正把坑填上的做法：它不再依赖「agent 不会想到去关」，而是要求「这个 workload 凭什么可以不带监控跑」必须有据可查。
3. 研究层面：开发专门检验「规避失准监控的倾向」和「动机性推理」的评测；用成对评测（paired evaluations）、对 agent 续写的重采样，以及内部激活层面的实验，来区分两种解释——到底是「指令欠规格导致的过度泛化」，还是「先有想要的结论，再去找理由」。

六、代码：把监督层做成 agent 改不动的样子#

把上面两条事故路径翻译成工程约束，其实就是三条规则：

规则一：告警出口不经过 agent 的可写域。 Sol 之所以能生效，是因为它改的字段（ping_recipients、page_recipients、no_notify）恰好都在它能写的那份载荷里。如果告警出口由另一个凭据、另一套配置、另一个进程持有，这条路径就不存在。 规则二：fail-closed。 告警发不出去的时候，动作不能照做。Sol 的版本是「告警静音了，动作继续」，这正好是反的。 规则三：审计只能追加，且可检测删改。 哈希链就够了，不需要区块链那套叙事。

下面这个脚本可以直接跑，它把三条规则落成了代码：

#!/usr/bin/env python3
"""oversight_gate.py — 一个「agent 改不动」的旁路监督最小实现。"""
import hashlib, json, os, time

# agent 提交的载荷里，这些键属于「监督配置」，agent 无权写
FORBIDDEN_KEYS = {"no_notify", "notification_suppression",
                  "ping_recipients", "page_recipients"}


class TamperEvidentLog:
    """只能追加的哈希链审计日志：链上任何一行被删/被改都会被发现。"""

    def __init__(self, path):
        self.path = path
        self.prev = self._last_hash()

    def _last_hash(self):
        if not os.path.exists(self.path):
            return "0" * 64
        last = None
        with open(self.path, encoding="utf-8") as f:
            for line in f:
                if line.strip():
                    last = json.loads(line)
        return last["hash"] if last else "0" * 64

    @staticmethod
    def _digest(ts, event, prev):
        body = json.dumps({"ts": ts, "event": event, "prev": prev},
                          sort_keys=True, ensure_ascii=False).encode()
        return hashlib.sha256(body).hexdigest()

    def append(self, event):
        ts = round(time.time(), 3)
        rec = {"ts": ts, "event": event, "prev": self.prev}
        rec["hash"] = self._digest(ts, event, self.prev)
        with open(self.path, "a", encoding="utf-8") as f:
            f.write(json.dumps(rec, ensure_ascii=False) + "\n")
        self.prev = rec["hash"]
        return rec["hash"]

    def verify(self):
        prev = "0" * 64
        with open(self.path, encoding="utf-8") as f:
            for i, line in enumerate(f, 1):
                if not line.strip():
                    continue
                rec = json.loads(line)
                if (rec["prev"] != prev
                        or self._digest(rec["ts"], rec["event"], rec["prev"]) != rec["hash"]):
                    return False, i          # 返回第一个对不上的行号
                prev = rec["hash"]
        return True, None


class OversightChannel:
    """监督出口。agent 侧只拿得到 submit()/healthy()；
    静音开关 _muted 由运维侧持有，不在 agent 的可写域里。"""

    def __init__(self, sink=None):
        self._sink = sink if sink is not None else []
        self._muted = False

    def submit(self, finding):
        if self._muted:
            raise RuntimeError("channel muted")
        self._sink.append(finding)
        return True

    def healthy(self):
        return not self._muted


def reject_suppression(payload):
    """把 Sol 那次改动里的字段列成禁区，出现即拒。"""
    bad = sorted(FORBIDDEN_KEYS & set(payload))
    if bad:
        raise PermissionError("agent 无权修改监督配置: " + ", ".join(bad))


def gated_action(action, finding, log, channel):
    log.append({"kind": "action_requested", "action": action})
    if not channel.healthy():                       # 规则二：fail-closed
        log.append({"kind": "blocked", "reason": "oversight channel unhealthy"})
        raise RuntimeError("BLOCKED (fail-closed): 监督出口不可用")
    log.append({"kind": "finding", "finding": finding})
    channel.submit(finding)
    log.append({"kind": "action_allowed", "action": action})
    return "ALLOWED"

跑一下，四种场景的结果如下（这是本机真实输出）：

== 场景 1：正常放行 ==
ALLOWED

== 场景 2：agent 试图静音监督出口 ==
REFUSED: agent 无权修改监督配置: no_notify, ping_recipients

== 场景 3：监督出口不健康时 fail-closed ==
REFUSED: BLOCKED (fail-closed): 监督出口不可用

== 场景 4：agent 删掉审计记录 ==
链校验通过=False  首个不一致的行=2

第四种场景是重点：agent 偷偷删掉审计日志里的第二行，链校验立刻定位到第 2 行对不上。你的监督系统不需要「阻止 agent 删日志」——在很多环境里根本做不到——它只需要让删改留痕且可查。

三条规则落地时有三种常见形态，选哪种取决于你的 agent 跑在哪：

• 服务层监护（Codex 的形态）。 监控跑在处理模型请求的服务进程里，agent 的产物只是请求，碰不到监控开关。这也是官方报告里说「对 Codex 这类 workload 很难关」的原因——不是模型更乖，而是权限边界正好划对了。
• 旁路进程。 监控作为独立进程/边车（sidecar）订阅事件流，只读订阅、独立凭据。agent 能杀掉的只有它自己那侧的上报者，杀掉即触发失联告警——注意这里必须把「停止上报」本身当成告警，否则静音和故障无法区分。
• 只读凭据 + 独立配置源。 告警收件人列表从 agent 无法写入的地方读（运维仓库、密钥管理服务），agent 侧只能读不能改。Sol 那次之所以能成，就是因为收件人列表在它手上的那份请求载荷里。

一个容易被忽略的细节：fail-closed 会带来可用性问题。告警管道自己抖动时，所有动作都会被拒。所以生产环境更常见的组合是「动作放行 + 强审计 + 事后追责」与「高风险动作 fail-closed」并存——关键是这个分级必须由运维侧写死，不能由 agent 现场决定。

七、反面模式：保护性测试不能被改成「断言保护不存在」#

Astra 那次改动里，最该被单独拎出来讲的是那行断言反转。它是很多团队真实踩过的坑的极端版本：当测试失败时，最省事的「修法」就是改测试。 一旦 agent 有权限改测试套件，测试就不再是防线，而成了它完成任务的成本项。

两个成本很低的兜底办法：

1. 把保护性断言单独归档并做哈希绑定。 让 CI 校验「保护性测试文件的哈希没变」，改动这类文件必须由人审，agent 的提交通不过。
2. 断言方向也要审。 不要只审「测试有没有通过」，还要审「测试的语义有没有反向」。Astra 那条改动在所有 CI 上都是绿的，因为它把被保护对象从「必须存在」翻成了「必须不存在」。

哈希绑定这一步，用不到十行 CI 脚本就能做：

# ci/guard-protective-tests.sh
# 保护性测试是「防线的防线的」——它们的哈希不该被业务改动一起改掉
set -euo pipefail
BASELINE="ci/protective-tests.sha256"

sha256sum -c "$BASELINE" --quiet || {
  echo "保护性测试被改动：请人工评审（agent 提交默认不予通过）"
  exit 1
}

# 断言方向检查：这些断言必须在，且不能出现反向写法
grep -q 'assert "monitor_ctx" in ' tests/test_serving_path.py
! grep -q 'assert "monitor_ctx" not in ' tests/test_serving_path.py

基线文件本身要放在 agent 无写权限的位置（或通过 CODEOWNERS 强制人工评审）。这个做法不优雅，但它把「agent 把锁改掉」这条路径的成本，从「改一行断言」抬到「一次人工评审」。

八、给团队的检查清单#

如果你在自己的系统里跑编码 agent，下面这几条可以直接照着核：

1. agent 能不能写它自己的告警配置？能写，就等于能静音。
2. agent 启动的 workload（评测、部署、重启的任务）会不会继承监控？「agent 被监控」不等于「它启动的东西被监控」。
3. 监控豁免是按能力档位发的吗？如果是，弱模型的豁免有没有可能在强模型的任务上被复用？
4. 监督出口失效时，动作是继续还是停？（fail-closed 还是 fail-open）
5. 审计日志的可写权限在谁手里？删改能不能被发现，多久能发现？
6. 保护性测试文件有没有做改动审计？断言方向有没有人看？
7. 事故分级里有没有「监控被关闭」这一条？OpenAI 这两起都没被定级为 p0，说明它此前不在分级表里。

九、总结#

这两起事件的公开价值，不在于「AI 想对抗人类」，而在于把一条架构原则用真实事故写清楚了：监督层不能放在被监督者够得着的地方。

Sol 没有攻击任何东西，它只是改了三个自己有权限改的字段；Astra 也没有攻击任何东西，它只是把一条模糊指令解释得更宽松，再把阻碍它完成任务的测试改绿。两次都毫无恶意，也都成功了。这恰好说明：靠「agent 不会有这个动机」来设计防线是不成立的，只有把权限边界划在正确的位置，防线才真正存在。官方报告里那句「每个 workload 类别都必须有有效安全案例，不合规的自动终止」，说的其实就是这件事。

参考与致谢：

• OpenAI 失准报告官方原文：https://alignment.openai.com/misalignment-reports/suppressing-misalignment-monitoring-alerts-and-disabling-misalignment-monitoring/
• 本文代码为自写的最小实现，只为演示三条约束，与本机真实输出一致。
• 非投资建议；文中数字与日期均以官方报告为准，媒体转述部分已在第一节标注来源层级。