<!-- title: 首字延迟战：Agent流式终局横评 -->

到 2026 年中，Agent 框架的竞争焦点悄然迁移：不再是"能不能跑通工具调用"，而是"用户点下回车后，多久看到第一个字"。AWS 在 Agentic AI Lens 里把这件事写成了硬性最佳实践（AGENTPERF02-BP04）——面向用户的 Agent 应该用**首字延迟（TTFT）**而非端到端延迟来评判，并把它作为独立 KPI。与此同时，LangChain 在 2026 年 5 月提出"从 Token 流到 Agent 流"：单模型单流的时代结束了，一个 Deep Agents 运行会派生子智能体、工具调用、人工审批、状态变更、媒体生成，前端需要的是**带类型的事件流**，而不是一串拼接的 token。协议层也在 2026 年完成洗牌：MCP 3 月规范（2025-03-26）用 Streamable HTTP 替换了 HTTP+SSE，ACP 并入 A2A，AG-UI 成为前端事件词汇表。本文以"流式"为切口，横评六大框架与三大协议的终局走向。

## 一、核心对比：以流式为第一维度

| 框架/协议 | 2026 关键事实 | 流式范式 | 首字延迟可见性 | 工具调用事件 | 推荐传输 |
|---|---|---|---|---|---|
| **LangGraph / Deep Agents** | 5 月发布 streaming-cookbook，astream_events v3 | 类型化事件流（投影式） | pipeline+model 双指标可分离 | 独立 tools 通道，可单独订阅 | Streamable HTTP / SSE |
| **OpenAI Agents SDK** | 基于 Responses API，Runner.run_streamed | SSE 事件（text delta/tool/handoff） | 依赖上游 preflight，需自管 | ResponseFunctionCallArguments 流式 | SSE（Responses） |
| **CrewAI** | 1.14.6，约 52.4k 星，12 个月~20 亿次执行 | 回调式 streaming + 任务级 | 黑盒，pre-inference 不可观测 | 任务级回调，非细粒度 | SSE / LiteLLM callbacks |
| **Microsoft Agent Framework** | 4 月 3 日 1.0 GA，AutoGen + Semantic Kernel 合并 | AgentRun 流 + A2A | 与 Strands 类似迭代器 | 可中断、可流式中断 | Streamable HTTP / WebSocket |
| **Pydantic AI** | Pydantic 团队，类型优先 | `run_stream()` 异步文本流 | 单模型为主，简单 | tool call 结构化 | SSE |
| **Mastra**（TS 原生） | Vercel AI SDK data-stream 协议 | parts 流（text/tool/finish） | 前端可直接消费 | tool-call parts 一等公民 | Streamable HTTP / SSE |
| **AG-UI**（协议层） | 2026 广泛采用，Bedrock AgentCore 3 月支持 | 类型化事件词汇表 | 定义标准事件 | lifecycle/run-card 标准化 | 与传输解耦 |

这张表的关键信号是：**第一梯队已经从"传 token"升级到"传语义事件"**。谁还在做"先攒齐再返回"，谁就吃满 3–15 秒的空白等待、1.5 秒后的用户流失高峰。

## 二、从 Token 流到 Agent 流：流式为何必须重做

LangChain 的判断很直接：为单次模型调用设计的流式 API，承载不了一个会规划、委派子智能体、调工具、等人工审批、产出媒体的现代 Agent。把所有这些压扁进一条 token 流，等于把装配工作全甩给应用层开发。新方案围绕四个理念重做：**类型化事件替代裸 chunk、投影（projection）替代解析、作用域订阅、同一套模型贯穿本地/远程/前端**。

它引入了一个统一的事件信封（envelope）：每个事件带"通道（channel）"和"命名空间（namespace）"两个标签。通道是可复用的关注点——`messages`、`values`/`updates`、`tools`、`lifecycle`、`checkpoints`、`custom:*`；命名空间标识事件来自 Agent 树的哪一部分（根图、嵌套子图、某个 Deep Agents 子智能体）。这一分离是关键设计选择：通道复用，命名空间定位。代码上，应用不再迭代裸协议事件，而是直接要它想渲染的东西：

