目录
一、GPT-5.4和Claude 4.5谁更强？这个问题已经没意义了
二、从拼模型到拼Skill，本质是工程化分水岭
三、Skill到底是什么：一个可复用的认知-执行闭环
四、OpenClaw、Cursor、Claude Code的Skill路线对比
五、工程落地：Skill不是脚本，是对业务的重新建模
六、你的Agent系统有没有“可生长的能力层”
如果你最近还在纠结“GPT-5.4比Claude 4.5强多少”，大概率没在一线做Agent落地。
2026年5月，这个问题的答案已经不重要了。
头部模型的差距在快速收窄。MMLU、HumanEval这些基准上，前五名的分差不到两个点。你在生产环境换一个模型，用户完全感知不到。
但另一件事正在变得要命：同样用Claude 4.5，有人搭出来的Agent能自动处理工单、修Bug、跑完整条CI流水线；有人只跑了一个“帮我写段代码”的聊天窗口。
差距在哪？
不是模型能力。是Skill生态。
这个判断不是我说的。看看Anthropic最近的招聘方向，超过一半的岗位在招“Agent Tooling Engineer”。OpenAI的GPT Store早就改名成了“Actions + Skills”。Cursor把Skill定义成最高层级的付费功能。
很多人已经开始感觉到：模型调用太简单了，难的是一整套可复用的、带上下文的、能自动纠错的执行单元。这个东西，就是Skill。
今天我从业内工程视角拆一次：Skill到底是什么，它为什么成为新的壁垒，以及你该怎么规划自己的Skill策略。
一、GPT-5.4和Claude 4.5谁更强？这个问题已经没意义了
三月份，我参加了一场闭门的技术讨论。台上两拨人分别展示用自家模型做的UI自动化测试Demo。
一方展示：模型看截图，分析哪里可能有问题，输出一段建议。
另一方展示：模型看截图，识别到登录按钮偏右5像素，直接调用Playwright修正定位策略，然后重新截图验证，整个过程不需要人盯着。
同样的模型系列，效果天差地别。
为什么？
前一个团队把模型当成“高级API”，问一句答一句。后一个团队在模型外面包了一层Skill——这个Skill知道什么时候截图、什么时候调用视觉比对、什么时候执行重试、什么时候把结果写回Jira。
核心不在模型参数，在Skill的设计。
这在行业里已经不是个案了。Cursor去年底的爆火，本质不是它的模型多强（底层也是Claude和GPT），而是它的Skill做得足够深——能够理解当前光标位置、能解析整个项目上下文、能规划多步文件操作。
再看OpenClaw，那个让LLM控制电脑浏览器的开源项目。它的成功不是因为用了某个独家模型，而是把“鼠标移动”“点击”“滚动”“截图分析”这几件事串成一个可组合的Skill库。用户只需要告诉它“帮我订下周飞北京的机票”，Skill自动分解成十几个原子操作。
模型的通用能力已经不再是护城河。谁能在模型之上构建更厚、更稳、更适配业务的Skill层，谁才有真正的议价权。
本质是：模型能力正在变成像电力一样的基础设施。你不能说“我们家用的电更纯”来竞争，你要比的是“谁用这些电设计出了更好的电器”。
二、从拼模型到拼Skill，本质是工程化分水岭
为什么Skill突然变得这么重要？
三个原因，一个比一个靠近工程本质。
第一，模型的能力增长进入了平台期。2024年到2025年，每三个月模型能力就有质的飞跃。但从2025年下半年开始，边际收益明显递减。GPT-5.4比GPT-5.3强，但强得有限。你再怎么调prompt，也不可能让模型凭空多出“执行shell命令”或“访问内部数据库”的能力。这些能力必须通过工具、通过Skill来补。
第二，业务场景是长尾的。没有一个通用模型能覆盖你公司内部那套老旧系统的操作逻辑。模型可以看懂ERP系统的截图，但它不知道你们公司的“订单审批”按钮藏在第三级菜单下的那个蓝色图标。你需要Skill去教它：这个场景下，先调哪个接口，遇到什么错误回退到哪个操作。
第三，也是最关键的——成本结构在变。模型调用一次的成本在快速下降，但错误处理、上下文拼接、重试逻辑的成本却在上升。如果你每个Agent任务都要从头写一遍“截图-分析-执行-重试”的流程，人力和心智成本会让你放弃99%的场景。Skill把这些固化下来，一次编写，到处复用。
工程师视角看：Skill就是一个封装了“感知-决策-执行-反馈”闭环的可复用单元。
这个闭环一旦封好，上层Agent只需要声明“我要用哪些Skill”，不再关心内部细节。
行业内已经在用Skill区分Agent的质量等级：
等级1：没有Skill，每次都裸调模型，prompt长到爆，结果不稳定。
等级2：有几个原子Skill（如“截图对比”“执行SQL”），但彼此孤立，组合需要人工编排。
等级3：有一套可组合的Skill生态，Skill之间可以相互调用，能处理长链路任务。
目前大部分商业化Agent在等级2到等级3之间。Cursor、Devin、OpenClaw都在等级3。这也是为什么它们看起来比普通聊天式AI“聪明”——不是模型聪明，是Skill层替模型挡掉了大量低层次决策。
三、Skill到底是什么：一个可复用的认知-执行闭环
不要被“Skill”这个名字迷惑。它不是脚本，也不是插件。
脚本是一段线性指令：“打开浏览器，输入网址，点击登录”。执行完就完了，没有反馈，没有自适应。
插件是一个功能扩展：“我能帮你查天气”。被动等待调用。
Skill是带上下文的、能主动规划的、可组合的最小执行单元。
拆开看，一个标准的Skill包含四个部分：
触发条件：什么时候该调用这个Skill。可以是自然语言意图匹配，也可以是系统状态变化。
上下文声明：这个Skill需要哪些输入。比如“视觉定位Skill”需要一张截图和一个目标描述。
执行体：实际干活的代码或调用链。可以是本地命令、API请求、浏览器操作等。
反馈与修正逻辑：执行失败后怎么办。重试？降级？上报人类？
这四个部分一起，才构成一个Skill。
我拿一个真实的例子说明。
我们内部做了一个“UI视觉回归Skill”，代码不到80行。它的执行体很简单：调用Playwright截图，和基线做pixel diff，超过阈值就调GPT-4o做语义解释。
但真正让它成为Skill的，是另外两件事：
触发条件：当CI流程中检测到UI组件变更时自动触发。不是等测试人员手动跑。
反馈修正：如果第一次diff因为网络超时失败，自动重试两次。如果两次都失败，切换到本地缓存基线。如果语义解释返回空，降级到只输出pixel diff结果。
没有这些容错和自适应逻辑，它就只是一个脚本，不是Skill。
这也是为什么Skill生态难以复制——不是技术难，是需要在大量真实场景中踩坑、补逻辑、优化分支。你抄一个Skill的代码很容易，但抄不到它背后针对你业务的长尾适配。
另一个例子是Claude Code的“代码理解Skill”。它的触发条件是用户输入中包含“这个函数是做什么的”。它会自动做三件事：定位函数定义、读取相关调用链、生成自然语言解释。如果函数太长，它还会分段分析。这些分段逻辑是Skill内部写死的，模型不需要每次重新思考“我应该怎么处理长函数”。
Skill的本质，是把“模型需要反复思考的低层次问题”预置成确定性流程。模型只在关键决策点介入，其余全部走固定路径。这样既省钱，又稳定。
四、OpenClaw、Cursor、Claude Code的Skill路线对比
既然说到Skill，绕不开三个代表性产品。它们代表了三种不同的Skill设计哲学。
OpenClaw：原子Skill + 自由组合
OpenClaw把浏览器操作拆到最细：click、scroll、type、screenshot、wait。每个Skill只做一件事。然后让LLM决定组合顺序。
优点是灵活，任何网页操作都能组合出来。缺点是长链路任务容易失败，比如“先登录，再搜索，再点击第三个结果，再截图”——中间如果登录失败，LLM可能不知道回退。
Cursor：上下文感知的深度Skill
Cursor的Skill不对外暴露原子操作。它只暴露几个高级Skill：理解项目、重构、查找引用、生成测试。每个Skill内部封装了数十个原子操作。
优点是用户不用操心顺序，一个Skill搞定整个任务。缺点是Skill边界固定，想做自定义组合很难。
Claude Code：混合模式
Claude Code介于两者之间。它有一组基础Skill（读文件、写文件、执行命令），也支持用户自定义Skill（通过Skill配置文件）。而且Skill可以调用Skill，形成层级。
比如“修复Bug”这个Skill，内部会调用“定位错误”“分析调用链”“生成补丁”“运行测试”四个子Skill。任何一个子Skill失败，上层Skill可以决定重试或换策略。
从工程落地角度看，Claude Code的模式最接近生产环境需求。OpenClaw太底层，对LLM推理能力要求太高；Cursor太黑盒，出了问题不好调试。混合模式让你既能灵活扩展原子能力，又能用高层Skill封装复杂流程。
不管你选哪种，都绕不开一个事实：Skill的设计质量，直接决定了Agent的上限。
五、工程落地：Skill不是脚本，是对业务的重新建模
如果你在考虑把Skill引入团队，有几个坑需要提前知道。我用工程视角讲三个最关键的。
第一，Skill的粒度选择。太细了Agent决策负担重，太粗了复用性差。一个经验法则：如果一个Skill内部会调用同一个外部服务超过3次，或者会写超过50行代码，就该拆。如果一个Skill需要你在调用它之前做超过两个条件判断，就该合。
具体到视觉测试场景，我们把“截图比对”和“语义解释”拆成两个Skill。因为截图比对在大量场景中独立使用（比如验证某个元素是否出现），而语义解释只在diff超过阈值时才需要。如果合成一个，每次都要白花语义解释的费用。
第二，Skill的元数据管理。每个Skill必须有清晰的名称、描述、输入输出格式。这不是形式主义。LLM要通过这些元数据决定调用哪个Skill。描述写不清楚，模型就不调用或乱调用。
我们踩过一个坑：把一个“上报测试结果”的Skill描述写成了“保存数据”。结果模型在需要保存用户配置时也调用了它，把测试结果存到了配置表里。后来强制规定Skill描述必须包含“什么时候用”和“什么时候不用”。
第三，Skill版本与回滚。Skill和代码一样会迭代。新版本可能引入Bug。必须有机制让Agent可以锁定某个版本的Skill，或者在灰度阶段只给特定流量使用。
我们的做法是在Skill配置中加入version字段，Agent运行时根据场景选择版本。测试环境用latest，生产环境用固定版本。配合监控，如果新版本失败率上升，自动回滚到上一个稳定版本。
说这些是想表达一个观点：构建Skill生态不是一个技术问题，而是一个工程管理问题。你不需要攻克什么AI难题，你需要的是定义清楚接口、管理好版本、设计好 fallback。
六、你的Agent系统有没有“可生长的能力层”
Skill的下一个阶段是什么？
我认为是Skill的自动生成和进化。
现在Skill还靠人写。但已经有探索让模型自动生成Skill：你给它几个成功和失败的例子，它总结出共性的成功模式，固化成一个新的Skill。
这很像人类的学习方式：做一件事，复盘，提炼出经验，下次直接用。
如果这个方向走通，Skill就不再是一堆静态文件，而是一个可生长的能力层。Agent每处理一个任务，有可能产出新的Skill，供后续任务复用。
届时，不同Agent的差距会进一步拉大。一个跑了十万次任务的Agent，积累了成千上万个经过验证的Skill；一个新Agent什么都没有。这种差距，不是换个更强模型能弥补的。
对在座各位来说，今天就可以开始做的事：
盘点你的团队在日常工作中重复做三次以上的事情。选一个，封装成第一个Skill。
不用完美，只要它能在你的场景中稳定跑通。
然后第二个、第三个。
Skill不会从天而降。它来自你对真实场景的逐个击破。
最后问一个判断题：
如果让你的Agent系统在一个全新的业务领域跑通一个完整任务，你需要从零写多少胶水代码？这些胶水代码里，有哪些可以沉淀成跨领域通用的Skill？
