Responses API 取消任务：后台请求怎么中止

任务边界与前置条件

资料包确认，Responses API 的 cancel 方法对应 POST /responses/{response_id}/cancel，但只有创建时将 background 设置为 true 的响应才支持取消。普通同步请求不要把取消按钮误接到这条流程上。

建议在自己的任务表中至少保存以下字段：

• 业务任务 ID、文章或批次标识。
• response_id、创建时间、请求模式和当前状态。
• 取消发起人、取消时间、取消原因和最后一次查询结果。
• 已收到的增量正文、最终正文位置和归档状态。

取消流程与状态同步

1. 创建后台请求。提交写作输入时设置 background: true，同时生成自己的业务任务 ID。不要等到用户点击停止后才补记关联关系。
2. 保存响应标识。收到响应后立即保存 response.id，并将本地状态设为“处理中”。response_id 为空时停止后续操作，先记录接口异常。
3. 读取最新状态。用户发起中止前，先用保存的响应标识调用 retrieve。以接口返回的最新状态为准，不要只相信页面缓存。
4. 判断是否仍可取消。只有仍在处理、且创建时确实启用了后台模式的任务，才显示取消动作。已完成、已失败或已取消的任务改为只读。
5. 提交取消操作。调用 SDK 的 client.responses.cancel(response_id)，或由服务端向 /responses/{response_id}/cancel 发起 POST 请求。取消动作应由服务端执行，不把密钥放进浏览器。
6. 同步最终状态。取消请求返回后，不要直接把本地状态写成“已取消”。再次 retrieve，并保存接口返回的状态、时间和可能存在的输出。

状态表设计

具体操作示例

例如编辑提交一篇长文，系统先创建后台响应并保存 resp_abc。几分钟后，编辑点击取消。服务端先查询该标识：若仍处于处理中，就写入“取消中”并调用取消方法；随后再次查询。如果最新状态为已取消，系统保存已收到的草稿片段，但将发布按钮保持为禁用。如果查询发现任务已经完成，则不再发送取消请求，而是转入正文完整性检查。

这个例子中，取消请求和任务状态是两件事：前者表示系统发起了动作，后者才表示远端任务的最终结果。

常见故障与修正动作

• 取消接口提示任务不支持。原因通常是创建请求没有设置 background: true。修正动作是让取消按钮只针对后台任务开放，并为非后台请求使用客户端连接关闭或页面状态结束等独立策略，不要冒充远端取消。
• 重复点击产生多次取消请求。原因是前端没有锁定按钮，或服务端没有检查本地状态。修正动作是使用任务 ID 做幂等控制，进入“取消中”后拒绝相同任务的重复提交。
• 页面显示已取消但接口仍在处理。原因是只根据取消请求的返回结果更新页面。修正动作是把任务先设为“取消中”，再查询最新响应，必要时记录重试和超时。
• 取消后仍出现部分正文。原因是请求可能已经产生了部分输出。修正动作是保留原始输出，明确标记为未完成草稿，禁止自动发布，并由编辑决定是否人工续写。
• response_id 找不到。原因可能是标识未持久化、传入了错误任务的标识，或请求记录被覆盖。修正动作是以业务任务 ID 和 response_id 双向校验，保留原始请求日志后再排查。

发布前验收清单

1. 创建请求中已明确设置后台模式，且任务表保存了 response_id。
2. 取消按钮只对仍可取消的任务显示，已完成和已失败任务不会重复提交。
3. 取消请求由服务端发起，密钥、原始输入和响应日志没有暴露给浏览器。
4. 取消后经过再次查询，本地状态与最新远端状态一致。
5. 已产生的部分输出已保存，但被标记为草稿或未完成，不会误发布。
6. 取消人、时间、原因、请求结果和错误信息均可追溯。
7. 批量任务逐条核对，没有因一条任务取消而误改其他任务状态。
8. 正常完成、取消、接口失败、重复点击和 response_id 缺失场景都已用测试任务验证。

若后台还需要保存响应、查询记录与删除审计，可参考Responses API 长篇写作后台任务的处理思路，但取消流程仍应以当前接口返回的最新状态作为最终依据。