角色一：业务负责人
负责定义任务边界、可接受的错误类型与接管条件，并对验收结论签字。这个角色不宜由技术团队兼任，否则范围容易随技术兴趣漂移，最终做出来的功能没人使用，验收也无法真正生效，遇到争议时更没有依据。
角色二：接口与权限工程
负责把目标系统整理成可调用的工具清单，配置最小权限账号、限流与审计日志。工具接口的稳定性直接决定 Agent 的可靠性，这项投入比反复修改提示词更值得，为什么优先做这项投入？因为它比后期补便宜得多。
角色三：评测与运营
负责维护样本集、统计成功率与接管率、按失败类型推动修复。这个角色需要既懂业务又看得懂日志，通常由业务骨干转岗培养。为什么不能临时抽调？因为口径一变，历史结果就无法比较，评测也就失去连续性。
数据条件：四类底稿
如何盘点这四类底稿？接口清单、规则与话术文档、带结论的历史任务、可回溯的操作日志，一样都不能少。缺日志无法复盘，缺历史结论无法评测，这两项最常被忽略，也最难在事后补齐，是试点前必须盘点的底稿。
适用与不适用
适合谁
- 有明确业务 owner 与接口团队的企业
- 愿意投入知识整理与样本标注的组织
- 计划把单点试点转为长期运营的团队
不适合谁
- 希望把项目整体外包、之后完全不管的业务方
- 接口封闭、无法提供测试环境的系统
典型场景
某保险公司的理赔资料初审试点中，业务负责人划定只处理意外险小额案件，接口团队开放影像查询与保单查询两个只读接口，评测运营从历史案件里抽出三百条样本并标注结论。三方每周碰一次，按失败类型分配修复任务，两个月后接管率趋于稳定。
可执行步骤
- 为试点指定一名业务负责人，同时给出书面授权与清晰的任务边界并归档
- 整理可调用的接口清单，画出账号权限矩阵，并标注限流与审计要求
- 从历史系统里收集带结论的任务，整理成可复用、可比较的评测样本
- 把规则、话术与例外情况整理成结构清晰、能被快速检索到的知识文档
- 确定评测运营的固定人选，并把周度复盘的节奏与判定口径固定下来
常见坑
- 让技术团队兼任业务负责人，范围会随技术兴趣不断漂移，做完才发现业务其实并不需要它。
- 接口文档早已过期却无人维护，联调反复失败，进度被拖慢，团队很容易转而怀疑方案本身。
- 历史任务没有结论标注，评测只能临时人工判断，结论既无法复用，也难在不同轮次间比较。
- 把评测工作交给临时人员，指标口径每周都在变，前后结果无法比较，改进也就无从谈起。
自检与验收清单
- 业务负责人是否获得书面授权、明确了任务范围
- 工具清单与账号权限矩阵是否都已经整理成文
- 历史样本是否都有结论标注，能否直接被复用
- 规则、话术与例外情况是否都整理到可检索的位置
- 评测运营是否固定到人，指标口径是否长期稳定
常见问题
小团队没有专职评测怎么办？
可由业务骨干兼任，但要把口径固定下来：同一批样本、同一套判定标准、每周同一时间复盘。人手少时宁可缩小范围，也不要降低评测的稳定性，否则前面几周的工作会白做。
接口暂时打不通怎么办？
先用人工导出加半自动方式跑通流程与评测，验证价值后再推动接口改造。但要清楚这只是过渡手段，长期靠人工搬运会抵消大部分预期收益，也会让评测样本逐渐失真。
数据不能出内网怎么办？
可选择私有化部署或内网推理方案，先完成部署与安全评估。若模型只能通过公有云调用，应把敏感字段脱敏后再送出，并在方案里写明数据流向、留存方式与到期删除机制。