AI随心创
先说结论
Agent 的补偿应只处理本次动作可确认的影响，并由业务服务在当前权限、记录版本和业务状态均符合条件时原子执行。人工已修改同一对象、原操作是否成功尚不明确，或系统缺少条件写入与结果查询能力时，应暂停自动补偿并核对；不能恢复整条旧快照，也不能拿到最新版本后强行重试。
读完你会得到
- 前向动作的成功凭据决定能补偿哪个对象、哪个影响范围。
- 补偿有独立业务意图、请求标识和结果状态；它本身也可能失败。
- 版本冲突后先保留当前状态。是否重拟补偿，需要业务判断和重新授权。
Agent 为一次任务创建了业务预留，人工随后调整了数量，另一个系统却返回失败。此时自动清理如果恢复旧快照，就可能抹掉人工刚完成的工作。本文只解决这类已产生外部写入、又遇到并发修改的补偿问题。
先判断业务上是否需要补偿
本文适合正在接 CRM、ERP、工单或库存接口的 FDE、应用工程师和流程负责人。前提是流程允许短暂的跨系统不一致，且业务已定义哪些动作可以取消。单库内能够用事务完成的修改，优先在该事务内处理。
Microsoft 的补偿事务文档指出：补偿需要考虑其他并发工作，也未必把系统恢复到最初状态；补偿自身可失败，需要记录进度并支持重复处理。
某一步超时，先确认它有没有完成。可以继续原业务流程、换用业务认可的替代方案，或等待人工判断时，不必马上撤销此前全部动作。已发送的消息、已交付的实物等效果，也不能靠改回数据库字段消除。
一条预留记录，为什么不能直接清空
教学场景：任务 T-71 需要在系统 A 创建一条预留，再在系统 B 完成后续登记。业务规定：只有仍属于本次任务、保持原数量且尚未被接管的预留，才允许自动取消。数量单位统一为“件”。
| 时点 | 发生的事 | 系统 A 的当前事实 |
|---|---|---|
| 1 | 任务 T-71 创建预留成功 | RES-71，qty=2，state=reserved，强 ETag="res-v18" |
| 2 | 人工把同一预留数量调整为 3 | RES-71，qty=3，state=reserved，新 ETag="res-v19" |
| 3 | 系统 B 的登记明确失败，流程要求检查是否取消预留 | 补偿计划仍持有创建成功时的 "res-v18" |
| 4 | 向系统 A 提交带原版本条件的取消请求 | 当前 "res-v19" 与期望不符，拒绝本次取消，转人工核对 |
第 4 步应留下 qty=3 的当前记录和冲突原因。若先读到新版本，再把补偿请求改成 "res-v19"，就跳过了“人工已经改变过这条预留”的保护。
本例中取消整条 RES-71 会同时取消人工调整后的预留；“只减去最初的 2 件”是否合理，也需要业务另行定义。原记录已经变化时，工程师不能替流程负责人决定剩余数量。另一任务创建的 RES-72 更不属于此次取消范围。
把前向凭据和补偿意图分开保存
前向凭据说明已经发生的事实；补偿意图说明现在申请做什么。两者通过关联标识连接。下面是最小教学记录，字段名可以按现有系统调整。
| 记录 | 需要保存的内容 | RES-71 示例及用途 |
|---|---|---|
| 前向动作 | 租户、任务、步骤和语义请求标识 | tenant-demo / T-71 / reserve / reserve-T71；避免把不同任务混成一次动作 |
| 成功凭据 | 对象标识、实际写入值、成功后的版本、外部回执 | RES-71 / qty=2 / "res-v18" / 系统 A 回执；请求已发出不能代替成功证据 |
| 影响范围 | 本次创建或改变了什么，哪些字段不属于本次动作 | 只针对 RES-71 的预留；不是整个库存数量或客户档案 |
| 补偿意图 | 具体业务动作、原因和对应前向凭据 | 取消这次预留；原因是系统 B 登记失败 |
| 补偿条件 | 预期版本、状态、归属和允许取消的其他前提 | 仍为 "res-v18"、reserved、归属 T-71，且未进入后续不可取消环节 |
| 独立请求标识 | 同一个补偿意图的稳定标识及参数摘要 | cancel-T71-RES71-1；重复投递保持同一标识，不能复用前向 reserve-T71 |
| 执行结果 | pending、succeeded、unknown、conflict 或 manual 等明确状态 | 状态名为教学约定；保留每次尝试、外部回执和最后一次查询 |
| 接管信息 | 负责团队、下一次核对时间及处置记录 | 冲突后由预留流程负责人接管；不要只在 Agent 对话里留一句报错 |
这些记录需要持久保存。前向效果与本地凭据可能不在同一事务里，存在“外部已成功、本地没记下”的窗口时，先按稳定请求标识查询业务结果；没有证据就把状态记为 unknown，不猜测对象，也不再次创建。
补偿命令的去重结果应与其业务写入形成可恢复的一致关系。外部服务负责动作时，应使用它明确支持的去重和查询合同；只在 Agent 内存里保存 cancel-T71-RES71-1，不能阻止外部重复取消。
让业务服务在写入时检查条件
调度器先读版本、随后无条件写入，两个动作之间仍可能插入一次人工更新。检查必须由拥有该业务记录的服务与写入一起完成。
- 验证当前调用者与结果查询范围
先确认身份、租户，以及对目标对象和补偿结果的读取权限。去重命中也不能跳过这些检查，避免旧回执泄露给无权查询的人。
- 在授权范围内查询已有补偿结果
以已验证的租户和补偿请求标识查询；参数摘要不一致时拒绝复用。已成功则返回允许读取的原回执；结果未知时继续查询，避免每次超时都生成一个新取消。
- 需要新写入时验证当前取消权限
重新核对当前取消权限、对象归属与允许操作范围。能查询旧结果不代表能发起新取消；前向动作曾被授权，也不代表现在仍可取消。
- 在权威服务内原子判断并更新
在同一业务写入边界内校验当前版本、状态及取消前提。符合时仅执行已定义的取消动作，并可靠保存补偿结果。若这些条件涉及多个系统，不能声称一次本地比较已锁住它们。
- 返回明确回执或冲突
成功回执关联前向动作与补偿意图。版本或业务条件不符时，不执行该取消，记录冲突并交接；权限失败也不能降级成无条件写入。
如果接口采用 HTTP 条件请求，RFC 9110 的 If-Match 使用强 ETag 比较，并要求在执行方法前判断条件。If-Match: * 只检查资源存在，不能证明记录未变化。版本不匹配时通常返回 412；规范也允许对已经应用的变更返回成功，因此客户端仍须按接口合同核对回执。
教学请求：目标仍是返回该强 ETag 的同一个预留资源。取消动作及请求去重均须由业务服务另行实现。
PATCH /teaching/reservations/RES-71
If-Match: "res-v18"
Idempotency-Key: cancel-T71-RES71-1
Content-Type: application/json
{"action":"cancel","forwardRequestId":"reserve-T71"}此处的 /teaching 路径和 JSON 是示例，不是可调用的产品 API；Idempotency-Key 的保存期限、冲突处理及查询方式也属于本例应明确的业务合同。ETag 自身不提供授权、业务取消语义或重复请求保护。
如果 ETag 覆盖整条记录，人工只改备注也可能触发冲突。这是保守而合理的结果。确实要允许无关字段更新后继续取消，应由业务服务定义更细的版本或条件，并原子检查全部相关前提，不能让模型自行判定“备注无关”后放行。
本节依据： [2] RFC Editor / IETF
用这些对照确认保护是否真的生效
| 输入条件 | 预期行为 | 应判为失败的表现 |
|---|---|---|
| RES-71 仍为 v18、qty=2，权限和业务前提都满足 | 服务端取消本次预留一次，返回可查询的成功回执 | 取消了其他任务对象，或连同整条客户/库存快照一起恢复 |
| 人工把 qty 改成 3，版本变为 v19 | 旧 v18 条件被拒绝，保留 qty=3，产生接管任务 | 读出 v19 后自动重试旧取消，或擅自把数量减为 1 |
| 人工只改备注，但接口使用整条记录 ETag | 仍按合同拒绝旧版本；需要细粒度放行时另行设计合同 | 客户端忽略冲突，认定备注不影响业务就无条件写 |
| 补偿预读后、条件写入前，人工先提交新版本 v19 | 业务服务原子拒绝旧 v18 补偿，保留人工新值 | 客户端预读检查通过后，写入覆盖了人工新值 |
| 取消成功，但响应丢失；同一取消再次投递 | 同一请求标识查询或返回原结果，不再产生第二次效果 | 每次超时换新标识，累计执行两次取消或释放 |
| 系统 A 已取消，系统 B 的清理结果未知 | 分别保留成功与未知；只核对系统 B，不宣告整体结束 | 把 A 的成功等同于所有系统都已清理 |
| 执行补偿前权限被撤销，或租户不符 | 拒绝写入并记录原因，转给有权限的负责人 | 使用前向动作的旧授权，或切到更大权限账号继续 |
| 某取消已成功，另一个无查询权限的用户用同一标识请求结果 | 先拒绝越权查询，不返回旧回执，也不执行新写入 | 仅因去重命中就返回其他租户或对象的结果 |
核对时同时查看业务记录、补偿状态和可查询回执。日志中出现“调用成功”不能证明最终业务状态正确。并发演练还要能稳定插入人工写入，单次顺序运行无法验证竞争窗口。
冲突、未知和部分完成，各自怎样收尾
| 状态 | 下一步 | 何时才算这一项结束 |
|---|---|---|
| conflict：记录或业务条件已改变 | 停止此补偿意图的自动写入；提交原始影响、当前差异及拒绝原因 | 负责人决定保留现状，或授权一项重新评估后的处理动作 |
| unknown：已发请求但拿不到确定结果 | 按原标识查询；查询服务故障时保留未知状态并告警 | 拿到可核对的成功/未执行结果；不能用等待超时推断没发生 |
| 部分完成：某些对象已处理，其余失败 | 逐对象记录结果，仅处理尚未确认的对象；按业务依赖安排次序 | 全部项目有可解释结论，或明确交给负责人；不要重复撤销已成功项 |
| manual：系统能力不足或影响不可自动消除 | 收窄自动写入范围，整理交接包，阻止依赖该结果的后续动作 | 负责人按业务流程确认处置，并留下关联记录 |
交接包至少含任务与租户、前向成功回执、补偿意图和条件、当前差异、已完成与未知的对象、负责人及下次核对时间。说明哪些后续动作已暂停，避免其他人把流程状态误读为“已全部恢复”。
负责人若决定修改处理方案，应创建可追踪的新意图，记录新的业务理由、权限与条件；不要更换旧意图的参数却保留同一个去重标识。这个决定可能是保留预留、部分调整或走另一条业务流程，不一定继续取消。
补偿重试次数、结果查询间隔和接管时限由业务风险、接口限流、去重记录保存期限及值班能力确定。无法在去重记录有效期内确认结果时，应接管核对，不能靠无限重试解决。
从一条能明确取消的写入开始
先选一个允许取消、可查询结果、由明确团队负责的业务动作。写出它的成功凭据和取消前提，再与系统负责人确认条件写入、去重、结果查询、权限以及未知状态的处置能力。接口缺少其中必要能力时，先保持人工处置或缩小自动化范围。
把上面的演练表改成这条动作的实际字段与状态后，再验证无人修改、人工修改、重复投递和响应丢失。跨系统流程还要说明各对象的依赖关系；不能一概按调用顺序倒着撤销。
已有流程可以对照阅读：断点恢复与外部副作用讲任务恢复边界，业务写入幂等讲重复请求，业务数据合同与状态机讲字段和状态权威。发生冲突后，可结合Agent 故障处置组织接管。更多实施顺序见企业 AI / FDE 实施导航。
如果需要梳理跨系统流程，可通过 AI随心创的企业 AI 与 FDE 咨询服务交流。准备一份脱敏的成功与失败样例、实际系统接口能力、允许取消的边界及负责团队，有助于判断哪些步骤适合先做小范围试点。记录和演练样例已完整列在正文中。
常见问题
为什么人工只改备注，也要停止旧补偿？
当接口的强 ETag 或版本覆盖整条记录时，备注修改也会让旧版本失效。客户端应按合同处理冲突。要允许这类情况继续，需要业务服务定义更细的条件，并在写入时原子判断，不能直接忽略版本失败。
补偿请求超时了，能换一个请求标识再发吗？
先按原补偿标识查询。超时不等于未执行。相同意图应沿用稳定标识和参数；如果查不到确定结果，保留 unknown 并接管，不能换标识制造第二次效果。
接口没有 ETag，还能做吗？
可以使用业务服务明确支持的版本号或条件更新机制，关键是条件检查与写入在同一个权威边界内完成。若接口只支持先读再无条件写，且没有其他可验证的并发保护，就不适合自动执行本例的取消。
资料来源与核对说明
文章中的行业定义与技术方法尽量引用官方或标准组织资料；表格、清单和决策框架是基于这些资料形成的编辑性整理，不代表来源机构对本站服务的背书。
- Compensating Transaction patternMicrosoft Learn / Azure Architecture Center
2026-10-22核验公开正文；页面标注最后更新2026-04-20，原始发布日期未标明，不推测。依据：补偿需要考虑并发工作，未必恢复初始状态；补偿可失败，应保存进度并设计幂等动作。本文预留记录、字段、状态和演练由本站设计，不是Azure产品接口或实测结果。
- RFC 9110: HTTP Semantics, 13.1.1 If-MatchRFC Editor / IETF
规范发布于2022年6月，2026-10-22核验13.1.1及13.2.1。If-Match使用强比较，在执行方法前检查；条件不成立时不得执行该方法，通常返回412；规范也允许对已应用的变更返回成功。本文业务取消、权限、幂等与核对字段是教学合同，不由HTTP头自动提供。
带上流程、样例和目标，添加企业微信沟通。先确定项目范围与验收方式，再安排实施。
