从 LLM 到 Agent Skill，龙虾的技术基础 · ⑧ Agent Skill

从 LLM 到 Agent Skill，龙虾的技术基础 · ⑧ Agent Skill

本系列共 8 篇。总览：从 LLM 到 Agent Skill：我理解的 AI 应用进化路线

这篇写给谁

如果你已经把 Agent 跑起来了，但团队开始遇到这些问题：

• 同类任务每次都“重造一遍”；
• 不同同事写出来的效果差异很大；
• 一改 Prompt 就引发连锁回归；
• 能力散落在聊天记录里，无法复用；

那你需要的不是再加一个模型，而是进入Agent Skill 化阶段。

一句话先定性：

Agent Skill = 把高频任务沉淀为可复用、可治理、可评估的能力模块。

1）为什么 Agent 的下一站一定是 Skill

在前几篇我们已经完成了能力搭建：

• LLM（生成）
• Token/Context（预算与信息组织）
• Prompt（任务契约）
• Tool/MCP（执行与标准化）
• Agent（多步闭环）

到这里，系统已经“能做事”。
但如果没有 Skill，团队会陷入三个长期问题：

1. 重复劳动：每个新场景都从零写流程；
2. 质量波动：效果高度依赖个人经验；
3. 治理困难：无法做版本、回归、审计。

所以，Skill 不是锦上添花，而是 Agent 工程化的必经阶段。

2）Skill 到底是什么（和 Prompt / Tool 的边界）

Skill 不是“长一点的 Prompt”，也不是“一个工具函数”。

它更像一个小型能力包，通常包含：

1. 触发定义：什么时候启用，什么时候不要启用；
2. 输入契约：输入字段、必填项、缺失策略；
3. 执行流程：步骤、工具调用顺序、失败分支；
4. 输出契约：结构、字段、质量标准；
5. 评估规则：如何判定成功/失败。

边界可以这样理解：

• Prompt：模型行为说明；
• Tool：单个执行动作；
• Skill：围绕某类任务的可复用“作战手册”。

3）一个高质量 Skill 的标准结构

建议每个 Skill 都采用统一结构，便于路由与维护：

A. 元信息（Metadata）

• name
• description（路由最关键字段）
• version
• owner
• risk_level

B. 激活规则（Activation）

• Use this when…
• Do NOT use this when…
• 前置条件
• 排他条件（避免多 Skill 抢同一任务）

C. 执行流程（Workflow）

• Step 1 / Step 2 / Step 3
• 每一步调用哪个 Tool
• 每一步失败时如何降级

D. I/O 契约（Contract）

• 输入 schema
• 输出 schema
• 失败输出格式（error_code、retryable）

E. 质量门槛（Quality Bar）

• 格式合规（可解析）
• 事实约束（必须引用来源）
• 长度/风格限制

4）Skill 路由：决定“用不用这个技能”的核心

很多团队把精力都放在执行流程，忽略了最关键的一步：技能是否被正确触发。

路由失误有两种：

• 漏触发：该用没用；
• 误触发：不该用却被激活。

提升路由质量的实操点：

1. description要写“任务意图 + 触发词 + 排除条件”；
2. 相似技能要明确边界（避免语义重叠）；
3. 用真实流量做触发日志分析；
4. 建立“路由评测集”（专测触发准确率）。

5）Skill 组合：从单技能到能力编排

成熟系统里，Skill 很少单独存在，通常需要组合。

推荐两条原则：

原则 1：单一职责

一个 Skill 只负责一个稳定任务流。
不要把“检索 + 分析 + 执行 + 通知”全塞进一个巨型 Skill。

原则 2：扁平组合优先

优先“多个小 Skill 协作”，少做过深的嵌套调用。
嵌套越深，可观测性越差、定位越困难。

6）Skill 的版本化与发布策略（团队必备）

Skill 一旦进入多人协作，就必须走版本治理。

建议：

• 语义版本：major.minor.patch
  • major：破坏性变更
  • minor：向后兼容新增
  • patch：修复
• 灰度发布：先小流量验证；
• 回滚机制：版本可一键回切；
• 变更日志：记录“改了什么、为什么改、影响范围”。

这部分做不好，Skill 会从“资产”变“雷区”。

7）Skill 评估：从“能跑”到“可靠”

Skill 评估建议分三层：

1）路由层

• Trigger Precision / Recall（触发准确率、召回率）；
• 误触发率；
• 漏触发率。

2）执行层

• 任务成功率；
• 平均步骤数；
• 工具调用成功率；
• 异常恢复率。

3）业务层

• 单任务成本；
• 响应延迟；
• 用户满意度；
• 人工接管率。

做法上可参考 Evals 思路：固定样本集 + 自动评分 + 人工抽检。

8）安全与合规：Skill 不能绕过治理

Skill 封装的是“流程能力”，不是“权限能力”。
权限、审计、审批必须继续在系统层统一治理。

高风险场景建议：

• 强制 HITL（人在回路审批）；
• 写操作使用最小权限工具；
• 结果必须带来源与证据链；
• 敏感操作强制审计留痕。

9）一个可落地的 Skill 建设路线图

阶段 1：选题

先挑“高频 + 高价值 + 低歧义”的场景做第一批 Skill。

阶段 2：模板化

统一 Skill 结构（元信息、激活、流程、契约、评估）。

阶段 3：可观测

为每次 Skill 调用记录：

• 是否触发；
• 触发原因；
• 执行轨迹；
• 成本与延迟；
• 成败标签。

阶段 4：持续优化

按周回看：

• 触发错误 Top N；
• 失败样本 Top N；
• 成本异常 Top N；
• 版本效果对比。

10）常见误区（最后一轮避坑）

1. 把 Skill 当“超长 Prompt”：缺少流程与评估定义。
2. 只写成功路径：失败分支、降级分支缺失。
3. 没有版本管理：线上行为不可控。
4. 过度嵌套技能：调试困难、链路脆弱。
5. 不做路由评估：触发准确率低导致“看似失灵”。

系列终章：从“会回答”到“可复制的智能系统”

如果把这 8 篇压缩成一条工程演进线：

LLM -> Token -> Context -> Prompt -> Tool -> MCP -> Agent -> Agent Skill

它对应的不是概念堆叠，而是能力升级：

1. 会生成（LLM）
2. 会控制成本与输入（Token/Context）
3. 会稳定执行规则（Prompt）
4. 会连接真实世界（Tool/MCP）
5. 会闭环完成任务（Agent）
6. 会规模化复用能力（Agent Skill）

走到 Agent Skill，标志着一件事：

你做的不再是“聪明对话”，而是“可复用、可治理、可迭代的 AI 生产系统”。

最后的实操建议（给准备落地的人）

如果你准备把这套方法真正落地，我建议从这三步开始：

1. 先选 3 个最常见业务流程做 Skill 试点；
2. 给每个 Skill 建立最小评测集与回归脚本；
3. 每月做一次“技能资产盘点”，淘汰低价值 Skill，升级高价值 Skill。

这样一年后，你会得到一个真正有复利的能力库，而不是一堆难维护的临时 Prompt。

延伸阅读

• Agent 能力分类（视频）：5 Types of AI Agents
• OpenAI Evals（官方）：Evals
• OpenAI 评估实践（官方）：Evaluation best practices
• 复用工作流思路参考（社区）：AI Agent Skills Complete Guide
• Claude Skills 介绍（社区视角）：Claude Skills Explained

系列：龙虾的技术基础 ⑧/8 · 完结