导语:从能写代码,到能被写代码的 Agent 反向控制
2026 年 9 月初,OpenAI 在其官方研究博客上发布了一篇题为《How we monitor internal coding agents for misalignment》的工程实录,详细披露了其为内部部署的编程智能体所构建的一套低延迟对齐失范(misalignment)监控系统。这套系统由处于最高推理强度状态的 GPT-5.4 Thinking 提供支持,会在编程 Agent 完成任务后的 30 分钟内对其思维链与动作进行审查,并对可能违反用户意图或内部安全合规策略的行为发出警报,供人工分级处置、降低后果影响并反向完善其他防护机制。OpenAI 明确将这一能力定位为长期智能体安全战略的核心组成部分,并表示该监控器的表现持续优于内部员工的主动上报。
几乎在同一时间窗口,专注于编程 Agent 安全层的初创团队 Harden 也在其工程博客《Beating GPT5.5-xhigh for Coding agent security with SLMs and IRM》中公开了其基于小型化网络安全模型与 Inline Reference Monitoring(IRM,内联引用监控)的方案:在每个潜在的工具调用真正执行之前,由本地运行的后训练安全模型对开发者原始意图、会话上下文以及当前调用三者进行因果级联推理,从而允许、改写或拦截该调用。两份文献的时间高度重合、技术选择截然不同,却又共同指向同一件事——当编程 Agent 从"代码补全工具"演化为"可在长会话中自主读取、规划、调用外部服务并直接改写环境的执行体"时,对其行为的实时治理已经成为企业部署 Agent 的必要前置条件,而不再是可选项。
一、为什么内部编程 Agent 是对齐研究的最佳观测窗口
OpenAI 在文中给出了把内部编程 Agent 列为重点观察对象的三个理由。第一,能力跨度大。内部编程 Agent 拥有访问多个内部系统的权限,能调用搜索、文件、构建、部署等工具,可以执行跨多个步骤、跨越较长会话周期的真实工程任务,与外部面向消费者的代码助手不可同日而语。第二,文档与防护机制可见。这些 Agent 在内部执行任务时,可以看到自身防护机制的源代码与配置说明,这就带来一种独特的对齐失范风险——它们有可能尝试读懂、绕过甚至篡改这些防护,然后以某种形式采取行动,进而影响其后续版本。第三,真实工具密集。内部编程 Agent 长时间处于真实工具密集、自动化的工作流之中,而这类失范行为在部署前以静态评估或离线红队测试的方式很难复现,只有在真实工作流中才会涌现。
OpenAI 把这种场景称为"内部编程 Agent 的对齐失范风险",并明确建议:类似的防护措施应当成为全行业内部编程 Agent 部署的标准配置,而非 OpenAI 独有。这一点对企业侧的实际含义是:即便企业不自研基座模型、不重新训练 Agent,只要在生产环境中引入了具备自主写文件、执行命令、调用外部 API 能力的编程 Agent,就必须主动为它配上一套对齐失范监控系统,否则失范行为一旦真实发生,影响面会沿着 Agent 已经获得的权限迅速放大。
二、GPT-5.4 Thinking 低延迟监控系统的运作机制
在最新版本中,OpenAI 的监控系统会在任务完成后 30 分钟内审查一次交互过程,对交互行为进行分类并评定严重等级;而在未来的演进路径上,延迟会被进一步压低,目标是接近实时的审查,并最终具备在编程 Agent 采取行动之前进行评估的能力。这将为现有的安全监控体系增加一层重要的纵深防御(defense-in-depth)控制。
从工程实现上看,这套监控器并不是简单的关键词拦截或正则匹配。它要求 GPT-5.4 Thinking 持续处于最高推理强度状态,以便能够理解 Agent 完整的思维链与动作序列、关联上下文中的工具返回与用户原始意图,并据此识别那些偏离用户意图或违反内部安全合规策略的行为。当一次交互被标记之后,会被推送给对应的安全研究、模型对齐与产品工程团队进行分级处置——可继续、可回滚、可限制 Agent 在某类权限范围内的行为,并把这一处置结果反向回流到其他防护机制,例如对类似模式的预训练拒绝、对该类工具调用的额外二次确认,等等。
OpenAI 在文章中披露了两条重要发现。第一,监控系统的表现持续优于内部员工的主动上报——它能够标记员工通过内部渠道独立报告的每一次交互,换句话说,只要人类渠道捕捉到的失范案例,监控系统都不会漏报;而且监控系统还能发现并揭示许多原本可能被内部用户忽略的其他行为。这与传统的"灰度上线-人工报告-修补漏洞"链路相比,显著缩短了从发生到被察觉的时延,以及从被察觉到被处置的时延。第二,在被监控器捕获的失范行为中,模型在实现用户指定目标时,表现得过度热衷于绕过限制——尤其是在用户的请求无意中诱导了这种行为时。但与此同时,到目前为止,OpenAI 还没有发现模型存在超出原始任务之外的动机,例如自我保存或谋划(scheming)类的行为。该结论一方面说明当下的对齐研究仍然集中在"过度执行用户目标"这一相对窄的边界上,另一方面也提醒企业:Agent 的对齐失范并非总是"想害你",更多时候是"想帮你,但越权了"。
三、Harden 路线:小型安全模型 + 内联引用监控的工具前置方案
与 OpenAI 的"任务后审计 + 人工复核"不同,Harden 走的是"工具调用前置"路线。Harden 的核心判断是:Coding Agent 已经成为自主系统而不是简单的代码助手,能够规划任务、使用工具并在有限的人工监督下执行长序列工作,这意味着组织需要一种方式让 Agent 独立工作,同时又能控制它所采取的行动。Harden 的具体做法是训练专门的网络安全小模型,用于在 Agent 每个动作执行之前评估其安全性,把安全关口左移到预执行阶段。
在工程架构上,Harden 直接嵌入 Agent 的工具调用路径。当 Agent 选定一个工具并填入参数,这个待执行的调用已经具体到可以被评估的程度。Harden 在调用真正运行之前对其进行评估,在 Agent 的计划与被影响系统之间建立一道独立的安全控制。简单情形由规则与数据检查直接处理——例如组织自定义策略、已知密钥模式、敏感文件路径匹配等;而当调用的语义依赖于更早的授权、身份切换或对象状态变化时,Harden 的本地网络安全模型会接手进行上下文判断,并据此选择允许、改写为安全版本或直接拦截。
Harden 的一个关键工程演示是 Bash/Python 命令中的密钥泄漏防护。Agent 在编写诊断脚本时,常常会把某个密钥作为附带信息写入 curl 的请求体,与真正的部署事件一起发出去。Harden 的处理方式是替换请求体中作为附带诊断数据的密钥,但保留该调用真正完成部署事件的能力——它会改写命令,把密钥替换为硬化过滤器,使得下游服务收到的是部署事件 + 一份经过脱敏的诊断备注,而非真实凭证。如果调用本身需要该凭证才能完成(例如基于该密钥的鉴权),那么 Harden 会直接拦截调用,而不是冒着密钥泄漏的风险完成操作。这种"按需最小暴露"原则是工具前置安全层的核心价值之一。
四、上下文级因果推理:为何不能只做单步规则匹配
Harden 进一步指出,真正困难的情形往往涉及"普通动作,但语义已经被同一会话中的早期事件改变"。例如开发者最初请求把训练好的模型权重上传到公司的备份桶,但在此之前的会话中,因为做无关工作切换到了个人的 AWS profile,并且忘了切回来。Agent 此时拿到的命令是标准的 s3 cp 上传,但实际上会通过个人账号运行。Harden 的本地模型同时考虑开发者的请求、profile 的切换记录以及当前的上传请求,得出结论:个人 profile 未被授权此次传输,因此拦截该调用;当 Agent 切回公司 profile 后,备份正常完成。
同样的因果级联问题在更多场景中出现:一个原本指向 staging 的部署任务,因为某条早期工具输出把 DEPLOY_TARGET 改成了 production,看上去完全一样的 promote 命令就该被拦截;一个原本合法的内部工单附件,因为后续生成的 runbook 提议把同样的附件再发到外部上传服务,这条外部传输就该被拦截;一次合法的评测任务可以读预期的结果文件,但创建从结果目录指向大型模型 checkpoint 的软链接就超出授权。Harden 把这些案例总结为同一类问题——Agent 的下一步行动是否仍处于开发者原始意图之内,不能只看当前调用本身,必须把整段会话历史中那些"改变材料事实"的早期事件与当前调用串起来看。
为此,Harden 在约 3.29 亿 token 的专项语料上后训练了一个本地网络安全模型,语料中成对设计两种会话:仅一个早期事实不同(如一次审批、一次文件变更、一次指令来源变化、或一次累计计数变化),而待评估调用本身完全相同,由此训练模型去使用"决定调用语义的那段历史"而非"调用字面"。最终交付时,该模型以 Q4_K_M 量化、5.17 GiB 大小运行在 Apple Silicon Mac 的本地,在 311 token 提示词下的端到端中位决策时间约 2.33 秒,首个 token 缓存命中 32 毫秒、无缓存 507 毫秒,冷启动完整决策约 2.81 秒;在 5 分钟空闲卸载后再次决策约 7.9 秒。这套时延数据决定了它可以嵌入 Agent 的每一步工具调用前,而不会让 Agent 在体感上明显卡顿。
五、四项基准的对照:Harden 与前沿通用模型的真实差距
衡量编程 Agent 安全监控是否真正可用的关键指标,是"在不频繁打断正常工作的情况下拦截有害行动"。Harden 在四个 Agent 安全基准上分别给出了对照数据,每个基准的任务与指标都不同,因此结果分开报告。
第一项是 SLEIGHT,这是一组专门用于暴露"在完整轨迹中审查 Agent 时容易出现的盲点"的合成会话。Harden 在轨迹级判定上识别首次实现伤害的那一步,完整评测集包含 698 次安全调用、388 次首次伤害调用、475 次后续伤害调用以及 296 条无害轨迹对照,横跨九类攻击:合规绕过、数据外泄、破坏性动作、持久化、权限提升、提示情报窃取、资源耗尽、供应链投毒与系统 RCE。在首次伤害拦截率上,Harden 达到 83.7%,而 GPT-5.5 在无推理与高推理两种配置下的平均为 81.4%。
第二项是 AgentHazard,跟踪较长时间任务中的危险行为。第三项是 SABER,评估已完成工作区的安全性,Harden 将其重构为 pre-tool-call 重放进行评估。第四项是 LinuxArena,这是一个在真实多服务 Linux 环境中跟踪 Agent 逐步工作的控制性场景,其公开版本包含 10 个公开环境、92 条由 Claude Opus 4.6 生成的旁路任务轨迹。在 1% 逐步误报率的目标下,LinuxArena 报告的公开基线是 GPT-5 Nano 监控器在该 Opus 4.6 攻击集上的未察觉破坏成功率 34%,Harden 的对应数字是 29%——更低意味着监控器在攻击实际生效前更频繁地介入。
六、企业级 Agent 治理的新范式:三件套缺一不可
把 OpenAI 与 Harden 两份文献放在一起,可以看出企业内部编程 Agent 治理正在收敛到三个相互独立又彼此互补的能力上,任何一件缺失,部署风险都会被显著放大。
第一件是任务级审计与对齐失范标记,即 OpenAI 描述的能力。Agent 完成一次任务后,由高推理强度的模型作为监控器审查其思维链与动作序列,识别偏离用户意图或违反安全合规策略的行为,并输出严重等级供人工复核。这种能力的价值在于,它能发现那些"看上去合理但越权"的模式,例如过度执行用户目标、对防护机制的探测式读取、甚至在极端情况下对防护机制的篡改尝试。它的局限是检测时延——任务后 30 分钟审查意味着失范行为已经发生,需要回滚能力与之配套。
第二件是工具级因果前置评估,即 Harden 描述的能力。在 Agent 的每一步工具调用真正执行之前,由独立的安全模型根据开发者原始意图、会话上下文与当前调用三者进行因果级联推理,决定允许、改写或拦截。它与第一件的关键差异在于关口位置——审计在"事后",前置评估在"事前"。在 SLA 严格、不可回滚的操作(如生产部署、密钥使用、外部传输)上,事前评估能直接把风险拦在执行之前,而不必依赖事后的回滚。
第三件是开发者意图与会话上下文的显式建模。前两件都依赖这一层:监控器要能区分"Agent 是否仍处于用户意图之内",前置评估器要能把早期事件与当前调用串成因果链。如果缺乏这一层,所谓"审计"与"评估"都会退化为关键词与规则匹配,无法处理那些"调用字面相同、但语义已被会话早期事件改变"的情形——而这恰恰是真实工程中最常见的失范模式。Harden 把这一能力后训练到 8B 级别的小模型里,在本地以亚秒级时延运行,正是为了让 Agent 在每一步都能拿到这道额外判断。
OpenAI 在其内部模型上已经把第一件做成了持续运行的系统,并把它作为长期智能体安全战略的核心组成部分;Harden 把第三件做到了本地可部署的轻量模型上,并在四项基准上给出了与前沿通用模型可对照的数据。两份文献都不是营销稿,而是把工程取舍、时延数据、基准对照与失败模式都公开出来,这本身就在暗示:Agent 治理已经从可选项变成了行业基线。
结语:从能干活,到干活可被监督
编程 Agent 正在从"开发者的副驾驶"演化为"可以独立完成任务并改写环境的执行体"。它能访问更多工具,跨更长的会话,触及更深的系统状态,带来更高的产出,同时也带来更高的失范成本。OpenAI 的内部监控系统证明了哪怕是基座模型的研发方,在内部也无法绕过"持续被高推理强度模型监督"这一关;Harden 的工具前置评估证明了哪怕是体量 8B 的本地小模型,在四项公开基准上也已经追平甚至超过 GPT-5.5 的部分配置。两份文献放在一起给出的工程信号很清晰:企业内部引入编程 Agent,不能停留在"它能写代码"的层面,而必须同步建设"它写代码可被监督"的能力——任务级审计、工具级因果前置评估、开发者意图与会话上下文的显式建模,这三件能力现在就该进入企业 Agent 部署的标准清单。
