你有没有注意到一个很奇怪的事情：现在的 AI Agent 再怎么厉害，本质上还是在「排队」。
读完 → 想完 → 写完 → 等反馈 → 再读 → 再想 → 再写。
一条直线，从头走到尾。人类可不是这样工作的。你一边听会议一边在笔记本上画架构图，一边看文档一边在脑子里盘算方案。多条线同时跑，互相影响。
上周 Max Planck 智能系统研究所的一篇论文提出了一个直接的解法：把 LLM 的单流处理拆成多流并行。论文叫「Multi-Stream LLMs」，在 HN 拿了 86 分。
分数不算爆炸性的，但我认为这篇论文指向的方向比大多数人意识到的更重要。
当前 Agent 的根本瓶颈
从 ChatGPT 到 Claude Code 到 Cursor，所有 Agent 的底层都是同一套消息交换格式：
user message → assistant thinking → assistant output → tool call → tool result → assistant thinking → ...
串行。一次只能做一件事。
这导致了几个很实际的问题：
不能边读边想。 Agent 收到一大段代码，必须全部读完才能开始分析。不能像人类那样读到第 10 行就已经在脑子里形成假设了。
不能边想边做。 Agent 在生成思考过程（chain-of-thought）的时候，输出流是冻结的。想了 30 秒钟，用户看到的是一片空白。想完了才一口气吐出结果。
不能被打断。 Agent 在写一段长回复的中途，你发了一条新消息。它要么忽略你（写完再看），要么强行中断（之前写的全废了）。没有「暂停处理一下新信息，然后继续」这个选项。
不能同时处理多个事。 一个编程 Agent 在写代码的时候，不能同时跑一个安全审计。必须写完，然后单独审计一遍。
这些限制在简单对话里不明显，但在 Agent 执行复杂任务时就成了实打实的性能瓶颈。
Multi-Stream 的核心思路
论文的做法概念上很简洁：把每个「角色」（用户输入、系统指令、思考过程、工具调用、输出）拆成独立的流（stream）。
传统模型的一个 forward pass 做一件事：读一段输入，或者生成一个 token。
Multi-Stream 模型的一个 forward pass 同时做多件事：从多个输入流读取，向多个输出流写入。所有流之间有因果依赖（后面的时间步能看到前面所有流的内容），但同一个时间步内各流是并行的。
打个比方：
传统模型像一个只有一条车道的公路。不管你有多少辆车（读、想、写、调工具），都得排队过。
Multi-Stream 像一条多车道高速公路。读取、思考、输出可以同时在不同车道上跑。前面车道的车看得到后面车道的情况（因果依赖），但不会互相堵塞。
三个直接好处
论文在三个维度上验证了这个架构的优势：
1. 效率：并行化降低延迟
最直观的好处。当思考和输出可以并行时，用户感知到的延迟大幅降低。
传统模式：想 5 秒 → 写 3 秒 = 用户等 8 秒 Multi-Stream：想和写同时进行 = 用户可能等 5 秒就开始看到输出
论文里展示了一个例子：Agent 在处理信息的同时就开始执行动作（Example A.1: Acting While Processing Information）。不需要等全部处理完。
2. 安全：关注点物理隔离
这是我觉得最有前景的方向。
当前 Agent 的一个大安全问题是 prompt injection：恶意指令被夹在正常输入里，模型分不清哪些是系统指令、哪些是用户输入、哪些是攻击者注入的内容。因为它们全在同一条流里，长得都一样。
Multi-Stream 把不同来源的内容放在物理隔离的流里。系统指令在 stream A，用户输入在 stream B，外部工具返回在 stream C。模型可以从架构层面区分「谁在说话」。
论文专门做了 prompt injection 的实验（Example A.3: Prompt Injection Defense Through Stream Separation），效果显著。这不是靠 prompt 策略防御，而是靠架构设计防御。
3. 可监控性：思考过程可审计
当前模型的 chain-of-thought 混在输出里，或者藏在不可见的 thinking token 里。你要么看不到它在想什么，要么看到了但和输出混在一起很难分析。
Multi-Stream 把思考过程放在独立的 stream 里，和输出流物理分离。这意味着：
- 你可以实时监控 Agent 在想什么，而不影响它的输出
- 可以在思考流上跑一个独立的安全审计（Example A.2: Parallel Audit During Code Generation）
- 如果 Agent 在思考流中出现了危险倾向，可以在它行动之前拦截
论文甚至做了一个实验：检测 Agent 有没有在「假装对齐」（alignment faking）。通过分析独立的思考流，可以比传统方法更准确地发现 Agent 的真实意图。
技术实现：比你想的简单
一个好消息：Multi-Stream 不需要重新设计 Transformer 架构。它是一种训练方法（instruction-tuning 层面的改变），不是架构改变。
具体做法：
- 构造多流格式的训练数据（把 Alpaca 等数据集重建为多流格式）
- 用特殊 token 标记不同流的开始和结束
- 用因果一致性验证确保各流之间的时序关系正确
- 在推理时用同步多流解码（每个时间步同时生成多个流的 token）
论文在 Qwen2.5-7B 上做了验证（叫 Stream-7B），表现出了清晰的多流能力。他们还训练了一个 27B 版本（Stream-27B），能处理更复杂的多流场景。
这意味着任何现有的开源模型都可以通过后训练（post-training）获得多流能力。不需要从头预训练。
对 Agent 开发者意味着什么
如果这个方向成熟，Agent 框架需要重新设计。
当前的 Agent 框架（LangChain、Claude Code 的 harness、Cursor 的 Composer）都是基于消息序列的：发一条消息，等回复，再发一条。
多流 Agent 的框架需要支持：
- 多个并行通道的管理
- 流间的同步和依赖关系
- 实时监控多个流的状态
- 在某个流出现问题时的干预机制
这有点像从单线程编程转向多线程编程。能力天花板提高了，但复杂度也上去了。
和 Cursor Composer 2.5 的关联
前两天我写 Cursor Composer 2.5 的时候提到了他们关注的三个维度：沟通风格、effort 校准、长任务续航。
Multi-Stream 架构天然解决了其中一个问题：长任务续航。当 Agent 可以在一个流里持续执行任务、另一个流里监控进度和调整策略时，长任务的质量会更稳定。
如果 Cursor 下一代 Composer 采用了多流架构（他们正在和 SpaceXAI 从头训练新模型），能力可能会有质的飞跃。
这不是第一次有人提这个想法
论文的 Related Work 里提到了两个前序工作：Multiverse 和 StreamingThinker。说明这个方向已经有一些人在探索了。
但 Multi-Stream LLMs 这篇的贡献在于：把想法系统化了，在效率/安全/可监控三个维度上都给出了实验验证，而且证明了不需要改架构就能实现。
论文来自 Max Planck + ETH Zurich + ELLIS Institute，都是欧洲顶尖 AI 研究机构。第一作者 Guinan Su 和最后一位 Jonas Geiping 都有很扎实的系统安全背景。
我的判断
多流 LLM 可能不会以「一夜之间所有模型都变成多流」的方式落地。更可能的路径是：
- 先在安全场景落地（流隔离防御 prompt injection 有明确的商业价值）
- 再在效率场景落地（降低 Agent 延迟，提升用户体验）
- 最后在复杂 Agent 场景全面铺开（真正的并行思考和行动）
第一步可能很快就会被头部 AI 公司采用。Anthropic 的 Claude 现在已经有了隐藏的 thinking token，把它变成一个独立的、可审计的流是自然的演进。
如果你在做 Agent 相关的开发，建议关注这个方向。从单流到多流的转变，和从同步到异步、从单线程到多线程一样，是基础设施层面的范式转移。先理解原理的人会有优势。
这是 AI Agent 系列的第十篇。相关文章：