插件发现与执行：从 toolId 到真实 HTTP 请求

插件注册完成后，工作流真正运行时还要解决两个问题：

这个工具是谁？这个工具怎么调用？

这就是插件发现和执行。

1. 插件发现：ID 找元数据

Workflow 不需要记住工具的 URL、Method、鉴权方式。

它只需要保存：

toolId
version
operationId

运行时：

toolId + version
↓
找到工具 Schema

所以插件发现的本质是：

通过唯一 ID 找到能力描述。

这种设计很常见，插件、模型、MCP Server、配置中心都可以这样做。

找到 Schema 后，Link 就知道：

请求地址
GET / POST
参数放哪里
怎么鉴权

然后根据 Schema 动态构造请求：

Schema
+
Workflow 参数
↓
HTTP Request

这样新增工具时，不需要一直修改核心执行代码。

核心思想是：

用元数据驱动执行，而不是把调用逻辑写死。

Workflow 只负责提供业务参数。

Link 再根据 Schema 把参数放到不同位置：

Path
Query
Header
Body

例如：

userId → Path
city   → Query
token  → Header
JSON   → Body

本质上是在做：

统一参数 → 目标协议参数。

以后做 HTTP、RPC、MCP 适配，都能复用这套思路。

不同第三方 API 的请求和返回格式可能完全不同。

Link 的作用就是把这些差异挡在下面：

Workflow
↓
统一工具协议
↓
Link
↓
不同第三方 API

调用完成后，再把结果统一包装返回 Workflow。

这样上层不用关心每个第三方接口的细节。

Tool Schema 一般是：

修改少
读取多

所以非常适合缓存：

Redis
↓ miss
MySQL

这种模式也适用于：

模型配置
路由规则
权限配置
字典数据

当系统出现下面这些情况时，可以考虑这套设计：

能力很多
调用协议不统一
工具需要动态新增
不想频繁修改核心代码
上层希望屏蔽底层差异

典型场景有：

插件平台
Agent Tools
MCP
低代码平台
API Gateway
模型平台

整个过程可以压成：

toolId
↓
找到 Schema
↓
解析调用规则
↓
路由参数
↓
执行底层协议
↓
统一返回

最值得记住的一句话是：

上层通过 ID 找能力，中间层通过元数据理解能力，再把统一参数翻译成底层真正能执行的请求。