原文：mp.weixin.qq.com/s/pDNVyurIX...（2026年10月07日）
先看一个场景。
你让 AI 帮你起草一封邮件。它开始搜索联系人信息。
就在搜索结果还没返回的当口，你突然改口：
"等一下，先帮我查一下明天的天气。"
这时候，Agent 卡住了。
因为它正处在一个尴尬的位置：工具调用发出去了，结果还没回来。 它不知道该带着这条"悬空"的调用去处理你的新消息，还是该干等。
这个小卡顿，暴露的是一个大问题：
一个 Agent 实例，可能同时面对多个事件------用户的新消息、工具返回的结果、定时器到期、另一个 Agent 的协作请求。它该先理谁？
处理得好不好，直接决定性能和体验。
这一篇，我们把这件事讲透。
骨架：把 Agent 想象成一个"永不停止的循环"
先给个整体图景。
异步 Agent 的骨架，是并发编程里的事件循环。
把它想象成一个长期运行的循环：
每一轮，从队列里取出若干事件 → 追加到"轨迹"里 → 调用一次大模型 → 执行它决定的工具 → 回到循环开头，等下一批。
听起来抽象？其实它和 Go 语言里 for { select { ... } } 逐轮读 channel 消息，是同一个结构。
理解了骨架，真正的问题就浮现了：新事件，在什么时候被"看见"？
传统同步接口里，事件只在每轮循环的边界被消费。模型在推理、工具在执行时，新事件先在队列里排队，等到达一个"安全点"（一段推理结束、一次工具返回）再处理。
而原生异步，允许模型还在思考或输出时，就接收新要求。
两种都有边界，只是边界由不同的层来管。 工具取消也不是万能的------收到一条"停止"消息本身，并不会自动撤销已经发生的动作。
三种策略：取消、排队、并行
在兼容同步接口的运行时里，有三种处理策略。记住三个生活化的画面就好。
① 取消式------给紧急事件"提前制造一个安全点"。
用于紧急事件。比如你点了"停止"，或者监督系统发来高优先级指令。
做法是：立刻中断当前步骤，把这一刻变成一个可以接入新事件的边界；清空待处理队列；把新老事件一起追加到轨迹末尾；立刻重新调用模型，让它用最新的完整轨迹重新评估局势。
最典型的就是你在它执行错误操作时喊一句："停！我说错了。" 它立刻看到，立刻纠正。
② 队列式------常规事件，排队批量处理。
用于不紧急的事件。比如一个异步工具返回了结果，或你补充了一句信息。
做法是：先把事件放到队列末尾，不打断当前操作；等当前这轮完成，队列非空就一次性全部追加给模型。
好处是批量处理，省往返。比如它调搜索工具时，你补一句"只看最近一个月的"，等搜索结果回来，这两件事一起呈现给模型，一次搞定。
③ 并行式------独立的轻量查询，另起一个循环。
比如它正分析海量数据，你突然问："今天天气怎么样？"
这种查询有三个特征：跟主任务无关、要快、成本低。
用取消式会打断重要工作，用队列式又让你等太久。
于是系统判断独立性后，在一个并行会话里独立执行，生成回复立刻返回；同时明确标记"与主任务并行执行"，避免模型混淆。
怎么判断"急不急"？
策略有了，那到底该怎么选？
硬编码规则当然可以，但事件的语义才决定处理方式：
›
"马上停下来" → 取消式
›
"今天天气怎么样" → 并行式
›
"报告记得用中文发我" → 队列式
所以更聪明的做法是：用一个轻量级的分类小模型当"事件路由器"，事件一到达，快速判断该走哪条路。
还有个细节要特别小心：取消点必须是工具或推理能安全收尾的位置。 没完成的工具结果，要用显式占位符表示，绝不能伪造成功------否则模型会把"任务已启动"误当成"任务已完成"，在结果真正回来前就做出错误判断。
在批量处理里，还容易踩另一个坑：模型只回应最后一个事件，漏掉前面的要求。 解决办法是在每个事件前加显式标记，并在末尾补一句汇总："上面有 4 个未处理事件，请确保回应涵盖所有信息。"
从"收到"到"可靠"：原生异步的出现
前面这套是"兼容派"------运行时替你把事件排好队，让只能用同步接口的模型也能参与异步任务。
而另一条路线是"原生派"：让模型自己就懂这种节奏。
GPT-6 Astra 已经支持两项关键能力：
›
异步工具调用：把"发起行动"和"获得结果"分开。发起一个耗时查询后，模型可以先去做不依赖它的部分，等结果回来再接上。
›
回合中途引导：你可以在它思考或组织回答的过程中，就追加"预算减少了""参会人数变了"这样的新约束，它保留已完成的工作，把新要求带进后续处理。
这里藏着一个很妙的设计思想：从工具的名字开始，就传递异步语义。
传统的 phone_call 暗示"调用就会拨号并等通话结束"。而在异步范式下，应该把"启动"和"完成"解耦，比如改叫 initiate_phone_call，并明确告诉模型：
"此工具启动一个由子 Agent 处理的电话任务，发起成功后立即返回任务 ID，你可以继续处理其他事项；通话结束后会收到单独的通知事件。"
模型看到这个名字和描述，自然就懂：这是"发起"，不是"完成"。
不过要提醒一句：修改计划，不等于停止正在运行的工具，更不会自动撤销已经发生的动作。 真正的执行、取消和状态管理，仍然由运行时负责。
最后一道关：可靠，比先进更重要
原生异步解决了"消息能不能在运行中到达"。
但复杂任务里，真正的可靠性还取决于模型怎么用这些消息。至少要检查三件事：
结果归属与未完成状态：延迟到达的结果，归没归对任务？结果没到，会不会编造数据？
任务恢复与动作控制：处理完新要求，还能不能继续原任务？分得清"改计划"和"停执行"吗？
多条更新的综合使用：能否同时遵守"预算"和"人数"，而不是只记住最后一句？
评估要覆盖两层：模型有没有理解变化，系统有没有按变化正确执行。
最后回到开头那句"停！"。
它能不能真的停下来、停得干净、停完还能接着干------这才是异步 Agent 从"能用"走向"可靠"的分水岭。