过去三年我一直在观察 AI agent 实验悄悄翻车。最不体面的一个案例，是某产品总监把几句 ChatGPT prompt 直接扔给团队当 AI assistant 使用，六周之后这位 assistant 读到了一份用户不该看的内部文档，安全团队不得不紧急介入。根因不是模型质量，而是从头到尾没有部署路径。
另一个案例我坐在对面听。某技术 VP 跟我说 Q4 之前要把 AI agents 铺到全组织，但他叫不出任何一个能覆盖 seat 成本的用例。两年之后那个团队还在原地。
几乎所有远程团队都有同一个模式：要么把 AI agents 当万能药，要么把它当噱头，都会跳过让 agent 从实验品变成受治理系统的 90 天部署窗口。这篇就是一个可以本季度就跑起来的三阶段 playbook。
三个可以先启动的高杠杆用例
不是所有 AI agent 用例都值得做。Gartner 预测到 2028 年，33% 的企业软件会内置 agentic AI 能力；到 2026 年，75% 的组织将采用混合办公。当所有人都有同样的能力时，差异不在模型，而在用例。
在我服务过的团队中反复验证过 20-40% 生产力提升的三个用例：
1. 会议纪要 agent
会议纪要 agent 加入固定会议、产出异步摘要、抽取 action item，并在 5 分钟内推到团队频道。跨三个时区的团队，光同步会议就损失 30% 的信息，因为一半人根本不在场。异步摘要把这份损失变成有迹可循的文档。
具体收益：我辅导的一家金融科技团队，60 天内把每周同步站会从 15 场砍到 8 场。他们的 agent 产出摘要、列出负责人，并把未解决的阻塞点每天做一次 recap 推送。
2. 任务 dispatcher
这类 agent 读取团队频道里的状态更新，识别需要人工介入的工作，根据路由表分派给对应负责人。它不做决策，只做分诊。省下的不是会议本身的时间，而是经理每天早上花在找答案上的 3-5 分钟。
3. 知识检索 agent
跨时区团队每天要问五个人一个问题，才能确定文档里有没有写。检索 agent 覆盖团队 wiki、决策日志和历史项目，一次查询就能带出处返回答案。这是分布式团队里杠杆最高的一个用例。
三个用例的共同点是可量化收益与低爆炸半径。每个都有清晰的时间节省、清晰的产出、清晰的回滚路径。可以先做一个，再扩展。
90 天甘特：识别、试点、扩展
我把部署窗口切成三个 30 天阶段。跳过任何一个阶段，是绝大多数试点默默死掉的原因。
阶段 1（第 1-30 天）：识别与准备
不要从工具开始。从访谈开始。
第 1 周 相关方访谈。 召集工程、产品、运营各 10 人访谈，聊会议、任务路由、文档迷失三个维度。目标是暴露痛点，不是演示产品。
第 2 周 挑选 1-2 个高杠杆用例。 用第 4 节的用例矩阵挑选，写下要跟踪的 KPI。每周节省时间、减少会议、每次查询命中的文档数。如果量化不了，后面就不好 defend pilot。
第 3 周 沙箱搭建 agent。 这是最容易冲动的一周。先在沙箱里做一版，不接生产数据，prompt 迭代到输出可信为止。
第 4 周 撰写治理文档。 定义数据访问边界、使用政策、评审节奏。这一周不能省。我观察到的翻车 90% 都发生在这周团队决定跳过治理直接上线的时候。
阶段 1 里程碑：一个可运行的 agent（沙箱）+ 一份治理文档 + 一个可量化 KPI。
阶段 2（第 31-60 天）：小范围试点
第 5-6 周 10 人 2 周试点。 挑一个高杠杆用例，只给 10 人用两周。这是试点，不是推广。
第 7-8 周 迭代。 不要急着扩。根据试点数据调 prompt，信号正向再扩到第二个团队。同时移除未使用的数据访问、加审计日志加固边界。
阶段 2 最常见的错误是把试点当推广。如果一个 agent 在 10 人小试里没用，它不会因为在 100 人里就变好用了。
阶段 3（第 61-90 天）：扩展与迭代
第 9 周 全员推广。 面向全员上线，附一页使用政策，办一场 office hour。同时准备 CFO 友好的价值报告：每周节省时间、减少会议、每日命中知识数。
第 10 周 复盘与再规划。 砍掉未达 KPI 的 agent，扩展跑通了的用例，把下一个用例放进管道，进入下一个 90 天。
90 天是一个完整循环，不是整个旅程。试点在跑、复盘在排期，就说明方向是对的。
用例选择矩阵
不是每个工作都值得套一个 agent。用这张 2x2 矩阵来判断：
| 标准 | 高价值 / 低风险 | 高价值 / 高风险 | 低价值 / 低风险 | 低价值 / 高风险 |
|---|---|---|---|---|
| 示例 | 会议纪要 | 薪资决策草稿 | 打招呼聊天机器人 | HR 绩效评估 |
| 建议 | 立即部署 | 加人工复核闸口 | 作为 MVP 部署 | 不要部署 |
价值按每周节省时间、KPI 影响来衡量，风险按爆炸半径和可回滚性来衡量。像写薪资草稿这种用例价值高但风险也高，必须加强制人工复核闸口才能用。
每次给管道里加新用例，都要过一遍这张矩阵。跳过矩阵，你要么部署了一个没人用的 agent，要么部署了一个引起合规事故的 agent。
影子 AI 治理边界
影子 AI 是员工自己搭 agent 时的产物，也是我见过的所有安全事件中最常见的原因。Gartner 和 Forrester 都报告，未治理的 AI 使用已经成为远程组织的头号内部安全风险，但答案不是封锁所有 AI 访问，那样只会把行为推得更深。
要正规化。
治理规则 1. 任何接触生产数据的 agent 必须在内部 registry 注册。未注册的 agent 技术上可行，但组织上不可接受。团队知道它们存在，会被审计。
治理规则 2. 每个 agent 有一个指定负责人并明确升级路径。Agent 出问题，有人担责。负责人是一个角色而不是一个人，问责就消失了。
治理规则 3. 一页纸的使用政策，写进团队 handbook，每 90 天评审一次。政策评审不是可选项。工具和法规的变化速度都快过 handbook。
这就是我给每个团队的边界。正规化，而不是封锁。
上线前风险清单
在上线任何一个 agent 之前，先把这份清单跑一遍：
- 数据分级确认。agent 不触碰组织外的敏感数据。
- 数据源登记。agent 从哪里读数据、谁批准过。
- 权限最小化。agent 有明确权限，而不是默认开放。
- 审计日志开启。每个决策、每次输出都留下痕迹。
- 升级路径文档化。agent 出问题，通知谁、如何通知。
- 回滚方案明确。多快能关掉 agent。
- 外部写入限速。agent 一次不能发一百封邮件。
- 高风险 agent 走人工审批。超过 5 项权限的 agent 不自动批。
任何一个问题回答不出来，这个 agent 就不该上线。一个 30 分钟内关不掉的 agent 不是 agent，是负债。
不要部署的清单
不管 demo 多漂亮，我永远不会建议远程团队部署下面这些用例：
- 薪资、奖金、绩效决策。AI 生成的 HR 敏感内容草稿一律不放行。
- 无律师复核的合同法务分析。爆炸半径不可逆。
- 客服一线。AI agents 可以协助，不能替代。
- 不可逆的资金操作。钱出去就回来了。
- 内部员工绩效评估。伦理扛不住真实场景。
风险不在技术。风险在围绕技术的人。每一次 AI agent 部署翻车，都不是因为模型在胡扯，而是因为团队忘了 agents 是组织行为变化，不是 SaaS 采购。
一份 90 天落地清单
下面这份一页总结，可以打印出来贴墙上，用在下一次团队里。
- 第 1-30 天 识别与准备：访谈 10 人、选 1-2 个高杠杆用例、沙箱搭建、写治理文档。目标：一个待试点的 agent。
- 第 31-60 天 小范围试点：给 10 人用 2 周，跑量化 KPI，按反馈迭代。目标：一个有真实用户群的 agent。
- 第 61-90 天 扩展与迭代：全员推广、一页政策、价值报告、复盘不达标用例。目标：一个在生产的团队。
重点不在工具。重点在于当模型能承担协同税时，远程团队如何协作。90 天足够判断团队是否准备好了，不会多花一天。
不要跳过治理。不要跳过试点。不要把复盘当可选项。这三个纪律，把成功的 AI agent 部署和事后的影子 AI 事件隔开。