这是 Skill As A Service 系列的第一篇。先直接说几个核心判断：为什么软件可以用 Skill 的形式提供服务，以及 Skill 包如何成为新的软件组织单元。至于技术选型、Agent 执行引擎建设、如何一步步落地 Skill As A Service，以及这种模式对软件工程和普通工程师意味着什么，后面会陆续展开。
一、GUI软件的问题：所有能力都被页面锁住
现在的大部分软件系统，搭建路径基本是相似的：
数据库 → ORM → Service 层 → Controller → 前端工程 → 用户交互
这条链路看起来顺理成章，但有一个致命的隐含前提：用户必须通过预设的图形界面来使用系统。
于是，每个筛选条件、每个操作按钮、每个导出入口，都必须提前被精心设计出来。哪怕只是一个很小的需求变化，也可能牵动 UI、前端、接口、后端逻辑、权限和测试整个链条。
这里面其实藏着两个深层矛盾。
第一个矛盾：需求是组合爆炸的，开发却是线性的。 业务用户真正想要的，往往不是一个孤立的功能，而是数据维度、筛选条件、操作动作的自由组合。N 个数据维度乘以 M 种操作方式，很快就会变成海量的页面、按钮和接口。但研发资源只能一项一项地排期，结果就是功能永远在积压，永远在排队。
第二个矛盾：能力被 GUI 预设锁死了。 软件能做什么，完全取决于系统提前设计了哪些入口、接口和流程。用户能使用的能力，被牢牢限制在开发者预设好的筛选项、表单字段、按钮、权限和业务路径里。一旦问题超出这个范围，就只能重新提需求，然后走完整的评审-开发-测试-部署流程。
说到底，问题不在于后台页面做得不够多，而在于：系统把能力封装进了页面，也就把用户锁在了页面里。
二、新架构：让数据和业务能力直接进入 Agent
Skill As A Service 的核心思路其实很简单：把那些专门为 GUI 服务的中间工程链路尽量蒸发掉，只保留真正有价值的东西——数据、业务规则和可执行能力。
传统架构：数据库 → ORM → Service 层 → Controller → 前端工程 → 用户交互SaaS 架构：数据库 ──→ Database MCP ──→ Agent 平台 ←── 用户对话业务逻辑 → Business MCP ──→←── Skill
这里的关键变化是什么？能力不再必须变成一个完整的后台系统，才能被用户使用。数据库可以通过 Database MCP 直接暴露查询能力，业务逻辑可以通过 Business MCP 暴露操作能力，而 Agent 平台则负责理解用户目标、选择工具并完成编排。
GUI 并没有消失，只是角色变了。它不再是围绕后台系统长期堆出来的那一整套页面工程，而是 Skill 包里可选的常用功能页面。可以提前预设好，也可以在对话过程中根据上下文临时渲染。对于自然语言不如点一下按钮来得快的场景，页面就是最高效的入口；而对于开放、探索、组合性强的场景，对话仍然是默认入口。
Database MCP：释放数据能力
Database MCP Server 的作用，是把数据库的 Schema、查询和写入能力，通过 MCP 协议暴露给 Agent。MCP 有一个很重要的特征：自描述。每个工具都会声明自己的参数、约束和用途，Agent 可以读取这些描述并自主调用。
这和传统 REST API 完全是两回事。REST API 通常需要人先读文档，再写代码去调用；而 MCP Tool 是 Agent 直接读 schema，然后直接调用。
| 传统后台功能 | SaaS 实现方式 |
|---|---|
| 数据列表 + 筛选 | “查一下最近 7 天注册的用户，按地区分组” |
| 数据统计 | “过去一个月各产品线的营收趋势” |
| 关联查询 | “买了产品 A 的用户还买了什么” |
| 批量导出 | “导出上个月所有订单到 CSV” |
一旦接入了 Database MCP，很多临时查询就不再需要为每个组合单独开发页面了。数据库建好、权限配置好、MCP 接上，用户就可以通过自然语言完成临时查询、聚合分析和跨表关联。而那些真正高频、固定、点击更快的查询，再沉淀为 Skill 包里的常用页面。
Business MCP：封装不能直接改库的业务动作
并不是所有操作都应该交给 Agent 直接改数据库。
判断标准其实很明确：只要一个操作涉及多步校验、外部服务调用或事务性数据变更，就应该封装成 Business MCP，而不是让 Agent 直接操作表。
拿退款来举例：
- 只用 Database MCP：Agent 可能直接 UPDATE 订单状态，但退款时效、人工审核、积分退回、优惠券恢复、支付网关调用这些细节，都容易被遗漏。
- 使用 Business MCP：系统暴露
processRefund(orderId, reason)，内部完成权限校验、状态机校验、支付网关调用、积分恢复和操作日志。Agent 只需要调用这个工具。
MCP 工具的粒度，取决于业务本身的复杂度。工具太细，Agent 需要理解太多业务细节；工具太粗，灵活性又会下降。比较稳妥的原则是：Agent 应该知道何时调用工具，但绝不应该被迫去理解业务规则的内部实现。
对话驱动的能力编排
在传统后台里，一个所谓的“操作组合”，通常意味着一个新页面或新按钮。但在 SaaS 架构下，组合可以发生在运行时。
举个例子，用户说：
Agent 可以自动编排为：
Database MCP 查询用户→ Agent 过滤与分析→ Business MCP 发放优惠券→ Agent 导出报表
传统模式下，这类需求可能要经过评审、设计、开发和部署。而在 SaaS 模式下，它首先是一段对话；如果后来反复出现，再沉淀为 Skill 或者页面。
三、Skill：把高频能力沉淀为可复用单元
如果说 MCP 提供的是底层能力，Agent 负责的是临时编排，那么 Skill 就是高频能力的沉淀形式。
Skill 远不只是“从对话里提炼出来的快捷方式”。它首先是一个可运行、可复用的能力包，包含依赖的 MCP 工具、编排逻辑和一组可选入口；同时，它也不是创建后就固定不变的功能模块，而是可以在使用中继续沉淀、扩展和进化的能力单元。
Skill 包├─ MCP 配置：依赖哪些 MCP Server 和工具├─ 编排逻辑：调用顺序、条件分支、数据流转、错误处理└─ 可选入口：页面、快捷指令、定时任务、工作流链
| 构成 | 作用 |
|---|---|
| MCP 配置 | 声明 Skill 运行时需要哪些数据和业务工具 |
| 编排逻辑 | 定义工具如何协作，形成完整业务流程 |
| 可选入口 | 决定用户如何快速触发和使用这个能力 |
页面是 Skill 包里的可选常用功能入口，用来覆盖那些“点一下比说一句更快”的场景。它可以是提前预设好的页面模板，也可以是在对话过程中根据当前任务临时渲染出来的页面。页面上的按钮、筛选、提交动作，背后仍然是 Skill 编排逻辑中的 MCP 工具调用。
Skill 的四种入口形态
| 形态 | 适合场景 | 示例 |
|---|---|---|
| 页面 | 自然语言不如点击操作高效的常用功能，可预设也可临时渲染 | 退款审批面板、数据查询看板、财务凭证录入 |
| 快捷指令 | 参数相对固定、无需复杂确认的即时操作 | /日报 自动查询、分析、汇总并推送 |
| 定时任务 | 时间驱动的后台自动化 | 每天 10:00 扫描行业新闻并推送摘要 |
| 工作流链 | 多阶段、多角色参与的流程 | AI 初稿 → 人工审核 → AI 配图 → 人工确认 → 发布 |
这四种形态不是互斥的分类，而是同一个能力在不同场景下的入口选择。一个操作一开始可能只是对话里的临时请求；如果当前步骤适合结构化点击，Agent 可以临时渲染页面；如果它长期高频出现，也可以沉淀为预设页面。更适合一句话触发的能力，可以配置为快捷指令；跨时间或跨角色的能力，则扩展为定时任务或工作流。
三层交互模型
| 层级 | 方式 | 适用场景 |
|---|---|---|
| L1 对话 | 自然语言输入 | 低频操作、探索性查询、临时分析 |
| L2 Skill | 固化能力单元 | 常用页面、快捷指令、定时任务、工作流 |
| L3 对话生成 Skill | 描述需求，由 Agent 生成新 Skill | Skill 库没有覆盖的新场景 |
Skill 的创建有两条路径。
一条是直接设计。团队可以一开始就把退款审批、日报生成、内容发布这些流程设计成 Skill，明确依赖哪些 MCP、如何编排、以什么形式使用。
另一条是从对话中“生长”出来。用户反复通过 L1 对话完成同类操作后，Agent 平台可以识别出重复模式，并提示是否保存为 Skill。已经存在的 Skill 也可以继续吸收这些使用模式：增加新的页面入口、调整编排逻辑、补充异常处理，或者扩展新的 MCP 工具依赖。这样一来，系统能力不再只由产品排期决定，也会从真实使用中长出来。
四、实际效果：从“开发功能”变成“编排能力”
研bot平台的内容生成管线就是一个很典型的例子。
用户输入：
系统可以编排为：
1. Yanbot MCP → 查询分数线数据2. Yanbot MCP → 查询调剂数据3. Agent → 分析数据并撰写内容4. Skill → 生成配图或发布素材
传统流程里，用户可能需要在多个系统之间切换：查分数线、查调剂信息、整理表格、分析趋势、撰写内容、制作配图。整个过程耗时 45 到 90 分钟。
在 SaaS 架构下，这个流程被压缩为一句对话，执行时间压缩到 30 秒。更重要的是，它不是一个孤立的功能，而是一组可按需组合的能力。
这就是 Skill as a Service 架构的本质变化：
传统后台：为每个功能开发一个入口SaaS 架构：让 Agent 根据目标实时组合能力
查询类功能尤其明显。过去一个新筛选组合可能需要 3 到 5 天开发；现在组合可以通过对话完成，高频组合再沉淀为 Skill 包里的常用页面。
五、边界与落地：从只读查询开始
必须承认，Skill As A Service 不是替代一切的银弹。它更适合内部系统、运营后台、数据分析、审核审批、内容生产这类场景——需求变化快、组合操作多、用户也愿意用自然语言表达目标。
| 推荐场景 | 适合原因 |
|---|---|
| 内部运营后台 | 功能变化快，用户对效率敏感 |
| 实时监控大屏 | 指标口径经常调整，适合自然语言配置 |
| 数据分析看板 | 查询方式灵活，传统 BI 配置成本高 |
| 审核/审批系统 | 流程相对标准，适合沉淀为 Skill |
| 内容运营工具 | 查、析、写、发天然是链式操作 |
当然，也有一些场景需要谨慎对待。
| 场景 | 风险 | 缓解方式 |
|---|---|---|
| 强合规系统 | 需要完整操作留痕和审批 | MCP 审计日志 + Skill 内置审批链 |
| C 端普通用户 | 对话式操作习惯尚未完全普及 | 用 Skill 包里的常用页面，提供更直接的点击入口 |
| 高风险写操作 | Agent 直接改库可能绕过业务规则 | 封装为 Business MCP，禁止直接写表 |
比较现实的落地路径，可以分四步走。
第一步，接入只读 Database MCP。 先让 Agent 查询数据，不做任何写操作。这样风险最低，也最容易验证价值。很多报表、筛选、统计需求会立刻被覆盖。
第二步，封装 Business MCP。 识别退款、审批、发券、发布等关键业务动作，把规则封进工具里。Agent 负责调用，业务规则仍然由系统保证。
第三步，建设高频 Skill。 把反复使用的查询、审批、日报、内容生成流程沉淀为 Skill。点按钮更快的场景，沉淀为常用页面，也可以在临时任务中按需渲染页面；一句话更快的场景，配置快捷指令；跨时间或跨角色的场景，配置定时任务或工作流。
第四步，让 Skill 库持续生长。 高频需求走 Skill，低频需求走对话。对话中反复出现的新模式，再由 Agent 辅助生成新的 Skill。
总结
SaaS（Skill As A Service）把软件的一种新形态定义为“可组合、可进化的 Skill 包”。
传统后台把能力藏在页面和接口后面，用户只能沿着预设路径操作。而新的架构，把数据能力交给 Database MCP，把业务动作交给 Business MCP，把编排交给 Agent，把高频流程沉淀为 Skill。
最终形成的交互模型是：默认走对话，高频沉淀为 Skill；Skill 可以直接作为服务被使用，也可以在使用中持续进化；Skill 不够用时，再通过对话生成新的 Skill。
这绝不是在简单地用聊天框替代后台，而是把整个后台系统从“页面驱动”改造成“能力驱动”。当能力可以被 Agent 理解、调用和组合，软件就不再只是一个固定的系统，而会变成一组持续生长的服务单元。
这篇文章只是在定义这个新范式。围绕它还有几个更工程化的问题需要继续拆开讨论：为什么能力暴露要走 MCP，而不是系统内部直接调用；为什么 Agent 执行引擎不应该轻易自建；如何从数据库接入、Business MCP 封装、Skill 包设计、权限审计、灰度迁移等环节落地 Skill As A Service；当 Skill 成为一种软件组织单元之后，软件工程的边界会怎样变化；以及普通工程师的工作重心会从写页面和接口，转向怎样设计能力、约束能力和编排能力。
参考资料：
- Model Context Protocol (MCP): modelcontextprotocol.io
- Postgres MCP Server: github.com/modelcontex…
- 研bot：Yanbot Agent 的 SaaS 架构实践
