Agent ， Skill 和 Tool的关系

前言🔖

我会用通俗类比 + 清晰对比表 + 核心逻辑图，帮你彻底理清 Agent、Skill、Tool 三者的关系 —— 这三个概念本质是「层级递进 + 功能分工」，在不同框架（如 LangChain）中叫法略有差异，但核心逻辑完全一致。

一、核心定义（通俗版，先建立认知）🔖

先给一个生活化的类比：把 Agent 看作「厨师」，Skill 是「做菜的能力」，Tool 是「锅铲 / 菜刀 / 电磁炉」。

概念	本质	类比（厨师场景）	技术场景示例
Tool	「具体的物理工具」，不可再拆分的最小执行单元	锅铲、菜刀、电磁炉	一个查询天气的函数、调用 API 的方法、计算器函数
Skill	「组合工具完成某类任务的能力」，由一个 / 多个 Tool 构成	做红烧肉的能力（= 菜刀切肉 + 炒锅翻炒 + 电磁炉加热）	「天气查询 Skill」（= 调用天气 API 的 Tool + 数据格式化 Tool）
Agent	「决策者」，掌握多个 Skill，根据需求选择 / 组合 Skill 完成复杂任务	厨师（掌握「做红烧肉」「炒青菜」等多个 Skill，根据顾客需求选对应的 Skill 做菜）	点餐 Agent（掌握「菜品查询 Skill」「价格计算 Skill」，根据用户点餐需求调用对应 Skill）

二、核心关系（逻辑图 + 拆解）🔖

关键拆解：

Tool 是基础：Skill 和 Agent 的「最小执行单元」
- Tool 是「原子级」的，只能做一件最具体的事（比如「调用天气 API 查北京天气」「计算两个数的和」），无任何决策能力；
- Tool 是 Skill 和 Agent 能落地的「物理基础」—— 没有 Tool，Skill 只是「空能力」，Agent 只是「空大脑」。
Skill 是中间层：Tool 的「组合封装」，Agent 的「可用能力」
- Skill 是为了完成「某一类业务任务」，把一个或多个 Tool 按逻辑组合起来的「能力包」；
- 比如「价格计算 Skill」=「读取菜品单价的 Tool」+「累加计算的 Tool」+「折扣计算的 Tool」；
- Skill 是 Agent 能「直接调用」的单位 ——Agent 不会直接调用零散的 Tool，而是调用封装好的 Skill（就像厨师不会直接说「我要用锅铲」，而是说「我要做红烧肉」）。
Agent 是顶层：Skill 的「决策者 + 整合者」
- Agent 不关心 Skill 内部由哪些 Tool 构成，只关心「这个 Skill 能完成什么任务」；
- Agent 的核心工作：接收用户需求 → 判断需要调用哪个 / 哪些 Skill → 让 Skill 执行（底层调用 Tool）→ 整合 Skill 的结果返回给用户；
- 比如点餐 Agent 收到「我要点红烧肉算总价」的需求后，决策调用「菜品查询 Skill」→ 再调用「价格计算 Skill」→ 整合两个 Skill 的结果，告诉用户「红烧肉在售，总价 48 元」。

二、框架中的对应关系（以 LangChain 为例）🔖

在 LangChain 等主流框架中，Skill 和 Tool 常常混用（框架里一般只提 Tool，Skill 是业务层对 Tool 的封装），这是新手最容易混淆的点：

通用概念	LangChain 中的叫法	框架内定位
Tool	Tool	框架底层的最小执行单元（直接定义函数）
Skill	无明确对应（业务层封装）	开发者基于多个 Tool 封装的业务能力
Agent	Agent	框架核心，调用 Tool（即业务层的 Skill）完成任务

举个 LangChain 中的实际例子：

# 1. 定义 Tool（框架级最小单元）
def get_dish_price_tool(dish_name):  # Tool：查单个菜品价格（原子操作）
    menu = {"红烧肉":48, "番茄炒蛋":18}
    return menu.get(dish_name, 0)

