4月14日(Skills+AI概率+Agent设计)

Agent Skills从入门到精通

2026年最值得学习的AI技能是什么？我会毫不犹豫地推荐Skills。

Skills很可能是今年Agent领域最重要的创新之一。

简单理解：模型是大脑，Agent是躯体，而Skills就是双手。

Skills就是我们专门给AI定制的“标准操作手册（SOP）

每个Skill都有一个专门的文件夹（核心文档 SKILL.md），用来放执行指令、资源文件和参考资料等。但千万别小看这个文件夹，它能让AI瞬间从“职场小白”变成“职场老司机”。

• Prompt就像顾客的点单：“老板，给我做一个牛肉汉堡，不要洋葱！”（指令很明确，但怎么做全看厨师心情）。
• MCP就像厨房里的工具和食材：它给了AI铲子、平底锅、牛肉饼和面包（AI终于不用空手套白狼了）。
• Skills是这家店的秘制菜谱+员工守则：“第一步，肉饼必须煎 3分半钟；第二步，酱汁只能挤两圈半；做完后，必须清理灶台！”

Skills规定了动作的先后顺序、质量底线和执行标准。有了它，AI就不再瞎猜你的心思，而是按部就班地干活。

拆解Skills的核心架构

通常，一份标准的Skill结构如下。

1. 以SKILL.md为第一指引，了解该skill对大模型的要求。
2. 结合当前的任务情况，判断是否需要调用scripts（代码脚本）、references（参考文档）和assets（素材资源）。
3. 最后通过“规划-执行-观察”的交错式反馈循环，来完成用户制定的任务要求。

1）核心原则：触发即正义

Description的首要任务不是给人看的，而是给AI的路由机制看的。它需要明确回答两个问题：

• 这个skill是做什么的？(功能定义)
• 用户在什么场景/说什么话时应该使用它？(触发条件)

2）“黄金结构”公式

一个高质量的description通常遵循这个结构：[一句话核心功能] + [具体执行动作] + [明确的触发关键词/场景]。

简单理解就是，写好description的秘诀在于模拟用户的提问方式。想象一下你会怎么向AI提出请求，然后就把这些请求中的关键词都塞进description里。

Skills的三个“魔法机关”

机关一：智能开关（YAML元数据）

每个Skill文件的开头（就是用---包裹的那块），都有一个小小的控制面板，这是Skills的元数据，会始终加载到Claude Code的系统提示中。这就好比技能的“开关”和“权限卡”。

机关二：随用随取的“小抄”（渐进式披露）

过去的AI有个毛病：记性不好。如果我们把公司的所有开发规范都塞给它，它的“短期记忆（上下文窗口）”瞬间就被撑爆了，导致它开始胡言乱语（AI幻觉）。

Skills的设计非常聪明：平时绝不占用脑容量，只在需要时占用。

你写好的几十个Skills，就像存放在书架上的工具书。Claude Code平时不去翻它们，只有当你触发了“测试代码”的技能时，Claude Code才会翻出小抄，只把关于“如何测试”的那张纸加载进大脑。内存省了，思路也无比清晰。

机关三：呼叫外援与影分身（行动导向与子代理）

Skills可不只是让AI读说明书，它还能让AI“动起手来”。

在Skill的指导下，Claude Code可以像人类一样敲击命令行、搜索文件、运行测试。更有趣的是，如果它碰到了一个极其复杂的巨无霸任务，它可以召唤一个“子代理”（Subagent）——就像是它召唤了一个自己的“影分身”，让分身专门去隔壁房间解决那个大难题，搞定后再把结果汇报给自己。

这里面，渐进式披露（Progressive Disclosure）是Skills最牛的的设计哲学。

它让Skills的所有信息不是一次性塞给Claude Code，而是分三层加载，根据需要逐步展示。

这种设计有什么好处？

想象一下，你有一个包含数百页技术文档的Skill。如果每次对话都把这些文档加载进去，对话上下文（Context）很快就会被撑爆。但通过渐进式披露，Claude Code只在需要时才加载相关文档——就像一本组织良好的指南书，你只看需要的章节，而不是从头读到尾。

Skills与Prompt、MCP、Agent、Projects的区别

在Claude Code中，一个SKILL.md文件：

• 包含了超级精细的Prompt（告诉AI目标是什么，怎么做，做到什么效果）；
• 规定了AI可以且只能使用哪些工具、可执行代码（给AI发放特定的武器）；
• 指挥Agent按照1-2-3-4的严格顺序执行，绝不偏离轨道。

创建并部署一个skill通常包含四个阶段

阶段一：明确需求与边界

在动手前，先回答清楚这三个问题：

1）这个skill要解决什么具体问题？原则是“单一职责”，每个skill只专注一个能力。例如，“处理PDF”太宽泛，而“从PDF中提取表格并转换为CSV”就是好的定义。

2）触发它的关键词/场景是什么？这将决定description字段的写法，而description是Agent判断是否调用该skill的唯一依据。不要写“帮助处理文档”，而要写“当用户提到PDF、表单或文档提取时，用于从PDF中提取文本和表格”。

