AI Agent核心技术栈详解：Skill、Function Call、Tools、LangChain与LangGraph层级差异与实战细节

2201_75816487

229人浏览 · 2026-06-04 21:38:34

2201_75816487 · 2026-06-04 21:38:34 发布

当下AI Agent开发的技术栈名词层出不穷：Skill、Function Call、Tools、LangChain、LangGraph，很多开发者极易混淆三者边界：分不清工具与技能的区别、看不懂函数调用的底层逻辑、搞不懂LangChain与LangGraph的选型差异。

这些技术并非平行替代关系，而是从底层调用能力、原子能力封装，到上层编排框架的层级递进关系。本文将从技术定义、底层原理、核心差异、适用场景、协同逻辑五个维度，彻底厘清这套Agent核心技术栈，同时补充配套关键术语，帮你搭建完整的Agent技术认知体系。

一、先理清层级：整套技术栈的核心从属关系

首先建立全局认知，五者是自底向上的依赖层级，不存在并列替代，而是层层封装、逐级赋能：

Function Call（函数调用）：LLM原生底层能力，是所有外部能力调用的基础协议

Tools（工具）：可被调用的原子能力单元，是Function Call的调用对象

Skill（技能）：多个Tools+业务逻辑的组合封装，是面向业务的高阶能力

LangChain：通用LLM应用开发框架，提供工具封装、调用链路、记忆、提示词等基础能力

LangGraph：基于LangChain的进阶编排框架，专注复杂、有状态、可循环的Agent工作流

简单总结：Function Call是底座，Tools是原子，Skill是业务组合，LangChain是基础脚手架，LangGraph是生产级复杂编排引擎。

技术栈层级架构示意图

为方便直观理解自底向上的依赖关系，以下为极简层级拓扑：

【业务层】 Skill（业务技能组合） ↑ 封装组合【原子能力层】 Tools（独立工具单元） ↑ 调用触发【底层协议层】 Function Call（LLM结构化调用协议） ↑ 框架承载 ``【编排框架层】 LangChain（简易线性编排） → LangGraph（复杂有状态图编排）

二、底层核心：Function Call（函数调用）——LLM的“对外交互接口”

1. 核心定义

Function Call是大模型原生内置的能力协议，并非框架衍生功能。它解决的核心问题是：让原本只能输出文本的LLM，具备结构化输出、主动调用外部程序的能力。

传统LLM生成自由文本，无法精准对接代码、接口、数据库；Function Call通过标准化JSON格式输出调用参数，实现LLM与外部世界的可信交互，是所有Tool、Agent能力的底层基石。

2. 技术细节与执行流程

标准Function Call执行闭环分为四步，也是行业通用底层规范：

工具注册：开发者向LLM传入工具描述（函数名、功能说明、入参结构、参数类型），让模型理解工具能力边界
意图识别：LLM解析用户Prompt，判断当前任务是否需要调用外部工具，而非直接文本回答
结构化输出：模型不输出自然语言，而是输出标准化JSON调用指令（函数名+合规入参），杜绝格式错乱
本地执行+结果回传：本地代码解析指令、执行函数，将工具执行结果回传给LLM，模型二次整理输出最终答案

3. 关键技术特性

无状态单次调用：原生Function Call无记忆、无循环、无状态，单次调用结束即终止
模型原生约束：依赖模型训练时的函数调用对齐能力，不受框架限制，OpenAI、DeepSeek、通义千问等主流模型均原生支持
精准参数校验：强制结构化输出，解决自由文本无法对接程序的核心痛点

4. 极简代码示例：原生 Function Call 调用逻辑

以下为不依赖框架、原生LLM函数调用极简代码，还原底层执行逻辑：

import json

# 1. 定义工具描述（注册工具，让LLM认知工具能力）
tool_desc = {
    "name": "calculator",
    "description": "用于数学四则运算",
    "parameters": {
        "type": "object",
        "properties": {
            "expr": {"type": "string", "description": "数学表达式"}
        },
        "required": ["expr"]
    }
}

# 2. 模拟LLM结构化输出（Function Call 核心：标准化JSON）
llm_function_call = {
    "name": "calculator",
    "parameters": {"expr": "128 * 5 + 60"}
}

# 3. 本地执行工具
def calculator(expr: str) -> float:
    return eval(expr)

# 4. 结果回传LLM二次整理
result = calculator(llm_function_call["parameters"]["expr"])
print("工具执行结果：", result)
# 最终LLM整合结果输出：128*5+60的计算结果为700

三、原子能力：Tools（工具）——可被调用的最小执行单元

1. 核心定义

Tools是可被Function Call调用的最小原子能力，是具体的执行载体，本质是一段可执行代码、接口、脚本或数据库操作。它只负责「单一、纯粹、无逻辑耦合」的功能执行。

常见Tool：计算器、天气查询API、搜索引擎、代码解释器、数据库查询、文件读写、爬虫接口等。

