事件如何启动异步 Agent

一句话收获：长任务必须脱离模型会话，拥有独立状态、查询、取消和回执。

这个场景在解决什么问题

这个场景要讲清"事件驱动 + 异步任务"是怎么回事：一个外部事件怎么启动一个 Agent 任务，任务怎么从即时工具到异步 Job，最后怎么通过回调和用户沟通闭环。原文的做法是让一个外部事件启动任务，观察它经历的异步状态变化。它值得单独学，是因为很多人让模型"傻等"一个长任务结束，而模型会话一旦断开，任务就丢了——正确的做法是让长任务脱离模型会话、拥有自己的状态。

先理清这条判断链（文字版）

这个场景是一条"从事件到异步闭环"的链：先看事件怎么触发并完成准入，再看短操作怎么用即时工具同步完成，接着看长任务怎么变成异步 Job 独立推进，最后看回调怎么验真、更新状态、通知用户。验收标准是——能不能说清"长任务为什么必须脱离模型会话、异步闭环以什么结束"。

先看事件触发：邮件/定时器/Webhook 只提交任务意图，先做事件准入。
再看即时工具：短操作一次调用返回明确结果，仍需外部验收。
接着看异步 Job：长任务返回任务引用，由队列和执行器独立推进。
最后看回调与沟通：回调验真、更新状态、通知用户，闭环以权威状态和回执结束。

逐层详解

第 1 步：事件触发

原文：邮件、定时器或 Webhook 只负责提交任务意图。

白话：一封邮件、一个定时器、或者一个 Webhook（网络回调钩子）触发了任务，但它们只是"提交了任务意图"，不等于任务可以直接执行。

类比：像门铃响了——门铃只是告诉你"有人来了"，不代表你该直接开门，你得先看看是谁。

举例：客户发来一封"申请退款"的邮件，触发了一个事件，但系统得先验证这封邮件的来源是否可信、退款对象是不是明确、是不是重复提交。

为什么重要：事件来源和对象需要先验证——不能收到事件就照做，得先确认来源可信、对象明确、没有重复。

怎么验证（证据点）：

事件来源
对象明确
去重信息

别踩的坑（边界）：收到事件不代表任务可以直接执行——事件只是"敲门"，真正执行前要过准入这一关。

落地检查：先完成事件准入——落地时先做事件准入：验证来源、确认对象、去重，通过了再往下走。

第 2 步：即时工具

原文：短操作在一次调用中返回明确结果。

白话：如果是很短的操作（几秒内能出结果），就用"即时工具"在一次调用里直接返回明确结果，不需要额外的任务系统。

类比：像查一下天气——问一句、马上拿到答案，没必要开一个"后台任务"去跑。

举例：客户问"订单 1001 现在什么状态"，Agent 直接调用"查询订单"工具，一次调用就返回"已发货"，同步完成，不用建 Job。

为什么重要：可同步完成的动作不需要额外任务系统——能一次调用搞定的，就别上重型的异步任务系统，避免过度设计。

怎么验证（证据点）：

结果随调用返回
状态明确
回执完整

别踩的坑（边界）：调用返回不代表业务验收自动通过——工具返回了结果，不代表这个结果就通过了业务验收，验收是另外一步。

落地检查：即时工具仍需外部验收——落地时即时工具返回后，还要再过一道外部验收，别把"返回了"当成"办成了"。

第 3 步：异步 Job

原文：长任务返回任务引用，由队列和执行器独立推进。

白话：如果是长任务（要跑很久），不能靠模型一直等，而是返回一个"任务引用"（比如 Job ID），由队列和执行器在模型之外独立推进。

类比：像在餐厅点了一份要等 40 分钟的菜，服务员给你一个取餐号（任务引用），厨房自己去慢慢做，你该干嘛干嘛，过会儿拿号来问进度。

举例：客户申请"批量导出 10 万条订单"，Agent 提交一个异步 Job，拿到 Job ID，任务进队列由执行器慢慢跑，模型会话可以先结束，回头用 Job ID 查进度。

为什么重要：模型会话可能结束，任务生命周期不能丢失——因为模型会话随时可能结束，长任务必须有自己的状态，不能依赖"模型一直等着"。

怎么验证（证据点）：

Job 可查询
进度可见
支持取消

别踩的坑（边界）：模型持续等待不是可靠异步机制——让模型一直等着长任务结束，是不可靠的，会话一断任务就悬了。

落地检查：长任务状态位于模型外——落地时把长任务的状态放在模型外的队列/执行器里，模型只拿到一个可查询、可取消的任务引用。

第 4 步：回调与沟通

原文：回调验证来源和当前状态，随后更新任务并通知用户。

白话：任务完成后，通过回调把结果送回，先验证回调的来源和当前状态，然后更新任务状态，最后通知用户。

类比：像快递送到后给你发短信——但系统得先确认"这短信真是快递系统发的（验来源）""包裹确实签收了（对状态）"，再更新订单状态，最后才通知你。

举例：批量导出完成后，回调触发，系统先验证回调来源可信、确认导出任务当前是"进行中"才接受，然后把它更新为"已完成"，最后通知用户"导出完成，可下载"。

为什么重要：事件结果需要重新进入受控 Loop——回调结果不能直接信，要验真后重新进入受控的循环（Loop，指 Agent 的受控决策循环）里处理。

怎么验证（证据点）：

回调验真
状态更新
通知有依据

别踩的坑（边界）：通知发送不等于业务完成——给用户发了"已完成"的通知，不代表业务真的完成了，通知要有真实状态和回执做依据。

落地检查：异步闭环以权威状态和最终回执结束——落地时把"闭环完成"的标准定为：权威状态已更新 + 拿到了最终回执，而不是"通知发出去了"。

落地可行性小结

本场景涉及的技术栈：事件源（邮件/定时器/Webhook）、事件准入、即时工具调用、异步 Job（队列 + 执行器 + Job ID）、回调验真、状态更新、用户通知。真实落地做法：短操作走即时工具、长操作走异步 Job；长任务的状态独立于模型会话，用队列/执行器推进，给模型一个可查询、可取消的 Job 引用；回调回来先验来源、对状态，再更新、再通知。要检查的：事件是否做准入去重、长任务是否支持查询和取消、回调是否验真、通知是否有权威状态和回执依据。常见坑：让模型傻等长任务、收到事件就执行、把通知发出当业务完成、回调不验来源。

回顾

事件（邮件/定时器/Webhook）只提交任务意图，要先做准入验证和去重。
短操作用即时工具一次调用返回，但仍需外部验收。
长任务必须脱离模型会话，变成异步 Job，拥有独立状态、查询、取消。
模型持续等待不是可靠的异步机制。
异步闭环以权威状态 + 最终回执结束，通知发出不等于业务完成。