3）需要哪些资源？脚本、模板、参考文档还是示例数据？把这些提前整理好，放入skill文件夹的对应子目录（如scripts/、references/、assets/）。

阶段二：构建skill文件夹

在确定了需求之后，就可以创建skill的文件结构了。根据使用场景，你可以选择三个存放位置。

核心文件SKILL.md的结构如下：

命名规范：name字段仅使用小写字母、数字和连字符，不超过64个字符。文件夹名称须与name一致。

阶段三：编写核心指令

这是决定skill质量的关键步骤。Anthropic内部团队的经验表明，最有价值的内容是“常见陷阱”章节——应持续累积Agent的失败模式，让后来者可以直接绕坑。

一个高质量的SKILL.md通常包含以下要素：

1）明确的职责边界：告诉Agent能做什么和绝对不能做什么。例如，一个SQL分析skill应明确限定只能执行SELECT查询，禁止DROP、DELETE 等危险操作。

2）具体的操作步骤：用编号列表而非段落文字。Agent对结构化内容的遵循度远高于叙述性文字。

3）输入输出规范：给出示例格式和预期输出，这能显著降低结果的随机性。

4）硬性约束：使用“必须”“严禁”“总是”等绝对化词汇。研究发现，包含至少3条明确约束和1个输出示例的skill，其结果的稳定性可提升60%。

阶段四：测试、调试与迭代

创建完成后，按以下清单验证：

• 路径检查：确认SKILL.md位于正确的目录（.claude/skills/<skill-name>/）。
• YAML校验：确保元数据格式正确，---包裹无误。
• 触发测试：用自然语言提问，观察Agent是否识别并请求使用该skill。
• 执行验证：检查输出是否符合预期格式和内容。

如果skill未被触发，90%的情况是description写得不够具体。调试时可运行claude –debug查看详细加载日志。

AI圈最烧脑的8个概念

LLM大语言模型

LLM（Large Language Model），就是大语言模型——当前所有AI技术的核心引擎。

市面上几乎所有大模型，都基于一个叫Transformer的架构训练而成。

大模型的本质：一个文字接龙游戏

说穿了极其朴素：大模型就是一个"预测下一个词"的机器。

Token与Tokenizer

大模型本质上是数学函数，它只认数字，不认文字。

那问题来了：你输入的是中文、英文、代码，模型怎么"看懂"？

答案就是Tokenizer——人类和模型之间的翻译官。

💡Tokenizer干两件事：

1. 编码：把你输入的文字翻译成数字（喂给模型）
2. 解码：把模型输出的数字翻译回文字（给你看）

Context与Context Window

Context（上下文）=大模型每次处理任务时接收到的所有信息的总和。

包括什么？比你想象的多：

• 你当前问的问题
• 之前的对话记录
• 模型正在生成的Token
• 可用的工具列表
• System Prompt（开发者给你设的人设和规则）
• ……等等一切

那超长文档怎么办？

比如你要AI分析一份上千页的产品手册，不可能全塞进去。这时候就需要RAG技术（检索增强生成）

RAG的核心思路：不把整本书给模型看，只把和问题最相关的几页摘出来给它。

1. 从文档中搜索和你的问题最匹配的片段
2. 只把这些片段发给模型
3. 模型基于这些片段回答你的问题

既突破了Context Window的限制，又控制了成本。

Prompt、Prompt工程与Harness

Prompt = 你给大模型的具体指令或问题。

说到Prompt，就不得不提一个最新的概念——Harness（指令束）。

Harness是什么？

如果说Prompt是"给AI写一封邮件"，那Harness就是"给AI配了一整套工作手册"。

Prompt关注的是"这一次怎么回答"，Harness关注的是"AI应该怎么工作"——包括身份定义、行为边界、工具使用规则、输出格式、质量标准……所有东西打包在一起，形成一个完整的约束框架。

Tool与MCP

Tool（工具）

Tool本质上就是一个函数：输入参数 → 执行操作 → 返回结果。

• 大模型：负责选择工具 + 汇总结果（大脑）
• 工具：负责执行具体操作（手脚）
• 平台：负责串联整个流程（传话筒）

MCP

MCP（Model Context Protocol），全称"模型上下文协议"。

一句话说清楚：MCP就是AI工具的"Type-C接口"。

以前每个手机都有自己的充电接口，现在统一用Type-C。

MCP干的也是这事

统一工具接入标准，写一次代码，所有平台通用。

Agent与Agent Skill

Agent = 能自主干活的系统

Agent和普通AI对话的核心区别：Agent能自主规划、调用多个工具、持续工作，直到把任务完成。

Skills：给Agent的说明书

Agent Skills就是解决方案——提前写好一份说明书，Agent每次干活前自动读取。

本质上就是一个Markdown格式的文档，包含：

一张图串起来

AI的本质是一个"预测下一个词"的引擎（LLM），通过最小单元（Token）处理信息，在有限的记忆空间（Context）里，根据你的指令（Prompt/Harness），借助外部能力（Tool/MCP），自主完成任务（Agent/Skill）。

