坤霆@全栈技术研究室

上个月，一个技术朋友跟我吐槽。

他的团队花了两周设计了一套重构方案，要把跑了五年的单体应用拆成微服务。架构设计很扎实，领域划分清晰，接口定义规范，甚至连服务间通信方案都做了三版对比。

评审会上，他讲了45分钟，从领域驱动设计讲到CAP定理，从服务网格讲到可观测性。CTO听完，问了一个问题："这个事做了之后，下个季度的大促能少出几次故障？"

他愣了一下，说："理论上会改善。"

CTO说："你们再想想。"

没有然后了。

这不是段子。我见过太多类似的场景，包括我自己。一个技术方案，技术上无懈可击，但就是过不了决策者那关。大部分技术Leader的第一反应是：他不懂技术。但如果你仔细复盘，问题往往不在技术本身。

决策者到底在听什么

技术方案被否，十有八九不是技术有问题，而是呈现方式和决策者真正关心的东西之间有错位。

技术Leader做方案评审，通常的逻辑是：先讲现状有什么问题，再讲对比了几种方案，最后讲为什么选这个。这个逻辑没毛病，但讲着讲着就容易变成技术展览——架构怎么拆、数据怎么迁移、性能数据有多好看。30分钟里25分钟在讲HOW，5分钟讲WHY，而且这个WHY还是技术视角的WHY。

上个月，一个团队的朋友跟我说，他们在内部做了一次 Agent 能力评估。方式是让 Agent 跑 50 个真实的客服场景，然后让人工逐条打分。

结果出来之后，所有人都在争论一个问题：82% 的通过率，到底算好还是不好？

没人能回答。因为"好"没有标准。

这件事让我意识到一个问题：我们在疯狂地往生产环境里塞 Agent，但我们几乎没有一套可靠的方法来评价它到底干得怎么样。传统软件测试的那套方法论——单元测试、集成测试、端到端测试——在 Agent 面前，几乎全部失效。

传统测试为什么失效了

传统测试建立在一个核心假设之上：确定性。给定输入 A，系统必须输出 B。如果输出了 C，那就是 bug。

Agent 天然不满足这个假设。同一个用户问题，Agent 可能走完全不同的推理路径，给出不同的回答——而且两个回答可能都是"对的"。你怎么写断言？你没法写 assertEqual(agent.answer, expected_answer)，因为 expected_answer 本身就不唯一。

这还只是最表面的问题。更深层的麻烦在于：

上周跟一个带前端团队的朋友聊天，他说了一句话让我印象很深："现在最痛苦的不是写代码，是看代码。"

他的团队半年前全面推了 AI 编码助手。效率确实上来了——以前一周的活，现在两天就能干完。但代码审查（Code Review）的压力也跟着翻了三倍。以前每天审查两三百行，现在动辄上千行。审查者的时间没变，代码量却暴增了。

更麻烦的是，AI 生成的代码有一个特点：看着都对，但你不一定知道它为什么这么写。

这不是个案。我最近跟几个做技术管理的朋友聊过，发现一个共同的焦虑——AI 在加速代码生产，但质量把关的那道门，还是靠人肉。这道门正在被冲垮。

审查的瓶颈不是态度，是带宽

过去十几年，代码审查是软件工程里最被推崇的实践之一。它有效的核心前提是：代码作者能解释自己的思路，审查者通过提问和质疑来发现潜在问题。这是一场人与人的对话，有来有回。

AI 生成的代码打破了这个前提。

审查者面对的不再是一个能解释"我为什么这么写"的同事，而是一堆看起来合理但没人能完全解释意图的代码。你问 AI 为什么这么实现，它可以给你一个事后合理化的解释，但那个解释未必反映真实的决策过程——因为它根本没有"决策过程"，它只是在做概率预测。

上个月，一个朋友在群里吐槽：他们的在线文档产品要加多人协作功能，技术负责人评估了一下，给了个方案——用 WebSocket 广播所有编辑操作，冲突了就提示用户"文档已被他人修改，请刷新后重试"。

我问他，你们打算让用户刷新多少次才能写完一段话？

这不是段子。在我见过的技术选型里，"广播 + 冲突提示"仍然是很多团队处理实时协作的第一反应。理由很简单——实现成本低，逻辑好理解。但这条路的尽头，是一个永远填不完的坑。

冲突不是边缘情况

想象一个场景：两个人同时编辑同一份文档的同一行。A 把"用户协议"改成了"服务条款"，B 在同一位置加了个逗号。两个操作几乎同时发生，网络延迟让它们到达服务器的顺序不确定。

