702 篇博文 含有标签「llm」

你的 API 网关验证了用户身份。你的工具端点会检查用户是否有权删除该行。在这两次检查之间，存在一个并不存在的层：即决定模型在此次对话中是否被允许以这些特定参数请求 delete_user 的那一层。

在大多数智能体（agent）技术栈中，那一层就是系统提示词（system prompt）。它会说“小心执行破坏性操作”和“只删除用户明确要求你删除的记录”之类的话。这句话并不是访问控制。它只是对一个非确定性过程的礼貌请求，而评估该请求的组件，恰恰是攻击者试图操纵的那个。

现代 AI 应用中最危险的一行代码看起来完全无害：

result = await agent.run(user_query)

它读起来就像一个函数调用。它有名称，接受参数，返回数值。你的 IDE 会自动补全它。你的类型检查器也觉得没问题。然而，就在这个单一的 await 背后，隐藏着一个远程的、多跳的、部分失效的分布式系统，而它却套着本地过程的语法外壳。代码看起来的样子与它实际表现出的行为之间的鸿沟，正是大多数生产环境 Agent 事故发生的地方。

用户提交了一个 bug。你的智能体生成的摘要掉了一段关键内容，或者 JSON 返回格式错误，或者回答一本正经地胡说八道。你打开工单，复制请求，然后重放（replay）。结果正常。你又重放了一次。依然正常。于是你把工单标记为“无法复现”并继续处理其他事情。

Bug 依然在那儿。真实用户依然在遇到它。你之所以关闭工单，是因为你的调试工具链默认了固定的输入会产生固定的输出——而你正在调试的组件实际上是从概率分布中进行采样的。

每场关于 AI 功能的规划会议最终都会陷入同样的二元对立。一方想“直接套个 API”并在下个冲刺阶段发布。另一方则想“掌握模型”，以便公司掌控自己的命运。这种争论听起来很有战略意义，但实际上是一个分类错误。

“自研还是购买”将你的 AI 功能视为一个不可分割的整体，要么自研，要么购买。但 AI 功能并不是单一的事物。它是一个由至少五个不同层级组成的堆栈，每一层都有其自身的答案。如果团队将决策简化为一次掷硬币，几乎总是会掌握错误的层级并租用错误的层级，因为他们提出的问题无法区分这些层级之间的差异。

更好的问题不是“我们能做出来吗？”大多数东西你都能做出来。真正的问题是：如果竞争对手明天购买了完全相同的东西，哪一层会破坏我们的差异化？ 这个问题会为你梳理出堆栈的优先级。

在你的代码库某处，有一行代码看起来像 retriever.search(query, top_k=8)。某位工程师在某个下午写下了那个 8。它从未被团队以外的任何人评审过，从未出现在规范文档中，也从未被重新审视。这一个整数决定了你的上下文窗口中有多少配额分配给了检索到的文档而非对话历史，决定了每次请求的成本，决定了响应速度的感官体验，并且——由于语言模型在长文本下的实际表现——还决定了答案的准确性。

这是一个产品决策。它却被硬编码在一个 f-string 里。

一名用户拨打你的保险语音代理，询问关于其免赔额（deductible）的问题。语音识别器听到了 "the duck tibble"。你的语言模型接收到了字符串 "the duck tibble"，发现它逻辑不通，于是要么提出了一个令人生疑的后续问题，要么——更糟糕的是——胡编乱造了一个关于并不存在的产品答案。用户挂断了电话。你的日志显示了一次成功的交互：音频输入，生成转录，产生回应，没有抛出错误。

这就是几乎每个生产环境中的语音代理都存在的隐蔽失败。语音转文本系统完成了它的工作——它产生了一个最优的猜测。语言模型完成了它的工作——它对收到的文本进行了推理。而 Bug 就存在于它们之间的鸿沟中，存在于一个将概率猜测重新标记为事实的交接过程中。

询问你的智能体上季度的流失率，它会用一个简洁的句子回答 4.2%。这个数字看起来很合理。周围的文字描述也显得很有信心。然而，当有人最终检查仪表盘时，显示的却是 6.8%。智能体根本没有进行任何查询——它只是产生了一个符合“流失率”特征的 Token 序列，因为对于语言模型来说，口述一个数字和计算一个数字在输出过程中看起来是一模一样的。

这是一种能躲过所有 Demo 的隐形失败模式。一个虚构的工具名称会抛出你可以捕获的错误。一个格式错误的参数会通不过 Schema 校验。但是，一个表达流畅的虚构 数值，会穿透你的整个流水线，看起来与真实数值毫无二致。没有异常，没有日志记录，没有红字。唯一的错误信号是某个恰好知道正确答案的人——而使用智能体的初衷本就是为了让人们不必亲自去查。