```python
run = await graph.astream_events(
    {"messages": [{"role": "user", "content": "Research LangChain streaming"}]},
    version="v3",
)
async for message in run.messages:
    async for delta in message.text:
        sys.stdout.write(delta)
final_state = await run.output()
```

**优缺点**：投影式 API 让前端复杂度骤降——每条消息以类型化内容块（text/reasoning/tool-call args/usage）到达，而不是需要自己拼回的字符串流。代价是协议本身的复杂度和迁移成本，旧代码必须从 tuple 流迁移到 v3 事件模型。**变现评估**：这是高客单价的训练营题材。"用 React + LangGraph 搭一个可实时显示子智能体状态的研究面板"是一个完整、可演示、有差异化卖点的项目，能直接对标企业内部研发看板。

## 三、TTFT 才是真指标：流水线 TTFT vs 模型 TTFT

AWS 把 TTFT 上升为面向用户 Agent 最直接的体验信号：几百毫秒内开始吐字，即便总生成要好几秒，用户也觉得"快"。关键是**端到端延迟和 TTFT 是独立运动的两条线**——换更快的模型改善总时长，但当 pre-inference（上下文装配、检索、提示词构造、串行预检）是瓶颈时，TTFT 纹丝不动；只看总时长的仪表盘会掩盖用户真实感受到的退化。

AWS 给出的可落地做法是把 TTFT 拆成**两个独立指标**：在用户边界（第一个字节到达客户端）发射 `pipeline TTFT` 作为 SLO KPI，在第一个真正流给用户的推理调用处发射 `model TTFT`，二者分开发到 OpenTelemetry / CloudWatch。当两者分叉，差值就指向非模型贡献者。最反直觉但最重要的一点：**流式模型输出是必要但不充分**——当第一个 token 离开模型时，Agent 可能早已把整个 TTFT 预算花在推理开始前的工作上了。压缩检索、收窄检索上下文、并行化独立的 pre-inference 步骤，才是 TTFT 改善的主战场。

```python
# 伪代码：双指标埋点
t0 = monotonic_now()
ctx = await assemble_context(query)   # pre-inference
docs = await retrieve(ctx)            # pre-inference
prompt = build_prompt(ctx, docs)      # pre-inference
t_first_token = None
async for delta in converse_stream(prompt):
    if t_first_token is None:
        model_ttft = monotonic_now() - t_model_call   # 模型 TTFT
        emit("model_ttft", model_ttft)
    yield delta
pipeline_ttft = t_first_token - t0                    # 流水线 TTFT（SLO）
emit("pipeline_ttft", pipeline_ttft)
```

**优缺点**：双指标法能精准定位"慢在模型还是慢在准备"，避免把预算砸错地方（如堆更快 GPU 却无视检索）。缺点是需要可观测后端支持双维度埋点，团队要养成"先测再优"的纪律。**变现评估**：可作为"Agent 性能 SRE"课程的核心模块——大多数团队根本没把 TTFT 单独监控，这是直接填坑的咨询切入点。

## 四、协议层终局：SSE / WebSocket / Streamable HTTP 三角

agentmarketcap 的 2026 横评给出残酷的生产数据：**未流式时用户等 3–15 秒才看到首个输出，1.5 秒后流失率飙升；流式后首个内容在 ~1 秒内出现，感知等待最多降 80%**，即使总计算时间完全相同。三个协议各占一席：**SSE** 是单向流式的工作马，跑在标准 HTTP 上，负载均衡器/CDN/可观测工具天然认识它，适合 token 流和长任务进度；**WebSocket** 是双向持久 TCP 通道，用于语音 Agent、人在回路中改方向、实时协同编辑等"客户端必须在中途发数据"的场景，但要付 sticky session、Redis pub/sub 协调层、自定义重连的状态化代价；**Streamable HTTP** 是 MCP 2026 年 3 月规范的最大变量。

旧 MCP 传输要求服务器为每个客户端维持长连 SSE 连接——状态化、吃资源、负载下崩。新 Streamable HTTP 默认无状态（标准 POST/GET），长响应时同端点可选升级为 SSE，用 session ID 做恢复（旧 SSE 传输掉了就得重来），单一端点双向通信。对在 AWS Lambda、Cloudflare Workers、边缘计算跑 MCP 的团队，这意味着 MCP 第一次真正 serverless 友好。决策树极简：**客户端要在活动流中途发数据吗？要→WebSocket；不要→SSE（或 MCP 场景用 Streamable HTTP）**。大部分 Agent 用例落在"不要"这一栏。

