企业官网建设流程全解析

2026 年谈大模型应用，最值得开发者关注的早已不是“哪个模型参数更多”，而是“怎么让模型在真实工作流里稳定地创造价值”。Agent Skills 就是在这个节点上被反复提起的概念。你对它可能有两种模糊印象：要么觉得它只是“提示词工程的又一种包装”，要么觉得它是某个大厂新推出的神秘框架。这两种理解都不太准确。

这篇博客会把 Agent Skills 从头拆到尾：它到底是什么、和 Agent、Tool、MCP 有什么区别、怎么动手定义一个可用的技能包、怎么在论文写作这类真实场景里落地。整篇文章以“能跑通最小示例”为目标，最后会给你一份可以直接收藏的排查清单和工程建议。

1. 这篇文章真正要解决的问题

先从一个很普遍的困扰说起。

假设你要让大模型帮你做行业研究报告。你精心写了一段提示词，要求它按“背景—现状—数据—结论—建议”的结构输出。第一次效果不错，第二次模型自由发挥，把结构改成了四段式，第三次连数据口径都变了。你不得不反复调整提示词，甚至把历史对话一次次重发。

这就是当前大模型应用最大的痛点：模型很强，但对“你的任务、你的流程、你的标准”没有稳定的记忆。

提示词能解决单次任务，却解决不了“能力复用”。换个项目、换个团队成员、换一次编程模型上下文窗口刷新，所有经验又要重新灌输一遍。

Agent Skills 要解决的核心问题，正是把“一套解决某一类问题的知识、流程和脚本”固化成模型可以按需加载的文件包。它不是玄学，也不依赖某个特定模型，而是一种工程组织方式。

读完这篇文章，你可以做到三件事：

1. 写出第一个符合规范的 SKILL.md 文件。
2. 配套一个可执行的辅助脚本，形成完整的技能包。
3. 把技能包加载到 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。这个技能不仅包括该用哪些工具，还包括关水阀、拆旧件、缠生料带、按顺序装回的步骤和注意事项。

技术语境里：

简单理解：一个 Skill 可以“包含”工具的调用，也可以完全不调用工具，只提供领域知识和步骤约束。

2.3 与 MCP 的关系

MCP（Model 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

流程通常是这样的：

1. 启动 Agent 会话时，系统扫描技能目录，把每个技能的 name 和 description 注入上下文。
2. 模型根据用户问题时，判断是否匹配某个技能描述。
3. 如果匹配，模型读取该技能目录下的 SKILL.md 正文，理解具体步骤。
4. 模型按说明执行，必要时调用 scripts 下的脚本工具。

这意味着：

• description 写得太泛，模型不会主动调用。
• 正文写得太模糊，模型执行结果不稳定。
• 脚本本身有问题，模型再聪明也无法产出正确结果。

所以设计和调试 Skill 的核心工作，本质是“把隐性的领域知识显性化”。

4.4 设计原则

三个原则值得牢记：

1. 单一职责：一个技能只解决一类问题。不要做一个“万能助手”技能。
2. 描述场景化：description 里写“当用户需要……时使用”，而不是写“我是一个助手”。
3. 执行可验证：附带的脚本应当能独立运行并返回明确结果，不要把关键逻辑依赖在模型的自由发挥上。

5. 动手实现：从零定义一个可用的 Agent Skill

下面我们抛开抽象概念，直接创建一个最小可用技能包。目标是让模型学会“用给定模板整理工作周报”。

5.1 环境准备

• 操作系统：Linux、macOS 或 Windows（Windows 建议使用 WSL 或 Git Bash）。
• Python：3.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-report

5.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.py

6.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 ["问卷", "访谈", "文本分析"] EOF

6.6 接入 Agent 并调用

把技能包加载到工具链：

claude --add-skill ./skills/mixed-methods-writing

然后在对话中请求：

用户：帮我整理下面这些文献笔记，并生成一个混合研究方法的对比矩阵。我的研究方法包括问卷调查、半结构化访谈和文本分析。 笔记： 研究方法: 问卷调查用于测量用户使用意愿 理论框架: 技术接受模型 访谈: 8位深度访谈，分析用户使用障碍 文本分析: 分析20篇在线评论

预期输出包含两部分：第一部分是按主题整理的文献笔记，第二部分是包含“问卷 / 访谈 / 文本分析”三行的方法矩阵表格。技能内的脚本负责结构化，模型负责把结构化结果组织成符合学术写作习惯的文本。

6.7 运行结果判断标准

判断技能是否生效，有三个标志：

1. 脚本被调用：执行日志中能看到organize_notes.py或build_method_matrix.py的运行记录。
2. 输出符合模板结构：不是自由发挥的散文，而是有标题、表格、分类的结构化内容。
3. 文献信息未被篡改：作者、年份、关键观点与输入一致。

如果模型没有调用脚本而是直接生成结果，说明 SKILL.md 的 description 或正文引导还不够明确，需要进一步细化触发条件。

7. 常见问题与排查思路

排查时记住一个原则：先确认技能描述是否进入上下文，再确认脚本能否独立运行，最后才怀疑模型理解能力。大多数问题出在前两步。

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 结合的生产路径

如果你的技能需要访问内部业务系统，更稳妥的方式是：

1. 把业务系统的数据访问逻辑封装成 MCP Server。
2. Skill 的脚本通过 MCP 协议调用该服务。
3. 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 不是设计出来的，是在一次次真实任务调用和修复中迭代出来的。建议把本文示例保存下来，作为你搭建第一个技能包的起点，动手试一次，比读十篇概念讲解都有用。