AI Agent 中的 Skill — 什么是"技能"

---

一、从一个问题开始

你招了一个实习生，第一天上班。

你不会对 ta 说"用 SQL 的 SELECT JOIN 查表"这种微观指令，
你会说"来了新订单就走这个 SOP：查库存→锁商品→建订单→扣余额"。

这个 SOP，就是 Skill。

Skill = 让 AI Agent 从"知道一切但执行不稳"的通才，变成"特定场景下能稳定完成任务"的专家。

---

二、为什么大模型需要 Skill

2.1 没有 Skill 的 Agent — 原理都懂，细节全错

用户：帮我排查一下服务器上数据库连不上的问题。

LLM 脑子里：
  "PostgreSQL 默认端口 5432..."
  "要检查 pg_hba.conf..."
  "但 Ubuntu 24.04 的 pg_hba.conf 在哪个路径？不确定..."
  "scram-sha-256 认证和 md5 有什么区别？忘了..."

每一次执行都像第一次，每次都要试错。

2.2 有了 Skill 的 Agent — 照着 SOP 走，又快又稳

同一个问题，Agent 加载了 postgresql-connectivity-debugging Skill：

  步骤 1 → 检查 pg_hba.conf → 路径 /etc/postgresql/15/main/
  步骤 2 → Ubuntu 24.04 默认 scram-sha-256，老客户端不兼容 → 提示用户
  步骤 3 → 腾讯云安全组优先于本地 iptables → 先查安全组
  步骤 4 → telnet 43.139.143.86 35432 测试连通性
  陷阱  → Docker 容器里 localhost ≠ 宿主机的 localhost

一次通过，不需要试错。

---

三、Skill 的本质 — 过程知识

Skill 不是代码，不是 API，不是 prompt 模板。它是一份结构化的过程知识文档。

知识可以分成两种：

陈述性知识（"是什么"）
  → PostgreSQL 端口是 5432
  → 腾讯云有安全组功能

过程性知识（"怎么做"）
  → 遇到连接超时，第一步查安全组，第二步查 pg_hba.conf
  → 踩过坑：Docker 容器里 localhost 不通宿主机
  ↑
  Skill 存储的就是这种过程性知识

---

四、Skill 的解剖结构

skill-name/
├── SKILL.md          ← 主文件（必选）
├── scripts/          ← 脚本（可选）
├── templates/        ← 模板（可选）
└── references/       ← 参考资料（可选）

SKILL.md — 六个核心部分

---
name: service-deployment
trigger: 用户说"部署"/"上线"/"启动服务"
---

## 1. 触发条件
什么情况下加载这个 Skill。精确描述，避免误触发。

## 2. 前置知识
执行前需要知道什么 —— API 端点、配置路径、依赖版本。

## 3. 执行步骤
代码块明确的步骤，每一步都能验证是否完成。

## 4. 常见陷阱
实际踩过的坑，OS 差异、版本差异、默认值不符合预期。

## 5. 验证方法
怎么确认任务真的做对了，不是"看起来做完了"。

## 6. 参考资源
附带的脚本、模板、外部文档链接。

---

五、Skill 不是什么

❌ 常见误解	✅ 真实是什么
Skill 是可执行代码	Skill 是指导文档，告诉 Agent 怎么调用已有的工具
Skill 越多越好	Skill 是"减速带"，只有匹配的才加载，乱加载反而干扰
Skill 替代 API 工具	API 提供"能做什么"，Skill 提供"怎么做"，互补
Skill 是静态的	Agent 完成后可以自动提炼/更新已有的 Skill
Skill 就是 Prompt 模板	Prompt 只有"说什么"，Skill 包含步骤+陷阱+验证+脚本

---

六、一个完整的 Skill 示例

场景：帮助用户部署 Java 应用到服务器

---
name: service-deployment
description: 在 Linux 上用 systemd 部署 Java 应用
trigger: 用户提到"部署"、"上线"、"启动服务"
---

## 前置条件
- 应用 jar 包已编译好
- JDK 21 已安装
- 用户有 sudo 权限

## 执行步骤

