你的团队在 2024 年拒绝了微服务拆分。当时开了一个两小时的会议，Slack 上的讨论异常激烈，还有一份对比运营成本的电子表格。结论是坚定的：在平台团队交付多区域部署之前，保持单体架构不变。当时在场的每一个人都还记得这件事。
你的编码 Agent 当时并不在场。上周二，它再次提议拆分——语气自信，带着一份干净的迁移计划和一份论据充分的设计文档。再上个周二，另一个 Agent 会话建议提取计费服务。下周，第三个 Agent 会建议用你评估过并两次拒绝的消息中间件来替换你定制的任务队列。就它们所能看到的信息而言，它们都没有错。它们只是看不到决策的价值所在，因为解决这些问题的推理过程存在于已过期的 Slack 线程、未记录的会议以及两名工程师的脑海中，而其中一人已经离职了。
这是 Agent 辅助工程的一种悄然发生的失败模式：已解决的问题正以机器速度被重新审议。而解决办法是大多数团队在十年前归类为“官僚主义、有则更好”的一项实践——架构决策记录（ADR）。
你正在重命名一个函数到一半，文件就在光标下重新加载了。你正在暂存的 diff 不再与工作树匹配。你的开发服务器无故热重载了两次，而十分钟前还通过的测试，现在却在你从未打开过的一个文件中报错了。没有崩溃，没有警告。你和你的编程 Agent 刚才一直在同时编辑同一个工作树，而你发现这一点的方式和大多数团队一样：通过那些莫名其妙的 diff。
数据库在五十年前就解决了这个问题，并给它起了一个名字 —— 并发控制 (concurrency control)。两个操作共享可变状态的写入者要么需要一个锁，一个隔离边界，要么需要一个合并协议，而在这些选项中做出选择是一个具有已知权衡的设计决策。然而，大多数采用编程 Agent 的工程团队从未明确做出这个决定。他们将第二个写入者直接扔进一个单一的工作树中，保留着单写入者世界的习惯，然后将产生的怪象归类为 “AI 不稳定”。这不是不稳定，这是一个竞态条件 (race condition)，而你正是参赛者之一。
团队上午十点开站会。第一位工程师开始汇报他的 Agent 们昨晚完成了什么——只是,早上七点启动的评测套件还没跑完,Agent 凌晨三点开的那个 PR 正在等另一个 Agent 评审、而后者的队列深度无人知晓,长跑的重构 Agent 已经进入第十一个小时(预估是四小时),既没有卡住的信号、也没有健康的信号。昨天的状态既不是"已完成",也不是"进行中"。从会议室里看,昨天的状态根本无从得知。
站会本来是一种为同步人类工作量身定做的同步仪式。每个人做一件事、完成它、睡一觉、第二天早上汇报。工作的最小单位是一个工作日。汇报的最小单位是一个人。节奏匹配的是底层介质。现在这些前提全都不成立了。今天工作的最小单位是一次 Agent 运行,它在你上床前就启动了,可能在会议进行中或会议后三小时收工。汇报的最小单位是一支集群,而不是一个人。而那个节奏——上午十点准时开始、9 到 15 分钟一轮的轮流播报——是底层介质根本不会按这个频率产出事件的节奏。
二十年来，软件工程的瓶颈一直是写代码。我们优化了 IDE、自动补全、重构工具和各种框架，让"打字"变得更便宜。我们赢了。可现在瓶颈往下游挪了一步：写代码很便宜，读代码却很贵。PR 机器人可以并行启动十次实现尝试，在你早上喝完咖啡之前就把十个 Pull Request 砸到你的仓库里。你的审查者做不到这一点。
AI 辅助的软件交付，速率限制器已经不再是模型的每秒 token 数，而是你每天能投入多少双"人眼"去看 diff。当这些眼睛被压垮，系统不会优雅地降级——它会开始盖橡皮图章。代码带着 LGTM 🚀 被合入，没有人真正读过。一名资深工程师批准了一份由 AI 写、又被另一个 AI 工具审查过的补丁，三周后一个数据不一致的 bug 吃掉了某个人四十个小时的人生。表面上的正确不等于系统层面的正确，绿色的流水线不等于"我理解了"。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
