用 Agent 做代码审查：把机器能查的和人该看的分开

代码审查是 agent 很容易做出价值的地方，但前提是分清楚机器该查什么、人该看什么。 先看能力现状。Claude Code 侧有后台运行的审查子 agent，用独立上下文做审查，输出不占用主会话；还有专门的评审系统，会并行派多个 agent 分析改动、验证问题以过滤误报、按严重程度排序。MiMo Desktop 侧可以靠多会话分工，一个会话做实现、一个会话做审查。 机器适合查的： 一，明显的缺陷。空指针、未处理的异常、资源未释放、边界条件遗漏。 二，一致性。命名规范、代码风格、是否遵守了项目的约定。 三，安全隐患。硬编码的密钥、SQL 拼接、不安全的反序列化。 四，测试覆盖。新增逻辑有没有对应的测试。 五，明显的性能问题。循环里的数据库查询、不必要的全量加载。 人该看的： 一，需求理解是否正确。这是机器最弱的一环，它能看出代码有问题，但很难判断"这是不是我们真正要的东西"。 二，取舍是否合理。为什么选这个方案、为什么要这样做权衡，需要业务上下文。 三，可维护性。这段代码半年后别人能不能看懂。 实操建议： 一，把机器审查接进 CI。每次 PR 自动跑，把明显问题拦在人工 review 之前。这一步能省掉大量低价值讨论。 二，审查结果要分级。把误报率高的规则先关掉，否则团队会因为噪声而忽略所有提示。 三，保留人工关口的强制性。至少有一个人的 approve 才能合并，这条不能因为有了 agent 就放松。 一个成本上的参考：专门的评审服务按 token 计费，一次评审的量级在十几到几十美元之间。对于核心仓库值得，对于实验性分支未必划算，按分支策略区分使用。