907 篇博文 含有标签「insider」

一次客户审计发现，在 Redis 集群中存放了长达 11 个月的逐字记录的用户 PII，而数据驻留团队中没人知道这个集群的存在。系统并未遭到破坏。没有攻击者入侵。这些数据是推理团队为了性能优化而构建并命名为“Prompt 缓存”的服务故意写入在那里的。分析路径上的脱敏工具在此期间运行得非常完美。只是脱敏工具根本没在那条路径上。

尽管如此，违规行为是真实的。根据 GDPR，保留时间超过合同约定的 30 天就已经足够；数据无需泄露即可触发第 33 条规定的通知义务。数据驻留团队的清单列出了每一个日志、每一个仓库、每一个队列——但唯独漏掉了这个缓存，因为在组织架构图中，这个缓存位于推理团队的一侧。每个人都信任的隐私边界直接顺着分析流水线向下延伸，却在大模型（LLM）栈开始的地方止步了。

一位西班牙客户投诉称，她的年度续费被提前一天计费了。支持工单在经历了三个队列后，终于转到了一位工程师面前，他敏锐地察觉到了问题的端倪：这是一个日期格式化的回归（regression）问题，且仅出现在欧洲用户群中。他在 date-formatting 模块上运行了 git log，却一无所获。该模块已经 11 天没动过了。而 11 天前真正被改动的，是它的 package.json —— lodash 的版本从 4.17.20 升级到了 4.17.22。这次升级是由一个安全代理（security agent）发起的，由值班人员批准，并在没有任何评论的情况下合并了。

在同一个文件中，版本字符串上方两行有一条 18 个月前写的注释：// do not upgrade — breaks the snapshot tests in date-formatting, see FRONT-2418（请勿升级 —— 会破坏 date-formatting 中的快照测试，详见 FRONT-2418）。安全代理没有阅读它。或者更准确地说：安全代理阅读了整个文件，但它的提示词（prompt）指令是查找有漏洞的版本字符串，而不是衡量周围注释的权重。这条注释是承载关键信息的机构知识（institutional knowledge）。而代理却将其视为无关紧要的背景装饰。

这是一个两个互不知晓正在发生碰撞的系统之间的协同失效。安全代理履行了它的职责。写下注释的原工程师履行了他的职责。每次修改文件都遵守固定（pin）版本的开发代理也履行了它的职责。唯独没有人决定谁该负责在它们之间进行调解。

评测集（eval set）是一个文件。但它也暗含了对 AI 功能用途的理论定义。这两者并非一回事，混淆它们的团队建立了一个质量网关，而其校准完全依赖于单个人的工作记忆。当那个人离职时，文件留下了，但那套理论也随之而去了。

这是你在组织架构图中看不到的失败模式。你规划了一个提示工程（prompt engineering）角色。你雇佣了一个优秀的人才。他们发布了 v1 版本的提示词，审视了简陋的基准测试，并将其重写为内容丰富的东西——一个失败模式分类法、每个类别的权重，以及一套能够消除边缘情况歧义的标注指南（rubric）。评测集变成了“该模型是否好到足以发布”的契约。六个季度后，你发现这份契约除了编写它的那个人之外，其他人都看不懂。

你的事故时间线显示“过去 72 小时内没有部署”。你的 Prompt 注册表也印证了这一点：prompt v37 已经冻结三周了。你的评估工具链在周二晚上运行正常。但在周三早上，你其中一个 Agent 的结构化输出失败率翻了三倍，另一个 Agent 的重试预算翻了一倍，而第三个 Agent 开始愉快地忽略一条它已经遵守了一个月的指令。什么都没变。除了确实有东西变了，而且变在组织中两边都没盯着的地方：模型。

