很多人第一次把智能体接进自己系统时，都按普通 HTTP 接口的思路写：发请求，等响应。问题是 Agent 干的活经常不是秒级的——一条链路里有检索、有多轮模型调用、有外部工具，跑个一两分钟很正常。我们有个"竞品周报生成"的流程，要抓七八个来源再汇总，单次三分多钟。同步等是不可能的，网关 60 秒就把你掐了。

说说我现在的异步化套路，供参考。

1. 任务提交和结果获取拆开。 调用方提交任务，立刻拿到一个 task_id 返回，连接就断。Agent 那头慢慢跑，跑完把结果落到一个地方（我直接写数据库表，结果是 JSON 一整坨）。

2. 拿结果用轮询还是回调，看调用方是谁。

• 给前端页面用：轮询。每 3 秒查一次状态接口，状态机就四个值 pending / running / done / failed。简单可靠，别上来就 WebSocket，没必要。

• 给后端系统用：回调。任务提交时带一个 callback_url，跑完往回 POST。注意回调要做重试（我设的 3 次，间隔 10s/60s/300s），对方服务抖一下结果就丢了的设计不能要。

3. 把"跑到哪了"也暴露出来。 长任务最磨人的体验是黑盒等待。我让流程里每个大节点跑完都更新一次进度字段（"已抓取 5/8 个来源"），前端轮询时顺带展示。用户能看到进度，等三分钟也不焦虑；看不到，等 30 秒就开始骂。

4. 超时和重复提交要兜底。

• 任务级超时：超过 10 分钟还在 running 的直接标 failed，否则僵尸任务越积越多。

• 幂等：同一个用户同样的参数 5 分钟内重复提交，返回已有 task_id。手抖双击的人比你想象的多。

顺带说下平台侧。我的 Agent 是在一个零代码编排平台上搭的，发布出来就是个 API，本身不替你管这些异步语义——它管"流程怎么跑"，提交/轮询/回调这层壳还得自己包。一开始我嫌麻烦，后来想通了：这层壳是你系统的边界，本来就该攥在自己手里。包一次之后，后面再加几个长任务 Agent，复用同一套壳就行了。

状态表的 DDL 和回调重试的伪代码放评论区。你们的长任务都怎么处理的，有用消息队列做这层的吗？

（工具是讯飞星辰，MaaS 那套把模型和算力都托管了，我没碰一点底层。）