文章摘要
2025年下半年推出的Agent Skills知识封装格式,半年内成为智能体领域通用开放标准。一场16分钟行业分享提出,智能体落地无需从零搭建专属智能体,应聚焦封装可复用技能单元,解决行业知识难沉淀、重复开发成本高的痛点。经十个月实践该思路得到验证,推动智能体架构收敛,行业差异化竞争将转向上层专业知识封装。

2025年下半年,一款名为Agent Skills的知识封装格式正式推出,短短半年时间就成为智能体领域的通用标准。一场16分钟的行业分享中,两位技术专家提出了一个颠覆当前AI落地思路的判断:与其投入精力从零搭建专属智能体,不如专注构建可复用的技能单元。当时这更像是行业的一次务实探索,但随着时间推移,这个判断的价值愈发凸显。

2025年12月,这款格式被正式发布为开放标准,同时上线了组织级管理和合作伙伴技能目录。到2026年,包括主流智能体产品在内的数十款工具已经开始支持同一份SKILL.md文件格式,这种跨厂商的普及速度在AI领域并不多见。

智能体落地的范式转变

2025年前后,行业对智能体的想象还停留在宏大的通用智能体概念上,认为一个统一的智能体可以连接所有工具,端到端完成复杂工作。但同时,行业也一直存在质疑:随着任务链条拉长,智能体的执行可靠性会出现漂移,经常会出现自以为完成任务但实际并未完成的情况。

这场分享实际上在这场争论中选择了一个更务实的方向:与其继续为智能体添加复杂的架构层,不如将专业知识封装为可稳定调用的单元。本文将结合分享内容和后续10个月的行业实践,为正在探索智能体落地的从业者提供参考。

智能体的通用性与代码的核心作用

在更早的设想中,不同领域的智能体需要专属的架构和工具,每遇到新场景就要重新搭建一套系统。但实际落地后发现,底层的通用智能体已经具备了很强的通用性,领域定制化更多体现在专业知识层面,而非架构本身。

有专家提出,代码就是智能体连接数字世界的核心接口。以生成财务报告为例,智能体可以通过调用API获取业务数据,将信息整理到文件系统中,用代码完成数据分析,最终合成完整的专业报告。整个流程不需要专门为财务场景开发专属的智能体架构,只需要可靠的语言模型、可用的运行环境和清晰的执行逻辑即可。

这一思路让智能体的核心脚手架被简化到极致,只需要基础的命令行和文件系统即可支撑大部分场景。但同时,另一个更关键的问题也浮现出来:如何让智能体拥有领域专业知识?

智能体不缺智能,缺的是知识沉淀

比如报税场景,比起一个智商超群但不懂税务法规的模型,一位深耕税务领域多年的专业人士显然更可靠。因为报税不需要从零推导税法条款,而是需要稳定、一致的执行流程,这只能来自领域专家的经验沉淀。

当前的智能体就像这位智商超群但缺乏专业经验的专家,它们可以在投入足够指导后完成复杂任务,但在任务开始时往往缺少关键的领域上下文,无法有效吸收组织内部的专业知识,也不会随着时间自动优化。

这正是当前智能体落地的普遍痛点:企业需要反复向AI解释任务背景,员工总结的经验无法沉淀到系统中,不同人员使用同一工具得到的输出质量差异巨大。Agent Skills正是为解决这个问题而生的。

Agent Skills的核心思路是将可复用的过程性知识打包成结构化的文件集合,用更通俗的话来说,技能就像一个标准化的文件夹。这种设计的初衷是让任何人和任何智能体,只要有一台电脑,就能创建和使用技能。

技能不需要更换现有系统,可以用Git做版本管理,存储在云盘或者打包发送,完全利用行业已经成熟的文件协作习惯。这种看似简单的设计,实际上降低了技能的使用门槛,让非技术人员也能理解和修改。

企业中最难复制的从来不是书面的流程文档,而是老员工脑中的隐性经验:如何处理例外情况、如何快速识别异常数据、如何理解客户的真实诉求。这些内容难以用文字完整描述,过去只能依靠师徒制口口相传,人员流动后经验就会流失。技能提供了一种折中方案,可以将反复使用的步骤化知识固定下来,完成从个人经验到组织资产的转化。