1. **确认端口不被占用**
   ss -tlnp | grep :{port}
   如果占用 → 告诉用户，询问是否换端口

2. **复制 jar 到标准目录**
   sudo mkdir -p /opt/{app-name}
   sudo cp {jar-path} /opt/{app-name}/

3. **创建 systemd service**
   模板内容参考 templates/service.template
   关键配置：Type=simple, Restart=always, User=appuser

4. **启动并验证**
   sudo systemctl daemon-reload
   sudo systemctl enable --now {app-name}
   sleep 3
   curl http://localhost:{port}/actuator/health

5. **配置日志轮转**
   /etc/logrotate.d/{app-name}

## 常见陷阱

- ⚠️ systemd 的 ExecStart 必须写绝对路径，写相对路径会启动失败
- ⚠️ 不要在 ExecStart 里用 nohup — systemd 自己负责守护进程
- ⚠️ Spring Boot 需要 30-60 秒启动，curl 验证前先 sleep 或轮询
- ⚠️ User= 指定的用户必须有 jar 和日志目录的读写权限

## 验证方法

systemctl status {app-name} → Active: active (running)
curl http://localhost:{port}/actuator/health → {"status":"UP"}
journalctl -u {app-name} -f → 无 ERROR 日志

---

七、Skill 的生与死

7.1 来源：Skill 怎么来

来源一：人工撰写
  领域专家把自己的经验写成 Skill → 沉淀知识

来源二：Agent 自动提炼
  Agent 完成一个复杂任务后自动做总结：
  "刚才修复 PostgreSQL 连接问题用了 5 步，
   第 3 步在安全组上踩了坑 → 提炼成 Skill"

来源三：社区共享
  像 Docker Hub 一样，下载别人写好的 Skill 直接用

7.2 维护：Skill 怎么活

首次使用 → 验证 Skill 管用
再次使用 → 发现有个过时的配置路径 → 自动 patch
多次使用 → 积累更多陷阱记录 → Skill 越来越厚

一个活了 100 次的 Skill，比官网文档更靠谱

7.3 淘汰：Skill 怎么死

触发条件不再匹配 → 被新的 Skill 替代
内容过时 → Agent 标记为 deprecated
长时间无人使用 → 自动归档

---

八、Skill vs Prompt Engineering

	Skill	Prompt
粒度	完整的任务流程	单个对话指令
复用性	跨会话、跨用户复用	一次性
结构	步骤 + 陷阱 + 验证	自由格式
维护	Git 版本化	写完就丢
举例	“部署应用 SOP”	“用表格列出结果”

---

九、Skill vs MCP（一句话区别）

Skill = 📖 操作手册 → 教 Agent "怎么思考"
MCP   = 🔌 USB 接口 → 给 Agent "连接什么工具"

Skill 不能帮你调 GitHub API，MCP 不能告诉你遇到 403 怎么排查。
两者各司其职，配合使用。

---

十、Skill 的三个核心价值

价值一：消除试错

  LLM 本身每次执行任务都像第一次，不确定细节。
  Skill 让它直接走已验证的路径，一步到位。

价值二：知识沉淀

  团队里最懂 PostgreSQL 的那个人离职了，他调试数据库的经验还在。
  Skill 把个人经验变成组织资产。

价值三：自动化起点

  Skill 是 Agent 自动化的最小单元。
  有了 Skill，Agent 不用每件事都从零推理，直接加载"肌肉记忆"。

---

十一、什么时候需要 Skill？

问题：一个任务值得写成 Skill 吗？三个问题自检：

① 这个任务是否重复出现？（至少 2 次以上）
② 这个任务是否有非显而易见的步骤/陷阱？
③ 这个任务失败了是否代价很大？

三个都是"是" → 写 Skill
两个是"是" → 考虑写
只有一个 → 暂不需要

---

十二、总结

Skill 不是 AI 的超能力，
而是把 AI 反复验证过的成功路径固化下来，
让下一次执行不再从零开始。

就像人类的"经验"不是写在基因里的，
而是通过反复实践、踩坑、总结，最后内化成的本能。

AI Agent 的 Skill，就是 AI 的经验。