AI 时代下的 SaaS: Skill As A Service （一）

SaaS 正在从 Software as a Service 走向 Skill as a Service。软件不一定只能表现为预先做好的 GUI 系统，也可以以 Skill 包的形式成为服务：可被 Agent 调用、编排和复用。Skill 包既是一种软件形态，也是会在使用中持续沉淀和进化的能力单元。用户不必先进入一个固定系统，再沿着菜单寻找功能；他们可以直接用对话提出目标，高频目标再沉淀为 Skill。

这是 Skill As A Service 系列的第一篇。本文先讨论最基础的问题：为什么软件可以用 Skill 的形式提供服务，以及 Skill 包如何成为新的软件组织单元。至于技术选型、Agent 执行引擎建设、如何一步步落地 Skill As A Service，以及这种模式对软件工程和普通工程师意味着什么，会在后续文章里展开。

一、GUI软件的问题：所有能力都被页面锁住

常见的软件系统通常是这样搭起来的：

text 复制代码

数据库 → ORM → Service 层 → Controller → 前端工程 → 用户交互

这条链路看起来合理，但它有一个隐含前提：用户必须通过预设的图形界面使用系统。

于是，每一个筛选条件、每一个操作按钮、每一个导出入口，都要被提前设计出来。一次很小的需求变化，也可能牵动 UI、前端、接口、后端逻辑、权限和测试。

真正的矛盾有两个。

第一，需求是组合爆炸的，开发是线性的。

业务用户想要的往往不是一个孤立功能，而是数据维度、筛选条件、操作动作的自由组合。N 个数据维度乘以 M 种操作方式，很快就会变成大量页面、按钮和接口。但研发资源只能一项一项排期，结果就是功能永远在积压。

第二，能力被 GUI 预设限制。

软件能做什么，取决于系统提前设计了哪些入口、接口和流程。用户能使用的能力，被限制在开发者预设好的筛选项、表单字段、按钮、权限和业务路径里。一旦问题超出范围，就只能重新提需求，然后走完整的评审-开发-测试-部署流程。

问题不在于后台页面做得不够多，而在于：系统把能力封装进页面，也把用户锁进了页面。

二、新架构：让数据和业务能力直接进入 Agent

Skill As A Service 的核心思路很简单：把为 GUI 服务的中间工程链路尽量蒸发掉，只保留真正有价值的东西：数据、业务规则和可执行能力。

text 复制代码

传统架构：
  数据库 → 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 架构里，组合可以发生在运行时。

例如用户说：

查询华东区过去 3 个月购买产品 A 的用户，筛选消费超过 5000 元的，发放优惠券，导出报表。

Agent 可以自动编排为：

text 复制代码

Database MCP 查询用户
→ Agent 过滤与分析
→ Business MCP 发放优惠券
→ Agent 导出报表

传统模式下，这类需求可能要经过评审、设计、开发和部署。SaaS 模式下，它首先是一段对话；如果后来反复出现，再沉淀为 Skill 或者页面。

三、Skill：把高频能力沉淀为可复用单元

如果说 MCP 提供底层能力，Agent 负责临时编排，那么 Skill 就是高频能力的沉淀形式。

Skill 不是"从对话里提炼出来的快捷方式"这么简单。它首先是一个可运行、可复用的能力包，包含依赖的 MCP 工具、编排逻辑和一组可选入口；同时，它也不是创建后就固定不变的功能模块，而是可以在使用中继续沉淀、扩展和进化的能力单元。

text 复制代码

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平台的内容生成管线就是一个典型例子。

用户输入：

查山东大学 2025 年计算机录取数据，关联 081200 调剂信息，生成小红书备考攻略。

系统可以编排为：

text 复制代码

1. Yanbot MCP → 查询分数线数据
2. Yanbot MCP → 查询调剂数据
3. Agent     → 分析数据并撰写内容
4. Skill     → 生成配图或发布素材

传统流程里，用户可能需要在多个系统之间切换：查分数线、查调剂信息、整理表格、分析趋势、撰写内容、制作配图。整个过程耗时 45 到 90 分钟。

在 SaaS 架构下，这个流程被压缩为一句对话，执行时间压缩到 30 秒。更重要的是，它不是一个孤立功能，而是一组可按需组合的能力。

这就是 Skill as a Service 架构的本质变化：

text 复制代码

传统后台：为每个功能开发一个入口
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 架构实践