def calculate_sum_tool(prices):  # Tool：累加计算（原子操作）
    return sum(prices)

# 2. 封装 Skill（业务层能力，框架不关心，开发者自己封装）
def calculate_order_skill(dish_list):  # Skill：计算点餐总价（组合Tool）
    prices = [get_dish_price_tool(d) for d in dish_list]
    total = calculate_sum_tool(prices)
    return total

# 3. Agent（框架级，调用 Skill/直接调用 Tool）
class OrderAgent:
    def handle_order(self, dish_list):
        total = calculate_order_skill(dish_list)  # Agent 调用 Skill
        return f"总价：{total}元"

四、关键易错点澄清）🔖

Skill 和 Tool 不是绝对割裂的：

简单场景下，一个 Skill 可以只包含一个 Tool（比如「天气查询 Skill」=「调用天气 API 的 Tool」），此时 Skill 和 Tool 几乎等价；
复杂场景下，一个 Skill 必须组合多个 Tool（比如「旅游规划 Skill」=「查机票 Tool」+「查酒店 Tool」+「查天气 Tool」）。

Agent 不直接操作 Tool（最佳实践）：

虽然技术上 Agent 可以直接调用 Tool，但实际开发中，一定要先封装成 Skill—— 这样 Agent 只需关注「业务任务」，无需关注「底层操作」，代码更易维护、扩展。

不同场景的叫法差异：

通用 AI 领域：常说「Agent + Skill」；
LangChain/AutoGen 等框架：常说「Agent + Tool」；
本质：Skill 是「业务视角的能力」，Tool 是「技术视角的执行单元」。

总结：

层级关系：Tool（最小执行单元）→ Skill（Tool 组合成的业务能力）→ Agent（调用 Skill 的决策者）；
功能分工：Tool 做「具体操作」，Skill 做「能力封装」，Agent 做「决策 + 整合」；
框架适配：LangChain 等框架中「Tool」对应通用概念的「Tool」，「Skill」是开发者基于 Tool 封装的业务层能力，Agent 统一调用这些能力完成任务。

五、不同平台对Skill的理解不同🔖

请看下面的博客，这个博主的对Skill 理解 = Tool

https://blog.csdn.net/chunmiao3032/article/details/157734862

这其实是概念分层和视角不同导致的差异，我们可以把这两种理解放在一起对比一下：

🔹1. 文章里的 Skill 定义（开发者视角）

这篇文章是从业务开发类比的角度来定义的：

Agent ≈ 业务类（比如 OrderService）
Skill ≈ 类里的单个方法（比如 sendEmail()、getNews()）
核心结论：Skill 是 Agent 的「原子方法」，是最小功能单元，有明确入参和出参。

这个视角下，Skill 就是最小执行单元，和我们之前说的「Tool」几乎等价 —— 因为在日常开发里，一个方法就是最小的可执行单元，不能再拆分了。

🔹2. 我们之前的 Skill 定义（系统架构视角）

我们之前是从系统分层的角度来定义的：

Tool：最小执行单元（原子操作，比如调用 API、计算数字）
Skill：由一个或多个 Tool 组合而成的「能力包」，用来完成某一类业务任务（比如「价格计算 Skill」=「查单价 Tool」+「累加 Tool」+「折扣 Tool」）
Agent：调用 Skill 的决策者

这个视角下，Skill 是Tool 的组合封装，是业务层的能力，而不是最小单元。

🔹3. 为什么会有这种差异？

其实这两种理解并不矛盾，只是看问题的层级不同：

文章视角：把「Skill」直接等同于「最小可执行单元」，因为在 Agent 平台（如扣子、AutoGPT）里，Skill 就是你注册的一个个函数 / API，是 Agent 能直接调用的最小单位。
我们的视角：把「Skill」定义为「业务能力」，而「Tool」是更底层的技术实现单元 —— 这是为了在复杂系统中更好地解耦和复用。

