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 的经验。
