578 篇博文 含有标签「insider」

上周二发布给用户的按钮标签从未经过文案人员之手，从未在 Figma 中评审过，从未进行过 QA，甚至在推理阶段（inference time）之前都不存在。它是由一个模型生成的，该模型在对话中途决定，收集送货地址的正确方式是渲染一个包含六个字段的内联表单，而不是再进行三轮文字交流。表单生效了，标签也没问题。团队中没有人能告诉你究竟是哪次模型运行生成了它，因为追踪记录（trace）已经从热存储中移出，而评估套件测试的是文本输出，而非组件图。

这就是生产环境中的生成式 UI（Generative UI）：模型不再仅仅是一个偶尔调用工具的文本生成器。它是一个输出为组件树的 UI 编译器，而设计系统现在是模型必须遵守的契约，而不仅仅是人类松散遵循的指南。这种转变打破了一整套假设——针对静态规范的 QA、固定布局的无障碍审计、最终字符串的文案审查、构建时的设计系统一致性检查——而大多数团队在替换掉这些旧流程之前，就已经发布了功能。

当 Agent 平台第一次崩溃时，事后分析报告（Postmortem）通常包含这样一句话：“周五我们还有八周的冗余容量。到了周一下午，我们已经达到了已配置容量的 140%。”没有人撒谎。容量模型本身是正确的，只是被应用到了一个它从未被设计用来应对的工作负载上。传统的容量规划假设需求沿着一条平滑曲线增长，周季节性是主导信号，最坏的情况是可以提前六个月规划的“黑色星期五”。Agent 工作负载彻底打破了这一假设。

Agent 需求的形态不是曲线，而是悬崖。有三件事造成了这种悬崖效应，并且它们会产生复合影响。一个企业级客户的入驻，就能根据你已经签署的合同通知，在通宵之间将基线移动 10 倍。一个 Agent 循环可以将微小的用户活动增长放大为扇出倍增的浪潮，对推理端的冲击比面向用户的图表显示的要高出 30 倍。单个产品变更——例如启用工具调用、延长上下文、切换到更大的模型——可以在用户数量不变的情况下，将单个任务的 Token 消耗提高一个数量级。

如果你的容量规划以 QPS 为单位，且你的冗余预算是“75% 的利用率是健康的”，那么你不是在规划。你是在赌这三个“悬崖”不会在同一个星期降临。

走进任何一家有五十名工程师在生产环境编写 LLM 代码的公司，你都会发现七个网关形态的产物。推荐团队造了一个用于在 OpenAI 和 Anthropic 之间路由。支持机器人团队写了一个用来挂载他们的 Prompt 注册表。平台团队有一个半成品代理，处理鉴权但不处理限流。增长团队有一个 Lambda，在数据发出时进行 PII 脱敏。数据科学团队直接调用供应商 SDK，而且没人告诉他们停止这样做。没有共享网关。只有七个共同的问题，每个都被孤立且拙劣地解决了，而首席财务官 (CFO) 正准备询问为什么 AI 账单环比增长了 40%，却没有任何明确的负责人。

这与行业在 2016 年和 2017 年遇到微服务时的架构节奏完全相同。成千上万的外部依赖，每个团队都有相同的共同关注点——鉴权、重试、可观测性、策略——以及在“解决一次”或“随处重新发明”之间做出选择。当时的答案是服务网格 (Service Mesh)。现在的答案是内部 LLM 网关，而大多数公司仍处于“随处重新发明”的阶段。

模型有知识截止日期。用户不知道它是什么。产品在几乎所有情况下都不会告诉用户。当用户问了一个正确答案在三个月前已经改变的问题时，助手会给出一个言之凿凿的错误答案——这并非因为模型失效了，而是因为产品从未提供一种方式来标记这种信息鸿沟。你与用户之间的信任契约是隐性的、不对称的，并且每当世界发生变化而你的 UX 假装没有变化时，这种契约就会被悄然打破。

主流模式是将截止日期视为一个注脚：一段埋藏在帮助中心里的披露文本、一个无人阅读的 /about 页面，或者在第一周就被关闭的一次性工具提示。这种定位是一个 bug。知识截止日期不像“上下文长度”那样是模型的一个属性。它是一个 UX 界面——经过工程化、设计和演进——将其视为次要因素，会导致交付的产品在用户无法审计的语调下，围绕自身的无知进行编造。

