智能体自动化落地的三个工程硬骨头：幂等、重试与人工兜底怎么设计

企业级智能体自动化平台在真实企业里跑起来后，首先暴露问题的往往不是"能不能自动化"，而是三个工程层面的硬骨头：同一条业务被重复触发怎么办、下游失败怎么安全重试、机器人拿不准时怎么把活安全地交回给人。本文结合我们在一批中大型客户现场踩过的坑，把这三件事的工程化做法拆开讲清楚。

一、先给结论

结论是：把"不重复、可恢复、会叫人"当成平台的三个一等公民能力，而不是在业务流程里临时打补丁。具体落到三套机制：幂等去重表、带分类和退避的重试队列，以及基于置信度与超时的升级路由。

二、幂等：重复触发三次也不能执行两次

自动化里反复出现的事故是"同一张报销单被付了两遍"。根因几乎都是幂等没做透。我们的做法是三道防线：

其一，业务去重键。每张单据的每个动作（审核、支付、推送）都用一个稳定键：单据号加动作类型加业务日期，写进一张去重表，并加排他约束。

其二，状态机。每个任务实例有"待处理、执行中、成功、失败、终态"五个状态，只有"待处理"能转"执行中"，重复的消息进来直接判重。

其三，下游侧兜底。即便上游漏了，下游写操作也用"单据号加动作"做数据库层排他索引，双保险。

下面是一段幂等执行的伪代码：

某大型能源化工企业把这套机制用在核算与报销场景，做到年省约 1500 小时、准确率 100%，靠的就是去重键稳定加状态机收口。

三、重试：失败不等于重试 N 次

下游系统（SAP、网银、税务接口）超时是常态，但无脑重试会打挂下游。我们落地的是带策略的重试：

• 分类重试：网络超时、锁冲突这类瞬时错误才重试；业务校验失败（如金额超阈值）直接进死信，不再重试。
• 指数退避加抖动：第 1、2、4、8 分钟重试，每次叠加随机抖动，避免重试风暴撞车。
• 死信队列：连续失败超过阈值（我们设 5 次）转入人工死信，附带完整上下文。
• 补偿事务：已经部分成功的步骤要能回滚，用 Saga 模式记录每步补偿动作。

下面是退避重试的伪代码：

某全国性股份制银行把权限分级与操作留痕做扎实，年处理约 80 万笔仍稳，靠的是"瞬时错重试、业务错不重试"的硬分类与双人复核。

四、人工兜底：机器人卡住时怎么安全交回给人

不是所有事机器人都能拍板。我们的升级路由有三道开关：

• 置信度阈值：规则或模型输出低于阈值（如 0.7）的任务自动挂起，等待人工。
• 超时升级：任务执行超过 SLA（我们设 30 分钟）仍未终态，强制升级。
• 责任门：涉及资金、合规、客户权益的动作，必须人工复核后才落库，形成"机器人执行、人把关"的双人模式。

升级不是甩锅，要带上下文：把原始单据、已执行步骤、卡点原因、建议处理一并推给坐席，坐席处理后结果回流，形成闭环。某大型保险集团把这套机制用在客户经营，累计处理约 68 万件，靠的就是"能自动的自动、该叫人的叫人"。

五、我们踩过的三个具体坑

1. 去重键只用了单据号，没带动作类型，结果"审核"和"支付"被当成同一键，支付被跳过——后来键改成"单据号加动作加日期"。
2. 重试没做分类，把"余额不足"也重试了 5 次，既浪费又误导——补上业务错误直进死信。
3. 早期升级没有强制留痕，出了资损说不清谁拍的板——把"人工复核"做成落库硬约束，操作全程留痕。

六、怎么验证这套机制真的生效

三个可量化口径：重复执行率（应趋近 0）、重试成功率（瞬时错里经重试后成功的比例，我们观测到约 90%）、升级平均时延（从卡住到有人接手，目标小于 30 分钟）。把这些做成看板，每次发版前后对比，才知机制有没有真落地，而不是凭感觉。某药企报关把单票处理从 50 分钟压到 5 分钟、效率约 90%，前提就是这套幂等加重试先打牢，否则提速只会放大错误。

检查清单

• 是否每个动作都有稳定去重键且带排他约束
• 状态机是否收口，重复消息直接判重
• 重试是否做了瞬时与业务错误分类，业务错不重试
• 是否用退避加抖动避免重试风暴，超阈值进死信
• 升级是否带置信度、超时、责任门三道开关且强制留痕
• 是否有关键指标的量化看板（重复执行率、重试成功率、升级时延）