2026 年谈大模型应用最值得开发者关注的早已不是“哪个模型参数更多”而是“怎么让模型在真实工作流里稳定地创造价值”。Agent Skills 就是在这个节点上被反复提起的概念。你对它可能有两种模糊印象要么觉得它只是“提示词工程的又一种包装”要么觉得它是某个大厂新推出的神秘框架。这两种理解都不太准确。这篇博客会把 Agent Skills 从头拆到尾它到底是什么、和 Agent、Tool、MCP 有什么区别、怎么动手定义一个可用的技能包、怎么在论文写作这类真实场景里落地。整篇文章以“能跑通最小示例”为目标最后会给你一份可以直接收藏的排查清单和工程建议。1. 这篇文章真正要解决的问题先从一个很普遍的困扰说起。假设你要让大模型帮你做行业研究报告。你精心写了一段提示词要求它按“背景—现状—数据—结论—建议”的结构输出。第一次效果不错第二次模型自由发挥把结构改成了四段式第三次连数据口径都变了。你不得不反复调整提示词甚至把历史对话一次次重发。这就是当前大模型应用最大的痛点模型很强但对“你的任务、你的流程、你的标准”没有稳定的记忆。提示词能解决单次任务却解决不了“能力复用”。换个项目、换个团队成员、换一次编程模型上下文窗口刷新所有经验又要重新灌输一遍。Agent Skills 要解决的核心问题正是把“一套解决某一类问题的知识、流程和脚本”固化成模型可以按需加载的文件包。它不是玄学也不依赖某个特定模型而是一种工程组织方式。读完这篇文章你可以做到三件事写出第一个符合规范的 SKILL.md 文件。配套一个可执行的辅助脚本形成完整的技能包。把技能包加载到 Agent 工具链里跑通一次完整调用并知道失败时去排查哪里。2. Agent Skills 是什么与 Agent、Tool、MCP 的关系2.1 概念定义Agent Skills 目前没有一个全球统一的“标准”但主流实现例如 Anthropic 提出的 Claude Skills 模式以及多个开源 Agent 框架的吸收方案都在朝同一个方向收敛Agent Skills 是一种以自然语言描述SKILL.md加辅助脚本/资源文件为载体的“领域能力包”。拆开看它可以理解为两个部分技能说明书一段人类可读、模型可解析的描述告诉模型这个技能解决什么问题、适合什么场景、怎么使用。技能实现物一个或多个脚本、模板、数据文件真正承担执行任务。为什么是这种形态因为大模型本身不适合记忆大量固定逻辑但非常擅长“读懂说明并调用工具”。SKILL.md 就是把“怎么做”的决策逻辑写在明面上让模型照着执行而不是每次靠随机发挥。2.2 与 Tool 的区别很多教程里Agent Skills 和 Tool 经常混着讲但它们解决的问题层级不同。Tool 是一个功能函数解决“模型能做什么”。例如get_weather(city)、search_web(keyword)单个工具只完成一次外部交互。Skill 是一个领域能力包解决“模型能做好什么”。它可能包含多个工具、多段知识说明、一套流程编排。用一个生活类比螺丝刀、扳手、电钻是 Tool而“修理厨房水龙头”是一套 Skill。这个技能不仅包括该用哪些工具还包括关水阀、拆旧件、缠生料带、按顺序装回的步骤和注意事项。技术语境里维度ToolAgent Skill粒度单个函数/API一组知识、脚本、流程的组合核心内容接口定义与执行逻辑领域流程、规范、示例、资源解决目标扩展模型的外部操作能力让模型在特定领域内稳定高质量工作是否依赖模型理解弱参数传给函数即可强模型需要理解描述并按流程执行典型示例查询天气、发送邮件、执行 SQL写学术论文、做竞品分析、生成营销方案简单理解一个 Skill 可以“包含”工具的调用也可以完全不调用工具只提供领域知识和步骤约束。2.3 与 MCP 的关系MCPModel Context Protocol是另一个绕不开的词。它解决的是“模型连接外部工具的标准接口问题”相当于工具生态的 USB-C 接口标准。Agent Skills 和 MCP 并不冲突而是两个层面的东西MCP 关注“连接”让模型与外部数据源、系统通过统一协议交互。Agent Skills 关注“能力封装”把解决某类问题需要的方法、知识、流程、脚本打包。实际工程里两者往往组合使用Skill 负责告诉模型“这个领域的任务该怎么拆、按什么标准做”MCP 负责在真正需要查询数据库、调用业务系统时提供标准接口。2.4 一个小结论可以把 Agent Skills 理解成一个“可加载的专业知识包”。模型是通用大脑Skill 是大脑外接的专科模块。大脑本身不需要重新训练换一个专科模块就能处理新领域的复杂任务。3. 为什么 Agent Skills 在 2026 年会被反复提起吴恩达Andrew Ng近两年在公开课和演讲中反复强调一个判断大模型价值落地的关键越来越取决于 Agent 工作流而不只是模型本身。虽然不能把 Agent Skills 完全归功于某一个人但它确实是这一思路走向工程化后的产物。为什么是 2026 年这个时间点被反复讨论我的判断是三个驱动力同时到位了。3.1 工具调用机制普及Function Calling 已经成为主流模型的标配能力。模型不仅能生成文本还能输出结构化的函数调用请求。这意味着“给模型一个脚本去执行”的技术门槛已经消失。Skill 的概念在被大规模使用前底层条件已经成熟。3.2 Agent 工作流从 Demo 走向生产早期 Agent 应用大多停留在“多轮对话 搜索”的演示阶段。但实际业务场景需要的不是对话而是稳定产出每天生成固定的数据报告、按公司标准撰写售前方案、批量整理客户访谈纪要。这类需求要求能力高度可复用、可复制Skill 这种“打包 加载”的形态天然匹配。3.3 团队知识复用成为刚需过去团队里的领域经验靠文档、培训、口口相传。现在已经有团队开始把“老师傅怎么处理客户投诉”“资深分析师怎么写行业研报”整理成技能包让模型和新人共同使用。这是知识管理方式的一次重要变化知识第一次可以直接变成可执行、可调用、可版本化的生产工具。所以你会发现Agent Skills 的真正价值不在技术复杂度而在于它把“知识”从人的脑子里抽出来变成了团队资产的组成部分。SKILL.md 是知识脚本是知识模板也是知识。知识有了版本、有了可用性测试、有了迭代流程。4. Agent Skills 的核心架构与设计思路4.1 核心结构一个典型的 Agent Skill 结构大致如下skills/ └── research-report/ ├── SKILL.md ├── templates/ │ └── report_template.md └── scripts/ ├── collect_data.py └── generate_chart.py目录名是技能标识SKILL.md 是入口附属目录存放执行所需的脚本和资源。4.2 SKILL.md 的关键字段不同框架的 SKILL.md 格式略有差异但通常会在文件开头使用 YAML frontmatter 写元信息--- name: research-report description: 用于生成行业研究报告。当用户需要市场分析、竞品研究、行业趋势整理时使用。 --- !-- 这里写技能的具体使用说明、步骤、注意事项 --两个关键字段name技能名称必须唯一且语义清晰。description技能描述这是模型判断“何时调用该技能”的核心依据必须写清楚触发场景而不是只写“这是研究助手”。正文部分的写法也很重要。模型会读取正文来理解执行方式所以正文应当清晰包含这个技能解决什么问题。执行步骤是什么。有哪些注意事项。是否依赖某些脚本脚本调用顺序是什么。4.3 模型如何“加载”一个 Skill流程通常是这样的启动 Agent 会话时系统扫描技能目录把每个技能的 name 和 description 注入上下文。模型根据用户问题时判断是否匹配某个技能描述。如果匹配模型读取该技能目录下的 SKILL.md 正文理解具体步骤。模型按说明执行必要时调用 scripts 下的脚本工具。这意味着description 写得太泛模型不会主动调用。正文写得太模糊模型执行结果不稳定。脚本本身有问题模型再聪明也无法产出正确结果。所以设计和调试 Skill 的核心工作本质是“把隐性的领域知识显性化”。4.4 设计原则三个原则值得牢记单一职责一个技能只解决一类问题。不要做一个“万能助手”技能。描述场景化description 里写“当用户需要……时使用”而不是写“我是一个助手”。执行可验证附带的脚本应当能独立运行并返回明确结果不要把关键逻辑依赖在模型的自由发挥上。5. 动手实现从零定义一个可用的 Agent Skill下面我们抛开抽象概念直接创建一个最小可用技能包。目标是让模型学会“用给定模板整理工作周报”。5.1 环境准备操作系统Linux、macOS 或 WindowsWindows 建议使用 WSL 或 Git Bash。Python3.10 或更高版本。一个支持 Skill 机制的 Agent 工具或框架。演示中使用支持--add-skill方式的 CLI 工具不同版本命令可能略有差异思路一致。文本编辑器建议使用 VS Code方便直接查看 Markdown 和脚本文件。5.2 创建技能目录mkdir -p skills/weekly-report/templates mkdir -p skills/weekly-report/scripts cd skills/weekly-report5.3 编写 SKILL.md文件路径skills/weekly-report/SKILL.md--- name: weekly-report description: 生成工作周报。当用户需要总结本周工作、整理产出清单、汇报项目进展时使用。输入需要包含本周完成事项的原始描述或备注。 --- # 工作周报技能 使用本技能可以将用户提供的零散工作记录整理成结构清晰的周报。 ## 执行步骤 1. 阅读用户提供的本周工作记录。 2. 将记录按以下分类整理 - 本周完成 - 项目进展 - 问题与风险 - 下周计划 3. 使用 templates/weekly-report-template.md 中的结构输出。 4. 输出时把原始记录中的模糊表达改写为更清晰的业务语言但不要编造用户没有提到的事实。 ## 注意事项 - 如果用户没有提供任何工作记录先询问不要自动编造内容。 - 每个分类不超过 5 条要点。 - 对涉及数字、日期、项目名称的内容保持原样不要自行修改。5.4 创建周报模板文件路径skills/weekly-report/templates/weekly-report-template.md## 本周工作周报 ### 本周完成 - ### 项目进展 - ### 问题与风险 - ### 下周计划 -5.5 添加辅助脚本为了展示“脚本 Skill”如何配合我们再添加一个关键词提取脚本。当用户提供的工作记录是长文本时脚本负责提取候选关键词模型再根据关键词组织周报。文件路径skills/weekly-report/scripts/extract_keywords.py#!/usr/bin/env python3 从工作记录文本中提取候选关键词。 import re import sys from collections import Counter def extract(text: str, top_n: int 10) - list[str]: words re.findall(r[\u4e00-\u9fffA-Za-z0-9], text) counter Counter(w for w in words if len(w) 1) return [w for w, _ in counter.most_common(top_n)] if __name__ __main__: input_text sys.stdin.read() if not input_text.strip(): print() else: print(\n.join(extract(input_text)))这个脚本不做任何复杂 AI 推理只负责从文本里提取高频词降低模型理解长文本时的负担。真正的工作流是模型读取文本调用脚本得到关键词再结合模板生成周报。5.6 加载技能并验证在支持 Skill 机制的 CLI 工具中加载方式一般类似claude --add-skill ./skills/weekly-report启动后可以这样测试用户这周我做了三件事重构用户登录模块修复了订单支付超时问题准备了下周的灰度发布计划。帮我生成工作周报。预期输出应当按照模板结构生成并且“修改用户登录模块”“修复支付超时”“灰度发布计划”分门别类出现在对应条目下。如果模型没有自动调用技能优先检查你 CLI 工具的技能加载命令是否正确以及 SKILL.md 里的 description 是否明确覆盖了“生成周报”这一场景。6. 综合示例用 Agent Skills 辅助人文社科论文写作前面做的是最小示例下面结合一个更贴近真实场景的案例用 Agent Skills 辅助人文社科混合研究方法论文写作。这个热词最近讨论度很高也确实是 Skill 能发挥作用的典型场景。人文社科论文不是“让 AI 写论文”而是让 AI 承担文献整理、方法矩阵对比、结构检查等重复性工作学者保留研究设计和最终判断。6.1 场景痛点一位做混合研究方法问卷 访谈 文本分析的研究生通常会遇到文献笔记分散在多个文档难以整理成综述。研究方法部分需要说明“定量和定性如何融合”但逻辑每次都不一样。论文结构需要符合期刊格式反复修改耗费大量时间。这些任务有一个共同点它们有相对稳定的流程和标准但每次都占用大量人工时间。这正是技能包最适合解决的。6.2 技能包目录结构skills/ └── mixed-methods-writing/ ├── SKILL.md ├── templates/ │ ├── literature-review-template.md │ └── methods-section-template.md └── scripts/ ├── organize_notes.py └── build_method_matrix.py6.3 编写 SKILL.md文件路径skills/mixed-methods-writing/SKILL.md--- name: mixed-methods-writing description: 辅助人文社科混合研究方法论文写作。当用户需要整理文献综述、设计混合研究方法矩阵、生成研究方法章节结构时使用。 --- # 混合研究方法论文写作技能 本技能面向使用问卷、访谈、文本分析等混合研究方法的学术写作者。 ## 适用任务 1. 文献笔记整理将零散笔记转化为结构化的文献综述素材。 2. 方法矩阵生成对比定量与定性方法在研究中的角色。 3. 研究方法章节起草生成包含数据来源、样本、分析策略的章节框架。 ## 执行步骤 ### 当用户要求整理文献笔记时 1. 调用 scripts/organize_notes.py传入用户提供的笔记原始文本。 2. 脚本输出按主题分组的关键信息。 3. 使用 templates/literature-review-template.md 组织输出。 4. 保留原文献中的作者、年份、核心观点不要改写原有学术表述。 ### 当用户要求生成方法矩阵时 1. 调用 scripts/build_method_matrix.py传入研究方法名称列表。 2. 脚本输出研究阶段、数据来源、分析方法、优劣势对比。 3. 在输出中明确指出该研究采用混合设计的衔接逻辑。 ## 注意事项 - 本技能不负责生成研究结论只负责辅助写作过程。 - 所有引用文献信息必须基于用户提供的内容不得编造文献。 - 如果用户的输入缺少样本量或数据来源信息输出中应保留占位符并提示用户补充。6.4 文献整理脚本文件路径skills/mixed-methods-writing/scripts/organize_notes.py#!/usr/bin/env python3 将笔记按主题分组的轻量脚本。 import sys import re from collections import defaultdict def organize(raw: str) - dict[str, list[str]]: groups defaultdict(list) # 按“主题: 内容”的行格式解析 for line in raw.splitlines(): line line.strip() if not line: continue match re.match(r^(.*?)[:](.*)$, line) if match: topic, content match.group(1).strip(), match.group(2).strip() groups[topic].append(content) else: groups[未分类].append(line) return groups if __name__ __main__: text sys.stdin.read() groups organize(text) for topic, items in groups.items(): print(f## {topic}) for item in items: print(f- {item})6.5 方法矩阵生成脚本文件路径skills/mixed-methods-writing/scripts/build_method_matrix.py#!/usr/bin/env python3 生成混合研究方法对比矩阵。 import sys import json METHOD_INFO { 问卷: { 阶段: 量化数据收集, 优势: 可批量获取数据支持统计检验, 局限: 难以深入理解行为和动机, }, 访谈: { 阶段: 质性数据收集, 优势: 可深入理解个案经验与意义建构, 局限: 样本量有限结果外推受限, }, 文本分析: { 阶段: 质性/量化均可, 优势: 适合分析政策、媒体、档案等已有材料, 局限: 对编码一致性要求高, }, } def build(methods: list[str]) - str: lines [| 研究方法 | 所处阶段 | 核心优势 | 主要局限 |, | --- | --- | --- | --- |] for m in methods: info METHOD_INFO.get(m) if info: lines.append(f| {m} | {info[阶段]} | {info[优势]} | {info[局限]} |) else: lines.append(f| {m} | 待补充 | 待补充 | 待补充 |) return \n.join(lines) if __name__ __main__: methods json.loads(sys.stdin.read()) print(build(methods))这两个脚本都不依赖第三方库可以直接运行验证python3 scripts/organize_notes.py EOF 研究方法: 本文采用问卷调查法收集量化数据 研究方法: 半结构化访谈用于理解用户深层动机 理论框架: 基于计划行为理论 EOF python3 scripts/build_method_matrix.py EOF [问卷, 访谈, 文本分析] EOF6.6 接入 Agent 并调用把技能包加载到工具链claude --add-skill ./skills/mixed-methods-writing然后在对话中请求用户帮我整理下面这些文献笔记并生成一个混合研究方法的对比矩阵。我的研究方法包括问卷调查、半结构化访谈和文本分析。 笔记 研究方法: 问卷调查用于测量用户使用意愿 理论框架: 技术接受模型 访谈: 8位深度访谈分析用户使用障碍 文本分析: 分析20篇在线评论预期输出包含两部分第一部分是按主题整理的文献笔记第二部分是包含“问卷 / 访谈 / 文本分析”三行的方法矩阵表格。技能内的脚本负责结构化模型负责把结构化结果组织成符合学术写作习惯的文本。6.7 运行结果判断标准判断技能是否生效有三个标志脚本被调用执行日志中能看到organize_notes.py或build_method_matrix.py的运行记录。输出符合模板结构不是自由发挥的散文而是有标题、表格、分类的结构化内容。文献信息未被篡改作者、年份、关键观点与输入一致。如果模型没有调用脚本而是直接生成结果说明 SKILL.md 的 description 或正文引导还不够明确需要进一步细化触发条件。7. 常见问题与排查思路问题现象可能原因排查方式解决方案模型始终不调用 Skilldescription 写得过于宽泛或与任务场景不匹配检查 SKILL.md 的 description 是否包含明确的触发词改成“当用户需要……时使用”的句式覆盖更多同义表达SKILL.md 加载报错YAML frontmatter 格式错误查看启动日志或加载提示用 YAML 校验工具检查 name、description 字段格式脚本没有被执行脚本缺少执行权限或 shebang 错误查看脚本执行日志添加#!/usr/bin/env python3并执行chmod x script.py脚本运行时报依赖缺失脚本使用了第三方库但未声明直接在终端运行脚本复现错误在 SKILL.md 正文中写明依赖或使用标准库重写脚本输出内容编造文献模型没有严格遵循“只使用输入信息”约束检查正文是否包含“不得编造”的明确要求在 SKILL.md 注意事项中加入强约束语句技能在某些上下文中失效Skill 加载了但上下文被长对话挤占观察日志确认模型是否还能看到技能描述缩短对话长度或把关键说明重新强调给模型同一个技能在不同框架表现不一致各框架对 SKILL.md 字段支持程度不同查阅对应框架的技能格式文档按实际使用的框架调整元信息字段排查时记住一个原则先确认技能描述是否进入上下文再确认脚本能否独立运行最后才怀疑模型理解能力。大多数问题出在前两步。8. 最佳实践与工程建议8.1 命名与描述技能命名要短、唯一、表达领域特征例如weekly-report、academic-writing、customer-complaint-handling。description 是最重要的元信息。它面向模型不面向人。写法上建议包含三要素适用对象这个技能为谁服务。触发场景用户提出什么类型的问题时该使用。输出目标最终产出的结果是什么。错误示例description: 一个生成报告的工具正确示例description: 当用户需要把零散工作记录整理成周报、例会纪要或项目进展汇报时使用。输出结构化 Markdown 文档按完成事项、项目进展、风险、下周计划分类。8.2 脚本安全与权限技能包里的脚本会以当前用户权限运行必须遵守最小权限原则不把 API 密钥、数据库密码硬编码进技能包。脚本只处理为了完成任务所需的数据。需要访问外部系统时通过环境变量或安全配置注入凭证。对删除、覆盖、写数据库等高风险操作脚本里必须加入确认参数和回滚机制。生产环境里技能包也应该像代码一样做代码评审。不要因为“只是给模型读的”就跳过安全检查。8.3 版本管理与测试技能包可以看作一种特殊代码资产推荐用 Git 管理。目录结构固定、变更频率高的场景可以拆出技能仓库团队内部共享。测试策略可以参考接口测试的思路每个技能准备 2~3 条典型输入验证输出是否稳定。脚本用单元测试覆盖边界情况例如空输入、超长输入、特殊字符。每次修改 SKILL.md 的 description 后都要重新验证模型是否能在正确场景下调用。8.4 与 MCP 结合的生产路径如果你的技能需要访问内部业务系统更稳妥的方式是把业务系统的数据访问逻辑封装成 MCP Server。Skill 的脚本通过 MCP 协议调用该服务。SKILL.md 只负责描述领域流程不承担复杂系统对接。这样做的好处是边界清晰Skill 管方法和流程MCP 管连接和协议模型管理解和决策。8.5 日志与可观测性模型调用技能的过程不是黑盒。建议在技能执行的关键节点打印日志模型决定调用技能的一刻。脚本开始执行的参数。脚本执行结果的状态码。最终输出的长度和结构摘要。这些日志既是排查依据也是评估技能质量的长期数据来源。通过观察“哪些技能被高频调用”“哪些技能经常失败”可以持续优化技能库。9. 总结与后续学习方向这篇博客把 Agent Skills 拆成了三个层面来理解第一它是一种工程组织方式把知识、脚本、流程封装成模型可加载的文件包解决的是能力复用问题。 第二它和 Tool、MCP 不是竞争关系而是不同层级的分工Tool 管接口MCP 管连接Skill 管领域能力封装。 第三它的实践起点并不高写一个 SKILL.md、配一个脚本、用 CLI 加载就能跑通第一个最小技能。如果你接下来要继续深入可以从这几个方向走阅读你正在使用的 Agent 框架对 Skill 格式的官方文档弄清字段差异。把自己工作中重复三次以上的任务先做一个 10 行的最小技能包。学习 MCP 的基础协议把技能接到真实业务系统上。参考社区里高质量技能包的 SKILL.md 写法看别人如何设计 description 和执行步骤。最后提醒一句先做小、先做窄、先保证一批输入输出稳定再扩展技能范围。真正有效的 Agent Skills 不是设计出来的是在一次次真实任务调用和修复中迭代出来的。建议把本文示例保存下来作为你搭建第一个技能包的起点动手试一次比读十篇概念讲解都有用。 Agent Skills深度解析：构建可复用的大模型技能包与工作流
2026 年谈大模型应用最值得开发者关注的早已不是“哪个模型参数更多”而是“怎么让模型在真实工作流里稳定地创造价值”。Agent Skills 就是在这个节点上被反复提起的概念。你对它可能有两种模糊印象要么觉得它只是“提示词工程的又一种包装”要么觉得它是某个大厂新推出的神秘框架。这两种理解都不太准确。这篇博客会把 Agent Skills 从头拆到尾它到底是什么、和 Agent、Tool、MCP 有什么区别、怎么动手定义一个可用的技能包、怎么在论文写作这类真实场景里落地。整篇文章以“能跑通最小示例”为目标最后会给你一份可以直接收藏的排查清单和工程建议。1. 这篇文章真正要解决的问题先从一个很普遍的困扰说起。假设你要让大模型帮你做行业研究报告。你精心写了一段提示词要求它按“背景—现状—数据—结论—建议”的结构输出。第一次效果不错第二次模型自由发挥把结构改成了四段式第三次连数据口径都变了。你不得不反复调整提示词甚至把历史对话一次次重发。这就是当前大模型应用最大的痛点模型很强但对“你的任务、你的流程、你的标准”没有稳定的记忆。提示词能解决单次任务却解决不了“能力复用”。换个项目、换个团队成员、换一次编程模型上下文窗口刷新所有经验又要重新灌输一遍。Agent Skills 要解决的核心问题正是把“一套解决某一类问题的知识、流程和脚本”固化成模型可以按需加载的文件包。它不是玄学也不依赖某个特定模型而是一种工程组织方式。读完这篇文章你可以做到三件事写出第一个符合规范的 SKILL.md 文件。配套一个可执行的辅助脚本形成完整的技能包。把技能包加载到 Agent 工具链里跑通一次完整调用并知道失败时去排查哪里。2. Agent Skills 是什么与 Agent、Tool、MCP 的关系2.1 概念定义Agent Skills 目前没有一个全球统一的“标准”但主流实现例如 Anthropic 提出的 Claude Skills 模式以及多个开源 Agent 框架的吸收方案都在朝同一个方向收敛Agent Skills 是一种以自然语言描述SKILL.md加辅助脚本/资源文件为载体的“领域能力包”。拆开看它可以理解为两个部分技能说明书一段人类可读、模型可解析的描述告诉模型这个技能解决什么问题、适合什么场景、怎么使用。技能实现物一个或多个脚本、模板、数据文件真正承担执行任务。为什么是这种形态因为大模型本身不适合记忆大量固定逻辑但非常擅长“读懂说明并调用工具”。SKILL.md 就是把“怎么做”的决策逻辑写在明面上让模型照着执行而不是每次靠随机发挥。2.2 与 Tool 的区别很多教程里Agent Skills 和 Tool 经常混着讲但它们解决的问题层级不同。Tool 是一个功能函数解决“模型能做什么”。例如get_weather(city)、search_web(keyword)单个工具只完成一次外部交互。Skill 是一个领域能力包解决“模型能做好什么”。它可能包含多个工具、多段知识说明、一套流程编排。用一个生活类比螺丝刀、扳手、电钻是 Tool而“修理厨房水龙头”是一套 Skill。这个技能不仅包括该用哪些工具还包括关水阀、拆旧件、缠生料带、按顺序装回的步骤和注意事项。技术语境里维度ToolAgent Skill粒度单个函数/API一组知识、脚本、流程的组合核心内容接口定义与执行逻辑领域流程、规范、示例、资源解决目标扩展模型的外部操作能力让模型在特定领域内稳定高质量工作是否依赖模型理解弱参数传给函数即可强模型需要理解描述并按流程执行典型示例查询天气、发送邮件、执行 SQL写学术论文、做竞品分析、生成营销方案简单理解一个 Skill 可以“包含”工具的调用也可以完全不调用工具只提供领域知识和步骤约束。2.3 与 MCP 的关系MCPModel Context Protocol是另一个绕不开的词。它解决的是“模型连接外部工具的标准接口问题”相当于工具生态的 USB-C 接口标准。Agent Skills 和 MCP 并不冲突而是两个层面的东西MCP 关注“连接”让模型与外部数据源、系统通过统一协议交互。Agent Skills 关注“能力封装”把解决某类问题需要的方法、知识、流程、脚本打包。实际工程里两者往往组合使用Skill 负责告诉模型“这个领域的任务该怎么拆、按什么标准做”MCP 负责在真正需要查询数据库、调用业务系统时提供标准接口。2.4 一个小结论可以把 Agent Skills 理解成一个“可加载的专业知识包”。模型是通用大脑Skill 是大脑外接的专科模块。大脑本身不需要重新训练换一个专科模块就能处理新领域的复杂任务。3. 为什么 Agent Skills 在 2026 年会被反复提起吴恩达Andrew Ng近两年在公开课和演讲中反复强调一个判断大模型价值落地的关键越来越取决于 Agent 工作流而不只是模型本身。虽然不能把 Agent Skills 完全归功于某一个人但它确实是这一思路走向工程化后的产物。为什么是 2026 年这个时间点被反复讨论我的判断是三个驱动力同时到位了。3.1 工具调用机制普及Function Calling 已经成为主流模型的标配能力。模型不仅能生成文本还能输出结构化的函数调用请求。这意味着“给模型一个脚本去执行”的技术门槛已经消失。Skill 的概念在被大规模使用前底层条件已经成熟。3.2 Agent 工作流从 Demo 走向生产早期 Agent 应用大多停留在“多轮对话 搜索”的演示阶段。但实际业务场景需要的不是对话而是稳定产出每天生成固定的数据报告、按公司标准撰写售前方案、批量整理客户访谈纪要。这类需求要求能力高度可复用、可复制Skill 这种“打包 加载”的形态天然匹配。3.3 团队知识复用成为刚需过去团队里的领域经验靠文档、培训、口口相传。现在已经有团队开始把“老师傅怎么处理客户投诉”“资深分析师怎么写行业研报”整理成技能包让模型和新人共同使用。这是知识管理方式的一次重要变化知识第一次可以直接变成可执行、可调用、可版本化的生产工具。所以你会发现Agent Skills 的真正价值不在技术复杂度而在于它把“知识”从人的脑子里抽出来变成了团队资产的组成部分。SKILL.md 是知识脚本是知识模板也是知识。知识有了版本、有了可用性测试、有了迭代流程。4. Agent Skills 的核心架构与设计思路4.1 核心结构一个典型的 Agent Skill 结构大致如下skills/ └── research-report/ ├── SKILL.md ├── templates/ │ └── report_template.md └── scripts/ ├── collect_data.py └── generate_chart.py目录名是技能标识SKILL.md 是入口附属目录存放执行所需的脚本和资源。4.2 SKILL.md 的关键字段不同框架的 SKILL.md 格式略有差异但通常会在文件开头使用 YAML frontmatter 写元信息--- name: research-report description: 用于生成行业研究报告。当用户需要市场分析、竞品研究、行业趋势整理时使用。 --- !-- 这里写技能的具体使用说明、步骤、注意事项 --两个关键字段name技能名称必须唯一且语义清晰。description技能描述这是模型判断“何时调用该技能”的核心依据必须写清楚触发场景而不是只写“这是研究助手”。正文部分的写法也很重要。模型会读取正文来理解执行方式所以正文应当清晰包含这个技能解决什么问题。执行步骤是什么。有哪些注意事项。是否依赖某些脚本脚本调用顺序是什么。4.3 模型如何“加载”一个 Skill流程通常是这样的启动 Agent 会话时系统扫描技能目录把每个技能的 name 和 description 注入上下文。模型根据用户问题时判断是否匹配某个技能描述。如果匹配模型读取该技能目录下的 SKILL.md 正文理解具体步骤。模型按说明执行必要时调用 scripts 下的脚本工具。这意味着description 写得太泛模型不会主动调用。正文写得太模糊模型执行结果不稳定。脚本本身有问题模型再聪明也无法产出正确结果。所以设计和调试 Skill 的核心工作本质是“把隐性的领域知识显性化”。4.4 设计原则三个原则值得牢记单一职责一个技能只解决一类问题。不要做一个“万能助手”技能。描述场景化description 里写“当用户需要……时使用”而不是写“我是一个助手”。执行可验证附带的脚本应当能独立运行并返回明确结果不要把关键逻辑依赖在模型的自由发挥上。5. 动手实现从零定义一个可用的 Agent Skill下面我们抛开抽象概念直接创建一个最小可用技能包。目标是让模型学会“用给定模板整理工作周报”。5.1 环境准备操作系统Linux、macOS 或 WindowsWindows 建议使用 WSL 或 Git Bash。Python3.10 或更高版本。一个支持 Skill 机制的 Agent 工具或框架。演示中使用支持--add-skill方式的 CLI 工具不同版本命令可能略有差异思路一致。文本编辑器建议使用 VS Code方便直接查看 Markdown 和脚本文件。5.2 创建技能目录mkdir -p skills/weekly-report/templates mkdir -p skills/weekly-report/scripts cd skills/weekly-report5.3 编写 SKILL.md文件路径skills/weekly-report/SKILL.md--- name: weekly-report description: 生成工作周报。当用户需要总结本周工作、整理产出清单、汇报项目进展时使用。输入需要包含本周完成事项的原始描述或备注。 --- # 工作周报技能 使用本技能可以将用户提供的零散工作记录整理成结构清晰的周报。 ## 执行步骤 1. 阅读用户提供的本周工作记录。 2. 将记录按以下分类整理 - 本周完成 - 项目进展 - 问题与风险 - 下周计划 3. 使用 templates/weekly-report-template.md 中的结构输出。 4. 输出时把原始记录中的模糊表达改写为更清晰的业务语言但不要编造用户没有提到的事实。 ## 注意事项 - 如果用户没有提供任何工作记录先询问不要自动编造内容。 - 每个分类不超过 5 条要点。 - 对涉及数字、日期、项目名称的内容保持原样不要自行修改。5.4 创建周报模板文件路径skills/weekly-report/templates/weekly-report-template.md## 本周工作周报 ### 本周完成 - ### 项目进展 - ### 问题与风险 - ### 下周计划 -5.5 添加辅助脚本为了展示“脚本 Skill”如何配合我们再添加一个关键词提取脚本。当用户提供的工作记录是长文本时脚本负责提取候选关键词模型再根据关键词组织周报。文件路径skills/weekly-report/scripts/extract_keywords.py#!/usr/bin/env python3 从工作记录文本中提取候选关键词。 import re import sys from collections import Counter def extract(text: str, top_n: int 10) - list[str]: words re.findall(r[\u4e00-\u9fffA-Za-z0-9], text) counter Counter(w for w in words if len(w) 1) return [w for w, _ in counter.most_common(top_n)] if __name__ __main__: input_text sys.stdin.read() if not input_text.strip(): print() else: print(\n.join(extract(input_text)))这个脚本不做任何复杂 AI 推理只负责从文本里提取高频词降低模型理解长文本时的负担。真正的工作流是模型读取文本调用脚本得到关键词再结合模板生成周报。5.6 加载技能并验证在支持 Skill 机制的 CLI 工具中加载方式一般类似claude --add-skill ./skills/weekly-report启动后可以这样测试用户这周我做了三件事重构用户登录模块修复了订单支付超时问题准备了下周的灰度发布计划。帮我生成工作周报。预期输出应当按照模板结构生成并且“修改用户登录模块”“修复支付超时”“灰度发布计划”分门别类出现在对应条目下。如果模型没有自动调用技能优先检查你 CLI 工具的技能加载命令是否正确以及 SKILL.md 里的 description 是否明确覆盖了“生成周报”这一场景。6. 综合示例用 Agent Skills 辅助人文社科论文写作前面做的是最小示例下面结合一个更贴近真实场景的案例用 Agent Skills 辅助人文社科混合研究方法论文写作。这个热词最近讨论度很高也确实是 Skill 能发挥作用的典型场景。人文社科论文不是“让 AI 写论文”而是让 AI 承担文献整理、方法矩阵对比、结构检查等重复性工作学者保留研究设计和最终判断。6.1 场景痛点一位做混合研究方法问卷 访谈 文本分析的研究生通常会遇到文献笔记分散在多个文档难以整理成综述。研究方法部分需要说明“定量和定性如何融合”但逻辑每次都不一样。论文结构需要符合期刊格式反复修改耗费大量时间。这些任务有一个共同点它们有相对稳定的流程和标准但每次都占用大量人工时间。这正是技能包最适合解决的。6.2 技能包目录结构skills/ └── mixed-methods-writing/ ├── SKILL.md ├── templates/ │ ├── literature-review-template.md │ └── methods-section-template.md └── scripts/ ├── organize_notes.py └── build_method_matrix.py6.3 编写 SKILL.md文件路径skills/mixed-methods-writing/SKILL.md--- name: mixed-methods-writing description: 辅助人文社科混合研究方法论文写作。当用户需要整理文献综述、设计混合研究方法矩阵、生成研究方法章节结构时使用。 --- # 混合研究方法论文写作技能 本技能面向使用问卷、访谈、文本分析等混合研究方法的学术写作者。 ## 适用任务 1. 文献笔记整理将零散笔记转化为结构化的文献综述素材。 2. 方法矩阵生成对比定量与定性方法在研究中的角色。 3. 研究方法章节起草生成包含数据来源、样本、分析策略的章节框架。 ## 执行步骤 ### 当用户要求整理文献笔记时 1. 调用 scripts/organize_notes.py传入用户提供的笔记原始文本。 2. 脚本输出按主题分组的关键信息。 3. 使用 templates/literature-review-template.md 组织输出。 4. 保留原文献中的作者、年份、核心观点不要改写原有学术表述。 ### 当用户要求生成方法矩阵时 1. 调用 scripts/build_method_matrix.py传入研究方法名称列表。 2. 脚本输出研究阶段、数据来源、分析方法、优劣势对比。 3. 在输出中明确指出该研究采用混合设计的衔接逻辑。 ## 注意事项 - 本技能不负责生成研究结论只负责辅助写作过程。 - 所有引用文献信息必须基于用户提供的内容不得编造文献。 - 如果用户的输入缺少样本量或数据来源信息输出中应保留占位符并提示用户补充。6.4 文献整理脚本文件路径skills/mixed-methods-writing/scripts/organize_notes.py#!/usr/bin/env python3 将笔记按主题分组的轻量脚本。 import sys import re from collections import defaultdict def organize(raw: str) - dict[str, list[str]]: groups defaultdict(list) # 按“主题: 内容”的行格式解析 for line in raw.splitlines(): line line.strip() if not line: continue match re.match(r^(.*?)[:](.*)$, line) if match: topic, content match.group(1).strip(), match.group(2).strip() groups[topic].append(content) else: groups[未分类].append(line) return groups if __name__ __main__: text sys.stdin.read() groups organize(text) for topic, items in groups.items(): print(f## {topic}) for item in items: print(f- {item})6.5 方法矩阵生成脚本文件路径skills/mixed-methods-writing/scripts/build_method_matrix.py#!/usr/bin/env python3 生成混合研究方法对比矩阵。 import sys import json METHOD_INFO { 问卷: { 阶段: 量化数据收集, 优势: 可批量获取数据支持统计检验, 局限: 难以深入理解行为和动机, }, 访谈: { 阶段: 质性数据收集, 优势: 可深入理解个案经验与意义建构, 局限: 样本量有限结果外推受限, }, 文本分析: { 阶段: 质性/量化均可, 优势: 适合分析政策、媒体、档案等已有材料, 局限: 对编码一致性要求高, }, } def build(methods: list[str]) - str: lines [| 研究方法 | 所处阶段 | 核心优势 | 主要局限 |, | --- | --- | --- | --- |] for m in methods: info METHOD_INFO.get(m) if info: lines.append(f| {m} | {info[阶段]} | {info[优势]} | {info[局限]} |) else: lines.append(f| {m} | 待补充 | 待补充 | 待补充 |) return \n.join(lines) if __name__ __main__: methods json.loads(sys.stdin.read()) print(build(methods))这两个脚本都不依赖第三方库可以直接运行验证python3 scripts/organize_notes.py EOF 研究方法: 本文采用问卷调查法收集量化数据 研究方法: 半结构化访谈用于理解用户深层动机 理论框架: 基于计划行为理论 EOF python3 scripts/build_method_matrix.py EOF [问卷, 访谈, 文本分析] EOF6.6 接入 Agent 并调用把技能包加载到工具链claude --add-skill ./skills/mixed-methods-writing然后在对话中请求用户帮我整理下面这些文献笔记并生成一个混合研究方法的对比矩阵。我的研究方法包括问卷调查、半结构化访谈和文本分析。 笔记 研究方法: 问卷调查用于测量用户使用意愿 理论框架: 技术接受模型 访谈: 8位深度访谈分析用户使用障碍 文本分析: 分析20篇在线评论预期输出包含两部分第一部分是按主题整理的文献笔记第二部分是包含“问卷 / 访谈 / 文本分析”三行的方法矩阵表格。技能内的脚本负责结构化模型负责把结构化结果组织成符合学术写作习惯的文本。6.7 运行结果判断标准判断技能是否生效有三个标志脚本被调用执行日志中能看到organize_notes.py或build_method_matrix.py的运行记录。输出符合模板结构不是自由发挥的散文而是有标题、表格、分类的结构化内容。文献信息未被篡改作者、年份、关键观点与输入一致。如果模型没有调用脚本而是直接生成结果说明 SKILL.md 的 description 或正文引导还不够明确需要进一步细化触发条件。7. 常见问题与排查思路问题现象可能原因排查方式解决方案模型始终不调用 Skilldescription 写得过于宽泛或与任务场景不匹配检查 SKILL.md 的 description 是否包含明确的触发词改成“当用户需要……时使用”的句式覆盖更多同义表达SKILL.md 加载报错YAML frontmatter 格式错误查看启动日志或加载提示用 YAML 校验工具检查 name、description 字段格式脚本没有被执行脚本缺少执行权限或 shebang 错误查看脚本执行日志添加#!/usr/bin/env python3并执行chmod x script.py脚本运行时报依赖缺失脚本使用了第三方库但未声明直接在终端运行脚本复现错误在 SKILL.md 正文中写明依赖或使用标准库重写脚本输出内容编造文献模型没有严格遵循“只使用输入信息”约束检查正文是否包含“不得编造”的明确要求在 SKILL.md 注意事项中加入强约束语句技能在某些上下文中失效Skill 加载了但上下文被长对话挤占观察日志确认模型是否还能看到技能描述缩短对话长度或把关键说明重新强调给模型同一个技能在不同框架表现不一致各框架对 SKILL.md 字段支持程度不同查阅对应框架的技能格式文档按实际使用的框架调整元信息字段排查时记住一个原则先确认技能描述是否进入上下文再确认脚本能否独立运行最后才怀疑模型理解能力。大多数问题出在前两步。8. 最佳实践与工程建议8.1 命名与描述技能命名要短、唯一、表达领域特征例如weekly-report、academic-writing、customer-complaint-handling。description 是最重要的元信息。它面向模型不面向人。写法上建议包含三要素适用对象这个技能为谁服务。触发场景用户提出什么类型的问题时该使用。输出目标最终产出的结果是什么。错误示例description: 一个生成报告的工具正确示例description: 当用户需要把零散工作记录整理成周报、例会纪要或项目进展汇报时使用。输出结构化 Markdown 文档按完成事项、项目进展、风险、下周计划分类。8.2 脚本安全与权限技能包里的脚本会以当前用户权限运行必须遵守最小权限原则不把 API 密钥、数据库密码硬编码进技能包。脚本只处理为了完成任务所需的数据。需要访问外部系统时通过环境变量或安全配置注入凭证。对删除、覆盖、写数据库等高风险操作脚本里必须加入确认参数和回滚机制。生产环境里技能包也应该像代码一样做代码评审。不要因为“只是给模型读的”就跳过安全检查。8.3 版本管理与测试技能包可以看作一种特殊代码资产推荐用 Git 管理。目录结构固定、变更频率高的场景可以拆出技能仓库团队内部共享。测试策略可以参考接口测试的思路每个技能准备 2~3 条典型输入验证输出是否稳定。脚本用单元测试覆盖边界情况例如空输入、超长输入、特殊字符。每次修改 SKILL.md 的 description 后都要重新验证模型是否能在正确场景下调用。8.4 与 MCP 结合的生产路径如果你的技能需要访问内部业务系统更稳妥的方式是把业务系统的数据访问逻辑封装成 MCP Server。Skill 的脚本通过 MCP 协议调用该服务。SKILL.md 只负责描述领域流程不承担复杂系统对接。这样做的好处是边界清晰Skill 管方法和流程MCP 管连接和协议模型管理解和决策。8.5 日志与可观测性模型调用技能的过程不是黑盒。建议在技能执行的关键节点打印日志模型决定调用技能的一刻。脚本开始执行的参数。脚本执行结果的状态码。最终输出的长度和结构摘要。这些日志既是排查依据也是评估技能质量的长期数据来源。通过观察“哪些技能被高频调用”“哪些技能经常失败”可以持续优化技能库。9. 总结与后续学习方向这篇博客把 Agent Skills 拆成了三个层面来理解第一它是一种工程组织方式把知识、脚本、流程封装成模型可加载的文件包解决的是能力复用问题。 第二它和 Tool、MCP 不是竞争关系而是不同层级的分工Tool 管接口MCP 管连接Skill 管领域能力封装。 第三它的实践起点并不高写一个 SKILL.md、配一个脚本、用 CLI 加载就能跑通第一个最小技能。如果你接下来要继续深入可以从这几个方向走阅读你正在使用的 Agent 框架对 Skill 格式的官方文档弄清字段差异。把自己工作中重复三次以上的任务先做一个 10 行的最小技能包。学习 MCP 的基础协议把技能接到真实业务系统上。参考社区里高质量技能包的 SKILL.md 写法看别人如何设计 description 和执行步骤。最后提醒一句先做小、先做窄、先保证一批输入输出稳定再扩展技能范围。真正有效的 Agent Skills 不是设计出来的是在一次次真实任务调用和修复中迭代出来的。建议把本文示例保存下来作为你搭建第一个技能包的起点动手试一次比读十篇概念讲解都有用。