过去两年，大模型领域最重要的变化，可能并不是模型参数继续扩大，而是 AI Agent 的整体架构正在发生根本性的转变。

早期的大模型应用，本质上仍然停留在“对话系统”阶段。无论是 Prompt Engineering，还是后来的 Function Calling、Tool Calling，其核心逻辑都非常简单：模型负责推理，工具负责执行，整个系统围绕“大模型 + Prompt + API”展开。这样的架构在 Demo 阶段效果很好，但一旦进入真实生产环境，很快就会遇到瓶颈。

因为真实世界中的任务，从来都不是一次函数调用能够解决的。

一个看似简单的企业流程，背后往往包含大量长链路、多步骤、强状态的操作。例如读取 PDF、分析 Excel、登录业务系统、填写表单、提交审批、发送邮件、更新数据库，这些步骤之间存在上下文依赖、状态恢复、异常处理与权限控制。传统 Tool Calling 更像是一次原子函数执行，而现实世界需要的，其实是一整套“程序化经验”。

这也是为什么，越来越多的 AI Agent 开始从“工具驱动”走向“技能驱动”。

近期关于 Agent Skill 的研究，本质上就在重新定义下一代 Agent 的能力组织方式。研究者们提出了一个非常关键的观点：未来 Agent 的核心抽象，不再只是 Tool，而是 Skill。

Skill 并不是一个 Prompt，也不是一个 API，它更像是一个完整的“能力包”。

在传统软件世界中，我们已经非常熟悉这种抽象。Linux 有 Package，VSCode 有 Plugin，Docker 有镜像，Maven 有 Dependency。这些东西本质上都在做同一件事：把某种能力进行模块化封装，并在运行时动态加载。而 Skill，其实就是 Agent 世界里的“能力模块”。

一个完整的 Skill，通常不仅仅包含文本说明，而是会包含一整套执行体系：工作流说明、操作 SOP、脚本、模板、参考文档、资源文件、工具依赖，甚至权限声明。它真正重要的地方在于：Skill 不再只是“告诉模型应该做什么”，而是开始向 Agent 注入真实的执行能力。这意味着，Agent 的能力边界正在从模型参数内部，逐渐扩展到外部 Runtime 世界。

而 Skill 最核心的设计思想，是“渐进式加载”，这也是整个 Skill Runtime 中最关键的架构创新之一。

过去 Prompt 最大的问题在于：上下文窗口是有限的。如果把所有规则、流程、文档全部塞进 Prompt，Context 很快就会爆炸。因此新一代 Skill 系统开始采用一种类似“按需加载”的机制。最开始加载到模型里的，仅仅只是非常少量的元信息，例如 Skill 名称和功能描述。Agent Runtime 会根据当前用户任务，动态决定是否激活某个 Skill。当 Skill 被真正触发后，系统才会进一步加载对应的 Instructions、Workflow、SOP、脚本与资源文件。更深层次的资源，例如 Python Script、Shell、模板文件、参考文档，则会在执行过程中继续按需加载。

这个设计极其重要。因为它意味着，Agent 的能力开始脱离 Context Window 的硬性限制，逐渐进入一种类似“文件系统级扩展”的模式。

换句话说，Agent 不再只是一个“上下文预测机器”，而开始变成真正的 Runtime。这也是为什么，越来越多的人开始把下一代 Agent 称为“Agent Operating System”。

因为从系统结构来看，它已经越来越像现代操作系统：有动态能力加载、有模块化插件体系、有权限系统、有生命周期管理、有 Tool 调度、有状态恢复、有 Runtime Memory，甚至开始出现类似 Package Manager、Scheduler、Capability Control 的机制。

在这种架构下，Skill 的定位其实已经非常清晰：它负责的是“程序经验”。而 MCP（Model Context Protocol）负责的，则是“连接能力”。

