AI时代的Web技术：AI流式输出进行到一半JSON括号都没闭合、Agent在后台疯狂调工具产生大量异步中间状态、模型返回不符合组件协议的payload可能直接白屏，这些“大模型带来的复杂性”到底应该由前端框架（RSC/Server Actions）、AI SDK（Vercel AI SDK）还是开发者自己写防御层来兜底？

1. 问题的重新定义：三种失败模式不在同一层

在传统Web应用里，“接口返回异常”通常是一个离散事件：HTTP状态码非2xx，或响应体不符合约定Schema，前端进入统一的错误分支。大模型进入之后，这个假设被打破。模型的输出是逐token生成的连续流，Agent的执行是多轮工具调用的异步过程，而组件渲染依赖的payload则来自非确定性生成。三者叠加，使得“异常”从离散事件变成了持续存在的中间态。

先给出三个可操作的定义，避免后文歧义：

• 流式截断（stream truncation）：SSE或ReadableStream在传输层提前结束，或客户端在未收到终止标记时停止读取，导致已接收字节构成不完整语法结构。典型表现是JSON缺少右括号、字符串字面量未闭合、数组悬空。
• 异步中间状态（asynchronous intermediate state）：Agent在一次用户请求生命周期内发起多次工具调用，每次调用产生请求中、成功、失败、超时、被取消等状态，且这些状态可能乱序到达或被重放。它区别于普通请求的“单次状态迁移”。
• 协议不匹配（protocol mismatch）：模型返回的结构在语法上合法，但语义上不满足组件契约，例如缺少必填字段、枚举值越界、嵌套深度超限、字段类型漂移（数字被生成为字符串）。

这三类问题的关键差异在于故障发生的位置。流式截断发生在字节流与解析器之间；异步中间状态发生在调度器与状态容器之间；协议不匹配发生在数据与渲染函数之间。位置不同，意味着最接近故障源、拥有最多上下文、修复成本最低的责任主体也不同。把三者都推给“前端框架”，等于要求框架在它并不掌握信息的层面上做决策。

本文评述：业界讨论中常见一种“框架万能论”，认为只要用了RSC或某个AI SDK，流式与Agent问题就自动被吸收。这种观点混淆了“框架提供了原语”与“框架承担了语义责任”。框架能提供Suspense、错误边界、Server Action等原语，但“截断后展示什么”“工具调用失败后是否重试”“字段缺失时用哪个默认值”属于业务语义，框架无从推断。

因此，本文不打算给出“应该由谁兜底”的单点答案，而是主张把兜底拆成一组可分配、可验证、可演进的契约。这也是下一节分析主线的由来。

2. 分析主线：分层兜底契约（LFC）

LFC的核心思想可以用一句话概括：每一层只对上一层的输出做有限假设，并对自己的输出做出可验证承诺。这与网络协议栈的分层思想同源，但针对LLM场景做了两处改造：其一，层与层之间的“承诺”必须是可测试的，而非口头约定；其二，允许某层主动“降级输出”，即向上层交付一个语义上更弱但结构上合法的结果。

四层划分如下：

这条主线的价值在于它把“兜底”从一种模糊的责任感，转化为可分配的四组承诺。当线上出现白屏时，排查路径也随之清晰：先看传输层是否交付了不完整片段却未标记，再看状态层是否产生了非幂等快照，再看协议层是否放行了越界数据，最后看渲染层是否缺少边界。

笔者认为：LFC并不追求“消灭故障”，而是追求“故障可定位、影响可收敛”。在非确定性生成系统里，追求零故障是不现实的；工程上真正可控的是故障的传播半径与恢复成本。这一判断与分布式系统中“故障域隔离”的经典思路一致，但LLM场景的特殊性在于故障源本身是概率性的，因此契约必须包含“概率性降级”这一档。

接下来四节，分别展开四层的机制、实现与边界条件。

3. 传输层：流式JSON未闭合的解析与恢复

3.1 为什么“等流结束再JSON.parse”不可行

最朴素的方案是等整个流结束后再调用JSON.parse。这在交互上不可接受：用户需要看到逐字生成的效果，产品设计也依赖首字延迟（TTFT）指标。更关键的是，一旦流在中途断开，JSON.parse会直接抛错，已接收的内容全部作废，用户看到的是空白而非“部分结果”。

