工作流与插件集成：从 PluginNode 到 Agent Tool

当工作流运行到插件节点时，本质上要解决三件事：

调用谁
参数从哪里来
底层怎么执行

这就是插件节点存在的意义。

1. 节点配置就是调用契约

一个插件节点通常只需要保存：

pluginId
operationId
version
businessInput

分别表示：

pluginId
→ 调哪个工具

operationId
→ 调工具里的哪个能力

version
→ 使用哪个版本

businessInput
→ 从工作流上下文取哪些参数

这样 Workflow 不需要知道第三方 API 的具体细节。

工作流上下文通常很复杂：

用户输入
LLM 输出
上一个节点结果
系统变量

而工具可能只需要：

{
  "city": "北京"
}

所以中间需要一层转换：

Workflow Context
↓
提取 businessInput
↓
Tool Input

核心思想是：

上层数据模型和工具输入模型不要直接耦合。

工具最开始是一份 Schema：

Schema
→ 描述工具怎么调用

运行时再转换成：

Tool
→ 真正可以执行

整个过程就是：

Schema
↓
解析
↓
Tool
↓
run()

这是一种很常见的设计：

配置描述能力，运行时对象负责执行能力。

Workflow 最好只调用一个统一入口：

PluginNode
↓
PluginService

底层再决定：

内置 TTS
HTTP Tool
MCP Tool
其他能力

这样上层不用关心底层协议。

核心思想是：

对上统一，对下适配。

现在的 Workflow 是：

人提前决定调用哪个 Tool

未来 Agent 则是：

模型动态决定调用哪个 Tool

但下面这些东西都可以继续复用：

Schema
Tool
Link
鉴权
执行器

所以真正变化的是：

谁来做决策

而不是：

工具怎么执行

HTTP、Java 内置工具、MCP，本质上都可以继续抽象成：

Tool

理想架构是：

Workflow / Agent
      ↓
     Tool
   /   |   \
HTTP  Java  MCP

这样以后增加新协议，上层基本不用改。

这套设计适合：

工作流平台
Agent Tools
MCP 平台
低代码平台
插件系统
规则引擎

特别是当系统里“能力越来越多、协议越来越杂”时，非常适合增加统一 Tool 抽象。

整个设计可以压成：

上层
→ 决定调用什么

中间层
→ 把上下文转换成工具输入

下层
→ 把 Tool 转换成具体协议并执行

最值得记住的一句话是：

决策和执行分离，上层只决定“用什么工具”，下层负责“这个工具具体怎么跑”。