```text
flowchart TD
    U[用户提交请求] --> GW{客户端需中途发数据?}
    GW -- 否 --> SSE[SSE / Streamable HTTP]
    GW -- 是 --> WS[WebSocket / WebRTC]
    SSE --> RUN[后端任务运行器]
    WS --> RUN
    RUN --> PRE[pre-inference: 检索/装配]
    PRE --> MODEL[模型流式推理]
    MODEL -->|token delta| EV[类型化事件流]
    MODEL -->|toolUse 块| EV
    PRE -.pipeline TTFT.-|埋点| MET[双指标 TTFT 仪表盘]
    MODEL -.model TTFT.-|埋点| MET
    EV --> PROJ[投影: messages/tools/values]
    PROJ --> FRONT[前端按通道订阅]
    RUN -.掉线.- CKP[checkpoint 恢复]
    CKP --> FRONT
```

**优缺点**：SSE 胜在简单与可观测，WebSocket 胜在双向实时，Streamable HTTP 胜在无状态与可恢复。误选 WebSocket 做 token 流的团队三天就回滚——"负载均衡器窒息、重连逻辑雪球、可观测性消失"。**变现评估**："Agent 流式协议选型 + 落地"是面向架构师的中级课，决策矩阵本身就能做一张可售卖的速查图。

## 五、工具调用断流：静默卡顿的缓冲-恢复术

AWS 点名一个高频反模式：Agent 在流式中途调工具时，事件流打开一个 `toolUse` 内容块，把工具输入作为 delta 流出去，然后**暂停**等工具执行并把结果喂回。如果客户端在这段空窗里收不到任何信号，用户就看到"半截输出 + 莫名其妙的卡顿"。基准解法叫 **buffer-and-resume**：工具块一出现就立刻向客户端转发一个可见的进度状态，下一个内容块开始时恢复流式。更激进的投机流式存在，但底线是——**任何静默停顿都不能到达用户**。

模型把工具调用切成 delta 流式这件事本身很关键：工具参数边生成边可见，前端可以在工具还没真正执行时就渲染"正在调用 search_web…(参数组装中)"。AG-UI 协议把它标准化成显式事件：text 生成块、thinking 推理步骤（可与最终答案分离渲染）、tool call 事件（哪个工具、什么参数、结果何时到）、state 同步、error/retry。前端工程师因此不需要和后端逐项目标事件 schema——协议给了共享词汇表。CopilotKit 生态已围绕 AG-UI 构建，Bedrock AgentCore 在 2026 年 3 月接入。

```typescript
// AG-UI 风格：前端只渲染自己需要的事件类型
const runner = agent.startStream(input);
for await (const ev of runner) {
  switch (ev.type) {
    case "tool_call_start": showWorking(ev.toolName); break;
    case "tool_call_args":  showArgs(ev.toolName, ev.delta); break;  // 参数边生成边显示
    case "tool_result":     showResult(ev.toolName, ev.result); break;
    case "text_chunk":      appendAnswer(ev.delta); break;          // buffer-and-resume：工具期不静默
    case "state_snapshot":  updateProgress(ev.state); break;
    case "done":            finish(); break;
  }
}
```

**优缺点**：把工具调用显式事件化，能把"卡住"变成"可见的忙碌"，直接压低流失率。代价是工具执行时长不可控时，进度状态可能误导（一直 spinner）。**变现评估**：可做成"Agent UX 微交互"实战课——大量团队的工具调用仍是黑盒转圈，这是肉眼可见的体验差。

## 六、多智能体渐进式流：不要阻塞上游

