当 Agent 写代码快过人类审查：软件工程的信任链必须重建

写代码的产能正在迅速变得廉价，真正稀缺的是可验证的正确性。下一阶段的软件工程，不是让人类追着每一行 AI 代码跑，而是让 Agent 提交证据，并让线上系统持续产生可用于纠错的信号。

01 速度倒挂：写代码不再是瓶颈，建立信任才是

过去，软件团队最昂贵的资源是能把需求变成代码的人。一个功能从讨论到上线，慢在设计、实现和调试，代码审查只是流程中的一道关卡。Agent 改变了这个比例：它可以在几分钟内阅读仓库、生成实现、补齐接口、修改配置，再连续提交多个版本。代码开始像自来水一样涌出，而人的注意力没有同步扩容。于是一个新的速度倒挂出现了——机器负责生产，人类却仍试图用逐行阅读的方式消费。

问题不在于程序员不够认真，而在于这种审查方式已经无法匹配产出规模。要理解一段改动，人需要恢复上下文：需求是什么、旧代码为什么这样写、调用链经过哪里、异常会落到谁身上。Agent 一次修改十几个文件，审查者就要在十几个局部上下文之间反复切换。即使每一行都看过，也不等于真正验证了行为。阅读容易让人获得“我似乎理解了”的感觉，却很难证明并发竞争、脏数据、超时重试和版本兼容真的没有问题。

代码产出越快，逐行审查越容易从质量保障变成排队系统。

更危险的是，当审查队列持续积压，团队通常不会真的降低交付速度，而是悄悄降低审查强度。变更被快速浏览，批准变成一种礼仪；审查者重点检查命名、格式和局部写法，却没有时间重建完整业务模型。流程看起来更严格了，实际却只留下“有人点过同意”的记录。这正是事实上的瓶颈：Agent 已经把实现压缩到小时甚至分钟，人类仍用为低频手工编码设计的制度，去处理高频自动生成的变更。

因此，团队首先要接受一个不太舒服的事实：今后无法依靠阅读全部代码来获得安全感。安全感必须来自可重复的验证证据。人的角色也要随之上移，从检查每块砖是否摆正，转向检查建筑标准、承重测试和验收过程是否可信。源码当然仍有价值，但它不该再是所有变更唯一、同等强度的信任入口。真正需要被审查的，是这次修改声称解决了什么，以及它用什么方式证明自己没有破坏其他东西

02 从审查代码转向审查验证流程

更合理的交付单位，不再是一份代码差异，而是一份“实现加证据”的完整包。Agent 接到任务后，不仅要写功能，还要先列出场景：正常路径是什么，输入边界在哪里，哪些状态不能同时出现，外部依赖失败时系统应该怎样退化。随后由它编写单元测试、集成测试和必要的端到端测试，准备数据夹具，执行测试并提交结果。代码回答“怎么做”，测试和执行记录回答“凭什么相信这样做是对的”。

这时，人类审查的对象就发生了变化。我们不必先钻进每个函数，而是先看场景矩阵是否覆盖了真实风险：空值和极值是否出现，重复请求是否保持幂等，部分成功后能否恢复，权限是否默认拒绝，旧版本数据能否继续读取。然后看断言是否真的验证了结果，而不是只确认“没有抛异常”；看测试是否经过真实边界，而不是把所有依赖都模拟掉；看失败用例是否先失败、修复后才通过。审查这些问题，比纠结一个循环写成哪种形式更接近质量本身。

人类审查验证逻辑与风险边界，Agent 负责高频执行并生产证据。

测试也不能只是 Agent 为自己写的“通关脚本”。如果实现和测试共享同一个错误理解，两者可能一起通过。因此，需求中的关键不变量要由人明确，例如“扣款成功只能发生一次”“任何租户都不能读取其他租户的数据”“迁移失败后旧版本仍可启动”。对于重要功能，可以让另一个独立上下文的 Agent 从攻击者或故障注入视角补充用例，再由人检查两组假设是否独立。关键不是堆积测试数量，而是防止实现逻辑偷偷定义了验收标准。

评审页面最终应该像一份实验报告：需求和风险、场景清单、关键不变量、测试层级、执行环境、失败与通过记录、性能变化、回滚条件一目了然。人类可以快速发现“遗漏了断网恢复”或“这个断言只检查状态码”，而不必先读完数百行实现。只有在证据异常、风险较高或设计值得质疑时，再下钻源码。对权限、资金、安全、数据删除等高风险区域，针对性源码审查仍然必要；但它应由风险触发，而不是无差别覆盖所有自动生成代码。

这意味着测试不再是开发完成后的附件，而是 Agent 的证明责任。没有测试计划的实现是不完整的，没有失败证据的回归测试是不可信的，没有可重复环境的“本地通过”也不能成为发布依据。当团队把这种证据包定义为合并门槛，Agent 的速度才不会变成审查者的债务，而会转化为更密、更快、也更可追溯的验证能力。

03 没有可观测性，就没有真正可托管的线上 Agent

