990 篇博文 含有标签「insider」

在你的推理集群中的某个地方，可能有一块芯片正在计算错误答案。不是崩溃 —— 而是错误答案。它通过了制造测试，通过了健康检查，但在指令序列、数据值、电压和温度的特定组合下，它会返回一个完全错误的数字。超大规模云服务商已经在大规模范围内记录了这一现象：大约每千台设备中就有一台会发生静默数据损坏（Silent Data Corruption），这一比率比我们过去担心的宇宙射线导致的比特翻转（bit flip）要高出几个数量级。

五十年来，软件拥有一种针对此情况的免疫系统：确定性（Determinism）。相同的输入，相同的输出 —— 因此你可以进行校验和（checksum）、回放，并与基准结果（golden results）进行对比，撒谎的硬件最终会被抓获。LLM 推理是第一个失去这种免疫系统的主要工作负载。当模型给出一个略差的答案时，是因为采样器的随机性，还是因为退化的 GPU 在你的 KV 缓存中翻转了比特？没人能通过检查来判断。一个不稳定的加速器可以在所有仪表盘显示正常的情况下，静默地拉低你的质量指标数周之久。

每个构建 Agent 的团队最终都会遇到同样的瓶颈。系统提示词（System Prompt）起初只有 400 个 token。接着有人添加了数据库迁移检查清单。然后是复盘模板、部署运行手册、客户邮件风格指南。18 个月后，它变成了一个拥有 9,000 个 token 的巨石，没人敢去改动它，因为修改关于回滚流程的一行内容，竟然会降低 Agent 在支持工单中的语气表现。你构建了一个相当于 50,000 行的 main.c 的提示词——而且每个人都在对其进行静态链接。

直觉的反应是使用 RAG：将运行手册切片、嵌入（embed），然后按需检索。但这会以一种更隐蔽的方式失败。RAG 是为检索“事实”而生的，而事实在被碎片化时可以平滑退化——关于你计费模型的五个相关切片中检索到三个，仍然能告诉 Agent 大部分所需信息。但程序（Procedures）无法平滑退化。检索到 60% 的数据库迁移运行手册并不是 60% 有用，而是意味着一场生产事故。有第 1 到 4 步但缺失了第 5 步（“在切换前验证复制延迟”）比完全没有运行手册更糟，因为 Agent 现在的行为带着一种它尚未赢得的自信。

在你的代码库中的某个地方，有一个配置文件，在 test 配置下写着类似 model: small-and-cheap，而在 production 下写着 model: frontier。当有人添加这一行时，感觉是很负责任的做法 —— 为什么要为了每天运行 20 次的 CI 任务去消耗 frontier 模型的 token 呢？但那一行代码悄无声息地废除了一项你的团队十五年来一直在不假思索遵循的规则：你测试的环境应该表现得和你上线的环境一致。

“十二要素应用宣言”（Twelve-factor methodology）称之为开发环境与生产环境等同（dev/prod parity），我们在这方面已经做得非常出色，以至于我们开始忽略它的存在。Docker 为我们提供了位级一致的运行时环境。基础设施即代码（Infrastructure-as-code）为我们提供了完全一致的拓扑结构。然后，我们在请求路径中间加入了一个语言模型，重新引入了我们花了十年时间才弥合的差距 —— 只不过这一次，产生差异的组件不再是数据库版本。而是系统中负责做决策的部分。

如果你的 Agent 团队通过一个共享的计划文件、仓库或设计文档进行协作，每个人都在上面读写，那么恭喜你：你重新发明了黑板架构 (blackboard architecture)。这种架构在 1975 年曾是顶尖技术。令人尴尬的不是“重新发明”本身——好的想法值得回归。尴尬之处在于，原始架构有三个承重组件，而大多数现代 Agent 技术栈只重建了其中之一。

Hearsay-II 是 1971 年至 1976 年间在卡内基梅隆大学构建、由 DARPA 资助的语音理解系统。它面临着一个听起来很熟悉的问题：许多专业但不可靠的专家——声学分析器、语法预测器、语义评分器——没有一个能独立解决问题，它们都需要建立在彼此的局部推测之上。由此产生的架构包含一个共享工作区（黑板）、独立的专家（知识源）以及一个调度程序，调度程序在每一步决定接下来应该执行哪个专家的贡献。五十年后，将 LLM Agent 连接在一起的团队正趋向于同样的形态——一个主 Agent、一组执行者、一个共享产出物——并陷入了黑板架构文献在大多数人出生前就已命名并解决的失败模式。