简单说：

在平台开发（如扣子、AutoGPT）里：Skill = Tool（最小执行单元）
在复杂系统架构里：Skill = 多个 Tool 的组合（业务能力）

六为什么要这么分层？🔖

🔹为什么在复杂系统里，Skill ≠ Tool？

在大型企业或复杂 AI 系统中，直接让 Agent 调用一堆零散的 Tool（API / 函数）会带来几个问题：

决策负担太重：Agent 需要理解每个底层 Tool 的细节（参数、依赖、异常），容易出错。
复用性差：同样的业务逻辑（比如 “计算订单总价”）要在多个 Agent 里重复实现。
维护成本高：底层 Tool 变了，所有直接调用它的 Agent 都要改。

所以，架构上会引入一个中间层：

Tool：底层原子操作（调用支付接口、查数据库、发邮件）
Skill：业务能力封装（订单结算 Skill、用户画像 Skill、风控校验 Skill）
Agent：只关心业务目标，调用 Skill 完成任务

这样一来，Agent 不用管 “怎么查库存、怎么算折扣”，只需要调用 “订单结算 Skill”，Skill 内部再去组合多个 Tool 完成整个流程。

🔹实际应用场景举例

1. 电商智能客服系统

Tool：
- get_product_stock_tool：查商品库存
- get_discount_rule_tool：查优惠规则
- calculate_price_tool：计算折后价
- create_refund_order_tool：创建退款单
Skill（业务能力）：
- 订单结算Skill：组合 get_product_stock_tool + get_discount_rule_tool + calculate_price_tool
- 退款处理Skill：组合 get_order_detail_tool + check_refund_condition_tool + create_refund_order_tool
Agent：
- 客服 Agent：根据用户问题，调用「订单结算 Skill」或「退款处理 Skill」，不用关心底层 Tool 怎么实现。

2. 企业级 RPA + AI 混合系统

Tool：
- read_excel_tool：读取 Excel 数据
- call_crm_api_tool：调用 CRM 接口
- send_wechat_tool：发送企业微信消息
Skill：
- 月度报表生成Skill：组合 read_excel_tool + call_crm_api_tool + generate_pdf_tool
- 客户跟进Skill：组合 get_customer_info_tool + send_wechat_tool + log_followup_tool
Agent：
- 运营 Agent：每月自动触发「月度报表生成 Skill」，并通过「客户跟进 Skill」提醒销售。

3. 多 Agent 协作系统

Tool：
- weather_api_tool：查天气
- hotel_search_tool：查酒店
- flight_book_tool：订机票
Skill：
- 行程规划Skill：组合 weather_api_tool + hotel_search_tool + flight_book_tool
- 预算核算Skill：组合 get_flight_price_tool + get_hotel_price_tool + calculate_total_tool
Agent：
- 规划 Agent：调用「行程规划 Skill」生成方案
- 财务 Agent：调用「预算核算 Skill」校验成本
- 总控 Agent：协调两个 Agent，完成整个旅行规划。

🔹一句话总结

在平台开发里，Skill 就是你给 Agent 的一个个 “小工具”（Tool），直接用就行。
在复杂系统架构里，Skill 是 “业务能力包”，它把底层的 Tool 封装起来，让 Agent 只需要关心 “做什么”，而不是 “怎么做”。

七实际有哪些应用案例🔖

当然有！这种「Tool（原子操作）→ Skill（业务能力封装）→ Agent（决策调用）」的分层架构，已经在企业级 AI 系统、电商、金融、政务等领域大规模落地。

🔹1. 阿里云百炼（企业级 Agent 平台）

阿里云百炼是典型的复杂 Agent 系统架构，完全区分了「工具（Tool）」和「技能（Skill）」：

