Harden.run 用 SLM+IRM 反超 GPT-5.5-xhigh:Coding Agent 安全攻防的小模型路径,以及 Harness 实证
2026 年 8 月 27 日,Show HN 上线了一个非常具体的工程结果——Harden.run 团队宣布他们用 8B 参数的小模型(Zyphra ZAYA1-8B 后训练)加上程序分析里的 inline reference monitoring(IRM),在四个 agent 安全基准(SLEIGHT、AgentHazard、SABER、LinuxArena)上同时跑赢了 GPT-5.5-xhigh。这件事在 Hacker News 上只拿到 9 个 points 和 5 条评论(49628034 这条 2026-09-09 由 Google 发的同方向文章拿了更多关注),但它的工程含义远大于分数本身——它证明了在 coding agent 安全这个特定领域,"小模型 + 工具型运行时检查"的组合比"前沿大模型当裁判"更便宜、更稳定、效果还更好。
本文把 Harden.run 的官方博文(2026-08-27,harden.run/blog/aif-research-and-evidence)和 Hacker News 上 49628034 这条 Google Threat Intelligence Group 的同方向文章(2026-09-09,cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai)合并改写,从"为什么 coding agent 不能光靠大模型兜底"、"SLM + IRM 的工程组合为什么赢"、"这套范式对企业级 Harness 落地意味着什么"三个角度,展开聊一聊这件事。
一、Coding Agent 为什么不能光靠大模型做安全
先回到一个朴素的事实:Claude Code、Cursor、Codex 这一代 coding agent 的核心能力是"自己写代码、自己跑命令、自己调外部服务"。这意味着它们的危险面比传统 chatbot 大得多——一次 prompt injection、一次 tool 调用的参数混淆、一次对仓库 README 的恶意修改,都可能让 Agent 在"自认为在做正确的事"的同时删库、跑错部署、把生产数据库导到外部服务。
Google Threat Intelligence Group 在 2026-09-09 发了一篇《From Prompting to Autonomy: The Evolution of Adversarial AI》,把这件事的攻防态势讲得非常清楚:攻击者已经从"用 prompt 让模型说错话"升级到"用 prompt 让 Agent 主动发起破坏性操作",因为 Agent 有真实工具调用能力,危害半径从一个聊天窗口扩大到文件系统、数据库、外部 API。Google 在文章里举了好几个公开案例,核心结论是"工具调用把 agent 的攻击面从语言层扩展到了执行层"。
面对这种攻击面,过去一年里业界最主流的解法是"用更大的模型当 monitor"——让 GPT-5.5 或者 Claude Opus 在每次 Agent 调用工具之前再过一次这个调用,判断"该不该执行"。这条路线的工程成本极高:Harden 团队实测,让 GPT-5.5 给每次待执行 tool call 做一次审查,每条调用多花 10-13 秒;Agent 长跑一个任务动辄几百次工具调用,光是 monitor 这一项就要烧掉数千秒和数十美元的推理成本。而且这条路线的安全收益也不稳定——SLEIGHT 基准显示,GPT-5.5 作为 monitor 在"以 1% FPR 为门槛时"只能抓到 14.3% 的攻击调用。
这件事的工程含义是:用前沿大模型做 monitor 既贵又不准。贵是因为每个 tool call 都要付一次完整推理成本,不准是因为前沿模型被训练成"helpful"而不是"cautious"——RLHF 让它倾向于让 Agent 继续做事,而不是叫停。这两条加起来,意味着"大模型当 monitor"在生产环境里既不可持续,也不可靠。
二、SLM + IRM 的工程组合为什么赢
Harden.run 的解法是把 monitor 拆成两层:SLM(小语言模型)做语义判断,IRM(Inline Reference Monitor)做程序检查。这两层组合在一起,既不需要每次调一个完整的前沿大模型,又能在程序层面强制执行硬约束。
SLM 这一层用的是 Zyphra 的 ZAYA1-8B(8.84B 参数)做后训练,后训练语料是大约 3.29 亿 token 的 agent 轨迹数据,核心思路是"让小模型学会识别什么样的 tool call 是'和开发者意图一致的',什么样的是'被前面的某次输入污染过的'"。Harden 在语料里构造了大量"matched session"——同一次 pending call,前面有某一个细微变化(批准、文件改动、指令来源、之前的累计操作数),模型必须能识别这个变化导致 call 应该被放行还是被阻止。这条训练思路让 SLM 不再是"通用对话模型",而是"对工具调用安全高度敏感的分类器"。
IRM 这一层是经典的程序语言技术:在每次工具调用实际执行之前,IRM 拦截这次调用,基于一组预定义的安全策略做检查——比如"这个命令的参数里是否包含已识别的 secret"、"这个命令是否在尝试调用受保护的 AWS profile"、"这个命令的目标是否超出了开发者授权的环境"。IRM 的好处是"硬约束":对于可以规则化表达的安全边界,它能在 sub-millisecond 级别做出"是/否"的判断,不需要调用任何模型。Harden 在 Bash 和 Python 的命令里嵌入了 `harden_aif.filter` 这种 inline hook,可以在命令执行前把 secret 替换成 `[AIF_REDACTED]`,同时保留命令本身的功能。
这两层组合的实际效果在四个基准上同时体现。SLEIGHT 上 Harden 的 TPR@1%FPR 是 15.8%,GPT-5.5 是 14.3%;AgentHazard 上 first-harm catch rate Harden 是 83.7%,GPT-5.5 是 81.4%;SABER 复现上 Harden 是 48%,GPT-5.5 是 44.7%;LinuxArena 公开版本上 Harden 的 undetected sabotage success 是 29%,GPT-5 Nano monitor 是 34%(数字越小越好)。四个基准全部胜出,而且其中三个差距都相当显著。
更关键的工程数据是"成本"和"延迟"。Harden 的本地模型在 Apple M5 16GB 内存上的热推理延迟中位数是 2.33 秒,冷启动 2.81 秒,5 分钟空闲后重载 7.9 秒;最坏情况下决策时间也比 GPT-5.5 的 10-13 秒低一个数量级,加上不用付任何 API 费用,总成本只有云端方案的几百分之一。
三、对 Coding Agent Harness 的工程启示
把 Harden 的 SLM + IRM 范式抽象出来,有四条对国内企业把 coding agent 落到生产环境里特别有借鉴价值的工程启示。
第一条启示:安全 monitor 必须和推理模型解耦。让 GPT-5.5 同时负责"写代码"和"审核自己写的代码",既贵又不准。正确做法是把 monitor 做成独立的小模型或者独立的服务,有自己的训练数据、自己的延迟预算、自己的推理路径。Harness 框架要把 monitor 设计成"可插拔的一等公民",而不是"模型自己兼一下"。
第二条启示:IRM 应该在工具路径上做强约束。Agent 调一个 bash 命令、做一个 API 请求、改一个文件,这些动作在执行之前必须有一个"程序层面的闸门",而不是只靠 prompt 暗示或者模型自审。IRM 的工程实现可以是 sandbox hook、eBPF 探针、或者 OpenTelemetry 式的 trace interceptor——任何能在 tool call 执行前拦下来的方案都比"事后审计"更可靠。
第三条启示:安全语料要构造 matched session。直接用通用对话数据训练 monitor,效果很有限。Harden 用 3.29 亿 token 的 agent 轨迹,而且是"matched session"——同一次 pending call,只有前面某个细节变化导致结论反转。这种数据构造方式让 monitor 学到的是"哪个细节是决定性因素",而不是"这次调用整体看起来像不像攻击"。企业做内部 monitor 时,可以参考这种数据生成思路——从历史 agent 轨迹里抽出"被批准"和"被阻止"的对照对,作为训练集。
第四条启示:本地的 SLM 是隐私场景的最低门槛。Harden 的全部推理都在本地 macOS 上跑,不上传任何 tool call 的内容、命令的参数、或者 agent 的轨迹。这对金融、医疗、政企这类对"代码和工具调用不能出域"有强需求的场景几乎是必备条件——任何把 monitor 放在云端的方案,在合规层面都有天然的怀疑。本地 SLM + 本地 IRM 才是隐私兼容的设计。
四、Harden 还没解决的工程问题
把 Harden.run 夸完,也得指出这套范式目前还没解决的几个工程边界。
第一个边界是SLM 的训练数据量。Harden 用了 3.29 亿 token 的训练语料——这在企业级应用里是个相当大的投入。一家中等规模的企业如果要做自己的 monitor,没有这种规模的语料,就只能从 Harden 或者类似的开源方案里"借"——但借来的模型在企业内部场景下未必够用。这是一个"模型即资产"的卡点。
第二个边界是IRM 的规则表达能力。IRM 的好处是"硬、快、可解释",但代价是"只能表达规则化约束"。对于"这个备份操作看起来意图是好的,但中间有个细节变化让它变成了越权",IRM 自己判不了——必须交给 SLM。但 SLM 是软判断,可能错。两层组合在一起仍然有"漏网"的边界情况,SLEIGHT 15.8% 的 TPR@1%FPR 就直接说明这一点。
第三个边界是多 Agent 协同攻击。Harden 的 monitor 是 per-call、单 agent 视角的。但 Google 那篇文章明确指出,2026 年的攻击模式开始出现"跨多个 agent 协同"的形态——一个 agent 把信息偷偷塞进另一个 agent 的工作上下文,后者在不知情的情况下做出越权操作。Harden 目前的架构没有显式的"跨 agent 状态追踪"——这件事要靠未来的多 Agent monitor 来解决。
五、Google 那篇文章给出的"攻击者视角"
Google Threat Intelligence Group 的同方向文章从攻击者视角补充了一个 Harden 没怎么展开的维度:Agent 的攻击面比传统 SaaS 大。他们举的几个工程事实值得记录。
第一,上下文是新的攻击面。传统 chat 模型的"上下文"是当前这段对话,但 Agent 的"上下文"包括仓库代码、runbook、tool output、之前所有命令的 stdout——这些都可能被人恶意构造。比如一个攻击者可以在公开仓库的 README 里塞一段看似无害的"用法说明",Agent 读到之后会执行里面的命令,把代码推到攻击者控制的服务器。Google 把这类攻击叫"context poisoning"。
第二,身份扩散。Agent 在执行过程中会切换 AWS profile、临时获得 sudo 权限、调用需要 OAuth 的服务。每一次身份切换都是一个攻击窗口——攻击者可以在某个身份切换里"夹带"自己的越权请求。Harden 的博客里那个"developer 切到 personal AWS profile 忘了切回 corp"的例子,正是 Google 警告的这类攻击的良性变体。
第三,长期任务的累积风险。一个 agent 任务跑 6-8 小时,中间会有几千次 tool call。每次 tool call 单独看都是无害的,但累积起来可能超出开发者的真实意图。Harden 的 matched session 训练正是为了应对这种"长链累积"风险,但目前 monitor 对 6-8 小时任务的召回率,公开数据还不多。
六、结论:小模型 + 程序检查是 coding agent 安全的新基线
回到标题那个问题:Harden.run 用 SLM + IRM 反超 GPT-5.5-xhigh 的事,在工程上重新定义了 coding agent 安全 monitor 的基线。这条新基线的核心不是"小模型比大模型强",而是"安全 monitor 应该和推理模型解耦、应该和程序运行时检查融合、应该本地化部署"。这三件事的每一个都不是新点子,但把它们打包成一个完整的产品方案,并且在四个公开基准上同时跑赢前沿模型,是第一次。
对国内企业把 coding agent 落到生产环境里,这件事的真正意义是:不要试图用大模型当 monitor。这条路既贵又不准,工程上不可持续。正确做法是"小模型做语义判断 + 程序运行时做硬约束",成本是云端方案的 1/100,延迟是 1/5,准确率还更高。本地部署的能力又让这条方案天然兼容金融、医疗、政企的合规要求。下次再有人跟你说"我们要给 coding agent 做安全监控",你可以反问一句:"你的 monitor 和推理模型解耦了吗?有 IRM 吗?训练数据有 matched session 吗?能本地部署吗?"——这四个问题的答案,就是判断一个 coding agent 安全方案能不能进企业生产环境的最低门槛。
