990 篇博文 含有标签「insider」

当依赖项损坏时，你的构建会失败。当临时规避方案变得不再必要时，什么都不会发生。这种不对称性正是为什么每一个运行超过一年的生产级 LLM 系统都带有它不再需要的脚手架——重试编排、输出修复解析器、强制思维链、复杂的任务分解、分块启发式方法——每一个都是为了弥补特定模型的特定弱点而构建的，而且每一个都在无声无息中比它所补偿的弱点活得更久。

令人不安的是，这不仅仅是一个像过期的特性标志（feature flags）那样的卫生问题。过时的脚手架不仅仅是消耗你的延迟和 Token。在最坏的情况下，它会主动将新模型限制在旧模型的上限内：你的分解逻辑将一个任务切分为六个步骤，是因为 2024 年的模型无法处理整个任务，而 2026 年的模型本可以一次性完成，现在却继承了六个在你构建的缝隙中丢失上下文的机会。

在你公司的某个地方，有一张幻灯片上写着一个数字。“AI 质量：87”。上个季度这个数字是 85，所以幻灯片是绿色的。与此同时，你的值班频道里塞满了截图，显示助手正在自信地为你的最大企业客户捏造退款政策。这两件事同时发生，而撒谎的是那张幻灯片。

这张幻灯片背后的管理层需求完全合情合理：给我一个可以追踪的分数，让我知道这玩意儿是在变好还是变坏。这在收入和可用性上行得通，但在 AI 功能上行不通。因为 AI 功能的质量不是一个标量 —— 它是在输入、用户和时间维度上的分布。将这种分布平均成一个数字并不能起到总结作用，反而精准地破坏了决策者所需的信息。

这篇文章讨论的是这两个事实之间的差距：为什么你的评估套件（eval suite）的平均值隐藏了那些真正伤害你的回归（regressions），你应该汇报什么，以及如何向董事会报告的受众展示一个本质上存在波动的指标，且不会在指标下降的第一周就毁掉你的信誉。

在你公司的某个角落，一名工程师已经将一个智能体集群接入了一个仅获授权 50 个用户席位的 SaaS 产品。这个集群在一夜之间运行了上千个并发会话，通过一个服务账号进行身份验证，并完成了整个部门的工作。没人询问过法务，也没人询问过供应商。如果你仔细阅读合同，很有可能整个工作负载都是未经授权的——这并非因为有人存心欺骗，而是因为这份合同是为一个“用户”意味着“敲击键盘的人”的世界而编写的。

这是智能体时代悄然浮现的合规问题。按席位许可、服务条款中的自动化条款、公平使用率限制以及按用户分析，所有这些设计的初衷都基于一个假设：使用量随员工人数而扩展。智能体从各个方向同时打破了这一假设。运行智能体集群的客户不仅让供应商的定价模型承受压力——他们还经常违反协议的字面规定、其背后的经济逻辑，或者两者兼而有之。

调出你上次遇到持续 429 错误时的请求日志。你可能会发现一些奇怪的现象：错误并不是以稳定的流形式出现的。它们成波浪式出现——一波 429 爆发，接着是一段安静的间隔，然后是更大的爆发，再接着是另一个间隔。服务商的配额在波动期间并没有改变。你的流量也没有激增。你所看到的其实是你自己的重试逻辑在自我同步。每个在第 0 秒失败的客户端都计算了相同的退避（backoff）延迟，睡眠了相同的时长，并在同一瞬间醒来，然后再次共同失败。

这就是“惊群效应”（thundering herd），而最讽刺的是，标准的修复方案——指数退避（exponential backoff）——并不能阻止它。确定性的指数退避“组织”了惊群。它将一群几乎在同一时刻失败的客户端聚集起来，并让他们步调一致地前进：所有人都在 1 秒后重试，然后所有人都在 2 秒后，再然后是 4 秒。负载峰值的间隔变得更远了，但每个峰值的高度依然和第一个一样。如果正是这个峰值触发了你的速率限制，那么你实际上构建了一个永远重新触发它的节拍器。

你的定价页面显示每个用户支付的费用相同。但你的成本仪表板却给出了不同的答案。同样的 AI 功能 —— 同样的提示词模板、同样的模型、同样的特性标志（feature flag） —— 为西班牙语用户提供服务的成本要高出 55%，日语用户大约翻倍，而阿拉伯语或孟加拉语用户则超过 3 倍。与此同时，这些用户获得的质量也明显更差：在翻译成不同语言的相同基准测试问题上，当前沿模型脱离英语分布时，其表现会下降 13 到 24 个百分点。

