插件平台的通用设计：把外部能力变成可管理资源

很多系统一开始接第三方能力时，最直接的做法就是写代码。

比如接一个天气 API：

写 Client
↓
写 Service
↓
写 DTO
↓
重新发布

工具少的时候没问题，但能力越来越多以后，代码会越来越重。

更通用的做法是：

把外部能力从“代码”抽象成一种“平台资源”。

---

1. 插件资源化

一个插件不再只是某个 Java 类，而可以抽象成：

插件
=
元数据
+
Schema
+
鉴权配置
+
版本

这样一个外部 API 就可以被：

创建
修改
删除
查询
启用
禁用
版本管理

系统不需要每增加一个工具就重新写一套逻辑。

---

2. 管理模型和运行模型分离

平台通常会有两种视角。

管理侧关心：

名称
描述
图标
创建人
状态
分类

运行侧关心：

URL
Method
参数
Schema
鉴权
版本

因此可以拆成：

管理模型
→ 给人配置和运营

运行模型
→ 给机器真正执行

PaiFlow 里的 tool_box 和 tools_schema，本质上就是这种思路。

---

3. 配置驱动代替硬编码

传统方式：

新增 API
↓
写代码
↓
重新发布

配置化以后：

阅读 API 文档
↓
填写 Schema
↓
注册工具
↓
通用执行器执行

核心思想就是：

把经常变化的东西放进配置，把稳定的东西留在代码里。

通用执行器只负责：

读取配置
↓
解析配置
↓
构造请求
↓
执行

至于具体接的是天气、TTS 还是 OCR，它不需要提前知道。

---

4. CRUD 背后其实是业务流程

用户点击一次“创建插件”，背后可能不是简单的一条 INSERT。

而是：

Console
↓
保存管理数据
↓
保存执行 Schema
↓
保存鉴权信息
↓
刷新缓存
↓
插件正式可用

所以很多平台型系统里的 CRUD，本质上已经是：

跨服务的资源生命周期管理。

这也是为什么看起来只是“增删改查”，实际实现并不简单。

---

5. 配置和密钥应该分开

Schema 可以描述：

需要 Authorization
需要 X-API-Key
参数放 Header

但真实 Token 不应该直接写死在 Schema 中。

更合理的是：

Schema
→ 描述如何鉴权

安全存储 / Redis
→ 保存真实凭证

运行时再动态组合。

这样密钥更容易更新，也更方便权限和安全治理。

---

6. 插件系统一定要考虑安全边界

只要系统允许用户配置：

URL
Header
Token
请求参数

就必须考虑安全问题。

例如：

localhost
127.0.0.1
内网 IP
云服务内部地址

通常都不能随便访问，否则插件服务可能变成访问内部系统的跳板。

所以 URL 校验、鉴权、超时、限流、审计日志，都应该属于插件平台的一部分。

---

7. 什么时候可以复用这套设计

当你的系统开始出现下面这些情况时，就可以考虑这套模式：

外部 API 越来越多
工具需要动态添加
不同用户拥有不同工具
需要工具版本管理
需要统一鉴权
需要统一调用 HTTP / RPC / MCP
不希望每新增能力都重新发版

典型场景包括：

工作流平台
Agent Tools
MCP Server 管理
低代码平台
API 开放平台
AI 模型供应商管理
企业内部能力市场

这些系统表面不同，本质都在做一件事：

把能力抽象成资源，再统一管理和执行。

---

总结

插件 CRUD 真正值得学习的，不是数据库增删改查。

而是：

外部能力
↓
资源化
↓
配置化
↓
持久化
↓
版本化
↓
安全治理
↓
统一执行

最终目的就是：

把原本散落在代码里的外部能力，变成平台可以统一管理、授权、升级和调用的标准资源。

这套思路一旦掌握，以后再看 MCP、Agent Tool、API 平台或者低代码系统，会发现底层设计其实非常相似。