Agent试点验收：七类失败复盘表

读完可拿到七类失败归因表、三张验收清单和放权阈值，按步骤先跑只读试点，再决定哪些自动执行。

作者：进学斋 · 观山书院

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

---

最近不少团队把 AI Agent 放进真实流程：客服工单、运营巡检、数据整理、内部审批。Demo 很顺，一到多人、多系统、长时间运行就出问题。表面看是效果不稳定，真正卡住的是失败信号没有被拆开。

这篇给一套验收方法：七类失败复盘表、三张清单、三天只读试点、分级放权。你可以按步骤先跑只读试点，再决定哪些动作自动执行。

一、先把失败讲清楚：七类信号决定要不要继续

1. 任务理解偏移：它做成了另一个任务

用户要整理客诉并生成回复草稿，Agent 只做了分类。用户要补全字段，Agent 改写了整段文案。偏移的根源常在目标拆解，不在模型本身。

你可以看一次通过率、人工介入率和低质量输出占比。若同一个意图经常走偏，先改任务模板和验收字段，再考虑提示词。

2. 上下文丢失：关键依据没跟到下一步

多轮任务里，前面的约束、客户等级、预算口径、历史处理结论，到工具调用阶段被丢掉。结果看着合理，经不起复核。

观察上下文引用次数、关键字段正确率、任务耗时。如果重复查询和重复确认变多，说明链路没有把依据传下去。

3. 工具越权：不该做的动作被做了

读接口变写接口，草稿变发送，查询变删除。这类问题比回答错误更危险，因为它直接改变外部状态。

记录敏感动作命中数、工具调用入参、调用者身份、目标系统。发现越权先收窄工具白名单，而不是补一句不要删除。

4. 结果不可验：输出漂亮，但无法追溯

Agent 给出结论，却没有留下依据来源、计算口径、工具返回值、置信提示。业务同学不敢签，工程同学难复现。

验收要看关键字段正确率、依据链路完整率、用户是否接受结果。没有可验字段，就不能把动作交给自动流程。

5. 成本失控：一个任务跑成了循环

重复检索、反复总结、模型多次调用、工具多次请求，单任务成本持续上涨。团队只盯 token，容易漏掉耗时、重试、人工复核。

跟踪重复调用次数、任务耗时、错误恢复时间、单位任务成本趋势。成本异常往往是流程有环，先断环再扩容。

6. 审批缺失：自动动作绕过人

高风险动作没有审批位，或者审批只是走形式。真正出问题时，责任链断裂，复盘也找不回当时为什么放行。

检查审批缺失率、外部写入动作命中数、审批记录保留期限。审批不是加一个按钮，而是给每个高风险动作绑定人和理由。

7. 回滚缺位：改出去收不回来

改文档、发消息、更新工单、调整配置，失败后没有回滚 ID、没有补偿动作、没有兜底模板。一次成功，可能掩盖下一次事故。

记录回滚责任人、错误恢复时间、幂等性、审计 ID。写操作若不能回滚，只允许在低影响范围试点。

—— 先采集运行日志，再判断问题在模型、提示词、工具还是流程。

不要一上来就换框架、扩权限或加提示词。先让失败可观测，团队才有讨论基础。

配图·湖光暮色

二、定义验收口径：用三张清单替代看起来可用

1. 业务验收清单

业务侧只问结果能不能用。你可以固定五项：任务目标完成率、关键字段正确率、用户是否接受结果、低质量输出占比、人工复核比例。每项都要说明口径。

比如关键客诉字段包含客户身份、诉求类型、责任团队、处理时限。缺一项，就不算完成。

2. 工程验收清单

工程侧要能复现、能追踪、能止损。你可以固定：超时率、重试次数、幂等性、日志字段完整性、依赖服务错误码、调用链路耗时分布。

日志至少包含 task_id、run_id、agent_version、tool_name、input_hash、output_hash、duration、error_code。

event: agent.plan
task_id: T-1024
run_id: R-77
user_intent: 整理客户投诉并生成回复草稿
planned_steps: retrieve, summarize, draft
tool_call: search_tickets status=open
risk_level: read_only
approval_required: false
idempotency_key: T-1024-R-77-search-001

这段日志不是为了好看，是为了三天试点后能归因。若只有结果没有过程，复盘会变成猜。

3. 安全合规清单