做Agent产品，你不是在做AI助手，你是在重新分配责任

Agent = 在给定目标、约束和工具权限下，能够自主推进一个任务闭环的软件执行体。

注意四个关键词：目标、约束、工具、闭环。

• 没有目标，它就是个聊天机器人；
• 没有约束，它就是个不可控的脱缰野马；
• 没有工具，它只会生成文本，不会"行动";
• 没有闭环，它就只是答了一句话，不是完成了一件事。

Agent该代理什么？不是代理人，是代理一段责任

不要代理一个岗位，要代理任务链中那些"高频、可观察、可评价、可授权"的部分。

人和Agent的协作边界，要按"决策类型"切，不是按"动作"切

第1层：目标定义权 → 必须留在人手里

• 这件事到底要不要做
• 成功标准是什么
• 什么不能碰
• 优先级是什么

Agent永远不该擅自改目标。

第2层：过程规划权 → 可以部分给Agent

• 任务怎么拆
• 先做什么后做什么
• 缺信息时先补什么

前提是目标和约束已经被讲清楚。

第3层：执行权 → 可以大量给Agent

• 检索、汇总、生成、调用API、填表、排程

这是Agent最该接的一段。

第4层：责任签字权 → 高风险动作必须回到人

• 发给客户
• 花钱
• 改正式数据
• 对外承诺
• 发布到生产

人定义目标、约束和最终责任；Agent代理信息处理、任务推进和局部决策；涉及高风险不可逆动作时，回到人审批。

一个更实用的Agent方法论：PACT框架

P = Problem（先定义问题，不要先定义Agent）

问自己五个问题：

1. 用户到底想完成什么任务？
2. 这个任务原来的流程是什么？
3. 卡点在哪里？
4. 哪一段最值得被代理？
5. 成功后用什么指标衡量？

A = Authority（定义代理权）

这是Agent设计文档里最容易被漏掉的一节，但它最重要：

• Agent能决定什么、不能决定什么
• 能调用哪些工具
• 哪些动作必须审批
• 它能花多少钱、耗多少token、跑多久
• 它能不能写入正式系统

C = Context（定义上下文结构）

不要把所有信息一股脑塞进去。上下文至少要拆成：

• 角色规则
• 当前任务目标
• 用户偏好
• 历史动作摘要
• 工具返回结果
• 可引用知识
• 禁止事项
• 当前状态机位置

很多Agent一跑就乱，根源不在模型，在上下文失控。

T = Trust（定义信任机制）

用户为什么敢把事交给它？因为你给了：

• 可见的计划：它打算怎么做
• 可见的依据：它为什么这么做
• 可见的工具调用：它动了什么
• 可回滚：错了能撤
• 可审批：关键步骤能拦
• 可追责：出问题能查
• 可评估：跑得好不好有数据

Agent不是靠"聪明"赢得信任，是靠透明、稳定、可预期赢得信任。

PRD要重写：给你一份Agent PRD的8个新模块

1. 任务定义：任务名、触发条件、完成标准、失败标准
2. 代理边界：什么由Agent负责，什么必须人负责
3. 决策分层：目标/过程/执行/签字四层分别归谁
4. 工具权限表：每个工具的用途、输入输出、风险级别、是否需审批
5. 上下文设计：系统规则、用户偏好、任务态记忆、长期记忆、检索/截断策略
6. 状态机：待命→接收目标→澄清→规划→执行→自检→请求审批→完成/降级
7. 失败与降级策略：工具失败、信息不足、低置信度、超时、越权时怎么办
8. 评估体系：离线评测 + 在线指标 + 人工抽检

真正决定Agent产品成败的，是"责任切分"，不是"智能"

很多Agent产品失败，是因为它们在卖"像人"。但用户在乎的从来不是它像不像人。

用户在乎的是四件事：

• 你能不能把事推进
• 你会不会乱来
• 你错了我能不能看出来
• 我是不是还得给你擦屁股

一个好的Agent，几乎从来不是最像人的那个。它是边界清楚、状态清楚、错误清楚、交接清楚的那个。

三件事定死

1. 你的Agent代理的是"信息处理"还是"行动执行"？前者（采集/总结/分析/建议）容易出效果，后者（发消息/改数据/调系统）风险高很多。两条路的难度根本不在一个量级。
2. 你的Agent是"单任务强闭环"还是"多任务通用平台"？绝大多数情况下，先做单任务强闭环。评估清楚、工具少、上下文短、用户预期稳定，才有快速迭代的空间。
3. 你的Agent失败后，用户还能不能继续做事？如果失败就卡死，产品就是个单点故障。Agent必须是加速器，不能是绊脚石。

总结

做Agent产品，不再是"设计功能给人用"，而是"设计一套人和机器共同承担任务责任的机制"。

1. 选对可代理任务
2. 划清代理权与审批边界
3. 把上下文和工具组织成稳定执行系统
4. 用评估、日志、降级机制把它做成可托付的产品