技能的构成:脚本作为工具与渐进式加载

技能不仅仅是普通的文件夹,其中还可以包含脚本文件,这些脚本可以直接作为智能体的工具使用,这也是技能相对于传统工具的结构性优势。

传统的工具往往存在几个固有问题:说明文档模糊导致智能体无法理解、实现存在缺陷时智能体无法自行修复、工具始终占用上下文窗口无论是否需要使用。而脚本可以解决这些问题:代码自带自文档,智能体可以直接读取理解;遇到问题时智能体可以自行修改代码;脚本可以存储在文件系统中,只有在需要时才加载。

比如团队经常需要重复编写用于设置幻灯片样式的Python代码,与其每次都重新生成,不如将这段代码存入技能库,后续遇到相同任务时直接调用即可,既保证了流程一致性,又提升了效率。

随着技能库的扩大,同时挂载数百甚至数千个技能并保持可组合性成为挑战。因此技能在运行时采用渐进式加载机制:平时只向智能体展示技能的元数据,让它知道有这个技能存在;当智能体判断某个技能与当前任务相关时,才读取完整的SKILL.md文件,这个文件既是技能的核心指令,也是整个文件夹的目录,其余文件则按需加载。

至此,技能的定义可以总结为:一个包含脚本工具的结构化文件夹。这种设计将原本抽象的模型能力转化为可以被查看、修改的具体实体,解决了过去AI能力不透明的问题。

技能生态的三类形态与发展趋势

技能发布仅五周,就已经出现了数千个技能,行业将这些技能分为三类,这个分类在后续10个月中基本保持稳定。

第一类是基础技能,用于为智能体补充通用或领域专业能力。比如官方推出的文档技能,可以让智能体创建和编辑专业办公文档;第三方开发者开发的科研技能,可以让智能体完成电子健康记录数据分析和生物信息学库调用。

第二类是第三方合作技能,由生态伙伴为自身产品开发。比如浏览器自动化工具厂商推出的技能,可以让智能体更高效地完成网页浏览和操作;笔记软件推出的技能,可以帮助智能体更好地理解用户的工作空间。这类技能将厂商的产品能力转化为智能体可以直接调用的专业知识。

第三类是企业内生技能,也是最受关注的一类,这类技能针对组织内部的定制化需求打造。企业正在用技能教授智能体两件事:一是组织的优秀实践,二是内部定制软件的独特使用方法。同时,开发团队也在用技能部署智能体,并将代码规范和内部工作流程传递给智能体。

技能生态正在呈现三个明显的发展趋势:

  • 技能复杂度不断提升,从最初的简单提示词文件,发展到包含可执行程序、二进制文件、代码脚本和资源素材的完整包,开发和维护周期也从小时级延长到周级甚至月级,越来越接近软件的开发模式
  • 技能与模型连接协议形成互补,开发者开始编写专门用于编排多个工具的工作流技能,将外部数据和连接能力组合起来完成复杂任务
  • 非技术人员开始参与技能开发,财务、招聘、法务等领域的专业人员都可以为日常工作定制专属技能,这验证了技能降低智能体使用门槛的设想

这一变化改变了AI能力建设的组织分工:过去是技术团队开发工具、业务团队提出需求,现在业务团队可以直接将自身经验转化为智能体能力,组织中最懂业务的人员的经验首次有了可以固化和复制的载体。

智能体架构的收敛:Agent+MCP+技能库

综合来看,当前通用智能体的技术架构正在逐步收敛,形成了清晰的三层结构:

  • 最内层是智能体运行循环,负责管理模型上下文,控制输入输出的token
  • 中间层是运行环境和工具连接,为智能体提供文件系统和代码执行能力,同时连接外部工具和数据资源
  • 最外层是技能库,智能体可以根据任务需求动态加载对应的技能

