Agent 与 Skills 学习笔记
更新时间:2026-04-25
适合阅读顺序:先看《MCP 与 Skills 入门指南》,再看《Codex Skills 设计拆解》,最后看这篇。
1. 先讲结论
如果把大模型看成一个会思考、会生成文本和代码的大脑,那么 Agent 就是在这个大脑外面加上了“目标、工具、记忆、环境和执行循环”的工作系统。
而 Skills 是 Agent 的“专业工作方法包”。
一句话理解:
Agent解决“让模型持续完成任务”Tools/MCP解决“让模型能调用外部能力”Skills解决“让模型遇到某类任务时知道怎么稳定地做”
所以学习 Agent 不能只学 prompt,也不能只学工具调用。更重要的是理解:
如何把一次性的智能输出,变成可重复、可验证、可协作的工程流程。
2. Agent 是什么
普通 ChatGPT 对话更像:
用户输入 -> 模型回答
Agent 更像:
用户目标
-> 理解任务
-> 制定计划
-> 读取上下文
-> 调用工具
-> 观察结果
-> 调整计划
-> 修改文件或生成产物
-> 验证
-> 汇报结果
也就是说,Agent 不只是“回答问题”,而是能围绕目标持续行动。
2.1 Agent 的核心组成
一个 Agent 通常可以拆成几个部分:
| 组成 | 作用 | 例子 |
|---|---|---|
| Model | 推理和生成 | GPT、Claude、Gemini 等 |
| Instruction | 行为规则 | 系统提示词、开发者指令 |
| Tools | 外部能力 | shell、浏览器、数据库、API |
| Context | 当前信息 | 对话、文件、日志、网页、截图 |
| Memory | 可复用信息 | 项目约定、历史偏好、知识库 |
| Skills | 任务方法 | 做 PPT、改前端、查 OpenAI 文档 |
| Environment | 执行环境 | 本地工作区、容器、远程服务器 |
| Verification | 验证闭环 | 测试、截图、lint、人工审查 |
其中最容易被忽略的是 Verification。
没有验证的 Agent 只是“看起来很会做事”。有验证闭环的 Agent 才更接近工程系统。
3. 为什么 Agent 需要 Skills
没有 Skill 的 Agent,每次遇到任务都要临场判断:
- 这个任务该不该先读文件?
- 应该用哪个工具?
- 输出格式怎么写?
- 需要跑哪些验证?
- 什么情况下应该停止?
- 失败以后怎么恢复?
这些判断当然可以让模型自己想,但问题是:每次都重新想,稳定性就会变差。
Skills 的作用就是把高频任务的经验沉淀下来。
它让 Agent 从:
临时发挥
变成:
按专业流程执行
3.1 Skills 不是更长的 prompt
很多人一开始会误解 Skills,以为它就是“把提示词写长一点”。
其实不是。
好的 Skill 更像一个小型操作手册:
- 什么时候触发
- 读取哪些上下文
- 使用哪些工具
- 先后顺序是什么
- 输出应该长什么样
- 哪些事不能做
- 如何验证完成
所以 Skill 的价值不在于“知识多”,而在于“把任务空间收窄”。
4. Agent、MCP、Skills 的关系
可以用一个简单分层来看:
用户目标
↓
Agent:负责理解、规划、执行、反思
↓
Skills:提供某类任务的工作方法
↓
Tools / MCP:提供外部操作能力
↓
文件、网页、数据库、API、命令行、应用程序
三者的关系:
| 概念 | 关注点 | 典型问题 |
|---|---|---|
| Agent | 怎么完成一个目标 | 我现在该做什么、下一步是什么 |
| Skills | 某类任务怎么做得稳定 | 做 PPT/Excel/代码评审应该走什么流程 |
| MCP/Tools | 能调用什么外部能力 | 如何查数据、跑命令、读资源、调接口 |
一个形象但实用的理解:
- Agent 是执行者
- Skills 是工作方法
- Tools 是工具箱
- MCP 是标准化工具接口
- Verification 是验收机制
5. Agent 的执行循环
Agent 做事通常不是一步到位,而是循环式推进。
Observe -> Plan -> Act -> Verify -> Report
5.1 Observe:观察
先收集上下文。
例如:
- 读 README
- 看目录结构
- 查当前 git diff
- 搜索相关函数
- 打开网页或截图
- 读取用户给的文件
这一步的关键是:不要凭空猜项目结构。
5.2 Plan:计划
计划不是越长越好,而是要把任务拆成可执行步骤。
好的计划通常包含:
- 先改哪里
- 哪些文件不碰
- 怎么验证
- 失败时怎么降级
5.3 Act:行动
执行动作可以是:
- 修改代码
- 生成文档
- 调用 API
- 操作浏览器
- 执行脚本
- 写出文件
Agent 的行动能力越强,越需要边界和验证。
5.4 Verify:验证
验证是 Agent 工程化的核心。
常见验证方式:
- 单元测试
- 类型检查
- lint
- 构建
- 截图
- 运行 demo
- 检查生成文件
- 人工可读审查
如果一个任务没有验证,就要在最终回答里说明“未验证的风险”。
5.5 Report:汇报
最后不是把所有过程倒出来,而是告诉用户:
- 做了什么
- 结果在哪里
- 怎么验证的
- 还有什么风险
好的 Agent 汇报应该短、准、可追踪。
6. Skills 的执行模型
Skill 的设计和 Agent 循环天然适配。
一个 Skill 一般会在这些位置发挥作用:
| Agent 阶段 | Skill 提供什么 |
|---|---|
| Observe | 该读什么、不要读什么 |
| Plan | 任务拆解方式 |
| Act | 工具使用规则、脚本入口 |
| Verify | 检查标准、完成条件 |
| Report | 最终回复格式 |
例如 PowerPoint Skill 会规定:
- 用什么工具生成 PPTX
- 图片、文本、图表怎么处理
- 怎么渲染预览
- 如何确认文字可编辑
- 最终只给
.pptx成品链接
这就是典型的“从任务开始到结束都被 Skill 约束”。
7. Skills 的几种常见类型
7.1 流程型 Skill
用于规定做事步骤。
例子:
- 代码评审
- 需求分析
- OpenAI 文档查询
- 面试复盘
- 项目源码解读
核心写法:
当遇到 X 任务:
1. 先读取 A
2. 再判断 B
3. 如果缺少 C,先补充或说明
4. 输出 D 格式
7.2 工具型 Skill
用于规定某个工具链怎么用。
例子:
- Excel 生成
- PowerPoint 生成
- PDF 处理
- 图片生成
- 浏览器自动化
核心写法:
必须使用工具 A
不要使用工具 B
失败时按顺序尝试 C/D
最后执行验证 E
7.3 领域型 Skill
用于沉淀某个业务或知识领域。
例子:
- 公司内部 API
- 测试用例生成
- 金融建模
- 安全威胁建模
- 运维故障排查
核心写法:
领域术语是什么
关键数据在哪里
常见判断规则是什么
输出要符合哪套规范
7.4 风格型 Skill
用于控制输出风格和质量标准。
例子:
- 前端 UI 设计
- 品牌文案
- 简历 bullet 改写
- 技术博客风格
- PPT 叙事风格
核心写法:
目标风格
禁止风格
质量标准
示例片段
8. 一个任务什么时候该沉淀成 Skill
可以用下面几个问题判断:
- 这个任务是否会重复出现?
- 每次做时是否有固定步骤?
- 是否容易因为遗漏步骤而翻车?
- 是否有明确输出格式?
- 是否需要固定工具链?
- 是否包含团队/个人特定知识?
如果大部分回答是“是”,就适合做成 Skill。
不适合做成 Skill 的情况:
- 只做一次的临时任务
- 完全开放的闲聊
- 没有稳定流程的探索
- 只需要一句 prompt 就能解决
9. Skills 的设计层级
写 Skill 时,可以按四层来设计。
9.1 触发层
主要是 description。
它决定 Codex 会不会在任务开始时想到这个 Skill。
好的 description 要具体:
description: Use when Codex needs to analyze a Java Spring Boot project, explain module structure, trace request flow, and produce study notes. Do not use for generic Java syntax questions.
差的 description 太泛:
description: Help with Java.
9.2 流程层
写在 SKILL.md 正文里。
它决定 Agent 被触发后怎么做。
例如:
1. Read README and build files first.
2. Identify entrypoints and package structure.
3. Trace one representative request path.
4. Summarize modules, data flow, and interview talking points.
9.3 资源层
放在 references/ 和 assets/。
适合承载:
- 长文档
- API 说明
- 项目规范
- 模板文件
- 示例输出
原则:不常用、不总是需要、比较长的内容,不要塞进 SKILL.md。
9.4 执行层
放在 scripts/。
适合承载:
- 批量转换
- 目录初始化
- 固定格式生成
- 数据清洗
- 校验脚本
原则:稳定、重复、容易出错的动作,交给脚本。
10. 一个完整 Skill 的思考模板
你可以按下面问题设计任何 Skill。
10.1 任务边界
- 这个 Skill 解决什么问题?
- 不解决什么问题?
- 和哪些 Skill 容易混?
- 用户怎么描述时应该触发?
10.2 输入
- 用户会给什么?
- 需要读哪些文件?
- 需要联网吗?
- 需要工具或账号吗?
- 缺输入时能不能降级?
10.3 流程
- 第一步必须做什么?
- 哪些步骤可以并行?
- 哪些步骤不能跳过?
- 什么情况下要问用户?
- 什么情况下可以自己决定?
10.4 输出
- 输出 Markdown、代码、表格还是文件?
- 要不要包含路径?
- 要不要包含验证结果?
- 要不要保留中间产物?
10.5 验证
- 怎么知道任务完成了?
- 失败时怎么判断?
- 有哪些常见误报?
- 最低可接受结果是什么?
11. 结合你的学习场景:可以沉淀哪些 Skills
你当前目录里已经有很多学习资料、面经、项目和工具脚本。很适合用 Skills 把学习过程系统化。
11.1 八股题复盘 Skill
触发场景:
- “帮我整理这道八股”
- “这段回答适合面试吗”
- “给我查漏补缺”
工作流:
- 先判断题目属于 Java、网络、数据库、操作系统、测试、项目哪一类。
- 给出面试可讲版本。
- 补充底层原理。
- 给出追问链。
- 生成复习卡片。
输出结构:
## 面试版回答
## 原理展开
## 常见追问
## 易错点
## 复习卡片
11.2 项目讲解 Skill
触发场景:
- “讲一下这个项目”
- “帮我准备项目面试”
- “这个仓库怎么启动”
工作流:
- 读取 README、构建文件、目录结构。
- 找入口文件和核心模块。
- 梳理业务流程或请求链路。
- 总结技术栈和亮点。
- 转成面试表达。
输出结构:
## 项目一句话介绍
## 技术栈
## 核心模块
## 请求/数据流
## 可以讲的亮点
## 面试追问准备
11.3 简历匹配 Skill
触发场景:
- “根据这个 JD 改简历”
- “我这个项目怎么写更像测试开发”
- “帮我准备投递”
工作流:
- 抽取 JD 关键词。
- 匹配你的项目经历。
- 找差距。
- 改写 bullet。
- 生成面试追问。
输出结构:
## JD 关键词
## 匹配点
## 风险点
## 简历 bullet 建议
## 面试准备问题
11.4 测试开发 Skill
触发场景:
- “帮我写测试用例”
- “这个接口怎么测”
- “生成 pytest 脚本”
工作流:
- 明确被测对象。
- 拆正常、异常、边界、权限、并发、性能。
- 输出用例表。
- 如有接口文档,再生成自动化脚本。
- 给出验证方式。
输出结构:
## 测试范围
## 测试点拆解
## 用例表
## 自动化脚本建议
## 风险与补充
12. 从 Prompt 到 Skill 的升级路径
很多任务一开始不需要直接写 Skill,可以逐步升级。
第 1 阶段:临时 Prompt
适合一次性任务。
例子:
帮我把这道 MySQL 索引题整理成面试回答。
第 2 阶段:固定模板
当你发现反复让 AI 按同一格式输出,就可以写模板。
例子:
按“面试版回答、原理、追问、易错点”输出。
第 3 阶段:工作流
当任务不只是格式,而是有步骤,就写成工作流。
例子:
先判断题目类型,再补充原理,再生成追问。
第 4 阶段:Skill
当工作流稳定、可复用、还可能需要 references/scripts/assets,就做成 Skill。
八股复盘 Skill
项目讲解 Skill
简历匹配 Skill
测试用例生成 Skill
这条路径很重要:
不要一上来就为所有事情写 Skill。先用,再总结,再沉淀。
13. 学 Agent 应该重点练什么
13.1 练任务拆解
Agent 的能力不只是“模型聪明”,还取决于任务是否拆得好。
你要习惯问:
- 输入是什么?
- 输出是什么?
- 中间需要哪些信息?
- 哪些步骤可验证?
- 哪些决策可以自动化?
13.2 练上下文管理
Agent 最大的问题之一是上下文有限。
所以要学会:
- 只读相关文件
- 用搜索而不是盲目打开全部文件
- 长资料拆 references
- 把大任务拆成阶段
- 每一步保留关键结论
13.3 练工具选择
同一个任务可能有很多工具能做。
好的 Agent 设计要知道:
- 什么时候用 shell
- 什么时候用浏览器
- 什么时候用脚本
- 什么时候用 MCP
- 什么时候不要用工具,直接回答就行
13.4 练验证意识
这是区分“会玩 AI”和“会用 Agent 做工程”的关键。
每个任务都问一句:
我怎么知道它真的完成了?
如果能回答这个问题,你的 Agent 设计就会稳很多。
14. 常见误区
14.1 把 Agent 当搜索引擎
Agent 不只是查资料。它应该能计划、执行、修改、验证。
14.2 把 Skill 写成百科
Skill 不是知识库。长知识应该放 references,核心流程才放 SKILL.md。
14.3 工具越多越好
工具越多,决策空间越大,出错机会也越多。
好的 Agent 工具集应该是“够用且边界清楚”。
14.4 不写失败路径
很多流程只写成功路径,一旦 API 失败、文件缺失、测试不过,Agent 就会乱试。
Skill 里要写清楚:
- 失败先看什么
- 尝试几次
- 何时停止
- 何时告诉用户
14.5 没有输出标准
如果不规定输出格式,Agent 每次可能都不一样。
对学习笔记、面试复盘、项目分析这类任务,输出结构非常重要。
15. 学习路线建议
第一阶段:理解概念
目标:
- 分清 Agent、Tools、MCP、Skills
- 理解上下文和工具调用
- 知道 Agent 为什么需要验证
建议输出:
- 一张对比表
- 一个简单 Agent 执行流程图
- 一篇 MCP vs Skills 笔记
第二阶段:观察现成 Skills
目标:
- 看懂
SKILL.md - 看懂 description 怎么写
- 看懂 scripts/references/assets 怎么分工
建议观察:
skill-creatoropenai-docsfrontend-designExcelPowerPoint
第三阶段:改造自己的流程
目标:
- 把自己常用 Prompt 变成模板
- 把模板变成工作流
- 把工作流变成 Skill
建议先做:
- 面试复盘 Skill
- 项目讲解 Skill
- 简历匹配 Skill
第四阶段:接入工具
目标:
- 用脚本处理重复动作
- 用 MCP 接外部资源
- 用测试/截图/命令行做验证
建议练习:
- 自动读取目录并生成项目结构说明
- 自动把 JD 和简历做匹配评分
- 自动把接口文档转成测试用例表
16. 一个最小实践:项目讲解 Skill 草稿
如果你要马上动手,可以先写一个最小版本。
目录:
project-explainer/
└── SKILL.md
SKILL.md:
---
name: project-explainer
description: Use when Codex needs to explain a local software project, trace its structure, identify entrypoints, summarize technical stack, and prepare interview-ready project notes.
---
# Project Explainer
## Workflow
1. Read README, package/build files, and top-level directory structure first.
2. Identify framework, entrypoint, config files, and main modules.
3. Trace one representative request, command, or data flow.
4. Summarize the project in learning-note format.
5. Include interview talking points and likely follow-up questions.
## Output
Use this structure:
- Project overview
- Tech stack
- Directory structure
- Core modules
- Main flow
- Highlights
- Risks or unclear parts
- Interview Q&A
## Rules
- Do not guess missing architecture.
- Cite file paths when explaining code.
- If the project cannot run, explain why and what was checked.
这个 Skill 虽然简单,但已经具备了 Skill 的核心:
- 明确触发场景
- 明确执行流程
- 明确输出结构
- 明确禁止猜测
17. 最重要的思维方式
学 Agent 和 Skills,核心不是背概念,而是学会把事情工程化。
你可以经常问自己四个问题:
- 这个任务能不能重复?
- 重复时最容易错在哪里?
- 哪些步骤应该写成规则?
- 哪些动作应该交给工具或脚本?
当你能这样思考时,你就不只是“会用 AI”,而是在设计一个可复用的智能工作系统。
18. 总结
Agent 是执行系统,Skills 是方法沉淀,MCP/Tools 是能力接口,验证是质量闭环。
真正好用的 Agent,不是靠一次 prompt 写得多神,而是靠:
- 清晰的任务边界
- 合适的工具
- 稳定的工作流
- 可复用的 Skills
- 可靠的验证方式
学习 Agent/Skills 最好的路径是:先用 AI 做具体任务,再把高频任务总结成模板,最后把模板升级成 Skill。
这也是从“让 AI 帮我一次”走向“让 AI 成为稳定生产力系统”的关键一步。