990 篇博文 含有标签「insider」

Hadoop 时代的一代人彻底学会了一个教训，以至于它成了一种本能：移动数据是昂贵的，所以要把计算移动到数据所在的地方。每一个 MapReduce 调度器、每一个 HDFS 块放置决策、每一个“数据本地化”（data locality）仪表盘的存在都是为了服务于这一原则。然后，在托管模型 API 的兴起和智能体（agent）热潮之间的某个时刻，我们悄然颠倒了这一原则——而且没有人重新评估这一决策的成本。

看看现代智能体循环（agent loop）实际上在做什么。它从向量数据库中检索一堆文档，从对象存储中提取代码库快照，从六个内部服务中收集工具执行结果，将所有这些内容拼接进一个上下文窗口，然后将整个负载发送到通常位于不同 VPC、不同区域、甚至不同云平台的模型端点。然后在下一轮对话中重复这一过程。周而复始。你的上下文具有质量，而你正在为每一次跳转支付运费。

你的智能体（agent）用上个季度的价格回答了客户的计费问题，复盘报告会将此归咎于模型。但不应该如此。Prompt 组装正确，检索评分很高，模型对所给的所有信息进行了合理的推理——而所给的一切在三天前都是真实的。在 CRM 导出、文档同步和向量索引重建之间的某个环节，“世界的当前状态”悄然变成了“截至周二的世界状态”，而你的技术栈中没有任何环节在衡量这种差异。

数据工程师在几年前就解决了这类问题。一个消费十张上游表的下游仪表板拥有血缘关系（lineage）、新鲜度检查以及一个在夜间任务出错时进行呼叫的轮值机制。你的智能体所消费的上下文窗口也是同样的东西——一个由文档、工单、代码、CRM 和记忆连接而成的物化视图（materialized view）——只不过没有人负责这个连接（join），没有任何东西衡量它的陈旧度，当它提供昨天的真相时，失败却被归类为“模型幻觉”。

Text-to-SQL 演示从不会因为语法而失败。模型生成的 SQL 非常流畅 —— 说实话，比大多数初级分析师写得都好 —— 查询可以运行，并且返回了一个数字。演示在三周后的生产环境中宣告失败，因为 CFO 注意到智能体的 “Q2 营收” 与董事会报告不符。这不是因为 SQL 格式错误，而是因为数据仓库中有三种说得通的营收定义 —— 预订额 (bookings)、已确认营收 (recognized) 和扣除退款后的净值 (net-of-refunds) —— 而模型自信地选择了其中一个。恰恰不是财务部门使用的那一个。

这是最关键的失效模式，而且在你见过的每一个基准测试中都是不可见的。解决方案不是更好的模型或更长的提示词。而是一项大多数数据团队已经构建了一半然后放弃的基础设施：语义层 (semantic layer)。你为 BI 仪表板编写的指标定义 —— dbt metrics、LookML、Cube 定义 —— 事实证明是数据智能体缺失的工具契约。交付可靠智能体的团队意识到，构建顺序与大家的假设恰恰相反：语义层优先，智能体随后。

微调项目的预算会议总是估错了重点。团队估算的是数据流水线、训练运行和评估轮次——一项有着明确终点的一次性投资。随后模型发布，准确率图表节节攀升，然后大家就转向下一个项目了。六个月后，一封邮件寄达：你的适配器（adapter）所绑定的基础模型有了退役日期。你的系统本身没有任何变化，但它的根基全变了。

这是没人算进成本的部分：微调不是一个你已经完成的产品。它是别人代码库的一个分叉（fork），而每一次基础模型的发布都是一次你并未计划的上游变基（rebase）。任何曾在快速更迭的开源项目中维护私有补丁（patches）的人都清楚个中滋味——分叉的创建成本很低，但维护成本极高。

让编程智能体（coding agent）构建一个 React 组件，它第一次尝试就能写出地道的、基于 Hook 的、带有无障碍标注的代码。让同一个智能体使用你公司的内部 ORM —— 那个平台团队维护了六年、拥有出色文档和上百个内部用户的框架 —— 它就会幻觉出不存在的方法，从其他库里发明配置选项，并自信地交付出基于它臆造的 API 编写的代码，而这些代码根本无法通过编译。

这种差异并非源于质量。你的 ORM 可能比模型能完美处理的一半开源库设计得都要好。差异在于训练数据。React 背后有数百万个公开仓库；而你的框架则一个都没有。在自然语言处理（NLP）的术语中，你的内部框架是一种低资源语言（low-resource language） —— NLP 研究人员针对低资源语言记录的每一个后果，现在都适用于你的代码库。

询问大型语言模型现在几点，你得到的回答虽然语气自信，但几乎肯定是不准确的。这并非因为模型坏了，而是因为它的内部没有时钟。Transformer 是一种无状态的文本补全引擎：它将 token 映射到 token。在整个流水线中，没有任何地方会接收到“现在是 14:32 UTC”这样的信号。模型感知不到当前时刻 —— 这是你必须在每一轮对话中主动提供给它的东西，否则它就会从陈旧的训练数据中臆造一个时间。

这种无声的失败往往在最糟糕的时刻浮出面。你的智能体认为现在是星期一，因为会话是在星期一开启的，于是它在星期二、星期三依然坚信这一点，直到它为一个已经过去的日子设定了“明天早上”的提醒。它利用数小时前就已冻结的 now 来分析“过去 24 小时”的日志。它在转换跨时区的会议时间时，因为误判了夏令时的边界而导致一小时的偏差。这些在传统意义上都不像是“幻觉”。其输出流畅、合理且逻辑自洽，只是它锚定在了一个不再存在的时刻。

