目录一、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上下文感知的深度SkillCursor的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本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。