两朵乌云
“两朵乌云”这个比喻从何而来？
- 出处: 1900 年开尔文说，物理学晴朗的天空上还飘着两朵乌云;
- 结局: 后来一朵变成了相对论，另一朵变成了量子力学;
- 借用: 今天 Agent 的天空同样称不上晴朗，也存在两朵乌云;
- 第一朵: Agent 如何流式地、实时地与环境交互;
- 第二朵: Agent 如何像人一样，从与环境交互的成功与失败中持续积累经验;
- 关键限制: 两朵乌云都不是靠某一次模型升级就能凭空吹散的，跨越它们要看模型与 Agent 如何共同演进，见模型与 Agent 的共同演进;
为什么 Agent 今天还不够实时？
- 现状: 绝大多数 Agent 仍按轮次（turn-by-turn）的“请求—应答”模式运行——你说完一句，它想一整段，再一次性吐出结果;
- 冲突: 真实世界不会停下来等它想完，话会被打断，画面在持续变化，邮件在不断到达;
- 目标形态: 一个真正“活着”的 Agent 应能边听边想、边说边想;
- 交互要求: 能在话说到一半时就开始规划，也能在没人吩咐时主动发现“这封邮件该处理了”;
- 基础原语: 中断、抢占、取消等交互语义与观察和动作空间的扩展相关，见观察与动作空间;
走向实时性有哪两条并行路径？
| 路径 | 做法 | 说明 |
|---|---|---|
| 架构上做快慢分离 | 前台快模型维持对话节奏，后台慢模型负责深度思考 | 实时与智能几乎是两条正交的轴，单一模型难以兼顾 |
| 把推理本身做快 | 提高 decode 速度，让按轮次的等待短到近乎消失 | turn-by-turn 与“实时”的界限随之模糊 |
| 硬件与系统协同 | FP4 量化、并行推测解码与推理系统协同设计 | 小米 MiMo 在单个通用 8 卡节点上首次把 1T 参数模型的生成速度推过 1000 token/s |
| 模型固化进芯片 | 把整个模型固化进专用芯片 | Taalas HC1 将 Llama 3.1 8B 固化进 6nm 芯片，约 17000 token/s、响应低于 100 毫秒 |
- 固化的代价: 芯片只能运行被固化的那个模型，模型更新需要重新流片;
- 来源一: 小米 MiMo 官方技术博客 “Pushing 1T-Parameter Model Generation Speed to 1000 TPS”，2026;
- 来源二: Forbes，Karl Freund，“Taalas Launches Hardcore Chip With ‘Insane’ AI Inference Performance”，2026;
- 体验结论: 当模型每秒能吐出上千个字，“想完再说”与“边想边说”的体验差距就被抹平了;
- 推进力量: 这条路正被芯片与推理引擎快速推进;
为什么模型上岗之后几乎不再成长？
- 比喻: 今天的模型更像一个记性极好、却学不会新东西的天才;
- 训练期: 把人类知识背得滚瓜烂熟;
- 上岗后: 几乎不再成长——每次任务结束，那些踩过的坑、试出来的窍门大多随着上下文一起被丢掉;
- 问题性质: 这究竟是不是一个真问题，取决于两种针锋相对的假设，见小世界假设与大世界假设;
- 涉及工程: 把经验写成知识文档、指令或程序，还是经过筛选后用于更新模型参数，正是第三章记忆与第九章持续进化在摸索的方向;
跨越两朵乌云的前提是什么？
- 前提: 得先看清一件事——模型和 Agent 从来不是上下游，而是一起往前走的;
- 展开: 模型与 Agent 的共同演进;