我上个季度合作的一个团队看着他们的 LLM-as-judge 分数在六周的提示词（prompt）迭代中从 78% 飙升至 91%。他们发布了产品。但用户却非常讨厌它。新的提示词产生了更长、格式更丰富、听起来更自信的回答 —— 而评委（judge）爱死了每一个回答。团队并没有构建出更智能的提示词。他们只是对评委的偏见进行了逆向工程。

这是团队中没人审计的失败模式。LLM-as-judge 有据可查的系统性偏见：无论质量如何，更长的回答得分更高；在两两比较中，第一个选项胜出的概率高于随机概率；且看起来像评委自身训练分布的输出得分高于不符的。如果你在十二个月前接入了一个 LLM 评委，且从未针对人类进行重新验证，那么你的分数就不是质量信号 —— 它们衡量的是你的提示词学会如何操纵其评估器的程度。

令人沮丧的是，捕捉这一点的审计方法很直接，防止它的校准纪律也很廉价，但几乎没有团队会执行其中任何一项。

当你第一次用经典的 SRE 复盘（Postmortem）模板来分析 LLM 事故时，模板赢了，而事故输了。时间线、诱因、缓解措施、预防措施 —— 每个字段都填好了，每个复选框都勾选了，但在文档的最后，没人能回答唯一重要的问题：究竟是哪个变量发生了变动？不是部署事件。不是基础设施故障。不是代码变更。而是 Prompt 的修订、路由选择的模型切片、未触发报警的 Eval 评分所用的 Judge 配置、质量投诉发生时的检索索引状态、规划器（Planner）正在组合的工具 Schema 版本，或者是异常时间段内的流量组合。这些在模板里都没有对应的一行。

SRE 模板并不是为那些“事实来源是观察到的行为而非代码路径”的系统设计的。在 LLM 技术栈中默默变动的变量，正是模板从未需要列举的变量。强行借用模板，只会产生那种被归类为“持续调查中”的“我们不知道发生了什么变化”的复盘报告。

对人类来说，503 意味着一个“稍后再试”的页面和一段咖啡休息时间。对 Agent 来说，503 只是在七次重试中的第一次尝试前那 250 毫秒的挫折，而且规划器（planner）已经开始询问 LLM 是否有其他工具可以绕过这个失效的依赖项。第一种行为为过载的服务提供了恢复空间。第二种行为则是过载服务的噩梦：数以千计的关联重试，每一次都比人类的操作更廉价、更快速，其中一半还会扩散（fan out）到下一个依赖项，因为规划器认为那是一个富有创意的变通方案。

负载脱落（Load shedding）—— 即通过丢弃低优先级任务来维持高优先级路径可用的准则 —— 是在流量发送主体主要是键盘前的人类，或者是具有手动调优重试策略且行为良好的服务的时代设计的。当 Agent 集群出现时，这两个假设都会瞬间崩塌。Agent 重试速度更快，能同时从更多地方发起重试，绕过故障重新规划，并把你返回的 503 视为负载均衡的暗示，而不是你本意中希望达成的协作式背压（back-pressure）信号。

本文将探讨为什么标准的负载脱落策略在面对 Agent 客户端时会失效，上游服务需要什么样的原语才能真正卸载 Agent 流量，以及 Agent 本身在工具层和规划层必须做些什么，才能不再成为别人事故报告中的恶意流量。

长上下文与 RAG 的经济学在两年内翻转了两次，而在那两个窗口期中选择了某种架构的团队，现在正处处支付着错误的代价。在 2024 年，趋势是将一切都塞进上下文窗口，因为窗口在不断扩大，而每 token 的价格在持续下降，因此检索流水线被斥为过时的繁琐工作。在 2025 年，共识发生了反转：关于“上下文腐烂”的研究表明，在百万级 token 的提示词中，窗口中部的有效召回率大幅下降，全窗口调用的延迟变成了用户体验问题，且账单变得非常惊人，于是检索技术重新得到了重用。到 2026 年，正确的答案不再是任何一种口号。它是一个在设计阶段做出的基于单个功能的决策，并记录下四个维度的权衡，因为为整个产品选择单一架构，是让每个功能同时出错的低成本方式。

一直困扰着团队的思维模型是将长上下文 vs RAG 视为路线图上的承诺，而不是针对每个界面的选择。你阅读了一篇有影响力的博客，选边站队，雇佣了擅长那一边的工程师，编写了一份将其规范化的平台文档，现在每个新功能无论是否合适，都采用了相同的架构。需要新鲜数据的功能忍受着陈旧的上下文。需要可扩展语料库的功能为他们永远不会使用的检索基础设施买单。需要引用来源的功能在发布时却缺失了这一项。这些都不是 bug。它们是将功能级决策视为产品级决策所带来的必然代价。

