Skill 的哲学设计
Skill 的哲学设计
一句话先讲明白
一个真正好用的 Skill，不是把步骤写得越细越好，而是让 Agent 在某个场景下“更会思考、更会选工具、更少犯常识性错误”。
很多人一提到 Skill，第一反应是：
- 给模型一套固定流程
- 让它照着步骤执行
- 尽量把每一步写死
这当然有用。
但如果你写的是一个通用场景的 Skill，比如联网、写文档、代码审查、做调研，那么把步骤写得太死，反而会把模型的上限锁住。
因为真实任务不是流水线。
真实任务里，Agent 需要一边行动，一边判断：
- 这条路还值不值得继续？
- 现在该换工具吗？
- 看到的结果是真相，还是误导？
- 当前障碍必须解决，还是可以绕过？
所以，Skill 的核心，不只是“告诉模型做什么”，而是校准模型在某类问题上的思考方式。
二、先纠正一个常见误解：Skill 不是“超长提示词”
很多人会把 Skill 理解成：
我把一大段经验写进
SKILL.md，以后模型就会更听话。
这句话只对了一半。
Skill 确实会把经验交给模型，但它真正有价值的地方，不是“字多”，而是“结构对”。
一个差的 Skill 往往长这样：
- 写了很多步骤
- 写了很多规则
- 写了很多注意事项
- 但没有告诉模型：这个场景的判断原则是什么
结果就是：
- 模型表面上很努力
- 实际上一直在错误方向上重复尝试
- 工具也在用，但用得不对
- 遇到异常时不会调整策略
所以，Skill 设计的关键不是堆信息，而是让模型形成一个更像“熟练员工”的工作心智。
三、我现在更认同的一种公式
结合 Web Access 这篇文章里的思路，我觉得一个高质量通用 Skill 可以概括成：
Skill = Agent 策略哲学 + 最小完备工具集 + 必要的事实说明
这三个部分，分别解决三类问题：
- 策略哲学：解决“模型该怎么想”
- 最小完备工具集：解决“模型手里有没有牌可打”
- 必要的事实说明：解决“模型知不知道那些容易忘、但又很关键的事实”
如果只给工具，没有策略哲学，模型会乱用。
如果只给哲学，没有工具，模型会想得很好但做不出来。
如果没有事实说明，模型就会在一些“它本来可能知道、但当前没想起来”的地方持续犯错。
这三者要一起看，Skill 才会真正像一个“能力模块”，而不是一段松散说明。
四、第一部分：Agent 策略哲学
1. 什么叫“策略哲学”？
人话版就是：
你不是直接告诉 Agent 每一步怎么做，而是先告诉它，在这个场景里，应该按什么原则思考。
比如联网任务。
我们平时让同事帮忙查信息，不会说：
- 先用搜索引擎
- 再打开第二个结果
- 再点击某个按钮
- 再滚动三次
我们只会说：
你上网帮我查一下这个事。
然后对方会自己判断：
- 这是适合搜索引擎，还是适合直接上官网？
- 这是静态网页，还是必须登录后才能看？
- 这个页面打不开，是网站挂了，还是访问方式不对？
这就是“场景化思考方式”。
而一个好的 Skill，要做的正是把这种思考方式显式写出来。
2. 为什么这一步特别重要？
因为模型很容易陷入“惯性推理”。
典型表现就是：
- 一提到联网，就只会
search - 一看到多个网页都这么写，就默认是真的
- 一发现页面没加载出来，就以为网站坏了
- 一条路径没通，就在原地重试很多次
这不是模型不聪明。
而是模型在很多场景下，会沿着当前上下文的惯性往下滑，不会主动停下来重新判断方向。
所以，Skill 里的策略哲学，本质上是在帮模型建立一个“刹车 + 校准 + 重选路径”的机制。
3. 一个很有代表性的思考框架
Web Access 里给联网任务抽了一个很好的四步循环，我觉得非常值得借鉴：
- 先定义成功标准：什么算完成？要拿到什么信息？做到什么结果？
- 选一个最可能直达的起点：先用最合适的方法验证，而不是平均用力。
- 用过程结果当证据：每一步都在告诉你方向对不对，而不只是“成功/失败”。
- 对照成功标准收尾：完成就停，不为了“显得完整”而过度操作。
这类内容的价值在于，它没有把路径写死。
它只规定了：
- 先想清目标
- 再选路径
- 再根据证据纠偏
- 最后适时收手
这就给模型留下了泛化空间。
面对没见过的网站、没见过的任务、没见过的页面结构，它依然能用同一个框架继续判断。
4. 奶奶版理解
如果把 Agent 想成一个刚入职但脑子很快的新人，那么：
- 坏 Skill：教他死记硬背流程图
- 好 Skill：先告诉他“这类活儿应该怎么看、先看什么、卡住了怎么判断是不是该换路”
前者适合重复流水线。
后者才适合复杂现实世界。
五、第二部分：最小完备工具集
1. 光会想不够，还得有工具
很多 Agent 任务失败，不完全是因为模型不会想。
还有一个常见原因：
模型想做，但手里没有足够完整的基础工具。
比如联网场景，如果只有搜索，没有浏览器；或者只有抓页面正文，没有交互能力；或者能交互，但没有很清楚的工具边界说明。
那模型即使判断对了，也未必做得出来。
2. 什么叫“最小完备”？
不是工具越多越好。
而是：
刚好覆盖这个场景最核心的原子能力，不缺关键牌，也不过度堆砌。
还是拿联网来说，人上网本质就三件事：
- 搜：先找到信息可能在哪
- 看：把内容真正读到
- 做：在页面上执行点击、输入、上传、提交
如果一个 Skill 提供的工具，正好覆盖这三类能力，而且边界讲清楚了，那么它就是一个接近完备的工具集合。
3. 为什么要强调“边界讲清楚”？
因为模型不是天然知道每个工具什么时候最好用。
你要告诉它：
- 什么时候用搜索引擎做发现
- 什么时候直接读页面正文
- 什么时候要拿原始 HTML
- 什么时候必须进入浏览器
否则模型就容易出现两个问题：
- 有工具，但用错了工具
- 工具之间来回摇摆，浪费上下文和时间
所以 Skill 不是只列一个工具清单，而是要补齐一张“工具能力地图”。
4. 一个很重要的取舍
做通用 Skill 时，常见误区是：
- 要么什么都想支持，结果复杂到模型根本用不好
- 要么工具太少，看起来简单，实际上经常卡死
这就是为什么“最小完备”这个词很关键。
它强调的不是最多，而是够用且成体系。
六、第三部分：必要的事实说明
1. 模型知道很多，不等于任务里一定想得起来
这是 Skill 设计里最容易被忽视的一点。
很多人会想：
这些知识模型不是早就知道吗？为什么还要写进 Skill？
问题在于，模型“知道”和模型“此刻会主动调用出来”，不是一回事。
任务执行时，模型经常会忘掉一些很关键、但又不会自动浮到台前的事实。
这类信息我更愿意叫它：
惰性知识
也就是它本来可能知道，但在当前任务里不会优先想起来。
2. 哪些事实适合补进 Skill？
一般有三类：
- 容易被忽略的环境事实
- 明显影响成败的边界条件
- 明显影响安全的高风险约束
举几个很典型的例子：
- 某类页面其实必须登录态才能稳定获取
- 某些反爬站点不适合用静态抓取
- 浏览器自动化可能误碰用户已有标签页
- 某个脚本就是当前环境下最稳的最优路径
这些东西如果不写，模型未必不会做出来。
但它往往要多试几轮，踩几个坑，才慢慢摸到。
而 Skill 的价值之一，就是把这种本该提前知道的事情，前置成“必要事实”。
3. 这里有个边界：不是把所有事实都塞进去
必要事实说明，不等于百科全书。
它强调的是：
- 跟当前场景强相关
- 明显影响决策质量
- 经常被模型忽略
如果什么都塞，Skill 很快就会膨胀。
最后模型读到的是一堆信息，但真正关键的提醒反而被淹没了。
七、为什么“别把路径写死”反而更高级？
这是 Skill 设计里一个非常反直觉、但很重要的点。
很多人以为：
我把步骤写得越细，模型越不容易跑偏。
这句话只在两类任务里成立：
- 高重复、低变化的流程任务
- 环境非常稳定的封闭任务
但对通用型 Skill 来说，过度指定路径会带来三个问题：
1. 会压掉模型的环境判断能力
模型本来可能根据页面状态、工具反馈、上下文证据，选择更合适的路径。
一旦你把路径写死，它就更可能为了“服从说明书”而忽略真实证据。
2. 会把你的偏见也一起写进去
设计者以为的“标准流程”，往往只是某个场景下碰巧好用。
一旦环境变了，这个流程就可能从最佳实践，变成错误锚点。
3. 会让 Skill 丧失泛化能力
越依赖具体路径，越难迁移到新站点、新任务、新上下文。
所以，更成熟的 Skill 写法通常是：
- 把判断原则讲清楚
- 把工具边界讲清楚
- 把关键事实讲清楚
- 只在少数确实存在最优路径的地方，直接指定做法
这才是“既给约束，又留智能”的写法。
八、一个很实用的写法模板
如果以后我们自己写 Skill，我觉得可以按下面这个顺序来组织：
1. 这个 Skill 解决什么场景
先说适用范围，而不是先上步骤。
比如：
- 当用户要求联网搜索、读取网页、操作页面时使用
- 当任务涉及站内搜索、动态页面、登录态内容时优先考虑浏览器方案
2. 这个场景的策略哲学
写清楚这个场景里：
- 应该先定义什么
- 怎样判断当前路径是否有效
- 遇到障碍怎么调整
- 什么叫完成，什么时候该停
3. 可用工具及其边界
列出模型手里的能力，并明确：
- 各自适合什么
- 各自不适合什么
- 什么时候该升级手段
4. 必要事实说明
补那些模型容易忘、但很关键的事实：
- 环境限制
- 登录约束
- 风险边界
- 最优路径
5. 少量明确规则
比如：
- 不操作用户已有标签页
- 不在同一种失败路径上反复重试
- 任务完成后关闭自己创建的资源
这种规则不需要很多，但必须足够硬。
九、两个常见误区
误区一：把 Skill 写成 SOP 大全
表现是：
- 每一步都想规定
- 每个分支都想提前写完
- 最后变成一份超长流程图
问题在于，现实任务分支太多，写不完。
而且你写得越细，越可能误导模型忽视现场证据。
误区二：只有理念，没有落地工具
还有一种 Skill 很“高级”，里面全是原则：
- 关注目标
- 灵活应变
- 根据反馈调整策略
听起来没问题。
但模型真正开始做事时，却发现：
- 没工具
- 工具边界不清楚
- 环境事实没人交代
最后就会变成“思想很先进，执行很原始”。
所以，理念和工具必须一起交付。
十、这套设计哲学最打动我的地方
我觉得这套思路最有价值的地方，不是它教人怎么写一个联网 Skill。
而是它给了一个更通用的启发：
写 Skill，本质上不是在写命令，而是在给 Agent 植入一个场景化的工作心智。
这件事一旦想通，很多东西都会变：
- 写代码审查 Skill，不只是列检查项，而是先校准“怎么发现风险”
- 写写作 Skill，不只是列文章结构，而是先校准“怎么理解读者和目标”
- 写调研 Skill，不只是列搜索步骤，而是先校准“什么算可信来源、什么算完成”
也就是说，Skill 的高级感，不在于它有多复杂。
而在于它是否真的改变了 Agent 在该场景里的思考质量。
十一、奶奶版总结
如果让我用最直白的话收尾，那就是：
- 差 Skill：像拿着一本死板流程表干活
- 好 Skill：像老员工把“做这类事的脑子”传给了新人
再压缩成一句：
Skill 不是替 Agent 思考，而是帮助 Agent 在某个场景下更好地思考。
把这句话想明白，后面无论你写联网 Skill、调研 Skill、写作 Skill，方向都会更稳。
十二、小结
- Skill 的核心不是堆步骤，而是校准 Agent 在场景中的思考方式。
- 通用型 Skill 更适合写“策略哲学”，而不是写死操作路径。
- 工具不是越多越好，关键是形成最小完备工具集。
- 很多失败来自“惰性知识”没被唤起，所以要补必要事实说明。
- 一个真正强的 Skill，本质上是在交付场景化工作心智。
参考
- 一泽 Eze，《Web Access：一个Skill，拉满Agent联网和浏览器能力》，微信公众号，2026-03-23。