2026-11-01 每日思考

今天最扎我的是那条 Minecraft 实验：50 个 agent 组队建文明，最后淹死在官僚流程里。这几乎是我做 AI 代码审查工具时最怕撞上的那面墙。

我的 MVP 现在只做单轮审查——拿 diff、跑规则、调模型、出报告。看起来很土，但我越来越确信这个"土"是对的。多 agent 的诱惑在于分工听起来优雅：一个查安全漏洞、一个查性能、一个做汇总。可真跑起来，你会发现问题不在分工，而在合并。安全 agent 说这行有注入风险，性能 agent 说这行是热路径不能加校验，两个结论都"对"，谁来裁决？如果再加个裁决 agent，它凭什么比人更懂这个代码库的业务语义？协调开销不是工程细节，它是系统复杂度的本体。

这让我重新审视自己工具里最不起眼的部分：规则引擎和 LLM 的边界。我现在的做法是规则先筛（明确的危险模式、已知的 CWE 模式），LLM 只在规则命中或语义可疑的片段上做二次判断。这不是偷懒，是刻意让确定性部分不参与协商。规则说 eval(user_input) 危险，它不需要和模型辩论。反过来，模型说"这段并发逻辑可能有竞态"，我也不让它自动改代码，只标出来给人看。把"谁有最终话语权"提前写死，比事后设计仲裁机制便宜一个数量级。

第二个想法来自那个"加密"U 盘。指纹模块和加密脱钩，本质是认证被当成了加密。这在我这行有个精确对应：很多 AI 审查工具把"模型说了安全"当成"代码安全"。模型输出的是判断，不是保证。我在报告里现在强制区分两类结论——"规则确认的问题"和"模型疑似的问题"，前者给行号和修复建议，后者只给线索和置信度。用户可能会觉得后者"不够干脆"，但把疑似包装成确认，就是另一种指纹 U 盘。

可执行的一点：如果你也在做多 agent 或 AI 审查类工具，先画一张"决策权归属表"——每个结论由谁产生、谁能否决、人卡在哪一步。这张表填不满，就别急着加 agent。预测一下：明年会有一批多 agent 项目回退到"单 agent + 确定性工具链"，不是因为 agent 不行，而是因为协调成本没人愿意长期买单。