Agent 落地实战：把失败写成可恢复状态

读完可拿到业务事件分片表、失败恢复清单和上线前验证步骤，两天内完成一次可控 Agent 试点。

作者：进学斋 · 观山书院

全文约3789字 · 阅读约需13分钟

---

这篇直接给你一张事件分片表、失败恢复清单和上线前检查步骤。你可以用它跑一次低风险 Agent 试点：能查资料、能生成草稿、能记录状态，失败时知道谁接手、怎么恢复、靠什么证据复盘。

最近不少团队把 Agent 跑成了“会议室明星”：它能读工单、查知识库、写草稿，演示里一句话就能把资料聚起来。一旦接进真实业务，问题就露出来：连续调用要确认状态，失败要重试，写操作要留痕，审计要能追。

一、背景：Demo 为什么会停在会议室

问答、检索、草稿，这些任务短、失败轻，适合演示。业务要的是连续执行：先查工单，再读知识库，再生成回复草稿，再把结果写进系统。

链路一长，失败就不再是“结果不准”，而是“有没有做过”“是否重复做”“能不能撤销”。据公开资料和行业观察，很多试点在模型选型上很快定下来，却在事件分片、状态记录、回滚动作上迟迟补不齐。

你可以先选一个低风险闭环：内部工单摘要、日志归类、客服知识检索。关键不是任务简单，而是失败后不会污染生产数据。

—— 能跑起来只是起点，可恢复才是上线资格。

配图·春野柔光

二、机制：状态分片与运行证据

1. 把长流程切到可停可审

一个可运行的 Agent，不应被当成一次性黑盒。更稳的做法是把流程切成事件、判断、调用、校验、交付等短节点。每个节点都要有输入、输出、超时、重试、人工接管点。

比如“客服工单摘要”可拆成：读取工单、检索知识库、生成草稿、检查敏感字段、保存草稿、通知人工。每一步单独有状态，失败时才知道卡在哪里。

2. 每个节点留下最小证据包

证据包不是聊天记录，也不是自由文本。它要能回答：谁、在哪一步、用了什么工具、做了什么动作、有没有继续自动跑。

最小字段可以很少：task_id、event_id、step_id、input_digest、tool_name、params_masked、result_status、duration_ms、next_action、retryable、human_required、rollback_basis。

{
  "task_id": "ticket-042",
  "event_id": "cust-export-timeout",
  "step_id": "summarize-draft",
  "input_digest": "客户报障：导出报表超时",
  "tool_name": "kb.search",
  "params_masked": "tenant=t-a1b2|query=export",
  "result_status": "success",
  "duration_ms": 1800,
  "next_action": "save_draft",
  "retryable": false,
  "human_required": false,
  "rollback_basis": "no_write"
}

这段记录不追求漂亮，它追求可追问。审计人员看到状态是 success，还要看到下一步是不是 save_draft；看到超时是 timeout，也要知道它有没有进入人工确认。

3. 状态别靠自由文本

“已生成草稿”这种描述很自然，但审计时容易失效。更可靠的状态字段是：是否已执行、是否可重试、是否需要人工确认、是否有回滚依据。

如果写操作已发出但外部系统超时，不能简单标成失败，也不能自动重发。它至少要有“可能已发生”“需要人工确认”“可补偿动作”三个标记。

—— 工程不是让机器更会说话，而是让每一步都能被追问。

配图·庭园小径

三、步骤：两天跑通小闭环

如果排期紧，可以把第三天的检查并入第二天尾段。核心是先让证据完整，再让流程跑顺。

Day1：建立准入和权限

选一个低风险事件，例如内部工单摘要。先写任务准入表：什么事件能进、什么字段必须脱敏、什么结果不能自动发送。

再写工具权限表：只开放只读查询、摘要生成、草稿保存。生产数据库写入、消息发送、退款补偿这类动作，先不要给 Agent。

事件分片表

这张表不需要复杂，但它把“能做什么”和“不能自动做什么”写清楚。尤其失败动作列，最好直接写动作，不写形容词。

Day2：接入状态记录与失败恢复

