设想 AI 帮忙发文章：点了发布，页面一直转圈。它等了一会儿，决定再点一下。
平台收到两次请求，后台多出两篇一样的文章。AI 以为自己在排障，作者得去处理重复内容。
这个假设场景里，最该问的是：第一次到底成功没有？页面没告诉我们，不代表平台没做。
回应丢了，文章可能已经发了
一次发布至少有三个不同阶段：请求发出、平台处理、结果返回。用户通常只能看见最后那个提示。
假设平台已经创建文章，但是返回结果时网络断了。你的电脑不知道成功了，文章却已经存在。这时候再创建一次，如果服务端不识别重复请求，就可能多出一篇。
超时只说明我没按时拿到结果。至于平台有没有创建文章，还得查。
可以想象给餐厅打电话订餐。你说完地址，对方已经写了单，电话突然断线。你再打过去，如果直接重新报一遍而不先确认前一单，就可能收到两份午饭。
传统程序会重试，消息队列会重投，用户会连点，多个工作进程也可能同时领取同一个任务。
AI 多了一层"自主判断下一步"：看见报错，它可能换工具、换参数、换入口，再尝试一次。如果系统只鼓励"坚持把任务完成"，却没告诉它哪些动作会改变外部世界，它就可能把读页面和发文章当成同一种可重试操作。
只提醒 AI"小心一点"不够。哪些动作可以重试、已经试过什么、结果不明时怎么查，程序里都得有相应安排。
AWS 的工程资料专门讨论了如何用幂等 API 让自动重试更安全，强调同一次意图在重复请求时不应产生额外副作用。1 做 Agent 也可以参考这套已有做法。
重试时，别换办事单号
同一操作重复执行，对相关业务状态的效果与执行一次相同，这是幂等的核心含义。
把开关"设置成关闭"，执行两次仍是关闭；把开关"切换一下"，执行两次却可能回到开启。字面都在操作开关，语义完全不同。
创建文章一般不能天然假设幂等。发出两次"创建"可能就是两篇。你需要让系统分得清：这次是同一个请求的重试，还是用户真的想再发一篇。
幂等键就像办事单号：第一次办这件事时生成，后续重试带同一个单号。服务端看见办过，就返回已有结果，而不是再办一份。
重试时要沿用原单号。 每次都换号，服务端看到的自然都是新任务。也不要只用文章标题作为单号，同名文章未必是同一篇。
一个发布任务的意图，至少涉及账号、平台、文章版本和操作类型。把 A 平台的成功当成 B 平台的成功，或者把旧稿的结果当成新稿的结果，都会弄错。
我会先持久化一条发布任务，给它稳定编号；账号、目标平台和稿件版本明确记录。内容发生实质变化，要创建新的任务版本，而不是偷偷沿用原来的请求记录。
还需要记录请求内容的摘要，用来检查"同一个编号，参数却变了"。这不是要求把隐私内容塞进编号，而是保持编号随机、业务信息单独存储。
Stripe 的 API v1 文档给出了一个具体实现：相同幂等键重试返回保存的响应；参数不一致会报错，键被清理后再次使用可能被当成新请求。2 使用前要查清作用范围、保存期限和服务端约定。
不同服务实现不同，不能看到请求头里能加一个字段，就假设对方真的提供幂等保证。
平台成功了，本地却没记上
还有一种情况，即使自己建了任务数据库也会遇到：
- 本地记录：准备发布。
- 远端平台：创建成功。
- 程序崩溃，来不及把远端文章编号写回本地。
- 重启后只看本地，发现"还没成功"，于是又发一次。
本地数据库和远端发布没有自动组成原子事务。平台创建成功、本地却没记下来，这个空档依然存在。
如果远端支持幂等请求，同一任务重发时用原键，可以利用其约定恢复结果。如果远端不支持，就要先查远端状态；能确认已有作品，再补全本地记录。
如果查不到，也不能立即宣布失败。平台可能延迟展示，检索可能不完整。对不可安全重试的操作，应把它标记为"结果未知"，再核对或交给人处理。
只能点网页，就回作品管理核对
这是内容创作者最容易遇到的版本。你能控制浏览器点击，但未必能改平台后端，也不能要求平台接受你发明的请求头。
这种情况下，发布后核对作品记录这一步就不能省。
操作前保存当前稿件的目标平台、账号、版本和已有草稿标识；操作后观察成功页或作品管理记录，取得作品编号、链接和状态。遇到转圈或超时，先查结果，再决定要不要继续。
截图有用，但要配上身份信息。一张没有标题、账号和时间背景的"发布成功"截图，可能证明的是另一篇文章。标题也只能辅助查找，平台给出的稳定编号更可靠。
如果已进入审核，任务可以记录为"提交成功，审核中"。审核中不是没有发布请求，也不应该触发重新创建。平台驳回、草稿保存和最终公开，又是不同状态。
我不会把这套观察流程称作严格的"恰好一次发布"。没有服务端配合、可靠查询和去重约束，就不能凭浏览器自动化保证所有故障场景都不重复。
假设 CSDN 成功，小红书上传失败，抖音还在审核。一个总开关显示"同步失败"，最危险的操作就是把三个平台全部再来一遍。
应该为每个平台维护独立任务：目标账号、稿件版本、当前状态、外部编号、最后观察时间。只恢复失败或未知的那一个，已经确认成功的不要再创建。
尤其要区分文章、图文和视频。三者不是同一个上传动作，也未必共用同一套封面、正文和审核流程。某个平台已保存草稿，不代表另一平台已经公开。
这里同样不把某款同步插件的界面错误当成重复发布证据。界面报错只能说明有一个环节出了问题，具体结果要回目标平台核对。
写代码时，这几步别省
下面是流程示意，不是可以直接复制上线的完整代码。存储层还需要唯一约束、并发控制，以及对领取任务进程的故障恢复。
text
读取持久化任务 task
如果 task 已确认成功：返回已有作品编号
如果同一任务参数变化：拒绝复用，要求新版本
获取任务执行权，避免多个进程同时提交
如果远端支持幂等：用原 request_key 提交或重试
否则如果此前已经提交过：先查远端，不能直接再创建
确认成功：保存远端编号、时间与可核对证据
结果不明确：标记 UNKNOWN，进入核对流程
明确失败：按该错误类型决定重试或人工处理"获取执行权"不能只写成进程内的布尔变量，多进程和重启时它会失效。租约、唯一约束等机制如何配合，需要按数据库和工作队列设计；执行权过期，也不代表旧进程的远端请求一定停止了。
本地锁约束的是自己的进程，远端去重仍要靠远端的能力。
网络临时故障可能适合重试，参数写错通常需要改参数，缺权限需要补权限。已经明确成功的操作则不应该因为后续日志写入失败而重新创建。
重试次数、等待间隔和总预算应该受控。否则上层重试几次，下层又重试几次，外加模型自己再试，调用量可能迅速放大。
对于有副作用的操作，要先判断是否具备安全重试条件。增加等待只能减少频率，不能把不安全操作变成幂等操作。
我会优先测试五种情况：结果返回前断网、远端成功后本地崩溃、两个进程同时处理、同一编号参数变化、任务恢复时仍在审核。这些比只测"正常点击一次成功"更能暴露问题。
回到发文章这件事：页面转圈时，先去作品管理查。已经有作品编号，就记下编号和状态；确认失败，才判断能不能重试；查不清，先留在"未知"。多花一点时间核对，总比把同一篇文章再发出去好。
资料与说明
1 AWS Builders' Library：Making retries safe with idempotent APIs。
2 Stripe：Idempotent requests。本文涉及保存响应及键清理的描述针对其 API v1，不外推到所有 API 或平台。
流程和漫画用于解释工程原理。资料核对：2026-10-23。
个人原创，转载说明出处。