大多数在全球范围内发布 AI 功能的团队从未衡量过这两项数据。他们拥有分地区的定价、分地区的支持 SLA、分地区的法律审查 —— 却只用一套英语评估测试集来代表全球每个用户的体验。

这就是分词器税（tokenizer tax），它与仅靠规模无法弥补的质量差距相互叠加。在你按语言维度拆分数据之前，这两者在仪表板上都是不可见的。而且这两者早在你写下第一个提示词的几年前，就由你无法控制的分词器训练语料库决定了。

如果你在任何真实规模下运行编程智能体 (coding agents)，你就拥有一支临时虚拟机舰队。你可能并没有主动申请这样做。但在你决定（且正确地决定）不信任的、由模型生成的代码绝不应该在应用程序的信任边界内执行的那一刻，这一切就发生了。每个任务都有自己的沙箱，每个沙箱都是一个微型虚拟机 (microVM) 或硬化容器。突然间，那个自以为在构建“智能体产品”的平台团队，实际上正在运营一些看起来非常像微型 AWS Lambda 的东西：池预热 (pool warming)、快照流水线、装箱调度器 (bin-packing schedulers)，以及一个针对无人认领环境的清理进程 (reaper process)。

陷阱在于假设你的容器编排直觉可以无缝迁移。有些确实可以。但 Kubernetes 是为了调度长周期的、同质化的服务而设计的，而智能体沙箱恰恰相反：生命周期短、极度异构，且创建速度之快让部署滚动更新 (rollout) 看起来像是在悠闲散步。那些挣扎的团队往往将沙箱基础设施仅仅视为“步骤更多的容器”。有趣的工程挑战——以及几乎所有的成本——都集中在四个问题上：冷启动、文件系统状态、装箱密度和弃置。

AI 工程中的大多数“自研还是购买”之争都是逐个组件展开的。我们应该构建自己的模型网关还是使用 OpenRouter？编写自己的智能体循环还是采用框架？微调还是提示词？每一次争论都有专门的会议、电子表格和嗓门最大的人。而每一次争论都悄悄地假设，格局会保持足够长的时间，让决策能够产生回报。

事实并非如此。你 AI 技术栈下的根基正以史无前例的速度移动。在固定的能力水平下，推理价格每年下降 9 倍到 900 倍不等 —— 具体取决于你追踪的能力阈值。2021 年底每百万 token 耗资 60 美元的 GPT-3 级输出，现在只需几分钱。智能体框架在三年内经历了多次颠覆性的重写。网关层从“我们应该建一个”到充满托管和私有化选项的竞争激烈的红海市场，仅用了大约 18 个月。在这样的格局中逐个组件进行决策，就像是盯着脚尖去划船。

有一个诞生了 60 年的工具正是为了解决这个问题：沃德利地图。它不会告诉你该构建什么。它会告诉你一些更有用的东西 —— 你的哪些组件即将变成别人的廉价产品，而哪些组件正在向相反的方向移动。

你发布过的每一个进度条都建立在一个假设之上：你知道分母。上传一个 40 MB 的文件？分母就是 40 MB。安装 212 个包？分母就是 212。进度条是诚实的，因为在工作开始之前，总工作量是已知的。

智能体（Agent）从根本上打破了这个假设。它执行的不是预定的步骤列表——它在执行过程中不断发现剩余的工作。它读取一个文件，结果发现了另外三个值得读取的文件。它运行测试，测试失败了，于是引发了一个谁也没计划过的调试分支。原来的第 4/7 步变成了第 4/19 步，偶尔又会变成第 4/4 步，因为最后三步被证明是不必要的。对于智能体来说，计算完成百分比（Percent-complete）并不难，而是“未定义”。在工作完成之前没有分母，而一旦完成，答案永远是 100%。

然而看看我们发布的产品：预示即将完成的加载动画（spinners）、爬到 90% 就卡住的进度条、在原本需要 8 分钟的任务进行到第 2 分钟时显示“即将完成……”的标签。这些都是小小的谎言，而且用户能识破它们。有趣的交互设计问题不是如何更逼真地伪造进度，而是当工作的持续时间在结构上无法预知时，诚实的安抚（honest reassurance）应该是什么样子的。

