我见过的 Agent 项目失败，大多数不是因为技术选错了——是因为走错了步子。场景没验证就大规模推广、技术没跑通就铺开、团队没准备好就上线。每一步都有它该做的事和不该做的事。
这篇文章提供一个五步框架。不是我发明的——是我从自己的项目经验和看到的行业案例里总结出来的。
| 步骤 | 目标 | 时间 | 退出标准 |
|---|---|---|---|
| 第一步：场景识别 | 确认值不值得做 | 1-2 周 | 评分卡总分 < 20 分 → 放弃 |
| 第二步：技术验证 | 确认做不做得到 | 2-4 周 | 关键指标不达标 → 暂停或缩小范围 |
| 第三步：试点运行 | 确认能不能用 | 4-8 周 | 用户留存 < 30% → 回到第二步 |
| 第四步：规模推广 | 确认能不能复制 | 4-8 周 | 新场景 ROI 不达标 → 不推广 |
| 第五步：持续运营 | 确认能不能进化 | 长期 | 效果持续下降 → 重新评估 |
关键原则： 每一步都有明确的门槛和退出标准。不是"走一步算一步"——是"过不了门槛就停"。
目标： 确认这个场景值不值得用 Agent。
做什么：
关键交付物： 一张场景评分表。
| 场景 | 推理需求 | 输入结构 | 频次 | 风险 | 总分 |
|---|---|---|---|---|---|
| 客服工单分类 | 5 | 5 | 5 | 3 | 38 ✅ |
| 报表生成 | 3 | 2 | 2 | 2 | 21 ⚠️ |
| 数据 ETL | 1 | 1 | 5 | 4 | 20 ⚠️ |
退出标准： 所有场景总分 < 20 分 → 这个阶段不适合上 Agent，等条件成熟再评估。
这个阶段的常见错误： 试图用 Agent 解决管理问题。"员工工作效率低"——如果是管理问题（流程乱、职责不清），Agent 解决不了。Agent 解决的是执行问题，不是管理问题。
目标： 确认技术上行不行得通。
做什么：
关键交付物： 评估报告 + 成本估算。
必须用真实生产数据，不能用构造数据。 构造数据的问题我在"Agent 落地的坑"那篇里详细讲过——构造数据在 PoC 阶段看起来完美，一上生产就出问题。
评估指标：
退出标准： 核心指标不达标 → 暂停或缩小范围。不是"继续优化"——如果准确率只有 60%，优化到 85% 可能需要几个月。停下来重新评估场景选择可能更明智。
目标： 确认真实用户能不能接受、愿不愿意用。
做什么：
关键交付物： 试点报告 + 用户反馈分析。
这个阶段最容易犯的错误： 试图证明 Agent 好用。你不需要证明它——你需要发现它哪里不好用。试点的目的是发现问题，不是展示成果。心态不对，试点结论就会偏。
我的亲身经验： 内容流水线的试点阶段，我花了两周才发现最大的问题不是 Agent 写不好——是我自己还没适应"审核者"的角色。如果我不调整心态，Agent 再好也没用。
退出标准：
目标： 确认能不能复制到其他团队或场景。
做什么：
关键交付物： 推广手册 + 培训材料。没有文档不推广。 试点团队的人会流动，没有文档，新来的不知道怎么用。
退出标准： 新场景 ROI 不达标 → 不扩大推广范围。
目标： 确认系统能不能持续产生价值。
做什么：
关键交付物： 月度运营报告。
退出标准： 连续两个月效果持续下降 → 重新评估场景选择。
| 原则 | 说明 |
|---|---|
| 每步有退出标准 | 不是"走一步算一步"——过不了门槛就停 |
| 用数据说话 | 不是"感觉好了"——是指标达标了 |
| 先试点后推广 | 不要跳过试点直接全公司推 |
| 关注人而不是技术 | Agent 落地最大的障碍从来不是技术 |
一句话： Agent 落地的关键不是"怎么做出来"，而是"怎么让团队接受、让 ROI 为正、让系统持续进化"。五步法不能保证你一定成功，但能保证你失败得早一点、成本低一点。
💬 评论