很多人会误以为 Skill 与 MCP 是竞争关系，但实际上它们属于 Agent 技术栈中的不同层次。MCP 解决的是 Agent 如何连接外部世界，例如 PostgreSQL、GitHub、Browser、Redis、SaaS API、本地文件系统等，它本质上是 Agent 的“系统调用层”；而 Skill 解决的，则是 Agent 应该如何完成具体任务，例如如何进行网络排障、如何填写报销单、如何完成工单流转、如何分析日志。这实际上是“经验系统”与“连接系统”的区别。

未来真正成熟的 Agent 架构，很可能会逐渐演化成：

用户请求进入 Runtime 后，由 Skill Router 动态匹配合适的 Skill，再由 Runtime 将对应 Skill 注入上下文，随后通过 MCP 连接外部系统，并最终在 Browser、OS、Shell、Python Runtime 等环境中完成真实执行。

这已经完全不是传统意义上的聊天机器人，它更像一个能够动态加载能力、调度资源、调用系统、执行工作流的 AI Runtime System。

Skill Router 也正在成为整个系统中最关键的组件之一。

因为当 Skill 数量开始增长后，一个新的问题会迅速出现：Agent 到底应该激活哪个 Skill？这其实已经开始接近操作系统中的“任务调度问题”。

未来的大型企业，很可能会拥有成百上千个 Skill：

财务 Skill、网络诊断 Skill、客服 Skill、报表生成 Skill、故障分析 Skill、数据治理 Skill、办公自动化 Skill……

如何进行 Skill Matching、动态路由、上下文调度、能力组合，会逐渐成为 Agent Runtime 的核心能力。

更进一步，Skill 的意义还不只是“能力模块化”。

它真正深远的地方在于：企业经验开始第一次被结构化沉淀。

过去企业里的很多核心能力，其实都存在于人脑中。一个资深运维专家知道怎么排障，一个财务人员知道怎么审核，一个网络专家知道怎么定位故障，但这些经验很难真正沉淀下来。而 Skill 的出现，本质上是在把这些 SOP、流程经验、操作逻辑，转化成可加载、可治理、可组合、可迁移的数字化能力模块。

这意味着，未来企业积累的真正资产，很可能不再只是代码，而是 Skill Library。

而 Skill 之间，还会进一步形成组合。

一个复杂任务，不再由单一 Workflow 完成，而是由多个 Skill 动态协作。例如 PDF Processing Skill、Excel Analysis Skill、Report Generation Skill、Mail Sending Skill，可以在 Runtime 中被动态编排，形成完整业务闭环。这其实已经非常接近下一代 Workflow Engine 的形态。

尤其是在 Computer Use Agent（GUI Agent）快速发展的背景下，Skill 的价值会被进一步放大。

因为 GUI 操作天然就是“经验型任务”。

打开系统、寻找菜单、识别页面元素、点击按钮、输入内容、处理异常、恢复状态，这些操作都不是简单 API 能够表达的，它们需要大量程序经验、状态记忆与环境理解。因此 GUI Agent 与 Skill 几乎天然契合。

但与此同时，Skill 也带来了新的巨大风险，因为它已经不再只是文本。

Skill 开始拥有：文件权限、Shell 权限、网络权限、Tool 权限。

新的攻击也随之出现，例如 Prompt Injection、数据窃取、权限提升、恶意脚本、Supply Chain Attack。未来一定会出现类似“Skill Marketplace”的生态，就像今天的 App Store、VSCode Marketplace、Docker Hub 一样。而当 Skill 生态形成后，治理问题会立刻变得极其重要：谁来审核 Skill？如何限制权限？如何防止恶意能力注入？如何建立 Runtime Sandbox？

这意味着，未来 Agent 世界一定会逐渐形成自己的：权限系统、Skill Sandbox、Capability Model、Trust Governance。

它们会越来越像：Linux Capability、Android Permission、Kubernetes RBAC。

本质上，Agent 正在从“模型时代”进入“Runtime 时代”。

过去大家比拼的是模型参数，而未来真正的竞争力，很可能会变成：谁拥有更强的 Skill Ecosystem，谁拥有更成熟的 Runtime，谁拥有更稳定的 Governance，谁拥有更完整的 MCP 生态与 Agent Infrastructure。

Skill，很可能会成为整个下一代 AI Agent 世界最核心的基础抽象层。