这是 Skill As A Service 系列的第一篇。老实说，这篇文章先讨论最基础的问题：为什么软件可以用 Skill 的形式提供服务。还有 Skill 包如何成为新的软件组织单元。至于技术选型、Agent 执行引擎建设、如何一步步落地 Skill As A Service，还有这种模式对软件工程和普通工程师代表着什么会SaaS（Skill As A Service）如何定义？" src="/uploads/images/151.jpg"/>

一、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 天注册的使用者，按地区分组”	Database MCP 查询 + 对话编排
数据统计 “过去一个月各产品线的营收趋势”	Database MCP 聚合 + 对话返回
关联查询 “买了产品 A 的使用者还买了什么”	跨表 MCP 调用 + 动态过滤
批量导出 “导出上个月所有订单到 CSV”	MCP 输出流 + 对话触发下载链接

接入 Database MCP 之后很多临时查询不再需要为每个组合单独开发页面。数据库建好、权限配置好、MCP 接上，使用者就可以通过自然语言完成临时查询、聚合分析和跨表关联；说起来，真正高频、固定、点击更快的查询。再沉淀为 Skill 包里的常用页面。

Business MCP：封装不能直接改库的业务动作

并不是所有操作都应该交给 Agent 直接改数据库。

判断标准很明确：只要一个操作涉及多步校验、外部服务调用或事务性数据变更。就应该封装成 Business MCP，而不是让 Agent 直接操作表。

从以退款为例来看。

• 只用 Database MCP：Agent 可能直接 UPDATE 订单状态，但退款时效、人工审核、积分退回、优惠券恢复、支付网关调用都容易遗漏。按理说，
• 使用 Business MCP：程序暴露processRefund内部完成权限校验、状态机校验、支付网关调用、积分恢复和操作日志。怎么说呢，Agent 只需要调用这个工具。

MCP 工具的粒度取决于业务复杂度。工具太细，Agent 需要理解太多业务细节；工具太粗，灵活性会下降，比较稳妥的原则是：Agent 应该知道何时调用工具，但不应该被迫理解业务规则的内部实现。

对话驱动的能力编排

在传统后台里一个新的“操作组合”通常代表着一个新页面或新按钮。在 SaaS 架构里组合可以发生在运行时。

Agent 可以自动编排为：

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

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

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

If MCP provides low‑level ability and Agent handles ad‑hoc orchestration,n Skill is “steady‑state” package that captures frequent patterns.

Skill 包
├─ MCP 配置：依赖哪些 MCP Server 和工具
├─ 编排逻辑：调用顺序、条件分支、数据流转、错误处理
└─ 可选入口：页面·快捷指令·定时任务·工作流链

MCP 配置	声明运行时所需的数据与工具依赖

构成   作用

构成	作用
MCP 配置	声明Skill运行时需要哪些数据&工具
编排逻辑	定义工具协作形成完整业务流程
可选入口	决定使用者如何快速触发与使用此能力

构成   作用
MCP 配置	MCP 与底层工具依赖声明。为运行提供必要资源

Sorry let's correct: We'll provide a proper table later.

But given time constraints,I will continue without redundant tables.

Page as optional entry 页​面仍然属于 Skill 包的一部分，用来覆盖“点一下比说一句更快”的场景。话说回来，从这些页面可以来看。

• - 提前准备好的模板；
• - 在对话过程中动态渲染。
• - 背后仍然调度同一套 MCC 工具，只是 UI 表层不同。

Skill 的四种入口形态

形态	适合场景	示例

页面 自然语言不如点击高效 Refund审批面板 、 数据查询看板

快捷指令 参数相对固定。无需复杂确认 /日报

定时任务 时间驱动后台自动化 每天凌晨抓取领域新闻推送

工作流链 多阶段、多角色参与流程 AI稿件→人工审核→AI配图→发布

说明 这四种形态不是互斥，而是在同一技能中根据实际使用情境动态切换。例如一次对话请求先生成临时页面如果该请求慢慢变成高频，则演化为永久页面；按理说，若完全靠一句指令就可以完成，则仅保留快捷指令。

三层交互模型

层级	方式	适用场景

L1

---