702 篇博文 含有标签「llm」

影子 IT 曾经意味着营销团队报销 SaaS 订阅，或者工程师私自创建 S3 存储桶。这很烦人，是采购方面的头疼问题，但大部分情况下是可以承受的。影子 AI 也是出于同样的本能——绕过缓慢的官方路径——只不过爆炸半径更大，且进入门槛几乎降至为零。

一名工程师可以在一个下午将 LLM API 调用接入生产工作流。一名支持主管可以在午饭前搭建一个无代码的分流智能体。一名数据分析师可以将一个季度的客户记录粘贴到聊天窗口中，以“快速总结一下”。这些都没有经过审查，没有出现在架构图中，而且你的治理计划无法保护一个它根本不知道存在的系统。

令人不安的是规模。2025 年 UpGuard 的一项调查发现，超过 80% 的员工——以及近 90% 的安全专业人员——在工作中使用未经批准的 AI 工具。你的安全团队在用，你的高管也在用。问题不在于你是否有影子 AI，而在于你是否能看到它。

观察某人第一次使用聊天产品时，你会发现他们在模型完成输出之前就开始阅读了。这种“边出边读”的行为正是流式传输（streaming）存在的全部意义：它将数秒的等待转变为一种对话般的感觉。然而，这也是你的输出防护栏（guardrails）悄然失效的原因。

这是一个令人尴尬的过程。模型生成了第 1 个 Token、第 2 个 Token、直到第 150 个。每一个 Token 在到达时都会立即渲染。到第 200 个 Token 时，模型产生了一个虚假的用药剂量、泄露了一个电子邮件地址，或者生成了一句违反内容政策的话。你的输出侧防护栏正确且立即触发了。但“立即”已经太晚了——用户已经阅读了前 200 个 Token。你无法撤销渲染。防护栏履行了职责，但违规内容仍然传达给了人类。

一个用户询问你的助手某项配置更改是否可以安全发布。模型流式返回了：“是的，你可以安全地部署。” 300 毫秒后，它继续写道：“——但在 us-east 区域除外，那里的旧连接池仍在排空。”但用户已经读完了前半部分，感受到了绿灯带来的放松，并点击了部署。这句修正说明到达时，人已经走开了。

这里没有人犯错。模型是正确的。用户阅读了屏幕上的内容。渲染器忠实地显示了每个到达的 Token。然而结果却是一次糟糕的部署，因为流式传输将模型的“中间状态”变成了用户视为“最终结果”的东西。

你的团队启用模式约束解码（schema-constrained decoding）的那一天感觉像是一个里程碑。解析错误停止了。JSONDecodeError 警报消失了。从文本中抓取字段的脆弱正则表达式也被删除了。有人在站会上说“模型现在返回有效的 JSON 了”，结构化输出的任务单随之关闭。

那句话正是麻烦的开始。“模型现在返回有效的 JSON 了”是正确性工作的开始，而不是结束。JSON 模式和约束解码保证了响应的形状（shape）——即 quantity 是一个整数，status 是三个枚举值之一，对象包含你要求的键。它们完全无法保证 quantity 是否是正确的数字，status 是否反映了真实发生的情况，或者 sku 字段是否指向了目录中存在的商品。

打开任何一个已经在生产环境中运行了一年的智能体的系统提示词（system prompt）。滚动到底部。你会发现一层读起来像道歉一样的句子沉积层：“绝对不要伪造订单号。”“不要承诺无法确认的退款。”“如果用户在德国，不要提及旧版方案。”每一句都是一块化石。每一句都标志着生产环境中出现问题的确切时刻 —— 有人被传呼了，而当时能找到的最快修复方法就是增加一句话。

没人删除这些句子。不是因为它们还在发挥作用，而是因为删除一句话意味着需要证明一个否定命题 —— 证明模型不会在一个可能已经在三个模型版本前修复的 Bug 上发生回退。没人能证明这一点，所以那行字留了下来。系统提示词变成了一个关于过去事故的“只增不减”（append-only）日志，它让你在每一次调用中都永远支付着 token 费用。

这是 AI 系统中最隐蔽的一种技术债，因为它看起来不像债。它看起来像是在尽职尽责。

三月，一位用户告诉你的智能体停止推荐有室外座位的餐厅——他们搬到了一个带宝宝的公寓，深夜外出已经结束了。九月，智能体为他们的周年纪念建议了一家屋顶酒吧。用户感到恼火，而你感到困惑，因为你亲眼看着三月份的纠正生效了。它被写入了记忆。它仍然在那儿。问题在于它与最初的偏好并排存在，而最初的偏好也还在那里，检索算法浮现了旧的那个，因为它对“周年纪念晚餐”的向量嵌入（embedding）匹配度稍高一点。

这是没有人针对其设计的失败模式。团队在记忆写入上花费数周时间——提取、摘要、嵌入、命名空间——而将删除视为以后再解决的问题。长期记忆使得添加一个事实几乎是零成本的，因此事实不断堆积。但记忆库不是日记。日记允许包含过去真实的事情。智能体读取并据此做出决策的记忆库则不然，因为智能体无法区分事实与过时的残余。

当一个智能体（agent）给出的回答比上周差时，第一直觉往往是归咎于提示词（prompt）。有人会重新编写系统指令，删减几句话，增加一个示例，然后发布。有时这会有所帮助。但通常这毫无作用，因为提示词从来就不是问题所在。问题在于，一个冗长的工具调用结果静默地消耗了 18,000 个 token，将实际的任务指令推到了上下文窗口中关注度较低的中部位置，让模型在一个 70% 都是噪音的记录上进行推理。

