资源即工具：把 ERP API 变成 Agent 的原生能力

「资源即工具」看似只是格式转换，实际上它给了企业三个承诺：一致性、可扩展、可治理。

资源即工具：从 ERP API 到 function calling 全屏查看 ↗

一、大模型眼中的「工具」长什么样

现代大模型都支持统一的工具调用协议（function calling）：平台在对话开始时提交一份工具清单——每个工具一个名字、一段描述、一份 JSON Schema 参数定义——模型按需发起调用，平台执行后把结果回填给模型。

这份清单里的一个工具，长这样：

{
  "name": "yonyou_query_price_records",
  "description": "按组织、产品与客户查询集团价格记录，支持时间范围过滤",
  "parameters": {
    "type": "object",
    "properties": {
      "org":     { "type": "string", "enum": ["华东集团"], "description": "组织编码" },
      "product": { "type": "string", "description": "产品 ID" },
      "price_type": { "type": "string", "description": "价格类型编码" }
    },
    "required": ["org", "product"]
  }
}

三个部分各司其职：名字让模型精确引用，描述让模型判断什么时候该用它，参数 Schema 约束模型只能按结构填参。注意 org 参数里的 enum——它的取值范围只有一个，这不是巧合，是后面要讲的权限收窄。

这意味着，只要能把 ERP API 翻译成这个协议，Agent 就「原生」具备了调用 ERP 的能力。翻译工作就是 Connector 的核心：资源（Resource）= 工具（Tool）。

二、一次翻译的三步

手记 · 资源登记 → Schema 投影 → 工具注入，下方是一次工具调用的生命周期

第 1 步：命名与描述

资源的编码会与连接器编码拼接，生成符合模型工具命名规范的工具名——例如连接器 yonyou 下的资源 query_price_records，最终成为 yonyou_query_price_records。拼接出来的名字自带归属：看到工具名就知道它属于哪个系统，出了问题也能顺着名字查到资源登记。

描述文案则直接采用资源登记时写的业务语义描述。这里的原则是：描述是写给模型看的需求文档，写得越像「给新同事的交接文档」，模型调用越准。什么场景该用、什么场景不该用、参数怎么理解，都写在这里。

第 2 步：参数 Schema 投影

资源登记的输入参数结构会被投影为模型的 JSON Schema。其中有一类特殊处理：组织类参数会被权限系统自动收窄。

同一个资源，登记时 org 是一个普通的字符串参数；注入给具体用户时，Schema 被运行时改写：

"org": { "type": "string", "enum": ["华东集团"] }

如果用户的授权里只包含「华东集团」，那么该参数的取值范围在 Schema 层面就被限定为「华东集团」——模型不是「被要求不要乱填」，而是根本无法填别的值。权限不是一段提示词，而是协议本身的一部分。这是「把权限做进协议」的一个典型体现。

第 3 步：技能注入

工具清单解决「有什么可调」，技能文档解决「怎么调好」。技能分两层：连接器级写这个系统的通用调用常识（鉴权方式、分页口径、错误语义），实例级写当前环境的特有步骤，实例级覆盖连接器级。

技能以 Markdown 编写，在对话启动时拼入系统提示词（有大小上限），内容例如：

查询某客户某物料的集团价格需要三步：① 用组织编码查询组织列表 → ② 换取产品 ID → ③ 以产品 ID + 价格类型查询价格记录。

模型据此自主完成多步编排，而不是每一步都靠人下指令。

三、运行时：工具从哪里来

手记 · 运行时按实例、角色、组织、会话四层收敛，筛出的工具才进入模型；每次调用写入审计

一个平台里可能配置了十个连接器、几十个实例，但任何时刻，Agent 只看见当前会话有权限的部分：

用户在会话中绑定了某个实例（用户端弹窗选择）；
对话启动时，运行时做一次权限解析：用户 → 对该实例的角色 → 角色包含的资源；
仅授权资源被转换为工具注入；组织范围随授权注入为参数枚举；危险等级高的资源即使白名单里也受策略约束——通配授权永远不放行审批级资源，必须逐个显式授予；
模型发起工具调用 → Connector 执行器路由到对应的 Provider（内置实现或适配器进程）→ 业务系统；
结果回填模型，同时写入调用审计日志。

值得注意的是第 2 步的措辞：工具清单不是从配置里「读」出来的，而是算出来的。角色改了、授权停了、实例下线了，下一个会话的工具列表立刻不同——中间没有任何需要重新发布的环节。

工具列表是权限计算的产物，不是配置的罗列。 这句话是本期的题眼。

四、结论

「资源即工具」看似只是格式转换，实际上它给了企业三个承诺：

一致性：所有系统的能力都用同一种方式登记、授权、调用，Agent 侧零特殊逻辑；
可扩展：接一个新系统 = 登记一批资源，不需要碰 Agent 与对话层的代码；
可治理：每个工具都有明确的归属、风险等级与授权路径，安全评审有据可查。