工具接入与 Tool Hub 安全

适用版本：ChengOS v0.1.0+ ｜ 最后核对：2026-08-12 ｜ 来源：crates/cheng-nodes/src/nodes/builtin/tools/tool_hub、tools/runtime、tools/mcp_hub.rs、tools/skills_hub

把工具节点直接连到智能体上，在一定规模内是可行的。但每个工具都会往模型的上下文里增加一份函数定义，因此十几个工具意味着每一次请求都带着十几份 Schema——既昂贵，也越来越容易让模型搞不清该用哪个。

Tool Hub（tools/tool_hub）通过在众多工具前面放一个稳定函数来解决这个问题。

Tool Hub 是什么，不是什么

Tool Hub 不是第二套工具运行时。 它是位于既有 ToolRuntime 之上、面向工作流的发现、配置与命令路由层。执行仍然走共享运行时的策略、约束与审批流水线——Tool Hub 决定什么可以运行并路由调用，运行本身由运行时负责。

模型看到的是一个带两个动作的包装函数：

每条命令在分派之前都会针对可信白名单做校验。

真正关键的安全属性

配置是静态的，大语言模型永远无法写入它。 工作流作者在属性面板中决定工具范围；模型只能在这个范围内选择。模型提供的名称是一个查找键，绝不是权限依据。

正是这一条规则，让「给模型一个通用的 execute 函数」这件事变得安全，而不必逐个连线工具。没有它，一个通用执行器就是一个任意代码执行的攻击面。

两种模式

user 模式

工作流作者通过 enabled_tools 在属性面板中启用工具。list_tools 只返回这些条目，execute 也只接受已配置范围内的命令。

当你自己设计智能体的能力边界时使用这种模式。

skill 模式

由所选技能的规范化 tool_hub.tools 声明决定什么可以执行。其中两个细节承载了关键作用：

• list_tools 不可用。 模型改为通过 Skills Hub 的 describe 了解工具面。不存在第二条可能已经过期的发现路径。
• **每次 execute 都会重新解析技能当前的规范化定义。** 模型提供的技能名只是这次查找的键，因此被编辑过的技能会立即生效，模型也无法锁定在某个更宽松的旧版本上。

当在同一个循环中，先前的 Skills Hub describe 恰好建立了唯一一个可信的活跃技能绑定时，skill_name 可以省略。零个绑定或多个不同的绑定属于歧义，会被拒绝而不是猜测——一个描述过两个技能的智能体必须说明它指的是哪一个。

其他几个 Hub

Tool Hub 是四个聚合器之一，每个面向不同的来源：

它们可以组合：一个智能体可以同时连接 Tool Hub、MCP Hub 和 Skills Hub，它们的定义会被合并成一套工具面。

MCP 服务

tools/mcp_hub 通过 stdio、SSE 或 HTTP 连接外部 MCP 服务。服务暴露的工具、提示词模板和上下文资源会被自动发现——添加一个服务就等于添加能力，无需编写任何节点。

可以在管理控制台中可视化配置服务，也可以通过环境变量批量注入规则。需要认证的 MCP 服务和其他工具一样从凭证库获取凭证，因此密钥不会进入模型的上下文。

技能

技能是打包好的能力：一份清单、说明和可选代码。已安装的技能可通过 tools/skills_hub 发现，其中 describe 会返回技能的规范化工具面——这也正是 Tool Hub skill 模式所依赖的活跃技能绑定的建立方式。

技能通过一条流水线导入：解析来源 → 校验（tools/validate_skill_spec）→ 取得审批 → 事务性写入（tools/write_skill_package）；文件 watcher 会热加载结果。来源可以是自然语言、URL、Git 仓库，或标准的 SKILL.md。

如何选择

下一步

• ReAct 智能体指南——消费这些工具的循环。
• 模型配置——各供应商对原生 function calling 的支持情况。