这不仅是措辞问题，更是资源分配问题。资源分配在系统工程中有一个专属名称：调度（scheduling）。上下文窗口是一种固定大小的资源，多个消费者在其中竞争，而目前大多数智能体技术栈“调度”它的方式就像 1960 年代的批处理系统调度内存一样——先到先得，直到用完为止。

观察一个 Agent 思考多步任务的过程，你会注意到一些熟悉的东西：它的规划方式就像你调试代码一样。尝试一种方法，观察结果，如果错了，就撤回并尝试另一种。Agent 将其计划描述为一棵选项树，它可以探索、剪枝和重新访问。这种心智模型在代码沙箱中是正确的，因为在那里的每个操作都有隐式的撤销功能。但在 Agent 接触到现实世界的那一刻，这种模型就错得离谱且危险。

发出的邮件无法撤回。扣款的银行卡在没有退款流程、手续费以及已经看到通知的客户的情况下，是无法撤销扣款的。除非有人设置了软删除，否则被删除的数据行就彻底消失了。一条发布的 Slack 消息可能已经被阅读了。Agent 的规划模型没有原生的“单向门”概念——即一旦采取行动，就再也无法假装它从未发生过。

这不是一个模型智能问题。即使是更聪明的模型仍然不知道你的哪些工具是可逆的，因为可逆性不是操作本身的属性。它是操作所落地系统的属性。你必须明确告诉它。

将你的 GPU 推理自动缩放至零（Autoscaling to zero）看起来是显而易见的成本控制策略。GPU 是账单中最昂贵的项目，流量具有突发性，而空闲时间纯粹是浪费。所以你开启了缩放至零（scale-to-zero），看着云端账单下降，并以此自得。

然而，在一段沉寂之后，一位用户出现了，他们的第一次请求需要 60 秒才能返回一个 token。运行 Serverless LLM 推理的生产部署经常报告冷启动超过 40 秒才出现第一个 token —— 相比之下，模型预热后的每个 token 延迟大约仅为 30 毫秒。这是冷路径和热路径之间千倍的延迟差距，而这完全取决于你的流量空闲情况。

这是没有人会写在 PPT 上的权衡。缩放至零并没有消除成本；它将稳定的金钱成本转化为了突发性的延迟成本，然后将这种延迟成本隐藏在仪表盘很少关注的 p99 尾部。

财务团队指出，本季度的 LLM 账单上涨了 18%。一名工程师调出使用情况仪表板，发现 70% 的流量现在流向了经济型模型（budget model）而非前沿模型（frontier model），他感到有些困惑：路由更改本应是为了削减开支。每 token 价格确实如电子表格预测的那样下降了。但账单还是上涨了。

这不是计费错误。这是成本优化在悄无声息中发生逆转的最常见方式。证明降级合理的电子表格衡量的是一件事——token——而生产系统支付的是完全不同的另一件事：完成的任务。较弱的模型不仅仅是产生更便宜的 token。它还会改变其周围每个组件的行为，而这些二阶效应最终都会反映在同一张发票上。

这个陷阱非常诱人，因为一阶数学逻辑确实是正确的。经济型模型的每 token 价格可能比前沿模型便宜 10 到 30 倍，且对于大部分流量，它返回的答案在质量上是难以区分的。错误不在于路由决策。错误在于在错误的边界衡量路由决策。

现在每个智能体 (agent) 框架都将“长期记忆”作为核心功能发布，每个团队都将其视为百利而无一害的好事。智能体记住了用户的偏好、之前的决策、项目上下文以及上周收到的修正，因此每次会话的起始状态都比上一次更“热”。演示效果令人难以抗拒：用户说一句“按照我的喜好设置项目”，智能体就照办了。没有人问那个显而易见的问题，因为这一功能的叙事框架在刻意回避它。

问题是：这一切何时会变得不再准确？

记忆存储本质上是一个缓存。它保存着关于一个并非静止不变的世界的事实。智能体在 8 个月前记录了“用户偏好 Postgres”，但团队此后已迁移到了另一个数据库。智能体记得“用户在增长团队”，而用户在 3 月份已经调岗了。智能体存储了一个简洁的对话总结，但该对话的前提在两条消息后就被修正了。记忆层在提取这些信息时，其自信程度和新鲜感与今早刚写下的事实完全一致。我们花了 50 年的时间才意识到，没有失效策略的缓存就是一个正确性漏洞 (correctness bug)。然后我们构建了智能体记忆，并在没有这种策略的情况下将其发布了。

在每个 AI 功能的演进过程中，审阅者总会提出一个听起来很合理的问题：“我们能不能让模型告诉我们它的置信度（confidence），这样我们就可以把低置信度的回答路由给人工或备选方案？”这听起来像是一份免费保险。你在输出 schema 中添加一个 confidence 字段，模型尽职尽责地填好它，现在你就有了一个可以调节的旋钮。发布吧。

那个旋钮并不是免费的，更糟糕的是，它通常没有连接到任何实际逻辑上。置信度数字只是模型乐于生成的一个 token 序列，模型并没有义务让它具有实际意义。团队支付真实的 token 和延迟来获取它，却从不检查它是否与正确性相关，然后根据它路由生产环境的流量，就好像 “0.9” 真的代表 90% 的可靠性评估一样。它就像一个用螺栓固定在仪表盘上的压力表，但玻璃后面其实什么也没连。

这篇文章讨论了两个没人定价的成本：生成置信度字段本身的单次请求税，以及信任一个未校准的数字来做路由决策所带来的更巨大的成本。