博客基于优码云团队交付的企业级 AI 工作流平台真实经验，拆解多模型编排、RAG 检索增强、工具调用、积分计费与多租户权限的工程落地细节。
2025 年到 2026 年，我们观察到同一个模式反复出现：企业试用 ChatGPT / Claude / 豆包之后，很快发现通用对话助手解决不了业务问题。客服工单需要查内部知识库、风控决策需要调多个 API、内容生产需要走审批流——这些场景需要的不是"一个聊天框"，而是一个能编排模型、调用工具、对接现有系统的 AI 工作流平台。
2025 年初，我们开始为一家企业级客户搭建这样的平台。项目从 PoC 起步，到 2026 年已经迭代了多个版本，支撑客服、风控、内容生产三条业务线。这篇文章把架构选型、踩坑和工程取舍写出来。
技术选型上我们选了 FastAPI 做后端、Next.js 14 做前端，PostgreSQL + Redis 做数据层。不是最"潮"的组合，但经过验证：FastAPI 的 async 原生支持对 LLM 流式输出友好，Next.js 的 App Router 在 SSR 和客户端状态之间平衡得不错。
核心模块分四层：
我们一开始的想法很直接：每个模型封装一个 adapter，上层统一调用。跑了两周发现三个问题：
最终方案是每个模型保留独立的 prompt 模板和 tool 定义，上层用统一的 Task 抽象层做编排，不做"一刀切"的 adapter。
平台内置了 RAG 知识库功能，让 AI 工作流能检索企业文档。初期用 bge-m3 做 embedding，1024 维向量存 PostgreSQL pgvector。上线后发现：
我们做了两轮优化：第一轮加 query 重写（把口语化问题转成关键词组合），第二轮加 reranker 对 top-20 结果重排。检索准确率从 47% 提到 89%。这个数字我们在官网公告里也提过——不是编的，是真实 A/B 测试结果。
AI 工作流执行一个复杂任务（比如"分析本月销售数据并生成报告"）可能需要 5-10 步工具调用。初期我们让模型一次性规划完所有步骤，结果：
改成"规划一步、执行一步、反思一步"的循环模式后，任务完成率从 62% 提升到 91%。代价是执行时间延长了 30%，但对企业场景来说可靠性比速度重要。
平台需要支持多企业使用，每个企业下多个用户。计费按 token 消耗折算成积分。设计上几个关键决策：
不是所有场景都适合上 AI 工作流平台。我们遇到过两个反例：
企业级 AI 工作流平台的核心不是模型能力——模型能力是底座，真正决定项目成败的是工程细节：多模型编排的兼容性、RAG 检索的精度、长程任务的可靠性、多租户的隔离与计费。这些没有银弹，只能一个一个坑踩过去。
我们把这个平台的经验沉淀成了可复用的工程框架。如果你正在评估是否要自建，或者已经在踩类似的坑，欢迎来聊。