Code Review 之死：转向Agent-legible Systems

FOGMOE-telegram-bot 是我的一个暑期兴趣项目，fork 自 FOGMOE 的一个相对简单实现。经过两个月的设计和打磨、燃烧了数不尽的 Codex 额度，这个项目已经具备了云 agent 的基本特性：容器化 agent 工作区、新想法的 fmBPF 动态插件系统，以及可靠的运维与部署工具。

项目由 Python 3.14 搭配 C++23 原生实现，立足 Linux 平台，数据服务是 PostgreSQL。根据 cloc，Git 跟踪范围内约 38.36 万行非空行和注释的有效代码，其中生产代码 24.47 万、测试代码 13.89 万，Python 与 C++ 各居其半。而且这些代码有质量保障：生产代码 9,109 个函数，平均圈复杂度约 5，有 456 个长尾的函数超过 15、127 个超过 30；整体一致性极强，贯彻领域驱动设计，用类型系统约束和表达语义与业务逻辑，是典型的良好设计后自顶向下实现。

一个人在两个月内，把一个约 2.8 万行的项目系统性重写并演化成了约 38 万行的工程系统，在几年前并不可能。更何况即使经过了单纯的设计与开发阶段，也要面对运维和部署、Telegram 界面的产品反馈，跨度远非传统后端工程师。

请允许我称呼 coding agents 普及之前的软件工程为传统软件工程，因为在这样一个项目中我们能明显看到完全不同的成本模型：其规模和效率远远超越了某个工程师对某一技术栈的熟练度所能覆盖的范畴。数量如此庞大的代码轻易击穿了人的注意力经济：过去写一个算法和审阅一个算法所耗费的精力尚能是相近的，但 agent 联网参考最佳实践复现一个算法往往只需要数秒。人有限的注意力在整个过程中形成了最大的串行化部分，这是明显的瓶颈转移。

最合乎直觉的做法是延缓 agent 的代码产出，或者直呼“AI slop”一竿子打死，重回古法编程。我认为这种模式和思潮是幼稚的：它并没有切实证明“AI slop”相较于熟练的 senior 有多少的不足，很多工程品味根本没法测，何况你不能说用99%的开支换来1%的表现就一定是“更好的”。在没有 coding agent 之前很多后端工程师为了保交付、赶产出写的代码就不 slop 了吗？况且很多思潮下意识地会拿 AI 的幻觉说事，但我们为什么要预设模型就是神圣的、万能的？一个工程师难道不会犯错吗？可我们为什么能够信任ta的判断？

到底是什么使得代码值得信任？

我认为，代码不是因为作者值得信任而值得信任，而是因为它能够被系统性地验证、反驳和约束，code review 只是在旧成本模型下的一种治理方式：我们相信这套制度可以提升代码质量和共享知识，而工程师所犯的错误少到可以恢复。如果回到正确的关注重心：“如果它是错的，我有没有足够好的机制把它抓出来？”这套制度的要素非常明显：一为准入门槛，二为容错机制。

类型系统、测试、lint、架构检查、CI 都很重要，但它们关注的是我们已经明确建模的风险。真实系统还会受到数据分布、并发、负载、依赖、内核、网络、调度和故障模式影响，所以静态分析、测试和 CI 即使在过去也没有取代 reviewer。因为工程师有一种更高层次的上下文，他们能够想象出自己的系统在运行时是什么样的、什么样的语义和协议需要被遵守。

我们审视当下的 coding agent，强化学习后训练将模型的程序性能力提升到了相当的高度，以至于有人叫嚣“scaling 撞墙”、“密度定律”。这里我无意讨论强化学习后训练在模型采样过程中的实质，也不想深入探讨事实性能力与程序性能力的鸿沟；我想指出，当前工具调用式的 coding agent 所取得的成就实际上有两个先决条件：外部知识可以被工具方便地获取、有可测量的量与反馈机制。

我认为，使用 agent 进行系统性工程的关键在于，让 agent 能够获得单纯静态代码不可见的运行时信息进行推理，而非依赖模型内部知识做它所不擅长的高语境判断。我把这种从设计之初就让运行状态、关键不变量与因果证据能够被 Agent 主动查询、实验和验证的系统，称为 Agent-legible Systems。

云原生的时代 Google SRE 能够成为显学，在于它将运维能力本身纳入系统设计，把可靠性从事后救火变成一种可以被设计、测量、预算和自动化的系统属性。我认为 AI-native 系统设计的关键变在于把 observability 纳入系统设计，不应该在代码写完之后，才想办法让 agent 理解系统，系统从设计之初就应该考虑它将如何被 agent 观察和推理。

我们应当将重心转移到基础设施。比如我们要提供这样一种能力：不是 agent 像工程师读了一遍代码以后说：“这里性能不好”，而是 agent 可以启动一个工具链和工作流得到 profiling 数据，清晰地显示出“这里性能不好”。不是开一堆 subagents review 以后得到多少个 P0、P1，而是 agent 可以很快地启动测试环境并且得到一份详尽的 tracing 和崩溃报告。传统 Code Review 的一个核心价值，是 reviewer 可以凭经验模拟运行时，而我们在设计上让 agent 直接观测运行时：我们提供方便使用的工具来供它获取知识，并且确保信息能够闭环反馈。

我们不需要让这些信息被压缩精炼、用更好的表达方式或者可视化，而是让这些信息能够张成整个空间，因为 agent 的注意力并不值钱。过去事后还原需要大量的推理和枯燥的工具使用，方能灵光一闪注意到问题，现在完全可以交由 agent 去整理发现，把一个启发式的工作转化为数据分析。

这样，人不该也不必把最稀缺的注意力用来检查几千行机械实现，而应该审查领域模型、公开契约、关键不变量、迁移、安全边界和不可逆架构决策。实现细节可以越来越多地交给 Agent，而人的判断力集中到这个系统究竟允许发生什么、绝不能发生什么。同时我认为应当进行敏捷开发，诗性编程、文档优先。所谓文档优先不应当是 Big Design Up Front，是协作时优先沉淀稳定事实：ADR、Schema、迁移、类型化接口、组合根、运行手册，减少“只有某个人脑子里知道为什么”的隐式知识，让人和 Agent 都围绕同一套事实源工作。

回眸历史，因为有了异构系统通信的需求才出现了企业集成总线；又因为过度设计才衍生出了微服务思想；而分布式系统又引入了 SRE。这一次有了 agent，软件生成的传统成本模型被大大颠覆，我们则设计出一套让 Agent 提出假设 → 操纵环境 → 获取运行时证据 → 反驳假设 → 修改系统 → 再验证的闭环，做出 agent-legible systems。毕竟，做架构是站在系统演化的生命周期与枯荣上去思考问题，而这一次我们让 agent 直接感受系统的呼吸和脉搏，参与到演化中去。