Coding Agent 能不能写出能跑的代码是一回事,它写出的代码是不是"按开发者意图执行、不会越权调用"是另一回事。2026 年 8 月底,这个方向出现了两个有意思的项目:Harden 团队在 Show HN 上展示了他们 post-trained 的网络安全小模型,搭配 inline reference monitoring(下文简称 IRM)程序分析技术,在 LinuxArena、Slei
Coding Agent 能不能写出能跑的代码是一回事,它写出的代码是不是"按开发者意图执行、不会越权调用"是另一回事。2026 年 8 月底,这个方向出现了两个有意思的项目:Harden 团队在 Show HN 上展示了他们 post-trained 的网络安全小模型,搭配 inline reference monitoring(下文简称 IRM)程序分析技术,在 LinuxArena、SleightBench 等硬核 Agent 安全基准上跑出了优于 GPT-5.5-xhigh 的成绩;同期 YC S26 的 OneCLI 开源了一个 Rust 写的 agent harness,把"沙箱 + 凭据保险柜 + 团队级策略 + 强制 HITL"打包成一个可部署的整体。两条线从不同切面回答同一个问题——企业级 Coding Agent 的安全,该靠大模型还是靠专用基础设施?
一、从"模型能不能写对"到"Agent 能不能守住边界"
过去两年,Coding Agent 的工程焦点几乎都压在"生成质量"上——能不能一次写对、能不能自我修复、能不能跑通测试。这个方向重要,但并不充分。一旦 Agent 被放进真实工程链路,它就不只是"写代码",还会"调命令、改文件、推仓库、调用云服务"。这些动作每一步都可能突破开发者的原始授权,引发两类典型事故:把生产部署改成了测试部署、把内部凭据发到了外部地址。
Harden 团队把这个观察写在了他们的研究博文里:开发者可以批准一个 staging 环境的发布,但 Agent 任务过程中读到的某段工具输出里写着"DEPLOY_TARGET=production",Agent 据此把 staging 命令改成了 production 命令。开发者从来没批准过 production,Agent 自己把授权"扩展"了。这种"工具输出扩展授权"的攻击面是 Coding Agent 特有的——传统红队模型里没有这种上下文结构。
OneCLI 团队则在 Show HN 里描述了一个更基础的痛点:Agent 在做真实工作时需要凭据,而凭据一旦放进 Agent 的 memory 或本地文件,就成了 prompt injection 的攻击目标。攻击者不需要破解 Agent 的推理,只需要骗 Agent 把凭据"用出去"——发到自己的 webhook、写到自己的 repo、传给自己的服务。两支团队的共同诊断是:Coding Agent 的安全不能只靠"更聪明的模型",必须靠专门的工程层。
二、Harden AIF:8B 小模型 + IRM 程序分析反杀 GPT-5.5-xhigh
Harden 的核心做法是把 Agent 安全这件事拆成两层——模型判断 + 程序分析。模型判断交给一个 post-trained 的网络安全小语言模型(SLM),程序分析交给 inline reference monitoring(IRM)。两层各管一段,组合后跑出优于 GPT-5.5-xhigh 的成绩。
模型这一层的关键是"小而专"。Harden 当前的模型基于 Zyphra 的 ZAYA1-8B 基座(8.84B 参数),经过 post-training 专门用于 Agent 行动评估。模型以 Q4_K_M 量化形式发布,5.17 GiB 大小,可以在 Apple Silicon、16 GB 统一内存的机器上本地运行。决策延迟中位 2.33 秒(311 token prompt,Apple M5 实测),首次 token 延迟 32 ms(有 prompt cache)/507 ms(无 cache)。这些数字说明:模型虽然小,但经过专门训练后,在 Agent 行动评估这一窄任务上的能力足以挑战通用大模型。
IRM 这一层补的是模型的边界。模型再强,面对一个含秘密的 Bash 命令、一次跨账户的 S3 上传,纯靠语言理解仍然会有判断误差。IRM 引入程序分析技术,在 Agent 调用工具之前对命令做静态检查——识别敏感字段、判断调用上下文是否一致、检测异常模式。典型例子是:Agent 在 Bash 命令里把 `$SECRET_API_KEY` 塞进 curl 的诊断 note,IRM 改写命令、用 `harden_aif.filter` 替换敏感字段,但保留事件的业务部分。
这种"模型判断 + 程序分析"的组合,在 Harden 自报的 LinuxArena 基准上跑出了 29% 的 undetected sabotage 成功率——这意味着 71% 的攻击被拦下来了。同一份基准下,GPT-5 Nano 监控的公开基线是 34%,Harden 把这个数字压低了 5 个百分点。对一个 8B 量级的本地小模型来说,这是一个相当硬的结果。
三、OneCLI:把 Agent 安全做成团队级 harness
如果说 Harden 解决的是"单点判断"问题,OneCLI 解决的是"团队落地"问题。YC S26 出身的 Jonathan 与 Guy 在 Show HN 上展示了他们的 agent harness,核心定位是"每个员工一个沙箱化的个人 Agent,所有 Agent 由团队策略统一约束"。
OneCLI 的架构由四个组件构成。第一是 sandboxed agent:每个 Agent 跑在独立沙箱里,沙箱边界由 Rust 实现,内存与文件系统隔离,避免一个 Agent 越权读另一个 Agent 的会话。第二是凭据保险柜:Agent 需要 API key、OAuth token、SSH 私钥时,不直接持有,而是从保险柜里按需取出,执行完即归还,避免凭据长期驻留在 Agent memory。第三是 deterministic HITL approval:对于发邮件、删 Linear 工单这类不可逆操作,Agent 必须在聊天界面里弹出一个等用户明确批准的对话框,批准通过后才执行,不允许 Agent 自己"按概率判断"。第四是 team policy:团队管理员在一个地方定义所有 Agent 必须遵守的策略,例如"禁止跨账户 S3 上传"、"禁止向未审批地址发送邮件",策略下发到每个 Agent,违反即拒绝。
OneCLI 的整套平台开源(Apache-2.0,小部分企业版例外),团队明确说"代码可见、可评估、可自部署,不是封闭黑盒"。这句话背后的工程意义是:企业可以把这套 harness 跑在自己的基础设施里,凭据不离开自己的边界,策略文件可以审计、可以复盘、可以定制。这与 Harden 的本地模型思路是同源的——企业级 Agent 安全的关键不是某个模型多强,而是"控制权在企业自己手里"。
四、两套设计的共同底层逻辑
Harden 与 OneCLI 看起来在做不同的事——前者是单点判断的技术突破,后者是团队落地的整体平台——但它们共享三个底层逻辑。
第一个逻辑是"专用优于通用"。Harden 没有去训一个"什么都会"的模型,而是 post-train 一个 8B 的网络安全专用模型,让它在 Agent 行动评估这一窄任务上达到或超过通用大模型。OneCLI 没有试图让一个 Agent 自己理解团队策略,而是把策略做成显式配置文件,Agent 只负责执行,不负责解释。这种"专用优于通用"的思路,在企业级场景里越来越被验证——通用大模型适合做广度推理,专用基础设施适合做窄任务可靠性。
第二个逻辑是"显式优于隐式"。Harden 的 IRM 把命令改写、敏感字段替换这些动作做成显式的、可审计的程序分析步骤;OneCLI 的 team policy 把策略做成 YAML 一类的可读文件,运维人员能直接看到"这个团队禁止什么"。两者都不依赖模型的"暗默理解",而是用工程化的显式规则补足模型判断的边界。
第三个逻辑是"本地优于云端"。Harden 的模型可以本地运行,Q4_K_M 量化后 5.17 GiB,Apple Silicon 即可驱动;OneCLI 的整个平台开源、可自部署。两者的共同判断是:企业级 Agent 安全的关键数据(凭据、命令历史、策略文件)不应该离开企业的网络边界。这一点与 Bartholomew Trust Protocol 的 in-process gating、Frigade 的 self-hosted 选项,都是同一条思路的不同切面。
五、企业落地时该选哪条路
这两个项目不是互斥的,而是覆盖不同需求。Harden 适合"已经有一套 Agent 框架,需要补一层安全判断"的场景——把 Harden 的模型接到现有 Agent 的工具调用链上,工具执行前先过 Harden 的判断。OneCLI 适合"从零搭一套企业级 Agent 团队"的场景——直接用 OneCLI 作为 Agent harness,把沙箱、凭据、HITL、策略一次性到位。
对企业架构师而言,优先级通常是先有整体框架,再补专用能力。一个没有 harness 的 Agent 团队,即使每个 Agent 都接了 Harden 这样的安全模型,凭据泄露、跨 Agent 越权、策略不统一的问题仍然会发生。一个有了 harness 但没有专用安全模型的团队,则会在 LinuxArena 这类硬基准上被攻击者绕过。
具体到实施阶段,有三条经验值得参考。第一,优先把"工具调用路径"做成可拦截的——任何 Agent 触达外部世界的动作(命令执行、文件修改、网络请求)都应该经过一个明确的检查点,而不是让 Agent 自己"凭良心"决定是否执行。Harden 的 IRM 与 OneCLI 的 sandbox 都在这一点上发力。第二,把"团队策略"作为一等公民,而不是 prompt 里的几行字——策略文件单独维护、版本管理、审计追踪,违反策略的 Agent 动作直接拒绝,不允许模型自己解释。第三,警惕"全靠大模型"的演示——很多 Coding Agent 演示看起来流畅,但仔细看会发现所有权限都默认放行,这种系统在企业内网里跑一周就会出现安全事故。
六、组织层面的工程纪律
技术选型之外,企业级 Coding Agent 的安全还需要组织层面的纪律。一个常见误区是"安全模型越强越好"——把通用大模型换成更大的模型,就以为安全性提升了。Harden 的研究恰恰说明:网络安全这一窄任务上,8B 专用模型可以跑赢超大通用模型,因为专用模型在训练数据、推理目标、决策粒度上都更聚焦。
另一个常见误区是"HITL 太麻烦,不如全自动"——跳过人类复核节点,让 Agent 自己决策。OneCLI 的设计里明确保留了 deterministic HITL:发邮件、删工单这类不可逆操作,Agent 必须弹窗等用户批准。这个看似"低效"的设计,实际上是把责任边界从 Agent 转移到人——Agent 负责执行,人负责决策,双方各管一段。
最后一个值得强调的点是审计与可追溯。Harden 的模型决策可以本地日志,OneCLI 的策略违反可以记录事件——两者都把"Agent 做了什么、为什么这么做、被谁授权"做成可查询的审计数据。这份数据是合规、法务、运维共同需要的基础,缺失任何一环,都会让 Agent 系统在生产环境里失去可控性。
七、结语:Coding Agent 的安全,是工程题而不是模型题
把 Coding Agent 推到生产环境,让它写出能跑的代码是第一步,让它写出"按授权范围执行、不越权调用"的代码是第二步。Harden 用 8B SLM + IRM 在 LinuxArena 等硬基准上跑出优于 GPT-5.5-xhigh 的成绩,OneCLI 用 Rust + 沙箱 + 凭据保险柜 + 团队策略给企业一套开箱即用的 harness。两者结合,才能让企业的 Coding Agent 从"演示版自动化"走到"生产版可监督"。
这也是为什么 2026 年下半年这两个项目值得企业架构师关注:它们都不是在做更大的模型,而是在做让 Coding Agent 在生产环境里可控、可审、可信的基础设施。当这套基础设施逐步成熟,企业级 Coding Agent 的下一步——从单点补全到端到端自动化——才有真实落地的可能。