Agent、Skill、Tool、LLM 的四层关系与协同逻辑

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,底层组件支撑上层组件,上层组件整合底层能力:

  1. LLM 是所有组件的基础:没有 LLM 的推理决策能力,Skill 的选择、Tool 的调用都无法自动化完成;
  2. Tool 是 LLM 的能力延伸:LLM 本身无法直接操作外部系统(如查数据库、调病历接口),必须通过 Tool 接口实现;
  3. Skill 是 Tool 的"标准化封装壳":原始 Tool 可能存在参数复杂、调用方式不统一、无异常处理等问题,Skill 解决这些问题,让 LLM 能"无门槛调用";
  4. Agent 是最终的整合载体:Agent 持有 LLM 实例、Skill 列表,是面向用户的交互入口。

三、核心协同流程(以医疗病历分析为例)

医疗智能体分析患者病历的场景,完整拆解四者的协作步骤:

  1. 用户输入任务"分析患者张三的病历,判断是否存在血糖异常"
  2. Agent 接收任务,交给 LLM 解析
    • Agent 将任务 + 自身的 Skill 列表(如病历查询技能血糖数据解析技能报告生成技能)传入 LLM;
    • LLM 基于 Prompt 推理:"需要先获取张三的病历数据 → 调用病历查询技能;再解析血糖指标 → 调用血糖数据解析技能;最后生成报告"
  3. LLM 决策调用 Skill,Agent 执行
    • 第一步:调用「病历查询技能」
      • 该 Skill 内部封装了电子病历系统 Tool(API 接口);
      • Skill 自动处理:参数拼接(患者 ID=张三)→ 调用 Tool API → 解析返回的 JSON 数据 → 提取血糖检测结果(如血糖值 7.8 mmol/L);
      • Skill 将标准化结果返回给 Agent。
    • 第二步:调用「血糖数据解析技能」
      • 该 Skill 封装了医疗参考值 Tool(本地知识库/远程接口);
      • Skill 执行:对比血糖值与参考范围(3.9-6.1 mmol/L)→ 判定为"血糖异常";
      • Skill 返回解析结论给 Agent。
  4. LLM 聚合结果,生成最终回答
    • Agent 将两个 Skill 的执行结果传给 LLM;
    • LLM 基于 Prompt 生成自然语言报告:"患者张三的血糖检测值为 7.8 mmol/L,高于正常参考范围(3.9-6.1 mmol/L),存在血糖异常风险"
  5. 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 = 完整的诊疗医生,用专业知识结合设备操作技能,为患者提供诊断服务。
相关推荐
冬奇Lab15 小时前
一天一个开源项目(第36篇):EverMemOS - 跨 LLM 与平台的长时记忆 OS,让 Agent 会记忆更会推理
人工智能·开源·资讯
冬奇Lab15 小时前
OpenClaw 源码深度解析(一):Gateway——为什么需要一个"中枢"
人工智能·开源·源码阅读
AngelPP19 小时前
OpenClaw 架构深度解析:如何把 AI 助手搬到你的个人设备上
人工智能
宅小年19 小时前
Claude Code 换成了Kimi K2.5后,我再也回不去了
人工智能·ai编程·claude
九狼19 小时前
Flutter URL Scheme 跨平台跳转
人工智能·flutter·github
ZFSS19 小时前
Kimi Chat Completion API 申请及使用
前端·人工智能
天翼云开发者社区20 小时前
春节复工福利就位!天翼云息壤2500万Tokens免费送,全品类大模型一键畅玩!
人工智能·算力服务·息壤
知识浅谈20 小时前
教你如何用 Gemini 将课本图片一键转为精美 PPT
人工智能
Ray Liang21 小时前
被低估的量化版模型,小身材也能干大事
人工智能·ai·ai助手·mindx
shengjk11 天前
NanoClaw 深度剖析:一个"AI 原生"架构的个人助手是如何运转的?
人工智能