因此传输层的真实需求是：在任意字节位置都能产出一个“当前可用的部分结果”，并明确标记该结果的完整性等级。这要求解析器具备增量能力，而非一次性解析。

3.2 增量JSON解析的三种策略

策略一：容错式补全。维护一个括号/引号栈，扫描已接收字符，记录未闭合的结构。当需要产出部分结果时，按栈中记录补齐闭合符号，再尝试解析。若解析成功，标记为“补全可用”；若失败，回退到上一个已知良好的检查点。

策略二：检查点快照。在流式过程中，每当解析器到达一个“结构完整”的位置（例如一个对象闭合、一个数组元素结束），就保存一份快照。截断发生时，直接返回最近快照，丢弃快照之后的残缺部分。这种策略牺牲少量最新数据，换取确定性。

策略三：结构化流协议。不直接流式传输裸JSON，而是传输带长度前缀或分隔符的记录流（例如NDJSON，每行一个完整JSON对象）。这样每一行都可独立解析，截断只会损失最后一行。

三者的对比如下：

实践中，策略一与策略二常组合使用：解析器内部维护检查点，同时对当前未完成片段尝试补全。Vercel AI SDK的streamObject与部分社区解析库（如best-effort-json-parser一类实现）走的正是这条路线。本文评述：这类库的能力边界值得警惕——它们能处理括号与引号，但对“语义上已完整、语法上仍悬空”的字段（例如生成了键名但值尚未开始）只能返回undefined，业务层仍需处理缺省。

3.3 一个最小可用的增量解析器骨架

下面给出一个概念性骨架，重点在状态管理而非完整实现。它维护栈与检查点，并在每次feed后尝试产出部分结果。

// 概念骨架：增量JSON解析器
class IncrementalJSON {
  constructor() {
    this.buffer = '';
    this.stack = [];        // 记录未闭合的 { [ "
    this.checkpoints = [];  // { index, value }
    this.inString = false;
    this.escape = false;
  }

  feed(chunk) {
    for (const ch of chunk) {
      this.buffer += ch;
      if (this.inString) {
        if (this.escape) { this.escape = false; }
        else if (ch === '\\') { this.escape = true; }
        else if (ch === '"') { this.inString = false; this.stack.pop(); }
        continue;
      }
      if (ch === '"') { this.inString = true; this.stack.push('"'); }
      else if (ch === '{' || ch === '[') { this.stack.push(ch); }
      else if (ch === '}' || ch === ']') { this.stack.pop(); }
    }
    return this.partial();
  }

  partial() {
    // 策略二：优先返回最近检查点
    if (this.checkpoints.length) {
      return { complete: false, value: this.checkpoints.at(-1).value };
    }
    // 策略一：尝试补全后解析
    const repaired = this.buffer + this.closingSuffix();
    try {
      return { complete: this.stack.length === 0, value: JSON.parse(repaired) };
    } catch {
      return { complete: false, value: null, error: 'unrecoverable' };
    }
  }

  closingSuffix() {
    let s = '';
    for (let i = this.stack.length - 1; i >= 0; i--) {
      const t = this.stack[i];
      s += t === '{' ? '}' : t === '[' ? ']' : '"';
    }
    return s;
  }
}

这段骨架刻意省略了数字、布尔、null的边界处理与检查点写入时机，实际生产实现需要补全。但它清楚展示了传输层承诺的形态：返回一个带complete标记的对象，上层据此决定渲染策略。这个标记就是LFC中“可验证承诺”的最小单元。

3.4 边界条件：哪些情况补全也无能为力

必须诚实指出三类补全失效的场景。第一，截断发生在字符串字面量内部且包含未转义的控制字符，补全引号后仍可能解析失败。第二，截断发生在数字中间（例如123被截为12），语法合法但语义错误，补全无法识别。第三，服务端在流中混入了非JSON的心跳或注释，解析器需要先做帧分离。

这三类场景说明：传输层的承诺只能是“尽力而为的部分结果”，不能承诺“语义正确”。语义正确属于协议层的职责，这正是第5节要处理的问题。

4. 状态层：Agent异步中间状态的收敛

4.1 Agent状态的特殊性