2. 技术规范与开发细节

标准Tool必须满足单一职责、入参明确、幂等执行、返回结构化结果四大规范：

一个Tool只做一件事，不嵌套复杂业务逻辑
参数可被Function Call精准解析，无模糊入参
多次调用结果一致，避免重复执行出错
返回统一格式数据，方便LLM二次处理

4. 标准Tool工具极简代码实现

严格遵循「单一职责、幂等、结构化返回」的Tool开发规范：

# 标准原子Tool：订单查询工具（仅负责查询，无业务逻辑）
def query_order(order_id: str) -> dict:
    """
    工具功能：根据订单号查询订单信息
    幂等性：多次调用结果一致，无数据变更
    """
    # 模拟数据库查询
    mock_order_data = {
        "20260604001": {"status": "已发货", "amount": 299, "goods": "AI教程"},
        "20260604002": {"status": "待付款", "amount": 199, "goods": "技术周边"}
    }
    return mock_order_data.get(order_id, {"msg": "订单不存在"})

# Tool输出为结构化数据，可直接被LLM解析
print(query_order("20260604001"))

3. Tool与Function Call的核心区别

很多人混淆二者：Function Call是“调用动作与协议”，Tool是“被调用的实体”。没有Function Call，Tool无法被LLM主动触发；没有Tool，Function Call只是空有协议、无实际执行能力。

四、业务高阶：Skill（技能）——工具的业务化组合封装

1. 核心定义

Skill是面向业务场景的高阶能力，是多个Tool、多轮Function Call、固定业务规则、判断逻辑的封装集合。如果说Tool是“零件”，Skill就是“组装好的功能模块”。

原生LLM+Tools只能完成单点简单任务，而真正落地的Agent需要连贯业务能力，Skill就是为了解决「工具碎片化、业务无闭环」的问题。

2. 技术实现细节

一个完整的Skill包含三层结构：

工具层：多个原子Tools（如查询库存、计算价格、生成订单三个Tool）
规则层：业务判断逻辑、调用顺序、参数校验、异常重试机制
交互层：用户意图匹配、结果整理、话术封装

3. 举例直观区分

Tool：订单查询接口（仅输入订单号、返回订单信息）
Skill：订单售后咨询技能（自动查询订单→校验订单状态→匹配售后规则→生成售后方案→回复用户）

核心差异：Tool是原子技术能力，Skill是闭环业务能力。

4. Skill 业务技能封装代码示例

基于上方原子Tool，封装带业务规则、流程逻辑的高阶Skill：

# 导入原子工具
# from tool_demo import query_order

# 封装业务Skill：订单售后咨询闭环技能
def order_after_sale_skill(order_id: str) -> str:
    # 1. 调用原子工具查询订单
    order_info = query_order(order_id)
    if "msg" in order_info:
        return "您好，您查询的订单不存在，请核对订单号！"
    
    # 2. 植入业务规则（Skill核心：业务逻辑封装）
    status = order_info["status"]
    if status == "已发货":
        return f"订单状态：已发货，商品{order_info['goods']}，可申请退换货，售后通道已开启"
    elif status == "待付款":
        return f"订单状态：待付款，未发货无需售后，可直接付款或取消订单"
    else:
        return "订单状态异常，請联系人工客服"

# 直接调用即可输出完整业务结果
print(order_after_sale_skill("20260604001"))

核心差异：Tool是原子技术能力，Skill是闭环业务能力。

五、基础框架：LangChain——快速搭建LLM应用的通用脚手架

1. 核心定位

LangChain是开源通用LLM应用开发框架，定位是「降低LLM应用开发门槛」。它不创造Function Call和Tool能力，而是对原生能力进行标准化封装，提供全套开发组件。

核心价值：统一模型调用、工具注册、记忆管理、提示词模板、链路编排标准，让开发者无需重复造轮子，快速搭建对话、RAG、简单Agent应用。

2. 核心技术组件

Chains（链路）：串行组合多个能力，实现简单任务流水线（如检索-问答链路）
Tools封装层：统一各类工具的注册、调用、参数解析接口
Memory（记忆）：对话缓存、长期记忆、会话状态管理
Prompts：标准化提示词模板、动态占位符渲染
Agents（基础智能体）：基于循环的简单工具调用Agent，适合单流程、无复杂分支场景

4. LangChain 简单Tool调用Agent代码示例

基于LangChain快速搭建线性、轻量工具调用Agent，适配简单场景：

from langchain_openai import ChatOpenAI
from langchain.tools import tool
from langchain.agents import AgentExecutor, create_tool_calling_agent
from langchain_core.prompts import ChatPromptTemplate

# 1. 定义LangChain工具
@tool
def calculator(expr: str) -> str:
    """用于数学四则运算，传入数学表达式"""
    return str(eval(expr))

