问题一：任务够高频吗
低频任务即使做成了也省不下多少工时，却要承担同样的建设与维护成本。先统计任务每月发生次数、占用人力与等待时间，再判断值不值得为它单独建一套系统，为什么先算这一步？因为它常被跳过，却是最省钱的筛选。
问题二：错误代价可承受吗
把可能的错误逐条列出，标注能否撤回、影响范围与多久能被发现。可撤回、影响局部、当天可发现的错误适合先试；不可撤回或直接对外的动作，必须保留人工确认，不能交给模型独立完成，这条边界要在方案里写清。
问题三：接口与数据具备吗
Agent 的能力上限由可用工具决定。要确认目标系统是否有稳定接口、账号能否细分权限、数据能否按任务取出。只能靠人工导出表格的环节，应先做流程改造再谈自动化，否则只是把人工换了个位置，收益有限，边界也没有真正改变。
问题四：有没有验收与接管人
没有业务验收人，项目多半停在演示阶段；没有接管人，系统卡住时无人处理。两个角色都要落到具体岗位与姓名，并写进项目确认单，否则上线后的责任会自然消失，出了问题只能互相推，这属于治理边界问题。
问题五：失败后业务能否继续
试点期间要保留原有流程作为兜底，直到接管率稳定在可接受区间。如何判断耦合过深？看系统一停业务是否立刻中断。若答案是肯定的，应先设计降级路径，再谈上线与扩面，否则试点会变成新的单点故障。
适用与不适用
适合谁
- 正在写立项材料、需要快速判断可行性的负责人
- 有多条候选流程、需要对顺序做取舍的业务部门
- 预算有限、希望先验证再继续投入的企业
不适合谁
- 希望先采购平台、再回头找场景的团队
- 无法提供真实任务样本和测试环境的业务方
典型场景
某集团公司收到三个 Agent 试点申请：合同摘要、发票核对、员工问答。评估小组用五个问题打分，发现合同摘要的错误影响对外且难以撤回，发票核对接口齐全但需财务复核，员工问答频次高、错误可即时纠正，最终选择员工问答先做，其余两个排入下一批。
可执行步骤
- 逐项统计每个候选任务的月发生次数、平均占用工时与平均等待时长
- 把可能出现的错误逐条列出，标注可否撤回、影响范围以及发现时间
- 逐项核对目标系统是否具备稳定接口、可细分的账号权限与测试环境
- 为试点指定业务验收人与接管人，并把两人的岗位与姓名写进项目确认单
- 为试点设计降级方案与人工兜底流程，并安排在上线前完整演练一次
常见坑
- 只估算节省的工时，不计算建设、评测与长期维护的投入，结论通常过于乐观，容易误导决策。
- 把不可撤回的对外动作放进首批试点，一旦出错无法补救，项目与团队都会受到明显挫伤。
- 验收人只挂名不参与，验收会变成技术团队自说自话，业务始终不认账，系统上线即闲置。
- 没有兜底方案，系统一停业务就断，只能紧急回滚，之后团队很长时间不敢再提智能化了。
自检与验收清单
- 五个问题是否都留下了书面答案，并附上判断依据
- 错误清单是否已逐条标注可撤回性与影响范围
- 接口、权限与测试环境是否都已经实际验证过
- 验收人与接管人是否已经到岗并承担相应职责
- 兜底方案是否演练过，演练记录是否完整留档
常见问题
五个问题要全部通过吗？
不必。前三个决定能不能做，后两个决定能不能稳住。若接管人与兜底方案缺失，即使前三个条件很好，也应先补齐这两项再启动，否则项目很难持续，团队也很难向管理层交代。
评分低就一定不做吗？
不一定，可以调整范围再评估。例如把任务缩到只做查询与草稿、把范围限定在一个部门，很多问题会随之变小，结论也可能改变，这比直接放弃或硬着头皮上更划算，也更容易被业务接受。
谁来做这个评估？
由业务负责人牵头，技术、财务与合规各出一人参与，两到三小时可以完成一轮。只由技术团队评估，容易忽略接管成本与业务连续性，结论最终也很难被业务真正接受并签字确认。