Hello，大家好，我是人月聊IT。今天接着AI和大模型方面的话题。即大模型厂商Anthropic最近刚推出的Claude Skills。为了更好地阐述我后面要描述的观点，我们还是先看下对于Claude Skills的一些标准解释和说明。
图片
Claude Skill 是 Anthropic 推出的一种功能扩展机制,允许用户为 Claude 添加自定义的能力和工具。简单来说,它让 Claude 能够:
- 连接外部服务和 API:如数据库、第三方应用等
- 执行特定领域的任务:根据用户需求定制专门功能
- 扩展知识边界:访问实时数据和专有信息
Claude Skill 的推出主要解决了以下问题:
- 个性化定制:不同用户有不同需求,Skill 让 Claude 能适应特定工作流程
- 实时数据访问:突破知识截止日期限制,获取最新信息
- 自动化工作流:将 Claude 集成到现有业务系统中
- 提高效率:减少重复性手动操作
对于一个完整的Skill技能定义通常包括了知识库，工具，技术，方法步骤，约束等内容。比如一个参考的目录架构如下：
图片
当然，我们可以也可以为互联网架构师定义一个叫软件架构师助手的Skill，具体如下：
复制所以从上面定义也可以看到，一个Skill包括了方法流程，知识库，操作规则和约束，工具技术，参考示例等各个方面的内容。
当你看了这个定义是不是感觉和提示词工程，MCP上下文工程很类似，或者感觉这就是一个结构化文字定义的AI Agent？那么我们究竟应该如何去理解Skills呢？这里给出一个简单公式：
Skills = 大模型+方法（worflow+规则)+工具(mcp call)+知识库(rag或其他知识形态）
大家都知道对于大模型，它一直在想方设法的拓展它对外部的一些边界和能力。从最早的Function Call到MCP上下文工程，再到A2A Agent协议，所有的这些都是为了更好的扩展大模型的知识边界，方便大模型和外部的协同。但是实际仍然很难达成满足我们垂直业务场景的需求目标。
也正是这个原因，我们在大模型上面构建了大量的AI Agent智能体。大家不要把Agent理解为一个应用，或者说具备了任务规划分解执行记忆能力的智能体。Agent更加重要的是沉淀了你面对业务场景和垂直域问题解决的业务经验，这才是Agent真正的价值。
但是我们在前面也专门强调过，随着大量的Agent的开发，实际是造成了大量的AI应用信息孤岛，后续难以运维和运营管理。这个问题不是简单的通过A2A协议就能解决的问题。也正是这个原因，我在前面也专门谈到了应该结合MCP去构建一种更加通用的智能体来解决问题。
包括我当时也提出了企业级AI应用的新范式，即：
图片
在大模型具备深度推理能力后，企业级AI应用目标是构建一个通用性AI智能体，提供面向业务场景和问题的端到端输出，在这个过程中需要进行问题规划理解，拆分，行动，归纳总结，复盘，记忆能力。企业级AI应用不应该是再开发一个个独立的AI Agent信息孤岛。
MCP Sever能力接入可以穷举，但是AI Agent定制化开发难以穷尽，一个个去开发Agent思路将被淘汰，这个本质仍然是开发了大量上层的AI应用信息孤岛。
而对于Claude Skill的推出，也进一步加强了我原来的一些观点。对于里面的一些关键点，我准备再展开进行说明如下：
从知识到技能
为了更好的解释上面的观点，我仍然将Skill翻译为技能，来探究下从知识到技能的过程。首先我们要有一个重要的观点，就是：知识是结果，而技能是应用知识达到结果的方法过程。同样的知识不同的人用，那么最终的结果质量可能千差万别。
图片
如上图，张三有一个技能就是应用知识解决问题。比如应用架构类的知识去进行一个架构设计。但是应用架构类知识实际就包括了两个方面的关键内容，即：
- 显性化知识：架构规范，模板，知识库
- 隐性知识：个人私有经验，最佳实践
那么张三拿到一个需求后实际是如何做这个事情呢？一个方面就是要参考标准规范模板和约束，一个是应用相关的架构设计工具，然后就是自己的私有经验发挥作用。这个私有经验原来并没有显性化。或者说拿到需求到架构设计完成都是张三一个人做这个事，张三甚至连需求的完整结构化描述这个事情都不会做，因为没有必要。这也是我们经常说到的，传统问题解决模式下，由于问题定义和问题解决都是我自己，我甚至没有做好关键的问题定义和问题解决两个工作的分离，但是不影响我最终结果输出。
好了，如果现在张三很忙，需要李四来帮助进行架构设计。这个时候仅仅提供给李四相关的架构规划和模板，李四就能够输出同样质量的架构文档吗？
答案显然不是，因为张三的私域经验没有显性化。
那么为了让李四输出的文档尽量达到我们的希望要求，我们经常做的事情就是张三会单独给李四交代，做这个事情的时候哪些地方是关键点你要注意，哪些历史项目案例你可以参考，输出的架构哪些地方要注意检查，哪些集成点不要疏漏？只有把这些交代清楚，李四可能才能够很好的去做这件事情。
所以你把这个理解清楚后，就更加容易理解，为何当前简单的提示词，RAG库等实际很难让大模型得出我们需要的结果。
知识固然重要，但是应用知识通达目的地的路有千万条，我需要大模型走符合我真实工作或业务场景的路，那么就得将我的私域经验显性化表达出来，类似原来的提示语工程，或者Agent开发的Workflow和规则定义。而现在Skills也是这个思路。方法，工具，技术，知识这些经验都需要你提前定义好，给AI一个更加准确的操作手册，让AI按你的既定轨道运行。
所以Skills实际是隐性经验的极大成者。知识可以解决通用场景问题，但是只有知识+技能才能够更好的解决特定场景下的业务问题。这个和大模型可以解决通用问题，Agent可以解决特定问题是一个道理。
当把这个理解清楚后，我们再来看关系：
Skills和MCP的关系：实际技能模板纳入了解决特定场景问题需要的工具和外部能力，这些能力可以是通过MCP的方式接入。或者你也可以理解为通过Skills定义对MCP能力进行组装和编排。
Skills和Agent的关系：在我们谈云计算的三层分层模型就一直在强调，底层是资源层，中间是能力和服务层，上层是应用层。那么对应到过来也是一样的道理，底层大模型是资源层；中间Skills是能力和服务层；上层Agent是应用层。原来编写在Agent里面的规则和Workflow等定义实际是应用和能力高度紧耦合。我们现在需要的是将Agent里面能复用的能力解耦出来，沉淀到Skills技能层，这是后续实现Agentic AI能力的基础。
Skills和RAG的关系：在Skills定义中会更加清楚的说明具体知识库的应用规则，给出更加准确的知识库知识的应用规则约束。让AI查找知识有的放矢，而不是漫无目的的检索。类似我们说的Agentic RAG能力
图片
所以昨天刚好在群里面看到一篇文章，就是有一个企业架构的顾问，他就让ClaudeSkill帮他生成了一个作为资深的企业架构顾问需要的这么一个Skill的技能库，然后基于这个技能库让他去做了一个行业的企业架构规划分析，这个事情看起来挺不错，但是实际上没有任何的意义。
原因就是什么？
这个知识本来就是大模型已有的知识，这个技能库大模型本来就有，你只是把这个东西显性化了，你即使不做这个事情，你让大模型帮你做一个行业的企业架构分析，它基本上也能输出这个结果。
所以技能库的核心是你个人结合行业，结合你自己的工作岗位，你特有的一些私域经验的显性化表达，这个才是技能的重点。
这个东西在原有的AI大模型知识库里面它是没有的。
举一个最最简单的例子，我们一个软件开发团队，我架构师就有这么一个你核心的代码审查的经验，或者是问题排查的经验，他把他的这些经验把它显性化为一个技能，好了，有了这个技能以后，他相关的开发人员你要去做问题分析，代码的审查你不用找我了，你直接把我的技能库拷过去，你运行这个技能库去做代码分析，你得出的结果跟我帮你做这件事情基本上是一样的，这个才是真正的价值。
所以我一直强调技能这个东西它一定是私有经验的显性化的表达，它更强调了方法过程，而不是最终的知识库这么一个结果。
复杂问题求解-问题分解+技能组合
这个是我今天要强调的第二个重要内容。通过前面分析大家可以看到，实际Skills的很多东西在原来的提示词定义，MCP上下文工程或者Agent开发里面都有。那么为何我这次给Skills这么高的一个评价？
因为Skills技能模式真正解决了知识的模块化或者叫知识的可复用问题。我们所有复杂问题的解决，都是底层技能组件的能力组合。定义单个Skill技能的时候你可能还无法看到作用，但是上升到企业或组织级别，如果能够定义整个组织的可复用技能库，那么价值巨大。
所以这里先回顾下我原来讲的复杂问题解决：
图片
简单解释下上面这个图，对于任何问题的解决后，我们需要对解决方案进行拆分，拆分为可以复用的知识点或经验点。对于复杂问题你很难找到完全1对1匹配的现成解决方案，那么我们对复杂问题的解决，本质是首先要对复杂问题进行拆解，将其变成一个个子问题，然后在细粒度上面，我们就容易从知识技能库找到对应的解决方案进行匹配，最终再将子问题的解决糅合成一个完整的解决方案。
这个思想实际和我经常谈到的SOA架构里面的找到可复用服务，然后基于目标场景和目标快速的组装和编排服务一样的道理。
因此任何复杂场景复杂问题的解决，它更多的都是应该是底层可复用的技能组件的组合。你定义可复用的单个技能组件不是重点，你企业去沉淀这么一种可复用的技能组件库才是真正的重点。因为任何复杂的问题它都可以拆解，拆解完以后，它就是底层各个经验，各个组件库的一个组合。
图片
举个简单例子。
我现在想要写一个应标的PPT演示文档，但是这个事情我把它拆解以后可以看到，第一个它是首先是要去写word的文案，接着我要找一个PPT的高手帮我来做PPT。第三个步骤我可能还要找一个美工UI人员对这个 PPT进行美化。
那做完这个事情其实就涉及到三个Skill技能，如果你企业大模型已有的技能库里面刚好有这么三种的技能组件，那么你就可以快速的去组装编排，达成你最终的一个目标。
在大模型没有Skill技能这个概念之前，我们怎么样做这个事情呢？
我们往往是去做了一个做应标PPT的一个 AI Agent智能体，来达到同样的目的。但是大家要注意，企业面对的问题场景层出不穷，千差万别，如果应对不同的问题，你都要去做这么一种AI智能体的话，那你可能要做成千上万个智能体，你才能够真正满足企业的需求，而且这对智能体就是一堆的信息孤岛难以维护。
真正的做法应该是去识别企业里面可复用的各种技能，把它变成一个个技能的定义或者叫技能组件。场景没法从穷举，但是结合企业实际的行业垂直的情况，我们的技能库它是可以穷举的，这种技能库就带来了在企业里面资深的有经验的人，他真正的经验做了显性化的沉淀，这种知识这种经验是可以在企业内部迁移的，而且这种知识经验由于有大量私域经验的沉淀，它是通用的互联网的大模型没有的能力，这个才是我们真正需要的东西。
所以我一直在强调随着技能这个概念的拓展，大模型在企业内部在行业内部垂类的个性化的应用一定会加速。有了这个技能库，等于是我们每个人都配了一个AI的一个外挂或者是AI数字分身，发展到后面就是每个组织都配置了符合企业要求的满足特定技能的数字员工。这才是大模型向企业端进化的关键模式和方法。
