让 Agent 改安全漏洞，生产环境还差哪三道闸

让 Agent 在代码库里找漏洞、判断风险、给出补丁，这件事终于从演示视频往工程流程里挪了。

Google 刚发布的 Gemini 4 Carbon 把这条链路的三段都放到了台面上：官方称它在找漏洞的 SEC-bench Pro 上是 88.2%，判断漏洞是否能被利用的 ExploitGym 上是 54.8%，修复根因的 CWE-bench 上是 71.0%。它还在 Artificial Analysis Intelligence Index v5.0 拿到 59 分。数字很好看，但别急着把它翻译成「可以直接接进生产」。这些是官方测试条件下的成绩，不是你仓库里的交付记录。

更值得看的是 Google 自己的动作。Carbon 现在没有面向所有开发者全面开放，而是先给一部分网络安全防御者和受信任伙伴，继续收集反馈、调整防护。模型发布方都把试用门槛卡在这里，团队接到一个更会干活的 Agent 时，反而更该把自己的门槛写清。

数据来源：Google 官方公告。三条柱对应不同任务的不同基准，不能把它们当成同一能力的横向排名，更不能替代你的依赖、权限和 CI 环境中的验证。

这篇不打算把跑分再念一遍。假设你的团队以后拿到了 Carbon，或者已经在用别的编码 Agent 做安全扫描和修复，真正要决定的不是「要不要把模型换成最新的」，而是第一轮试用给它什么权限、什么结果才算合格、谁能说这份证据够了。

我会把这件事拆成三道闸：范围闸、验证闸、证据闸。它们听着不酷，但比在 PR 里多一段「模型已完成修复」有用得多。

第一道：范围闸——先把它放在能回收的地方

安全 Agent 和普通补全工具的差别，不在于它会不会写代码，而在于它要读更多上下文、调用更多工具，还可能主动提出「我已经找到根因，顺手改了这里」。能力越完整，默认权限越不能跟着膨胀。

第一轮试用最好只给一组隔离的、可复现的仓库快照：没有生产密钥，没有真实用户数据，没有能写入主分支的凭据。让 Agent 读取问题描述、依赖锁文件、源码和既有测试；需要运行命令时，限定在一次性的沙箱或短生命周期 runner 里。它可以生成 diff，但不能自行合并、发版或扩展访问范围。

这里要分开看模型能做到什么和它被允许做什么。Google 在公告里把 Carbon 的能力分成找漏洞、验证风险、修复根因三段；落到研发流程里，也应该对应三段不同的授权，而不是拿到一个高分模型就把仓库、CI 和部署权限一次性打包交出去。

可以把首次试用的范围写成一句很朴素的规则：只读输入＋临时执行环境＋可审查的补丁输出。 如果一个任务做不到这三件事，就先不要让 Agent 接手。

具体挑任务时，可以从「已有告警、已有维护者、已有测试入口」的改动开始。例如，依赖扫描指出一个已经有修复版本的组件；Agent 的工作是找出受影响调用、给出升级 diff、补一条围绕实际调用路径的回归测试。它不需要连接生产数据库，也不需要替团队决定版本策略。这样的任务不一定最耀眼，却能让你看见模型在哪一步误读了仓库、在哪一步调用了不该调用的工具。

反过来，有些任务一开始就不适合交给它：跨多个服务的权限设计、包含客户数据的故障排查、需要临时绕过发布规则的线上事故。它们的共同点是，错误的成本远大于一份补丁节省的时间。把这类任务排除在第一轮之外，并不耽误体验模型能力；只是承认权限是产品设计的一部分，不能等到出事再补。

第二道：验证闸——补丁不是答案，能复现的修复才是

安全基准里「修对了」通常有明确的判题器。现实仓库没这么体贴：一个补丁能让当前测试绿，也可能只是绕过了触发条件；一个依赖升级能消掉告警，也可能把兼容性问题留给下个发布窗口。

