首字延迟战：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 子智能体）。这一分离是关键设计选择：通道复用，命名空间定位。代码上，应用不再迭代裸协议事件，而是直接要它想渲染的东西：

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 改善的主战场。

# 伪代码：双指标埋点
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 用例落在"不要"这一栏。

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 月接入。

// 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 委派时浮现，二者都作为轻量句柄返回，只在前端真正伸手要时才流详细消息/工具/状态：

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，连接掉线后任务后台继续，用户可重连到可恢复流。

// 前端：作用域订阅 + 断线重连
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 管订阅生命周期、重连、装配。

// 渲染驱动：组件只订阅它渲染的数据
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 拼字符串，门槛低、差异化高。

推荐方案

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