1. 手写流式 Chat 之后

在前面，我们学习过如何实现流式 AI Chat：

• 后端：Hono 的 streamText 往 SSE 通道里逐条 writeln 协议帧
• 中间：自定义事件名 thinking / token / done / error
• 前端：fetch + reader.read() + 手写 parseSSEEvents 切分双换行
• React 侧：手写 useStreamChat Hook 管理 status / thinkingNode / reply / metadata 四个状态

那一套代码跑起来了，从字节层把「逐 token 到 UI」的全链路走通了。但你要是把它搬进真实项目，大概率会撞上这几个问题：

问题一：前端状态机，每次都要重写一遍。 思考态、生成态、结束态、出错态 —— 这 4 种状态不是只出现在 AI 伴侣项目里，几乎所有 LLM 产品都要处理。可每次开新项目还是要把 useState + while(true) { reader.read() } 再写一遍，因为上次那份代码和新项目的消息协议对不上。

问题二：模型切换，牵一发动全身。 项目从 OpenAI 换 Claude，从 Claude 换 Workers AI，每一次切换都要改后端调用代码、改请求体结构、改响应解析。LangChain 的 ChatOpenAI / ChatAnthropic 能抹平一部分，但前端协议层和 UI 渲染层仍然和 Provider 强绑。

问题三：Tool Calling 的 UI 自己搓。 LLM 调用了 search_memory 工具 —— 前端要不要展示「正在检索记忆」？工具返回后要不要展示检索到了 3 条？这些「中间态」要序列化成什么协议从后端发出去、前端又怎么渲染？这一层没有现成的约定，每个项目都在造轮子。

问题四：每出一个新能力都要重新接一次。 Anthropic 发了 thinking tokens，你要改协议让前端渲染思考段；OpenAI 又发了 reasoning 参数，再改一次。后面还有 MCP 工具、多模态输入等等——每一个新能力都意味着前端事件类型、后端序列化、中间协议三处同步改。

这四个问题不归 LangChain 管，也不归 Hono 管——它们都是**「前端和后端之间的 AI 胶水层」**的问题。这一层在 2024 年以前一直没有事实标准。

Vercel AI SDK 就是来填这个空的。