要同时解决协议、权限、语义、审计四道坎，靠的不是写更多代码，而是一组正确的领域抽象。
一、设计目标：把「接入」变成「建模」
第 1 期我们说过，接 ERP 难在协议、权限、语义、审计四道坎。要同时解决它们，靠的不是写更多代码，而是一组正确的领域抽象。我们的答案是一套六个概念组成的模型，它们回答了六个问题：
| 概念 | 回答的问题 | 一句话 |
|---|---|---|
| 连接器类型（config） | 这是什么系统？ | 声明需要哪些连接参数：地址、租户、应用凭证…… |
| 连接实例（instance） | 连的是哪一个？ | 一份填好的真实参数，代表一条可用连接 |
| 资源（resource） | 能做什么？ | 一个 API = 一个 Agent 工具，带参数结构与风险等级 |
| 角色（role） | 谁能用什么？ | 一组资源的白名单，授权的最小单位 |
| 技能（skill） | 怎么用好？ | 写给大模型看的调用说明书 |
| 用户授权（grant） | 具体给谁？ | 「用户 × 实例 × 角色」三元组，授权的原子 |
二、三个关键设计决策
决策 1：类型与实例分离
「用友云」是一个类型（它需要 host、租户、应用 key、应用 secret 四个参数——这由类型上的参数 Schema 声明）；「集团测试环境」和「生产环境」是两个实例。类型定义一次，实例随便建；参数 Schema 用管理端内置的可视化 Schema 编辑器维护，非开发人员也能调整字段类型、默认值与是否必填。
这带来一个直接收益：换环境不改系统。测试实例调通后，新建一个生产实例、把授权迁移过去即可。
决策 2：资源是唯一的能力表达
我们不把「能力」散落在提示词或代码里，而是统一登记为资源：HTTP 方法、端点、输入参数结构，外加一个容易被忽视但极其重要的字段——风险等级：
- 只读：查询类接口，可以放心授权；
- 写入：创建/修改类接口，需要更谨慎的白名单策略；
- 审批级：涉及财务、审批等敏感操作，任何通配授权都自动排除它。
这个分级直接决定了第 4 期要讲的权限策略边界。
决策 3：授权是三元组，而不是开关
很多产品的连接器是「绑定了就能用全部功能」。我们坚持授权粒度为 用户 × 实例 × 角色：
- 同一个实例，销售角色只能查，财务角色可以看审批级接口；
- 同一个用户，对测试实例有完整角色，对生产实例只有查询角色；
- 授权上还可以附带扩展参数（例如可见的组织列表），实现「同一个实例、不同用户看到不同组织的数据」——这是多集团/多事业部场景的关键能力。
三、回到那个例子
销售问：「查华东集团下 A 物料在客户『某某医药』的近期价格记录。」
在六表模型下，这句话能被安全执行，是因为链路早已闭合：
- 该用户有一条对生产实例的授权，角色是「销售查询」；
- 「销售查询」角色包含组织、物料、价格记录三个资源；
- 授权扩展参数里写着
orgs=[华东集团]，所以「华东」不是 Agent 猜的，而是权限算出来的。
四、为什么是「六」？
七个概念里，我们刻意没有把「调用日志」算进模型六件套——日志是治理产物而非建模对象，它属于第 4 期。而模型里的每一环都对应一次管理动作：定义类型 → 建实例 → 登记资源 → 配角色 → 写技能 → 授用户。六个概念，六个管理页面，一条可解释的授权链路。
客户的安全团队看到这条链路，往往比看到功能列表更容易建立信任。
相关阅读
- 第 1 期：为什么企业需要 ERP Connector
- 全部期数目录：AI 笔记