大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



对于大模型而言，其如何理解并使用工具，通常主要依赖以下三个方面：

• 大模型自身在预训练阶段所获得的通用知识与能力
• 工具本身的描述信息，例如工具的功能、参数及调用方式
• 开发者编写的系统提示词与用户提示词，用于引导模型的整体行为

在一些通用任务场景下，上述三点往往已经能够满足需求。然而，当智能体需要完成专业性较强、流程较复杂或规则较多的任务时，仅依赖大模型自身的能力显然是不够的；而工具描述本身通常只关注“如何使用该工具”，对“如何完整、正确地完成一类任务”提供的指导也十分有限。

因此，在实际应用中，我们往往会将对整体任务目标、执行原则以及流程约束的说明写入系统提示词中，以此来引导智能体的行为。

但随着任务复杂度的不断提升，这种做法会逐渐暴露出明显的问题。那就是系统提示词会变得越来越长、越来越复杂，不仅增加了上下文开销，也会使模型在推理过程中难以抓住重点，反而更容易出现理解偏差和幻觉，从而错误地执行任务。

为了解决这一问题，我们可以换一种思路——不再将所有任务规则一次性写入系统提示词，而是将复杂任务进行拆分。

具体来说，我们可以先将一个复杂任务拆分为若干相对独立、职责清晰的子任务，并分别为这些子任务设计对应的执行流程、规则说明和注意事项。随后，我们将这些“针对某一类任务的完整执行说明”封装为一个个技能（Skill）。

在系统提示词中，我们只需要简要地列出当前智能体可用的技能及其功能概述。当智能体接收到用户请求后，只有在判断该请求与某个 Skill 相关时，才会按需加载该 Skill 的详细内容；若暂时无关，则保持其不被使用，从而避免不必要的上下文占用。通过这种方式，我们可以在显著降低上下文复杂度与长度的同时，依然为智能体提供足够专业、结构化的任务指导，从而提升系统的稳定性与执行准确性。

从本质上来看，这种将信息按需加载、逐步暴露的设计思路，正是当前大模型应用中所强调的上下文工程（Context Engineering）的重要组成部分。其核心目标并不是“提供尽可能多的信息”，而是在合适的时间，向模型提供恰当且必要的信息。这一思想最早由 Anthropic 在 Claude Code 中系统性地提出，并以 Skill 的形式加以实践。将复杂的任务知识与执行规范封装为可独立加载的技能模块，由模型在推理过程中自主选择和使用。

从我个人的理解来看，Skills 其实更像是让智能体变得专业化的重要路径，以往在没有 skills 的情况下，一个智能体使用工具，通常是这样被引导的：

• system prompt 里写：

• 什么时候该用工具
• 先用哪个工具
• 用完工具后要注意什么

• tool 描述里写：

• 参数
• 返回值
• 用法示例

结果是工具“怎么用”是清楚的，但在什么业务语境下、按什么流程去用”是模糊的。而 skills 正好补的是这一层。其主要关注的是在完成某一类任务时，工具应该如何被组合、约束和使用。

skills 通常包含的内容你已经见过了：

• 任务目标（比如“写一条符合业务规则的 SQL”）
• 业务约束（哪些状态有效，哪些要排除）
• 使用工具的原则（什么时候该查 schema，什么时候不该）
• 示例（“正确的工具使用范式”）

所以我们就可以把 Skill 当作是对工具的“调度说明书”，用一个更高的维度指导智能体完成特定的任务。

那下面我们就来基于 LangChain 来尝试复现一下 Skills 的使用吧！

我们需要安装配套的库来进行任务的完成：

GPT plus 代充 只需 145

然后我们还需要获取百炼大模型的 api_key 来进行 qwen 大模型的调用：

然后我们需要测试一下是否能够调用大模型：

GPT plus 代充 只需 145

准备好以上内容后我们就可以正式开始进行代码的实战了！