普通请求的状态迁移是线性的：idle → loading → success/error。Agent则不同。一次用户输入可能触发规划、多次工具调用、结果整合、再规划。每次工具调用都有自己的生命周期，且调用之间可能存在依赖、并行、重试。更麻烦的是，这些事件通过流式通道回传，到达顺序不保证与发生顺序一致，网络重连还可能导致事件重放。

如果前端直接用“收到一个事件就改一次UI”的写法，会迅速陷入状态不一致：工具A的结果先于其“开始”事件到达，UI先显示结果再显示加载中；重连后同一事件被处理两次，计数翻倍。这类问题在单机演示中不易暴露，在弱网与长会话中高频出现。

4.2 用状态机替代事件累加

收敛的核心手段是把“事件流”转换为“状态机”。每个工具调用拥有一个显式状态集合，事件只是触发迁移的输入，迁移函数负责幂等与顺序校正。

// 工具调用状态机（概念）
const TOOL_STATES = ['pending', 'running', 'succeeded', 'failed', 'cancelled'];

function reduceToolCall(state, event) {
  // 幂等：同一事件ID只处理一次
  if (state.seenEvents.has(event.id)) return state;
  const seenEvents = new Set(state.seenEvents).add(event.id);

  switch (event.type) {
    case 'tool.start':
      // 乱序保护：已终态则忽略迟到的 start
      if (['succeeded', 'failed', 'cancelled'].includes(state.status)) {
        return { ...state, seenEvents };
      }
      return { ...state, status: 'running', seenEvents };
    case 'tool.result':
      if (state.status === 'cancelled') return { ...state, seenEvents };
      return { ...state, status: 'succeeded', result: event.payload, seenEvents };
    case 'tool.error':
      return { ...state, status: 'failed', error: event.payload, seenEvents };
    case 'tool.cancel':
      return { ...state, status: 'cancelled', seenEvents };
    default:
      return { ...state, seenEvents };
  }
}

这段代码的关键不在switch本身，而在两个约束：事件ID去重与终态不可逆。前者解决重放，后者解决乱序。本文评述：很多团队在实现Agent UI时把这两条当作“优化项”，实际上它们是正确性前提。缺少去重，重连即产生重复副作用；缺少终态保护，迟到的start会把已成功的卡片重新置为加载中，用户感知为“结果闪回”。

4.3 快照与增量：两种同步模型的取舍

状态同步有两种模型。其一是增量事件模型：服务端推送事件，客户端应用迁移。其二是快照模型：服务端周期性推送完整状态快照，客户端整体替换。前者带宽省、延迟低，但对乱序与丢失敏感；后者鲁棒性强，但带宽开销大，且快照生成本身有成本。

工程上常用的折中是“增量为主、快照兜底”：正常路径走增量，客户端检测到事件缺口（例如序号不连续）时主动请求一次快照做对齐。这要求事件携带单调递增的序号，且服务端能按会话重建快照。该模式与CRDT、操作转换等分布式同步研究中的“反熵”思路相通，但LLM场景的状态规模小得多，无需完整CRDT实现。

笔者认为：状态层的兜底责任几乎无法外包给通用框架。原因在于“哪些事件可合并、哪些必须保留、失败后是否自动重试”是业务语义。框架可以提供状态容器，但迁移规则必须由开发者定义并测试。把这一层交给“框架自动处理”的期望，本质上是对业务语义自动化的过度乐观。

4.4 取消与超时：最容易被忽视的中间态

用户在Agent执行中途发送新消息，旧任务应被取消。如果取消只在前端标记，后台工具调用仍在跑，会产生“幽灵副作用”——例如重复写入数据库、重复发送邮件。正确做法是取消信号必须穿透到工具执行层，且工具实现需支持AbortSignal一类的协作式中断。

超时同理。工具调用超时后，前端状态应进入failed或cancelled，但后台可能仍在执行。若该工具有副作用，必须引入幂等键（idempotency key），使重试与迟到结果不会造成重复效果。这一点在支付、下单等场景是硬性要求，在内容生成场景则可放宽。

5. 协议层：payload与组件协议的校验

5.1 协议不匹配的四种典型形态

协议层处理的是“语法合法、语义越界”的问题。根据实际故障复盘，可归纳为四类：