我上个季度交流过的一个团队发布了一个模型路由（model router），在离线基准测试中获得了 96% 的路由准确率，并使平均推理成本降低了 58%。但在运行三周后，支持工单开始集中在特定的用户群体中——即那些通过 API 运行脚本化批量查询的企业管理员。低成本路径向这些用户发送了大量垃圾回复。路由完全按照设计运行，但设计本身错了。

这个故事代表了常态，而非特例。“能用小模型就用小模型，必须用大模型时才用大模型”的架构是生产环境下 LLM 系统中最可靠的成本杠杆之一，在标准基准测试中记录的成本降幅在 45% 到 85% 之间。但每个路由演示中引用的节省数字都假设了基准测试的分布。生产流量并不具备这种形态，而两者之间的差距正是质量回退（quality regressions）存在的地方——这些回退集中在你的离线评估（eval）从未设计覆盖的细分领域。

仪表板显示，这个版本的质量提升了两个点。文本评估套件运行正常。你的模型供应商发布了一个新的 Checkpoint，在你跟踪的每个公开基准测试上都超过了前一个版本。你推进了发布。一周后，支持团队标记了一个隐蔽但持续增长的工单量上涨，内容关于上传的屏幕截图 —— 用户反映模型“读错了图表中的数字”或“漏掉了表格中的一行”。几天后，音频转录的投诉接踵而至，主要来自非美式英语使用者。这些都没有出现在你的评估流水线中。发布看起来很健康。但事实并非如此。

这就是多模态评估漂移（Multimodal Eval Drift），几乎每一个在以文本为核心的架构上硬塞进视觉和音频功能的团队都在发布这种问题。曾经适用于文本的评估规范 —— 黄金集（Gold Sets）、LLM 作为评委（LLM-as-judge）、漂移仪表板、以及决定是否发布的综合评分 —— 在多模态领域仅剩空名。每个模态的失败率不具可比性，捕捉文本错误的评分标准（Rubrics）捕捉不到图像错误，而且产生文本黄金集的标注流水线是针对每半年发布一次的工作量校准的，而不是针对伴随每次 Checkpoint 更新而来的多模态退化。

正确的心智模型是：多模态并不是同一个模型上的一个开关 —— 它是一个具有不同失败分布的不同产品面，而忽视了这一区别的评估规范在每次模型发布时都在输出隐形的退化。

一位资深工程师在周一加入你的团队。到了周五，他们已经交付了一个涉及 11 个文件的 TypeScript 重构，并在通过评审时仅有两个小细节（nits）需要修改。两周后，这位工程师打开了路由智能体（routing agent）的系统提示词——240 行指令、三个编号的示例块、四个“绝不允许”子句，以及底部一段读起来像道歉的段落——然后盯着它看了一个小时。他们无法告诉你如果删除第 87–94 行会发生什么。六个月前写下这些内容的工程师也无法告诉你。

这是没人会写在入职文档里的鸿沟。一个重度依赖提示词的代码库看起来像是个代码库：它存在于同一个仓库中，运行相同的 CI，并在相同的 PR 中接受评审。但它的语义却存在于别处：存在于一个团队中没人构建的模型观察到的行为中，针对的是一个没人能完全枚举的输入分布，其失败模式表现为添加一句话的 PR，而不是错误报告。传统的代码阅读工具——类型、签名、测试、命名——几乎不起作用。一个试图“阅读代码”的新员工无法了解为什么每一行都在那里，而一个只交给他们 Notion 文档和 Slack 频道的团队，实际上是在默认将入职培训“外包”给提示词的最初作者。

调出你公司的数据分类政策。公开、内部、机密、受限——四个整齐的层级，每一个都映射到一组访问控制和一份批准的存储位置清单。现在问一个该政策从未准备回答的问题：这些层级中，哪些允许以发送给第三方模型 API 的 Token 序列的形式离开公司边界？

答案几乎总是沉默。这并非因为政策本身有误，而是因为它是不完整的。当今使用的每种分类方案都是为一种访问向量设计的，即询问“该员工是否被允许读取这一行？”Prompt 层引入了一个完全不同的向量：一个获得授权的服务读取了该行，将其转换为 Prompt，并将其跨网络传输给一个供应商，而该供应商可能会记录它、在其上进行训练，或将其以明文形式保存三十天。这些都不属于读取权限范畴。这些都不在覆盖范围内。

这就是缺失的一列。在你添加这一列之前，你的数据分类文档只是在自信地宣称一种你实际上并不具备的控制态势。