Agent、Skill、Tool、LLM 的四层关系与协同逻辑
在大模型智能体(Agent)体系中,LLM 是核心大脑,Tool 是外部能力接口,Skill 是能力封装载体,Agent 是整合所有组件的智能主体。四者从底层能力到上层应用形成清晰的依赖与协作关系,具体拆解如下:
一、核心定义与定位
| 组件 | 核心定位 | 本质 | 作用 |
|---|---|---|---|
| LLM(大语言模型) | 智能体的大脑/决策中枢 | 具备自然语言理解、推理、生成能力的模型(如通义千问、GPT) | 1. 理解用户任务;2. 决策需要调用的 Skill/Tool;3. 聚合执行结果生成最终回答 |
| Tool(工具) | 智能体的外部能力接口 | 可调用的外部服务/函数(如数据库查询 API、病历系统接口、向量库检索、计算器) | 弥补 LLM 能力短板(如实时数据、复杂计算、权限内操作) |
| Skill(技能) | 智能体的能力封装单元 | 对 Tool 的调用逻辑 + 输入输出适配 + 异常处理的封装 | 1. 屏蔽 Tool 的底层调用细节;2. 标准化 Tool 的使用方式;3. 组合多个 Tool 形成复合能力 |
| Agent(智能体) | 整合所有组件的智能主体 | 具备自主决策、任务规划、多组件协同能力的系统 | 1. 管理 Skill 列表;2. 基于 LLM 决策执行流程;3. 协调 Skill/Tool 完成复杂任务 |
二、四层依赖关系(从底层到上层)
四者的依赖关系是 LLM ← Tool ← Skill ← Agent,底层组件支撑上层组件,上层组件整合底层能力:
- LLM 是所有组件的基础:没有 LLM 的推理决策能力,Skill 的选择、Tool 的调用都无法自动化完成;
- Tool 是 LLM 的能力延伸:LLM 本身无法直接操作外部系统(如查数据库、调病历接口),必须通过 Tool 接口实现;
- Skill 是 Tool 的"标准化封装壳":原始 Tool 可能存在参数复杂、调用方式不统一、无异常处理等问题,Skill 解决这些问题,让 LLM 能"无门槛调用";
- Agent 是最终的整合载体:Agent 持有 LLM 实例、Skill 列表,是面向用户的交互入口。
三、核心协同流程(以医疗病历分析为例)
以医疗智能体分析患者病历的场景,完整拆解四者的协作步骤:
- 用户输入任务 :
"分析患者张三的病历,判断是否存在血糖异常" - Agent 接收任务,交给 LLM 解析
- Agent 将任务 + 自身的 Skill 列表(如
病历查询技能、血糖数据解析技能、报告生成技能)传入 LLM; - LLM 基于 Prompt 推理:
"需要先获取张三的病历数据 → 调用病历查询技能;再解析血糖指标 → 调用血糖数据解析技能;最后生成报告"。
- Agent 将任务 + 自身的 Skill 列表(如
- LLM 决策调用 Skill,Agent 执行
- 第一步:调用「病历查询技能」
- 该 Skill 内部封装了
电子病历系统 Tool(API 接口); - Skill 自动处理:参数拼接(患者 ID=张三)→ 调用 Tool API → 解析返回的 JSON 数据 → 提取血糖检测结果(如
血糖值 7.8 mmol/L); - Skill 将标准化结果返回给 Agent。
- 该 Skill 内部封装了
- 第二步:调用「血糖数据解析技能」
- 该 Skill 封装了
医疗参考值 Tool(本地知识库/远程接口); - Skill 执行:对比血糖值与参考范围(3.9-6.1 mmol/L)→ 判定为"血糖异常";
- Skill 返回解析结论给 Agent。
- 该 Skill 封装了
- 第一步:调用「病历查询技能」
- LLM 聚合结果,生成最终回答
- Agent 将两个 Skill 的执行结果传给 LLM;
- LLM 基于 Prompt 生成自然语言报告:
"患者张三的血糖检测值为 7.8 mmol/L,高于正常参考范围(3.9-6.1 mmol/L),存在血糖异常风险"。
- Agent 将结果返回给用户
四、关键关联细节
1. Skill 与 Tool 的关系:封装与被封装
- 一对一封装 :一个 Skill 封装一个 Tool,例如
计算器 Skill封装计算器 Tool,负责参数校验(如输入是否为数字)、调用执行、结果格式化。 - 一对多封装 :一个 Skill 组合多个 Tool 形成复合能力,例如
病历分析 Skill同时封装病历查询 Tool+医疗知识库 Tool+报告生成 Tool,按顺序调用三个 Tool 完成分析。 - 核心价值:Skill 让 LLM 无需关心 Tool 的底层实现(如 API 地址、参数格式),只需调用标准化的 Skill 名称即可。
2. LLM 与 Skill/Tool 的关系:决策与执行
-
LLM 不直接调用 Tool,而是通过 "决策调用 Skill" 间接使用 Tool 能力;
-
这种"LLM → Skill → Tool"的分层模式,核心是通过 Prompt 约束 LLM 的决策逻辑 ,例如:
你是医疗智能体,可调用的技能有: 1. 病历查询技能:参数为患者姓名,返回病历原始数据 2. 血糖解析技能:参数为血糖值,返回是否异常 请根据用户任务,选择合适的技能,按 JSON 格式输出:{"skill_name": "...", "params": {...}} -
LLM 根据 Prompt 生成标准化的 Skill 调用指令,Agent 解析后执行对应的 Skill。
3. Agent 与所有组件的关系:管理者与协调者
Agent 是四者的"总指挥",核心职责包括:
- 组件管理:注册/注销 Skill、维护 Tool 的权限配置、管理 LLM 的上下文(Context);
- 流程控制:支持单步执行(如 ReAct 模式)、多步规划(如 CoT 思维链)、分支/并行执行;
- 异常兜底:当 Skill/Tool 调用失败时,触发降级策略(如使用默认值、调用备用 Skill);
- 记忆能力:记录任务执行历史,支持长对话上下文管理。
五、关系总结(一句话概括)
Agent 是整合者,通过 LLM 的决策能力,调用封装了 Tool 接口的 Skill,从而完成单个 LLM 或单个 Tool 无法完成的复杂任务。
简单类比现实世界:
- LLM = 医生的专业知识与诊断思维;
- Tool = 医院的检查设备(如血糖仪、CT 机);
- Skill = 医生的操作技能(如使用血糖仪、解读 CT 报告);
- Agent = 完整的诊疗医生,用专业知识结合设备操作技能,为患者提供诊断服务。