我越来越觉得，很多 AI Agent 的问题不在“模型还不够聪明”，而在我们把它们塞进了一个很别扭的接口里：一条聊天消息进来，一条聊天消息出去，中间所有思考、工具调用、观察结果、用户反馈，都被挤在同一条时间线上。
这件事平时不明显。你让模型改一段代码、总结一篇文章，它慢一点、啰嗦一点，问题不大。但一旦进入真正的 Agent 场景，比如浏览器操作、长时间代码修改、后台任务、多人协作，它就开始露馅：模型正在“思考”时没法同时接收新信息，正在“输出”时没法真正读环境变化，正在等工具结果时也没法继续做别的规划。
说白了就是：我们想要一个能并行工作的智能系统，却还在用单线程聊天窗口来驱动它。
最近 HN 上有一篇论文讨论的正是这个问题：Multi-Stream LLMs: Unblocking Language Models with Parallel Streams of Thoughts, Inputs and Outputs。它的分数不算特别夸张，但我觉得比很多“又一个 Agent 框架”更值得写。因为它不是在 prompt 外面再包一层流程图，而是在问一个更底层的问题：LLM 的交互格式，是否已经成为 Agent 能力的瓶颈？
HN 原帖标题也很直接：Multi-Stream LLMs: new paper on parallelizing/separating prompts, thinking, I/O。这不是一个已经成熟可用的工程框架，更像是一份架构提案。但它戳中了生产级 Agent 的一个痛点。
当前 Agent 最大的隐性假设：所有事情都必须排队
今天大多数 Agent 系统，本质上还是 ChatGPT 时代的消息协议：
- system message 定规则；
- user message 给任务；
- assistant message 生成回答或工具调用；
- tool message 把结果塞回上下文；
- assistant 再继续。
OpenAI 的 Agents SDK 已经把 handoff、guardrails、tracing、tool calling 封装得很清楚；Anthropic 的 Computer Use 也让 Claude 可以观察屏幕、点击、输入、等待环境变化；MCP 则通过 Model Context Protocol 把外部工具和数据源标准化成可连接的上下文。
这些都很重要。
但它们大多没有改变一件事：模型核心仍然沿着一条 token 流推进。每一步都像排队办事，先读输入，再生成动作，再等工具结果，再读回来，再继续。
论文作者把这个问题说得更尖锐：即使是高级 Agent，也仍然在单一计算流里依次和用户、系统、自身 chain-of-thought、工具交换消息。结果是模型不能在阅读时行动，不能在行动时继续思考，不能在输出时响应新信息。
人话翻译：Agent 看起来像“自动驾驶”，底层却更像“每隔几秒截一张图，然后让司机闭眼想完再操作”。
这就是为什么很多电脑操作 Agent 或编码 Agent 会显得笨拙。它不是不会规划，而是规划、观察、执行、反馈被硬塞进同一条窄管道里。管道越长，延迟越大；任务越复杂，状态越容易错位。
Multi-Stream LLM 到底改了什么？
这篇论文的核心想法并不复杂：把原来的一条消息流拆成多个并行流。比如输入、输出、思考、工具结果、用户反馈不再都挤在同一个序列里，而是作为不同 stream 同时被模型读取和生成。
论文摘要里最关键的一句是：每一次 forward pass 都同时从多个输入流读取，并在多个输出流生成 token，而这些 token 又都因果依赖于更早的时间步。
听起来有点抽象。可以把它想成从“单人单窗口客服”变成“一个小型控制室”：
- 左边屏幕持续接收用户和环境输入；
- 中间屏幕维护计划和内部状态；
- 右边屏幕输出动作、代码或工具调用；
- 监控屏幕只看安全和异常信号。
重点不是“多开几个 prompt”，而是模型训练时就学习这些流之间的因果关系。它不是外部 orchestrator 强行把任务拆开，而是模型本身支持多通道计算。
我比较看重的是这里的“分离关注点”。现在 Agent 的工具调用、思考痕迹、用户文本、系统约束经常混在一个上下文里。安全团队想审计，往往只能拿到一坨聊天记录，然后试图还原模型为什么这么做。Multi-Stream 至少在理论上提供了更清晰的边界：哪些 token 是观察，哪些是计划，哪些是动作，哪些是监督信号。
这对 Agent 安全很关键。之前我写过一篇关于评测基准被 exploit 的文章：Berkeley 研究团队系统性破解八大 AI Agent 评测基准。那类问题的根源之一，就是 Agent 的目标、环境、奖励和动作边界混在一起，模型很容易学会“看起来完成任务”的捷径，而不是按真实意图行动。
Multi-Stream 不会自动解决对齐问题，但它让系统有机会把“想什么”和“做什么”拆开监控。
为什么这比又一个 Agent 框架更值得关注？
坦白说，我对很多 Agent 框架已经有点审美疲劳了。它们通常做三件事：包装工具调用、加一点状态机、提供一个漂亮的 dashboard。不是没用，但大部分问题还是推给了底层模型和 prompt。
Multi-Stream 的价值在于，它指出了一个更底层的工程约束：如果模型只能顺序处理一条上下文流，再复杂的框架也只是在单车道上修立交桥。
举个例子，浏览器 Agent 正在填写表单。传统架构下，它可能是：截图 → 模型分析 → 输出点击 → 等待页面变化 → 再截图 → 再分析。每一步都完整阻塞。页面如果中途弹出验证码、网络延迟、按钮状态变化，Agent 只能下一轮才知道。
如果有独立的环境输入流，模型理论上可以在生成后续动作时持续读取新观察；如果有独立的安全监督流，系统也可以在动作流生成危险操作时及时中断。注意，我说的是“理论上”。现在这篇论文更像方向证明，还不是一个你明天能接进生产的 SDK。
但方向是对的。
这也让我想到另一类工程实践：用状态机给 Agent 加护栏。我之前写过 Statewright：用状态机给 AI 编程 Agent 加护栏。Statewright 的思路是在模型外部限制阶段、命令和文件范围；Multi-Stream 则更像在模型内部提供可分离的通道。前者是外部控制面，后者是模型计算面。
理想的生产系统大概率两者都要：外部状态机负责权限和流程，内部多流模型负责低延迟、多通道感知和动作生成。
对生产级 Agent，真正有价值的可能是三件事
第一是延迟。
Agent 系统的慢，不只来自模型推理速度，也来自“轮次”。一次工具调用、一轮观察、一轮思考、一轮输出，累计起来就是体感上的笨重。Multi-Stream 如果能减少阻塞轮次，收益可能比单纯把模型量化到更快还明显。
第二是可观测性。
今天的 tracing 通常记录“某轮调用输入是什么、输出是什么、调用了哪个工具”。这当然有用，但粒度仍然偏粗。如果模型内部存在计划流、动作流、监督流，tracing 就可能从“记录聊天”升级为“记录控制系统”。
这对企业落地很实际。你不只是想知道 Agent 调用了 delete_file，你还想知道它是在什么计划状态下调用的、是否有监督信号反对、环境输入是否已经过期。
第三是安全边界。
当前 prompt injection 最大的麻烦之一，是恶意内容可以伪装成普通输入进入同一上下文，然后影响模型的工具决策。多流架构并不能让攻击消失，但它至少提供了一种结构性隔离：网页内容是网页内容，系统规则是系统规则，工具动作是工具动作，监督策略是监督策略。
当然，这里有个我不确定的地方：如果模型训练数据和损失函数设计不好，多流也可能只是把混乱从一个大上下文搬到多个小上下文。流之间的权限、因果遮罩、训练目标怎么设计，才是难点。
论文提出的是方向，不是银弹。
什么时候不该高估它？
我不建议现在就把 Multi-Stream LLM 当成“下一代 Agent 标准答案”。原因很简单：工程生态还没准备好。
第一，推理框架需要改。现在主流 serving stack、KV cache 管理、batching、streaming API，基本都围绕单序列或简单多轮对话设计。多输出流意味着调度和内存管理都要重做一部分。
第二，数据构造很难。要让模型学会多流协同，你需要高质量的多通道轨迹：什么时候观察、什么时候计划、什么时候行动、什么时候监控。真实世界里这种数据很少，而且标注成本不低。
第三，产品接口也要变。用户习惯了聊天框，开发者习惯了 messages 数组。多流 API 如果设计得太复杂，会把应用开发者吓跑。最后可能还是需要 SDK 把复杂性藏起来，就像今天工具调用把 function schema 包在 messages 里一样。
所以我更倾向于把它看成一个中期信号：未来 1-2 年，Agent 架构会从“聊天消息 + 工具调用”逐步走向“控制系统 + 多通道状态”。谁先把这件事做成可用的 developer experience，谁就可能拿到下一波 Agent 基础设施红利。
我的判断：Agent 的下一步不是更长上下文，而是更清晰的通道
过去一年，大家很容易把 Agent 问题归因到上下文不够长、模型不够强、工具不够多。于是方案就是更长 context、更强 reasoning、更多 MCP server。
这些都有用，但不够。
如果所有信息仍然挤在同一条顺序流里，长上下文只是更长的堵车队伍。模型能记住更多历史，不代表它能同时观察、计划、执行和被监督。
Multi-Stream LLM 给我的启发是：生产级 Agent 需要的不是一个“更会聊天的模型”，而是一个能被工程系统接管、观测和约束的计算单元。聊天只是其中一种界面，不应该继续成为底层架构。
今天如果你在做 Agent 产品，我不会建议你等 Multi-Stream 模型成熟后再动手。更现实的做法是先在系统层模拟这种分离：把 observation、plan、action、audit log、policy check 拆成不同数据结构，不要全塞进一个 prompt；用状态机限制动作阶段；用 tracing 记录每次工具调用的上下文；对高风险动作加人工审批或 deterministic policy。
等到底层模型真的支持多流时，你的系统会更容易迁移。
反过来，如果现在还把 Agent 做成“一个超长 system prompt + 一堆工具 + 祈祷模型别乱来”，那即使模型再强，也迟早会在复杂任务里踩坑。
这篇论文还早，但它指向的不是小优化，而是 Agent 架构从聊天范式走向控制范式的转折点。至少在我看来，这比又一个套壳 Agent 框架更值得关注。
参考信源：