Prompt 注册表记录 Prompt 版本。模型网关记录模型版本。但在实践中，几乎没有人追踪这两者的“配对”关系。Prompt v37 并不是一个独立的工件——无论你的工具链是否承认，它都是一份针对特定模型协商后的契约。当平台团队将 claude-sonnet-latest 别名向前推进一个补丁版本时，另一端的契约已经被悄悄修改了。由于部署发生在别人的基础设施上，且名称未变，你的事故时间线依然显示“没有部署”。

你的平台团队出于成本考虑采用了供应商的 "auto" 模型标识符。上线后的第一个仪表盘数据非常有说服力：在每周 eval（评估）中没有出现可衡量的质量下降，支出却减少了 34%。三个月后，在你最短、流量最高的功能点上，客户满意度已经连续两个季度下滑。一项由产品主导的调查最终将这种回归追踪到了一个工程团队无人触及的模型标识符上。代码里写的是 "auto"。而供应商一直在重新定义 "auto" 这一路整过程中的含义。

教训并不是自动路由不好。教训是，"auto" 是一个移动的目标，其分布随供应商的经济效益而漂移，而你的 eval 的代表性是供应商优化与你的产品质量之间唯一的屏障。如果 eval 与流量不匹配，那么你所庆祝的折扣，其实是从一个无人审查的质量斜坡中支付的。

一个检索增强生成（RAG）管道可能会连续数周出现性能退化，而没有任何指标能察觉到。相关性评分看起来正常，检索延迟没有变化。触及受损主题的评估切片（eval slice）向错误方向移动了 0.25 个点，而你的每周审查将其归因于噪声。直到有人阅读了模型为某个客户工单实际接收到的上下文窗口，发现同一个段落出现了三次——一次是标题格式，一次是小写格式，一次是去除了标点的格式——你才意识到，一个月以来，你的前五名（top-five）在暗地里其实只是前二名。

这类故障的特点是：系统完全在按照指令行事。检索器正在返回与查询最相似的向量。这些向量中的每一个都确实与正确的主题相关。索引根本不知道其中三个向量来自同一个段落（只是以三种方式索引了三次），因为原本应该捕获这种情况的入库阶段去重环节正在静默跳过它。

一个平台团队签署了一份为期数个季度的预留吞吐量合约。在承诺容量内按固定的 token 费率计费，超过上限的部分则按更高的超额费率计费。财务部门根据六个月的历史流量对消耗进行了建模，而这些流量很少触及上限。合约中规定“溢出”是指超过承诺上限的每分钟字节数，基于这个定义，这笔交易看起来很稳健。

六周后，在流量形态、路由配置和产品界面均未改变的情况下，账单飙升了 2.4 倍。供应商在季度中期悄悄修改了计量定义。现在，“溢出”还包括自动路由器发送到高于预留层级的模型请求——因此，即使总吞吐量完全在承诺范围内，一次在复杂提示词上选择 Sonnet 的操作也会被计入超额桶中。原本按预留费率结算的 30% 流量，现在改按超额费率计费。财务部门通过仪表板追踪了三周的突发增长，最后才有人读到季度中期的定价补充协议，并在脚注中发现了这一重新定义。

合约并未被违反。但计价所使用的单位被重新定义了。

周会汇报的幻灯片上写着 99.9%。发票则显示账单翻了三倍。这两个数字在相邻的仪表盘上共存了数月，却没人发现它们衡量的是不同的世界。可靠性数值是重试后的结果——每一个最终返回 200 的调用都被计为成功——而成本数值则是客户端进行的每一次尝试，按 Token 计费。在两者之间，是一个慷慨的五次重试循环，以及一个尾部延迟正在悄悄恶化的供应商。第一次有人同时观察这两个数字是在一次故障期间，当时成本异常告警在可用性告警之前就触发了。

这就是整个模式。一个看起来像是可靠性机制的重试预算，本质上也是一个成本-质量调节旋钮，而那些只关注其中一面的团队，正在为一个发票最终会修正的可用性数字买单。

