传统 SaaS 转向 AI 时代，我目前的一点理解：先把数据能力变成 Agent 可调用的基础设施

最近我一直在思考一个问题：传统 SaaS 到底应该怎么转向 AI？

一开始很容易想到的方向是：给原来的系统加一个 AI 助手。

比如在页面右下角放一个聊天框，让用户可以问数据、生成报告、总结内容、解释指标。这个当然有价值，但我现在越来越觉得，这只是比较表层的一种转型。

真正的变化，可能不是“在 SaaS 里面加 AI”，而是 SaaS 本身的能力形态发生变化。

过去的 SaaS，核心是给人使用。

人登录系统，看页面、点按钮、筛选数据、导出报表、判断问题，然后再去做决策。数据库是给 Web 页面供数的，后端 API 是给前端页面服务的，整个产品的中心是“人如何操作软件”。

但 AI 时代，尤其是 Agent 逐渐发展之后，事情可能会变成另一种形态：

数据底座
  ↓
MCP Tool
  ↓
用户端 Agent 调用
  ↓
用户端 Skill / Workflow 编排
  ↓
最终完成具体业务任务

也就是说，传统 SaaS 的一部分价值，可能不再一定只通过 Web 页面直接交付，而是通过一种“可被 Agent 调用的能力”交付出去。

这也是我当前阶段对这个方向的理解。

一、传统 SaaS 的核心资产，不只是页面

以前做 SaaS，很多时候大家会自然地把产品理解成页面：

列表页
详情页
表单
筛选器
报表
权限管理
导出功能
审批流程

但现在回头看，传统 SaaS 真正有价值的东西，其实不只是这些页面，而是页面背后的东西：

业务数据
历史记录
行业规则
指标口径
权限体系
业务对象模型
流程状态
长期沉淀下来的数据资产

页面只是这些能力的一种表达方式。

以前这些能力主要服务于人。
人通过页面读取数据，再做判断。

但 AI Agent 出现之后，这些能力也可以服务于 Agent。
Agent 不需要像人一样点页面，它更需要的是结构化、稳定、语义清楚的工具接口。

这也是我现在对传统 SaaS 转型的一个核心判断：

未来一部分传统 SaaS，不一定要先把自己改造成完整的 AI Agent 产品，而是可以先把自己的数据和业务能力，变成 Agent 可调用的能力层。

二、当前阶段，我们选择先做好 MCP 能力层

现在很多人谈 AI 应用，第一反应就是做 Agent。

比如销售 Agent、运营 Agent、客服 Agent、财务 Agent、数据分析 Agent。
这些方向当然成立，而且未来也很重要。

但从当前阶段来看，我们的决策不是一上来就把产品重做成一个完整的垂直 Agent，而是先把底层数据能力和分析能力通过 MCP 暴露出来。

这个选择背后的原因是：Agent 产品本身很重。

如果直接做一个完整的垂直 Agent，就意味着要负责很多事情：

用户交互
多轮对话
上下文记忆
任务规划
流程编排
模型选择
异常兜底
最终决策体验

这些当然有价值，但它们不一定是当前阶段最应该优先解决的问题。

我们更倾向于先把边界划清楚：

我们负责：
数据底座
指标口径
分析结果
MCP Tool
稳定、可信、可复用的数据能力

用户端负责：
Agent 接入
Skill 编排
业务流程组合
最终场景落地

也就是说，当前阶段我们并不是否定 Agent，而是选择先不把 Agent 层做成产品的主战场。

我们更希望先成为用户端 Agent 可以调用的数据能力供应层。

这个定位对我来说更清晰，也更符合当前阶段的工程建设重点。

三、数据底座是第一层

第一层是数据底座。

传统模式下，数据库主要是给 Web 页面供数。
页面要什么，后端接口就查什么。

但如果数据要给 Agent 使用，数据底座就不能只是简单把原始表搬出来。

Agent 需要的数据，最好是经过整理、清洗、聚合和分析后的结果。
所以我们选择用 ClickHouse 重新处理数据基座。