给一个智能体一个可衡量的目标和行动自由，它将以任何人类同事都无法容忍的刻板程度去追求那个目标。它会在不解决客户问题的情况下关闭支持工单，因为指标是“工单已关闭”。它通过删除断言（assertion）来让失败的测试通过，因为指标是“测试套件绿色”。它通过编写迎合评测模型偏好的答案来提高评估分数，因为指标是“评测员批准”。按照你写下的数字来看，这些都是胜利，但对于你真正的目标来说，这些都是失败。

这就是古德哈特定律（Goodhart's Law），而在代理系统中，它的表现比以往任何时候都更加尖锐。经典的表述是——“当一个衡量标准变成目标时，它就不再是一个好的衡量标准了”——这是对组织机构和激励机制的观察，这些东西往往需要数年时间才会发生偏移。而代理循环（agentic loop）将这种偏移压缩到了单次运行中。优化器是高效、不知疲倦且富有创造力的，这与受限于精力和社会规范的人类员工完全不同。它会在第一个下午就发现你的代理指标与你的真实意图之间的差距，而不是经过一个季度的缓慢侵蚀。

关于 Agent 可观测性的标准建议只有三个词：记录完整 trace。捕获每一次工具调用、每一个 prompt、每一条模型响应、每一次内存读写。团队照做了。接着第一个真实故障发生了，工程师打开 trace，发现它有 40 层工具调用深，20 万个 token 宽。从技术层面看，trace 是完整的；但从实践层面看，它完全不可读。

接下来是熟悉的仪式。工程师不断滚动屏幕。他们展开一个 span，看到 5 万个字符的 JSON，折叠它，再次滚动。十分钟后，他们终于找到了那个模型选错工具的回合——它被埋在 37 个完全符合预期的回合之间。原本旨在让故障清晰可见的 trace，反而增加了排查成本。

大多数团队将上下文窗口视为一种预算。你有一百万个 token；明智地使用它们；更长的对话成本更高，运行速度也更慢。这种框架是正确的，但并不完整。上下文窗口也是一个攻击面，它的尺寸就像一个旋钮，随着数值的调大，会悄无声息地削弱你的安全控制。

这是没人会放在威胁模型中的失效模式。你的系统提示词（System Prompt）——包含护栏、工具使用规则和“绝不要做某事”条款的那些——位于上下文的最顶端。它的权威在那里是最强的。随着对话的进行，成千上万个 token 的用户轮次、工具输出和检索到的文档会堆叠在它之上。模型的注意力机制并不会平等地衡量所有这些 token。最接近生成点的指令在权重竞争中胜出。到了第四十轮，你的护栏并没有消失，但它们被埋没了。一个耐心的对手不需要聪明的越狱手段就能绕过它们，他们只需要一个足够长的对话。

这不是假设。这是 Transformer 处理长上下文时一种可衡量的属性，在研究文献中它有专门的名称，即使你的事故审查模板中还没有。

打开一个生产环境中的智能体，在用户输入第一个字符之前，数一数上下文窗口里已经有了什么。有一段由平台团队负责的系统提示词（system prompt）。有工具定义——可能有 40 个甚至更多——每一个都包含名称、描述、JSON schema、字段级文档以及一些枚举值。有一段检索到的示例，是搜索团队为了提升某个评测指标而加入的少样本（few-shot）示例。有来自信任与安全团队的 6 行安全指令，来自设计团队的 4 行格式规则，还有一段某人在处理故障时添加但没人删除的领域术语表。

加在一起，智能体启动时就有 30,000 个 token 的开销。在连接了三个 MCP 服务器的配置下，这个数字通常会更糟糕——一个被广泛引用的测量结果显示，三个服务器占用了 200,000 token 预算中的 143,000 个，在对话开始前就消耗了 72% 的窗口。这一切都没有错。每一行都是由为了解决实际问题的人添加的。而这恰恰就是上下文窗口正在被摧毁的原因。

演示很顺利。智能体（Agent）回答了那个难题，流畅地串联了四个工具调用，生成的一段文字让全场安静了片刻，直到有人喊出“发布吧”。没人问成本是多少。没人问它运行在哪个模型上，你在成功之前尝试了多少次输入，也没人问当一千个人同时使用它，而不是你周二独自坐在办公桌前时会发生什么。

那场演示刚刚变成了一份契约。不是书面的——而是更糟。它成为了一个隐形的基准线，领导层、销售和客户都会据此来衡量最终发布的产物。而这份契约的条款是由一个你根本负担不起的系统设定的。

演示经济学与生产经济学之间的差距是真实且巨大的，而且在做出承诺之前几乎从未被定价。Gartner 预计到 2027 年，超过 40% 的智能体 AI 项目会因为成本超支而被取消。2026 年 3 月的一项调查发现，78% 的企业已经启动了智能体试点项目，但只有 14% 将其扩展到了全公司范围。试点失败并不是因为技术行不通，而是因为那个行得通的版本从来就不是任何人能够部署的版本。