990 篇博文 含有标签「insider」

我上季度合作的一个团队针对其支持智能体（support agent）运行了一套包含 240 个案例的评估集。连续六个月，测试结果全线飘绿。接着，他们更换了规划器提示词（planner prompt）中的一个句子——仅仅是一次语气调整——结果第二天生产环境的人工接管请求激增了 3 倍。而评估分数却纹丝不动。人工接管分支仅仅是开始在以往能在线解决的临界案例上触发，而评估集中没有一个案例属于这种临界类型。该分支存在于提示词中，存在于生产环境中，唯独不存在于评估集中。

这就是我想命名的失败模式：智能体分支覆盖率 (agent branch coverage)。代码覆盖率工具在过去的 40 年里一直是调试的基础，但智能体系统具有运行时控制流——规划器分支会选择工具、限定回复条件、升级到人工、拒绝执行、或尝试不同的策略重试——而评估集仅触及团队想到的那些案例。规划器 80% 的决策分支从未在测试下执行，于是，一份“全绿”的评估报告就成了一场披着回归测试外衣的冒烟测试。

那些发布了带有显著性加权内存驱逐（salience-weighted memory eviction）功能智能体的团队，在不知不觉中，已经为每一次模型升级预订了一个内存迁移项目。驱逐策略表面上看起来是一个质量杠杆——选择最聪明的评分方法，获得最好的召回——但它实际上是一个隐秘的版本契约。当评分模型发生变化时，智能体实际上的“过去”也会随之改变。现有的围绕提示词和评估（evals）构建的工具链都无法捕捉到这一点，因为发生漂移的产物既不是提示词也不是评估，而是几个月前由一个已经不存在的模型做出的一系列关于“该忘记什么”的决定。

LRU（最近最少使用）和 LFU（最不经常使用）没有这个问题。它们是确定性的、与模型无关的，并且可以干净利落地在升级中幸存。但它们也会丢弃掉那些审慎的裁判模型会保留的信息。这是大多数团队在第一天——当 Demo 的召回率指标是衡量一切的唯一标准时——会做出的妥协。然而，这种妥协在智能体余下的生命周期里，每季度都会反噬你一次。

一位监管人员走进你的办公室，提出了安全团队反复演练过的那个问题：“请展示客户数据存放的每一个地方。” 你的数据团队拿出了清单。主数据库在上面。分析型数据仓库在上面。对象存储、队列、搜索索引、备份目的地——统统都在上面，附带着分类标签、保留政策、加密详情和负责人姓名。接着，房间里有人提到了 Agent 工作线程池，而清单上却对此只字未提。这个线程池已经运行了九个月。每个工作线程都有一个本地磁盘。这些线程上的 Agent 一直在解析 PDF、转录音频、下载邮件附件，并在工具调用之间缓存中间 JSON，而这一切从未停止过。却没有人将这些内容放入资产登记表。

这就是“临时目录问题”（scratch directory problem）。每一个长期运行的 Agent 工作线程都会积累一个临时文件系统，随着新工具的加入而有机增长——PDF 解析器提取的文本、Whisper 步骤转录的音频、Gmail 工具下载的附件、浏览器使用步骤的截图、为下一轮对话缓存的向量搜索片段、Agent 在两次工具调用之间生成的中间 JSON（以便第二次调用不必重新推导）。与数据库、队列和存储桶不同，这个表面没有保留政策，没有静态加密标准，没有 DLP 扫描器过滤，也没有出现在数据分类电子表格中。平台团队认为 “Agent 状态”指的是推理提供商的上下文窗口。SRE 团队认为 “Agent 状态”指的是持久化数据库。而工作线程的 /tmp/agent-workspace-${session_id}/ 目录则是客户数据的第三份副本，且处于无人管理的状态。

负责构建你公司内部 LLM 网关的团队最初将其范围设定为“限流和审计”。十八个月后，同一个团队正在主持季度分配会议，调解两个产品组之间的配额纠纷，并发现他们为解决容量问题而交付的架构，现在充当着公司内部的 AI 财务部。没有人授权他们担任这个角色，但也没有人把它从他们的职责中拿走。