你的 Agent 调用了一个耗时 35 秒的工具。在这 35 秒内，没有任何 Token 从模型流回浏览器。Provider 的 SSE 流仍然开启。你的工具仍在运行。用户的加载动画也在旋转。而在路径中间的某个你无法控制的反向代理认为连接静默时间过长，关闭了它，随后你的客户端重连逻辑尽职地从头重新启动了整个请求。

第一次响应产生了 4,200 个 Prompt Token 和 600 个 Completion Token。第二次响应也是 4,200 个 Prompt Token 和 600 个 Completion Token。用户得到了一个答案。而你的账单却收到了两份。

这份事后分析读起来像是一份幻觉报告。一名用户根据一份语气笃定的建议采取了行动，但结果证明该建议是错误的——这种错误在模型正常完成输出的情况下是不会出现的。然而，追踪记录显示模型并未完成输出。在预期的 800 个 Token 中，供应商连接在第 412 个 Token 时断开了。客户端的错误处理程序记录了这次失败。但随着 Token 的到达，持久化的部分消息已被写入对话历史，在用户的 UI 中看起来与其他完整的回答毫无二致。于是用户采信了它。支持团队将该工单归类为内容质量问题，花了整整两周时间才将其转交给平台团队。

这条链路中没有任何环节属于模型故障。模型对生成的 412 个 Token 表现得非常正确。失败的原因在于流式 UI 和持久化对话历史在“什么才算是一条消息”的问题上产生了隐秘的分歧。而正是这种流式传输本应缓解的故障模式，导致这一分歧成为了权威记录。

这是乐观渲染（Optimistic Rendering）与持久化存储之间的契约。大多数聊天产品只是从教程或框架中继承了这种模式，而从未将其视为一项契约，这种鸿沟最终表现为一系列看似模型 Bug 实则不然的尾部故障。

我上个月接触的一个团队对一个数字感到非常自豪：他们的高级主管智能体（supervisor agent）在第一次审查时就批准了其子智能体（subagents）97% 的计划。他们将其解读为“子智能体非常有能力”。六周后的红队审查则将其解读为“主管和子智能体实际上是同一个评估者在给自己的输出打分”。这两种解读都符合数据，但只有其中一种在生产环境中是真正“承重”的。

主管-审查-子智能体模式（supervisor-reviews-subagent pattern）是 2026 年多智能体系统中最常见的形态——约占生产部署的 70%，其中包括各大实验室发布的大多数参考设计。在纸面上，这看起来像是一种校验机制。规划者分解任务，专家执行者制定计划，主管在授权执行前审查每个计划。关注点分离、清晰的审计追踪，应有尽有。问题在于，如果你使用相同的基础提示词模板来构建主管和子智能体——即使角色特定的补充说明有一段不同——你构建的也不是校验机制，而是一个审查步骤，它只是同一个模型自我认同的产物。

你的 AI 团队将系统提示词（System Prompt）视为专有知识产权（IP）。部署流水线会将其从每一个客户可见的界面中剥离。针对生产环境调试的操作手册（Runbook）要求工程师在任何故障产物（Incident artifact）离开作战室（War room）之前，通过 grep 将其过滤掉。你的上一次安全审查捕获并封堵了三条不同的提示词泄露路径：过于冗余的 API 响应、发布到错误层级的调试请求头（Debug header），以及将提示词嵌入到消息中的堆栈跟踪（Stack-trace）端点。

但在某个早晨，这一切都变得毫无意义：一名工程师加入了一个关于无关账单争议的供应商支持电话，通过屏幕共享展示他们的终端以演示堆栈跟踪信息。而该回溯信息中包含了一行详细的日志，完整打印了完全解析后的提示词——每一个注入的变量都已被替换，包括针对特定客户的业务规则和内部模型路由提示。供应商的支持工程师按照标准支持工作流录制了通话。录音随后进入了供应商的工单管理系统。现在，提示词被清晰地存储在了一个第三方 SaaS 中，而你的安全审查与其没有签订合同，没有签署数据处理协议（DPA），也没有审计权。