传统做法要么让 A 的修改覆盖 B 的（后到的覆盖先到的），要么把文档锁住让 B 等 A 改完。前者丢数据，后者体验差。

CRDT（Conflict-free Replicated Data Type，无冲突复制数据类型）提供了第三条路：从数学上保证，只要操作满足交换律和结合律，无论网络传输顺序如何、延迟多长，所有客户端最终都会收敛到同一份数据。不需要中心服务器仲裁，不需要锁，不需要用户手动解决冲突。每个操作本身就是一个独立的、可传播的、可合并的单元。

从论文到产品的距离

上个月，一个朋友的公司上线了一个 AI 客服助手。上线第一周，用户满意度从 72% 飙升到 89%。所有人都觉得这是一次成功的技术落地。

第二周，满意度掉到了 61%。

没人知道为什么。日志里没有任何报错，API 响应时间正常，模型推理延迟也没变。客服主管说"AI 开始胡说了"，但没人能说清楚它从什么时候开始胡说、为什么胡说、胡说频率有多高。

这不是一个孤例。我最近跟好几个团队聊过，发现一个共同的痛点：AI Agent 跑起来之后，团队对系统的理解能力反而在下降。

传统监控的三个假设，全被 AI 打破了

过去十几年，可观测性领域建立了三大支柱：日志（Logs）、指标（Metrics）、链路追踪（Traces）。这套体系运转得非常好，但它建立在三个隐含假设之上。

第一个假设：系统的行为是确定性的。 给定相同的输入，系统会产生相同的输出。你可以通过阅读代码来理解系统的行为边界。但 AI Agent 不是这样。同样的用户问题，Agent 可能给出完全不同的回答，取决于上下文窗口的状态、之前的对话历史、甚至 prompt 里某个词的微妙变化。代码审计？你审的只是调用框架，真正的决策逻辑在模型的权重里，而那个黑箱你是看不到的。

上个月参加一个架构评审会，有个团队提出要在新加坡加一个机房。理由很充分——东南亚用户访问我们的服务，延迟大概在 250 毫秒左右，体验不够好。加一个区域，理论上能降到 30 毫秒以内。

方案看起来很完美，PPT 里的数据也很漂亮。但我问了一个问题：你们拆解过这 250 毫秒里，有多少是真的花在网络传输上的吗？

没人答得上来。

这件事让我想到一个越来越普遍的现象：很多团队在做多区域部署决策的时候，把"加机房"当成了万能解。延迟高？加机房。用户远？加机房。容灾不够？加机房。但很少有人认真算过，加一个区域的真实成本是什么，以及——有没有更便宜的方案能达到同样的效果。

250 毫秒里，真正的网络传输只占一半

这是很多人不愿意相信的事实：用户感受到的端到端延迟，有接近一半跟地理距离无关。

一个请求从用户手机出发，经过 DNS 解析、TLS 握手、TCP 连接建立，到达服务器后被处理，再把结果返回。这整个链路里，真正受光速限制、必须靠物理距离来解决的，只有网络传播那一段。其他部分——DNS 查询、TLS 协商、连接池等待、服务间调用链、数据库查询、应用层序列化——这些都可以通过架构优化来解决，不需要搬家。

上周参加一个内部技术评审，有人提了一个看起来不太起眼的问题：我们的Agent在执行复杂任务时，数据库连接池经常被打爆，为什么？

排查下来发现原因很直接——Agent在做多步推理时，每一步都可能触发数据库查询。而且它的查询模式完全不符合人类开发者的习惯：没有预编译的SQL模板，没有合理的分页，没有批量查询优化。Agent就像一个不知疲倦的实习生，一条一条地查，一步一步地追，直到把数据拼完整。

这件事让我开始认真想一个问题：当Agent成为数据库的主要使用者，而不是人类开发者时，数据库的设计范式是不是该变了？

传统数据库的隐含假设

过去几十年，数据库的设计和优化都围绕一个核心假设：使用者是人类开发者，通过应用程序发出可预测的查询。

SQL语法是为人类设计的。索引策略是基于已知的查询模式来优化的。连接池的大小是基于人类用户的并发行为来估算的。ORM框架把数据库操作封装成对象方法，本质上也是在替人类开发者降低心智负担。

这整套体系运转得很好——因为人类的行为是可预测的。一个电商系统的商品详情页，99%的情况下会命中那几个固定的查询路径。一个金融产品的持仓页面，查询模式在产品上线那天就已经确定了。

但Agent打破了这个假设。

Agent的访问模式完全不同