坑一与二：场景错、演示当可行
选一个演示效果最好但无人使用的场景，或用干净样例跑通就判定可行。真实数据的格式混乱、权限缺失与例外分支才是成本所在。如何验证可行性？用历史工单与真实附件做回放，比看现场演示可靠得多。
坑三：权限一次放开
为省事把 Agent 的账号按管理员配置，写操作也不加确认。为什么危险？一次误判就可能改动主数据或批量发出错误通知，恢复成本远高于省下的人力。应按任务给最小权限，写操作走二次确认，并把权限清单纳入变更评审。
坑四：没有评测集
没有固定的样本集与成功标准，团队只能凭感觉说效果不错，出错时也无法判断是提示词、工具还是数据的问题。上线前应固化一批历史任务，明确任务成功率与人工接管率怎么算，并保留失败样本。
坑五：没有接管机制
设计时假设 Agent 永远不会失败，没有转人工的入口与责任人。一旦卡住，业务只能绕过系统回到人工，系统随即被弃用。接管条件、响应时限与兜底流程必须在前置评审中定好，而不是上线后再补，这条边界要提前划清。
坑六：责任与运维缺位
合同只写功能与交付时间，没写数据使用范围、日志归属与故障响应。上线后也没有人为提示词与知识更新负责，三个月后准确率自然下滑。运营责任人与更新节奏要落到具体的人，并纳入季度检查，否则责任会悬空，这也是最容易被忽略的治理边界。
适用与不适用
适合谁
- 有明确业务问题、愿意先做单场景试点的团队
- 已经具备可调用接口与账号体系的企业
- 愿意指定业务验收人与接管责任人的组织
不适合谁
- 只想采购工具、不设验收与接管环节的团队
- 期望完全无人值守、后果不可逆的业务流程
典型场景
某零售企业的运营团队想用 Agent 处理退换货审核。试点前他们翻出三个月的真实工单，发现近四成涉及缺件与拆单，于是把范围收窄到标准件退货，只授予查询与草稿权限，审核结果由客服组长确认后发送，并记录每单的接管原因用于每周复盘。
可执行步骤
- 从历史工单中挑出真实、可验证的任务样本集，不要只依赖演示数据
- 为每类任务列清所需工具与最小权限，所有写操作一律加人工确认环节
- 用固定样本集定义任务成功率与接管率的口径，把算法写进验收文档
- 为每个环节指定接管人、兜底流程与响应时限，并在上线前演练一次
- 把数据使用范围、日志归属与运维责任逐条写进项目确认单，并完成签字
常见坑
- 把演示样本当作可行性依据，上线后才发现真实附件无法解析，返工与解释成本都要翻倍。
- 权限按管理员配置、写操作不做确认，一次误判就可能改动主数据，恢复与追责都很困难。
- 没有固定评测集，效果好坏只能凭感觉，出了问题也说不清是提示词、工具还是数据的原因。
- 上线后没有人为提示词与知识更新负责，准确率逐步下滑，业务绕回人工，系统事实上停用。
自检与验收清单
- 场景是否已有真实样本，是否已经明确使用人
- 权限是否按任务最小化，写操作是否都有确认
- 是否定义了成功率与接管率的口径，并写入文档
- 接管人与兜底流程是否已经落到具体岗位与姓名
- 数据使用范围与运维责任是否已书面化并签字
常见问题
试点应该选多大的场景？
一个岗位、一类单据、一个系统接口即可，通常能在四到六周内跑完一轮评测。范围越大变量越多，越难判断问题出在模型、数据还是流程上，也越容易在试点中期就失去焦点。
演示效果不错，为什么上线后落差大？
演示样本通常干净、边界单一，真实数据则有格式混乱、缺字段与例外分支。应把真实历史任务做回放测试，按失败类型分类统计，再决定是否扩大范围，否则落差会在上线后集中爆发。
供应商说能全自动，怎么判断？
要求对方给出接管机制与失败处理方案，并在合同里约定异常场景的责任划分。任何声称完全无需人工的承诺，都应要求用样本回放验证一次，而不是只看演示现场的效果。