多智能体是 TTFT 的放大器：如果每个上游 Agent 都必须完整结束，用户侧 Agent 才开始，那么每次串行交接都把全部时长计入 TTFT，而不是与下游重叠。AWS 给的替代方案是 **progressive streaming**——用户侧 Agent 在拿到最小必需输入后就开始推理，上游 Agent 的中间输出边产生边流进它的上下文。Strands Agents 把 agent 事件（token、工具调用、消息）作为 async iterator 暴露，下游消费者可订阅；LangGraph 这类图编排器提供等价原语。只有当下游确实无法在上游结果完整前开始时，才保留同步全量交接。

LangChain 的方案把子图和子智能体区分对待：子图在任何嵌套图执行时浮现，子智能体在 Deep Agents 的 `task` 委派时浮现，二者都作为轻量句柄返回，只在前端真正伸手要时才流详细消息/工具/状态：

```python
async for subagent in run.subagents:
    print(f"{subagent.name}: {subagent.status}")
    async for message in subagent.messages:
        async for delta in message.text:
            sys.stdout.write(delta)
```

这让 UI 能随 Agent 复杂度伸缩——看板可以白嫖一个运行中子智能体列表，只在选中时打开它的消息和工具流；研究产品可以展示整棵工作树的高级进度，而不为每个 worker 的每个 token 付带宽。**优缺点**：渐进式流能把串行协调延迟转成用户可见的并行进度，但要求子智能体输入依赖可部分化，编排复杂度上升。**变现评估**："多智能体实时面板"是高客单训练营——能展示树状子智能体状态、点击下钻、断线续看的 demo 极有说服力。

## 七、断线重连与会话恢复

长任务 Agent 不再是边缘场景，而是团队正在构建的目标负载——浏览器刷新、网络抖动时，用户不该重启整轮或看到重复内容。MCP 的 Streamable HTTP 用原生 session ID 做恢复；LangChain 的协议让事件携带顺序元数据，客户端可从"最后看到的事件"重连并重放，重新挂载线程、追平缓冲事件、继续接收实时更新。后端栈的典型形态是：前端用 `EventSource` 或流式 fetch 开 SSE，事件带类型（AG-UI 或自定义 schema）；标准 HTTP 负载均衡（无需特殊 WebSocket 路由，但超时要拉到 60–300 秒）；后端用 FastAPI 这类异步框架生成 SSE，长任务丢进 Celery/Redis 队列，SSE 从 Redis pub/sub 拉状态——把 HTTP 连接生命周期与计算任务解耦；LangGraph 做 checkpointing，连接掉线后任务后台继续，用户可重连到可恢复流。

```typescript
// 前端：作用域订阅 + 断线重连
const thread = client.threads.stream({ assistantId: "research-agent" });
await thread.subscribe({
  channels: ["messages", "tools", "values", "lifecycle"],
  namespaces: [["researcher"]],   // 只订阅 research 子树的输出
  depth: 2,
});
// 事件带 ordering 元数据；刷新后从 lastSeenEventId 续传，不重放、不重复
```

**优缺点**：会话恢复把"30 秒任务怕断网"变成可生产化，但需要持久化 checkpoint 和有序事件存储，是真实的基础设施投入。**变现评估**：可打包成"Agent 生产化（durable execution）"专题，覆盖 checkpoint、恢复、去重——企业落地最痛的恰恰是这一块。

## 八、前端契约统一：AG-UI 与框架 SDK

最后一层是前端。LangChain 同期发布了 v1 框架包（`@langchain/react`、`/vue`、`/svelte`、`/angular`），把同一套流式概念用各框架的惯用法暴露：React 用 hooks、Vue 用 composables、Svelte 用响应式 helper、Angular 用 injectors/signals。心智模型共享：一个根 hook（`useStream`/`injectStream`）、顶层投影（messages/values/tool calls/interrupts 零配置可用）、组件级选择器（`useMessages`/`useToolCalls`/`useExtension`，只在组件挂载时作用域订阅）、子智能体即时浮现但详细流按需打开、同线程 remount 不重放不重复。这是从"回调式流式"到"渲染驱动流式"的转变——组件挂载它需要的投影，SDK 管订阅生命周期、重连、装配。

```typescript
// 渲染驱动：组件只订阅它渲染的数据
function SubagentCard({ stream, subagent }) {
  const messages = useMessages(stream, subagent);
  const toolCalls = useToolCalls(stream, subagent);
  const uiEvent = useExtension(stream, "a2ui");   // 自定义通道：生成式 UI
  return <AgentTrace messages={messages} toolCalls={toolCalls} ui={uiEvent} />;
}
```

