从 Anthropic 到 OpenClaw,Agent Skills 正在成为软件行业新底座
时间拉回到2026 年 2 月 5 日，一个普通的星期四。
Anthropic 没有发布新模型，没有宣布什么算法突破，只是悄悄上线了一个叫 Claude Cowork 的产品，顺带发布了 11 个”技能包”。
然后，纳斯达克软件板块单日蒸发了 2850 亿美元。
高盛的软件股组合跌了 6%，法律科技公司 LegalZoom 暴跌 20%，汤森路透暴跌 16%。业内人把这一天称为”SaaS Apocalypse”，翻译过来就是——SaaS 末日。
我第一次看到这个新闻的时候，反应和很多人一样：11 个技能包？就这？
直到我认真研究了背后的逻辑，才意识到，资本市场的那种恐慌，是有道理的。
要理解这件事，得先回到一个最基础的问题：软件公司靠什么赚钱？
传统 SaaS 的商业模式，本质上是一套”三明治结构”：底下是数据，中间是业务逻辑，最上面是一层图形界面（GUI）。用户要用这个软件，就得学会这套界面——怎么上传文件，怎么配置规则，怎么导出报告。
这套界面，看起来是在”方便用户”，但本质上是一道锁。你学会了 A 家的界面，换 B 家就要重新学。你的数据在 A 家的系统里存了三年，迁移成本极高。软件公司通过这道锁，形成了对用户的绑定，也形成了对竞争对手的护城河。
所以你会看到，过去二十年，SaaS 公司最在乎的事情，就是 UI 好不好用，流程顺不顺畅，设计美不美观。产品经理的核心使命，是让用户”爱上”这个界面。
Agent Skills 出现之后，这个逻辑被从根上断掉了。
买一套法律科技软件（比如 Harvey AI，或者汤森路透的某个产品）→ 员工学习怎么用这套系统 → 手动上传合同 → 配置审查规则 → 等系统跑完 → 手动复核结果 → 导出报告。
整个过程，人要参与好几个环节，软件的 UI 是绕不开的中转站。
加载了 Legal Skill 的 Agent 是这样做的：
Agent 直接访问企业云盘里的合同文件 → 按照 Skill 里内置的法律 SOP，自动进行风险比对和条款审查 → 直接输出合规报告。
用户全程不需要打开任何软件界面，不需要学任何操作，甚至不需要知道中间用了什么工具。
Agent 时代，用户不再需要一个”好用的工具”。用户要的，是”直接的结果”。
黄仁勋对这件事的判断是：”AI 不会消灭 SaaS，SaaS 只是变成了基础设施。” 这句话听起来在给 SaaS 公司留面子，但仔细想想，”基础设施”意味着什么——水电煤也是基础设施，但没有人会说自来水公司”掌握用户入口”。
Agent Skills 消灭的，不是软件本身，而是软件的独立入口权。
很多人看完上面的描述，第一反应是：这不就是 API 吗？或者：这不就是 Workflow 吗？
Tool 是单一能力，比如”调用天气 API”、”搜索数据库”，它只会做一件事。
Workflow 是任务编排，把 A → B → C 几个步骤串起来，但它是静态的，流程是提前写死的。
MCP（Model Context Protocol）是通信协议，解决的是 Agent 和工具之间怎么”说话”的问题。
Skill 不一样。一个完整的 Skill，应该包含：Prompt 策略（怎么理解任务）、Tool 调用链（用什么工具、按什么顺序）、SOP 流程（业务标准作业程序）、Memory 机制（记住什么、忘掉什么）、权限控制（能访问什么、不能访问什么）、失败恢复机制（出错了怎么办）。
用一个不太严谨但很直观的比喻：Tool 是一把锤子，Workflow 是一张施工图，而 Skill 是一个有经验的工人——他知道什么时候用锤子，什么时候用电钻，出了问题怎么处理，还记得上次这类活儿是怎么做的。
所以 Skill 被定义为：可复用的业务执行单元。
在技术层面，Skill 的标准形态是一个 skill.yaml 文件，里面定义了 name、description、trigger（触发条件）、tools（调用的工具链）、workflow（执行流程）、permissions（权限范围）、memory（记忆策略）、output_schema（输出格式）等字段。
有人把 skill.yaml 类比为 Docker 的 Dockerfile，我觉得这个比喻挺准确。Dockerfile 定义了一个容器环境，让代码能在任何地方跑起来；skill.yaml 定义了一套业务能力，让 Agent 能在任何地方调用它。
理解了 Skill 是什么之后，再来看 OpenClaw 就容易多了。
截至 2026 年 2 月，OpenClaw 在 GitHub 上的 Star 数已经逼近 20 万。这是一个什么概念——它超过了当年的 AutoGPT，超过了 LangChain，成为全球开发者构建 Agent 应用时的首选框架。
OpenClaw 的设计哲学，用四个字概括：万物皆技能。
主程序是空的。不是说代码写得少，而是它在设计上就故意把自己掏空——核心只负责调度，不负责任何具体能力。当你说”帮我分析这份财报”，系统才去仓库里拉取 Financial_Analysis_Skill，加载进来跑，跑完之后卸载，释放资源。
对比一下传统 Agent 的问题：Prompt 全写死在主程序里，Tool 全耦合在一起，功能越加越多，Context Window 动不动就爆，维护起来一团乱麻。
OpenClaw 的解法是彻底的解耦——Agent 只是个操作系统，Skills 是装在上面的 App。
用户不再需要安装 100 个不同的 AI 工具，只需要在 OpenClaw 里挂载 100 个不同的 Skills，一个入口解决所有问题。
OpenClaw 真正的护城河，不是代码，而是它背后的技能生态平台——ClawHub（clawhub.ai）。
这里汇聚了全球开发者贡献的超过 5 万个标准化 Skills。你需要一个 K8s 集群管理技能？有。需要追踪小红书热帖？有。需要自动审查法律合同？有。所有 Skill 都遵循统一的 skill.yaml 标准，拿来就能用，不需要任何适配。
有人把 ClawHub 和 App Store 做了对比，我觉得这个类比非常贴切：App Store 属于移动互联网，Skill Store 属于 Agent 互联网。
移动时代，开发者争的是在 App Store 里被下载；Agent 时代，开发者争的是在 Skill Store 里被调用。商业逻辑变了，但”分发平台”的核心价值没有变。
OpenClaw 还有一个让我觉得有点”细思极恐”的特性：Autonomous Skill Refinement，直译叫”自主技能提炼”。
简单说，Agent 不只是会用 Skill，还会创造 Skill。
比如你让 OpenClaw 做一件以前没做过的事：”每天早上 8 点爬取 arXiv 最新论文，把摘要翻译成中文，发到我的飞书群。”
Agent 执行完这个任务之后，你可以对它说：”把刚才的流程固化成一个 Skill。”
然后 OpenClaw 会自动把刚才的操作步骤、Prompt 策略、API 调用逻辑打包成一个标准的 skill.yaml 文件。你可以把它上传到 ClawHub 分享给所有人，也可以私有化保存，下次直接复用。
使用即开发。这句话听起来很轻巧，但背后的含义是：软件开发的门槛，正在被大幅压低。
以前写一个自动化工作流需要半天，现在直接用自然语言描述一遍，让 Agent 跑一遍，Skill 就生成了。Prompt Engineer 正在悄悄进化成 Skill Engineer，而 Skill Engineer 要具备的核心能力，不是写代码，而是把业务流程抽象成可执行单元的能力。
四、Base Model + Skills：80% 场景的黄金组合
在 Agent Skills 出现之前，业界有一个根深蒂固的假设：要解决垂直领域的问题，必须构建垂直领域的专用 Agent。
这个假设催生了大量的”重型开发”项目——收集海量领域文书做微调，搭建复杂的私有 RAG 系统，甚至重新设计模型架构。成本极高，周期极长，做出来的东西泛化能力又很差，换个场景就歇菜。
Agent Skills 提供了一个完全不同的思路：通用大模型 + 特定技能包 = 解决垂域问题。
一家公司日常处理的合同审查、一家企业例行做的竞品分析、一个部门每周要写的汇报——这些任务看起来很”专业”，但本质上是流程固定、逻辑标准、可以被 SOP 完全覆盖的工作。
对于这类任务，你不需要一个”法学博士”级别的 AI。你需要的是一个足够聪明的通用 Agent，加上一个把专业 SOP 封装好的 Skill。这个组合，可以以 90 分的水平完成 80% 的垂域工作。
第二个原因：基座模型的能力，正在进入”智商溢出”阶段。
2026 年的通用大模型，其基础推理能力已经远超 2024 年专门微调过的垂直小模型。过去我们微调模型，是因为通用模型太”笨”，不做适配就用不了。但现在通用模型已经足够”聪明”，适配的工作可以完全交给 Skill 来做——Skill 提供经验，Base Model 提供推理，分工比微调更清晰，迭代也更快。
不再通过”改模型”来适应任务，而是通过”给技能”来适应任务。这一句话，基本概括了 2026 年 Agent 开发范式的核心转变。
说了这么多 Agent Skills 的好，该说说它的边界了。
有一类声音认为：既然”Base Model + Skills”能解决 80% 的问题，垂域 Agent 是不是要消失了？
有些领域的问题，不是”流程标准化”能解决的。科研 Agent 需要真正理解领域知识，做出非标准的推理判断；高端医疗 Agent 面对的是高度个性化的病例，不能靠套 SOP；核心系统编程，涉及的是对整个代码库的深度理解和全局推理。
以编程领域为例。Claude Code 单独存在是有道理的——它不只是”挂了一个 Coding Skill 的通用 Agent”。大型系统重构、复杂并发问题、编译链调试、Runtime 环境的测试闭环……这些问题需要的不是流程 SOP，而是对代码逻辑的深度推理能力。这种能力，需要在模型层面做专项训练，不是 Skill 能提供的。
结论其实很清晰：Skill 能解决流程问题，Specialized Model 才能解决深度推理问题。
“Base Model + Skills”横扫了 80% 的标准化应用场景，剩下 20% 的硬骨头——科研、高端医疗、核心系统编程——依然是垂域 Agent 的护城河，而且这道护城河很深，短时间内不会被 Skills 填平。
如果你是一个做 AI 应用开发的工程师，或者正在考虑往这个方向转型，有三件事是现在就应该开始掌握的。
这是最基础的一层。你要理解 Agent Skills 的标准运行机制，知道怎么在 Anthropic 或者 OpenClaw 的生态里检索合适的 Skill，怎么配置、编排和调度多个 Skills 来完成一个复杂任务。这一层的核心是”会用现成的”。
这是进阶的一层。核心能力是：把一个业务 SOP 产品化，把专家经验结构化，封装成别人可以直接调用的 Skill 文件。完整的 Skill 开发流程包括：需求定义、Workflow 设计、Prompt 策略设计、Tool 接入、Memory 机制设计、权限控制。每一步都有讲究，但最难的不是技术，而是把模糊的业务逻辑梳理成精准的可执行单元的那种抽象能力。
这是最底层的一层，也是真正拉开差距的地方。你需要理解”核心极简”的解耦架构，从底层开发出支持动态挂载、卸载和智能调度 Skills 的 Agent 运行环境，处理好 Skill Router（怎么判断调用哪个 Skill）、Context 管理（上下文怎么在 Skill 之间流转）、权限系统和沙箱机制。
未来真正好用的 Agent，架构一定是”核心极简 + 技能外挂”。主程序越简单，生态越丰富，能力越强——这个逻辑，和 Linux 内核的思想一脉相承。
有一个问题我想在结尾问一下：互联网时代，人在使用软件；Agent 时代，Agent 在使用软件。那么，软件公司应该讨好谁？
UI 不再是中心，App 不再是入口，用户体验不再只是指”人的体验”，还包括”Agent 调用这个 Skill 时的体验”。
下一代软件公司，卖的可能不再是 SaaS 订阅，而是一个个可以被 Agent 调用的”能力 Skill”。你的竞争优势，不再是界面做得多漂亮，而是你封装的 SOP 有多精准、工具链有多稳定、在 Skill 生态里被调用的频率有多高。
不是软件消失了，是软件的角色变了。不是 SaaS 死了，是 SaaS 退到幕后去了。真正站到台前的，是 Skill——那个安静地封装着人类业务经验，等待 Agent 来调用的东西。
你所在的行业，哪些 SaaS 最可能第一批被 Skills 替代？欢迎评论区聊聊。
夜雨聆风
