720 篇博文 含有标签「llm」

你的多智能体（multi-agent）流水线运行结束了。没有抛出任何异常。编排器报告成功。然而，答案却是错的，而且错得离谱 —— 执行器跳过了两个步骤，总结器将三个部分合并成了一个风马牛不相及的结论，输出看起来像是完全来自另一个任务。没有堆栈跟踪可以遵循，没有错误代码可以搜索。只有一个悄无声息的错误结果。

这就是输出耦合陷阱（output coupling trap）。这不是模型质量问题，而是接口工程（interface engineering）问题，也是多智能体系统在生产环境中发生隐形故障的首要原因。

想象一个处理用户支持工单的多智能体流水线。智能体 A 读取工单历史并认为用户是一个需要进阶回复的高级用户。智能体 B 在并行的调用中读取同样的工单历史，却认为用户是一个需要分步引导的初学者。两个智能体同时完成并将输出交给组合智能体——而现在，组合智能体必须调和这两个对同一个人的根本不兼容的心理模型。

这并非罕见的极端情况。分析生产环境多智能体故障的研究发现，36.9% 的失败是由智能体间的失调引起的：冲突的输出、移交过程中的上下文丢失，以及独立得出的不兼容结论。一致性鸿沟（consistency gap）——即并行 LLM 调用对共享实体产生相互矛盾的倾向——是智能体系统中被低估最多的失效模式之一。

有一件事看似不该令人意外，但实际上出乎意料：当你告诉智能体"避免犯错"与"优先保证准确性"时，你给出的并不是同一条指令。在模糊决策点上，可观测到的行为存在可测量的差异——以损失规避框架提示的智能体更多地回避、升级和放弃端到端任务完成；以收益寻求框架提示的智能体完成更多任务，但在决策边界处会引入更多错误。这种差异并非哲学层面的；它会体现在评估日志中。

这就是智能体的行为经济学，而大多数工程团队尚未系统地思考过这个问题。他们把系统提示当作文档来写——描述智能体是什么——而实际上，系统提示是一种决策塑造工具，无论作者是否有意为之，它都在编码一种风险立场。

当成本飙升、模型下线通知或竞争对手的基准测试迫使你更换 Provider 时，工程团队通常会在能力基准测试上评估候选模型，并将其视为迁移计划的全部。这个过程大约能捕获一半的问题。另一半并非能力问题，而是行为问题：那些不可见的格式习惯、拒绝模式、序列化怪癖以及输出约定——你的生产代码在数月迭代中已悄悄将其内化。

能力基准告诉你新模型能否完成任务。行为指纹告诉你你的代码库能否承受这次替换。

季度开始三周后，生产告警触发了。核心任务的准确率下降了八个百分点。你打开仪表盘，立即注意到同一个发布窗口内落地了三件事：上下文长度从 8k 增加到 32k token、模型版本从 gpt-4-turbo-preview 升级到 gpt-4o，以及基础设施团队为提升吞吐量推送的批处理大小变更。三项变更中没有一项单独被认为是高风险的。合在一起，它们制造了一个无法干净解决的调试难题。

欢迎来到发布顺序问题。

你正在为用户从未阅读过的 Token 付费。这不是 Bug，也不是供应商的价格把戏，而是因为你的系统正按设计运行——在每次请求中触发后台推理任务。这些任务在白板上看起来很聪明，却在每次请求中烧掉了真实的预算。

这就是隐形算力税（Shadow Compute Tax）：推理支出中用于推测性、过早触发或结构上保证永远不会到达用户的 AI 工作的那部分。在你的监控面板里，它几乎是隐形的——直到突然变得显眼为止，而那时它已经被默认为成本模型的一个前提假设。

摘要失败往往是隐性的。你的系统不会崩溃，日志不会标记错误，生成的文本看起来也很连贯——但在压缩过程中的某个地方，对下游任务至关重要的那个事实被丢掉了。RAG 流水线返回了一个自信的答案。多跳推理器得出了一个结论。客服代理给出了建议。所有这些都基于一个不再包含原始约束、例外或答案所依赖的数据点的摘要。

这就是摘要有效性问题：即“与原文保持一致”的摘要与“保留下游任务所需信息”的摘要之间的差距。大多数团队并没有针对此进行度量。他们上线的流水线只验证了摘要的存在，而不是摘要的完整性。

大多数团队发现“零样本墙”（zero-shot wall）的过程都如出一辙：一个新的边界案例导致模型出错，他们向提示词（prompt）中添加一个示例，问题解决了。三个月后，他们已经累积了 40 个示例，消耗了 6,000 个 token 的上下文，性能指标数周没有变化，而那个清楚每个示例来源的提示词工程师刚刚离职了。

