1. 引言：为什么 Agent 需要 Skill
Skill 本质上不是一种新的模型能力，而是一种对 Agent 能力进行"模块化封装和动态加载"的机制。
在过去一段时间里，Agent 开发的关注点主要集中在几个方向：
- 如何让 LLM 调用 Tool
- 如何构建 RAG
- 如何设计 Agent Workflow
- 如何让多个 Agent 协作
- 如何构建 MCP Server
但随着 Agent 系统越来越复杂，一个新的问题开始变得突出：
如何把 Agent 的"能力"本身进行模块化、复用和动态加载？
例如，一个 Agent 需要具备：
- PDF 文档处理能力
- Excel 数据分析能力
- PPT 生成能力
- Git 操作能力
- 数据库分析能力
- 发布系统操作能力
- 代码审查能力
如果所有这些能力都直接写进 System Prompt，Prompt 会越来越庞大；如果全部实现成 Tool，又会发现 Tool 只能描述"能做什么"，却很难完整表达"应该怎么做"。
于是，Agent Skill 开始成为 Agent Runtime 中一个非常重要的抽象。
以目前的 Agent Skill 设计来看，一个 Skill 通常由 SKILL.md、辅助文档以及可选脚本组成。tRPC-Agent-Go 已经在框架层面实现了这一套机制，并进一步把 Skill 与 Tool、Workspace、Code Executor 结合起来。
本文就以 tRPC-Agent-Go 为例，从底层原理分析 Skill 到底是什么，以及一个 Skill 是如何最终被 Agent 使用的。
最早开发 Agent 时，我们经常会采用这样的方式：
txt
User
↓
System Prompt
↓
LLM
↓
Tool Calling
↓
Tool例如：
txt
你是一个代码审查 Agent。
你需要：
1. 阅读代码
2. 检查代码规范
3. 检查潜在 Bug
4. 检查安全问题
5. 输出审查报告然后再提供：
txt
read_file
search_code
execute_command几个 Tool。
这种方案在 Agent 能力比较少的时候没有问题。
但当 Agent 开始拥有几十甚至上百种能力时，问题就出现了。
例如：
txt
System Prompt
├── PDF 操作规范
├── Excel 操作规范
├── PPT 操作规范
├── Git 操作规范
├── SQL 分析规范
├── Docker 操作规范
├── Kubernetes 操作规范
└── ...所有能力都提前塞进 Context，会导致：
第一，Context 膨胀。
大量 Agent 根本不会使用的知识被提前加载。
第二，能力难以复用。
不同 Agent 往往需要复制相同 Prompt。
第三，能力难以维护。
修改一套能力意味着修改 Agent Prompt。
第四，能力与执行逻辑耦合。
"如何完成任务"和"执行任务需要调用什么程序"混在一起。
Skill 的出现，本质上就是试图解决这个问题：
把 Agent 的专业知识、操作规范、辅助文档以及执行脚本，从 Agent 本身中拆出来，形成独立的能力模块。
2. Skill 到底是什么
2.1 Skill 的定义
如果简单理解：
Skill 是 Agent 可以按需加载和使用的一组专业能力。
一个典型 Skill 目录可能是：
txt
skills/
└── pdf-processing/
├── SKILL.md
├── docs/
│ └── usage.md
└── scripts/
└── convert.py其中：
txt
SKILL.md描述：
- Skill 是什么
- 什么情况下应该使用
- 使用步骤
- 注意事项
- Tool / Script 使用方式
而：
txt
docs/存放更详细的知识。
例如：
txt
PDF API 使用说明
PDF 转换规范
企业 PDF 模板规范而：
txt
scripts/则可以放真正需要执行的程序。
这种设计实际上形成了一个非常重要的分层：
txt
Skill
│
├── Description
│
├── Instructions
│
├── Documents
│
└── Executable ScriptstRPC-Agent-Go 对这一模式进行了框架级实现，其 Skill Repository 会扫描 Skill 目录，并解析其中的 SKILL.md。
2.2 Skill 解决什么问题
Skill 最核心解决的是：
Agent 能力的模块化与按需加载。
例如我们有：
txt
PDF Skill
Excel Skill
PPT Skill
Git Skill
Code Review SkillAgent 不需要在初始化的时候把所有内容全部加载进 Prompt。
而是：
txt
User
│
│ "帮我分析这个 PDF"
▼
Agent
│
│ 发现 PDF Skill
▼
Load PDF Skill
│
▼
LLM
│
▼
执行 PDF 操作因此 Skill 实际上解决的是一个非常典型的 Context Management 问题：
txt
所有知识全部加载
↓
❌
↓
按需发现
↓
按需加载
↓
按需执行2.3 Skill 与传统 Prompt 的区别
很多人第一次接触 Skill 时，会认为：
Skill 不就是一个 Prompt 文件吗？
从表面上看确实非常像。
例如：
txt
# PDF Processing
当用户要求处理 PDF 时：
1. 读取 PDF
2. 分析页面结构
3. 提取文本
4. 根据需求生成结果它本质上就是自然语言指令。
但两者的区别在于：
txt
Prompt
↓
描述如何回答
Skill
↓
描述如何完成一类任务
↓
可以包含
├── Instructions
├── Documents
├── Scripts
└── Execution Environment因此可以把它理解成：
Prompt 是模型上下文的一部分，而 Skill 是 Agent Runtime 中的一种能力单元。
这也是 Skill 与普通 Prompt 最大的区别。
3. Skill、Tool、Prompt 与 Workflow
理解 Skill 最容易产生误解的地方，就是把 Skill、Tool、Prompt、Workflow 混为一谈。
实际上它们解决的是完全不同的问题。
可以先建立一个简单模型：
txt
Agent
│
┌──────────────┼──────────────┐
│ │ │
Prompt Skill Workflow
│ │ │
怎么思考 怎么完成任务 怎么执行流程
│
▼
Tool
│
▼
执行具体操作3.1 Prompt：告诉模型怎么做
Prompt 最核心的职责是：
控制模型的行为和推理方式。
例如：
txt
你是一个代码审查专家。
审查代码时必须关注：
1. 并发安全
2. 内存泄漏
3. 错误处理
4. SQL 注入Prompt 本质上是：
txt
Instruction
↓
LLM Context它告诉模型：
"你应该怎么思考。"
3.2 Skill：封装 Agent 能力
Skill 更进一步：
把一类任务所需要的知识、规范、文档和执行能力组织起来。
例如：
txt
Code Review Skill
│
├── SKILL.md
├── Go Review Guide.md
├── Security Guide.md
└── scripts/
└── static-check.sh所以 Skill 更接近：
txt
Capability Package而不是单纯：
txt
Prompt Template3.3 Tool：让 Agent 执行操作
Tool 解决的问题是：
Agent 能够做什么具体操作？
例如：
py
read_file()
write_file()
search_code()
execute_command()
query_database()
send_email()Tool 通常是一个结构化接口：
txt
Tool
├── Name
├── Description
├── Input Schema
└── Execute()例如：
txt
query_database
↓
SQL
↓
Database
↓
ResultTool 是 Agent 与外部世界交互的执行接口。
3.4 Workflow：规定执行流程
Workflow 解决的是：
多个步骤按照什么顺序执行？
例如：
txt
需求分析
↓
代码生成
↓
代码检查
↓
单元测试
↓
构建
↓
发布这就是 Workflow。
如果把它进一步形式化，可以得到：
txt
A → B → C → D或者更复杂的 DAG：
txt
A
/ \
B C
\ /
DWorkflow 更关注：
流程控制。
3.5 Agent：负责动态决策
Agent 最特殊。
它不是简单执行固定流程，而是：
根据当前上下文动态决定下一步做什么。
例如：
txt
User:
帮我分析这个项目有没有安全问题。Agent 可能推理：
txt
需要：
1. 找到项目
2. 判断项目语言
3. 加载代码审查 Skill
4. 搜索依赖
5. 执行静态扫描
6. 分析结果
7. 生成报告这里的核心就是：
txt
Agent = Decision Maker因此可以形成一个非常重要的关系：
txt
Prompt → 思考规则
Skill → 能力封装
Tool → 行动接口
Workflow → 流程约束
Agent → 动态决策4. Agent Skill 的基本工作原理
理解 Skill 的关键，可以把整个过程拆成五个阶段：
txt
Discovery
↓
Loading
↓
Activation
↓
Context Injection
↓
Execution4.1 Skill Discovery
第一步不是加载 Skill，而是：
发现有哪些 Skill。
例如：
txt
skills/
├── pdf/
├── excel/
├── git/
├── code-review/
└── ppt/Runtime 启动时可以扫描：
txt
skills/建立索引：
txt
pdf → /skills/pdf
excel → /skills/excel
git → /skills/gittRPC-Agent-Go 的 FSRepository 就承担了类似职责，它会递归扫描 Skill Root，并寻找包含 SKILL.md 的目录。
更重要的是：
Discovery 阶段不需要把所有 Skill 的完整内容都加载进 Context。
只需要提供：
txt
name
description例如：
txt
Available Skills:
pdf:
Process and analyze PDF files.
excel:
Analyze and generate Excel spreadsheets.
git:
Perform Git repository operations.这就是 Skill 的 Overview Layer。
4.2 Skill Loading
当 Agent 判断：
txt
用户的问题与 PDF 有关才加载：
txt
pdf/SKILL.md此时才把详细 instructions 加入 Context。
这就是：
Lazy Loading / On-Demand Loading
4.3 Skill Activation
更进一步，有些 Skill 不仅仅需要 Prompt。
例如：
txt
release-notes Skill可能需要激活：
txt
release_docs_read_file
release_docs_search
release_docs_generate这样的 ToolSet。
tRPC-Agent-Go 当前已经提供了 Skill Tool Activation 能力：某个 Skill 被 skill_load 后，可以让对应 ToolSet 变得对模型可见，并支持 include / only 等激活模式。
这意味着 Skill 已经不只是：
txt
Prompt Package而开始成为：
txt
Capability Activation Unit4.4 Context Injection
Skill 加载以后，还需要解决：
Skill 内容怎么进入 LLM Context？
tRPC-Agent-Go 使用 SkillsRequestProcessor 对请求进行处理。
可以抽象成：
txt
User Request
↓
SkillsRequestProcessor
↓
Skill Overview
+
Loaded Skill Body
+
Selected Documents
↓
LLM Request其中最重要的设计是：
Skill Tool 决定"加载什么"，Request Processor 决定"怎么注入"。
这种职责分离非常重要。
4.5 Skill Execution
如果 Skill 中存在脚本：
txt
scripts/
convert.py那么 Agent 并不是把：
txt
convert.py整个文件复制进 Prompt。
而是通过执行环境运行：
txt
skill_run
↓
Workspace
↓
Script
↓
OutputtRPC-Agent-Go 使用 Workspace / Engine 抽象隔离执行环境，使 Skill 可以在不同执行后端运行。
于是整个 Skill 生命周期就变成：
txt
发现
↓
加载
↓
激活
↓
注入 Context
↓
执行
↓
返回结果5. tRPC-Agent-Go 中的 Skill 实现
现在进入最核心的部分。先看一段使用 Skill 的示例代码：
go
package main
import (
"context"
"fmt"
"log"
"trpc.group/trpc-go/trpc-agent-go/agent/llmagent"
localexec "trpc.group/trpc-agent-go/codeexecutor/local"
"trpc.group/trpc-go/trpc-agent-go/model"
"trpc.group/trpc-go/trpc-agent-go/model/openai"
"trpc.group/trpc-go/trpc-agent-go/runner"
"trpc.group/trpc-go/trpc-agent-go/skill"
)
func main() {
ctx := context.Background()
// 1. 创建 Skill Repository
repo, err := skill.NewFSRepository("./skills")
if err != nil {
log.Fatal(err)
}
// 2. 创建代码执行器
executor := localexec.New()
// 3. 创建支持 Skill 的 Agent
llm, err := openai.New(
openai.WithModel("your-model"),
)
if err != nil {
log.Fatal(err)
}
agent := llmagent.New(
"pdf-agent",
llmagent.WithModel(llm),
// 开启 Agent Skills
llmagent.WithSkills(repo),
// 为 Skill 提供代码执行能力
llmagent.WithCodeExecutor(executor),
)
// 4. 创建 Runner
r := runner.NewRunner(
"skill-demo",
agent,
)
// 5. 向 Agent 提出任务
events, err := r.Run(
ctx,
"user-001",
"session-001",
model.NewUserMessage(
"请分析一下这个 PDF 文件的主要内容，并总结其中的关键结论。",
),
)
if err != nil {
log.Fatal(err)
}
// 6. 输出 Agent 执行过程
for event := range events {
if event.Error != nil {
fmt.Println("error:", event.Error)
continue
}
if event.Response != nil {
fmt.Print(event.Response.Content)
}
}
}从源码结构来看，可以把 tRPC-Agent-Go 的 Skill 系统抽象成：
txt
LLMAgent
│
▼
SkillsRequestProcessor
│
▼
Skill Repository
│
┌────────┼────────┐
▼ ▼ ▼
Summary Body Docs
│
▼
Skill Tools
│
┌───────────┼───────────┐
▼ ▼ ▼
skill_load skill_list_docs skill_run
│
▼
Workspace
│
▼
Executor5.1 Skill 数据结构
Skill 并不是简单的一段字符串。从语义上看，可以抽象成：
txt
type Skill struct {
Name string
Description string
Body string
Docs []Document
Path string
}其中：
txt
Name用于标识 Skill。
txt
Description用于 Discovery。
txt
Body对应 SKILL.md 的主要内容。
txt
Docs对应辅助文档。
txt
Path则用于找到 Skill 的真实文件目录，并进一步挂载到 Workspace。
5.2 Skill Loader
tRPC-Agent-Go 中一个很重要的抽象是：
txt
skill.RepositoryRepository 不负责 Agent 推理。
它负责：
管理 Skill 资源。
最典型的是：
txt
FSRepository它会扫描：
txt
SKILLS_ROOT并建立：
txt
Skill Name → Directory的索引。
之后可以提供：
py
Summaries()
Get(name)
Path(name)这样的能力。
于是 Agent Runtime 不需要关心：
txt
Skill 到底来自本地文件系统？
数据库？
远程服务？
Git Repository？只需要依赖：
txt
Repository即可。
这其实是一个非常标准的 Repository Pattern。
5.3 Skill Manager
在更高层，可以把 Skill 管理理解成：
txt
Skill Manager
│
├── Discover
├── Get
├── Load
├── Select Docs
├── Activate Tools
└── RuntRPC-Agent-Go 当前实现中，这些职责并不是全部集中在一个巨大 Manager 中，而是拆分到：
txt
Repository
+
RequestProcessor
+
Skill Tools
+
Workspace
+
Executor几个组件中。
这种设计实际上比一个"大而全的 SkillManager"更容易扩展。
5.4 Skill 与 Agent 的关系
Skill 并不是 Agent。
更准确的关系是：
txt
Agent
│
├── Prompt
├── Memory
├── Tools
├── Skills
└── WorkflowSkill 是 Agent 的一种外部能力来源。
因此：
txt
Agent ≠ Skill而是：
txt
Agent uses Skill一个 Agent 可以使用：
txt
N 个 Skills一个 Skill 也可以被：
txt
N 个 Agents复用。
这就形成了：
txt
Skill
/ \
Agent A Agent B这也是 Skill 最大的工程价值之一。
5.5 Skill 与 Tool 的关系
这也是最容易混淆的一点。
例如：
txt
PDF Skill里面可能存在：
txt
convert_pdf.py
extract_text.py而 Agent 最终需要通过：
txt
skill_run来执行。
因此：
txt
Skill
↓
描述能力 + 使用规范
↓
Tool
↓
执行能力可以把它理解成：
Skill 告诉 Agent "应该怎么做"，Tool 提供"做这件事的接口"。
6. 一个 Skill 是如何被 Agent 调用的
现在把整个过程串起来。
假设用户说：
"帮我把这个 PDF 转成 Markdown。"
6.1 用户请求
txt
User
↓
帮我把 PDF 转成 Markdown进入：
txt
Runner
↓
LLMAgent6.2 Skill Selection
Agent 看到：
txt
Available Skills:
pdf-processing
excel-processing
git
ppt根据：
txt
name + description判断：
txt
pdf-processing最匹配。
6.3 Skill Loading
Agent 调用：
txt
skill_load例如：
txt
{
"skill": "pdf-processing"
}Skill Tool 将状态写入 Session。
然后：
txt
SkillsRequestProcessor检测到：
txt
skill = pdf-processing于是加载：
txt
SKILL.md以及需要的文档。
tRPC-Agent-Go 当前提供的 skill_load、skill_select_docs、skill_list_docs 正是用于控制 Skill 及其文档加载状态的工具。
6.4 LLM 推理
此时模型 Context 中已经出现：
txt
PDF Skill Instructions
+
PDF Documentation
+
User Request模型开始推理：
txt
需要执行 PDF 转换。
Skill 提供了 convert.py。
需要执行该脚本。于是下一步不是生成自然语言，而是：
txt
Tool Calling6.5 Tool Calling
例如：
txt
skill_run调用：
txt
{
"skill": "pdf-processing",
"command": "python scripts/convert.py input.pdf"
}然后：
txt
skill_run
↓
Workspace
↓
Executor
↓
convert.py
↓
output.md6.6 最终结果
执行结果重新返回 LLM：
txt
PDF converted successfully.
Output:
output.md模型最终回复用户：
txt
已经完成 PDF 转 Markdown。
文件位于 output.md。因此一次 Skill 调用实际上是：
txt
User
↓
Agent
↓
Skill Discovery
↓
skill_load
↓
Context Injection
↓
LLM Reasoning
↓
Tool Calling
↓
Workspace
↓
Script
↓
Result
↓
LLM
↓
User这才是完整的 Skill Runtime。
7. Skill 与 Tool Calling 的本质区别
可以用一句非常简单的话区分：
Tool 是"动作"，Skill 是"能力"。
例如：
txt
read_file是动作。
txt
code-review是能力。
再比如：
txt
query_database是动作。
txt
data-analysis是能力。
因此：
txt
Skill
├── Knowledge
├── Instructions
├── Tools
└── Scripts而：
txt
Tool
└── Execute one operation可以类比传统软件工程：
txt
Class / Module
↓
封装一组能力
Method
↓
执行一个具体操作所以：
txt
Skill ≈ Capability Module
Tool ≈ Callable Function这是理解 Skill 最重要的一个抽象。
8. Skill 与 Agent Workflow / DAG 的关系
Skill 和 Workflow 也非常容易混淆。
例如：
txt
Code Review Skill可能描述：
txt
1. 获取代码
2. 分析代码
3. 执行静态检查
4. 检查安全问题
5. 生成报告看起来像 Workflow。
但它们实际上不是一回事。
Skill 更关注：
完成某类任务需要什么知识和能力。
Workflow 更关注：
多个节点应该以什么顺序执行。
因此：
txt
Skill
↓
描述能力
Workflow
↓
组织能力例如：
txt
Code Review Skill
│
▼
Workflow
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Static Check Security Scan LLM Review
│ │ │
└─────────────┼─────────────┘
▼
ReportSkill 可以作为 Workflow 的节点。
Workflow 也可以调用多个 Skill。
因此二者是正交关系。
9. 从 tRPC-Agent-Go 抽象一个通用 Skill 架构
如果不考虑具体框架，可以抽象出一个通用 Agent Skill Runtime：
txt
Agent Runtime
│
┌──────────────┼──────────────┐
│ │ │
Skill Registry Skill Loader Skill Executor
│ │ │
▼ ▼ ▼
Discovery Context Workspace
│ │
▼ ▼
LLM Scripts进一步拆解：
txt
Skill Registry
↓
负责发现 Skill
Skill Loader
↓
负责加载 Skill
Skill Activator
↓
负责激活 Tool / Capability
Context Manager
↓
负责注入 Prompt
Skill Executor
↓
负责执行脚本
Workspace
↓
负责隔离执行环境这样就形成了一个比较完整的 Skill Runtime。
10. Skill 架构的工程实践
真正做生产级 Agent 时，仅仅能够加载 SKILL.md 是远远不够的。
10.1 Skill 发现
最简单的是：
txt
./skills但生产环境可以进一步支持：
txt
Local Filesystem
Git Repository
Database
Object Storage
Remote Registry
MCP Server最终形成：
txt
Skill Registry例如：
http
GET /skills
[
{
"name": "pdf",
"description": "Process PDF files"
},
{
"name": "excel",
"description": "Analyze Excel files"
}
]10.2 Skill 动态加载
不要：
txt
启动 Agent
↓
加载 100 个 Skill
↓
全部塞进 Context更好的方式：
txt
启动
↓
加载 Skill Summary
↓
用户请求
↓
选择 Skill
↓
加载完整 Skill也就是：
txt
Cheap Discovery
+
Expensive Loading这实际上就是一种 Context Lazy Loading。
10.3 Skill 权限控制
如果 Skill 可以执行：
txt
shell command那么权限控制就变得非常重要。
例如：
txt
Skill
↓
skill_run
↓
python
↓
shell
↓
filesystem必须考虑：
txt
允许执行什么命令？
允许访问哪些目录？
允许访问网络吗？
允许读取环境变量吗？
最大执行时间？
最大输出大小？tRPC-Agent-Go 的 skill_run 已经提供了命令 allowlist、denylist、超时、Workspace 等安全控制机制。
因此生产环境中不能简单地：
txt
exec.Command("sh", "-c", command)然后让 Agent 自由执行。
10.4 Skill 版本管理
Skill 本质上也是代码。
因此同样需要：
txt
Version
Dependency
Compatibility
Changelog
Rollback例如：
txt
pdf-processing@1.0.0
pdf-processing@1.1.0
pdf-processing@2.0.0Agent 可以根据：
txt
model
runtime
tenant
environment选择不同版本。
10.5 Skill 与 MCP 的结合
Skill 和 MCP 其实非常适合组合。
可以形成：
txt
Skill
↓
告诉 Agent 如何使用某类能力
↓
MCP
↓
提供真正的外部 Tool例如：
txt
GitHub Skill
↓
GitHub MCP
↓
search_repository
create_issue
create_pr这里：
txt
Skill = 使用说明 + 操作规范
MCP = Tool Provider因此：
Skill 可以解决"怎么使用能力"，MCP 可以解决"能力从哪里来"。
二者并不是竞争关系。
10.6 Skill 与 RAG 的结合
Skill 与 RAG 也可以结合。
例如：
txt
金融分析 Skill里面定义：
txt
分析步骤
指标解释
计算公式
风险规则但企业内部金融知识可能非常庞大。
没必要全部写进：
txt
SKILL.md可以：
txt
Skill
│
├── Instructions
│
└── RAG
│
├── 企业知识库
├── 产品知识库
└── 行业知识库于是：
txt
Skill
=
任务方法论
RAG
=
领域知识两者组合起来，可以形成更强的 Agent 能力。
11. 总结：Skill 正在成为 Agent 的能力插件机制
如果把整个 Agent Runtime 放在一起看，可以得到这样一个模型：
txt
Agent
│
┌────────────────┼────────────────┐
│ │ │
Prompt Skill Workflow
│ │ │
怎么思考 有什么能力 怎么组织
│
┌────────────┼────────────┐
│ │ │
Knowledge Tool Script
│ │ │
└────────────┼────────────┘
│
Execution
│
Workspace其中：
txt
Prompt解决：
怎么思考？
txt
Skill解决：
具备什么能力？
txt
Tool解决：
能够执行什么操作？
txt
Workflow解决：
多个能力如何组织？
txt
Agent解决：
当前情况下应该选择什么？
而 tRPC-Agent-Go 的实现非常有意思，因为它并没有简单地把 Skill 当成一个 Markdown Prompt，而是把它进一步连接到了：
txt
Skill Repository
↓
Request Processor
↓
Skill Tools
↓
Tool Activation
↓
Workspace
↓
Code Executor
↓
Artifact形成了一条完整的 Runtime 链路。
这意味着 Skill 的真正价值并不是：
"我多了一个
SKILL.md文件。"
而是：
Agent 开始拥有一种可以被发现、加载、激活、组合、执行和版本化的能力模块。
从这个角度来看，Skill 很可能会成为 Agent 架构中类似传统软件工程 Plugin / Module 的角色：
txt
传统软件：
Application
↓
Plugin
↓
Capability
Agent 系统：
Agent Runtime
↓
Skill
↓
Capability最终，Agent 不再是一个写死 Prompt 和 Tool 的"大模型调用器"，而会逐渐演化成：
txt
Agent Runtime
│
├── Skill Registry
├── Skill Loader
├── Tool Registry
├── Workflow Engine
├── Memory
├── RAG
├── MCP
└── Execution Runtime而 Skill，就是连接"Agent 智能"与"工程能力"的一个关键中间层。