在下面的任务中，我希望做的是一个 SQL 助手智能体，用来帮助在大型企业中编写跨不同业务垂直领域的 SQL 查询。在这样的企业环境里，可能存在以下两种情况之一：

• 每个业务垂直领域（vertical）都有各自独立的数据存储系统；
• 或者整个企业使用的是一个单体数据库，其中包含成千上万张表。

但它和“直接把所有数据库 schema 塞进系统提示词”不一样，Skills 用的是 Progressive Disclosure（渐进披露/按需加载上下文） 的思路：

• 智能体一开始只知道“有哪些技能（skills）”，每个技能只有一句话描述（很轻量）。
• 当用户的问题涉及某个业务域（比如销售分析、库存管理），智能体会通过 工具调用（tool call） 去加载对应技能的完整内容（包括 schema、业务规则、示例 SQL）。
• 加载后再写 SQL，这样就避免了：一开始把成千上万张表、规则都塞进上下文导致爆窗、幻觉、成本高。

因此我们需要制作以下四个核心组件：

1. 根据任务内容创建 Skill
2. 制造 load_skill 工具：输入 skill_name，返回对应 skill 的 （拼上“Loaded skill: …”）。
3. SkillMiddleware（关键点）：它做一件事：在每次模型调用前，把“技能目录”追加到 system prompt，让模型知道“我现在有哪些技能可用”。
4. Agent：用 把模型 + system_prompt + middleware + checkpointer 组起来。

首先我们需要先定义 Skill 的格式，这里我们将 Skill 拆分成 name，description 和 content 三部分内容。这里的 name 和 description 就是名称和一句话的描述，这两部分就会放到系统提示词里让智能体像选择工具一样进行选用。而 content 就是当智能体决定调用工具来获取到具体内容信息，这部分信息就会在调用后以工具结果的形式展示在上下文中：

在设置好了格式后，我们就可以来定义 Skills 了：

GPT plus 代充 只需 145

这里总共有两个 skill，一个是 sales_analytics，用于销售数据分析的数据库结构与业务逻辑，包括客户、订单和收入相关内容。另一个是 inventory_management，用于库存管理的数据库结构与业务逻辑，包括商品、仓库和库存数量。

这两个里面都是介绍对应数据库表的结构信息（Tables），然后介绍完表信息后也会介绍一下具体的业务规则（Business Logic）是如何的，最后还会给出一些查询的示例信息（Example Query）来让其能够对该任务有更深入的理解。

在之前我们在讲 SQL Agent 的时候都是给出一些 SQL 工具让工具自己来查这些个数据库里的表结构，而现在我们直接在 Skills 里给出的话明显效率会高很多。当然两者还是要结合着来使用的，因为最后执行的话还是要靠 SQLDatabaseToolkit 来实现查询的。

在创建完 skill 以后，我们还需要设置一个工具让智能体能够在合适的时候获取合适的 skill 以及内部对应的 content 内容：

所以这里传入的就是可能的 skill 名称，然后先看看里面有没有，有的话就将对应的 content 内容进行返回。假如没有找到的话，那就把有的 skills 名称都提取出来，然后返回说没有找到制定的技能，然后我们有的技能是什么。

设置完工具以后，我们还需要设置对应的中间件来动态更新系统提示词的内容：

GPT plus 代充 只需 145

• 这里我们首先将 load_skill 作为全局变量载入到该中间件中，因此每次当模型发出指令时，其都能够看见这一个工具的存在。假如我们放到 agent 的 tools 参数里面，反而有可能被其他一些中间件给影响，所以这里就选择放在了中间件的类里面，保证其能够正常运行。
• 接下来我们设置了一些初始化的信息，比如通过解包的方式将 skills 的名称和描述提取出来放到 skills_list 里，并且将 skills_list 的内容组合起来形成 skills_prompt 信息。
• 然后将 skills_prompt 信息与一些提示词进行组合，形成 skills_addendum 说明信息。最后将这部分信息添加到系统提示词的最后，并且通过 .override 的方式进行更新。更新完后再用 handler 对最新的 modified_request 进行调用。

