上传文件就能总结，输入客户问题就能写回复，演示看上去很顺利。到了日常工作，员工却还要导数据、复制结果、补异常，最后又回到表格和聊天群。这说明试点还没有解决完整的使用问题。
Unclear Goals
买了工具，却没定清要改善什么
如果先买平台再找用途，很容易试了很多功能，却没有人持续使用。启动前应写清：减少哪一处等待、避免哪类遗漏、缩短哪一步处理时间，以及由谁检查结果。
Unrealistic Test Data
测试只用了整齐的样例
地址少了一行、客户临时改规格、同一物料有两个名称、审批人出差、系统连接中断，这些都应进入测试。只用整理好的资料，很难发现系统遇到异常时会不会继续做错。
测试材料应该包含常见任务、边界情况和明确不能自动处理的情况。后者尤其重要，因为可靠系统必须会把问题交还给人。
Disconnected Systems
没有接进现有系统
如果员工仍要导出 ERP 数据、复制到聊天窗口，再把结果填回系统，就应算一算总工作量是否减少。要把 Agent 接进日常流程，还需处理账号权限、系统接口、操作记录和失败后的重试。
Missing Human Review
上线前没有安排好审核
上线前就应约定：哪些操作可以自动完成，哪些金额、客户、平台或异常必须先确认；谁有审批权，长时间无人处理时转交给谁。临时补审核容易遗漏，也可能把任务全部堆给一个人。
Unchecked Results
结果没人检查，问题没人跟进
按任务设定检查项：字段是否齐全、异常是否找出、建议是否被采用、错误是否在发布前拦住，以及准备和审核一共花了多久。这样才能判断改进了什么。
验收之后，还要继续记录问题。让使用者记录错误、修改理由和新出现的例外，再安排人员核查并更新规则。系统要适合这家公司的做法，需要这一步持续跟进。
Ongoing Support
项目交付后没有人继续负责
企业流程会变，人员会换，模型和平台也会更新。只交付一个“能运行的版本”，没有监控、反馈入口和维护责任，几个月后很容易失效。生产 Agent 需要明确的运行负责人：谁看日志、谁处理失败、谁批准规则变化、谁决定扩大范围。
A Complete Workflow
用一项完整任务重新安排试点
- 选择一个高频且风险可控的问题。
- 记录当前流程与基线，不省略例外。
- 先定义 Agent 的权限和人工确认点。
- 接入真实数据与真实工具，但限制范围。
- 用真实任务试运行，记录每次错误与人工修改。
- 达到约定的日常使用标准后，再扩大处理范围。