720 篇博文 含有标签「llm」

当一个智能体（agent）加入你的团队时，每个工程经理脑海中最接近的类比就是新员工。因此，应对策略显而易见：给它一个沙盒和只读日志，将最初的任务范围缩小，与其结对编程，预留一段磨合期，并随着信任的累积让它承担更重的工作。这听起来很负责任。这感觉就像是你把上一个初级工程师培养成高级工程师时那种耐心的管理方式。

这也是一个范畴错误（category error）——它不只是一个略显不完美的类比，而是一个错误的类比。初级工程师是一个还不太了解你系统的人。而智能体是一个无状态的函数，无论接触系统多少次，它永远都不会真正“了解”你的系统。这是两种完全不同的事物，适用于前者的管理直觉会在无形中让你错配注意力。

这之所以重要，是因为这个隐喻不仅会产生误导，还会让你把精力投在错误的地方。“培养智能体”并不是一种策略。智能体是固定的，你真正能改变的一切都存在于它之外。

Prompt 缓存被宣传为一种稳赚不赔的方案。缓存长期的共享前缀——你的系统提示词、工具定义、检索到的上下文——只需为变化的短尾部分支付全额费用，然后看着账单下降。数字是真实的：缓存读取的成本大约是新鲜输入 Token 的十分之一，因此具有大量稳定前缀的工作负载，其输入成本可以降低 80% 或更多。团队因此采用它，因此调整它，并用单一指标来汇报：缓存命中率，且趋势向好。

这种表述掩盖了一个事实：你刚刚划定的边界——缓存前缀与非缓存尾部之间的界线——并不是一个计费旋钮。它是一个正确性边界。缓存断点之上的所有内容都是系统认为可以在请求之间互换的内容。如果你为了最大化命中率而划定这条线，你就是在让财务指标来决定你的 Prompt 中哪些事实可以在用户之间、租户之间以及跨时间共享。这是一个隔离决策，理应有目的地做出。

这种失效模式是隐蔽的，因为它永远不会报错。如果缓存命中提供了一个由另一个用户概况塑造的上下文，它会返回一个格式完全正确的响应。如果缓存命中提供了一个在缓存预热时为真、但在重用时已失效的个性化信息，它会返回一个自信、连贯但错误的答案。你的延迟图表或错误率不会有任何波动。唯一的信号是看起来 非常棒 的命中率——因为 Key 太粗颗粒度了。

在 Prompt Injection（提示词注入）违规事件发生后，最常见的调查结果通常是某种形式的“模型被骗了”。检索到的文档包含了隐藏指令，Agent（智能体）执行了这些指令，导致客户数据泄露。随后的修复方案几乎无一例外地是内容过滤器：扫描输入、对恶意指令进行分类，并在其到达模型之前将其剥离。部署过滤器，结案。

这个结论是错误的，而过滤器就像是一台无休止的“跑步机”。“模型被骗了”描述的是症状，而不是漏洞。漏洞在于，一个拥有实际权限的 Agent——如数据库令牌、发送邮件能力、文件系统写入权——接受了来自一个永远不该被允许指挥这些权限的来源的指令。这并不是一种新型漏洞，而是一个“混淆代理”（Confused Deputy）问题，操作系统在近 40 年前就已经对其进行了命名并基本解决了它。

如果你将 Prompt Injection 视为检测问题，你就是在参与一场与每一个能组织语言的攻击者之间的军备竞赛。如果你将其视为权限问题，你就可以复用数十年来行之有效的安全工程经验。

一次 10 轮的对话成本并不是单轮对话的 10 倍，而是接近 55 倍。这是大多数团队在建模 AI 功能的单位经济效益（unit economics）时最容易犯的错误，也是为什么一个在表格上看起来有利可图的产品在生产环境中却在不断亏钱的原因。

错误在于将对话视为一系列独立的请求。事实并非如此。由于 LLM API 是无状态的，每一轮对话都会重新发送累积的全部历史记录。第一轮发送 1 个单位的上下文，第二轮发送 2 个，第十轮发送 10 个。整个会话中计费的总 Token 数是 1 + 2 + ... + N 的总和，其增长趋势为 N²/2 —— 即平方级增长 —— 而你的产品几乎肯定收取的是固定的线性价格。

那些最喜欢你产品的用户，正是那些进行最长对话的用户。他们也是在悄无声息中摧毁你利润空间的人。

频率限制（Rate limit）过去曾是一个基础设施细节。当你遇到 429 错误，你会使用退避算法（backoff）重试，将溢出的请求排队，而 On-call 频道之外的人甚至根本不知道这回事。用户看到的响应只是比平时慢了几百毫秒。这就是故事的全部。

对于智能体（agentic）功能，这个故事不再适用。当一个智能体在执行多步计划的过程中，中途触及了供应商的每分钟 Token 数（TPM）上限时，失败并不会停留在基础设施层。它会表现为一个半成品的答案、一个在最后一次调用前卡住的工具循环，或者让用户盯着一个永远无法解决的加载动画。配额不再仅仅是后端容量数字，而变成了一个产品必须围绕其进行设计的约束条件 —— 就像产品围绕结账流程或空状态进行设计一样。

两个支持用户在短短一分钟内向你的智能体提出了几乎相同的问题。第一个用户问：“我们针对 EU 订单的退款期限是多久？”第二个用户问：“我们针对 US 订单的退款期限是多久？”这两个句子的嵌入向量（embeddings）仅有一丝之差——长度相同，结构相同，只有一个两字母 token 的区别。你的语义缓存经过了相似度阈值的微调（在演示中看起来非常合理），将它们判定为匹配。于是，第二个用户得到了第一个用户的答案。EU 的 14 天冷静期被当作事实，以流利的文字呈现给了一位 US 客户，且没有任何补充说明。

没有人会因此收到报警。缓存返回了 200。延迟表现优异。成本看板显示了一次命中，这正是每个人想要的结果。唯一能说明出了问题的信号是客户根据一项不适用于他们的政策行事——而这个信号在几天后才会通过退款纠纷传来，而不是通过你的监控系统。

正是这种故障模式，让语义缓存与你之前构建过的任何缓存都截然不同。精确匹配缓存可能会过期，但它永远不会 错误——key 要么匹配，要么不匹配。语义缓存则是有意放弃了这种保证。它被设计为能针对从未见过的 key 返回答案，而这种延迟优势的代价是正确性风险，大多数团队从未对这一风险进行过量化。

影子 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）匹配度稍高一点。

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