Tool 层：平台提供底层原子工具（如「调用钉钉 API」「查阿里云 RDS 数据」「调用 OSS 存储」），开发者也能自定义原子 Tool（比如查订单数据库的函数）；
Skill 层：开发者基于多个 Tool 封装成「业务 Skill」（比如「订单履约 Skill」=「查库存 Tool」+「扣库存 Tool」+「生成物流单 Tool」）；
Agent 层：企业创建的 Agent（如「电商客服 Agent」「订单处理 Agent」）只调用封装好的 Skill，不直接操作底层 Tool。✅ 验证方式：登录阿里云百炼控制台（https://dashscope.aliyun.com/），在「工具中心」能看到原子 Tool，在「技能编排」里可组合 Tool 生成 Skill。

🔹2. 京东智能客服系统（电商场景）

京东的智能客服背后是多层 Agent 架构：

Tool 层：原子操作（查商品库存 API、查用户订单接口、计算优惠券 Tool、物流轨迹查询函数）；
Skill 层：业务能力封装（
- 「售后退款 Skill」=「查订单状态 Tool」+「校验退款条件 Tool」+「调用退款接口 Tool」+「发送短信通知 Tool」；
- 「商品咨询 Skill」=「查商品详情 Tool」+「查库存 Tool」+「查评价 Tool」）；
Agent 层：不同场景的 Agent（售前咨询 Agent、售后处理 Agent）调用对应 Skill，完成用户需求。✅ 验证方式：在京东 APP 联系客服咨询 “订单退款”，客服能一站式处理退款审核、金额计算、进度告知 —— 这就是「售后退款 Skill」的能力，而非单个 Tool 的调用。

🔹3. 招商银行智能投顾系统（金融场景）

招行的智能投顾是复杂 Agent 架构的典型：

Tool 层：原子工具（查用户资产 API、查基金净值接口、风险评级计算 Tool、收益测算函数）；
Skill 层：业务能力封装（
- 「资产配置 Skill」=「用户风险评级 Tool」+「基金筛选 Tool」+「收益测算 Tool」+「生成配置方案 Tool」；
- 「持仓调整 Skill」=「查当前持仓 Tool」+「市场行情 Tool」+「调整建议生成 Tool」）；
Agent 层：投顾 Agent 根据用户的 “资产配置需求”，调用「资产配置 Skill」生成方案，无需关心底层每个 Tool 的调用细节。✅ 验证方式：招行 APP 的「智能投顾」功能，输入 “10 万资金想稳健理财”，会直接给出组合方案 —— 这是 Skill 整合多个 Tool 后的结果，而非单个 Tool 的输出。

🔹技术层面的落地实现（可复现）

下面用 LangChain 实现一个极简的「复杂架构版 Agent」，演示 Skill 如何组合多个 Tool，让你直观看到落地方式：

# ====================== 1. Tool层（原子操作） ======================
from langchain_core.tools import Tool

# 原子Tool1：查菜品库存
def check_dish_stock(dish_name: str) -> str:
    stock_db = {"红烧肉": 50, "番茄炒蛋": 30, "水煮鱼": 0}
    return f"{dish_name}库存：{stock_db.get(dish_name, 0)}份"

# 原子Tool2：查菜品单价
def get_dish_price(dish_name: str) -> str:
    price_db = {"红烧肉": 48, "番茄炒蛋": 18, "水煮鱼": 68}
    return f"{dish_name}单价：{price_db.get(dish_name, 0)}元"

# 原子Tool3：计算总价
def calculate_total(prices: list) -> str:
    return f"总价：{sum(prices)}元"

# 封装LangChain Tool
tool_list = [
    Tool(name="CheckStock", func=check_dish_stock, description="查询菜品库存"),
    Tool(name="GetPrice", func=get_dish_price, description="查询菜品单价"),
    Tool(name="CalculateTotal", func=calculate_total, description="计算总价")
]