这是每个 AI 平台团队都在经历的发展轨迹，大多数团队在拥有政策、赞助人、甚至拥有足以支撑决策的遥测数据之前，就已进入了“政治经济阶段”。技术工作——请求路由、密钥管理、重试——是简单的部分。困难的部分在于，有限的供应商配额加上三个有上线期限的产品团队，就构成了一个预算分配系统，而运行网关的团队正是那个被要求进行分配的角色。

仪表板显示一切进展顺利。分流率高达 65%。工单量下降。单次咨询成本减半。接着，支持团队开始有人离职，离职面谈中提到了一些仪表板上没有列出的东西：“每一个班次都是煎熬。”

这是 AI 增强型支持中隐藏的机制。分流率衡量的不是消除的难度，而是浓缩后的难度。到达人工客服手中的案例不再是客户现实情况的代表性样本——它们是残余物，是 AI 无法解决的案例。而这些残余物比平均水平要沉重得多。

一个计算机使用型智能体（computer-use agent）在客户的 CRM 上完成了一项任务，工作线程池将浏览器返回到空闲环中，几百毫秒后下一个请求到达，仪表板导航成功——唯一的问题是，它是作为错误的用户登录成功的。前一个会话的 OAuth cookie 仍留在配置文件（profile）中。追踪记录显示 navigation succeeded（导航成功）、screenshot captured（截图已捕获）、action performed（操作已执行）。运行日志中没有任何内容表明，智能体正在以一个从未授权过它的用户身份进行操作。

这是浏览器智能体从其构建所用的库中悄然继承的一类故障。无头浏览器（headless browser）框架被设计为每个配置文件仅供一个用户使用，因为这是浏览器三十年来的工作方式。当工作池为了摊销全新的 Chromium 实例长达八秒的冷启动时间而重用配置文件时，这种“单用户”假设就破裂了，而且这种破裂对于团队通常信任的每一层遥测数据来说都是不可见的。

一年前，你的评估套件（eval suite）表现得非常出色。候选模型的得分分布在 60 到 80 分之间，排名结果能为你提供有效的参考。新的微调模型比基准模型高出 6 分；更廉价的模型则低了 3 分。决策依据这些数字而产生。而今天，在同样的评估套件下，每个候选模型的得分都是 95、96 或 97 分，得分差距已经缩小成了噪音。你的团队仍在运行评估，仍在阅读报告，仍在利用它为迁移亮绿灯——但这份报告已经不再包含任何有效信息。

这不是基准测试污染（benchmark contamination），也不是世界漂移引起的衰减（world-drift decay）。这是一个测量工具的问题：你的测试用例是针对平台已经超越的难度水平而校准的。尺子没有坏；而是你正在测量的东西已经超出了它的量程。那些没有意识到这一点的团队，仍然在使用一个辨别范围与所比较的候选模型不再重叠的工具来进行模型决策。

你的黄金评估集（Golden eval set）是一个你的安全团队甚至不知道其存在的隐私边界。它是通过对生产环境的 Trace 进行采样构建的，这意味着它是一系列精心挑选的真实客户查询集合——通常包含姓名、电子邮件、账号、愤怒的通话记录、输入了一半的信用卡卡号——并配有标准正确回复，最后提交到评估流水线读取的任何存储桶中。

最后一部分正是评估数据具有独特危险性的原因。原始的生产 Trace 之所以敏感，是因为它记录了客户所说的话。而评估案例则以一种全新的方式变得敏感，因为它记录了客户所说的话 加上标注的正确答案。这个标签是一个衍生作品，由某人（通常是标注员或领域专家）有目的地添加。它标志着“这是标准答案”。它赋予了 Trace 原始日志从未有过的生命力——日志保留策略最终会将 Trace 轮转删除，但评估案例现在成为了一个永久的测试 fixture（固定数据），团队致力于保持其测试通过（keeping green）。

在生产级 LLM 评估中存在一种悄无声息的失败模式，这是任何排行榜都无法捕捉到的：你的测试集是基于留存用户构建的，因此它永远不会提出那些让其他用户离开的问题。季度复季度，评估分数攀升，仪表板一片绿，但净留存率（net retention）依然在下滑。团队在追问“评估是否可被操纵？”，而真正的故事更简单也更残酷：评估分布向幸存者偏移了，而幸存者恰恰是你最不需要其反馈的人群。

