什么？有人手写 Skill？Agent Skill？Skill？文章摘要本文探讨了AI领域中Skill与Agent S

什么？有人手写 Skill？Agent Skill？Skill？

作者：吴佳浩

撰稿时间：2026-05-27

*** 为什么要写下面的内容呢？其实就是一些。。。算了你懂的。以下内容如果有疑议，就是你对👍 ***

引言

最近很多人在聊 Skill、Agent Skill、Workflow。

但你会发现，大多数人其实没搞清一件事：

Skill 到底是什么？
Agent Skill 又是什么？

甚至还有人：

把 Prompt 当 Skill
把 Tool 当 Agent
把 Workflow 当函数

结果就是：Agent 越做越乱。

下面把这两个概念说清楚，再给你一份今天就能落地的设计方法。

一、先看一个真实的 Agent Skill 长什么样

光说概念容易绕。先看具体的东西。

下面是一个双语技术报告生成的 Agent Skill 配置：

# Agent Skill: 双语技术报告生成
# L1 层：仅加载以下元数据
name: bilingual_tech_report
description: 当用户上传技术文档并要求生成中英双语报告时触发
trigger:
  intent: generate_bilingual_report
  entities: [document, target_lang="zh-en"]

# L2 层：触发后加载完整 Workflow
workflow:
  step_1_ocr:
    name: ocr_extract
    tool: ocr_engine
    input: "{{ upload.document }}"
    output: raw_text
    fallback: "若 OCR 失败，提示用户更换清晰扫描件"

  step_2_parse:
    name: structure_analysis
    skill: doc_parser          # 调用另一个原子 Skill
    input: "{{ raw_text }}"
    output: sections[]

  step_3_translate:
    name: batch_translate
    tool: translate_api
    foreach: "{{ sections }}"
    retry: 2                   # 失败自动重试
    fallback: "保留原文并标记 [待人工翻译]"
    memory_read: [user_glossary] # 读取用户历史术语偏好

  step_4_report:
    name: generate_docx
    skill: report_formatter
    input: "{{ translated_sections }}"
    memory_read: [user_style_pref]
    output: final_docx

# L3 层：执行到对应步骤时才加载
resources:
  doc_parser: /skills/doc_parser/v2/
  report_formatter: /skills/report/v3/
  assets: /assets/templates/tech_report.docx

注意四个细节：

① fallback 在每一步都有。 不是全局兜底，是每个节点单独处理。OCR 挂了怎么办、翻译超时怎么办，各管各的。

② memory_read 是动态注入的。 用户的术语偏好、排版风格，在需要的那一步才读进来，不是一开始就塞进上下文。

③ 三层加载结构（L1/L2/L3）。 L1 只告诉模型"我有什么能力"，L2 在真正触发时才加载完整 Workflow，L3 的资源文件在执行到对应步骤时才加载。

④ Agent Skill 编排原子 Skill，但不替代它们。 Workflow 里调用的 doc_parser 和 report_formatter 是独立的原子 Skill。Agent Skill 的核心不是"做翻译"或"做排版"，而是"知道什么时候调用谁、调用后怎么处理结果"。它是编排者，不是执行者。

这四点，决定了这个配置不是一个 Prompt，而是一个可调度、可重试、可组合的执行系统。

二、Skill 是什么？

一句话：

Skill 是"会做什么"。

Skill	本质
OCR Skill	识别图片文字
Translate Skill	翻译
SQL Skill	生成 SQL
Search Skill	搜索资料
Report Skill	生成报告

本质是原子能力。像一个函数：

graph LR
A[输入] --> B[Skill]
B --> C[输出]

在设计哲学上：无状态、单步骤、不具备调度能力、不具备自治能力。

选型参考：什么时候用什么？

不是所有场景都需要 Agent Skill。按复杂度选：

Prompt：一次性任务，不需要复用，没有失败处理需求
原子 Skill：单步骤、无状态、输入输出明确，需要被多处复用
Agent Skill：多步骤编排、需要调度 Tool、有失败处理、需要记忆上下文

不要过度设计。 能用一个 Prompt 解决的，不要硬拆成 Workflow。

三、Agent Skill 是什么？

一句话：

Agent Skill 是"什么时候做、怎么做、调用什么做、最后怎么收尾"。

它不只是：

会翻译

而是：

什么时候翻译
怎么翻译
调用什么工具
分几步执行
失败怎么处理
最后输出什么

四、最核心的区别

对比	Skill	Agent Skill
本质	单能力	行为系统
结构	Prompt	Workflow
是否有调度	没有	有
是否有 Tool	不一定	基本都有
是否有状态	通常没有	经常有
是否自治	很弱	较强
是否支持多步骤	很少	核心能力
是否可组合	一般	非常强

