1. 背景为什么行业一度喊出“AI杀死SaaS”1.1 “AI杀死SaaS”的说法从哪来过去两年大模型能力快速提升行业里出现了一种非常流行的判断用户不再需要订阅 SaaS 软件直接跟 AI 对话就能生成报表、写合同、做分析、跑流程。按这个逻辑SaaS 的意义被削弱了——既然自然语言就能完成任务为什么还要买一套固定功能的 CRM、ERP 或项目管理工具这个判断之所以传播很广是因为它抓住了一个真实的趋势大模型确实改变了人机交互方式。过去用户要学习软件的操作路径现在 AI 可以直接理解意图并给出答案。于是“AI 杀死 SaaS”就成了一个听起来很有冲击力的行业叙事。但从真实的技术落地情况来看这个说法正在反转。反转的原因不是大模型变弱了而是人们对软件工程的复杂度认识得更清楚了。1.2 AI 生成软件的真实能力边界要理解反转先要明白大模型在真实业务系统中能做什么、不能做什么。大模型擅长的是理解自然语言、生成文本、抽取信息、改写内容、生成代码片段、解释技术文档。这些能力适合做“智能层”但不适合直接替代“业务系统本身”。一个完整的 SaaS 系统包含以下部分用户体系与权限控制多租户数据隔离业务流程与状态机数据库事务与一致性审计日志与合规要求第三方系统集成前端交互与移动端适配稳定性、监控、告警与容灾大模型可以生成其中一部分代码但它无法独立承担事务一致性、数据权限、合规审计这些工程责任。更关键的是企业客户不会因为 AI 能生成软件就放弃对数据安全、交付质量、运维保障的要求。1.3 为什么“杀死”没有发生从实际项目反馈来看生成式 AI 并没有让企业停止购买 SaaS反而让 SaaS 产品的形态发生了变化。第一AI 生成的代码需要有人维护。交付软件只是起点后续的版本迭代、Bug 修复、性能优化才是成本大头这部分仍然依赖工程体系。第二企业数据不会随便交给公有大模型。很多 SaaS 客户对数据出域非常敏感私有化部署、本地知识库、权限隔离成为刚需而这些恰恰是 SaaS 平台原有的能力。第三SaaS 的核心价值不只是“功能”还包括流程沉淀、数据模型、集成生态和行业最佳实践。AI 可以增强这些价值但很难从零生成一套沉淀多年的业务模型。所以“AI 杀死 SaaS”这个说法本质上混淆了“交互入口”和“业务系统”两个层次。AI 改变的是入口SaaS 提供的是底盘。2. 反转的本质SaaS 没有被杀死而是被重写2.1 从“软件服务”到“智能服务”反转之后的行业共识是SaaS 不会被 AI 杀死但传统 SaaS 会被 AI 原生的 SaaS 重写。所谓 AI 原生不是给软件加一个聊天框而是从架构层面把大模型能力嵌入业务流程。传统 SaaS 的典型交互是用户打开界面点菜单填表单提交后系统执行逻辑。AI 原生 SaaS 的典型交互是用户用自然语言描述目标Agent 理解意图调用内部工具和数据完成操作并返回结果。从产品形态看变化是显著的维度传统 SaaSAI 原生 SaaS交互方式菜单、表单、按钮对话、自然语言指令核心逻辑固定流程意图识别 工具调用 流程编排数据访问界面绑定数据权限控制下的数据访问交付方式功能迭代交付模型 系统持续演进维护成本功能维护为主模型效果 系统稳定性双维护但底层的东西没有变用户身份、租户隔离、数据权限、审计追踪、计费与订阅。这些仍然是 SaaS 的生命线也是 AI 无法自动解决的问题。2.2 AI 原生 SaaS 的关键技术组件做 AI 原生 SaaS技术栈上通常围绕下面几块展开。第一是 Agent智能体。Agent 负责理解用户目标拆解成多个步骤决定调用哪些工具并在执行过程中处理异常。第二是 Function Calling函数调用。大模型本身不直接操作业务数据库而是通过定义好的函数接口来间接执行操作。函数调用让模型从“生成文本”变成“驱动系统”。第三是 RAG检索增强生成。企业私有知识、历史工单、产品文档不能实时进大模型训练RAG 通过向量检索先把相关内容捞出来再交给大模型生成答案是目前私有化 AI 功能的主流方案。第四是 MCP模型上下文协议。MCP 把大模型和外部工具、数据源之间的连接标准化让同一个模型可以复用地访问不同的业务系统。这一层解决的是“连接”问题。第五是权限与隔离。AI 不能绕过原有 SaaS 的权限体系。用户让 AI 查数据AI 只能查该用户有权限的数据用户让 AI 下单AI 只能在其授权范围内操作。这是 AI 原生 SaaS 最容易被忽略、也最容易出事故的一环。2.3 多租户与数据隔离仍然是核心很多团队在给 SaaS 接入 AI 时第一版只想着把模型 API 接上却忘了数据隔离这是非常危险的。比如一个多租户的 CRM 系统租户 A 和租户 B 的数据存在同一个数据库里靠 tenant_id 区分。如果 AI 查询逻辑没有强行拼接 tenant_id模型生成的查询语句就可能跨租户读取数据。这属于严重的事故级别。正确的做法是所有 AI 访问数据的入口都必须经过 SaaS 原有权限层不能为了让 AI“更自由”而绕过权限校验。换句话说AI 只能作为业务系统的执行者而不能成为业务系统的例外。3. 技术拆解在 SaaS 里接入 AI 的最小组件下面我们用一套简化示例演示 AI 原生 SaaS 的几个核心组件是怎么工作的。示例以常见环境为例语言使用 Python重点演示思路不绑定具体云服务。3.1 环境准备与版本说明建议环境如下操作系统Windows / macOS / Linux 均可Python3.10 及以上依赖库openai、flask、python-dotenv模型任意支持 Function Calling / Tool Use 的大模型接口数据库示例使用 SQLite生产环境建议替换为 PostgreSQL 或 MySQL版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路和完整链路。先安装依赖pip install openai flask python-dotenv在项目根目录创建.env 文件MODEL_API_KEY你的模型接口密钥 MODEL_BASE_URLhttps://你的接口地址 MODEL_NAME模型名称注意不要把密钥提交到 Git 仓库.env 文件应加入 .gitignore。3.2 第一步定义工具函数大模型不能直接操作数据库需要你先把可执行的操作封装成函数然后把这些函数的描述告诉模型。模型根据用户意图选择函数并传入参数应用层负责实际执行。先创建一个简单的订单查询函数# 文件路径services/order_service.py from typing import Dict, Any # 模拟的订单数据 ORDERS [ {id: 1001, tenant_id: t1, customer: 张三, amount: 1200.00, status: 已完成}, {id: 1002, tenant_id: t1, customer: 李四, amount: 800.00, status: 待付款}, {id: 1003, tenant_id: t2, customer: 王五, amount: 2500.50, status: 已完成}, ] def get_orders_by_tenant(tenant_id: str) - Dict[str, Any]: 根据租户 ID 查询订单列表必须传入当前登录用户的租户 ID result [order for order in ORDERS if order[tenant_id] tenant_id] return {code: 0, data: result}注意函数里强制要求传入 tenant_id这是为了确保 AI 只能访问当前租户的数据。3.3 第二步把函数描述传给模型模型侧需要知道有哪些函数可以用、参数是什么。下面这段代码定义了 order 查询工具的 schema# 文件路径agent/tools.py TOOLS [ { type: function, function: { name: get_orders_by_tenant, description: 根据租户ID查询订单列表租户ID必须来自当前登录用户会话不能由用户自由指定, parameters: { type: object, properties: { tenant_id: { type: string, description: 当前登录用户所属的租户ID } }, required: [tenant_id] } } } ]这个描述非常重要。你要明确告诉模型tenant_id 必须从当前登录会话获取不能由用户自由指定。如果不加这个约束模型可能把用户话里的“查看租户 A 的订单”直接当成参数传进去造成越权。3.4 第三步实现工具调用循环当模型返回需要调用某个函数时应用层要执行对应函数并把结果拼接回对话上下文再让模型生成最终回答。这是 Function Calling 的标准循环。# 文件路径agent/agent.py import json from openai import OpenAI from services.order_service import get_orders_by_tenant from agent.tools import TOOLS def build_client(): client OpenAI( api_keyos.getenv(MODEL_API_KEY), base_urlos.getenv(MODEL_BASE_URL) ) return client def run_agent(user_message: str, tenant_id: str): client build_client() messages [ {role: system, content: 你是一个订单助手只能查询当前租户的数据。}, {role: user, content: user_message} ] # 第一轮让模型决定是否调用工具 response client.chat.completions.create( modelos.getenv(MODEL_NAME), messagesmessages, toolsTOOLS, tool_choiceauto ) message response.choices[0].message messages.append(message) # 如果模型决定调用工具 if message.tool_calls: for tool_call in message.tool_calls: if tool_call.function.name get_orders_by_tenant: # 注意tenant_id 来自会话上下文而不是用户输入 tool_args {tenant_id: tenant_id} tool_result get_orders_by_tenant(**tool_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(tool_result, ensure_asciiFalse) }) # 第二轮模型基于工具结果生成最终回答 second_response client.chat.completions.create( modelos.getenv(MODEL_NAME), messagesmessages, toolsTOOLS ) return second_response.choices[0].message.content return message.content这里的关键点是传给函数的参数由应用层拼接而不是直接使用模型输出里可能携带的任意 tenant_id。如果你完全信任模型传参就可能在多租户场景下出现数据越权。4. 最小实战案例给 SaaS 加一个 AI 订单查询助手接下来我们把上面的组件组合成一个最小的可运行 Flask 服务模拟 AI 原生 SaaS 的后端链路。4.1 项目结构建议的目录结构如下ai-saas-demo/ ├── .env ├── .gitignore ├── requirements.txt ├── app.py ├── agent/ │ ├── __init__.py │ ├── agent.py │ └── tools.py └── services/ ├── __init__.py └── order_service.pyrequirements.txt 内容openai1.0.0 flask2.0.0 python-dotenv1.0.04.2 编写核心代码app.py 实现一个简化路由。真实系统中这里的 user_id 和 tenant_id 应该来自登录态示例中写死是为了演示链路。# 文件路径app.py import os from flask import Flask, request, jsonify from dotenv import load_dotenv from agent.agent import run_agent load_dotenv() app Flask(__name__) app.route(/api/ai/orders, methods[POST]) def ai_orders(): data request.get_json(forceTrue) user_message data.get(message, ) # 真实项目中这两个值从 session / token 解析得到 current_user_id u_1001 current_tenant_id t1 if not user_message: return jsonify({code: parameter_error, message: message 不能为空}), 400 try: result run_agent(user_message, current_tenant_id) return jsonify({code: 0, data: {reply: result}}) except Exception as exc: app.logger.error(AI agent 调用失败: %s, exc) return jsonify({code: agent_error, message: str(exc)}), 500 if __name__ __main__: app.run(host0.0.0.0, port8000, debugTrue)这里把 current_tenant_id 显式传递到 run_agent本质上是把权限边界放在应用层。不管用户怎么问模型都只能查 t1 租户的数据。4.3 运行与验证启动服务python app.py然后用 curl 测试接口curl -X POST http://127.0.0.1:8000/api/ai/orders \ -H Content-Type: application/json \ -d {message: 查一下我们最近的订单}预期返回是一段自然语言描述内容只包含 t1 租户的订单数据不会出现 t2 租户的订单。这里演示了接入 AI 功能后 SaaS 的最小闭环用户请求进入业务系统业务系统从会话中解析租户信息Agent 调用模型进行意图识别模型选择工具应用层执行工具结果回传模型生成自然语言回复回复返回给用户5. 常见问题与排查思路给 SaaS 接入 AI 时常见的坑集中在数据权限、上下文管理、结果稳定性、成本控制几个方面。问题现象常见原因解决思路模型回复了其他租户的数据工具函数参数由用户输入直接拼接没有使用会话上下文强制使用应用层注入的 tenant_id忽略模型传到该字段的任意值在工具描述中明确约束模型调用不存在的函数工具描述太模糊或者模型版本不支持 Function Calling检查工具 schema 是否有拼写错误确认模型接口支持工具调用必要时升级模型版本AI 回答与业务数据不一致工具结果没有正确拼接回 messages模型只凭记忆生成将工具返回值作为 tool 消息写回 messages再发起第二轮请求长对话后模型丢失约束system prompt 放在最前面但被长上下文稀释在每次请求前重新注入 system prompt并可以考虑在用户消息前面追加安全约束接口响应慢模型调用耗时长尤其工具多、上下文大增加超时和重试机制对常见问题做缓存减少历史消息数量费用上涨明显每次请求都带全量历史消息以及模型在无效工具调用上反复尝试限制上下文长度控制工具数量对失败任务做降级处理最隐蔽的问题是“间接越权”。比如模型虽然只查了当前租户的订单但工具返回的结果在prompt 中被重新表述时模型可能把字段拼错、把金额算错。因此除了权限控制还要在关键环节加校验模型返回的操作意图要落审计日志执行写操作前增加二次确认工具结果返回的内容做脱敏处理敏感字段手机号、银行卡号默认不返回模型6. 最佳实践与工程建议6.1 权限设计AI 不能绕过原有权限体系AI 接入 SaaS 的第一原则是AI 是执行者不是特权用户。任何通过 AI 完成的数据读取和操作都必须经过原有鉴权逻辑。实际项目中建议把 AI 的函数调用封装成独立的服务层统一接收三个参数用户身份租户上下文目标意图服务层内部再调用业务模块业务模块不感知调用方是用户还是 AI。这样权限逻辑可以复用也方便审计。6.2 数据安全私有化与大模型接口之间的边界企业使用 SaaS 时数据最终落到大模型接口很多客户无法接受。处理方式通常有两种使用私有化部署的模型数据不出内网使用公有模型接口但只把非敏感的业务摘要传给模型敏感字段在服务端脱敏RAG 也是常见的数据接入方式。把企业私有文档向量化后检索阶段只取相关片段不需要把全量知识库发给模型。但要注意向量库本身的权限控制同样重要否则检索阶段就可能跨租户命中数据。6.3 稳定性AI 功能必须可降级AI 能力存在不确定性模型接口可能超时、限流、返回错误。SaaS 产品不能因为 AI 挂了整个业务就不可用。建议在架构上做降级设计AI 功能独立部署故障不蔓延到核心业务关键操作保留传统表单入口模型调用设置超时时间超时后返回兜底提示对高并发场景做限流防止模型接口费用失控6.4 成本控制上下文越长费用越高大模型按 token 计费上下文越长成本越高。很多 SaaS 在接入 AI 后第一个月费用暴涨原因往往是历史消息无限制累积。控制成本的常用手段只保留最近 N 轮对话对用户问题做摘要压缩后再传给模型常用查询走缓存不重复请求模型工具返回结果过长时先做结构化截断6.5 可观测性记录模型输入输出与工具调用AI 功能上线后链路比传统接口长很多问题排查难度也随之上升。如果只记录 HTTP 状态码根本定位不到是模型理解错了还是工具执行出错。建议至少记录以下内容用户原始输入最终输入模型的完整 messages模型是否调用了工具、调用了哪个、参数是什么工具执行结果模型最终输出耗时与 token 消耗这些日志既要用于排查也要用于后续评估模型效果是 AI 原生 SaaS 的重要资产。7. 下一步可以怎么继续深入AI 杀死 SaaS 的故事正在反转反转背后不是技术倒退而是技术边界被理解得更清楚。真正有价值的机会在于把大模型的智能能力与传统 SaaS 的工程能力结合起来权限体系负责边界Agent 负责意图理解RAG 负责知识接入Function Calling 负责操作执行。如果你现在正在做 SaaS 产品可以从一个具体场景开始尝试选择一个用户高频操作、且规则相对明确的功能把它改造成 AI 自然语言入口同时保留传统操作路径。这样既能让用户感受到 AI 的价值又不会因为模型不稳定而影响核心业务。下一步可以重点学习几个方向Function Calling 的工具编排与异常恢复RAG 的召回质量评估与权限过滤Agent 的多步任务拆解与状态管理多租户场景下向量数据存储的隔离方案动手做一个最小原型比反复讨论“AI 会不会取代 SaaS”更有价值。先把一个场景跑通再逐步扩展这条路对个人学习者和企业团队都适用。