原生异步把哪两件事拆开？
- 异步工具调用（Async tool calling）: 把“发起行动”与“获得结果”分开;
- 行为: Agent 发起耗时查询后可继续推理、调用其他工具，或处理不依赖查询结果的部分;
- 例子: 查询会议场地时先整理议程与准备清单，等场地信息返回再比较方案;
- 关键动作: 分清工作的依赖关系——能独立推进的继续做，必须依据结果的决策留到结果到达之后;
回合中途引导改变了什么？
- 回合中途引导（Mid-turn steering）: 用户可在 Agent 仍在思考或组织回答时追加“预算减少了”“参会人数变了”等要求;
- 机制: 系统保留已完成的工作，把新的约束带入后续处理，使 Agent 在同一次任务中调整计划;
- 收益: 用户不必等一整轮回答结束才表达变化；接收到更新与作出调整之间仍可能有延迟;
- 本质: 这两种能力扩展的都是交互的时机——工具结果与用户要求都可以在任务推进过程中到达;
原生异步系统仍需运行时负责哪些事？
- 来源区分: 系统仍要分清事件来自工具结果还是用户要求;
- 状态记忆: 记住哪些工作已经完成、哪些还在等待;
- 语义澄清: 修改计划不等于停止正在运行的工具，更不会自动撤销已经发生的动作;
- 职责划分: 实际执行、取消与状态管理仍由运行时负责，模型能力不能替代运行时编排;
从“能接收异步消息”到“可靠处理异步任务”要检查什么？
- 检查一 结果归属与未完成状态: 能否把延迟到达的结果归入正确任务，在结果缺席时避免编造数据;
- 检查二 任务恢复与动作控制: 能否在处理新要求后继续原任务，并区分修改计划与停止执行;
- 检查三 多条更新的综合使用: 能否同时遵守预算与人数等约束，而不是只记住最后一条消息;
- 改进路径: 异步环境中的训练可改进模型；清晰的任务状态、事件来源与执行反馈可改进系统;
- 评估覆盖面: 评估需要同时覆盖两层——模型是否理解了变化，系统是否按变化正确执行;
原生接口与兼容方案如何选择？
- 选择依据: 构建 Agent 时根据模型的支持范围选择原生交互或兼容方案;
- 后备检查: 无论选哪条路线，都要检查整个系统能否正确应对延迟返回、中途修改与任务恢复;
- 常见误判: 代码使用异步语法、或模型经过异步训练，都不等于系统已经具备可靠处理异步任务的能力;
- 展开位置: 兼容同步接口的实现规则见 同步接口的异步兼容方案，事件循环与安全点见 结构化事件建模与处理策略;