五、最直观的理解

普通 Skill

一个员工会翻译

Agent Skill

一整套部门流程：

接需求
↓
OCR
↓
结构分析
↓
翻译
↓
生成双语报告
↓
导出 DOCX

已经不是一个 Prompt 了。

六、为什么大家开始放弃手写 Prompt

传统 Prompt 有一个根本问题：

Context Explosion

所有规则一次性塞进上下文

会导致：

Token 爆炸
注意力分散
Tool 选择混乱
长任务崩溃

七、为什么渐进式加载能解决 Context Explosion

传统 Prompt 的崩溃根源在于：上下文长度和系统复杂度成正比。

系统里有 20 个 Skill、50 个 Tool、几百条规则，全塞进一条 Prompt，Token 随规模线性膨胀，模型注意力被稀释，Tool 选择准确率下降，长任务直接崩溃。

L1/L2/L3 的解法是：上下文长度只和"当前激活的步骤"相关，和整个系统的复杂度无关。

graph TD
A[L1 目录层] --> B[L2 Skill 层]
B --> C[L3 资源层]

无论你的 Agent 系统有多少个 Skill，当前这一步只需要加载当前这一步的 Prompt、Tool 描述和必要资源。其他 Skill 的名字只在 L1 目录里占一行 YAML，不进入上下文。

Token 成本大幅下降，注意力集中在当前步骤。

八、一个常见的错误

"我写了一个超长 Prompt，里面告诉模型'你要先搜索，再总结，最后生成报告'，这就是我的 Search-Agent-Skill。"

这只是一个 Prompt。

真正的 Search Agent Skill 应该包含：

意图识别：判断当前请求是否需要搜索
搜索策略：用 Google？用内部知识库？用 SQL？
结果评估：搜到的内容是否足够、是否可信
循环控制：不够就换关键词再搜，或换数据源
输出格式化：按用户偏好输出表格/段落/报告

九、真正高级的 Agent Skill 已经拥有什么

一个高阶 Agent Skill 的执行闭环：

graph TD
A[Goal] --> B[Planning]
B --> C[Tool Use]
C --> D[Reflection]
D --> E[Retry]
E --> F[Final Result]

支撑这个闭环的模块包括：Tool Runtime、Memory、Workflow、Planning、Reflection、Evaluation、Retry、Context Management。

这时候它已经越来越接近小型自治 Agent。

十、行业演化方向

graph LR
A[Prompt] --> B[Skill]
B --> C[Agent Skill]
C --> D[Workflow]
D --> E[Agent Runtime]
D --> F[Agent OS]

现代 AI 工程的完整路径：

graph TD
A[Prompt Engineering] --> B[Skill Engineering]
B --> C[Workflow Engineering]
C --> D[Agent Engineering]
D --> E[Agent OS]

主流厂商的方向对比：

公司	方向	典型特征
OpenAI	GPTs / Tool Runtime	低代码配置即 Skill，强调 Tool 调用生态
Anthropic	Claude Skills / Computer Use	运行时自治，强调模型自主规划
Google	ADK Skills	与 Google 生态深度集成，多 Agent 协作
Microsoft	Copilot Extensions	企业场景优先，与 Office/Teams 结合
阿里	Agent Skill	电商与办公场景落地，强调业务闭环

方向不同，但底层逻辑一致：都在做 Agent Capability Runtime。

十一、今天就能用的设计清单（说一万遍不如自己试一遍，动手试试看童鞋门，筒子门）

如果你现在要设计一个 Agent Skill，按这六步走：

** 先画边界** 这个 Skill 解决什么问题？不解决什么问题？防止能力膨胀。

** 再拆步骤** 把流程拆成不可再分的原子动作，每一个对应一个 Skill 层。

** 设计触发器** 什么用户意图、什么上下文、什么前置条件，才激活这个 Skill？

** 预留逃生舱** 每一步都问自己：Tool 挂了怎么办？LLM 胡说了怎么办？超时了怎么办？

** 渐进加载** 把 Prompt、资源、工具说明拆成 L1/L2/L3，不要一次性塞进上下文。

** 先跑起来，再抽象** 先用硬编码 Workflow 跑通，再考虑是否提炼为通用 Agent Skill。

总结

Skill 是"会做什么"

Agent Skill 是"什么时候做、怎么做、调用什么做、最后怎么收尾"

未来真正重要的，不是你会不会写 Prompt，而是你是否理解 Agent Runtime 的运行本质。

什么？有人手写 Skill？Agent Skill？Skill？