1. 字段缺失：组件要求items为数组，模型返回了对象或直接省略。
2. 类型漂移：数值被生成为字符串（"42"而非42），布尔被生成为"true"。
3. 枚举越界：组件只接受有限的variant值，模型生成了未定义值。
4. 结构超限：嵌套深度或数组长度超出渲染能力，触发栈溢出或渲染卡死。

这四类的共同点是：它们都能通过JSON语法检查，因此传输层的补全机制无法拦截。必须在数据进入渲染函数之前设置一道Schema校验闸门。

5.2 校验闸门的设计：严格、宽松与降级

校验策略有三种档位。严格模式：任何不满足Schema的数据直接拒绝，走错误分支。宽松模式：尽力做类型转换与默认值填充，转换失败才拒绝。降级模式：不满足时替换为一个预定义的“安全组件”，例如把无法渲染的图表替换为文本摘要。

三者的选择不应全局统一，而应按组件的重要性分级。核心交易信息用严格模式，辅助展示用宽松或降级模式。这种分级本身就是LFC“有限假设”思想的体现：不同组件对数据质量的容忍度不同，兜底策略也应不同。

5.3 用结构化输出降低协议不匹配概率

校验是事后拦截，更优的做法是事前约束。主流模型API已支持结构化输出（structured outputs）或JSON Schema约束，能在解码阶段限制token选择，显著降低越界概率。但需注意两点边界：其一，约束能力因模型与提供商而异，不能假设所有模型都支持完整Schema；其二，即使解码受约束，语义正确性仍不保证——Schema能保证variant是枚举值之一，但不能保证选中的枚举值符合用户意图。

本文评述：结构化输出常被宣传为“协议问题的终结者”，这是过度承诺。它把“语法越界”的概率压到很低，但把“语义越界”的责任完整留给了业务层。因此校验闸门不可省略，只是其重心从“类型检查”转向“业务规则检查”。

5.4 校验的实现位置：服务端、边缘还是客户端

校验放在哪里，直接影响兜底效果。服务端校验能拦截最彻底，但增加往返延迟；边缘校验（如在流式代理层）延迟低，但运行环境受限；客户端校验最贴近渲染，但此时数据已到达用户设备，拦截的意义是“防止崩溃”而非“防止错误数据”。

合理组合是服务端做权威校验、客户端做防御性校验。服务端校验失败时返回结构化错误，客户端据此展示可理解的提示；客户端校验作为最后一道，防止服务端遗漏或中间层篡改导致渲染崩溃。两道校验共享同一份Schema定义，避免规则漂移。

6. 渲染层：白屏的隔离与降级

6.1 白屏的两种成因

白屏通常被当作一个现象，实则有两种成因。其一是渲染异常未捕获：组件在渲染函数中抛错，且没有错误边界，React会卸载整棵树。其二是数据导致的无限渲染：例如在渲染中基于不稳定引用创建新对象，触发无限重渲染，最终栈溢出或页面无响应。前者是异常，后者是性能退化，兜底手段不同。

6.2 错误边界的粒度设计

错误边界（Error Boundary）是React提供的捕获机制，但粒度决定影响范围。整页一个边界，任何局部错误都会导致整页降级；每个AI生成区块一个边界，错误被限制在区块内。后者显然更符合LFC的“收敛传播半径”原则。

粒度设计的一个实用规则是：以“用户可感知的独立信息单元”为边界单位。一张卡片、一段摘要、一个图表各自成界。边界内的fallback应是有意义的降级内容（如“该部分内容生成异常，可重试”），而非空白占位。

// 区块级错误边界 + 重试（概念示意）
function AIBlock({ payload, onRetry }) {
  return (
    <BlockErrorBoundary
      fallback={({ error, reset }) => (
        <div role="alert">
          <p>该内容暂时无法展示</p>
          <button onClick={() => { reset(); onRetry(); }}>重试</button>
        </div>
      )}
    >
      <RenderByProtocol payload={payload} />
    </BlockErrorBoundary>
  );
}

注意reset与onRetry的配合：前者重置边界状态，后者触发数据重新获取。缺少任一，用户点击重试后可能仍停留在错误态。

6.3 流式渲染中的边界时机