# ====================== 2. Skill层（业务能力封装） ======================
class OrderSkill:
    """点餐业务Skill：组合多个Tool完成点餐流程"""
    def __init__(self, tools):
        self.tools = {tool.name: tool for tool in tools}  # 映射Tool名称和实例

    def execute(self, dish_list: list) -> dict:
        """执行点餐Skill：查库存→查价格→算总价"""
        result = {
            "valid_dishes": [],
            "invalid_dishes": [],
            "total_price": 0,
            "stock_info": {}
        }

        # 步骤1：调用CheckStock Tool查库存
        for dish in dish_list:
            stock_info = self.tools["CheckStock"].func(dish)
            stock_num = int(stock_info.split("：")[1].replace("份", ""))
            result["stock_info"][dish] = stock_info
            if stock_num > 0:
                result["valid_dishes"].append(dish)
            else:
                result["invalid_dishes"].append(dish)

        # 步骤2：调用GetPrice Tool查有效菜品价格
        prices = []
        for dish in result["valid_dishes"]:
            price_info = self.tools["GetPrice"].func(dish)
            price = int(price_info.split("：")[1].replace("元", ""))
            prices.append(price)

        # 步骤3：调用CalculateTotal Tool算总价
        if prices:
            result["total_price"] = int(self.tools["CalculateTotal"].func(prices).split("：")[1].replace("元", ""))

        return result

# ====================== 3. Agent层（决策调用Skill） ======================
class RestaurantAgent:
    """餐厅Agent：只调用Skill，不关心底层Tool"""
    def __init__(self, order_skill):
        self.order_skill = order_skill  # 绑定Skill，而非直接绑定Tool

    def handle_order(self, user_dishes: list) -> str:
        """处理用户点餐请求：调用OrderSkill，整合结果返回"""
        # 核心：只调用Skill，不接触底层Tool
        skill_result = self.order_skill.execute(user_dishes)

        # 整合结果（给用户的友好响应）
        if not skill_result["valid_dishes"]:
            return f"点餐失败！{skill_result['invalid_dishes']}均无库存"
        
        return (
            f"点餐成功！\n"
            f"有效菜品：{skill_result['valid_dishes']}\n"
            f"无库存菜品：{skill_result['invalid_dishes']}\n"
            f"总价：{skill_result['total_price']}元"
        )

# ====================== 测试运行 ======================
if __name__ == "__main__":
    # 初始化Skill（组合Tool）
    order_skill = OrderSkill(tool_list)
    # 初始化Agent（绑定Skill）
    agent = RestaurantAgent(order_skill)
    
    # 测试点餐
    print(agent.handle_order(["红烧肉", "番茄炒蛋", "水煮鱼"]))

🔹复杂架构落地的核心价值（为什么企业要这么做）

解耦易维护：比如要修改「价格计算规则」，只需改 CalculateTotal Tool，所有依赖该 Tool 的 Skill（如 OrderSkill）会自动生效，无需修改 Agent 代码；
复用性高：「OrderSkill」可被「点餐 Agent」「收银 Agent」「后厨备餐 Agent」共用，不用重复开发；
容错性强：Skill 层可统一处理异常（比如 Tool 调用失败时的重试、降级），Agent 无需关心；
权限管控：可在 Skill 层控制 Tool 的调用权限（比如「退款 Skill」仅允许售后 Agent 调用），符合企业安全要求。

🔹总结

落地现状：这种分层架构已在阿里云百炼、京东智能客服、招行智能投顾等企业级系统中大规模应用，是复杂 Agent 系统的标准设计；
核心逻辑：Tool 是原子操作，Skill 是业务能力封装，Agent 只调用 Skill 完成任务；
落地价值：解决了复杂系统的复用、维护、权限问题，是从「轻量 Agent 原型」到「企业级 Agent 系统」的关键。

92IT

Just love IT.

Agent ， Skill 和 Tool的关系