打开你多智能体系统的架构图。然后再打开你的组织架构图。如果你眯起眼睛看，它们其实是同一张图。“研究智能体”对应着负责搜索的团队。“账单智能体”的硬边界恰恰就在财务部门停止与产品部门沟通的地方。那个将工作分发给五位专家的编排器，看起来极其像是一个带着五名直属下属的工程经理。你并非有意如此设计。是康威定律（Conway's Law）为你做了决定。

Melvin Conway 在 1967 年的观察是：任何系统设计都会反映出设计该系统的组织的沟通结构。六十年来，这始终是一个关于微服务和单体架构的故事。但智能体集群是我见过的对该定律最字面意义上的展示：智能体本身 就是 沟通结构。智能体边界是一个进程将消息传递给另一个进程并等待的地方。当你为了匹配团队而不是为了解决问题而划定这些边界时，你不仅继承了组织架构的形态，还继承了它的功能障碍，并以机器速度运行它。

你的智能体刚刚向错误的账户发放了 40,000 美元的退款，重新路由了一份触发加急运费的货运订单，或者推送了一个导致客户生产环境宕机六小时的配置更改。操作已经完成。它是不可逆的，或者代价大到接近不可逆。现在唯一重要的问题是那个在你上线产品前没人问过的问题：谁的预算来买单？

大多数团队都是通过惨痛的教训才发现答案的。在三天后的会议室里，供应商的客户经理在免提电话里向他们回读赔偿限额条款。限额是年度订阅费。而损失是这个金额的 40 倍。对话很快就结束了。

“你昨天做了什么？”是每一场站会的第一个问题。对于一个通宵运行智能体集群（agent fleets）的团队来说，这已经变成了一个无法如实回答的问题。字面上的答案是：我写了三个提示词（prompts），然后回家睡觉，醒来发现有 11 个 PR，其中 4 个我还没看。那个正在陈述进展的人并不是故意撒谎。是这种仪式在替他们撒谎，因为它建立在一个不再成立的假设之上——即工作单元是一个人类在办公时间内串行地、一次只做一件事。

这个假设是起到承重墙作用的。它支撑着燃尽图、Sprint 承诺、速率值、“受阻 / 进行中 / 已完成”列，以及“谁在什么时候告诉谁什么”的整个协作流程。抽掉这个假设，这些产物并不会优雅降级。它们会继续产生看似权威但毫无意义的数字。一个团队可以拥有漂亮的燃尽图和绿色的 Sprint 状态，而其实际吞吐量有一半发生在午夜到凌晨 6 点之间，这些工作不归属于任何人，没人审计，也没有体现在任何仪式中。

引入“人机回圈”（Human-in-the-loop），你就有了一个控制点。每天在这个人面前摆上一百个审批请求，你得到的只是一个戴着控制点徽章的“橡皮图章”。在架构图上，两者看起来一模一样。但在负载之下，它们的表现完全不同，而两者之间的鸿沟，正是大多数“负责任的 AI”部署默默宣告失败的地方。

任何观察过安全运营中心（SOC）陷入困境的人对这种模式都不陌生。行业调查显示，未被调查的警报比例在四分之一到三分之二之间——一个经常被引用的数字是，62% 的警报被直接忽略，55% 的团队承认经常错过被他们归类为关键的警报。分析师并不懒惰。他们每天处理数千个警报，而误报率通常超过 50%，人类大脑对这种比例的反应正是你所预期的：它不再关注了。智能体 AI（Agentic AI）正通过一个又一个确认对话框，重新制造这种完全相同的故障模式。

二十年来，文档一直是良好初衷的坟墓。你在第一个 Sprint 期间编写 README，那时架构整洁，你的热情高涨。但没人读它。到了第三个 Sprint，它就开始在构建命令上误导人，到了第六个 Sprint，它描述的是一个早已被删除的服务。文档是每个人都同意缴纳但实际上没人在缴的税 —— 一种没有反馈循环的道德准则。写了烂文档，什么也不会发生。不写文档，同样什么也不会发生，因为高级工程师把架构都记在脑子里。

然后我们将编程 Agent 指向我们的代码仓库，反馈循环一夜之间降临。README 现在是你拥有的杠杆率最高的文件 —— 这并不是因为有人做了关于文档规范的励志演讲，而是因为该文件的质量现在直观地决定了你的 Agent 是交付正确的代码，还是会信誓旦旦地对一个已不存在的架构产生幻觉。

这就是文档的复兴，而它与我们过去编写的文档几乎毫无关系。

传呼机在凌晨 2:14 响起。结账服务正抛出 500 错误，收入在流失，而你是值班工程师。你调出故障模块并开始阅读。代码很整洁——函数命名规范，结构合理，甚至还有几处有用的注释。然而你完全不知道它是干什么的。代码不是你写的。你团队里的任何人都没真正写过它。四个月前，一个智能体（agent）生成了这段代码，它通过了评审，测试通过了，并从此在生产环境中运行。现在它出故障了，而那个理应修复它的人却是第一次见到它。

这就是理解债（comprehension debt）：你的组织运行的代码量与人类实际理解的代码量之间日益扩大的差距。它不会显示在仪表盘上。当一切看起来都健康时，它在默默累积，并在最糟糕的时刻——在事故期间，当你对自己系统的理解不足其代价是以停机时间来衡量时——到期偿还。