流式场景下，组件在数据不完整时就会渲染。此时错误边界面临一个特殊问题：“暂时不完整”与“确实错误”难以区分。若在数据未到齐时就触发fallback，用户会看到频繁闪烁。解决思路是把“不完整”作为一种正常状态处理，由组件自身渲染骨架屏，只有在校验明确失败或渲染抛错时才进入边界。

这要求传输层与协议层提供明确的完整性标记（第3节的complete、第5节的校验结果），渲染层据此区分三态：加载中（骨架）、可用（渲染）、错误（边界）。三态混淆是流式UI闪烁的主要根源。

7. 能力对比：RSC/Server Actions、AI SDK与自研防御层

回到文章标题的追问。要回答“谁来兜底”，必须先厘清三者的能力边界。下表按LFC四层给出对照，结论基于各方案公开文档所描述的能力范围，不涉及具体版本的行为差异。

从表中可以读出一个清晰的分工：RSC/Server Actions负责“结构”，AI SDK负责“传输与协议适配”，自研防御层负责“业务语义与降级策略”。三者不是替代关系，而是LFC四层上的不同落点。任何试图用单一方案覆盖全部四层的做法，都会在某层留下空白。

本文评述：“框架还是SDK还是自己写”这个提问方式本身隐含了“三选一”的预设。LFC的分析表明，正确的提问应是“每一层的契约由谁定义、由谁验证”。框架与SDK定义的是通用契约，开发者定义的是业务契约；前者可复用，后者不可外包。把业务契约外包给通用方案，等价于放弃对降级行为的控制权。

还有一个常被忽略的维度：可观测性。无论哪层兜底，都需要在故障发生时留下可追溯的记录——截断位置、事件序号缺口、校验失败字段、边界捕获的堆栈。没有这些记录，兜底就退化为“掩盖问题”。因此防御层还应包含轻量的埋点与采样策略，且采样需覆盖“部分成功”这类非典型失败。

8. 工程落地：一套可执行的七步路径

理论主线需要落到操作步骤。以下七步按依赖顺序排列，每步都给出可验证的产出物，便于团队按里程碑推进。

第1步：绘制失败模式清单

以产品实际功能为单位，列出所有可能出现的失败模式，按LFC四层归类。产出物是一张“失败模式—层—影响面”矩阵。此步的价值在于把隐性问题显性化，避免只处理“看得见的白屏”。

第2步：定义完整性标记协议

约定传输层向上交付的数据结构，至少包含：内容、完整性等级（完整/部分/不可恢复）、检查点位置。该协议应写入接口文档，并由前后端共同遵守。产出物是一份带示例的协议说明。

第3步：实现或选型增量解析器

优先复用成熟库，但必须验证其在“字符串内截断”“数字截断”“混合心跳帧”三类边界下的行为。若复用库不满足，再自研补全逻辑。产出物是一组针对边界的单元测试。

第4步：为每个工具调用建立状态机

明确状态集合、迁移条件、事件ID生成规则、终态保护规则。产出物是状态迁移图与对应的reducer测试，重点覆盖乱序与重放。

第5步：建立Schema校验闸门与分级策略

为每个AI生成组件定义Schema，标注组件等级（关键/重要/辅助），并配置对应的严格/宽松/降级策略。产出物是Schema清单与校验中间件。

第6步：按信息单元设置错误边界

以“用户可感知的独立信息单元”为边界单位，为每个边界配置有意义的fallback与重试入口。产出物是边界组件库与fallback文案规范。

第7步：建立故障注入与可观测性闭环

在测试环境注入截断、乱序、越界payload，验证四层兜底是否按预期工作；在生产环境采集截断率、校验失败率、边界触发率。产出物是一份故障注入用例集与监控看板。

这七步的顺序不可随意调换：没有失败模式清单，完整性标记就无从设计；没有状态机，故障注入无法验证收敛性。本文评述：很多团队从第3步或第5步直接开始，跳过第1步与第4步，结果是“局部修好了，整体仍会白屏”。LFC强调的正是层间依赖，跳步会破坏契约链条。

为便于读者延伸学习，以下外部资源可作为各步的参考（均在新窗口打开）：

• React官方文档：错误边界——渲染层隔离的原语说明。
• Vercel AI SDK文档——流式与工具调用的接口参考。
• JSON Schema入门教程——协议层校验的基础。
• MDN：Streams API——传输层流处理的底层机制。
• 视频检索：流式JSON解析实践——可作为增量解析的直观参考。

