AI agent 平台一旦在公司内部或者客户侧跑出几个成功案例，接下来通常会迎来同一种热潮：越来越多业务都会觉得“这个流程也可以接 agent”“这个审批也可以自动化”“这个支持动作也应该让系统代做”。从增长角度看，这是平台开始被相信的信号；从治理角度看，这也是风险开始上升的起点。因为不是所有流程都适合自动化，更不是所有看起来重复的事情都适合在当前阶段交给 agent。
很多团队在扩张期最容易踩的坑，是把 use-case intake 当成需求收集，而不是资格审查。只要业务愿意提、价值听起来不错、技术上似乎也能接，就先排进路线图，等做完再看能不能稳住。结果平台做出一堆 exception-heavy、结果难验证、失败后没人兜底、边界模糊的能力，支持和工程团队再花更大代价去替这些“本来就不该先做”的用例擦屁股。
所以 automation review board 真正要做的，不是拖慢创新，而是把“什么应该先自动化、什么暂时还不该碰、什么只能先半自动化”变成一套能快速做判断的机制。没有这套 intake 过滤，AI agent 平台越成功，后面越容易被错误用例拖成低效平台。
建议配合 AI agent 评估框架完全指南、AI agent 证据来源与可信度分层、AI agent 人工审批控制台设计 和 AI agent 产品成功指标 一起看。
Intake 不是收集“想做什么”，而是先判断“这个场景值不值得接入”
| 维度 | 该先问什么 | 为什么它决定能不能接 |
|---|---|---|
| 可逆性 | 失败后能不能安全回滚或转人工 | 不可逆动作对早期平台极其危险 |
| 可验证性 | 成功和失败有没有明确标准 | 没法验证的流程会把评估体系拖空 |
| 例外密度 | 特殊情况是否频繁出现 | 例外过多的流程通常不适合先全自动化 |
| 业务收益 | 节省的是人力、时间还是错误率 | 没有明确收益，很难证明接入优先级 |
| 兜底路径 | 出错后谁接手、怎么接手 | 没有 fallback 的自动化只会制造支持债务 |
如果一个新用例连这些问题都答不出来，平台就不该把它当作“等开发排期”的普通需求。因为这意味着它现在缺的不是实现资源，而是最基本的交付边界定义。
Review board 真正该做的，不是层层审批，而是帮平台更早识别坏用例
很多团队一听到 review board 就担心会不会太官僚。问题在于，坏用例本来就会让平台付出更高成本，只是这些成本往往发生在上线之后：支持负担暴涨、手工兜底越来越多、客户理解不了状态、评估体系也无法证明这件事到底有没有价值。与其把这些成本放到后面再承担，不如在 intake 阶段就先筛掉明显不成熟的场景。
一个好的 review board，往往不需要很多人，但要看对几件关键事：
- 这个流程是不是高例外、低标准化的典型坏用例
- 是否存在清晰的人工 fallback 和升级链路
- 这次接入会不会把平台逼着补一堆并不该由平台承担的客户特殊逻辑
- 若只能先做半自动化，最小可交付形态是什么
这不是为了说“不”，而是为了让平台在做“是”之前知道自己到底答应了什么。
一个常见误判：流程看起来重复，但实际判断标准根本不稳定
某团队准备把供应商资质审核流程交给 AI agent，理由很充分：资料格式相对固定、量大、人工审核慢。项目一开始推进得很快，直到平台真的接入后才发现，这个流程的真正难点不在材料读取，而在大量上下文化例外：不同行业对同一字段的解释不同，客户内部政策也经常临时变，某些结论必须结合历史沟通记录判断。技术上 agent 能把材料先整理得很好，但一旦试图进一步自动决定，支持和人工审核团队的负担反而更高，因为他们得接住一堆半对半错、但很难快速判断风险大小的边缘案例。
问题并不是这个流程永远不能自动化，而是它本来就不适合一开始被定义成“全自动用例”。如果当初 intake 里把例外密度和可验证性看得更重，团队更可能先把它做成材料归档与风险预标，而不是直接承诺自动审批建议。
真正有用的 intake 产物，不是一页立项文档，而是一份最小资格包
一个能帮平台快速做判断的 intake packet，通常不需要很长，但要足够清楚：
- 要自动化的到底是哪一段，不是哪整个流程
- 成功与失败如何衡量，谁来给 ground truth
- 哪些动作是可逆的，哪些动作必须停在人前
- 例外样本长什么样，比例大概有多少
- 上线后谁负责支持、复盘和价值验证
这份资格包的作用，不是让文档更漂亮，而是让 review board 不用凭直觉和提案人的热情做决定。只有这样，平台才不会被“这个也能做、那个也能做”的增长幻觉带着走。
如果你现在只能先补一层，先把不适合自动化的用例更早说出来
很多平台都已经会写 rollout plan、评估方案和上线 checklist，但仍然缺最前面那一步：谁来在需求刚进来时，明确说出“这不是现阶段适合接入的用例”。这听上去像在减速，实际上是在帮平台保住后续速度。因为真正拖慢平台的，从来不是那些被早早拒掉的坏用例，而是那些被热情推进、上线后才发现边界模糊的坏用例。
AI agent 平台扩张得越快，越需要一套敢于先筛选、后交付的 intake 机制。不是所有自动化机会都该立刻抓住，先选对用例，平台才有机会把成功复制下去。
延伸阅读：