测试能够覆盖已知场景，却永远无法穷举真实世界。线上会出现从未见过的数据组合、罕见的时序、缓慢恶化的依赖，以及只在特定版本和特定租户上触发的问题。如果系统上线后只留下一句“请求失败”，Agent 和人类面对的其实是同一团黑箱。Agent 或许能更快地产生修复建议，但没有事实信号，它只是在更快地猜测。一个无法解释自己发生了什么的系统，也就不可能真正交给 Agent 托管。

完整可观测性不是多装一个日志平台，而是让一次用户行为可以被还原。结构化日志告诉 Agent 当时的输入类别、状态变化和错误原因；指标说明问题是孤例还是趋势，影响了多少请求和多少用户；分布式链路把延迟与失败定位到具体服务和依赖；业务事件则回答技术成功是否真的带来了业务成功。再加上部署版本、配置版本、特性开关和环境信息，Agent 才能把“支付成功率下降”关联到某次发布，而不是在整个仓库里漫无目的地搜索。

可观测性不是展示系统状态，而是为定位、复现和修复提供上下文。

其中最关键的是关联能力。每个请求需要稳定的关联 ID，日志、链路、任务和业务事件都能沿着它串起来；每次发布需要明确版本标签，才能比较发布前后的差异；每个告警要带上时间窗、影响范围和基线，而不只是一个超过阈值的数字。理想情况下，Agent 收到的不是“CPU 高了”，而是“新版本发布十二分钟后，某类请求的尾延迟持续升高，集中在同一依赖调用，并伴随重试次数增加”。后者已经接近一个可验证的故障假设。

可观测性还必须为机器消费而设计。字段要稳定，错误要分类，关键状态要显式记录，SLO 要能通过接口查询；同时，敏感信息必须在采集阶段脱敏，租户边界和访问权限不能因为 Agent 调试而被绕过。告警质量同样重要：持续的噪声会让 Agent 像人一样学会忽略告警。只有当信号具备上下文、可信度和明确所有权，Agent 才能从生产现象生成复现用例，再把猜测变成可以被测试推翻或确认的假设。

因此，可观测性不是上线后的运维附属品，而是 Agent 编程体系的一部分。测试定义系统在预期世界里应该怎样工作，可观测性描述它在真实世界里究竟怎样工作。前者给出合同，后者返回证据。缺少任何一边，自动化修复都只能停留在演示：要么只会处理预先编排的问题，要么面对真实事故时给出无法验证的补丁。

04 建立“测试—上线—观察—修复—回归”的信任闭环

当测试证据和线上信号连接起来，Agent 才不只是一个代码生成器，而是进入了软件的完整生命周期。一次故障发生后，它先读取告警关联的日志、指标和链路，确认影响范围与最近变更；随后在隔离环境中构造最小复现，让问题稳定出现；再补上一条修复前失败的回归测试，修改实现并运行相关测试集。补丁不是因为“看起来合理”而被接受，而是因为它消除了可复现的失败，同时没有破坏既有合同。

通过离线验证后，变更仍不应该直接覆盖全部流量。Agent 可以生成发布计划，标出受影响组件、观察指标、灰度比例、停止条件和回滚动作；人类审核风险边界后放行。系统先在小范围流量中运行，持续比较错误率、尾延迟、资源消耗和关键业务指标。如果信号恶化，自动停止并回滚；如果信号稳定，再逐步扩大。线上结果最终回写到变更记录中，成为这次修复真正完成的证据。

信任来自可重复的闭环：错误被发现、被复现、被修复，也被永久写进回归测试。

这个闭环会让系统越运行越容易维护。每一个真实事故都沉淀为新的测试，每一次误报都推动告警规则改进，每一次回滚都暴露发布门槛的缺口。Agent 擅长执行这种高频、重复、证据密集的工作：整理上下文、尝试假设、运行实验、生成差异和更新文档。人类则把注意力放在机器无法替代的部分：决定什么结果值得追求，哪些风险不可接受，什么时候必须停止，以及谁对最终决定负责。

这也改变了团队衡量工程效率的方式。提交了多少代码将越来越没有意义，更重要的是从异常出现到可靠复现需要多久，从修复产生到获得线上证据需要多久，同类问题是否还会再次发生。一个成熟的 Agent 工作流，不应该以“生成速度快”作为终点，而应该以更短的验证周期、更小的故障半径和更少的重复事故证明价值。速度只有进入约束明确的反馈回路，才会成为生产力。

所以，面对 Agent 生成的代码，我们真正要建立的不是一种人格化的信任。不要期待它永远理解需求，也不要假设测试通过就代表没有遗漏。应该信任的是一套制度：关键行为有可执行合同，变更有可审查证据，发布有渐进门槛，生产有完整信号，故障能够回到测试，风险始终有人负责。人类无需逐行追赶机器的产出，只需牢牢审查这套流程是否覆盖了真正重要的边界。

放心，不是相信 Agent 不会犯错；而是相信错误一定会被看见、被复现、被阻断，并最终变成系统不再重犯的经验。