# 2. 初始化模型、提示词、Agent
llm = ChatOpenAI(model="gpt-3.5-turbo")
tools = [calculator]
prompt = ChatPromptTemplate.from_messages([
    ("system", "你是专业的计算助手，优先使用工具计算"),
    ("user", "{input}"),
    ("placeholder", "{agent_scratchpad}")
])

# 3. 创建并执行Agent（线性隐式循环，无状态持久化）
agent = create_tool_calling_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

# 执行任务
res = agent_executor.invoke({"input": "计算 365 * 24 + 96"})
print(res["output"])

3. 核心短板（关键痛点）

LangChain的基础Agent和Chain是线性、隐式循环，存在明显落地瓶颈：无全局可视化状态、不支持复杂分支/并行/嵌套逻辑、状态不可持久化、无法人工介入、异常不可回溯。仅适合简单原型、轻量场景，无法支撑生产级复杂Agent。

六、进阶编排：LangGraph——生产级Agent状态机引擎

1. 核心定位

LangGraph是LangChain生态下的底层复杂编排框架，专门解决LangChain无法搞定的有状态、多分支、可循环、可中断的生产级Agent场景。它不是LangChain的替代者，而是LangChain的能力补全与进阶升级。

核心设计哲学：将Agent执行流程建模为有状态有向图（Stateful Directed Graph），把隐式的AI循环，变成显式可控的工程状态机。

2. 核心技术细节（区别于LangChain的关键）

全局State状态中心：统一存储对话历史、工具结果、任务进度、自定义业务参数，全节点共享、可读写、可持久化，彻底解决无状态痛点
显式Graph拓扑：通过Node（执行单元）、Edge（路由路径）、条件分支，自由编排串行、并行、循环、嵌套、回溯逻辑
可中断与可恢复：支持任务暂停、人工审核（Human-in-the-loop）、异常重试、断点续跑，适配企业级风控流程
多Agent原生协同：原生支持Supervisor主管节点、多子Agent分工协作、Map-Reduce批量任务处理
可视化与可观测：流程全链路可追溯、可调试，解决传统Agent黑盒问题

4. LangGraph 有状态复杂编排代码示例

实现全局状态、分支判断、可循环的生产级Agent，对比LangChain线性能力：

from langgraph.graph import StateGraph, START, END
from typing import TypedDict, Literal

# 1. 定义全局状态中心（核心：有状态持久化）
class AgentState(TypedDict):
    user_input: str
    process_result: str

# 2. 定义节点执行逻辑
def check_node(state: AgentState) -> AgentState:
    """校验节点：判断输入是否为计算需求"""
    if "计算" in state["user_input"]:
        state["process_result"] = "need_calc"
    else:
        state["process_result"] = "no_handle"
    return state

def calc_node(state: AgentState) -> AgentState:
    """计算执行节点"""
    state["process_result"] = "已完成计算处理"
    return state

# 3. 构建图拓扑（显式分支、可控流转）
builder = StateGraph(AgentState)
builder.add_node("check_node", check_node)
builder.add_node("calc_node", calc_node)

# 4. 配置路由分支（LangChain不具备的显式条件跳转）
builder.add_edge(START, "check_node")
builder.add_conditional_edges(
    "check_node",
    lambda s: "calc_node" if s["process_result"] == "need_calc" else END
)
builder.add_edge("calc_node", END)

# 5. 编译执行（可中断、可恢复、可追溯）
graph = builder.compile()
result = graph.invoke({"user_input": "帮我计算 99 * 99"})
print(result)

3. 核心适用场景

复杂多轮任务、多智能体协作、需要人工介入、长流程业务、异常容错场景（智能客服、数据分析Agent、自动化办公、工业运维、多步骤决策系统）。

5. LangChain vs LangGraph 执行流程对比图

LangChain 执行逻辑（线性隐式）

用户输入 → LLM判断 → 工具调用 → 结果返回 → 流程结束 ``（无分支、无状态留存、无法人工介入）

LangGraph 执行逻辑（图状显式）

全局State初始化 → 节点执行 → 条件分支路由 → 循环/暂停/人工审核 → 状态更新 → 结束 ``（可回溯、可断点续跑、多节点协同）

七、核心技术栈横向对比（关键差异总结）

技术名词	核心定位	状态能力	核心特点	适用场景
Function Call	底层调用协议	无状态	LLM原生结构化调用能力，所有工具调用的基础	所有外部能力交互场景
Tools	原子执行单元	无状态	单一职责、可被调用的最小功能模块	单点查询、计算、接口调用
Skill	高阶业务能力	弱状态	多工具组合+业务规则，闭环场景能力	垂直业务闭环场景
LangChain	通用开发脚手架	短时会话状态	快速开发、组件丰富、上手简单，线性流程	原型开发、简单RAG、单轮Agent
LangGraph	生产级编排引擎	全局持久状态	图结构编排、分支循环、可中断、多智能体	复杂长流程、企业级Agent