你让 AI 一边看球赛，一边解说。它刚开始组织上一幕的描述，场上却已经进球了。传统 Agent 往往要先“看完、想完、说完”，才会读取下一条信息；任何一步拖久了，它就可能错过变化。
论文《LLMs are General Asynchronous Agents》想改变这种节奏。作者提出 AsyncLLM，让同一个 Agent 的观察、思考和行动可以重叠进行。它不是为足球、游戏或系统监控分别训练新模型，而是给现有 Qwen 3.x 模型加上一套通用的并发运行框架。
先说明证据边界：以下结果均来自这篇论文，尚无独立信源交叉验证。作者公开了框架代码，但论文中的模型版本、任务设置和指标差异较大，不能据此断言 LLM 已经普遍具备稳定的实时并发能力。
Agent 为什么总要“等一下”
AI Agent——能够持续观察环境、调用工具并采取行动的 AI 系统——通常按一个串行循环工作：读取输入，思考，行动，等待结果，再读取下一条输入。这适合一问一答，却不适合连续变化的环境。
比如，语音助手思考时，用户可能改口；游戏角色规划路线时，敌人可能突然出现；监控 Agent 分析旧日志时，系统可能已经发生新故障。串行系统只要有一步卡住，整条链都会停下。
所谓“异步”，就是一件事不必等上一件彻底结束才启动。Agent 等工具返回时仍能接收新消息，后台做长期推理时仍能处理突发事件。难点也随之出现：新输入、旧计划和工具结果可能同时到达，系统必须决定谁先处理，还要避免它们互相打架。
关键不是多开几个模型，而是共享“工作记忆”
AsyncLLM 借用了程序设计里的 async/await 模式。开发者可以定义多个协程——可以暂停、恢复并与其他任务交错执行的小任务。一个协程负责持续观察，一个负责深入思考，另一个负责快速行动。
真正关键的一步，是让这些协程共享部分模型记忆。作者把记忆切成若干 CacheBlock。每块保存一段输入对应的内部状态，包括 KV Cache——模型处理上下文时留下的中间结果，可以理解成无需反复重算的工作笔记。不同协程各写各的块，同时通过不同的“视图”读取其他块。
论文给出的例子里，“思考者”持续写推理，“撰写者”同步读取已经形成的内容并生成进度摘要。思考者不必停下来，把完整文本重新交给撰写者；后者直接查看共享的内部状态。它更像两个人共用一份实时更新的工作底稿，而不是不断互发整份文件。
底层实现还要解决一个工程问题：不同协程看到的记忆块顺序可能不同。AsyncLLM 为传统注意力、线性注意力以及图像和视频使用的多模态位置编码分别设计了组合办法，并把并发请求合并成 GPU 批次。调度器会拆分过长的输入，避免一个庞大的后台任务堵住需要快速反应的协程。
不过，这仍是框架层面的并发调度，不能直接理解为模型天生拥有独立、同时运转的多股意识。
三类任务都能跑，但证据强弱不同
在流式视频实验中，Agent 同时运行五个部分：逐帧判断是否出现重要事件、在后台重建事件、检查推理中是否有新内容、撰写描述，以及汇总输出。作者没有另训专门的事件探测器，而是让基础模型用预先写好的提示直接判断画面。
在 SoccerNet 和 ProactiveVideoQA 上，三种 Qwen 3.x 配置都超过了专门为视频流训练的 Mage-VL。以表中 Qwen3.5-9B 为例，它在 SoccerNet 的 TriggerAcc 和 TimVal 分别为 62.82 和 39.62，Mage-VL 为 52.79 和 27.87；两者在 ProactiveVideoQA 的综合 PAUC 分别为 52.99 和 43.27。作者也提醒，SoccerNet 的官方协议不评价描述质量，而 Mage-VL 的训练重点可能不同，因此这不是全面胜负。
第二组实验是 Doom 游戏。后台协程负责制定较长期的行动方向，较快的行动协程把它变成逐帧操作，并用探针判断何时可以提前出手。论文称，这套 Agent 比同模型的串行版本反应更快，同时保留了推理带来的收益。但正文没有给出可直接复述的具体分数，作者也明确说，这只能证明基本能力，不代表达到这些游戏的最佳水平。让模型自行编写协程的尝试，在 HealthGathering 中初步表现不错，在 DeadlyCorridor 中则较差。
第三组实验处理实时系统日志。Q3.6-35B-A3B 的完整串行基线准确率为 61.76%，平均看完全部事件，并执行 8452 次前向计算；AsyncLLM 的准确率降至 55.88%，但只看到平均 55.49% 的事件便作答，前向计算减少到 3837 次。Qwen3.5-9B 上也有相似取舍：准确率从 47.06%降至41.18%，前向计算从8726次降至2582次，平均在事件流进行到44.98%时回答。
所以，“更快且准确率相当”需要谨慎理解。异步版本确实更早、计算步数更少，但两种模型的准确率都低于等待完整日志的串行基线。它展示的是速度与准确率之间一个有吸引力的折中，而不是无代价提速。
为什么这一步值得关注
过去，不同领域往往各自搭建并发系统：语音助手处理打断，视频模型筛选关键帧，机器人分开“思考者”和“执行者”，监控程序持续扫描日志。AsyncLLM 的价值，在于把这些表面不同的问题归到同一种编程模型里：定义并行协程，安排它们共享哪些记忆，再让调度器负责执行。
而且，这些演示没有做任务专用微调。也就是说，作者主要改变了模型如何运行，而不是为每个场景重新训练一遍。如果这条路线继续成熟，开发者或许可以用组合协程的方式，把通用模型较快接入新的连续环境。
但论文题目里的“General”仍更像研究假设，而不是已经盖章的结论。三类场景说明同一框架具有迁移潜力；它们还不足以证明面对任意并发任务都可靠。
局限与未知
- 所有能力和效果都来自作者自己的实验。论文没有独立复现，也没有证明该方法适用于所有现代 LLM。
- “无需任务专用训练”不等于无需人工设计。实验仍使用了特定的协程结构、提示词、事件探针和防止模型分心的提示。
- 自行定义协程的能力还不稳定，在两个游戏场景中表现不一致。现实系统还需要回答冲突处理、延迟上限和出错恢复等问题。
这篇论文真正推进的，不是宣布 Agent 已经学会完美地“一心多用”，而是提出一种可复用的办法，让观察、思考和行动不再必须排成一条队。它把问题从“为每种实时任务造一个专用模型”，改写成“怎样安排多个共享记忆的推理过程”。这或许才是它最值得继续跟踪的地方。