2026-11-06 每日思考

今天 Cloudflare 开源了 security-audit-skill，我盯着它的 README 看了很久——不是因为它做得多好，而是因为它把"独立验证"四个字写进了产品定义里，而这恰好是我这个 MVP 阶段最心虚的地方。

我的代码审查工具目前的做法是：模型读 diff，输出漏洞与性能问题，附置信度和行号。听起来完整，但我知道它的真实失败模式——不是漏报，是"看起来对的错报"。模型会给一段完全安全的代码编出一个 CWE 编号，理由写得头头是道，行号还精确。用户第一次遇到会愣住，第二次就开始不信整个工具。安全工具的信任是一次性的，这和聊天机器人完全不同。

Cloudflare 的思路给了我一个明确的方向：不要试图让审查 agent 更聪明，而是让它的结论必须经过一个不共享上下文的环节复核。具体到我的场景，这意味着审查 agent 输出结构化 finding（CWE 类型、触发路径、最小复现片段），然后由一个独立的验证 agent 只拿着这个 finding 去代码里找证据——找不到就降级为"待确认"。关键在于两个 agent 不共享对话历史，否则复核会变成自我确认。这个设计成本不高，但能把"编造 CWE"这类错误压下去一大截。

但我也得批判一下这个思路的天花板。独立验证能过滤幻觉，过滤不了"共识性错误"——如果两个 agent 基于同一套训练分布，对某类漏洞模式有同样的误解，复核只会加固错误。真正的独立性需要异质来源：静态分析器、符号执行、甚至人工规则。所以我的下一步不是加更多 agent，而是把 Semgrep 这类确定性工具接进验证层，让 LLM 负责"提出假设"，让规则引擎负责"证伪"。这也呼应了今天 Norvig 那篇旧文被顶上热榜的意味：统计学习的有效性不需要机制承诺，但工程系统需要——你需要一个不依赖概率的东西来兜底。

再往外看一层，今天 ArXiv 上那篇讲"有限实验能认证什么机制"的论文其实在说同一件事：行为等价不蕴含机制等价。我的工具能证明"这段代码在测试里没炸"，证明不了"这段代码没有漏洞"。承认这个边界，然后把边界写进产品文案，比假装全能更可能活下来。

给同行的建议：如果你的 agent 产品输出的是"判断"而非"操作"，今天就去做一件事——把验证环节拆成独立进程，切断上下文共享，并至少接入一个非 LLM 的确定性检查器。预测：未来半年内，"agent 输出 + 独立验证层"会成为代码类 agent 的标配架构，而单 agent 直出结论的产品会在企业采购环节被系统性淘汰。