周五下午 4:50，数据团队的某人启动了一次评估扫描（eval sweep）：针对公司的共享模型部署运行四万个提示词，计划在周末完成。下午 5:10，面向客户的聊天助手开始超时。值班工程师盯着仪表盘看了两个小时，显示服务商返回了 429 错误，直到有人想起问一句还有谁在使用该账号。没有任何东西损坏。系统正完全按照配置运行，也就是说什么也没做，因为没人配置它去做任何事。

这是一种新型故障的雏形，它具有一个比普通停机更棘手的特性：没有需要修复的 Bug。评估扫描是正当的工作。聊天助手的流量也是正当的工作。失败之处在于，两个具有不同紧急程度的团队从一个无差别的推理算力池中提取资源，而该池子对谁更重要没有任何判断。当你的公司有多个团队同时使用同一个服务商账号时，容量分配就不再仅仅是基础设施的细节——它变成了一个政治问题，而传呼机（pager）继承了这一麻烦。

你的编程智能体（Coding agents）刚刚让编写代码成为了交付软件中最廉价的部分。但它们并没有让代码落地变得更便宜。AI 采用率高的团队合并的 Pull Request (PR) 数量几乎是以前的两倍——而他们的交付指标却几乎没有变化，因为每一个 PR 仍然必须挤进同一个代码评审流水线、同一个 CI 集群以及同一个合并队列（Merge Queue），而这些设施当初是按人类打字速度设计的。约束并没有消失，而是向后移动了，移到了系统中那个最窄的管道：从“已批准”到“进入主分支（main）”之间的串行化路径。

这是一个经典的约束理论（Theory-of-constraints）故事，大多数工程组织目前正身处其中却尚未察觉。当一名开发者可以在并行工作树中指挥 5 到 10 个智能体时，PR 的体量就不再与员工人数挂钩。但合并吞吐量仍然取决于一些更为死板的东西：你的 CI 每小时能验证多少个 main 分支的候选状态。这个数字受限于测试套件的时长、执行器（Runner）容量、抖动率（Flake rate）和队列机制——而这些都没有随着智能体变快而变快。

在某处，此时此刻，一个 AI 助手正在向潜在客户解释你的产品。它引用的价格是你 18 个月前修改过的，推荐的集成是你上个季度停止支持的，并建议一个返回 410 Gone 的 API 端点。你永远不会看到这段对话。没有分析事件被触发。没有会话录像。潜在客户要么相信了错误答案并提交了一份困惑的支持工单，要么相信了错误答案，转而悄悄购买了模型随口提到的竞争对手的产品。

这不是一个假设的未来问题。AI 推荐已经占据了可观的流量 —— 对于某些技术和电子商务网站，这一比例高达 5–8% —— 而这些推荐背后的答案，是模型在任何时候吸收的关于你的任何信息生成的。你的营销团队花了十年时间学习如何监控品牌搜索、评论网站和社交媒体提及。几乎没有人正在监控增长最快的表面：当有人询问关于你的信息时，模型是怎么说的。

关于通宵编码智能体（coding agents）的宣传非常诱人：你睡觉，智能体集群干活，你醒来时 PR 已经处理完毕。但现实情况往往更微妙且代价更高。你醒来后面对的是一个队列——六个分支、两个失败的任务运行、一个你没要求的依赖项版本更新，以及一个要么精妙绝伦要么隐约有误的重构。智能体的确生成了代码。但呈现在你桌面上的交付物并不是代码，而是一个分诊（triage）问题，且大多数团队都没有处理它的工作流。

数据显示这并非少数人的抱怨。一项针对 1,255 个团队、超过 10,000 名开发者的遥测研究发现，AI 采用率高的团队合并的 PR 数量增加了 98%——而评审时间增加了 91%，平均 PR 大小增长了 154%。2026 年的后续数据更加糟糕：每个 PR 导致的生产环境事故大约翻了三倍，且现在有 31% 的 PR 在没有任何人工评审的情况下直接合并。当智能体开始值夜班时，瓶颈并没有消失。它转移到了上午 9 点，集中在你一天中的前 90 分钟，并有了一个名字：早晨评审队列。