所以总的来说，这个中间件本质上就是在把 Skills 里的 name 和 description 提取出来并且放入到系统提示词中，从而让智能体知道有哪些 Skills 以及如何进行使用它们。

当我们将Skills、工具、中间件都打造好以后，我们就可以来将其组合在一起了，这里我们就还需要写入短期记忆内容 InMemorySaver() 和一段简短的系统提示词即可：

此时我们就可以对该智能体进行调用了，首先我们还是要先创建一个线程 ID：

GPT plus 代充 只需 145

然后我们就可以发出一个查询的请求，了解一下一个月内超过 1000 美元订单的客户有哪些：

最后遍历本次调用中产生的所有消息，包括：

• 用户消息（Human Message）
• 模型消息（AI Message）
• 工具调用消息（Tool Message）

如果消息对象支持 ：

• 使用 LangChain 提供的格式化输出（更清晰）

否则：

• 以「消息类型 + 内容」的方式直接打印

GPT plus 代充 只需 145

可以看到当我们提问了问题以后，模型第一时间发出了 skills 调用的请求，然后将对应的 content 进行了返回。模型在阅读完 skills 内容后就给出了 SQL 调用的代码。可以看出这种方式其实是非常高效且有用的！

在前面的版本里，其实存在一个隐患：

❗ 模型理论上可以：

• 还没加载
• 就开始写 sales 的 SQL
• 或者乱用 schema

也就是说：

• 我们只是“引导”模型
• 但没有强制约束

而这一节做的事是：

把“先加载 skill → 再使用相关工具” 从一种提示习惯，升级为系统级规则

本质上来说，我们这里要做的就是把“已加载了哪些 skills”记录到 agent 的 state 里，然后让后续工具基于 state 决定“能不能用”。首先我们先定义一个 AgentState 的字段 skills_loaded，用列表的形式将已经载入的 Skills 进行记录：

GPT plus 代充 只需 145

这个 AgentState 在前面自定义中间件时已经进行了讲解，本质上就是在智能体流动过程中不断改变的状态信息。我们可以在中间件、工具等地方进行获取并对其进行修改。

有了这个 state 信息后，那我们还需要更新一下 load_skill 工具，使其能够在获取完 skills 里的内容后顺便把 skill_loaded 信息通过 Command 进行更新：

假如能够找到对应的 skill 的话，那就通过 update 的方法将 skills_load 的信息进行更新。假如没找到的话也还是通过 Command 将未找到的信息进行传回。

那拥有了 state 以后，我们也可以更进一步去实现只有在“对应 skill 已加载”的前提下，才能查询对应业务领域的内容。这里我们定义了一个 write_sql_query 的工具来进行实现：

GPT plus 代充 只需 145

这里首先我们就是从 runtime.state 中获取 skills_loaded 信息，假如找不到就是空列表。找到以后呢就检查一下业务领域 vertical 是否存在于 skills_loaded 中。假如不存在的话就返回错误信息。假如存在就通过校验。

接下来有了这个 state 和新的 write_sql_query 工具后，我们还需要将其加载到中间件 SkillMiddleware 中（其他地方都没变）：

然后我们就能够再次构建 agent 并进行调用：

GPT plus 代充 只需 145

此时返回的结果为就不再是前面简单的查询了，而是加上了一步检验的过程，从而确保是已经加载 Skills 后才能进行搜索结果的产出：

此查询将返回满足条件的客户 ID 和姓名。如果需要进一步分析这些客户，可以在此基础上扩展查询。

本教程中，将 skills（技能） 实现为内存中的 Python 字典，并通过工具调用的方式按需加载。不过，实际上还有多种方式可以实现基于 skills 的渐进式披露（progressive disclosure）机制。

• 内存方式（本教程采用）