所以 Agent 给出补丁后，验证顺序不要倒过来。不是先看它写的解释多完整，再决定要不要信；而是先让证据跑起来：原始复现或回归测试是否仍能说明问题、补丁后是否通过、相关单元测试和静态检查是否覆盖了改动、锁文件和依赖版本有没有被它顺手改坏。

下面这份最小检查表，不依赖某一个模型。它适合放在 Agent 任务的完成条件里：

□ 只接受可应用的 diff，不接受“已修复”的自然语言结论
□ 保留触发问题的最小测试或复现步骤；修复后它必须失败转通过
□ 跑受影响模块的测试、静态检查和依赖审计，并保存原始日志
□ 标出无法验证的假设：缺环境、缺凭据、缺复现样本都不能藏进“完成”里
□ 由代码所有者决定是否合并；Agent 只提供候选补丁

这里最容易被跳过的是第三项。长程 Agent 很擅长把任务做得「看上去收尾了」，但工程里真正贵的是回归。Google 也特别强调 Carbon 面向持续、多步骤的工程问题；任务跑得越久，越应该把每一步能不能回滚、验证范围有没有缩窄写成硬条件。

官方还报告 Carbon 在一项间接提示注入基准中取得 0.0% 的攻击成功率。这个结果值得关注，但它描述的是那组被评估的攻击，并不替你的仓库做权限设计。提示注入、第三方文档、Issue 描述、构建日志和工具返回值，一旦混进真实工作流，都会成为模型上下文的一部分。验证闸的作用，就是不让一句看似合理的解释越过可执行的测试。

还有一个容易漏掉的细节：把「发现」和「修改」拆成两次任务。第一轮让 Agent 只输出风险说明、受影响文件和复现建议；经过人工确认后，第二轮才允许它在隔离分支生成补丁。这样即便第一轮把一条构建日志或外部说明理解错了，错也不会直接变成代码改动。对长程任务来说，多一次明确的交接，往往比多给一轮自由探索更划算。

数据来源：Google 官方公告。图中为 Gray Swan 间接提示注入基准的已评估攻击集合，越低越好；它不等价于真实业务链路的零风险。

第三道：证据闸——让下一位审查者能接着判断

安全 Agent 最怕的不是它偶尔答错，而是它做了很多事以后，团队只剩一段漂亮总结，没人知道它读过什么、改了什么、为什么选这条路。

一次可审的任务，至少留下四样东西：输入版本（Issue、仓库 commit、依赖清单）、执行边界（允许的工具和命令）、输出 diff、验证日志。把它们放在同一个任务记录里，审查者才能区分「模型发现了一个问题」「模型猜中了一个问题」和「模型改动已经被测试覆盖」。

这套记录也不是为了给 Agent 增加仪式感。它解决的是一个很现实的交接问题：当补丁在两周后引发回归，或者同一个漏洞再次出现，团队能回到当时的输入、命令和证据，而不是对着聊天记录猜发生了什么。

如果要把它做成 CI 的门禁，规则可以比想象中短：没有 diff、没有可重跑测试、没有任务所有者签收，就只能停在建议，不能进入合并队列。 这也给模型留了一条体面的退路——它可以明确说明缺少什么，而不是为了交卷编一个确定性结论。

所以，现在要不要迁移？

如果你的团队还没有把 Agent 用在安全任务上，Carbon 的消息值得记住，但不构成「今天就迁移」的理由。它尚在分阶段开放，最合适的动作是先把候选任务挑出来：有固定复现、有成熟测试、能在隔离环境中跑完、允许人工审查的漏洞修复或依赖告警，都是更好的起点。没有这些条件的高权限线上任务，先留给人。

如果你已经在用编码 Agent 做这类事，真正值得升级的也许不是模型名，而是任务合同。范围写窄一点，完成条件写硬一点，证据留全一点。模型能力继续变强是大概率事件；让每次能力升级都能安全地进入团队流程，才是更慢、也更值钱的那部分工程。

你们现在让 Agent 处理的最靠近生产环境的一件事是什么？它已经有这三道闸里的哪几道了？

小岛AI