778 篇博文 含有标签「llm」

关于 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% 将其扩展到了全公司范围。试点失败并不是因为技术行不通，而是因为那个行得通的版本从来就不是任何人能够部署的版本。

每一个成熟的 AI 团队构建其评估套件的方式都如出一辙，而且几乎没有人会公开说出那个潜台词。生产环境中出现了一个故障。有人写了一份复盘报告。一名工程师将该事故提炼为一个测试用例，将其添加到评估套件中，于是仪表盘再次变绿。重复这个循环一年，你就会拥有几百个案例、一个令人满意的通过率，以及一个足以让你在演示幻灯片上感到无比安心的数字。

潜台词是：那个评估套件其实是一个博物馆。每一件展品都是团队已经挺过来的故障类别。98% 的通过率证明了你的系统可以抵御过去 —— 抵御那些已经发生过的特定破坏方式 —— 而对于模型迁移、提示词编辑或用户行为转变即将引入的新型故障模式，它几乎给不出任何参考。评估集是一个披着先行指标外衣的滞后指标。

每一个具有韧性的 LLM 设计在配置中都有一行代码指定了一个备选模型。它之所以存在，是因为有人在设计评审中提出了正确的问题——“如果主模型宕机了怎么办？”——而另一个人用一个 fallback: 键回答了这个问题。大家都点头表示赞同。架构图上多了一个带有虚线箭头的第二个框。合规文档中也增加了一句关于优雅降级的描述。

然后，再也没有人碰过它。

备选模型是大多数生产环境 AI 系统中被断言得最自信、但演练最少的组件。它被命名、被记录、被画在图中——而在它真正承载流量的那一天，也是它第一次遇到真实请求的一天。你并没有建立安全网。你只是构建了第二个断裂强度未知的模型，而你将在最糟糕的时刻发现那个极限。

每个成熟的 AI 系统都会配备回退方案（fallback）。当主模型被限流时，路由到更廉价的模型。当服务商返回 5xx 错误时，提供缓存的答案。当置信度低于阈值时，回退到手写的启发式规则（heuristic）。架构图中有一个清晰的小分支，标注为“降级模式”（degraded mode），每个人都因此感到更安全。

令人不安的部分在于：那个分支是系统中几乎从未运行过的唯一代码。主路径每天执行数百万次，并经过大量流量的调试、性能分析和实战测试。回退路径几乎从不执行——直到某天，它在负载下、在事故期间、在三名工程师看着仪表盘变红时，突然为所有人同时执行。

一个你不练习的回退方案并不是冗余。它是一个不受监控的第二系统，其“首秀”在统计学上注定会发生在最糟糕的时刻。

看看大多数智能体（Agent）评测集是从哪里来的。有人构建了智能体，向团队演示，演示成功了，于是演示脚本就变成了评测套件。那些通过评审的案例，正是有人已经亲眼看到它们运行成功的案例。评测集在构建之初，几乎就是“快乐路径”（Happy path）的录音——即在截屏当天成功运行的那一段工具调用序列。

所以，当仪表盘显示智能体得分为 94% 时，它实际上是在说：它通过了我们能想象到的案例。它完全没有提及搜索 API 在多步计划中途返回 429 错误的情况，或者用户推翻了两轮前设定的约束的情况，亦或是检索结果为空，智能体必须在胡乱猜测和承认不知道之间做出选择的情况。这些情况并非没有通过你的评测。它们压根就没在评测里。

这就是黄金路径偏见（Golden-path bias），除非你刻意对抗，否则它就是智能体评测套件的默认形态。解决方法不是增加案例数量，而是增加不同种类的案例——这些案例应根据失败模式（Failure mode）来选择，从生产环境中收集，并针对刻意引入的故障进行压力测试。

内部 API 依赖于一种默契而存在：没人会写下契约，因为每个人都已经心知肚明。那些碰巧存在的字段、调用者在暗地里解析的报错、返回空列表而非 404 的 200 响应 —— 这些都是关键的承重行为。而维系这些行为的基础是，你可以叫出每个调用者的名字，并在做出任何更改之前通过 Slack 联系他们。这种安排一直有效，直到它失效的那天。

当你将一个智能体（Agent）连接到该 API 的那天起，这种默契就失效了。这并非因为智能体怀有恶意或粗心大意，而是因为智能体是一个你无法触及的调用者。它没有 Slack 账号。它没有阅读你的迁移说明。它依赖于从示例载荷或 Schema 快照中吸收的响应形态，并且在你早已更新版本后，它仍会长期依赖这些形态。

一个令人不安的事实是，“内部”从未是 API 本身的属性。它其实是调用者列表的属性。将列表缩减到你认识的人，API 就是内部的；一旦增加一个你无法协调的参与者，API 就是公共的 —— 这意味着你需要承担“公共”一词所暗示的所有严谨规范，尽管你并没有构建任何本应具备的基础设施。

弃用通知看起来人畜无害。它以更新日志或邮件中一段平静的文字形式出现：该模型快照将在几个月后的某个日期从 API 中移除，这里是推荐的替代方案，感谢你与我们一起构建。其中暗含的工作量似乎只是一行代码的改动 —— 换掉模型字符串，重新部署，搞定。

这种设想是错误的，而且错得很昂贵。模型字符串是你损失的最小的东西。真正随着旧模型一起消失的，是你花了六个月调优的提示词（prompt） —— 每一个针对边缘案例的补丁、每一个重新排序的指令、每一个你因为那个特定模型会有特定烦人行为而添加的“仅以有效的 JSON 响应，不要用 Markdown 包装”。这些都不是可移植的。从统计学意义上讲，它是针对一个模型的行为进行拟合的。替代模型并不是“缺陷对缺陷”兼容的，因此这种拟合不再成立。

模型生命周期的结束是一个迁移项目。如果把它仅仅视为一次配置更改，你就会在生产环境中、在新模型上通过真实流量发现其中的差异。

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

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

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

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

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

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