• 将 skills 定义为 Python 数据结构
• 访问速度快
• 没有 I/O 开销
• 但更新技能内容需要重新部署代码

• 文件系统方式（Claude Code 的做法）

• 将 skills 组织为目录和文件
• 通过文件操作（如 ）进行发现和加载
• 适合技能内容频繁变更的场景

• 远程存储方式

• 将 skills 存储在 S3、数据库、Notion 或 API 中
• 在需要时按需拉取
• 适合大规模、多团队协作的企业级系统

• 系统提示词列举（本教程采用）

• 在 system prompt 中列出所有技能的简要描述
• 实现简单、直观

• 基于文件的发现

• 通过扫描目录结构来发现可用技能
• Claude Code 采用的方式

• 注册中心方式（Registry-based）

• 通过技能注册服务或 API 查询可用技能列表
• 适合分布式系统

• 动态查询方式

• 通过工具调用，动态返回当前可用的技能列表

• 一次性加载（Single load）

• 通过一次工具调用加载整个 skill 内容
• 本教程采用的方式
• 实现简单，适合中小规模技能

• 分页加载（Paginated）

• 将技能内容拆分成多个页面或片段
• 适合内容较大的技能

• 基于搜索的加载（Search-based）

• 在技能内容中按需搜索相关部分
• 例如对技能文件使用 / 操作
• 避免加载无关内容

• 分层加载（Hierarchical）

• 先加载技能概览
• 再逐步深入加载具体子模块或子章节

• 小型技能

• 少于 1K tokens（约 750 字）
• 可直接放入 system prompt
• 可结合 prompt caching 提升响应速度、降低成本

• 中型技能

• 1K–10K tokens（约 750–7500 字）
• 适合按需加载（本教程的典型场景）
• 能显著减少上下文占用

• 大型技能

• 超过 10K tokens
• 或占用上下文窗口的 5%–10% 以上
• 必须采用分页、搜索或分层加载等渐进式披露策略
• 否则会严重挤占上下文空间

• 内存方式：

• 速度最快
• 实现最简单
• 但技能更新需要重新部署

• 文件或远程存储方式：

• 技能可动态更新
• 无需改代码
• 但会带来 I/O 或网络延迟

最终选择取决于你对性能、灵活性、维护成本的需求。

总的来说，本文围绕复杂专业任务中大模型上下文失控的问题，引入并系统讲解了 Skills + Progressive Disclosure（渐进式披露） 的设计思想。核心在于不再将所有业务规则、流程约束和知识一次性写入 system prompt，而是将其拆分为职责清晰、可独立加载的技能模块。智能体在初始阶段仅感知“有哪些技能可用”，只有在任务真正涉及某一业务领域时，才通过工具调用按需加载对应 Skill 的完整内容，从而在显著降低上下文长度与复杂度的同时，依然保持对专业任务的充分理解与执行能力。这本质上体现了上下文工程“在合适的时间提供恰当信息”的核心原则。

在具体实现上，文章基于 LangChain 复现了 Skills 的完整工程形态：通过定义 Skill 结构、构建 工具、利用 Middleware 将技能目录动态注入 system prompt，并结合 记录已加载技能，从而实现对智能体行为的系统级约束。相比单纯依赖提示词引导的方式，这种设计将“先加载知识、再执行任务”的隐性约定，升级为可被程序强制执行的规则，使智能体的行为更加稳定、可控且可调试，也为后续引入校验、审计和复杂流程控制奠定了基础。

从更高层次看，Skills 并不仅是 SQL 场景下的技巧，而是一种可泛化的上下文工程范式，适用于多业务域、多团队协作和大规模知识体系下的智能体系统。无论是采用内存、文件系统还是远程存储来管理技能内容，或进一步结合 few-shot 示例加载、搜索式披露、多智能体协作等模式，Skills 都可以作为“任务级知识与执行规范的封装单元”，帮助大模型应用从“能回答问题”走向“可工程化、可扩展、可长期维护的智能系统”。

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【】