少样本提示（Few-shot prompting）非常具有诱惑力，因为它见效快。你观察到一个失败案例，添加一个演示示例，失败就消失了。反馈循环很紧凑，而且胜利感觉是无成本的。你没有注意到的是，随后的每一个示例带来的收益都在递减——到某个阶段，你为了那些几乎可以忽略不计的改进，付出了大量的 token、延迟和认知开销。

这就是“零样本墙”：它不是性能断崖式下跌的硬限制，而是一个收益锐减的区域。在这个区域，上下文学习（in-context learning）对于你的任务已经达到了天花板，剩下的唯一手段就是微调（fine-tuning）。

工程师为多区域 AI 部署做预算时，通常只考虑两个变量：每个区域的基础设施成本和复制开销。而真正被严重低估的，是上线之后才会暴露的三类成本：模型版本不一致导致欧盟集群与美国集群产出不同结果、KV 缓存隔离使 GDPR 区域内每个 token 的生成成本更高，以及重试逻辑将法国用户数据悄悄路由到弗吉尼亚时触发的静默合规违规。

一家德国银行为满足 GDPR 要求，花了 14 个月将一个大型开源模型部署在本地。这并不罕见。真正罕见的是，提出该架构方案的工程师从一开始就理解了合规约束。大多数团队直到事故报告出现才被迫面对这个问题。

我合作过的一个团队花了六个月的时间，将一个系统提示词（system prompt）调整到大约 4000 个 token。这是他们的镇店之宝——通过不断累积边缘情况处理、格式规则、人设指令、回退行为以及十几个 few-shot 示例而精心打造。后来，一名初级工程师加入，问为什么提示词这么长，并用一个下午的时间重写了它。新版本只有 200 个 token。在他们现有的评估集上，它的得分高出了 4 分。运行成本也降低了 40 倍，而且速度明显变快。

这并不是一个关于神奇短提示词的轶事。这是我几乎在每次阅读运行超过一个季度的生产级系统提示词时都会看到的模式。长提示词是随意的累加，而非设计的结果。QA 中出现的每个失效模式都贡献了一个段落。观看演示的每位利益相关者都贡献了一条语气指令。每个“似乎有帮助”的例子都被固定在了底部。结果就是，提示词比它要引导的用户输入还要长，充斥着模型在推理时必须默默解决的内部矛盾，注意力被稀释在各种相互竞争的需求中。

想象一下这个场景：凌晨 2:14，值班工程师的手机嗡嗡作响，你旗舰产品中的 AI 功能正自信地告诉企业客户，他们的账号是“西红柿汤”。模型供应商推送了一个路由变更，你的提示词被静默升级的分词器截断了，或者是检索索引针对一个损坏的 Parquet 文件重新生成了——原因现在还不重要。重要的是，距离有人截图输出并发布到 LinkedIn 只剩 10 分钟。

如果你唯一的对策是“回滚部署并等待 CI”，那你已经输了。标准的流水线回滚从报警到恢复需要 20 到 40 分钟，而糟糕的输出不会在绿色对勾渲染时礼貌地暂停。等到新容器恢复健康时，截图已经在信息流里传开了，支持信箱里塞满了 50 个工单，而你花了 6 个月建立的信任正被那些从未使用过该产品的人审查。

那些能在 5 分钟而不是 5 小时内控制此类事件的团队并不是靠运气。他们在需要之前就构建了一个紧急开关（Kill Switch）——这是一个允许值班工程师在几秒钟内禁用 AI 路径的原语，无需部署，无需合并，也无需任何人触碰生产环境的二进制文件。这篇文章将探讨这种专门针对 AI 功能的原语是什么样的，为什么确定性软件的版本不足以应对，以及在事故发生前的一天必须具备什么条件，才能让响应在事故发生的当晚奏效。

经典的 Bug Bash 是一种为确定性软件量身定制的确定性仪式。十名工程师挤在一个 Slack 频道里两小时，对照着黄金路径流程清单疯狂测试，然后提交带有清晰复现步骤的工单：“点击 X，看到 Y，预期 Z。” 这套方法之所以奏效，是因为被测系统是可复现的——相同的输入，相同的输出，相同的 Bug，次次如此。

如果针对 AI 功能运行完全相同的仪式，你最终会得到 200 张工单，其中 180 张会因为“符合预期的随机波动”而被关闭，同时还会漏掉那 20 张预示着真正的群体性回归（cohort regression）的工单。这种形式不仅陈旧，而且完全错位了。针对基于 LLM 的功能进行 Bug Bash 并不是一场捕捉缺陷的会议。它是一场针对概率分布的抽样练习，如果团队像运行确定性测试那样运行它，就是在收集噪声并将其视为信号。

这篇文章讨论的是如何为随机系统重新设计 Bug Bash——包括流程形式、参与者、分级准则以及什么才算“完成”等方面需要做出哪些改变。