这是换了装束的二战轰炸机装甲问题。Abraham Wald 观察了返回的飞机，注意到弹孔聚集在哪里，并指出你应该加固的地方是那些没回来的飞机上的弹孔。把轰炸机换成用户，把弹孔换成失败的交互轮次，你就得到了从生产追踪（production traces）中提取评估集的中心病理。

一个团队从前沿模型升级到了其更快的后继版本。评估套件（eval suite）全绿。最终答案一致。工具调用的 Schema 完全相同。结构化输出通过了与以往一样的 JSON Schema 验证。他们发布了。不到一天，支持票据就堆积如山：“助手感觉太匆忙了”，“它不再真正思考了”，“感觉不对劲”。产品经理调取了遥测数据，发现任务完成率没有变化。工程团队反复检查了评估和 Schema，没发现任何问题。投诉是真实的，但团队定义的契约——就如团队所定义的那样——依然完好无损。

改变的是流的纹理（texture）。旧模型在调用工具前会停顿 800 毫秒，发出一句“让我查一下……”的前导词，并以每秒约 35 个 Token 的速度输出，在子句边界处有自然的节奏。新模型以每秒 90 个 Token 的速度输出，从不停顿，且完全跳过了前导词。这些都没有出现在任何文档记录的契约中。但所有这些都是不可或缺的“承重”部分。

这就是海勒姆定律（Hyrum's Law），而流式传输（streaming）让它的表面积变得巨大。系统的任何可观察行为都会被某人所依赖——而流式 AI 界面暴露的可观察行为远比团队意识到的要多。

一个 200 毫秒的工具调用在火焰图（flame graph）上看起来就像是杂音。但在 Agent 循环中堆叠七个这样的调用，杂音就变成了信号 —— 模型在 800 毫秒内完成了思考，但用户却等待了 4.5 秒，因为每一次工具调用都在重新支付首个调用已经吸收掉的启动成本。残酷之处在于，这种成本在任何单一的追踪（trace）中都不会显示为异常。它表现为干脆利落的 Demo 与反应迟缓的生产环境 Agent 之间的差异，而大多数团队会将其归咎于模型。

Model Context Protocol (MCP) 已成为 Agent 工具链的默认集成界面，这意味着它也成了延迟（latency）堆积的重灾区。MCP 的设计 —— 基于 stdio 或可流式 HTTP 的 JSON-RPC、能力协商（capability negotiation）、动态工具发现 —— 对于一个必须桥接任意客户端和服务器的协议来说是正确的。但它隐含的单次调用成本结构对于 Agent 实际的访问模式并不友好。Agent 的模式不是“每个会话调用一次工具”，而是“每轮对话调用七个工具，每个会话进行四十轮对话”。

这篇文章将探讨这种错配：冷启动税究竟存在于何处，为什么它在长生命周期的 Agent 中是叠加而非被摊销（amortize）的，以及如何通过“预热池”（warm-pool）规范将数秒的惩罚降低到 100 毫秒以下。

这张图片是一张红色八角形停止标志的照片。有人在中间的单词上贴了一张小贴纸，上面写着“YIELD”（让行）。你问多模态模型：“这个标志写了什么？”模型回答：“该标志指示驾驶员在交叉路口让行给迎面而来的车辆。” 表现得既自信又流利，却既不忠实于视觉证据，也不忠实于文本证据。它是一个混合体，在产生分歧的真相通道之间采取了折中方案。

这种故障模式目前还没有一个统一的名称。研究多模态幻觉（multimodal hallucination）的研究人员将其称为“语义幻觉”（semantic hallucination）、“跨模态偏差”（cross-modal bias）或“模态主导”（modality dominance），具体取决于撰写论文的细分领域。交付文档 AI、截图智能体和缺陷检测系统的从业者每周都会遇到这种情况，并在事故复盘中将其描述为“模型只是在瞎编”。它不是瞎编的。这是一种在最终层融合了两个通道、却没有任何原语来表示通道意见不一情况的架构的可预测输出。