12 KiB
七虎AI PaaS 平台 — 迭代优化可执行方案 v1.0
来源: 基于
AI_PaaS_Platform_Analysis_and_Execution_Plan v2.md(元宝深度分析文档) 日期: 2026-07-27 原则: P0 先做、P1 跟进、P2 规划评估;每 Phase 一个交付周期
总览:20 项行动按 4 个 Phase 分组
Phase 0 (本周): 4 P0 项 — 基础设施补全,投入产出比最高
Phase 1 (2周内): 6 P0+P1 项 — 核心竞争力构建
Phase 2 (1月内): 5 P1 项 — 体验与护城河加固
Phase 3 (评估): 5 P2 项 — 按需投入
Phase 0:基础设施补全(本周,4 项 P0)
这些是文档反复强调的"先决条件"——不做,后面的都没法高效开展。
#0A. 多租户隔离(PG RLS + tenant_id)
现状: 平台无真正的多租户隔离。所有用户共享同一套数据,仅靠 JWT 区分身份。
目标: 启用 PostgreSQL Row Level Security,所有业务表加 tenant_id。
工作量: 3 天
实施:
- 核心表(conversations/messages/market_apps/skill_instances)加
tenant_id UUID列 - 启用
ALTER TABLE ... ENABLE ROW LEVEL SECURITY - 创建 RLS 策略:
USING (tenant_id = current_setting('app.current_tenant')::UUID) - FastAPI middleware 注入
app.current_tenant从 JWT 提取 - 知识库/资产存储目录结构改为
/workspace/{tenant_id}/{user_id}/
#0B. LiteLLM Proxy — 统一 AI 网关
现状: 自定义 failover(_try_models 列表 + continue 切换),无成本追踪、无限流、无缓存。
目标: 引入 LiteLLM Proxy 作为网关,客户端零改动。
工作量: 3 天
实施:
- 部署
litellm容器,配置litellm_config.yaml - 映射现有 4 个 provider(SiliconFlow/MiMo/AGNES/DeepSeek)
- 启用 Virtual Keys(按用户/租户分发 API Key,追踪花费)
- 启用 RPM/TPM 限流 + 加权负载均衡(替代 try-except failover)
- 启用 Redis 语义缓存(相同 prompt 不重复计费)
- litellm 端点替换
DATABASE_URL配置中的模型 endpoint
#0C. Meilisearch — 技能市场搜索引擎
现状: 技能市场搜索依赖 PostgreSQL ILIKE 查询,无中文分词、无 BM25、无分面筛选。
目标: 部署 Meilisearch 容器,替代 PG 全文搜索。
工作量: 2 天
实施:
- 部署
meilisearch容器(含 jieba 中文分词) - 创建
market_apps索引(name/description/tags/category/capability/publisher) - 全量同步现有 115 个技能到 Meilisearch
- 前端 MarketPage 搜索框改为调用
/searchAPI(sub-50ms 响应) - 支持 facets(category/capability/tags)+ 排序(downloads/rating/date)
- 后续可用 Tenant Tokens 做多租户搜索隔离
#0D. 角色模型扩展(5 级 + 用户组)
现状: 仅 admin/user 两级,无 user groups、无模型/技能按组分配。 目标: 5 级角色 + 用户组机制。 工作量: 3 天 实施:
- 角色:super_admin / admin / developer / user / guest
- 用户组(Groups):用户可属于多个组;组级模型配额和技能可见性
- 用户组 API(CRUD + 成员管理)
- 前端 AdminLayout 角色判断(developer 可发布技能但不可管理用户)
Phase 1:核心竞争力构建(2 周内,6 项 P0+P1)
#1A. 技能真实执行器 — 3 个标杆技能 ⭐ 最重要
现状: _execute_skill_tool() 是"指令转发"——把 SKILL.md 的文字抄给 LLM,让 LLM "模拟执行"。这是平台最大短板。
目标: 落地真实执行器,3 个标杆技能跑通端到端。
工作量: 2 周
实施:
Step 1: 执行器基础架构(3 天)
SkillRuntime类:鉴权 → 创建工作区 → 调技能 API → 扣配额 → 存储产物 → 记录计量SkillInstanceDB 模型:状态机(generating/ready/failed/archived)- S3 兼容对象存储集成(MinIO 起步)
- 工作区隔离:
/workspace/{tenant_id}/{user_id}/{skill}/{instance_id}/
Step 2: 标杆技能 #1 — AI PPT 生成器(5 天)
- 基于 dashi-ppt-skill 改造
- 适配层 API:
/api/generatePOST、/api/export/pptxGET、/api/export/pdfGET - 输入:文本/文档 → LLM 生成大纲 → 渲染 HTML 幻灯片 → 导出 PPTX/PDF
- 预览图生成(headless Chrome 截图)
- 配额:Free 3次/天,Pro 50次/天
Step 3: 标杆技能 #2 — SEO 优化助手(2 天)
- 基于 marketing-skills 改造
- 输入:URL/关键词 → 分析 SERP → 输出 SEO 报告+优化建议
Step 4: 标杆技能 #3 — AI 投研报告��2 天)
- 基于 equity-research-skill 改造
- 输入:股票代码 → 财报分析 + DCF 估值 → 输出结构化投研报告
#1B. 统一 SKILL.md Schema
现状: 技能元数据散乱,无统一格式/版本/权限/定价规范。 目标: 发布平台统一 SKILL.md 规范(9 大区块)。 工作量: 3 天 实施:
- Schema:name/version/author/description/capabilities/inputs/outputs/resource/permissions/dependencies/pricing
- 与现有 market_app DB 字段映射
- 自动解析器:
_parse_skill_content()增强,从 SKILL.md 提取结构 - 前端技能详情页显示结构化信息(输入/输出/配额/定价)
#1C. 流式 Token 计费 + 实时余额
现状: 仅记录 Token 用量,无计费、无余额扣减、无配额提示。 目标: 实时 Token 计费 + 流式扣费 + 用户余额。 工作量: 5 天 实施:
- LiteLLM 集成后,每次调用自动获取
usage.prompt_tokens + completion_tokens - 流式场景:累加 chunk 计数,
done事件时写入 - 用户余额表:
token_balances - 前端:对话中实时显示剩余 Token(顶部状态栏)
- 余额不足时提前拦截(不浪费一次模型调用)
#1D. Agent 可视化编排画布 ⭐ 亮点
现状: Agent 编排靠 YAML 手写,无可视化界面。 目标: 基于 React Flow 的可拖拽编排画布。 工作量: 2 周 实施:
- 前端:React Flow 节点编辑器(节点库:LLM/Skill/MCP/External/Reduce/条件分支)
- 拖拽连线定义数据流
- 导出为 YAML → 对接现有
run_graph()引擎 - 执行监控:实时高亮当前执行节点、查看输出
#1E. 角色模型扩展(5 级 + 用户组)— 续 Phase 0D
(已在 Phase 0 中定义)
#1F. 技能市场搜索 — 续 Phase 0C
(已在 Phase 0 中定义,Meilisearch)
Phase 2:体验与护城河加固(1 月内,5 项 P1)
#2A. 工具调用四级风险审批
现状: 仅 tool_policy 沙箱(白名单+预算+每轮上限),无操作风险分级。
目标: 参考 OpenWorker 的四级风险模型。
工作量: 3 天
实施:
- 风险等级:read / write_local / exec / external
- 每级定义默认行为(read 自动许可 / write_local 确认 / exec 审批 / external 管理员审批)
- 前端:高风险操作弹窗确认 + 审批后重试
- 审批队列:pending_approvals 表 + 管理员后台
#2B. 引入 MemPalace 分层记忆
现状: 五类结构化记忆(实体/事实/偏好/决策/待办),无分层索引。 目标: Wing/Room/Drawer 分层索引(MemPalace)。 工作量: 1 周 实施:
- Wing = 用户级(跨所有对话)
- Room = 对话级(单次对话上下文)
- Drawer = 话题级(对话内特定话题)
- 跑 LongMemEval benchmark 量化召回率
#2C. Loop 原语 + Verifier
现状: Agent 编排是 DAG 拓扑排序,无循环边、无验证器。 目标: 引入 Loop 原语(循环边 + 终止条件 + Verifier)。 工作量: 1 周 实施:
orchestrator.py支持循环边:{"from": "verify", "to": "generate", "condition": "not_passed"}- Verifier 节点:判断目标是否达成的验证器
- 前端画布(#1D)支持画循环边
#2D. executor 沙箱升级
现状: executor 容器基于 Docker,无严格内核隔离。
目标: gVisor 或 Firecracker 微虚拟机隔离。
工作量: 3 天
评估: gVisor 集成最简单(Docker 的 --runtime=runsc)
#2E. 技能 SDK + 脚手架 CLI
现状: 技能开发者手动创建目录和 SKILL.md。
目标: qihu-skill CLI 脚手架。
工作量: 1 周
实施:
qihu-skill init my-skill→ 生成目录结构 + SKILL.md 模板qihu-skill validate→ 校验 SKILL.md Schemaqihu-skill publish→ 打包上传到平台技能市场qihu-skill dev→ 本地调试(Mock SkillRuntime)
Phase 3:评估后按需投入(5 项,P2)
#3A. Semantica 决策溯源
- 场景:金融/医疗/法律客户要求可解释 AI
- 工作量:评估 3 天 + 集成 1 周
- 决策标准:是否有付费企业客户明确要求
#3B. Langfuse/LangSmith Agent 轨迹
- 场景:开发者调试 Agent 执行、产品优化
- 工作量:3 天集成
- 决策标准:Agent 可视化画布上线后,按需求优先级
#3C. Agent 广播网络(EigenFlux)
- 场景:Agent 间自动发现与协作
- 工作量:评估
- 决策标准:多 Agent 协作需求明确后
#3D. 前端暗色模式
- 工作量:3 天
- 决策标准:用户体验迭代批次
#3E. 移动端适配
- 工作量:2 周
- 决策标准:移动端用户数据达标后
优先级总表(20 项排序)
| # | 行动 | 模块 | 优先级 | 工作量 | 依赖 |
|---|---|---|---|---|---|
| 1 | LiteLLM Proxy 统一 AI 网关 | 模型路由 | P0 | 3d | - |
| 2 | Meilisearch 技能市场搜索 | 搜索 | P0 | 2d | - |
| 3 | PG RLS + tenant_id 多租户隔离 | 多租户 | P0 | 3d | - |
| 4 | 角色 5 级 + 用户组 | 多租户 | P0 | 3d | #3 |
| 5 | 3 个标杆技能真实执行器 | 技能市场 | P0 | 2w | - |
| 6 | SKILL.md 统一 Schema | 技能市场 | P0 | 3d | - |
| 7 | 流式 Token 计费 + 实时余额 | 变现 | P0 | 5d | #1 |
| 8 | Agent 可视化编排画布 | Agent | P1 | 2w | - |
| 9 | Loop 原语 + Verifier | Agent | P1 | 1w | #8 |
| 10 | 工具四级风险审批 | 安全 | P1 | 3d | - |
| 11 | executor gVisor 升级 | 安全 | P1 | 3d | - |
| 12 | MemPalace 分层记忆 | RAG | P1 | 1w | - |
| 13 | 技能 SDK + 脚手架 CLI | 技能市场 | P1 | 1w | #6 |
| 14 | LongMemEval 基准测试 | RAG | P1 | 2d | - |
| 15 | 技能审核流水线 | 技能市场 | P2 | 1w | #6 |
| 16 | 分润模型 + 开发者结算 | 变现 | P2 | 1w | #7 |
| 17 | Langfuse Agent 轨迹 | 可观测 | P2 | 3d | #1 |
| 18 | Semantica 决策溯源 | 安全 | P2 | 评估 | - |
| 19 | 前端暗色模式 | UI | P2 | 3d | - |
| 20 | 移动端适配 | UI | P2 | 2w | - |
竞品对比更新(基于分析文档)
| 维度 | 七虎AI 现状 | Open WebUI | Dify | 差距/优势 |
|---|---|---|---|---|
| RBAC | admin/user 2 级 | Admin/User/Pending + Groups | 内置多租户 | 🔴 落后 |
| 向量库 | 仅 pgvector | 9 种可插拔 | 多种 | 🟡 够用 |
| RAG 管线 | 单路向量 | 3 阶段 BM25+向量+Rerank | 混合检索 | 🟡 待增强 |
| 插件体系 | Skills+MCP | 5 类插件 | 工作流节点 | 🟡 够用 |
| Token 计量 | 仅记录 | 实时+按模型+仪表盘 | 内置 | 🔴 落后 |
| 模型路由 | try-except | Pipe 路由 | 内置 failover | 🟡 待 LiteLLM |
| Agent 编排 | DAG 图引擎 | 无 | 工作流画布 | 🟢 领先 |
| 技能市场 | 上架-安装-执行 | 无 | 无 | 🟢 护城河 |
当前已完成(对标分析文档的"已修复弱点")
这些本期会话已修复,分析文档第九节引用:
| 修复 | 状态 | 对应文档章节 |
|---|---|---|
| AGENT_GUIDE 标准化 | ✅ | §九 - 固定弱点已修复 |
| MCP 官方 SDK + Schema 转换 | ✅ | §九 |
| Tool Policy 白名单+预算+每轮上限 | ✅ | §九 |
| MiMo Token Plan 适配 | ✅ | - |
overflow-x: hidden 响应式修复 |
✅ | - |
架构蓝图 ARCHITECTURE.md |
✅ | - |
执行指令: 告诉我 "执行 Phase 0" 开始落地。每完成一项在对应 checkpoint 勾掉。 上传到 Gitea: 本方案同步上传到
qihuaiflow/docs/ITERATION_PLAN.md