你拥有的每一份延迟优化手册（latency playbook）都是为那些单次请求工作量大致恒定的系统编写的。数据库查询耗时相对固定。图像缩放随像素数变化，而这是预先可知的。甚至经典的 LLM 补全也有可预测的成本范畴：输入多少 token，输出有限的 token。推理模型悄无声息地打破了这一假设。当模型在运行时自行决定思考多久——且它是基于问题难度来决定时——响应时间便不再是基础设施的属性，而变成了问题本身的属性。

后果首先体现在你的分位数指标上。在生产环境中运行推理模型的团队报告称，p99 延迟会激增到 p50 的三到五倍，这不是因为主机变慢或缓存失效，而是因为百分之一的请求恰好真的很难。你的自动扩缩容策略、超时策略和 SLO 仪表板都是针对一个“这种差异意味着系统出现故障”的世界而调整的。而现在，这却意味着系统正按设计运行——你用来管理尾部延迟的所有工具都指向了错误的原因。

每个安全团队对拼写抢注 (typosquatting) 都有一个心智模型：攻击者注册 requets 并等待有人误输入 requests。这行得通，但它是对人类粗心大意的一种随机押注。Slopsquatting 则更糟糕，因为这种“拼写错误”并非随机。语言模型会以可预测、可重复的模式虚构出看似合理但并不存在的包名——攻击者可以查询你使用的相同模型，收集它们虚构的名字，并准确地在 PyPI 和 npm 上注册这些包。幻觉变成了预购单。你的编码智能体 (coding agent) 在拥有自主安装权限的情况下运行，就是那个取走包裹的顾客。

这并非假设。关于这一现象的最大规模研究对 16 个模型生成了 223 万个代码样本，发现 19.7% 的推荐包并不存在——涉及 205,474 个独特的虚构名称。当一位安全研究员将其中一个最常被幻觉出的 Python 包注册为一个无害的空壳时，它在三个月内被下载了超过 30,000 次，并最终出现在一家大型科技公司开源仓库的安装说明中。由“氛围编程” (vibe coding) 带来的供应链攻击已经完成了它的概念验证。

问一个工程师他们公司的业务逻辑在哪里，他们会指向一个 Git 仓库。问财务团队、运营团队或销售团队，诚实的回答是一个名为 pricing_model_v7_FINAL_final.xlsx 的文件。定价公式、人员编制计划、佣金计算、月末对账宏 —— 大多数公司的运营核心都运行在 Excel 和 Google Sheets 上。它没有类型，没有测试，没有代码审查，也没有部署流水线。它是像餐巾纸草图一样被维护着的生产基础设施。

三十年来，这套系统基本行得通，因为读取和写入这些文件的只有人类 —— 动作缓慢、谨慎，并且具备“这个数字看起来不对”的直觉。那个时代刚刚结束了。适用于 Google Sheets 和 Excel 的 MCP 服务器现在将完整的“增删改查（CRUD）”权限作为一等公民 Agent 工具开放，而且每个 Agent 平台都提供电子表格连接器，因为那里才是客户数据真正存放的地方。我们将有史以来构建的最快的写入者连接到了有史以来部署的最脆弱的生产系统上，而大多数团队只花了一个下午就完成了这项工作，甚至没有进行过一次设计评审。

故障频道里传来消息，说新的提示词正在幻觉退款金额，所以你做了一个显而易见的决定：将生产环境标签重新指向到上周的提示词版本。三十秒，无需重新部署，教科书级的回滚。结果 Agent 表现得反而更糟。上周的提示词引用了一个名为 lookup_order 的工具，但平台团队在周二将其重命名为 orders.search。记忆库中充满了由新提示词格式生成的偏好摘要，而旧提示词会将这些内容误读为用户指令。你并没有回滚 Agent，而是制造了一个“奇美拉”——三分之一是上周的，三分之二是今天的——并在从未测试过该组合的情况下将其推向了生产环境。

这是任何人的运维手册中都没有涵盖的失败模式：Agent 的部署不是一个单一的构建产物，而是一个三元组——提示词版本、工具契约、以及累积的记忆状态。回滚其中一个维度，而让另外两个维度保持现状，并不能恢复之前的状态。它创造了一个从未存在过、从未通过评估、且不属于任何团队值班范畴的新状态。