最近在技术社区里LangChain 的 Agent Skills 架构被讨论得很多。不少朋友问我它到底是一个新包装的概念还是值得认真跟进的架构方向我的判断是Agent Skills 真正解决的问题不是“让 Agent 能做更多事”而是把 Agent 的能力从“一次性实现”变成“可复用资产”。这个转变直接影响你写 Agent 的方式、调试的方式以及后续扩展的方式。先说一个比较常见的场景。很多人第一次用 LangChain 写 Agent 时流程是先找一个大模型 API再定义一个工具函数然后写一个 Prompt 告诉模型“你可以调用这些工具”。跑通之后再往里面加第二个工具、第三个工具。这个阶段体验还行因为工具数量少规则简单模型还能应付。但一旦工具数量变多任务链路变长问题就出来了。模型不知道该在什么时候调用哪个工具工具的输入输出格式不统一多步操作经常断在中间一步。更麻烦的是这些工具和当时的业务逻辑强耦合在一起换个项目想复用基本等于重写。这就是 Agent 开发从“原型”走向“工程化”时最容易卡住的地方。Agent Skills 架构本质上就是在解决这个问题。它不是多了一个工具函数而是把“做一个任务的能力”封装成一个独立单元这个单元自带描述、输入输出定义、执行逻辑、错误处理和可组合性。如果你把 12 个真实案例拆开看会发现它们并不是 12 种孤立的用法而是在反复印证同一个变化Agent 从“能聊天、能调工具”走向“能按技能模块组织复杂工作流”。下面我会用四个部分把这件事拆透它到底改了什么、案例怎么分类理解、落地时怎么设计和排查、以及它的适用边界在哪里。1. 先搞清楚Agent Skills 到底在解决什么问题很多讨论一上来就列功能、贴代码却没有回答一个最基础的问题为什么需要 Agent Skills这个问题的答案藏在 Agent 开发方式的演进过程里。1.1 从 Prompt 工程到 Agent再到 Skill 的演进逻辑最早做 LLM 应用核心工作是写 Prompt。你告诉模型要做什么、不要做什么、输出什么格式。这个方法对单轮、短任务很有效但一旦任务需要多步推理、查资料、操作外部系统Prompt 就撑不住了。模型没有记忆没有状态不能可靠地完成一系列动作。于是有了 Agent。Agent 的核心是把模型放在一个循环里模型决定调用什么工具工具返回结果模型继续推理直到任务完成。这个思路解决了“多步操作”的问题。LangChain 早期提供的 AgentExecutor就是基于这种 Loop 机制。但 Agent 方式也有新的问题。当你使用 5 个、10 个甚至更多工具时模型在每一步都要重新理解“我有什么工具、该选哪一个、参数怎么传”。这个认知负担会越来越重模型的选择准确率下降调试也变得困难。于是社区里出现了两种应对思路一种是 LangGraph 式的状态图方案把流程显式地画出来用节点和边控制 Agent 的走向另一种就是 Agent Skills把“工具 流程 知识 约束”打包成一个更高级别的能力单元。不要把这两者对立起来。LangChain 负责提供组件LangGraph 负责提供流程编排Agent Skills 负责提供可复用的能力模块。一个常见的误解是Agent Skills 会取代 LangGraph。实际上两类方案解决的是不同层级的问题Skills 描述的是“能做什么”Graph 描述的是“按什么顺序做”。1.2 Skills 与传统 Tool、Function Calling 的核心区别要理解 Agent Skills最好的方式是拿它和传统 Tool 做一个对比。传统 Tool 是一个函数功能很具体。比如“查询天气”“计算两个日期之差”“调用某个 HTTP 接口”。Tool 的描述通常只有一两句话模型通过描述决定是否调用。它适合完成原子性操作但很难承载一个完整任务。Agent Skill 则是一个完整的能力包。它通常包含几个要素能力名称和适用场景描述。输入参数定义包括类型、必填项、约束。执行流程可能包含多个步骤。处理过程中需要的提示词模板。错误处理逻辑比如重试次数、超时策略、降级方案。输出格式说明包括成功结果和失败结果。这个差异决定了使用方式完全不同。以传统工具方式写一个“研究某个行业动态”的 Agent你可能需要注册三四个工具搜索新闻、打开链接、提取摘要、生成报告。模型需要自己决定调用顺序。但以 Skill 方式写你可以把整个流程封装成一个IndustryResearchSkill模型只需要说“我想研究一下储能行业”这个 Skill 内部自己去完成搜索、阅读、梳理、报告生成的链路。这带来的直接好处是模型面对的选择变少了决策压力变小了技能内部的重试、容错逻辑可以统一处理不同 Agent 之间可以共享同一个 Skill而不必复制代码。1.3 为什么说这是一次架构层面的调整Agent Skills 之所以引起关注是因为它改变了 LLM 应用的开发组织方式。过去的开发组织方式是以模型为中心。你写 Prompt你定义工具列表模型在每一轮根据系统提示词决定下一步。这种方式适合小规模应用但当你面前有几十个工具、多个业务模块、多条流程时系统提示词会越来越长模型会越来越“倾向于”忽略一些工具或者在不合适的时机调用它们。Skills 的架构逻辑把模型从“每步都要精确判断”的压力中解放了出来。模型不再需要理解所有底层工具的细节它只需要在更高层级做决策这个任务应该调用哪个 Skill每个 Skill 自己负责内部的工具调度。这就像管理团队。以前你是一个项目经理需要精确指挥每一位员工的每一步动作现在你把任务分给几个小组长由小组长负责内部执行你只需要关注小组长的产出是否达标。从社区讨论和实际项目经验来看这种架构在大型 Agent 应用中的价值会越来越明显。但也要看到它的代价技能封装会带来额外的抽象层调试时你需要同时理解外层调用逻辑和内层实现逻辑。如果一个 Skill 的输出不符合预期你可能要查两层代码。这是使用 Skills 时必须接受的复杂度。2. 12 个典型案例拆解不要只记用法要看类别我看过不少案例总结很多文章把 12 个案例平铺开逐个介绍“这个技能能干什么”。这种记法很零散换个场景你还是不知道怎么设计。更有效的做法是先把案例按能力类型分类然后理解每一类在设计时有什么共性。我倾向于把常见 Agent Skills 案例分成四类工具型、知识型、流程型、协作型。2.1 工具型 Skills封装对具体工具的操作能力工具型 Skills 是最基础的一类。它对应“操作某个具体工具或系统”的能力内部一般会调用外部 API、命令行工具或第三方库。常见案例包括代码执行 Skill接收一段 Python 或 JavaScript 代码在沙箱中执行捕获输出和错误信息。文件操作 Skill读写本地文件、遍历目录、重命名、格式转换。表格处理 Skill读取 Excel 或 CSV清洗数据统计聚合生成图表。爬虫 Skill抓取指定网页内容提取正文处理编码问题。这类 Skill 的设计重点不是“能调 API”而是“把复杂操作的细节藏在内部”。以表格处理为例如果你直接给 Agent 暴露一个run_python_code工具它确实可以操作表格但你需要每一步都精确写清楚代码逻辑一旦代码出错Agent 还得去读错误信息并修改代码很容易陷入循环。但如果你封装一个ExcelAnalysisSkill输入是“文件路径 分析需求”输出是“清洗后的数据表 统计摘要”模型就不需要写代码也不需要在底层逻辑里来回试错。这里有一个很关键的设计原则Skill 的抽象级别要高于工具。Skill 不应该只是给工具换了个名字而应该真正封装一个完整任务。如果某个 Skill 内部只有一次 API 调用那它本质上还是一个 Tool没必要升级成 Skill。2.2 知识型 Skills让 Agent 会查、会读、会整理知识型 Skills 解决的是“获取和处理信息”的问题。它和直接给模型接一个 RAG 流程不同强调的是把知识获取过程做成一个稳定的能力模块。常见案例包括向量检索 Skill连接向量数据库根据语义相似度返回相关文档片段。知识库问答 Skill基于公司内部文档生成有引用来源的回答。网页检索 Skill调用搜索接口整理出结构化搜索结果。论文阅读 Skill解析 PDF 章节结构提取摘要和关键结论。知识型 Skill 很容易和 RAG 混淆。RAG 更多是指一种技术方案包含“索引、检索、生成”三个环节。Skill 则是把 RAG 的完整链路封装成一个可调用的单元。如果你的项目里有多个 Agent每个 Agent 都需要做“基于知识库回答”那么把 RAG 流程封装成 Skill 就是明显的收益点你只需要维护一份检索、重排、引用格式相关的逻辑所有 Agent 共用。知识型 Skill 的设计难点在于输入设计。很多人在写这类 Skill 时只定义了“问题”一个输入参数。这会导致一个问题当用户问法模糊时检索结果质量不稳定。更合理的做法是让 Skill 同时接收“问题”“检索范围”“期望的返回格式”等多个参数。比如可以传doc_filter{category: 产品手册, date_range: [2024-01-01, 2024-12-31]}让检索范围更可控。这需要你在封装时多花一些心思定义参数但换来的是更高的检索稳定性。2.3 流程型 Skills把多步操作固化下来这是 Agent Skills 相比传统 Tool 优势最明显的一类。它把多个步骤、多种工具调用、条件分支全部封装进一个 Skill。常见案例包括数据处理流水线 Skill接收原始数据执行清洗、转换、校验、入库。报告生成 Skill先收集素材再分析数据然后生成图表最后按模板输出 Markdown 报告。模型评估 Skill加载测试集批量运行推理对比基线结果输出评估报告。运维排查 Skill检查服务状态、拉取日志、分析错误码、给出修复建议。流程型 Skills 的价值在于它解决了 Agent 的一个核心痛点多步任务容易中断。如果每一步都由模型自己决定模型很可能在某一步走偏。但把流程固化到 Skill 内部后模型只负责接收任务、调用 Skill、拿到结果。中间步骤的执行和分支判断由代码控制确定性大幅提升。在设计流程型 Skill 时我建议做一件事把 Skill 内部的关键步骤用日志打点。这样当 Skill 执行失败时你能快速定位是第一步读取输入、第二步清洗数据、还是最后一步写入输出出了问题。很多初学者忽略日志结果遇到失败时只能整个 Skill 重跑排查效率很低。2.4 协作型 Skills多 Agent 场景下的能力分配协作型 Skills 面向的是多 Agent 场景。这类 Skill 本身可能是完成较为复杂的任务或者在执行过程中会调用其他 Agent 的能力。常见案例包括任务分发 Skill接收一个大型任务拆解成子任务分发给不同 Agent汇总结果。复核 Skill完成内容生成后调用另一个 Agent 或模型实例进行复查检查事实错误、格式问题。数据校验 Skill对比多个 Agent 的输出结果识别不一致之处。人机交接 Skill在需要用户确认的节点暂停等待用户批准后再继续后续操作。有人会问这和多 Agent 系统有什么区别区别在于 Skill 把“协作协议”封装了。如果你用 LangGraph 做多 Agent 编排通常需要显式定义状态转移和消息传递逻辑。而 Skills 的方式是把协作逻辑封装成一个技能Agent 只需要触发这个技能后续的协调交给 Skill 内部处理。它更适合“协作流程比较稳定、但参与 Agent 可能变化”的场景。协作型 Skill 的适用场景确实存在比如一个咨询报告生成任务可能先由一个 Agent 负责行业信息收集再由另一个 Agent 负责数据可视化。把这条流程封装成 Skill 之后调用方不需要知道内部是哪个 Agent 在处理只需要看到最终成果。这样既实现了任务解耦也让整个系统更容易演化。3. 真正决定成败的不是技能数量而是设计方式围绕 Agent Skills 的讨论里有一个容易让人焦虑的说法谁的技能库大谁就更强。从实际项目看技能数量多不等于系统好用。真正决定体验的是每个 Skill 的设计质量。3.1 每个 Skill 都要有清晰的“能力边界”这是我在评估 Agent Skills 时放在第一位的要求。一个 Skill 必须清楚说明自己能做什么、不能做什么、什么情况下应该拒绝任务。从技术实现上你可以通过系统提示词、输入校验、前置条件检查来增强能力边界。但更重要的还是设计时的认知这个技能是窄而深还是宽而浅一个常见的反面例子是“万能分析 Skill”。设计者把数据清洗、统计分析、可视化、报表生成全塞进一个 Skill结果模型以为它什么都能干但每次调用都只能覆盖其中一部分功能参数组合复杂到连调用者都记不住。这种 Skill 很难获得稳定的输出。更好的拆分方式是让每个 Skill 只做一类事情但把这一件事做到位。比如把“数据清洗”和“报表生成”拆开前者聚焦数据质量后者聚焦可视化展示。调用方可以根据需要组合两个技能。这要求你在设计时忍受“多几个 Skill”但换来的是更清晰的边界和更可预期的输出。3.2 上下文管理不要让技能把所有历史都塞给模型很多 Agent Skills 的实现里技能内部会有多轮子调用。比如先检索资料再写摘要再生成报告。如果实现粗糙每一步都把之前所有上下文原样传递给模型很容易把上下文窗口塞满同时引入大量无关信息干扰模型的注意力。更合理的做法是在每个步骤之间做上下文精简。举个例子一个“客户邮件回复 Skill”可能有三个步骤提取邮件要点、生成回复草稿、检查语气是否合适。这三个步骤其实不需要把原始邮件重复传给模型三次。第一步完成后只需要把“要点列表”传给第二步第二步完成后只需要把“草稿内容”传给第三步。从工程上看Skills 内部应该传递关键中间状态而不是完整历史记录。这也是 Agent Skills 和纯 Prompt 工作的核心差异你可以用结构化代码控制上下文流而不是完全依赖模型自己筛选重点。3.3 错误处理和重试逻辑应该内建我们看很多 Agent Skill 的示例代码只会展示正常流程。但生产环境里失败是常态。网络请求超时、数据库连接中断、模型返回格式不符合预期、文件路径不存在任何一个环节出问题整个 Skill 都会中断。建议在设计 Skill 时一开始就把错误处理纳入结构而不是后续打补丁。具体来说每个 Skill 应该有四层错误处理输入校验错误参数缺失、类型错误、范围超限时返回明确的错误信息而不是进入执行流程。依赖调用失败外部 API 或模型调用失败时区分“临时故障”和“永久错误”。临时故障可以重试永久错误要直接返回失败原因。格式校验失败输出结果不符合预期格式时增加一次修复或格式化步骤。降级策略如果主路径失败是否可以考虑备选方案。比如向量库挂了是否可以退回到关键词搜索。一个 Skill 如果缺少这些处理它在单次调用中可能看起来没问题但在批量任务或长期运行中会频繁失败。这是“原型可运行”和“生产可用”之间最大的差距。3.4 从单 Agent 技能到多 Agent 协作的演进路径Agent Skills 的另一个优势是它是天然的协作单元。当你把各个能力模块封装成 Skill 后不同 Agent 可以按需调用同一个 Skill这降低了重复开发成本也为多 Agent 协作打下了基础。演进路径通常是这样阶段一单 Agent 单 Skill验证流程可行性。阶段二单 Agent 多 Skill让 Agent 根据任务类型选择合适技能。阶段三多 Agent 多 Skill主 Agent 负责任务拆解和结果汇总子 Agent 各自调用自己的技能。阶段四Skill 跨项目复用形成团队或组织的技能广场。在每个阶段你需要关注的工程问题不同。阶段一关注流程是否正确阶段二关注技能选择准确率阶段三关注状态同步和结果合并阶段四关注权限控制、版本管理和质量评估。很多人一开始就想把系统设计到阶段四这是不现实的。更好的策略是先让一个技能在一个项目里稳定运行再逐步扩大规模。4. 落地 Agent Skills 的最小流程与踩坑排查如果你看完上面这些内容决定在自己的项目里尝试 Agent Skills接下来就是如何动手的问题。这一部分我会给一条从零开始的最小流程以及一套排查思路。4.1 最小可用流程先跑通一个 Skill我建议不要一上来就设计十几个 Skill。先选一个你当前工作中最频繁、最重复的任务把它沉淀成第一个 Skill。步骤如下明确任务边界。写清楚这个 Skill 的输入、输出、以及在什么条件下适用。先不用 LangChain用普通 Python 把核心步骤跑通。比如“读取文件、调用模型、返回结果”确认这一步没问题。把核心步骤封装成函数加上输入校验和错误处理。接入 LangChain 的 Tool 或 LangGraph 节点让 Agent 可以看到并调用这个 Skill。用一条真实样例测试检查输出格式是否符合预期并查看调用日志。补充更详细的描述让大模型知道什么时候该用、什么时候不该用。这套流程的核心思想是先保证每一步都可控再让它被模型调用。否则你很难区分失败原因是模型决策问题还是技能实现问题。4.2 一个质量评估清单你可以在设计完成后用下面这个清单评估自己的 Skill 是否合格评估项检查点输入定义是否明确每个参数的类型、是否必填、取值范围能力边界是否写清了“不适用场景”输出格式成功输出和失败输出是否有统一结构错误处理超时、重试、降级是否处理了日志关键步骤是否打点上下文精简中间步骤是否避免传递完整历史可组合性能否被其他 Agent 或 Skill 复用如果你对某项回答“否”建议先补上再推广使用。不要指望一个还没定义好成功/失败输出的 Skill能被模型可靠地调用。4.3 常见问题的排查链路使用 Agent Skills 时难免遇到问题。我建议按下面的链路排查少走弯路先看失败发生在哪一层是模型没有选择正确的 Skill还是 Skill 内部执行失败如果是模型选择错误检查 Skill 描述是否清晰、示例是否充足、不同 Skill 之间的边界是否模糊。如果是 Skill 内部执行失败看日志定位是哪个步骤抛错。输入问题还是资源问题检查输入是否符合 Skill 的参数定义缺参数、类型错误、格式不符都要排查。检查输出是否合规如果模型拿到的结果不符合预期可能是 Skill 的输出格式不够结构化。最后看环境问题依赖版本、网络权限、Python 版本、LangChain 版本都可能影响运行结果。实际操作中我发现两个最常见的问题一个是 Skill 之间描述太像导致模型选错另一个是 Skill 内部对异常输入没有做校验导致错误在较深的步骤里才暴露排查成本很高。针对第一个问题可以在描述里写“这是用于 XX 场景如果你需要 YY请调用另一个技能”。针对第二个问题就是在入口处立即校验输入不合格直接返回错误信息。4.4 从学习到生产的工程化建议如果你只是学习或用个人项目尝试上述内容基本够了。但如果你准备放进真实业务还需要考虑四件事第一权限控制。不是所有 Agent 或所有用户都应该能调用所有 Skill。特别是那些涉及文件写入、数据处理、外部系统操作的 Skill应该有严格的权限控制。第二版本管理。Skill 会随着业务需求变化而迭代。建议用 Git 管理每次变更并在 Skill 内部标注版本号。否则一旦调用方收到错误结果很难追溯是哪次变更导致的。第三监控与质量评估。上线后要监控每次调用的成功率和输出质量。对关键 Skill可以增加人工抽检流程。第四成本控制。一些 Skill 内部会调用多次大模型 API如果频繁使用成本会比单一调用高很多。建议在 Skill 内部限制模型调用频率并记录每次调用消耗。提醒一点不要急着把项目里所有逻辑都改造成 Skills。先从最稳定、最成熟的流程入手验证它在工程上的表现再逐步扩大范围。5. 哪些场景适合 Agent Skills哪些不适合任何一个架构方案都有适用边界。Agent Skills 很适合某些场景但在另一些场景里传统 Agent 或流程编排会更合适。5.1 适合的场景从我的实践观察下面这些场景使用 Agent Skills 的收益比较明显多 Agent 共用同一套能力。比如内部知识问答、数据检索、报告生成多个 Agent 都要用封装成技能后避免重复开发。需要稳定执行的多步流程。步骤多、顺序固定、容错要求高用流程型 Skill 固化下来比让模型自由规划更可靠。工具数量较大的项目。工具多了之后模型选择准确率会下降封装成更高层级的技能可以减少模型需要做的决策数量。跨项目复用。有明确抽象边界的技能比如“表格数据清洗”可以跨项目复用降低后续开发成本。5.2 不适合的场景这些场景则不建议为了用技能而用技能一次性或探索性任务。任务只跑一次封装成技能反而增加成本。需要高度灵活、无固定流程的对话。比如开放式头脑风暴过于结构化的 Skill 会限制模型的发挥。技能内部逻辑频繁变化且每次变化都不同。如果技能三个月就需要重写一次封装的价值就不大了。需要强实时交互、逐字输出的场景。Skills 更适合偏向后台执行的任务类型不太适合对话中需要即时反馈的场景。5.3 和 LangGraph、MCP 等方案放在一起选型现在市面上的方案不少LangChain、LangGraph、MCP、Agent Skills以及各种 Agent 框架。很多人在选型时陷入纠结。我的建议是不要把它们看作互斥的选项而是看作不同层级的工具LangChain 提供基础组件LangGraph 提供流程编排和状态管理MCP 提供标准和协议让不同 Agent 应用可以共享工具Agent Skills 则是在这些基础之上提供“能力封装”的组织方式。你可以组合使用用 LangGraph 编排复杂流程用 MCP 接入外部工具用 Agent Skills 封装内部能力单元。这种组合的好处是每一层只做一件事职责清晰维护起来也容易定位问题。6. 回到根上Agent Skills 的关键不是单个技能而是技能的组合与沉淀经过前面这些分析我想把话题收回到一个更本质的判断Agent Skills 的真正价值不在于它让单个 Agent 能力更强不在于它有 12 个案例还是 20 个案例而在于它提供了一种“沉淀能力”的方式。过去我们做 LLM 应用每次开发都是从 Prompt 开始从零定义工具从零编排流程。项目结束之后这些能力很难带走。Agent Skills 则不一样它把“完成某类任务的能力”变成了一个可复制、可迁移、可组合的模块。你做过的数据清洗流程可以封装成 Skill 放到下一个项目里你做过的报告生成流程可以封装成 Skill 让不同的 Agent 共用。这种沉淀随着 AI 应用开发越来越复杂会显得越来越有价值。当然也要承认 Agent Skills 还在快速演进中。不同版本的 LangChain、LangGraph 对 Skills 的支持方式可能有差异各社区的实践也还没有完全统一。所以在动手之前最好先确认你使用的框架版本和官方示例是否一致不要照搬网上的旧代码。如果你现在问我第一次尝试 Agent Skills 应该从哪里开始我会建议你不要先学十几个技能案例不要先搭复杂的多 Agent 架构。先找一个你反复在做的任务把它封装成一个完美的技能。让它有清晰的输入输出有完备的错误处理有日志有质量检查。当你完成了这一个技能你对 Agent Skills 的理解会比看十篇文章都深刻。这就像写代码真正理解一个框架的方式不是记住它的全部 API而是用它写好一个模块。Agent 的开发正在变得像工程化软件开发一样可测试、可复用、可维护。Agent Skills 是这个趋势里比较重要的一步值得花一些时间研究。但最终让你受益的不是某个新架构的潮流而是你亲手沉淀下来的那些技能。 LangChain Agent Skills 架构解析：从工具封装到可复用技能设计
最近在技术社区里LangChain 的 Agent Skills 架构被讨论得很多。不少朋友问我它到底是一个新包装的概念还是值得认真跟进的架构方向我的判断是Agent Skills 真正解决的问题不是“让 Agent 能做更多事”而是把 Agent 的能力从“一次性实现”变成“可复用资产”。这个转变直接影响你写 Agent 的方式、调试的方式以及后续扩展的方式。先说一个比较常见的场景。很多人第一次用 LangChain 写 Agent 时流程是先找一个大模型 API再定义一个工具函数然后写一个 Prompt 告诉模型“你可以调用这些工具”。跑通之后再往里面加第二个工具、第三个工具。这个阶段体验还行因为工具数量少规则简单模型还能应付。但一旦工具数量变多任务链路变长问题就出来了。模型不知道该在什么时候调用哪个工具工具的输入输出格式不统一多步操作经常断在中间一步。更麻烦的是这些工具和当时的业务逻辑强耦合在一起换个项目想复用基本等于重写。这就是 Agent 开发从“原型”走向“工程化”时最容易卡住的地方。Agent Skills 架构本质上就是在解决这个问题。它不是多了一个工具函数而是把“做一个任务的能力”封装成一个独立单元这个单元自带描述、输入输出定义、执行逻辑、错误处理和可组合性。如果你把 12 个真实案例拆开看会发现它们并不是 12 种孤立的用法而是在反复印证同一个变化Agent 从“能聊天、能调工具”走向“能按技能模块组织复杂工作流”。下面我会用四个部分把这件事拆透它到底改了什么、案例怎么分类理解、落地时怎么设计和排查、以及它的适用边界在哪里。1. 先搞清楚Agent Skills 到底在解决什么问题很多讨论一上来就列功能、贴代码却没有回答一个最基础的问题为什么需要 Agent Skills这个问题的答案藏在 Agent 开发方式的演进过程里。1.1 从 Prompt 工程到 Agent再到 Skill 的演进逻辑最早做 LLM 应用核心工作是写 Prompt。你告诉模型要做什么、不要做什么、输出什么格式。这个方法对单轮、短任务很有效但一旦任务需要多步推理、查资料、操作外部系统Prompt 就撑不住了。模型没有记忆没有状态不能可靠地完成一系列动作。于是有了 Agent。Agent 的核心是把模型放在一个循环里模型决定调用什么工具工具返回结果模型继续推理直到任务完成。这个思路解决了“多步操作”的问题。LangChain 早期提供的 AgentExecutor就是基于这种 Loop 机制。但 Agent 方式也有新的问题。当你使用 5 个、10 个甚至更多工具时模型在每一步都要重新理解“我有什么工具、该选哪一个、参数怎么传”。这个认知负担会越来越重模型的选择准确率下降调试也变得困难。于是社区里出现了两种应对思路一种是 LangGraph 式的状态图方案把流程显式地画出来用节点和边控制 Agent 的走向另一种就是 Agent Skills把“工具 流程 知识 约束”打包成一个更高级别的能力单元。不要把这两者对立起来。LangChain 负责提供组件LangGraph 负责提供流程编排Agent Skills 负责提供可复用的能力模块。一个常见的误解是Agent Skills 会取代 LangGraph。实际上两类方案解决的是不同层级的问题Skills 描述的是“能做什么”Graph 描述的是“按什么顺序做”。1.2 Skills 与传统 Tool、Function Calling 的核心区别要理解 Agent Skills最好的方式是拿它和传统 Tool 做一个对比。传统 Tool 是一个函数功能很具体。比如“查询天气”“计算两个日期之差”“调用某个 HTTP 接口”。Tool 的描述通常只有一两句话模型通过描述决定是否调用。它适合完成原子性操作但很难承载一个完整任务。Agent Skill 则是一个完整的能力包。它通常包含几个要素能力名称和适用场景描述。输入参数定义包括类型、必填项、约束。执行流程可能包含多个步骤。处理过程中需要的提示词模板。错误处理逻辑比如重试次数、超时策略、降级方案。输出格式说明包括成功结果和失败结果。这个差异决定了使用方式完全不同。以传统工具方式写一个“研究某个行业动态”的 Agent你可能需要注册三四个工具搜索新闻、打开链接、提取摘要、生成报告。模型需要自己决定调用顺序。但以 Skill 方式写你可以把整个流程封装成一个IndustryResearchSkill模型只需要说“我想研究一下储能行业”这个 Skill 内部自己去完成搜索、阅读、梳理、报告生成的链路。这带来的直接好处是模型面对的选择变少了决策压力变小了技能内部的重试、容错逻辑可以统一处理不同 Agent 之间可以共享同一个 Skill而不必复制代码。1.3 为什么说这是一次架构层面的调整Agent Skills 之所以引起关注是因为它改变了 LLM 应用的开发组织方式。过去的开发组织方式是以模型为中心。你写 Prompt你定义工具列表模型在每一轮根据系统提示词决定下一步。这种方式适合小规模应用但当你面前有几十个工具、多个业务模块、多条流程时系统提示词会越来越长模型会越来越“倾向于”忽略一些工具或者在不合适的时机调用它们。Skills 的架构逻辑把模型从“每步都要精确判断”的压力中解放了出来。模型不再需要理解所有底层工具的细节它只需要在更高层级做决策这个任务应该调用哪个 Skill每个 Skill 自己负责内部的工具调度。这就像管理团队。以前你是一个项目经理需要精确指挥每一位员工的每一步动作现在你把任务分给几个小组长由小组长负责内部执行你只需要关注小组长的产出是否达标。从社区讨论和实际项目经验来看这种架构在大型 Agent 应用中的价值会越来越明显。但也要看到它的代价技能封装会带来额外的抽象层调试时你需要同时理解外层调用逻辑和内层实现逻辑。如果一个 Skill 的输出不符合预期你可能要查两层代码。这是使用 Skills 时必须接受的复杂度。2. 12 个典型案例拆解不要只记用法要看类别我看过不少案例总结很多文章把 12 个案例平铺开逐个介绍“这个技能能干什么”。这种记法很零散换个场景你还是不知道怎么设计。更有效的做法是先把案例按能力类型分类然后理解每一类在设计时有什么共性。我倾向于把常见 Agent Skills 案例分成四类工具型、知识型、流程型、协作型。2.1 工具型 Skills封装对具体工具的操作能力工具型 Skills 是最基础的一类。它对应“操作某个具体工具或系统”的能力内部一般会调用外部 API、命令行工具或第三方库。常见案例包括代码执行 Skill接收一段 Python 或 JavaScript 代码在沙箱中执行捕获输出和错误信息。文件操作 Skill读写本地文件、遍历目录、重命名、格式转换。表格处理 Skill读取 Excel 或 CSV清洗数据统计聚合生成图表。爬虫 Skill抓取指定网页内容提取正文处理编码问题。这类 Skill 的设计重点不是“能调 API”而是“把复杂操作的细节藏在内部”。以表格处理为例如果你直接给 Agent 暴露一个run_python_code工具它确实可以操作表格但你需要每一步都精确写清楚代码逻辑一旦代码出错Agent 还得去读错误信息并修改代码很容易陷入循环。但如果你封装一个ExcelAnalysisSkill输入是“文件路径 分析需求”输出是“清洗后的数据表 统计摘要”模型就不需要写代码也不需要在底层逻辑里来回试错。这里有一个很关键的设计原则Skill 的抽象级别要高于工具。Skill 不应该只是给工具换了个名字而应该真正封装一个完整任务。如果某个 Skill 内部只有一次 API 调用那它本质上还是一个 Tool没必要升级成 Skill。2.2 知识型 Skills让 Agent 会查、会读、会整理知识型 Skills 解决的是“获取和处理信息”的问题。它和直接给模型接一个 RAG 流程不同强调的是把知识获取过程做成一个稳定的能力模块。常见案例包括向量检索 Skill连接向量数据库根据语义相似度返回相关文档片段。知识库问答 Skill基于公司内部文档生成有引用来源的回答。网页检索 Skill调用搜索接口整理出结构化搜索结果。论文阅读 Skill解析 PDF 章节结构提取摘要和关键结论。知识型 Skill 很容易和 RAG 混淆。RAG 更多是指一种技术方案包含“索引、检索、生成”三个环节。Skill 则是把 RAG 的完整链路封装成一个可调用的单元。如果你的项目里有多个 Agent每个 Agent 都需要做“基于知识库回答”那么把 RAG 流程封装成 Skill 就是明显的收益点你只需要维护一份检索、重排、引用格式相关的逻辑所有 Agent 共用。知识型 Skill 的设计难点在于输入设计。很多人在写这类 Skill 时只定义了“问题”一个输入参数。这会导致一个问题当用户问法模糊时检索结果质量不稳定。更合理的做法是让 Skill 同时接收“问题”“检索范围”“期望的返回格式”等多个参数。比如可以传doc_filter{category: 产品手册, date_range: [2024-01-01, 2024-12-31]}让检索范围更可控。这需要你在封装时多花一些心思定义参数但换来的是更高的检索稳定性。2.3 流程型 Skills把多步操作固化下来这是 Agent Skills 相比传统 Tool 优势最明显的一类。它把多个步骤、多种工具调用、条件分支全部封装进一个 Skill。常见案例包括数据处理流水线 Skill接收原始数据执行清洗、转换、校验、入库。报告生成 Skill先收集素材再分析数据然后生成图表最后按模板输出 Markdown 报告。模型评估 Skill加载测试集批量运行推理对比基线结果输出评估报告。运维排查 Skill检查服务状态、拉取日志、分析错误码、给出修复建议。流程型 Skills 的价值在于它解决了 Agent 的一个核心痛点多步任务容易中断。如果每一步都由模型自己决定模型很可能在某一步走偏。但把流程固化到 Skill 内部后模型只负责接收任务、调用 Skill、拿到结果。中间步骤的执行和分支判断由代码控制确定性大幅提升。在设计流程型 Skill 时我建议做一件事把 Skill 内部的关键步骤用日志打点。这样当 Skill 执行失败时你能快速定位是第一步读取输入、第二步清洗数据、还是最后一步写入输出出了问题。很多初学者忽略日志结果遇到失败时只能整个 Skill 重跑排查效率很低。2.4 协作型 Skills多 Agent 场景下的能力分配协作型 Skills 面向的是多 Agent 场景。这类 Skill 本身可能是完成较为复杂的任务或者在执行过程中会调用其他 Agent 的能力。常见案例包括任务分发 Skill接收一个大型任务拆解成子任务分发给不同 Agent汇总结果。复核 Skill完成内容生成后调用另一个 Agent 或模型实例进行复查检查事实错误、格式问题。数据校验 Skill对比多个 Agent 的输出结果识别不一致之处。人机交接 Skill在需要用户确认的节点暂停等待用户批准后再继续后续操作。有人会问这和多 Agent 系统有什么区别区别在于 Skill 把“协作协议”封装了。如果你用 LangGraph 做多 Agent 编排通常需要显式定义状态转移和消息传递逻辑。而 Skills 的方式是把协作逻辑封装成一个技能Agent 只需要触发这个技能后续的协调交给 Skill 内部处理。它更适合“协作流程比较稳定、但参与 Agent 可能变化”的场景。协作型 Skill 的适用场景确实存在比如一个咨询报告生成任务可能先由一个 Agent 负责行业信息收集再由另一个 Agent 负责数据可视化。把这条流程封装成 Skill 之后调用方不需要知道内部是哪个 Agent 在处理只需要看到最终成果。这样既实现了任务解耦也让整个系统更容易演化。3. 真正决定成败的不是技能数量而是设计方式围绕 Agent Skills 的讨论里有一个容易让人焦虑的说法谁的技能库大谁就更强。从实际项目看技能数量多不等于系统好用。真正决定体验的是每个 Skill 的设计质量。3.1 每个 Skill 都要有清晰的“能力边界”这是我在评估 Agent Skills 时放在第一位的要求。一个 Skill 必须清楚说明自己能做什么、不能做什么、什么情况下应该拒绝任务。从技术实现上你可以通过系统提示词、输入校验、前置条件检查来增强能力边界。但更重要的还是设计时的认知这个技能是窄而深还是宽而浅一个常见的反面例子是“万能分析 Skill”。设计者把数据清洗、统计分析、可视化、报表生成全塞进一个 Skill结果模型以为它什么都能干但每次调用都只能覆盖其中一部分功能参数组合复杂到连调用者都记不住。这种 Skill 很难获得稳定的输出。更好的拆分方式是让每个 Skill 只做一类事情但把这一件事做到位。比如把“数据清洗”和“报表生成”拆开前者聚焦数据质量后者聚焦可视化展示。调用方可以根据需要组合两个技能。这要求你在设计时忍受“多几个 Skill”但换来的是更清晰的边界和更可预期的输出。3.2 上下文管理不要让技能把所有历史都塞给模型很多 Agent Skills 的实现里技能内部会有多轮子调用。比如先检索资料再写摘要再生成报告。如果实现粗糙每一步都把之前所有上下文原样传递给模型很容易把上下文窗口塞满同时引入大量无关信息干扰模型的注意力。更合理的做法是在每个步骤之间做上下文精简。举个例子一个“客户邮件回复 Skill”可能有三个步骤提取邮件要点、生成回复草稿、检查语气是否合适。这三个步骤其实不需要把原始邮件重复传给模型三次。第一步完成后只需要把“要点列表”传给第二步第二步完成后只需要把“草稿内容”传给第三步。从工程上看Skills 内部应该传递关键中间状态而不是完整历史记录。这也是 Agent Skills 和纯 Prompt 工作的核心差异你可以用结构化代码控制上下文流而不是完全依赖模型自己筛选重点。3.3 错误处理和重试逻辑应该内建我们看很多 Agent Skill 的示例代码只会展示正常流程。但生产环境里失败是常态。网络请求超时、数据库连接中断、模型返回格式不符合预期、文件路径不存在任何一个环节出问题整个 Skill 都会中断。建议在设计 Skill 时一开始就把错误处理纳入结构而不是后续打补丁。具体来说每个 Skill 应该有四层错误处理输入校验错误参数缺失、类型错误、范围超限时返回明确的错误信息而不是进入执行流程。依赖调用失败外部 API 或模型调用失败时区分“临时故障”和“永久错误”。临时故障可以重试永久错误要直接返回失败原因。格式校验失败输出结果不符合预期格式时增加一次修复或格式化步骤。降级策略如果主路径失败是否可以考虑备选方案。比如向量库挂了是否可以退回到关键词搜索。一个 Skill 如果缺少这些处理它在单次调用中可能看起来没问题但在批量任务或长期运行中会频繁失败。这是“原型可运行”和“生产可用”之间最大的差距。3.4 从单 Agent 技能到多 Agent 协作的演进路径Agent Skills 的另一个优势是它是天然的协作单元。当你把各个能力模块封装成 Skill 后不同 Agent 可以按需调用同一个 Skill这降低了重复开发成本也为多 Agent 协作打下了基础。演进路径通常是这样阶段一单 Agent 单 Skill验证流程可行性。阶段二单 Agent 多 Skill让 Agent 根据任务类型选择合适技能。阶段三多 Agent 多 Skill主 Agent 负责任务拆解和结果汇总子 Agent 各自调用自己的技能。阶段四Skill 跨项目复用形成团队或组织的技能广场。在每个阶段你需要关注的工程问题不同。阶段一关注流程是否正确阶段二关注技能选择准确率阶段三关注状态同步和结果合并阶段四关注权限控制、版本管理和质量评估。很多人一开始就想把系统设计到阶段四这是不现实的。更好的策略是先让一个技能在一个项目里稳定运行再逐步扩大规模。4. 落地 Agent Skills 的最小流程与踩坑排查如果你看完上面这些内容决定在自己的项目里尝试 Agent Skills接下来就是如何动手的问题。这一部分我会给一条从零开始的最小流程以及一套排查思路。4.1 最小可用流程先跑通一个 Skill我建议不要一上来就设计十几个 Skill。先选一个你当前工作中最频繁、最重复的任务把它沉淀成第一个 Skill。步骤如下明确任务边界。写清楚这个 Skill 的输入、输出、以及在什么条件下适用。先不用 LangChain用普通 Python 把核心步骤跑通。比如“读取文件、调用模型、返回结果”确认这一步没问题。把核心步骤封装成函数加上输入校验和错误处理。接入 LangChain 的 Tool 或 LangGraph 节点让 Agent 可以看到并调用这个 Skill。用一条真实样例测试检查输出格式是否符合预期并查看调用日志。补充更详细的描述让大模型知道什么时候该用、什么时候不该用。这套流程的核心思想是先保证每一步都可控再让它被模型调用。否则你很难区分失败原因是模型决策问题还是技能实现问题。4.2 一个质量评估清单你可以在设计完成后用下面这个清单评估自己的 Skill 是否合格评估项检查点输入定义是否明确每个参数的类型、是否必填、取值范围能力边界是否写清了“不适用场景”输出格式成功输出和失败输出是否有统一结构错误处理超时、重试、降级是否处理了日志关键步骤是否打点上下文精简中间步骤是否避免传递完整历史可组合性能否被其他 Agent 或 Skill 复用如果你对某项回答“否”建议先补上再推广使用。不要指望一个还没定义好成功/失败输出的 Skill能被模型可靠地调用。4.3 常见问题的排查链路使用 Agent Skills 时难免遇到问题。我建议按下面的链路排查少走弯路先看失败发生在哪一层是模型没有选择正确的 Skill还是 Skill 内部执行失败如果是模型选择错误检查 Skill 描述是否清晰、示例是否充足、不同 Skill 之间的边界是否模糊。如果是 Skill 内部执行失败看日志定位是哪个步骤抛错。输入问题还是资源问题检查输入是否符合 Skill 的参数定义缺参数、类型错误、格式不符都要排查。检查输出是否合规如果模型拿到的结果不符合预期可能是 Skill 的输出格式不够结构化。最后看环境问题依赖版本、网络权限、Python 版本、LangChain 版本都可能影响运行结果。实际操作中我发现两个最常见的问题一个是 Skill 之间描述太像导致模型选错另一个是 Skill 内部对异常输入没有做校验导致错误在较深的步骤里才暴露排查成本很高。针对第一个问题可以在描述里写“这是用于 XX 场景如果你需要 YY请调用另一个技能”。针对第二个问题就是在入口处立即校验输入不合格直接返回错误信息。4.4 从学习到生产的工程化建议如果你只是学习或用个人项目尝试上述内容基本够了。但如果你准备放进真实业务还需要考虑四件事第一权限控制。不是所有 Agent 或所有用户都应该能调用所有 Skill。特别是那些涉及文件写入、数据处理、外部系统操作的 Skill应该有严格的权限控制。第二版本管理。Skill 会随着业务需求变化而迭代。建议用 Git 管理每次变更并在 Skill 内部标注版本号。否则一旦调用方收到错误结果很难追溯是哪次变更导致的。第三监控与质量评估。上线后要监控每次调用的成功率和输出质量。对关键 Skill可以增加人工抽检流程。第四成本控制。一些 Skill 内部会调用多次大模型 API如果频繁使用成本会比单一调用高很多。建议在 Skill 内部限制模型调用频率并记录每次调用消耗。提醒一点不要急着把项目里所有逻辑都改造成 Skills。先从最稳定、最成熟的流程入手验证它在工程上的表现再逐步扩大范围。5. 哪些场景适合 Agent Skills哪些不适合任何一个架构方案都有适用边界。Agent Skills 很适合某些场景但在另一些场景里传统 Agent 或流程编排会更合适。5.1 适合的场景从我的实践观察下面这些场景使用 Agent Skills 的收益比较明显多 Agent 共用同一套能力。比如内部知识问答、数据检索、报告生成多个 Agent 都要用封装成技能后避免重复开发。需要稳定执行的多步流程。步骤多、顺序固定、容错要求高用流程型 Skill 固化下来比让模型自由规划更可靠。工具数量较大的项目。工具多了之后模型选择准确率会下降封装成更高层级的技能可以减少模型需要做的决策数量。跨项目复用。有明确抽象边界的技能比如“表格数据清洗”可以跨项目复用降低后续开发成本。5.2 不适合的场景这些场景则不建议为了用技能而用技能一次性或探索性任务。任务只跑一次封装成技能反而增加成本。需要高度灵活、无固定流程的对话。比如开放式头脑风暴过于结构化的 Skill 会限制模型的发挥。技能内部逻辑频繁变化且每次变化都不同。如果技能三个月就需要重写一次封装的价值就不大了。需要强实时交互、逐字输出的场景。Skills 更适合偏向后台执行的任务类型不太适合对话中需要即时反馈的场景。5.3 和 LangGraph、MCP 等方案放在一起选型现在市面上的方案不少LangChain、LangGraph、MCP、Agent Skills以及各种 Agent 框架。很多人在选型时陷入纠结。我的建议是不要把它们看作互斥的选项而是看作不同层级的工具LangChain 提供基础组件LangGraph 提供流程编排和状态管理MCP 提供标准和协议让不同 Agent 应用可以共享工具Agent Skills 则是在这些基础之上提供“能力封装”的组织方式。你可以组合使用用 LangGraph 编排复杂流程用 MCP 接入外部工具用 Agent Skills 封装内部能力单元。这种组合的好处是每一层只做一件事职责清晰维护起来也容易定位问题。6. 回到根上Agent Skills 的关键不是单个技能而是技能的组合与沉淀经过前面这些分析我想把话题收回到一个更本质的判断Agent Skills 的真正价值不在于它让单个 Agent 能力更强不在于它有 12 个案例还是 20 个案例而在于它提供了一种“沉淀能力”的方式。过去我们做 LLM 应用每次开发都是从 Prompt 开始从零定义工具从零编排流程。项目结束之后这些能力很难带走。Agent Skills 则不一样它把“完成某类任务的能力”变成了一个可复制、可迁移、可组合的模块。你做过的数据清洗流程可以封装成 Skill 放到下一个项目里你做过的报告生成流程可以封装成 Skill 让不同的 Agent 共用。这种沉淀随着 AI 应用开发越来越复杂会显得越来越有价值。当然也要承认 Agent Skills 还在快速演进中。不同版本的 LangChain、LangGraph 对 Skills 的支持方式可能有差异各社区的实践也还没有完全统一。所以在动手之前最好先确认你使用的框架版本和官方示例是否一致不要照搬网上的旧代码。如果你现在问我第一次尝试 Agent Skills 应该从哪里开始我会建议你不要先学十几个技能案例不要先搭复杂的多 Agent 架构。先找一个你反复在做的任务把它封装成一个完美的技能。让它有清晰的输入输出有完备的错误处理有日志有质量检查。当你完成了这一个技能你对 Agent Skills 的理解会比看十篇文章都深刻。这就像写代码真正理解一个框架的方式不是记住它的全部 API而是用它写好一个模块。Agent 的开发正在变得像工程化软件开发一样可测试、可复用、可维护。Agent Skills 是这个趋势里比较重要的一步值得花一些时间研究。但最终让你受益的不是某个新架构的潮流而是你亲手沉淀下来的那些技能。