很多 AI agent 平台在扩张期都会遇到同一种压力：新的业务域想接入得越来越快。法务想上、采购想上、财务想上、客服想上，谁都希望平台把前面的成功复制过去。问题在于，业务域接入失败时，最常见的根因并不是模型能力不够，而是域本身还没准备好。数据字段没有统一口径、权限边界仍靠人工默契、失败后的人工兜底没人接、SLA 只存在于口头承诺里，这样的域即便强行接入，平台后面也会在支持和例外里付出更高代价。
很多团队会把 onboarding 误解成“技术联调开始了”。但对 AI agent 平台来说，真正重要的是联调之前：这条业务线是否已经把最基本的运行契约讲清。没有 domain onboarding contract，平台会反复陷入一种表面上在推进、实际上在透支的状态：功能似乎接进去了，可一到真实高峰、真实失败或真实升级场景，就发现谁也说不清这条自动化到底答应了什么。
所以 onboarding contract 的价值，不是多一套文档，而是把“这条业务域到底准备好了没有”变成一个可以被快速判断、被拒绝、也被分阶段通过的门槛。没有 readiness，平台越着急扩域，后面越容易被域级混乱拖慢。
建议配合 AI agent Use-Case Intake 与 Automation Review Board、AI agent Connector Certification 与 Revalidation、AI agent Delegated Admin 与 Scoped Operations 和 AI agent Support Replay Pack 与 Escalation Handoff 一起看。
域接入真正要对齐的，不只是接口，而是四类运行契约
| 契约类型 | 必须说清什么 | 缺了会发生什么 |
|---|---|---|
| 数据契约 | 关键字段、缺失值、历史样本、ground truth | 模型和规则永远在猜业务语义 |
| 权限契约 | 谁能看、谁能改、谁能批准、谁能兜底 | 出事后只能靠临时越权救火 |
| 服务契约 | 哪类任务保证什么时效、什么结果、什么退化模式 | 业务以为平台答应了比实际更多的事 |
| fallback 契约 | 失败后谁接手、在哪接手、怎样继续 | 自动化一旦失效就直接掉地上 |
很多域接入之所以拖成反复返工，就是因为团队只对齐了第一行。接口能打通当然重要，但如果后面三行还没定下来，平台上线的其实只是一个“能跑 demo 的流程”，不是一个能进生产的业务能力。
Readiness 最常被低估的，不是数据清洗，而是失败后的责任链
一条域自动化要进入生产，大家通常会先讨论字段是否齐全、样本是否可用、连接器是否稳定。这些都对，但真正最容易把平台拖进长期痛苦的，往往是失败责任链没先讲明。比如：
- 当 agent 判不准时，谁来做人工接手，是否有固定值班角色
- 当连接器失败时，业务接受延后重试，还是要求立即转人工
- 当 SLA 无法满足时，业务是否接受退化输出，还是必须直接停用
这些问题如果不在 onboarding 阶段讲清，平台后面就会被迫在事故现场临时定义责任。那时每一个决定都会更贵，也更容易引发“不知道这是平台问题还是业务准备不足”的争议。
一个常见事故：业务域看起来已经准备好了，结果上线后每周都在补例外
某团队准备把采购审核流程接入 agent。表面上看一切都具备：历史数据不少，流程也相对标准，还有明确的业务 owner。上线之后问题却一直没有停：同一个字段在不同采购类别里语义不同，历史样本里大量人工备注无法结构化，某些高风险单据必须由特定角色复核，而这些角色并没有固定轮值。技术团队最开始以为是 prompt 和规则还需要优化，后来才发现真正没准备好的，是整个域级运行契约。
最后团队没有继续在模型上硬调，而是先把 onboarding contract 重做了一次：字段口径和例外分类先被统一，高风险单据的人工兜底被写成固定流程，业务方也接受了首阶段只做预审和排序、不直接给最终建议。这样一来，平台不是一次性“全接进来”，但真正开始站稳了。
如果你现在只能先补一层，先让每个新域都回答“失败后谁接住”
很多平台最先补的是 readiness checklist，当然有帮助。但如果只能先问一个最能暴露真实准备度的问题，我会先问：这条域自动化一旦失败，谁在什么时候、通过什么入口接手。这一个问题几乎会把很多隐性准备度一起照出来。因为能回答它的域，通常数据、权限和服务边界也已经被认真讨论过；回答不了的域，往往只是看起来准备好了。
AI agent 平台扩域不是接更多接口那么简单，它本质上是在接更多现实世界的责任边界。准备好这些边界，再接入系统，平台才不会把增长变成长期支持负担。
延伸阅读：
