在 Solon AI 的设计哲学中，Tool（工具） 和 Skill（技能） 是构建智能体的两大核心支柱。理解它们的关系与区别，是开发高性能、可控 AI 应用的关键。

如果你是小白，可以先这样理解：

* Tool，相当于函数（Function）
* Skill，相当于类（Class）


### 1、原子执行（Tool） vs. 领域专家（Skill）


#### Tool（工具）：智能体的“手”

Tool 是一个原子化的执行单元。它通常对应代码中的一个具体方法，负责完成一项特定的任务（如查询数据库、发送邮件、调用天气接口）。

* 核心逻辑：输入参数 -> 执行逻辑 -> 返回结果。
* 模型感知：模型只知道这个工具“能做什么”以及“需要什么参数”。

#### Skill（技能）：智能体的“大脑模块”

Skill 是对一组能力及其使用规范的封装。它不仅包含“手”（Tools），还包含“思维方式”（Instruction/SOP）和“感知能力”（isSupported）。

* 核心逻辑：意图识别 + 执行约束 + 工具集。
* 模型感知：模型不仅知道有哪些工具，还知道在什么场景下使用、按什么步骤使用、以及使用时的禁忌。



### 2、Skill 与 Tool 的深度对比




| 维度 | Tool (FunctionTool) | Skill (Skill) |
| -------- | -------- | -------- |
| 组成单位     | 单个函数/方法     | 指令 (Prompt) + 工具集 (Tools) + 状态     |
| 抽象层次     | 物理层：解决“怎么做”     | 逻辑层：解决“什么时候做、按什么规程做”     |
| 上下文感知     | 无感知：被动等待模型调用     | 强感知：能根据 Prompt 决定是否激活 (isSupported)     |
| 注入内容     | 只有工具的 Schema (JSON)     | 注入 System Prompt 片段 + 工具列表     |
| 约束力     | 弱：模型根据描述自由发挥     | 强：通过指令强制模型遵循 SOP     |
| 注册方式     | defaultToolAdd  或 toolAdd    | defaultSkillAdd 或 skillAdd     |


### 3、它们之间的关系：包含与染色

在 Solon AI 中，Skill 与 Tool 并不是互斥的，而是包含与增强的关系：


#### 包含关系：

一个 Skill 内部通常挂载了多个 Tool。例如“财务技能”包含“对账工具”和“转账工具”。

#### 染色机制 (Coloring)：


这是 Solon AI 的特色。当你注册一个 Skill 时，它会自动为其内部的所有 Tool 打上元数据标签（如 tool.metaPut("skill", "finance")）。

* 效果：模型在看到工具列表时，能清晰地识别出哪些工具属于哪个专业领域，从而更好地对齐该领域的指令约束。


### 4、开发中如何选择？


#### 场景 A：选择使用 Tool

如果你只需要提供一个简单的、通用的功能，且不需要额外的逻辑约束，请直接定义 Tool。

* 例子：获取当前系统时间、字符串加解密、简单的数学运算。
* 理由：这些功能是确定性的，不需要告诉 AI“什么时候该用”，AI 只要看到描述就能理解。

#### 场景 B：选择使用 Skill

如果你的功能涉及业务流程、安全风险或复杂的上下文判断，请封装为 Skill。

* 例子：技术支持（TechSupportSkill）
  * 为什么不用 Tool？ 如果只给 AI 一个“发工单”工具，它可能会在没尝试解决问题前就乱发工单。
  * Skill 的优势：通过 getInstruction 告诉 AI：“必须先查知识库，查不到再问版本号，最后才能发工单”。
* 例子：动态网关（GatewaySkill）
  * 为什么不用 Tool？ 工具太多会撑爆上下文。
  * Skill 的优势：通过 isSupported 动态判断用户意图，只在相关时才把工具塞给 AI。


### 5、 最佳实践总结


* 单一职责用 Tool：如果你写的是一个通用的、工具性的函数。
* 业务流程用 Skill：如果你写的是一个业务模块，需要 AI 遵循特定的操作手册 (SOP)。
* 由简入繁：
  * 先写 Tool。
  * 发现 AI 调用工具的顺序不对、或者在不该用的时候乱用？
  * 用 Skill 把这个 Tool 包装起来，加上 getInstruction 约束它。

