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