最近用ChatGPT、Codex排查异步任务问题时，有一类故障特别容易让人误判：

接口已经返回：

200 OK

或者：

task submitted successfully

前端也提示：

操作成功。

但过了几分钟再去看结果，却发现：

文件没有生成。

数据没有同步。

任务没有执行完。

甚至后台日志里直接显示：

FAILED

于是就出现一个很反直觉的现象：

接口明明成功了，业务为什么还是失败了？

很多人看到这里，会先怀疑：

Worker不稳定。

消息队列有问题。

后台服务挂了。

但真正应该先搞清楚的是：

接口返回成功，到底代表哪一种“成功”？

因为在异步系统里：

Accepted ≠ Completed。

接口成功，很多时候只说明：

任务已经被接收。

并不代表：

任务已经真正完成。

---

一、一个很真实的场景：文件导出接口已经成功，但文件根本没有生成

假设系统里有一个报表导出功能。

用户点击：

“导出最近一年的订单。”

接口很快返回：

HTTP 200
{
  "success": true,
  "task_id": "job_1024"
}

前端马上显示：

导出成功。

但真实后台流程可能才刚刚开始：

创建任务
↓
写入队列
↓
Worker领取
↓
查询数据库
↓
生成Excel
↓
上传对象存储
↓
写回文件地址

接口返回的时候，

真正完成的可能只有前两步：

创建任务
写入队列

后面任何一个环节都可能失败。

比如：

数据库查询超时。

Worker进程崩溃。

文件生成异常。

对象存储不可用。

权限不足。

磁盘空间不够。

所以：

“提交成功”只是异步任务生命周期的开始。

---

二、为什么ChatGPT、Codex特别容易在这里提前判断“已经成功”？

因为Agent排查问题时，很容易看到：

response.status == 200

然后得出：

接口正常。

如果代码里还有：

enqueue(job)
return success

它可能进一步判断：

任务已经成功提交，没有明显问题。

但真正需要检查的是：

enqueue(job)

以后发生了什么。

也就是说：

同步调用成功，只能证明入口没有报错。

异步任务真正的业务结果，发生在另一个时间、另一个进程，甚至另一台机器上。

如果Agent只盯着HTTP响应：

它看到的只是任务入口。

而不是完整任务。

---

三、异步任务至少应该有一套明确状态机

一个比较完整的后台任务，不应该只有：

success / failed

更合理的是：

PENDING
↓
RUNNING
↓
SUCCEEDED

失败时：

FAILED

某些场景还可能有：

RETRYING
CANCELLED
TIMEOUT

这个状态机很重要。

因为它区分了：

任务已经接收

和：

任务已经完成。

例如接口返回：

task_id = job_1024
status = PENDING

这时候前端应该告诉用户：

任务已提交。

而不是：

任务已完成。

这一句话看起来只是文案不同，

实际上背后代表完全不同的系统语义。

---

四、200和202为什么不能随便混着用？

很多系统喜欢：

只要接口没报错，就统一返回200。

技术上未必一定错。

但语义上容易误导。

如果一个请求只是：

接受任务。

真正处理稍后完成。

那它更接近：

202 Accepted

也就是：

我已经接受这个请求，但处理还没有结束。

这时候调用方应该继续：

查询状态。

等待Callback。

订阅事件。

直到任务进入：

SUCCEEDED

才真正宣布完成。

所以异步任务最重要的一条原则就是：

接口响应状态，不能替代业务最终状态。

---

五、为什么“已经入队”也不代表任务一定会完成？

很多人看到消息已经进入队列，就觉得：

那后面肯定会跑。

也不一定。

因为队列只是把任务交出去。

后面还有：

Worker有没有存活。

消费者有没有拿到任务。

执行过程中有没有异常。

失败后有没有Retry。

Retry次数是否耗尽。

最终有没有进入Dead Letter Queue。

比如：

API成功
↓
任务进入队列
↓
Worker开始执行
↓
调用第三方API
↓
Timeout
↓
Retry 3次
↓
FAILED

从API视角：

整个过程一直都是“成功提交”。

但从业务视角：

任务最终失败。

所以真正需要观察的是：

Final State——最终状态。

---

六、最危险的情况：系统没有保存最终任务状态

有些系统只是：

接口把任务丢进队列。

然后就不管了。

这样一旦后台失败：

调用方甚至不知道失败发生过。

用户看到：

“提交成功。”

后台看到：

一条异常日志。

但系统之间没有任何关联。

这时候就会形成：

Silent Failure——静默失败

这是比直接报错更麻烦的问题。

因为：

任务看起来成功。

没有人重试。

也没有人处理。

结果就悄悄丢了。

所以异步任务至少应该保存：

task_id
status
created_at
started_at
finished_at
error
retry_count

这样任务从开始到结束才真正可追踪。

---

七、ChatGPT、Codex排查时，第一步不要盯HTTP响应

遇到这种问题，我建议先把任务拆成两段。

同步阶段

客户端
↓
API
↓
创建任务
↓
写入队列
↓
返回task_id

异步阶段

Worker领取
↓
执行任务
↓
处理外部依赖
↓
保存结果
↓
更新最终状态

然后分别确认：

同步阶段有没有成功？

异步阶段卡在哪一步？

不要把：

HTTP 200

当成整条链路的成功证明。

---

八、第二步：拿task_id一路追到底

