33 KiB
七虎 AI PaaS 平台 · 应用服务接入规范(可行性方案)
文档版本:v1.0.0
生成日期:2026-07-27
定位:七虎 AI PaaS 平台"应用服务"模块的接入标准、集成模式与落地路线图
前置依赖:本文件承接《AI_PaaS_Platform_Analysis_and_Execution_Plan.md》第五部分(七虎AI全面评估)的结论,将其"应用服务接入"从单点案例(MuMuAINovel)升级为平台级规范
目标读者:平台架构组、应用接入开发者、技能市场运营、安全审计
0. 背景与定位
0.1 为什么要做"应用服务接入规范"
七虎 AI PaaS 的定位是"AI 体验、办公提效、创收、自我提升的一站式交互平台"。平台的能力供给有三种形态:
| 形态 | 单位 | 执行环境 | 典型例子 |
|---|---|---|---|
| 技能(Skill) | 提示词 + 脚本 + SKILL.md | 平台 Agent 沙箱内执行 | dashi-ppt-skill、SEO 优化、投研报告 |
| 应用服务(App Service) | 独立可运行的应用 | 独立容器/子域名,单点登录接入 | MuMuAINovel、OpenCut、next-ai-draw-io |
| IM Bot | 消息驱动的长连接 Agent | 平台 IM 网关内执行 | 微信 Bot、企微 Bot、飞书 Bot |
"应用服务"是平台差异化最大的形态——它让第三方成熟的开源 AI 应用(小说创作、视频剪辑、绘图、求职……)一键接入平台,用户无需离开七虎 PaaS 即可使用,所有模型调用、Token 计量、订阅计费、会员权益都由平台统一管控。
0.2 本文件要解决的核心问题
- 什么样的开源项目适合接入? → 选型评估矩阵
- 接入分哪几档?每档改什么? → 三级集成深度模型
- 标准接入流程是什么? → 从选型到上线的 SOP
- 统一走平台的模型、计费、订阅,技术上怎么落地? → 架构模式 + 代码骨架
- 许可证风险怎么规避? → GPL/MIT/Apache 兼容策略
- 第一批接入哪些应用做样板? → 基于 Starred 列表的推荐清单
1. 候选应用选型评估矩阵
1.1 从 Starred 列表筛选的 6 个候选
结合你 GitHub starred 列表(259 个项目),按"是否独立可运行、是否有自托管能力、是否依赖 AI 模型、是否与平台定位契合"四要素,筛选出以下 6 个最适合做"应用服务"接入的候选:
| # | 项目 | Stars | 协议 | 技术栈 | 应用类型 | 接入价值 |
|---|---|---|---|---|---|---|
| 1 | MuMuAINovel | 新建 | GPL-3.0 | FastAPI + PG + React/AntD | AI 小说创作 | 长文本创作,高 Token 消耗,验证订阅闭环 |
| 2 | OpenCut | 78.5K | MIT | Next.js + Rust/WASM + PG + Redis | 视频剪辑 | 自媒体/短视频场景,MCP Server 规划中 |
| 3 | next-ai-draw-io | 33.8K | Apache-2.0 | Next.js + React | AI 流程图/架构图 | 办公提效,开发者高频刚需 |
| 4 | HyperFrames | 37.5K | Apache-2.0 | Node.js + headless Chrome + FFmpeg | HTML→MP4 视频渲染 | 课件/营销视频自动化生产 |
| 5 | dashi-ppt-skill | 4.1K | MIT | Node.js + React 渲染引擎 | PPT 生成/编辑 | 办公提效标杆,已做本地优先 |
| 6 | ai-job-search | 26.4K | MIT | TypeScript + Python + LaTeX | AI 求职流水线 | 个人提升场景,Drafter-Reviewer 范式 |
1.2 六维量化评估
对每个候选按 6 个维度打分(1-5),加权算出"接入适配总分":
| 维度 | 权重 | 评估要点 |
|---|---|---|
| 自托管能力 | 15% | Docker 一键部署?有无官方镜像? |
| 认证可替换性 | 20% | 是否已有 OAuth/OIDC 适配器?是否易加 Casdoor? |
| AI 调用可代理 | 20% | 是否走 OpenAI 兼容协议?能否改 BASE_URL? |
| 许可证友好度 | 15% | MIT/Apache 最友好,GPL 需外围集成规避 |
| 与平台定位契合 | 15% | 是否覆盖技能市场/办公/创作/提效场景 |
| 社区活跃度 | 5% | Stars、近期更新频率 |
| 数据隔离可行性 | 10% | 是否用 PG/可加 tenant_id/RLS |
1.3 评估结果
| 项目 | 自托管 | 认证 | AI代理 | 协议 | 契合 | 社区 | 隔离 | 加权总分 | 推荐档位 |
|---|---|---|---|---|---|---|---|---|---|
| MuMuAINovel | 5 | 4(已有LinuxDO OAuth) | 5(OpenAI兼容) | 2(GPL) | 5 | 3 | 5 | 4.25 | 🥇 首批·深度接入 |
| OpenCut | 5 | 3(需新增) | 4(AI功能可代理) | 5(MIT) | 4 | 5 | 4 | 4.20 | 🥇 首批·标准接入 |
| next-ai-draw-io | 5 | 3 | 5(多Provider) | 5(Apache) | 5 | 4 | 4 | 4.40 | 🥇 首批·标准接入 |
| HyperFrames | 4 | 2(CLI为主) | 5(走LLM生成HTML) | 5(Apache) | 4 | 4 | 3 | 3.95 | 🥈 第二批·轻量接入 |
| dashi-ppt-skill | 4(本地Node) | 1(无登录) | 5 | 5(MIT) | 5 | 4 | 2 | 3.70 | 转"技能"更合适 |
| ai-job-search | 3(CLI为主) | 1(无登录) | 5 | 5(MIT) | 4 | 5 | 2 | 3.55 | 转"技能"更合适 |
1.4 关键结论
首批接入 3 个应用做样板(按 ROI 排序):
- 🥇 MuMuAINovel —— 验证"平台统一模型+计费+订阅"的核心闭环(GPL 走外围集成规避)
- 🥇 next-ai-draw-io —— 协议最友好(Apache-2.0)、认证易加、办公提效高频刚需
- 🥇 OpenCut —— Stars 最高、MIT 最自由、视频场景与平台"自媒体/短视频创作"定位契合
第二批(2-3 个月后):HyperFrames(视频渲染 API 化后)、以及新出现的应用级项目。
dashi-ppt-skill 和 ai-job-search 不应作为"应用服务"接入——它们更适合作为"技能"上架到技能市场(本文件承接前份报告的第三部分改造方案)。这个判断很重要:应用服务 vs 技能的边界,下文第 2 节专门界定。
2. 核心概念:应用服务 vs 技能 vs IM Bot
接入前必须明确三者的边界,避免把"该做成技能的项目"错误升级为"独立应用",浪费容器资源。
2.1 决策树
一个新能力要上平台,先回答三个问题:
① 它有独立的前端 UI 吗?(用户要在独立界面里操作,不只是对话)
② 它需要长时间运行/持有状态吗?(如剪辑时间线、小说章节树、绘图画布)
③ 它单用户运行资源占用高吗?(视频渲染、GPU 合成、大型依赖)
①=否 → 做成【技能】 → 例:SEO 优化、投研报告、信息图生成
①=是 且 ②③ 中至少一个=是 → 做成【应用服务】 → 例:MuMuAINovel、OpenCut
①=是 且 ②③ 都=否 → 看交互模式:
以"消息对话"为主 → 做成【IM Bot】 → 例:微信客服 Bot
以"画布/编辑器"为主 → 做成【应用服务】 → 例:next-ai-draw-io
2.2 三类形态对比
| 维度 | 技能(Skill) | 应用服务(App Service) | IM Bot |
|---|---|---|---|
| 执行环境 | 平台 Agent 沙箱 | 独立容器/子域名 | 平台 IM 网关 |
| 前端 | 无(对话即界面) | 有(独立 Web UI) | 消息气泡 |
| 模型调用 | 平台 Agent 引擎统一 | 走平台 AI 网关代理 Key | 平台 Agent 引擎 |
| 计费单元 | 按次/按 Token | 按应用订阅/按 Token | 按会话/按 Token |
| 数据归属 | 平台知识库 | 应用内 DB + 平台审计 | 平台消息存档 |
| 上架审核 | SKILL.md + CI | 完整应用安全审计 | Bot 权限清单 |
| 典型生命周期 | 轻量,可热更新 | 重,需版本化部署 | 常驻,需心跳 |
3. 三级集成深度模型
所有应用接入分三档,按平台成熟度渐进式推进:
3.1 L1 · 浅集成(快速上线,3-5 天)
目标:单点登录打通,用户在平台内一键进入应用,但模型调用和计费暂由应用自理。
改造项:
| 改造点 | 应用侧 | 平台侧 |
|---|---|---|
| 认证 | 新增 Casdoor OIDC 适配器 | 在 Casdoor 注册应用、颁发 Client ID/Secret |
| 会话 | 用 OIDC 回调建立本地会话 | 提供 /.well-known/openid-configuration |
| 登录页 | 隐藏/禁用本地注册(可选) | 平台前台"应用服务"卡片 → 跳转授权 |
适用场景:早期 MVP、应用尚未完成模型代理改造、快速扩充平台"应用数量"。
3.2 L2 · 中集成(核心目标,2-3 周)⭐ 推荐默认档
目标:模型调用统一走七虎 AI 网关,平台统一计量、计费、订阅校验。
改造项(在 L1 基础上增加):
| 改造点 | 应用侧 | 平台侧 |
|---|---|---|
| AI 调用 | OPENAI_BASE_URL 指向平台网关 |
AI 网关新增代理 Key 校验中间件 |
| 密钥 | 用平台颁发的 PLATFORM_PROXY_KEY 替代用户自配 Key |
market_apps.proxy_key 颁发与管理 |
| 计量 | 每次调用透传 X-Platform-User-Id |
网关写入 token_usage_logs(app_id) |
| 订阅 | 启动时检查平台订阅态(可选增强) | 订阅校验端点 /api/v1/subscription/check |
| 配额 | 超限时优雅降级(提示充值) | 实时余额查询 API |
这是推荐的默认接入档位——L1 只是过渡,L2 才是"平台价值"真正体现的地方。
3.3 L3 · 深集成(生产级,4-6 周)
目标:多租户数据隔离、应用内增值购买、审计合规、平台级可观测。
改造项(在 L2 基础上增加):
| 改造点 | 应用侧 | 平台侧 |
|---|---|---|
| 数据隔离 | 所有表加 tenant_id,启用 PG RLS |
提供 RLS 策略模板 |
| 增值服务 | 高级功能走平台支付 API | 支付渠道 + 分润结算 |
| 审计 | 关键操作上报平台 audit_logs |
审计日志聚合查询 |
| 可观测 | 暴露 Prometheus 指标 | 平台 Grafana 统一看板 |
| 数据导出 | GDPR 导出/删除接口 | 用户注销级联清理 |
3.4 档位选择决策表
| 应用特征 | 推荐档位 | 理由 |
|---|---|---|
| 新建/重构中、协议友好、核心标杆 | L2 起步 | 一步到位,避免二次改造 |
| 成熟稳定、改动风险高(如 GPL 项目) | L1 → L2 渐进 | 先外围集成,验证后再深化 |
| 内部工具/实验性 | L1 即可 | 快速验证,不过度投入 |
| 金融/医疗/政企客户可达 | 必须 L3 | 合规刚需 |
4. 标准接入架构
4.1 整体拓扑
┌──────────────────────────────┐
│ 用户浏览器 │
└────────┬─────────────────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────────┐
│ 平台前台 │ │ 应用服务 A │ │ 应用服务 B │
│ (已登录态) │ │ (独立子域名) │ │ (独立子域名) │
│ │ │ │ │ │
│ /apps/novel ───┼─►│ novel.qihuyun │ │ drawio.qihuyun │
│ /apps/drawio ──┼─►│ OIDC 登录 │ │ OIDC 登录 │
│ /apps/video ───┼─►│ │ │ │
└────────────────┘ └───────┬────────┘ └─────────┬──────────┘
│ │
▼ ▼
┌────────────────────────────────────────────────┐
│ 七虎 AI 网关 (FastAPI) │
│ ┌──────────────────────────────────────────┐ │
│ │ 1. 代理 Key 校验 → 解析 user_id+app_id │ │
│ │ 2. 订阅/配额校验 → 拒绝或放行 │ │
│ │ 3. 模型路由 (LiteLLM) → 上游模型 │ │
│ │ 4. 计量写入 token_usage_logs │ │
│ │ 5. 流式响应返回 │ │
│ └──────────────────────────────────────────┘ │
└────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ Casdoor (OIDC IdP) │ PostgreSQL(RWS) │
│ Redis(会话/缓存) │ Meilisearch(搜索) │
└────────────────────────────────────────────────┘
4.2 单应用接入时序(L2 档位)
用户 平台前台 应用服务 Casdoor AI 网关
│ │ │ │ │
│ 点击"AI小说创作" │ │ │ │
│──────────────────────►│ │ │ │
│ │ 302 → 应用授权入口 │ │ │
│ │───────────────────►│ │ │
│ │ │ 重定向到 Casdoor │ │
│ │ │────────────────────►│ │
│ │ │ │ │
│ (用户已登录平台,静默授权) │ │ │
│ │ │ 302 + code ──────────────────────────────►│
│ │ │ │ │
│ │ │ 用 code 换 token │
│ │ │────────────────────►│ │
│ │ │◄──── JWT + userinfo ─│ │
│ │ │ │ │
│ │ │ 建立本地会话 │ │
│ │ │ 注入 user_id 到请求头 │ │
│ │ │ │ │
│ 在应用内发起 AI 请求 │ │ │ │
│ │ │ POST /v1/chat/completions │
│ │ │ Authorization: Bearer <proxy_key> │
│ │ │ X-Platform-User-Id: <user_id> │
│ │ │───────────────────────────────────────────►│
│ │ │ │ │
│ │ │ │ 校验 → 路由 → 计量 │
│ │ │ │ │
│ │ │◄──── 流式响应 ──────│ │
│◄──── 渲染结果 ────────│ │ │ │
5. 各应用接入改造要点(首批 3 个)
5.1 MuMuAINovel · 深度接入(L2)
为何首批第一:它是你主动提出、且最贴合"平台统一付费"诉求的项目;已有 LinuxDO OAuth 证明认证层可替换;OpenAI 兼容协议证明模型可调代理。
改造清单:
- 新增
CasdoorOIDCProvider类(照搬现有 LinuxDO 适配器模式) - 环境变量双模式:
PLATFORM_MODE=true/false切换自托管/平台托管 OPENAI_BASE_URL=https://api.qihuyun.com/app/api/aiserver/v1OPENAI_API_KEY=${PLATFORM_PROXY_KEY}(平台颁发的应用级 Key)- Docker Compose 加
depends_on: [casdoor, ai-gateway]
许可证处理(⚠️ GPL-3.0 重点):
- 方案 B:OIDC 适配器 + AI 代理层做成独立中间件/Sidecar,不修改 MuMuAINovel 核心源码 → 规避 GPL 传染性
- 在平台"开源致谢"页声明 MuMuAINovel 及 GPL-3.0 协议
- 部署容器命名为
mumuainovel-adapter+mumuainovel-core两层
预期效果:用户在七虎 PaaS 订阅 Pro+小说套餐 → 点击进入 MuMuAINovel → 静默登录 → 创作时消耗的是平台套餐内 Token → 用量实时出现在 Token 驾驶舱。
5.2 next-ai-draw-io · 标准接入(L2)
为何首批第二:Apache-2.0 协议最友好(无传染性);已有 ACCESS_CODE_LIST 密码机制说明认证层可扩展;支持 10+ AI Provider 且都走环境变量配置,模型代理最简单。
改造清单:
- 新增 Casdoor OIDC 适配器(项目用 Next.js,可用
next-auth库快速接入) - 通过环境变量统一 AI Provider 为平台网关:
AI_PROVIDER=openai AI_MODEL=qihuyun-default OPENAI_API_KEY=${PLATFORM_PROXY_KEY} OPENAI_BASE_URL=https://api.qihuyun.com/app/api/aiserver/v1 - 用
NEXT_PUBLIC_*注入平台用户上下文(user_id、subscription_tier) - 禁用
ACCESS_CODE_LIST(平台登录后无需二次密码)
协议优势:Apache-2.0 允许商业使用、修改、私有化部署,无开源传染风险。平台对其做的任何修改可选择性开源,也可私有。
预期效果:开发者在七虎 PaaS 点"AI 绘图"→ 进入 next-ai-draw-io → 用自然语言画云架构图/流程图 → 所有 AI 调用走平台网关计量。
5.3 OpenCut · 标准接入(L2)
为何首批第三:MIT 协议最自由;78.5K Stars 证明市场验证充分;"视频剪辑"是平台"自媒体/短视频创作"定位的核心场景;规划中的 MCP Server 与平台 Agent 生态天然契合。
改造清单:
- 认证:OpenCut 新版本正在重写,Editor API + 插件系统开放,OIDC 插件可作为官方插件形式接入
- AI 功能代理:OpenCut 的 AI 接入(智能剪辑、自动字幕、翻译)走平台网关
- 部署:Docker Compose 已含 PG + Redis,新增
casdoor-sidecar容器做认证代理 - 文件存储:用户上传的视频素材走平台对象存储(S3 兼容),不落应用本地盘
特殊处理:OpenCut 的视频渲染是计算密集型(GPU 合成、FFmpeg 编码),需单独规划资源配额:
- 容器资源限制:CPU/内存/GPU 配额按会员等级差异化
- 渲染任务异步化:提交→排队→渲染→回调通知(避免 HTTP 长连接超时)
- 大文件上传走分片 + 平台 CDN
预期效果:自媒体用户在平台订阅"创作套餐"→ 使用 OpenCut 剪辑短视频 → AI 字幕/翻译/去字幕走平台模型 → 渲染消耗平台算力配额。
6. 平台侧改造需求(支撑所有应用接入)
6.1 必须新增的平台能力
| 能力 | 说明 | 优先级 |
|---|---|---|
| 应用注册中心 | market_apps 表扩展(app_id, name, type='app_service', entry_url, proxy_key, is_platform_hosted, docker_compose_tpl) |
P0 |
| 代理 Key 体系 | 应用级 Key 颁发/轮换/吊销,关联 app_id + 配额 | P0 |
| AI 网关中间件 | 校验代理 Key → 订阅校验 → 路由 → 计量 → 审计 | P0 |
| OIDC 应用模板 | Casdoor 中预置应用配置,一键注册新应用 | P0 |
| 订阅套餐映射 | 会员套餐可包含"应用服务"权益(如 Pro+小说、创作套餐) | P0 |
| 用量看板(按应用) | Token 驾驶舱新增"按应用"维度统计 | P1 |
| 应用生命周期 | 部署/启停/升级/回滚/健康检查 | P1 |
| 审计聚合 | 各应用上报的操作日志统一入 audit_logs |
P2 |
6.2 数据库 Schema 扩展
-- 应用注册表(扩展现有 market_apps)
CREATE TABLE market_apps (
id VARCHAR(50) PRIMARY KEY,
name VARCHAR(200) NOT NULL,
type VARCHAR(20) NOT NULL DEFAULT 'skill', -- 'skill' | 'app_service'
category VARCHAR(50),
description TEXT,
icon_url VARCHAR(500),
entry_url VARCHAR(500), -- 平台托管型应用的访问入口
deployment_type VARCHAR(20), -- 'hosted' | 'external' | 'embedded'
docker_compose_tpl TEXT, -- Docker Compose 模板(hosted 型)
proxy_key_hash VARCHAR(256), -- 平台颁发的代理 Key(bcrypt)
auth_mode VARCHAR(20), -- 'casdoor_oidc' | 'platform_token' | 'none'
protocol_license VARCHAR(50), -- MIT / Apache-2.0 / GPL-3.0 等
integration_level INT DEFAULT 1, -- 1=L1浅 2=L2中 3=L3深
status VARCHAR(20) DEFAULT 'pending', -- pending/active/suspended
version VARCHAR(50),
repository_url VARCHAR(500),
is_featured BOOLEAN DEFAULT FALSE,
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
-- 应用实例(每个租户/用户部署一个实例)
CREATE TABLE app_instances (
id BIGSERIAL PRIMARY KEY,
app_id VARCHAR(50) REFERENCES market_apps(id),
tenant_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
instance_url VARCHAR(500),
container_id VARCHAR(200),
status VARCHAR(20) DEFAULT 'running',
deployed_at TIMESTAMP DEFAULT NOW(),
last_active_at TIMESTAMP,
resource_quota JSONB, -- {"cpu": 2, "memory_gb": 4, "gpu": 0}
rls_tenant_id BIGINT GENERATED ALWAYS AS (tenant_id) STORED
);
-- 应用订阅关联
CREATE TABLE app_subscriptions (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
app_id VARCHAR(50) REFERENCES market_apps(id),
plan_id VARCHAR(50),
status VARCHAR(20) DEFAULT 'active',
started_at TIMESTAMP DEFAULT NOW(),
expires_at TIMESTAMP,
payment_method VARCHAR(20), -- 'subscription_quota' | 'pay_per_use'
rls_tenant_id BIGINT
);
-- 扩展 token_usage_logs 增加 app 维度
ALTER TABLE token_usage_logs
ADD COLUMN IF NOT EXISTS app_id VARCHAR(50),
ADD COLUMN IF NOT EXISTS app_name VARCHAR(200),
ADD COLUMN IF NOT EXISTS billing_model VARCHAR(20); -- 'subscription' | 'pay_per_use'
-- RLS 策略(多租户隔离)
ALTER TABLE app_instances ENABLE ROW LEVEL SECURITY;
CREATE POLICY app_instances_tenant_isolation ON app_instances
USING (tenant_id = current_setting('app.current_tenant_id')::BIGINT);
6.3 AI 网关代理 Key 中间件(FastAPI 骨架)
# /app/api/aiserver/v1/chat/completions
from fastapi import Request, HTTPException, Depends
from fastapi.responses import StreamingResponse
import httpx, os
PLATFORM_AI_BACKEND = os.getenv("PLATFORM_AI_BACKEND") # 真实上游
@app.post("/app/api/aiserver/v1/chat/completions")
async def proxy_chat_completions(request: Request, body: dict):
# 1. 校验代理 Key
auth = request.headers.get("Authorization", "")
proxy_key = auth.replace("Bearer ", "")
app = await resolve_app_by_proxy_key(proxy_key)
if not app or not app["is_active"]:
raise HTTPException(401, "Invalid or revoked proxy key")
# 2. 解析用户 + 订阅校验
user_id = request.headers.get("X-Platform-User-Id")
subscription = await check_subscription(user_id, app["id"])
if not subscription or subscription["status"] != "active":
raise HTTPException(402, "Active subscription required for this app")
# 3. 配额检查
usage = await get_current_period_usage(user_id, app["id"])
if usage["tokens"] >= subscription["token_quota"]:
raise HTTPException(429, "Token quota exceeded, please upgrade")
# 4. 转发到真实上游(LiteLLM 或直连模型)
upstream_body = rewrite_request(body, target_model=subscription["allowed_model"])
async with httpx.AsyncClient(timeout=300) as client:
upstream_resp = await client.post(
f"{PLATFORM_AI_BACKEND}/v1/chat/completions",
json=upstream_body,
headers={"Authorization": f"Bearer {os.getenv('UPSTREAM_API_KEY')}"}
)
# 5. 计量(流式则异步累计)
await record_usage(
user_id=user_id,
app_id=app["id"],
app_name=app["name"],
model=upstream_body.get("model"),
prompt_tokens=upstream_resp.json().get("usage", {}).get("prompt_tokens", 0),
completion_tokens=upstream_resp.json().get("usage", {}).get("completion_tokens", 0),
billing_model="subscription"
)
return StreamingResponse(upstream_resp.aiter_bytes(), media_type="application/json")
7. 许可证风险管理
7.1 主流开源协议对比
| 协议 | 商业使用 | 修改后需开源 | 传染范围 | 适用接入策略 |
|---|---|---|---|---|
| MIT | ✅ | ❌(只需保留版权声明) | 无 | 自由集成、可改可闭源、最友好 |
| Apache-2.0 | ✅ | ❌(需声明修改) | 无 | 自由集成、需保留 NOTICE |
| GPL-3.0 | ✅ | ✅(衍生作品须 GPL) | 强传染 | 必须外围集成,不修改核心 |
| AGPL-3.0 | ✅ | ✅(网络服务也须开源) | 网络服务传染 | 避免修改,仅做协议适配 |
7.2 各候选项目的合规策略
| 项目 | 协议 | 风险点 | 合规方案 |
|---|---|---|---|
| MuMuAINovel | GPL-3.0 | 修改核心代码 → 衍生作品须 GPL | 外围集成:OIDC/AI代理做成独立 Sidecar,不改核心 |
| OpenCut | MIT | 几乎无 | 自由修改、可闭源,最省心 |
| next-ai-draw-io | Apache-2.0 | 需保留 NOTICE | 保留版权声明 + NOTICE 文件即可 |
| HyperFrames | Apache-2.0 | 同上 | 同上 |
| dashi-ppt-skill | MIT | 无 | 转技能上架,无顾虑 |
| ai-job-search | MIT | 无 | 转技能上架,无顾虑 |
7.3 平台级合规清单
每个接入应用必须:
- 在平台"开源致谢"页列出项目名称、作者、协议、仓库链接
- 保留原始 LICENSE 文件,不删除版权声明
- GPL 项目:修改(如有)以独立仓库开源,并在 README 声明
- 用户协议中说明"本平台部分功能基于开源项目构建"
- 联系原作者获取商业授权(GPL 项目强烈推荐,建立合作)
8. 落地路线图
8.1 三阶段推进
阶段一 · 奠基(第 1-4 周)
├── W1: 平台侧改造
│ ├── 扩展 market_apps 表 + RLS 策略
│ ├── AI 网关代理 Key 中间件
│ ├── Casdoor 应用注册模板
│ └── 订阅套餐映射
├── W2-3: MuMuAINovel L1 接入(OIDC 打通)
└── W4: next-ai-draw-io L1+L2 接入(双模式切换)
阶段二 · 标杆(第 5-8 周)
├── W5-6: MuMuAINovel 升级 L2(模型代理+计量)
├── W7: OpenCut L1+L2 接入
├── W8: 平台"应用服务"前台页面上线(卡片式入口)
阶段三 · 生态(第 9-12 周)
├── W9-10: 技能市场 + 应用服务统一审核流水线
├── W11: 应用内增值购买 + 分润结算
└── W12: HyperFrames 接入评估 + 第二批候选筛选
8.2 里程碑与验收标准
| 里程碑 | 验收标准 |
|---|---|
| M1:单点登录打通 | 用户在平台登录后,点击 3 个应用入口均能静默进入,无二次登录 |
| M2:模型统一路由 | 3 个应用的所有 AI 调用均走平台网关,上游模型可一键切换 |
| M3:计量闭环 | 平台 Token 驾驶舱可按"应用"维度展示用量,数据延迟 < 1 分钟 |
| M4:订阅闭环 | 用户订阅套餐包含应用权益,过期后应用自动提示升级 |
| M5:上架流程 | 第 4 个应用接入耗时 < 1 周(前 3 个的平均值的 50%) |
9. 风险与应对
| 风险 | 概率 | 影响 | 应对 |
|---|---|---|---|
| GPL 项目协议传染 | 中 | 高 | 外围集成策略 + 法律审查 + 作者商业授权 |
| 应用升级导致接入层破坏 | 中 | 中 | Docker 镜像锁定版本 + 适配层测试 + 灰度升级 |
| AI 网关成单点瓶颈 | 中 | 高 | LiteLLM 水平扩容 + Redis 缓存 + 熔断降级 |
| 多租户数据串扰 | 低 | 极高 | PG RLS 强制 + 集成测试 + 混沌工程 |
| 视频渲染资源耗尽 | 中 | 中 | 容器配额 + 任务队列 + 会员差异化 |
| 第三方应用安全漏洞 | 中 | 高 | 容器沙箱 + gVisor + 依赖扫描 + 最小权限 |
10. 与既有文档的承接关系
本文档是《AI_PaaS_Platform_Analysis_and_Execution_Plan.md》的专项延伸,承接关系如下:
| 既有章节 | 本文承接点 |
|---|---|
| 第二部分 §2.3 插件体系 | 应用服务是"插件"的终极形态——独立进程级插件 |
| 第三部分 dashi-ppt 改造 | dashi-ppt 转"技能"上架,本文界定它不该做"应用" |
| 第四部分 技能开发标准 | 本文 §2 的"应用 vs 技能"决策树与之互补 |
| 第五部分 §5.2.5 技能市场 | 应用市场是技能市场的"重型补充" |
| 第五部分 §5.4 优先级表 #5 | MuMuAINovel 接入即"落地标杆技能真实执行器"的具象化 |
附录 A:应用接入 SOP 检查清单
每个新应用接入必须逐条勾选:
A.1 选型评估
- 通过 §1.2 六维评估,总分 ≥ 3.5
- 许可证兼容(MIT/Apache 优先,GPL 走外围集成方案)
- 与平台定位契合(覆盖至少 1 个核心场景)
- 技术栈可容器化(Docker 镜像可用)
A.2 L1 接入(认证)
- 应用侧新增 Casdoor OIDC 适配器并通过联调
- 平台侧 Casdoor 注册应用、颁发 Client ID/Secret
- 平台前台"应用服务"卡片可跳转并静默登录
- 登出平台后,应用会话同步失效
A.3 L2 接入(模型+计费)
- 应用 AI 调用全部指向平台网关
- 平台代理 Key 颁发、轮换、吊销流程可用
- AI 网关中间件通过代理 Key 校验、订阅校验、计量写入
- Token 驾驶舱"按应用"维度统计正确
- 订阅过期后应用优雅降级(非 500 错误)
A.4 L3 接入(深度)
- 应用数据库启用 PG RLS,tenant_id 隔离验证通过
- 审计日志上报平台
audit_logs - 暴露 Prometheus 指标,平台 Grafana 可采集
- GDPR 数据导出/删除接口可用
- 安全审计通过(渗透测试 + 依赖扫描)
A.5 上架运营
- 平台"开源致谢"页已添加项目信息
- LICENSE 文件保留且完整
- 应用详情页(截图、介绍、入口、定价)已配置
- 监控告警已配置(可用性、延迟、错误率)
- 回滚预案已演练
附录 B:术语表
| 术语 | 含义 |
|---|---|
| 应用服务(App Service) | 独立可运行的 Web 应用,通过单点登录接入平台,共享平台模型与计费 |
| OIDC | OpenID Connect,基于 OAuth 2.0 的身份认证协议 |
| Casdoor | 开源的统一身份认证平台,本项目用作 OIDC IdP |
| 代理 Key(Proxy Key) | 平台颁发给应用的长期密钥,用于 AI 网关识别"哪个应用在代哪个用户调用" |
| AI 网关 | 平台统一接管所有模型调用的中间件,承担认证、路由、限流、计量、审计 |
| 外围集成 | 不修改目标项目核心源码,通过 Sidecar/中间件/环境变量方式接入,规避 GPL 传染 |
| RLS | Row Level Security,PostgreSQL 行级安全策略,实现多租户数据隔离 |
| LiteLLM | 统一 100+ LLM 供应商的开源网关,OpenAI 兼容格式 |
| L1/L2/L3 | 本文件定义的三级集成深度(浅/中/深) |
文档版本:v1.0.0
生成日期:2026-07-27
下一步行动:
- 将此文件喂给 WorkBuddy,按 §8 路线图推进阶段一(W1 平台侧改造)
- 将本文档作为《AI_PaaS_Platform_Analysis_and_Execution_Plan.md》的新章节合并
- 对每个首批应用(MuMuAINovel/next-ai-draw-io/OpenCut)单独生成改造代码骨架
反馈渠道:平台内部 Issue Tracker / 架构组邮件