选一个真实团队和一到两个高频任务。开始前记录现有耗时、返工、成本和通过标准，运行四到六周。结束后用相同口径核对，得出停止、调整或扩大的结论。
第一个试点任务要能重复、能核对
代码缺陷初步分析、项目资料整理、工单分类和固定格式报告都比一次性战略分析更容易建立基线。
适合试点的任务具有这些特征：
- 团队每周都会发生；
- 输入来源和完成标准大致稳定；
- 当前存在等待、重复操作或交接成本；
- 业务负责人能判断结果是否合格；
- 试点失败不会直接造成不可逆的生产影响。
范围扩到全公司或一次接入过多系统，会让团队难以判断结果来自产品、流程还是组织变化。
开始前记下现有做法
没有基线，试点结束后只能凭印象判断。连续观察几次现有流程，记录：
- 从接到任务到完成的总时间；
- 人工处理时间和等待时间；
- 返工次数与常见错误；
- 当前工具、模型和执行资源的成本；
- 结果由谁验收，什么条件算通过。
质量如果难以用一个分数表示，可以使用清单，例如“字段完整、来源可核对、格式符合要求、关键结论经负责人确认”。
四到六周能看到什么
一次演示很容易挑选理想输入。连续运行会遇到人员变化、输入异常、模型波动、权限申请和任务失败，也能看出员工是否愿意持续使用。
每次运行需要绑定任务、发起人、项目、模型、权限、用量和结果。失败原因会帮助团队决定修改流程、调整权限或停止这个场景。
每周复盘
- 本周哪些结果被接受，哪些需要返工？
- 失败来自输入、模型、工具、权限还是流程？
- 是否出现超出原定数据或动作边界的需求？
验收要同时核对效率和管理结果
结束时按试点前的同一口径比较耗时、返工、成本和通过情况，同时核对治理结果：
- 人员和 Agent 的身份是否明确；
- 权限是否可以按项目授予和回收；
- 用量是否能归到具体团队与任务；
- 过程和结果是否支持交接与复盘；
- 出现异常时是否有暂停、审批或人工接管方式。
最终决策可以是扩大、调整后再试或停止。有依据地停止一个不合适的场景，也是试点的有效产出。
试点需要留下的记录
- 确定一个团队和业务负责人；
- 选择一到两个高频可验收任务；
- 记录试点前基线与风险边界；
- 配置项目、人员、模型、工具和权限；
- 连续运行并每周复盘；
- 用相同口径验收；
- 形成停止、调整或扩大的书面结论。