一个设计良好的异步系统，应该能够根据：

task_id

查完整链路。

例如：

job_1024

10:01 PENDING
10:02 RUNNING
10:04 RETRYING
10:06 FAILED

然后进一步看：

失败发生在哪一步？

错误是什么？

已经重试几次？

有没有产生部分副作用？

如果系统连task_id都无法贯穿：

API。

Queue。

Worker。

日志。

数据库。

那么排查成本会非常高。

所以Agent排查异步任务时，很重要的一件事就是：

先建立完整Task Trace。

---

九、为什么Retry也可能制造新的问题？

异步任务失败以后，经常会自动Retry。

这本身没问题。

但如果任务不是幂等的：

重试可能产生重复副作用。

例如第一次执行：

订单已经创建。

但更新任务状态时失败。

Worker认为任务失败。

于是再次Retry。

第二次又创建一笔订单。

最后任务状态可能变成：

SUCCEEDED

但数据库里已经多出两份数据。

所以异步任务的完整设计不能只有：

状态机 + Retry。

还必须检查：

这个任务能不能安全重试。

这和之前讲过的幂等问题其实是一条线。

---

十、真正的“成功”应该怎么验证？

假设任务是：

生成报表。

那真正成功不应该只是：

worker returned success

而应该确认：

文件真的生成。

文件可以读取。

地址已经保存。

用户能够访问。

如果任务是：

同步数据。

真正成功应该确认：

目标系统里出现预期数据。

如果任务是：

部署。

真正成功应该确认：

目标版本上线。

Health Check正常。

也就是说：

最终成功必须对应一个可验证的业务结果。

而不是某个函数没有抛异常。

---

十一、Callback、Polling和Event，本质上都在解决同一个问题

异步任务完成以后，调用方怎么知道？

一般有几种方式。

Polling

客户端定期查询：

GET /tasks/job_1024

直到：

SUCCEEDED

或者：

FAILED

Callback

任务完成以后，后台主动通知调用方。

Event

任务状态变化以后发布事件：

TaskSucceeded
TaskFailed

具体用哪一种要看系统场景。

但目标是一样的：

把最终状态传回去。

否则调用方只能知道：

“我刚才提交过一个任务。”

却不知道：

“这个任务到底有没有做完。”

---

十二、Agent为什么特别需要“最终状态”？

因为以后ChatGPT、Codex越来越可能自己调用异步工具。

比如Agent调用：

run_ci()

接口返回：

submitted

如果Agent把它理解成：

CI passed

那后面的判断全部可能出错。

真正正确的流程应该是：

提交CI
↓
获得job_id
↓
等待任务完成
↓
读取最终结果
↓
验证测试结果
↓
继续下一步

所以异步系统越多：

Agent越需要理解：

提交成功和执行成功是两个不同状态。

---

十三、给自己测一个指标：假成功率

这篇我建议只看一个指标：

False Success Rate——假成功率

统计那些：

接口已经返回成功或者“任务已提交成功”的异步任务。

然后看最终有多少实际上失败。

例如：

100个任务都返回：

submitted successfully

最终有4个进入：

FAILED

那么：

假成功率 = 4%。

这个指标非常直观。

它反映的是：

系统前端看起来有多成功，

和后台真正完成多少，

之间到底有多大差距。

---

十四、假成功率高，最应该先解决什么？

如果这个指标比较高，

优先检查：

任务状态机是否完整。

有没有最终状态。

task_id能不能贯穿整个链路。

Worker失败有没有记录。

Retry是否可靠。

Retry是否幂等。

最终结果是否可验证。

前端有没有把“已提交”错误写成“已完成”。

不要第一反应就是：

让Agent反复重跑后台任务。

因为真正的问题可能是：

系统根本没有把任务生命周期设计完整。

---

十五、Plus和Pro怎么判断？

如果你的假成功率还比较高：

接口经常显示成功。

后台任务却：

失败。

卡住。

静默丢失。

最终状态无法确认。

那当前真正限制效率的不是ChatGPT、Codex容量。

而是：

异步任务的完成闭环还不可靠。

这种阶段Plus通常已经足够。

更值得先完善：

任务状态机。

最终结果验证。

失败回传。

Retry。

幂等。

Task Trace。

否则提高更多AI容量，

只是让Agent更快地产生更多：

“看起来已经成功”的任务。

---

如果你的假成功率已经长期接近0：

Agent提交异步任务以后：

可以自动跟踪状态。

确认最终结果。

失败能够恢复。

重试不会产生重复副作用。

同时大量复杂工程任务持续排队，

AI执行容量才真正开始成为瓶颈。

这时候Pro才更容易放大实际效率。

因为Agent依赖的是：

一个能够确认任务真正完成的工程闭环。

---

最后

接口返回成功，

并不一定代表业务完成。

在异步系统里，

真正需要区分的是：

Accepted

和：

Completed。

一个任务进入队列，只说明有人接单。

Worker开始执行，也不代表一定完成。

只有当：

任务进入最终状态。

业务结果可以验证。

调用方真正知道结果。

这条链路才算闭环。

所以以后让ChatGPT、Codex排查这类问题时，

不要只问：

“接口为什么已经返回200？”

更应该继续问：

“这个task_id最后去了哪里？”

很多所谓：

“接口成功了，但业务没成功”

的问题，

真正缺失的都不是某一行代码。

而是：

最后那一步完成确认。

持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。