这一架构带来的直接结论是:现在为智能体赋予新领域的能力,只需要搭配合适的工具连接和技能库,不需要从零开发专属的智能体。这一思路也得到了验证,官方在技能发布后很快推出了金融服务和生命科学两个垂直领域的产品,每组产品都搭配了专属的工具和技能,让智能体在专业场景中的表现大幅提升。

对于企业来说,这意味着AI落地的基本单位从“一个场景一个智能体”转变为“一组工具和一套技能”,不同场景可以共享底层智能体架构,只需要替换上层的专业知识和连接配置,大幅降低了重复开发的成本。

技能的工程化演进:像对待软件一样管理技能

随着技能数量和复杂度的提升,行业开始意识到需要像管理软件一样对待技能。这一方向的背后是知识积累单位的变化:使用提示词解决问题的交付物是一段临时文本,换个会话就会失效;而使用技能的交付物是结构化的文件集合,可以被版本管理、共享和迭代,真正属于组织。

当前技能的发展主要面临三个核心问题:

  • 测试与评估:需要更完善的工具来确保技能在正确的场景下被触发,同时衡量配备技能的智能体的输出质量。难点在于技能的触发本身是一个概率问题,描述过窄会导致技能无法被触发,过宽则会导致误触发
  • 版本管理:技能会随着时间迭代,配备技能的智能体行为也会发生变化,需要清晰追踪版本变更,以便在出现问题时回溯
  • 依赖关系:需要建立技能的依赖声明机制,明确技能依赖的其他技能、工具和运行环境,让智能体在不同环境中的表现更可预测

这些努力的目标不仅是服务于单一产品,而是让技能更容易被构建和集成到不同的智能体产品中。随着技能数量的增加,质量和安全问题开始浮现,相关的评估基准、依赖管理工具和版本发布方式也在逐步完善。

共享与演化:让智能体持续成长

分享的最后部分提到,技能的价值很大一部分来自共享和分发。最令人期待的愿景是建立一个由组织内部人员和智能体共同维护的能力知识库。

随着用户与智能体的交互、反馈和知识输入,智能体的能力会不断提升,团队和组织内的所有智能体都会同步进步。当新员工加入时,智能体已经熟悉团队的工作习惯和标准,可以快速上手完成任务。

这种价值还会向外溢出,就像社区贡献的工具可以提升智能体的能力一样,社区贡献的技能同样可以让更多智能体受益。当智能体本身也可以参与技能创建时,这种学习成果的迁移会变得更加高效,标准化的格式保证了智能体可以高效读取和使用自己生成的技能。

需要明确的是,技能并不会捕获所有类型的信息,它只专注于智能体在特定任务中需要使用的过程性知识。智能体可以根据需要快速获得新技能,也可以在技能过时后丢弃,对于快速变化的信息,上下文学习仍然是更高效的方式。

这场分享中最令人印象深刻的目标是:我们希望智能体在与你合作的第30天,比第1天强很多。现在这一愿景已经有了具体的产品实践,智能体可以通过工具自动创建技能,相关的自动评估和测试机制也在逐步完善。

总结:模型是处理器,技能是应用层

分享的结尾将智能体技术栈与传统计算机体系做了类比,清晰地定位了技能的位置:

语言模型就像处理器,需要巨额的研发投入和算力支撑,本身的价值有限;智能体运行时就像操作系统,负责协调资源和执行逻辑,提升处理器的使用效率;而技能就像上层应用,是将专业知识转化为实际价值的核心载体。

回顾这场分享的10个月实践,有三个核心判断已经得到验证:

  • 技能的抽象设计是正确的,它足够简单到被跨厂商接受,同时足够有用到成为通用标准
  • 企业智能体落地的核心痛点确实是知识沉淀,技能提供了比提示词和微调更高效的解决方案
  • 智能体的技术架构正在逐步收敛,真正的差异化竞争将来自上层的专业知识封装能力

如果你所在的团队还在为每个场景从零开发智能体,或许应该换个思路:将专业知识封装成可复用的技能单元,让智能体真正发挥价值。

关注AIGC与智能体技术,专注数字化转型与业务流程自动化,欢迎交流。

以上内容不代表本平台立场,仅供读者参考