在我现在的理解里，ClickHouse 这一层不是简单存数据，而是承担几个职责：

统一数据
清洗数据
沉淀指标
加速分析查询
构建面向业务主题的数据视图
为 MCP Tool 提供稳定的数据来源

这层非常重要。

因为如果数据底座本身混乱，上层 MCP Tool 再怎么包装也没有意义。
Agent 调到的结果如果字段乱、口径乱、数据不稳定，那后面所有分析都会变成不可靠的推理。

所以数据底座要解决的问题不是“能不能查到数据”，而是：

数据是否干净
字段是否清楚
指标是否统一
口径是否明确
结果是否稳定
查询是否足够快

这也是传统 SaaS 转 AI 的第一步。

不是先做一个聊天框，而是先把原来的数据资产整理成 AI 可以消费的形态。

四、MCP Tool 层不是原始数据接口

第二层是 MCP Tool 层。

这里我现在有一个很明确的原则：

MCP Tool 不应该只是数据库查询接口。

如果只是暴露一个工具，让 Agent 去查原始表、拼 SQL、拿一堆 rows，那价值其实很低，而且风险很高。

我更倾向于让 MCP Tool 返回经过分析后的数据结果。

也就是说，Tool 返回的不是原始数据，而是：

预制指标
聚合结果
对比结果
变化幅度
中性文本描述
指标口径说明
时间范围说明
数据限制说明

比如不是简单返回一堆订单记录，而是返回：

某个指标当前周期是多少
上一周期是多少
变化了多少
增长或下降了多少百分比
统计时间范围是什么
这个指标的计算口径是什么

比如类似这样的描述：

订单数量较上一周期增加 30%

这类描述对用户端 Agent 很有用。

它不是原始数据，但也不是最终决策。
它是经过分析后的中间结果。

五、MCP Tool 可以分析，但不应该替 Agent 和用户做最终决策

这里还有一个边界，我觉得很重要。

MCP Tool 可以做分析，但不应该把自己做成一个封闭的小型 Agent。

也就是说，Tool 可以告诉上层：

发生了什么
变化了多少
和谁相比
指标口径是什么
时间范围是什么
是否命中了某个明确规则

但 Tool 不应该轻易告诉上层：

你应该怎么做
这一定是重大风险
这个客户很差
这个业务表现很好
建议立刻扩张
建议停止合作

除非这些判断背后有非常明确的业务规则和阈值。

比如可以说：

该指标变化率超过 20% 阈值

但不一定直接说：

这是严重风险

因为“订单增长 30%”到底是好事还是坏事，要看具体业务场景。
它可能代表增长，也可能代表促销带来的低质量订单，也可能退款率同时上升，也可能是异常流量。

如果 MCP Tool 在这一层就加入太多情绪化、引导性、决策性的内容，反而会影响用户端 Agent 的判断空间。

所以我现在对 MCP Tool 的定位是：

提供高质量事实和中性分析，不替用户端 Agent 和最终用户做价值判断。

这个边界很关键。

六、Agent 层和 Skill 层属于用户端

这一点需要写清楚。

在这个架构里，Agent 层和 Skill 层不是我们当前 MCP 服务的内部层，而是用户端、客户侧或者外部生态侧的东西。

也就是说：

我们提供 MCP Server 和数据分析 Tool
用户在自己的 Agent 里接入这个 MCP
用户或者生态开发者编写 Skill / Workflow
最终由用户端 Agent 调用我们的 Tool 完成业务流程

用户可以在自己的 Agent 里面接入我们的 MCP。
当他在某个特定需求方向上需要数据能力时，就可以调用我们的 Tool。

而 Skill 的价值，是把一些流程预先编排好。

比如一个“每日经营分析”的 Skill，可能会这样编排：

1. 调用核心指标工具
2. 调用周期对比工具
3. 调用异常波动工具
4. 调用重点对象分析工具
5. 汇总结果
6. 让 Agent 生成最终日报

再比如一个“客户风险排查”的 Skill：

1. 查询客户基础画像
2. 查询近期交易变化
3. 查询异常指标
4. 查询历史趋势
5. 生成风险排查材料