安全侧重点不是模型能力，而是动作边界。你需要检查：敏感数据暴露、外部写入动作、删除/支付/发布类操作审批、审计记录保留期限、回滚责任人。

对客外发、资金变更、生产配置修改、删除记录，默认不进自动执行。即使业务催得紧，也只先在沙箱或影子系统跑。

可执行检查清单

☐ 建立 task_id、run_id、agent_version 三键日志，确保每次执行可追踪。

☐ 为每个工具调用记录输入摘要、输出摘要、耗时、错误码和幂等键。

☐ 把外部写入、删除、支付、发布、对客外发动作放入默认拦截名单。

☐ 给业务验收字段写明定义、口径、复核人，不接受模糊评价。

☐ 为失败样本设置每日复盘池，问题未关闭前不扩大调用范围。

☐ 每个高风险动作绑定审批人、理由字段、回滚责任人和审计 ID。

配图·晨雾山色

三、跑只读试点：三天量出能力边界

第一天：只记录，不执行

第一天让 Agent 只做影子运行。它接收输入，生成计划，记录工具调用意图、输出草案和失败提示。实际系统不被修改。

你要确认三件事：它是否理解目标，是否知道边界，是否能把计划说得清楚。若计划里出现删除、外发、支付，直接打回。

第二天：只放低危动作

第二天允许查询、摘要、草稿生成、格式转换。禁止跨系统写入、外发、删除、资金类操作。

重点看动作是否可重复、是否可撤销、是否产生真实状态变化。只要会影响别人，就退回人工确认。

第三天：失败归因与三档分类

第三天把任务按七类信号打标签。每个动作分成三档：自动执行、人工审批、必须禁用。

自动执行适合低危、可重复、只读、影响小的动作。人工审批适合中高风险写入和边界模糊动作。必须禁用适合不可验、不可回滚、越权倾向明显的动作。

据公开资料/行业观察，团队常见问题是把 Agent 一次性接到完整业务流程。更稳的做法是先跑影子日志，再逐步开放低危动作。

—— 试点不是证明它聪明，而是找出它什么时候不该被信任。

四、按风险放权：用分级执行把兜底写进流程

1. 动作风险乘以影响范围

不要按任务名称放权，要按动作风险。低风险只读可自动，中风险写入需确认，高风险外发或变更需人工审批。

表格可以放在验收会议首页。讨论时别问效果怎么样，先问命中了哪类失败。

2. 写操作三件套

所有写操作必须具备幂等、可回滚和审计 ID。同一用户同一任务重复失败时，优先熔断，而不是继续重试。

幂等键可以设计成 user_id + task_id + action_id。回滚字段可以记录 previous_state、restore_point、owner。审计 ID 让人工干预可追溯。

3. 兜底通道要提前准备

给 Agent 准备四条路：超时回退模板，失败转人工，敏感动作拦截，异常样本进入每日复盘池。

兜底不是失败后的补丁，而是流程的一部分。没有兜底的自动化，本质是把风险交给运气。

五、上线后迭代：用复盘表持续收紧边界

1. 每周汇总失败样本

每周把七类失败样本归并一次。更新提示词、工具描述、路由规则和验收阈值。问题不能靠临时补提示词掩盖。

如果同一任务反复命中工具越权，改工具权限。如果结果不可验，补字段。如果成本失控，设调用上限和熔断。

2. 灰度对比四组指标

小范围灰度批次时，你可以对比四组指标：一次通过率、人工介入率、单位任务成本、错误恢复时间。

指标变稳再扩大调用范围。指标波动时，先缩权限。放权顺序应是：只读查询、草稿生成、低危写入、外部写入、高风险审批动作。

3. 形成版本化验收记录

每次上线都要留下记录：本次改了什么，为什么改，哪些动作从审批降为自动，哪些仍保持人工兜底。

版本化记录能避免两个团队重复踩坑。也让 Agent 试点从口头可用变成可交接的工程资产。

三句话讲透

先记录再放权。没有日志和归因，所有乐观都容易变成事故。

先验收再上线。没有三张清单，Agent 的聪明只是局部表演。

先兜底再自动化。没有熔断、回滚和审批，团队不敢把真实流程交给它。

你可以今晚就做三件事：给当前试点补 task_id 日志；把删除、外发、支付动作放进默认拦截；用三天试点把动作分成自动、审批、禁用三档。

这篇适合转发给负责 Agent 试点的工程、产品和安全同学。建议收藏，下次验收直接对着清单过。