大模型很聪明，但它「够不着」你的业务系统。这一期讲清企业接 ERP 的四道坎，以及我们为什么要把「接入」做成一条声明式管线。
一、大模型很聪明，但它「够不着」你的业务系统
过去两年，几乎所有企业都试过让 AI 助手回答业务问题。效果往往止步于两类：
- 闲聊式问答：模型只能基于训练知识泛泛而谈，给不出「华东大区本月 actual 销售出库金额」这种答案；
- 胶水式集成：开发同学为每个场景写一段专属的 API 对接代码，做十个场景就有十份代码，改一个接口全部重测。
问题的本质是：大模型的智能在企业内网「断网」了。ERP、CRM 这些系统有完整的开放 API，但把它们交给 Agent 使用，中间隔着四道坎：
| 坎 | 表现 |
|---|---|
| 协议坎 | 每个 ERP 的鉴权、签名、分页、错误码各不相同，Agent 无法直接理解 |
| 权限坎 | API Key 是「全有或全无」的，谁来调用、能调哪些接口、能看哪些组织的数据，没有表达手段 |
| 语义坎 | Agent 拿到一份 API 文档 ≠ 会用。参数怎么填、多步调用怎么编排，需要「用法说明」 |
| 审计坎 | 出了问题，说不清「哪次对话调了哪个接口、动了哪些数据」 |
这四道坎，就是我们设计 Connector 子系统的原因。
二、我们的答案：一条配置化的接入管线
xclaw-hub 的 Connector 子系统把「接入一个业务系统」拆成一条声明式管线，全程不需要为单个场景写代码：
连接器类型 → 连接实例 → 资源目录 → 角色 → 技能 → 授权给用户
- 连接器类型：声明「这是什么系统」——需要哪些连接参数（地址、应用凭证等），用可视化的 Schema 编辑器定义；
- 连接实例：填上真实参数的一次具体连接，密钥加密存储；
- 资源目录：把系统的每个 API 登记为一个「资源」，附上参数结构与风险等级（只读 / 写入 / 审批级）；
- 角色：一组资源的白名单，是授权的最小单位；
- 技能：写给大模型看的「使用说明书」——多步调用怎么编排、参数怎么取值；
- 授权：把「某实例 × 某角色」授予某用户，还可以按用户收窄可见的组织范围。
对客户来说，接入一个新系统 = 定义一次类型 + 登记一批资源 + 配几个角色；对最终用户来说，在会话里选一下实例，ERP 的能力就出现在 Agent 的工具列表里。
三、以用友 YonBIP 为例
我们选择用友 YonBIP（云 ERP）作为首个完整实例。客户视角的画面是这样的：
- 管理员在管理端创建「用友云」连接器，填入应用凭证，几分钟内完成健康检查；
- 系统内已内置 YonBIP 的资源目录：组织、物料、产品、价格类型、价格记录、调价记录、客户、供应商等开箱即用的查询能力（均为只读，风险可控）；
- 配置两个角色：「销售查询」开放组织/物料/客户/价格记录，「基础数据」只开放物料与供应商；
- 销售人员在自己的会话里绑定实例后，直接问：「帮我查华东集团下 A 物料在客户『某某医药』的近期价格记录。」
Agent 会自动完成：确定可用组织 → 查询物料 → 查询价格记录 → 汇总并提示风险点。全程没有为「查价格」这个场景写过一行代码。
四、这个系列会讲什么
接下来五期，我们按这条主线展开：
- 第 2 期：六表领域模型——为什么是「类型 / 实例 / 资源 / 角色 / 授权 / 技能」这组抽象；
- 第 3 期：资源即工具——一个 ERP API 如何变成大模型标准协议里的 function tool；
- 第 4 期：安全与治理——角色白名单、密钥加密、组织级数据隔离、调用审计；
- 第 5 期：YonBIP 实战——从配置到对话的端到端流程；
- 第 6 期：演进路线——独立 Connector 平台与本体论重构的构想。
一句话总结这一期：Connector 解决的不是「能不能调 API」，而是「敢不敢让 Agent 调 API」。
相关阅读
- 第 2 期：六表领域模型：一条从配置到授权的抽象链路