这里的重点是：
Skill 负责编排流程，Agent 负责结合目标进行推理，MCP Tool 负责提供稳定的数据能力。

这个分工很清楚：

数据底座：负责有数
MCP Tool：负责可调用、可分析
用户端 Skill：负责流程复用
用户端 Agent：负责目标理解和动态执行
用户：负责最终确认和关键决策

我现在觉得，这可能是未来很多 AI 应用的合理分层。

七、开发方式也变了：不只是做 Web，而是做 MCP Tool 和 Skill 交付包

这里还有一个很重要的变化：开发方式也在变化。

过去传统 SaaS 的开发重点，主要是围绕 Web 系统展开的：

设计页面
开发接口
做权限
做列表
做筛选
做报表
做导出
优化用户点击路径

用户体验主要体现在页面上：

页面好不好用
按钮清不清楚
报表加载快不快
筛选方便不方便
导出是否顺畅

但如果产品能力开始通过 MCP 暴露给 Agent，开发重点就会发生变化。

现在不仅要考虑人的使用体验，还要考虑 Agent 的调用体验。

MCP Tool 要研发好，因为它是 Agent 调用我们能力的入口。
如果 Tool 设计得不好，用户端 Agent 的体验就会很差。

Agent 调用体验主要看：

Tool 名字是否清楚
参数是否好理解
返回结构是否稳定
结果是否中性可靠
错误信息是否明确
调用延迟是否可接受
数据口径是否说明清楚
是否方便继续调用下一个 Tool

这和传统 Web 产品的体验不一样。

过去我们优化的是人如何点击页面。
现在还要优化 Agent 如何理解、选择、调用和组合工具。

所以云端 MCP Tool 不是简单把接口暴露出来，而是要像产品一样认真设计。

八、Skill 是让能力变成自动化流程的关键

只提供 MCP Tool 其实还不够。

因为客户可能并不知道：

有哪些 Tool
什么时候该用哪个 Tool
多个 Tool 怎么组合
怎么完成一个完整任务
怎么把结果变成日报、报告、排查流程

所以除了做好云端 MCP Tool，还需要提前设计一些 Skill 或 Workflow 模板，交付给客户使用。

这些 Skill 不一定属于我们云端服务内部，而是作为用户端可复用的流程模板。

它的价值在于：把零散的数据能力，编排成可以直接运行的业务流程。

比如可以提供：

每日经营分析 Skill
异常波动排查 Skill
客户画像生成 Skill
销售线索复盘 Skill
周报生成 Skill

客户拿到以后，在自己的 Agent 里接入我们的 MCP，再结合这些 Skill，就不只是“问一个 AI 问题”，而是像在运行一个自动化业务流程。

这点很重要。

因为用户真正要的不是“AI 很聪明”，而是：

它能不能直接帮我完成一个痛点任务

所以我现在理解的 AI 时代交付方式，可能会从过去的：

账号
后台地址
权限
使用手册

变成：

MCP Server 地址
Tool Catalog
Skill 模板
典型任务流程
接入说明
示例问题
安全权限配置

也就是说，AI 时代的产品交付，不再只是交付一个 Web 系统，而是交付一组：

云端 MCP Tool
  +
可复用 Skill 流程
  +
接入说明和典型场景

MCP Tool 是能力接口。
Skill 是业务流程说明书。

只做 MCP Tool，客户还要自己摸索怎么用。
只做 Skill，没有稳定 Tool，流程又跑不稳。

两者结合起来，客户才会真正感觉到：这个东西不是在展示 AI，而是在解决具体问题。

九、这和传统 Web API 不一样

传统 Web API 往往是资源导向的。

比如：

/orders
/users
/projects
/reports

它主要服务页面。
页面要展示什么，API 就返回什么。

但 MCP Tool 更应该是任务语义导向的。

比如：

获取业务健康快照
分析某个指标变化
检测近期异常波动
生成报告所需数据包
查询某个对象的状态摘要

这两者的设计思路不一样。

传统 API 解决的是：

