# AI 原生 SaaS：让 AI 进入可治理的企业业务流程
把大模型接入系统并不困难。真正困难的是：当 AI 开始查询企业数据、调用业务接口、跨应用完成任务时，平台能否确定它代表谁、可以做什么、执行了什么，以及出现异常后如何追踪和停止。
这也是“接入 AI”与“AI 原生”之间的分界线。前者通常增加一个新的交互入口，后者则要求平台重新组织业务能力、权限模型、执行流程和交付方式。
G2rain 对 AI 原生 SaaS 的理解是：让经过治理的平台能力可以被 AI 理解、组合和执行，同时保留企业系统需要的身份、权限、审计、租户隔离和人工控制。
# 为什么一个聊天框远远不够
传统 SaaS 的主要交互方式是菜单、表单和固定流程。接入大模型后，用户可以用自然语言表达目标，但目标最终仍要落到确定的业务操作上。
如果平台没有先解决能力边界，AI 很快会遇到几个现实问题：
- 接口数量很多，但缺少稳定、清晰的业务语义。
- 同一个操作在不同应用中有不同身份与权限要求。
- 模型可以生成方案，却无法安全地执行真实业务动作。
- 流程跨越多个服务后，调用过程缺少统一监控和审计。
- 每个客户的流程不同，最终又回到大量定制代码。
因此，AI 原生不是从模型开始，而是从平台是否具备“可被调用且可被治理的业务能力”开始。
# 判断 AI 原生平台的五个问题
一个企业平台是否具备 AI 原生基础，可以先回答五个问题：
- 能力是否可描述？ AI 能否理解某个接口代表的业务动作、输入、输出和约束？
- 调用是否可授权？ 每次执行能否关联用户、应用、租户、角色与功能权限？
- 流程是否可编排？ 多个原子能力能否组成客户自己的业务流程，而不是重新开发一个接口？
- 运行是否可观测？ 平台能否记录执行步骤、结果、异常和关键决策？
- 能力是否可交付？ Agent 或 Skill 能否像其他业务能力一样被分配、开通、升级和停止？
只有这五个问题形成闭环，AI 才可能从演示环境进入长期运行的企业系统。
# G2rain 的 AI Native 能力链路
G2rain 规划的完整链路可以概括为：
DDD 业务域 → 最小颗粒度接口 → MCP Server → Agent / Skill → 云端编排执行 → 权限、审计与监控
这不是把已有 API 简单包装给模型，而是逐层建立清晰边界。
# 1. 用 DDD 划分业务边界
AI 要可靠调用能力，首先需要稳定的业务语义。G2rain 通过 DDD 组织平台核心与业务域，使“查询内容”“维护部门”或“开通业务能力”等动作属于明确的领域，而不是散落在控制器和页面逻辑中。
领域边界越清晰，能力的输入、输出、副作用和责任归属就越容易被描述，也越适合后续编排。
# 2. 暴露最小颗粒度接口服务
面向页面设计的大接口往往同时完成查询、校验和多项写入，不适合由 AI 灵活组合。AI Native 更需要职责单一、结果明确的原子能力。
“最小颗粒度”并不意味着无限拆分，而是每个能力应当：
- 对应一个可理解的业务动作。
- 有明确的输入、输出与错误语义。
- 能独立执行权限判断和参数校验。
- 对是否产生数据变更保持清晰说明。
- 可以被多个流程复用，而不是绑定某一个页面。
# 3. 通过 MCP Server 建立标准能力入口
MCP Server 的作用，是把经过筛选和描述的平台能力组织为 AI 可以发现和调用的标准入口。它连接的是 AI 运行环境与企业业务服务，但不会替代平台原有的身份、权限和领域规则。
平台需要为每项能力补充名称、用途、参数、返回值、失败条件和访问要求。只有具备这些上下文，模型才能在正确场景选择正确工具。
# 4. 用 Agent 和 Skill 表达角色与流程
原子能力解决“能做什么”，Agent 和 Skill 则进一步表达“由谁、按照什么方法完成目标”。
- Agent 面向一个相对稳定的职责，例如内容运营助手或平台运维助手。
- Skill 封装可复用的任务方法、工具组合和执行约束。
- 流程编排 把多个 Skill 与业务能力组合成租户自己的工作方式。
客户不必改变平台底层模块，就可以围绕自身制度、组织结构和审批习惯定义不同执行路径。
# 5. 在云端完成执行、监控与治理
真正进入企业生产流程后，平台不能只关心最终回答，还需要管理整个执行过程：
- 每一步调用使用了哪个用户、应用和租户身份。
- 调用了哪些工具，读取或修改了哪些业务对象。
- 哪些步骤成功、失败、重试或被人工终止。
- 高风险操作是否经过确认或审批。
- Agent、Skill 和提示配置使用的是哪个版本。
云端编排的价值，是让这些过程进入统一治理范围，而不是散落在客户端脚本或一次性对话中。
# 企业级底座为什么不可跳过
AI 不应该绕过 SaaS 平台原有的控制体系。相反，它应当成为一种新的受控调用方。
G2rain 现有平台能力为此提供了几类基础：
# 身份基础
g2rain-iam 负责统一认证和令牌主链路；每个接入应用还具备独立身份。未来的 Agent 调用需要同时回答“代表哪个用户”和“通过哪个应用或执行主体发起”。
# 权限基础
g2rain-basis 将角色、资源、应用、功能权限和业务能力组织在统一模型中。AI 可以调用什么，不应由模型自行决定，而应由平台在执行时做确定性授权。
# 入口与隔离基础
网关负责统一访问入口，租户、部门和数据权限约束可见范围。即使模型正确选择了工具，业务服务仍必须执行租户隔离、权限校验和数据规则。
# 交付基础
应用承载功能权限和业务能力，业务能力又可以与租户开通、商品和订阅流程衔接。这意味着 Agent 与 Skill 未来也可以进入可分配、可开通、可回收的交付体系，而不是部署后对所有用户默认开放。
# 一个业务场景如何被重新组织
以“准备并发布一篇企业内容”为例，传统做法通常是在 CMS 中设计固定表单和审批流程。如果不同客户的素材来源、审核角色和发布规则不同，系统就需要不断增加分支或定制代码。
在 AI Native 模式下，可以把流程拆成若干受控能力：
- 根据用户目标收集主题与素材。
- 查询 CMS 中已有栏目、标签和历史内容。
- 生成内容草稿，并调用确定性规则完成格式检查。
- 根据租户流程提交指定角色审核。
- 审核通过后，由具备发布权限的执行主体调用发布能力。
- 平台记录使用的素材、执行步骤、审核人和最终结果。
这里，大模型负责理解目标、生成内容和选择下一步；身份认证、权限判断、状态流转和最终发布仍由平台能力确定执行。不同客户可以调整 Agent 或 Skill 的组织方式，而不必改写 CMS 的核心领域逻辑。
这个示例用于说明目标架构，并不表示上述完整流程已经作为现成产品交付。
# AI 与确定性系统的责任边界
AI 原生不意味着所有流程都交给模型。企业平台更需要明确两类能力的分工。
适合由 AI 参与的部分包括：
- 理解自然语言目标和非结构化资料。
- 在多个可用能力中选择合适的执行路径。
- 生成草稿、摘要、分类建议和处理方案。
- 处理存在一定弹性的流程编排。
仍应由确定性系统负责的部分包括：
- 身份认证、权限判断和租户隔离。
- 金额、库存、计量、计费等关键业务规则。
- 数据一致性、事务和幂等控制。
- 最终状态变更、审计留痕和合规约束。
高风险写操作还应提供人工确认、审批、额度限制或回滚机制。AI 可以提出并组织动作，但不能成为绕过治理的捷径。
# 从现有平台走向 AI Native
G2rain 的推进路径不是先建设一个孤立的 AI 平台，而是沿着现有 SaaS 架构逐步演进。
# 第一阶段：平台能力标准化
持续完善统一身份、应用、角色资源、功能权限、业务能力、网关和部署体系；通过 DDD 与工程规范让业务接口具备稳定边界。
# 第二阶段：能力 AI 可用化
选择边界清晰、风险可控的接口接入 MCP Server，为能力补充可靠描述、参数约束、权限要求和错误语义。
# 第三阶段：Agent / Skill 场景化
围绕具体业务目标构建 Agent 与 Skill，先从查询、辅助生成和建议类场景开始，再逐步引入经过确认的写操作。
# 第四阶段：运行治理与租户交付
建立版本、监控、审计、评估和人工介入机制，并把 AI 能力纳入应用与业务能力模型，支持按租户交付和持续升级。
当前 20 个正式开源项目主要提供平台核心、业务扩展、应用接入、工程化和部署基础；MCP、Agent、Skill 与云端编排是建立在这些基础上的重点演进方向。公开文档会随着对应能力落地持续更新。
# 应该怎样衡量价值
AI Native 的价值不能只看模型回答是否“聪明”，更应该观察平台和业务指标：
- 一个新流程需要新增多少定制代码。
- 已有业务能力在不同租户流程中的复用比例。
- 从需求提出到可用流程上线需要多长时间。
- AI 工具调用的成功率、重试率和人工接管率。
- 高风险动作的确认、拒绝和回滚是否完整。
- 每次执行能否还原身份、权限、输入、步骤与结果。
这些指标共同回答一个更重要的问题：AI 是否真正降低了企业流程适配成本，同时没有削弱平台治理。
# 结语
AI 原生 SaaS 的终点不是让每个页面都出现聊天框，而是让企业已经沉淀的能力可以通过自然语言被发现、组合和执行。
这个过程必须建立在清晰的领域边界、标准接口、应用身份、功能权限、租户隔离、运行监控和持续交付之上。G2rain 正在做的，是把这些基础能力与 MCP、Agent、Skill 和云端编排连接起来，形成一条从平台能力到客户业务流程的可治理路径。
当新增需求不再总是等价于新增一轮定制开发，而能够更多地通过能力复用和流程编排完成，AI 才真正成为 SaaS 平台的原生组成部分。