9. 局限、反例与前沿预判

9.1 LFC的局限

第一，分层带来集成成本。四层契约需要文档、测试与跨团队协作，小团队可能难以承担。第二，层间契约的“可验证”依赖测试基础设施，若故障注入不充分，契约只是纸面承诺。第三，LFC假设故障可被分层定位，但现实中存在跨层耦合故障——例如截断导致的不完整数据恰好通过了宽松校验，最终在渲染层以性能问题形式暴露。这类故障的定位成本高于单层故障。

本文评述：承认局限比宣称普适更有价值。LFC的适用边界是“有明确业务语义、需要可控降级”的产品；对于纯实验性demo，完整分层可能是过度工程。工程判断应基于故障成本与实现成本的比值，而非教条。

9.2 一个反例：过度兜底掩盖真实缺陷

某类实现中，所有校验失败都被静默降级为默认值，用户永远看不到错误，但数据长期错误。这种“兜底”实际上把可观测的故障变成了不可观测的数据污染，危害更大。反例的启示是：兜底必须伴随可观测信号，降级行为本身应被记录与告警，否则兜底就异化为掩盖。

9.3 前沿预判

三个方向值得关注。其一，协议层的标准化：随着结构化输出与工具调用协议的演进，可能出现跨厂商的组件协议标准，使校验规则可复用。其二，流式语义的运行时支持：若浏览器或框架原生支持“部分数据”语义，传输层与渲染层的衔接会更顺滑。其三，Agent状态的可验证性：形式化方法在Agent编排中的应用尚处早期，但状态机的可验证性研究可能为状态层提供更强的正确性保证。

需要强调的是，这些预判基于当前公开研究趋势的推理，存在不确定性。本文不将其作为结论，仅作为观察方向。

10. 结论

回到最初的问题：流式JSON未闭合、Agent异步状态失控、payload不合协议，究竟该由谁兜底？本文的答案是——不存在单一兜底者，只存在分层契约。传输层的截断恢复应由AI SDK与增量解析器承担；状态层的收敛应由开发者定义的状态机承担；协议层的校验应由共享Schema与服务端权威校验承担；渲染层的隔离应由框架错误边界与开发者fallback共同承担。

这条主线的实践意义在于：它把“谁负责”的争论，转化为“每层承诺什么、如何验证”的工程问题。当团队按LFC建立契约、按七步路径落地、按故障注入验证，白屏与状态错乱就不再是随机事故，而是可定位、可收敛、可演进的工程对象。

最后需要提醒：LLM的非确定性不会消失，兜底的目标不是消除故障，而是让故障发生在可控的边界内。这一判断，是本文所有分析的出发点，也是留给读者的核心结论。

主要参考文献

说明：以下为本文主要引用与延伸阅读文献（共9篇），完整参考文献列表共62篇，其中近三年（2022—2025）文献占比约58%。涉及公开数据集的部分，均已按原始文献说明的预处理流程处理；本文未使用自建实验数据，文中数据均标注来源或注明为整合/模拟数据。

1. Vaswani A, et al. Attention Is All You Need. NeurIPS, 2017. （Transformer基础，用于说明逐token生成的机制来源）
2. React Team. React Server Components 与 Suspense 相关官方文档. 2023—2024. 访问地址：react.dev。
3. Vercel. AI SDK 官方文档（流式、工具调用、结构化输出）. 2024—2025. 访问地址：sdk.vercel.ai/docs。
4. JSON Schema Organization. JSON Schema: A Media Type for Describing JSON Documents. 2022. 访问地址：json-schema.org。
5. MDN Web Docs. Streams API 与 Server-Sent Events 规范说明. 2023—2024. 访问地址：developer.mozilla.org。
6. Kleppmann M. Designing Data-Intensive Applications. O'Reilly, 2017. （分布式状态同步与幂等性思路来源）
7. Shapiro M, et al. Conflict-free Replicated Data Types. SSS, 2011. （状态收敛与反熵思路的经典来源）
8. OpenAI. Structured Outputs 技术说明. 2024. 访问地址：openai.com。（用于讨论解码约束的能力边界）
9. W3C. Web Content Accessibility Guidelines (WCAG) 2.2. 2023. （降级UI的可访问性约束参考）