当你的 AI 功能输出错误答案时，第一个问题总是：“是模型的问题吗？”大多数工程师会进行模型评估，运行几个测试提示词，并得出模型看起来没问题的结论。他们通常是对的。模型没问题。故障发生在其他地方——在你的组件相互通信的那些无形接缝处。
这一结论的证据是一致的。对生产环境 RAG 部署的分析显示，73% 的故障是检索故障，而不是生成故障。在多智能体系统中，最常见的故障模式是消息顺序冲突、状态同步间隙和 schema 不匹配——这些都不会出现在任何单组件健康检查中。GPT-4 在处理复杂的提取任务时，产生无效响应的比例接近 12%，这不是因为模型坏了，而是因为模型与下游解析器之间的输出格式契约从未被强制执行。
模型背了锅，边界才是元凶。
扼杀生产系统的三个交接面
每个 AI 流水线都有一组关键的交接面——即一个组件的输出成为下一个组件输入的点。在大多数架构中，有三个交接面主导了故障场景。
工具输出与提示词对接。 当智能体调用工具时，工具返回数据。这些数据被反馈到下一次 LLM 调用中。如果数据轻微格式错误——缺失字段、非预期的类型，或者技术上存在但语义错误的数值——模型通常不会拒绝它。它会继续运行，并基于错误的前提进行自信的推理。系统记录 HTTP 200，延迟看起来正常，响应读起来也很流畅。没有错误产生。只是出现了一个三个迭代周期（sprints）都没人发现的错误答案。
这里的故障模式不是崩溃，而是基于损坏的上下文生成的听起来很有道理的输出。这类静默失败（Silent failures）最难调试，因为每个组件都报告运行健康。
检索到的上下文与生成器对接。 在检索增强系统中，检索器选取 chunk 传递给模型。模型根据这些 chunk 进行生成。这个交接在描述上很简单，但在实践中却很残酷。固定大小的分块（chunking）会在任意边界切断句子、表格和函数。语义搜索无法将“我该如何取消订阅？”与标题为“账户终止政策”的文档匹配。模型接收到十个最近邻结果，即使其中只有两个是相关的，这用噪声稀释了信号。
结果就是模型对每个查询都给出平庸的答案——不是因为它不能推理，而是因为它在根据错误的输入进行推理。检索器在工作，生成器也在工作，但它们之间的接缝出问题了。
结构化输出与下游解析器对接。 你要求模型返回一个 JSON 对象。它返回了 JSON——除了那 12% 的请求，它可能将 JSON 包装在句子中（”没问题！这是你要的数据：{...}”），或者遗漏了必填字段，或者将数值序列化为字符串。你的解析器会对这 12% 的请求抛出异常，静默地吞掉错误的请求，或者——最糟糕的情况——强制转换类型并将语义无效的数据进一步传播到下游。
在解析器输出作为另一个提示词或工具调用的流水线中，这个交接面变得呈指数级危险。一次糟糕的解析会污染随后的每一个步骤。
为什么标准监控无法察觉边界问题
这些故障之所以持续存在，是因为标准监控是以组件为中心的。你对模型调用进行埋点，追踪延迟和错误率，观察 GPU 显存。你对检索器进行埋点，追踪查询时间和命中率。你对工具进行埋点，追踪执行时间和退出码。
每个组件看起来都很健康。每个组件确实都很健康。但系统坏了。
运行健康（Operationally healthy）与行为可靠（Behaviorally reliable）是不同的属性，大多数监控技术栈无法区分它们。一个成功返回十个无关 chunk 的检索器在运行上是健康的。一个在模型期望字符串的地方返回带有 null 值的 JSON 对象的工具在运行上也是健康的。一个在 800ms 内完成并基于损坏上下文生成流畅段落的 LLM 调用在运行上同样是健康的。
故障存在于组件之间的关系中，而不是任何一个组件内部。标准的可观测性工具对组件进行监测，但不监测关系。
还有一个次要问题：交接故障往往是降低质量而非触发错误。崩溃会显示在你的错误率中。而错误的答案则表现为用户流失、支持工单，或者三周后经理发来的一条 Slack 消息。反馈循环很长，信号很弱，且根本原因难以察觉。
梳理你的交接面
第一个实际步骤是让你的交接面显性化。大多数团队对组件如何连接有一个模糊的心理模型——把它画出来，风险集中在哪里就会变得显而易见。
对于流水线中的每一次交接，记录以下三点：
有效的输出是什么样的？ 如果工具应该返回用户记录，请定义确切的 schema：哪些字段是必填的，预期什么类型，哪些范围是有效的。如果检索器应该返回排序后的 chunk，请定义“有效”检索的样子——最低相关性阈值、最大 chunk 数量、预期格式。
故障模式有哪些？ 对于每一次交接，列举上游组件产生下游组件无法处理的输出的各种方式。缺失字段、错误类型、空结果、截断的上下文、预期 JSON 时却返回了 Markdown。在这里保持显性会迫使团队面对那些通常隐含在代码中的假设。
当交接失败时，错误数据流向了哪里？ 系统是抛出错误并停止吗？还是静默返回空结果？或是将损坏的数据传递到下一阶段？最糟糕的结果——也是最常见的结果——是错误数据静默通过。如果你无法回答这个问题，那么你就有了一个未受监控的故障路径。
加固交接的四种模式
一旦映射了这些表面，就有一些具体的方案可以解决最常见的故障模式。
在生成时强制执行输出 Schema，而不只是在解析时。 现代推理 API 提供结构化输出模式，在生成过程中将模型约束在特定的 JSON Schema 内。这与在系统提示词（system prompt）中要求模型生成 JSON 不同——这是采样层面的硬性约束。与事后解析相比，在生成时强制执行 Schema 可以将解析故障减少高达 90%。在流水线需要结构化输出的任何地方都应使用它。
在每个边界进行验证，而不仅仅是在入口点。 一种常见的模式是在 API 边界验证用户输入，然后隐式地信任内部组件的输出。当组件在负载或边缘情况输入下以意外方式交互时，这种模式就会失效。将每一次交接都视为信任边界。验证的成本只有几毫秒；而一个隐性错误在十个步骤中传播的成本则是以天计的调试。
在工具调用中区分技术错误和语义错误。 当工具调用失败时，可能发生了两种截然不同的情况。技术错误（超时、频率限制、网络故障）应该重试——工具本身没问题，只是执行失败了。语义错误（调用了错误的函数、参数无效、类型不匹配）不应该重试——模型需要重新考虑其方法。重试语义错误的系统会产生无限循环并加剧错误状态。重试逻辑需要在决定如何处理之前对错误类型进行分类。
让上下文溢出显现出来。 Token 限制会导致隐性截断。模型到达上下文窗口的末端，早期的信息丢失，而系统继续运行，仿佛什么都没发生。API 响应中的 finish_reason=length 就是信号——大多数流水线并不检查它。当你检测到截断的补全时，这并不是一次成功。将其记录为一个独立事件，针对持续的截断率发出告警，并考虑流水线是否需要在上游更主动地截断上下文，而不是依赖模型来优雅地处理溢出。
可观测性差距
过去两年中 LLM 可观测性工具的出现是对这一问题的直接回应。市场正在快速增长——2026 年为 26.9 亿美元，预计到 2030 年将达到 92.6 亿美元——因为团队意识到单个组件的指标无法解释系统行为。
使可观测性工具对交接故障特别有用的，是追踪级（trace-level）的可视化：能够针对任何给定的请求，检查跨越每个边界的准确数据。不是“工具调用成功了”，而是“这是工具返回的内容，这是之后的提示词”。不是“检索器返回了结果”，而是“这是这些分块、它们的相关性分数，以及传递给模型的准确上下文”。
扁平的日志无法提供这些。你需要结构化的追踪，将跨组件边界的输入和输出联系起来，并使每个交接处的数据可供检查。没有这个，你只能看到出错了，但看不出在哪出的错。
开始工作
处理得最好的工程师不会从添加可观测性或编写验证层开始。他们从绘图开始。他们研究架构，列出每个组件输出变为另一个组件输入的点。然后他们针对每一个点询问：当上游组件产生了一些细微的错误时会发生什么？
这种练习能快速找出高风险的交接。在做出财务决策的流水线中，将用户数据返回给 agent 提示词的工具是高风险的。一个结构化输出进入解析器，再进入另一个模型调用的过程是高风险的。一个其分块是事实主张唯一依据的检索器是高风险的。
一旦地图存在，投资的优先级就变得清晰了。故障影响最大且验证最少的边界会被首先加固。生成时的 Schema 强制执行、解析时的验证、前五个交接表面的结构化追踪。
系统很少在模型处崩溃。找到交接点。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
