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

吴佳浩 Alben

188人浏览 · 2026-05-27 03:25:42

吴佳浩 Alben · 2026-05-27 03:25:42 发布

什么？有人手写 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	生成报告

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

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

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

不是所有场景都需要 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 的解法是：上下文长度只和"当前激活的步骤"相关，和整个系统的复杂度无关。

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

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

八、一个常见的错误

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

这只是一个 Prompt。

真正的 Search Agent Skill 应该包含：

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

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

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

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

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

十、行业演化方向

现代 AI 工程的完整路径：

主流厂商的方向对比：

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