自定义通道让产品流自己特有的状态（引用、进度、结构化计划、UI 描述、媒体句柄），而非只是助手文本——cookbook 里就有 Agent 经 `custom:a2ui` 通道发声明式 A2UI 消息、React 实时渲染界面表面的例子。**优缺点**：渲染驱动流式把前端从"解析日志"解放出来，多视图（聊天面板/侧栏/调试器/进度条/分析层）可各取所需而不争抢同一条流；代价是团队要接受一套新的事件协议心智模型。**变现评估**：这是面向前端工程师的"Agent UI 工程"蓝海课——大多数 Agent demo 的前端仍是手撸 SSE 拼字符串，门槛低、差异化高。

## 推荐方案

- **研究/看板型多智能体（树状状态可下钻）**：LangGraph / Deep Agents + astream_events v3 + Streamable HTTP。投影式 API + 作用域订阅是当前最完整的事件流方案。
- **单模型对话 / 简单工具 Agent**：OpenAI Agents SDK（`Runner.run_streamed`）或 Pydantic AI（`run_stream`），SSE 足够，别上 WebSocket。
- **TypeScript 全栈 / 生成式 UI**：Mastra + Vercel AI SDK data-stream，parts 流天然适配前端；配 AG-UI 做事件词汇表。
- **语音 / 人在回路中途改方向**：必须 WebSocket（或 AgentCore 的双向流 / WebRTC），SSE 不支持中途发数据。
- **MCP 工具服务（新部署）**：默认 Streamable HTTP，无状态、可恢复、serverless 友好；旧 SSE 仅留给存量。
- **生产化底线（任何选型都必做）**：拆 pipeline TTFT 与 model TTFT 双指标、工具调用 buffer-and-resume 不静默、checkpoint 支持断线重连。

一句话终局：2026 年，**流式不再是优化项，而是基线**。框架之争从"谁更能调工具"转向"谁的事件流更类型化、谁的 TTFT 更可控、谁的前端契约更统一"——还在做"先攒齐再返回"的，正在被用户用脚投票。

## 参考来源

1. [AGENTPERF02-BP04 Optimize streaming responses and time-to-first-token for agent interactions — AWS Agentic AI Lens](https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentperf02-bp04.html) — 把 TTFT 列为面向用户 Agent 的主导体验信号，定义 pipeline TTFT 与 model TTFT 双指标、工具调用 buffer-and-resume、多智能体 progressive streaming
2. [From Token Streams to Agent Streams — LangChain Blog（2026-05-21）](https://www.langchain.com/blog/token-streams-to-agent-streams) — 类型化事件、投影、通道/命名空间、作用域订阅、断线重连、多模态流、`@langchain/*` 前端 SDK 与 streaming-cookbook
3. [Agent Streaming Architecture 2026: The Protocol Decision Matrix — AgentMarketCap](https://agentmarketcap.ai/blog/2026/04/07/agent-streaming-architecture-sse-websocket-http-2026) — SSE/WebSocket/Streamable HTTP 三角对比，未流式 1.5 秒后流失飙升、流式感知等待最多降 80% 的生产数据，AG-UI 词汇表
4. [AI Agent Frameworks (2026 Update): 8 SDKs Compared — morphllm](https://www.morphllm.com/ai-agent-framework) — Microsoft Agent Framework 1.0 GA（2026-04-03，AutoGen+Semantic Kernel 合并）、CrewAI 52.4k 星/约 20 亿次执行、Google ADK 四语言 SDK、Claude Agent SDK 订阅额度、ACP 并入 A2A、MCP 超 200 服务器
5. [MCP Streamable HTTP 规范与 AG-UI 生态说明 — AgentMarketCap Streaming Production 系列](https://agentmarketcap.ai/blog/2026/04/07/streaming-agent-architecture-sse-websocket-production) — MCP 2026-03 规范（2025-03-26）从 HTTP+SSE 切到 Streamable HTTP，session ID 恢复，serverless 兼容；AG-UI 在 Bedrock AgentCore 2026-03 接入

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