把状态记录接到日志或任务系统里。跑三类用例：正常路径、工具超时、外部数据缺失。每个用例都生成一条可复盘证据。

失败恢复动作要按类型区分：

• 只读失败：可重试，也可降级为人工检索。
• 写操作失败：停止自动重试，查确认号和幂等键。
• 外部依赖超时：先进入“可能已发生”，再触发人工确认或补偿任务。

失败恢复清单可以这样列：

☐ 是否存在未完成的写操作？

☐ 是否已保存确认号或幂等键？

☐ 是否能把状态改回可恢复分支？

☐ 是否能通知人工而不污染业务数据？

☐ 是否能导出一张最小证据包？

如果这五项都答不出，不建议进入灰度写入。Agent 不是不能失败，而是失败后不能变成一团黑雾。

Day3：上线前检查

这一步也可压缩到 Day2 尾段。验收只看四件事：无证据不交付、未确认不写库、未回滚不自动重试、未审计不开放新权限。

交付物不是 PPT，而是三件：一张事件分片表、一份失败恢复清单、一组只读试点日志摘要或截图。它们证明过程可追，结果可停。

四、坑与选型：先稳定，再聪明

常见坑

一次给 Agent 太多工具，链路会看似聪明，实则不可控。模型如果靠猜业务规则，错误就会进入执行层。

失败后无限重试，是另一个高风险动作。尤其是写接口没有幂等键时，重试可能造成重复通知、重复扣减、重复工单。

用自由文本当状态，会让审计失去抓手。复盘时只看到一段说明，却看不到“是否已执行、是否需人工、是否可回滚”。

选型时先看运行证据

框架、平台、协议都可以换，但运行证据不能缺。选型至少看四项：是否有可恢复状态、是否有权限边界、是否有审计记录、是否能人工接管。

写操作要上三件套：预写清单、确认号、可补偿动作。预写清单让 Agent 先列出将要执行的变更；确认号用于追踪这次变更；补偿动作让失败后能恢复到可处理状态。

预写清单可以很短：

目标：更新工单状态
动作：调用 ticket.update
参数：状态=待人工确认，租户脱敏，草稿链接保留
影响：仅内部系统
回滚：可恢复为待确认前状态
确认号：pending-042-a1b2
补偿：发送人工复核提醒，不重复写库

这份清单的作用，是阻止模型用“我觉得可以”代替系统判断。

三档落地对比表

这张表比能力介绍更有用。它能帮团队把讨论从“模型行不行”拉到“权限、证据、回滚、接管是否齐了”。

五、延伸：从只读试点到灰度运行

分档开放，不一次性松手

只读试点成功后，再按风险等级打开草稿保存、低影响写入、生产写入。每一档都要重新验收，不因上一档通过就直接升级。

草稿保存可以先限定内部系统；低影响写入可限定小范围租户或测试数据；生产写入必须有双重确认。

升级前问三个问题：失败后能不能停、写出去能不能收、审计时能不能看懂。三个都答不上，先别扩范围。

月度复盘：别只看成功率

观察失败恢复类型、人工接管率、重复调用原因，比单纯看模型打分更有用。据行业实践，很多优化方向并不来自换模型，而来自补齐工具契约和状态字段。

如果重复调用多，先看任务拆分；如果人工接管多，先看权限和确认流程；如果失败恢复乱，先看工具契约和状态字段。

三句话讲透

任务要能停，动作要能审，失败要能恢复。

这三句话不是原则，而是验收口径。停，看是否有中断点和人工接管；审，看是否留下事件、工具、参数、状态；恢复，看是否有只读、写入、超时三类动作边界。

下一步不是盲目扩大自动执行范围，而是把证据、回滚、权限和审计做成可复制的工程模板。

—— 把失败写进状态表，Agent 才从演示走向工程。

收藏或转发给下一次 Agent 评审：先贴事件分片表、失败恢复清单和上线前检查项。让下一次试点讨论不再停在“能不能跑”，而是从“失败时谁接手、怎么回滚、靠什么证据判断”开始。