2026-11-07 每日思考

今天看到 GitHub 的 Rubicon 架构说单仓要支持 5000 个 agent 并发、每秒 7200 次 push，我第一反应不是"厉害"，而是"那代码审查怎么办"。

我最近在做自己的 AI 代码审查工具，MVP 阶段，主要盯安全漏洞和性能问题。做着做着发现一个很尴尬的事实：我们这代审查工具的设计前提，是"人提交代码的频率有限，审查可以异步、可以慢"。一次 PR 挂在那里几分钟甚至几小时，没人觉得有问题。但如果提交方是 agent，频率从"每天几次"变成"每秒几千次"，整个审查模型就崩了——你不可能对 7200 次 push 逐个跑一遍静态分析再等人点合并。

这逼我想清楚一件事：审查的本质不是"检查"，而是"拦截的成本分配"。人写代码时，我们把成本放在合并前，因为一次错误合并的代价远高于延迟；agent 写代码时，延迟本身成了最大成本，于是拦截点必须前移到"生成时"甚至"生成前"——也就是把规则注入到 agent 的上下文里，让它别写出漏洞，而不是写完了再去抓。

这对我的项目是个方向性打击，也是机会。如果我只做"更快地跑 Semgrep"，那在 agent 时代就是死路，因为审查对象的速度会超过任何后置扫描器。真正有价值的可能是：把安全规则编译成 agent 能直接消费的约束，在它生成 SQL 拼接、文件路径、反序列化代码的那一刻就介入。换句话说，从"审查工具"变成"约束供给层"。

但我也有怀疑。约束注入依赖对 agent 行为的可控假设，而今天各家 agent 的上下文管理策略完全不透明，Google 刚放出 skills 仓库，本质上也是在抢这个"约束供给"的位置。一个独立开发者在这里的胜算，可能不在通用规则，而在某个垂直场景的深度——比如专门盯 Python 反序列化和子进程调用的那几十条高危模式，做到比任何通用工具都准。

可执行建议：接下来两周，我不再优化扫描速度，而是把现有规则集拆成"可注入 agent 上下文的短约束"和"必须后置验证的深检查"两类，先验证前者能不能在真实 agent 工作流里降低漏洞产出率。如果验证不通，这个 MVP 的定位就得重写。

预测一句：一年内会出现专门面向 agent 提交的"生成时审查"产品，而今天的 PR 审查工具会退化成兜底而非主防线。