先给结论：Agent 写入业务系统后，只有完成独立回读并与预期结果一致，才能显示“完成”。 接口返回 200、页面提示“已提交”、流程显示“已受理”，都只是中间状态。
这套方法适合 CRM 字段更新、ERP 单据创建、项目状态流转、库存预留、外部门户提交等会改变业务对象的动作；不适合纯查询、草稿生成等没有写入的任务。若目标系统既没有可读接口，也没有可核对的业务唯一键，就不应开放无人值守写入。
写后回读 6 步
| 步骤 | 必须留下的事实 | 失败时怎么处理 |
|---|---|---|
| 1. 固定写入意图 | 目标系统、对象 ID、允许修改的字段、期望值 | 对象不唯一或字段超白名单，停止 |
| 2. 读取写前基线 | 修改前字段值、版本号、读取时刻 | 基线读不到，不执行写入 |
| 3. 校验授权与幂等 | 请求人、批准记录、幂等键或业务唯一键 | 授权过期或无法防重，转人工 |
| 4. 提交并记录回执 | 请求摘要、响应码、外部回执、提交时刻 | 超时进入“结果未知”，不直接重试 |
| 5. 从权威路径回读 | 实际字段、对象状态、读取时刻 | 按一致性窗口重读；仍失败则标“无法核验” |
| 6. 比对并关闭 | 期望值、基线值、实际值、白名单外差异 | 部分成功、值不符或超范围变化进入异常队列 |
第一步的关键是把“更新一下客户”改写成可验证动作，例如“只修改这位客户的下一次跟进日期和负责人备注，其他字段不变”。写入范围越模糊，回读越无法判断是否误伤。
第二步不能省。假设销售要求 Agent 更新 CRM 跟进结果，同时另一位同事改了客户负责人。没有写前基线，回读只能看到“现在是什么”，无法区分哪项变化来自本次动作。基线、期望和实际三组值并列，才能暴露并发冲突。
超时后先查，再决定是否重试
写接口超时最危险，因为结果可能已经落库。处置按目标系统的防重能力分三档：
- 原生支持幂等键：使用同一幂等键重试，不能每次生成新键。
- 没有幂等键，但有订单号、外部单号等业务唯一键：先按唯一键回查，查到后直接进入结果比对。
- 追加备注、追加日志等既无幂等键又无唯一键的动作：禁止自动重试，由人确认到底写了几次。
业务校验失败、权限不足、对象状态不允许等确定性错误，不应反复重试。重试适用于可安全重放的临时故障，而且必须有次数上限。更完整的异常分流可继续看Agent 异常队列怎么设计。
回读必须独立于写入回执
把写接口返回体当作回读结果，等于没有回读。更可靠的做法是从业务人员平时查看结果的权威路径重新读取：CRM 写入后查客户详情，ERP 建单后按单号查正式单据，外部门户提交后查受理状态。
还要为缓存、异步落库和跨系统同步留出可读一致性窗口。首次回读不一致时，可以按目标对象配置短暂等待和有限重读；超过窗口仍不一致，就生成结构化差异：NOT_APPLIED、PARTIAL、VALUE_MISMATCH、OUT_OF_SCOPE_DIFF 或 UNVERIFIABLE。其中“无法核验”绝不能归入成功。
例如项目经理批准 Agent 把交付里程碑改为“待客户验收”。提交成功后，Agent 应重新读取项目状态、对应验收单和更新时间。只有三者符合规则才能关闭任务；若项目状态变了但验收单不存在，正确结论是“部分成功，待处理”，不是“已完成”。
审计记录至少回答 3 个问题
每次写入都应能回答：谁批准的、改了什么、改完核过没有。审计记录至少包含写入意图、请求人、批准引用、基线快照、提交回执、回读快照、差异、重试次数和最终状态。验收时可配合AI Agent 项目验收的 7 个检查点逐项复跑正常、超时、重复提交和无权访问用例。
写后回读不是增加一条日志，而是重新定义“完成”：已生成不是完成，已提交不是完成，权威系统中的目标状态经过独立回读才是完成。 如果你准备把 Agent 接进 CRM、ERP 或项目系统，可从AI Agent 落地服务先梳理对象、授权、回读路径和异常责任人。