你的 Agent 在一个包含十二个步骤的任务的第七步挂掉了。框架捕获了异常，经过指数退避（exponential backoff）后进行了重试。它重试了该步骤 —— 但使用的是同样的上下文窗口（context window），其中已经堆积了三次失败的工具调用、一段解析了一半的错误消息，以及一个模型已经放弃的计划。当然，重试也失败了，因为重试是一场赌注，赌的是世界发生了变化，而那个 Agent 的世界没有任何改变。需要改变的是 Agent 的状态 —— 而任何 Agent 框架中的重试策略都不会做出这种决定。

Erlang 的 OTP 库在三十年前就为必须运行数十年的电话交换机制定了这项决策。主管树（supervisor trees）背后的洞察力从来不是“在崩溃时重启”。而是“如何恢复”是一个与“执行工作”完全解耦的关注点，它由一个独立的进程负责，并排列在一个层级结构中，每一层都对恢复的含义有更深一点的理解。现如今的大多数 Agent 框架将重试强加到单个调用上，这就像在电话交换机的每一行代码周围都套上 try/catch 一样。它们真正需要的是这种层级结构。

互联网经济建立在一个极其古老以至于无人明说的假设之上：加载页面的那个东西长着眼睛。当人类到来，广告曝光触发，联盟营销 Cookie 植入，分析事件记录访问——这一连串微小的变现事件支撑着内容的产出。现在，这条链条的每一个环节都在同时断裂，因为你网站的读者中，机器人的比例正日益增长。它们是 Agent，而 Agent 是看不见广告的。它提取答案，将其交给别处的用户，除了日志行之外什么也没留下。

这并非一个你可以作为工程师在旁观望的遥远出版商问题。如果你正在构建任何基于检索（Retrieval）的东西——无论是 RAG 管道、浏览网页的 Agent，还是总结网络内容的产品——你正处于一个市场的需求侧，而该市场的供给侧刚刚发现自己一直在免费赠送库存。修正正在进行中，它背后有基础设施和标准支撑，并且它将作为一项新的成本支出和新的失败模式降临在你的架构上：上个季度还免费开放的上游资源，这个季度就变得需要付费、授权或直接关闭了。

2026 年 1 月，curl 关闭了其漏洞赏金项目。六年的时间，86,000 美元的支出，以及源源不断的真实漏洞 —— 计划的结束并非因为资金耗尽，而是因为有效信号消失了。从历史上看，超过 15% 的提交最终被确认为真实的漏洞。但到了 2025 年底，这一比例降至接近三十分之一，而提交量却激增至正常水平的八倍。队列中充满了冗长、自信、却完全编造的报告 —— 其中一份报告甚至附带了 GDB 会话和寄存器转储，引用了一个在 curl 中根本不存在的函数。

令人不安的事实是：产生这些垃圾信息的人并不是恶棍。他们中的许多人是像你一样的工程师，运行着像你一样的智能体，对准了你的产品所依赖的代码库。AI 将“产出”一项贡献的成本压缩到了接近于零，但它对“审核”贡献的成本却毫无助益。任何具有这种形态的经济系统 —— 发射成本极低，吸收成本极高 —— 最终都会演变成垃圾信息问题，而吸收端则是那些在你那不知疲倦的智能体出现之前，就已经在义务工作的志愿者。

持久化记忆是每个人都会给自己的智能体添加、但几乎没人维护的功能。这个提议令人无法抗拒：智能体会记住你的模式、你的偏好、上周二的决定，并且每一次会话都比上一次更聪明。而失败模式则更加隐蔽：默认情况下，记忆呈单调增长，而一个关于不断变化的世界的“仅追加”事实存储库，无异于一种缓慢的投毒。被迁移的 API、被重组的团队、被推翻的架构决策 —— 所有这些都与新鲜事实并排存在于存储库中，以同样的权威性被检索，并以同样的自信心被注入到上下文中。

无状态的智能体会犯下孤立的错误。而配备了记忆的智能体可以将一个错误变成重复性的错误，因为它存储了该错误，随后又将其作为证据检索出来。一个被自信写下的错误记忆 —— “支付服务拥有退款逻辑” —— 会污染未来每一个召回它的运行过程，而每一个基于它执行的运行过程又可能写下源自它的新记忆。这不仅仅是一个存储问题。这是一个垃圾回收问题，而大多数智能体记忆系统在发布时都没有配备回收器。