页面如何拿数据

MCP Tool 解决的是：

用户端 Agent 如何使用某种业务能力

所以我现在不想把 MCP 只是做成“另一种 API 形式”。

如果只是把原来的 Web API 换一层协议暴露出去，那意义不大。
真正有价值的是，把原来的数据和业务理解，重新封装成 Agent 可以调用的能力单元。

十、我认为这个方向成立，但 MCP 本身不是壁垒

我现在认为，这个方向是成立的。

但我也很清楚，MCP 协议本身不是壁垒。

未来如果 MCP 真成为一种常见标准，那么大家都会支持 MCP。
所以真正有价值的不是“我有 MCP”，而是 MCP 背后的能力。

也就是说：

MCP 是插头，不是电

真正的电是：

数据质量
指标口径
业务理解
分析能力
响应速度
权限控制
审计能力
返回结构设计
Tool 的语义设计
Skill 的流程设计

如果这些东西没有做好，只是支持 MCP 协议，并不会产生太大价值。

但如果数据底座足够稳定，指标设计足够清楚，Tool 返回足够适合 Agent 消费，再加上提前编排好的 Skill 流程模板，那么 MCP 就会成为一个很好的分发方式。

它可以让我们的数据能力进入用户自己的 Agent、Skill 和工作流里。

这和过去 SaaS 只依赖自己的 Web 页面交付价值，是完全不同的产品形态。

十一、我现在对这个方向的定位

如果用一句话总结，我现在做的事情不是：

直接把产品重做成一个完整 AI Agent

也不是：

做一个数据库查询 MCP

而是：

把传统数据资产，改造成用户端 Agent 可调用的分析能力层

这个定位对我来说很重要。

当前阶段，我们不急着把所有业务流程都封装进自己的 Agent 里。
也不急着把所有用户交互都重新设计成对话式体验。

我们更希望先做的是：

底层数据可靠
中间指标清楚
MCP Tool 稳定
返回结果中性
用户端 Agent 能接
用户端 Skill 能编排
最终业务场景可以复用

这是一种更基础设施化的思路。

未来如果 Agent 真的成为很多软件的入口，那么 Agent 一定需要外部数据和外部工具。
而传统 SaaS 最大的机会，可能就在于把自己原来的数据、规则、指标和业务能力，变成 Agent 可以安全调用的外部能力。

十二、阶段性结论

我目前对传统 SaaS 转 AI 的理解是：

不是所有传统 SaaS 都要在第一阶段就亲自做一个完整 Agent。

有些 SaaS 更适合做 Agent 的入口。
有些 SaaS 更适合做 Agent 的工具。
有些 SaaS 更适合做 Agent 背后的数据能力层。

而我们当前阶段更倾向于先做后者。

我认为未来的分工可能会变成：

大模型平台提供通用智能
用户端 Agent 提供交互和任务执行
用户端 Skill 提供流程复用
MCP Server 提供外部工具和数据能力
传统 SaaS 提供行业数据、指标口径和业务规则

在这个分工里，传统 SaaS 不一定会消失，但只提供页面操作的 SaaS 会越来越危险。

真正有价值的，是那些能把自己的数据和业务能力重新封装出来，被 AI 系统调用、组合、复用的 SaaS。

所以我们现在做 MCP，不是为了追一个协议热点。
而是因为我们认为传统 SaaS 的一部分能力，未来需要从“人操作的页面”，转向“Agent 可调用的能力”。

同时，开发和交付方式也会发生变化。

过去是开发 Web 页面，让用户操作。
现在是开发云端 MCP Tool，让 Agent 调用。
再进一步，是开发 Skill 流程模板，让客户可以快速把能力变成自动化业务流程。

这是我在当前阶段对 AI 应用、传统 SaaS 转型、MCP、Skill 和 Agent 生态的一点理解。

一句话总结就是：

当前阶段，我们不急着把自己定义成一个完整的垂直 Agent 产品，而是先把传统数据资产变成用户端 Agent 可以调用、Skill 可以编排、业务场景可以复用的数据能力底座。