# AI 原生 OA 技术架构方案 > 文档状态：技术栈定稿 > 系统形态：完全移动端 > 目标平台：iOS、Android > 核心后端：Kotlin + Spring Boot + Flowable > 主数据库：PostgreSQL ## 1. 项目目标 本项目建设一套全新的 AI 原生移动办公系统，不复制传统 OA 的“菜单—表单—审批”使用方式，而是以移动工作台、AI 助手和任务中心为主要入口。 系统需要同时满足以下目标： - 完全移动端运行，统一支持 iOS 和 Android。 - 覆盖组织、人员、权限、动态表单、审批、知识、通知和文件等 OA 基础能力。 - 支持员工通过自然语言查询信息、生成材料、填写表单和发起业务流程。 - 支持 AI 在明确授权范围内调用业务能力，但不得绕过权限、审批和审计。 - 支持企业私有化部署，并保留接入不同大模型的能力。 - 支持从数百用户扩展至数万用户。 - 业务数据、流程数据和 AI 操作全过程可追溯、可审计、可恢复。 ## 2. 总体设计原则 ### 2.1 确定性业务与 AI 分离 权限判断、审批结果、金额计算、状态变更和事务一致性由 Kotlin 核心后端负责。AI 负责意图理解、知识检索、任务规划、信息提取和内容生成。 大模型不得直接访问生产数据库，不得直接修改审批状态，也不得自行获得高于当前用户的权限。 ### 2.2 模块化单体优先 第一阶段采用模块化单体，而不是全面微服务。核心业务部署为一个应用，但在代码、数据库访问和领域接口层面保持清晰的模块边界。 以下服务可以独立部署： - AI 服务 - 文档处理服务 - 消息通知服务 - 搜索与索引任务 - 外部系统集成任务 只有当某个模块确实需要独立扩容、独立发布、故障隔离或由不同团队负责时，才将其拆为微服务。 ### 2.3 移动优先 所有功能首先按照手机操作场景设计： - 减少复杂菜单和多层导航。 - 表单适合单手操作和分步填写。 - 支持拍照、扫码、语音、定位、文件上传和生物识别。 - 弱网状态下提供本地草稿、失败重试和状态恢复。 - 重要写操作提供明确的确认界面。 ### 2.4 默认安全 权限、数据范围、日志、审计、加密和敏感操作确认必须从第一版进入系统设计，不能作为后期补充功能。 ### 2.5 技术可替换 大模型、向量模型、对象存储、搜索引擎和消息基础设施通过内部接口隔离，避免核心业务绑定某个云厂商或模型供应商。 ## 3. 确定技术栈 | 层级 | 确定选型 | |---|---| | 移动端框架 | Flutter + Dart | | 状态管理 | Riverpod | | 路由 | GoRouter | | HTTP 客户端 | Dio | | 数据模型 | Freezed + json_serializable | | 本地数据库 | Drift + SQLite | | 安全存储 | flutter_secure_storage | | 移动端监控 | Sentry | | 核心后端 | Kotlin + Spring Boot | | Java 运行时 | JDK 21 LTS | | 构建系统 | Gradle Kotlin DSL | | 工作流 | Flowable BPMN + DMN | | 数据访问 | jOOQ + HikariCP | | 数据库迁移 | Flyway | | 主数据库 | PostgreSQL | | 向量检索 | pgvector | | 数据库连接代理 | PgBouncer | | 缓存和分布式锁 | Redis | | 消息队列 | Kafka | | 企业全文搜索 | OpenSearch | | 文件与对象存储 | MinIO（S3 兼容） | | AI 服务 | Python + FastAPI + LangGraph | | 身份认证 | Keycloak + OAuth 2.1/OIDC | | API 网关 | Apache APISIX | | 实时业务消息 | WebSocket | | AI 流式响应 | SSE | | 接口规范 | REST + OpenAPI 3 | | 可观测性 | OpenTelemetry + Prometheus + Grafana + Loki + Tempo | | 密钥管理 | HashiCorp Vault | | 容器与编排 | Docker + Kubernetes | | 发布管理 | Helm | | CI/CD | GitLab CI | | 后端测试 | Kotest + MockK + Testcontainers | | 代码质量 | Detekt + ktlint | | 移动端测试 | flutter_test + integration_test | | 性能测试 | k6 | 项目创建时选择各组件的稳定版本，并使用依赖锁文件、容器镜像版本及镜像摘要固定版本。生产环境禁止使用浮动的 `latest` 标签。 ## 4. 总体架构 ```text Flutter iOS / Android │ HTTPS │ Apache APISIX │ Keycloak 身份认证 │ ┌──────────────┴──────────────┐ │ │ Kotlin + Spring Boot Python AI 服务 核心业务与权限 检索、规划、生成 │ │ Flowable 模型网关 │ │ ├──────────────┬──────────────┤ │ │ │ PostgreSQL Kafka Redis │ │ │ pgvector 异步事件 缓存与锁 │ ┌─────┴──────────┐ │ │ MinIO OpenSearch 文件存储 全文检索 ``` 主要调用路径： ```text 用户操作 → Flutter 客户端 → APISIX 网关 → Kotlin 核心后端 → 身份、权限和数据范围校验 → 业务服务或 Flowable → PostgreSQL 事务提交 → Kafka 发布领域事件 → 通知、索引、AI 或外部集成异步处理 ``` AI 操作路径： ```text 用户自然语言请求 → Kotlin 后端验证身份并整理上下文 → AI 服务理解意图并生成执行计划 → Kotlin 后端验证工具和参数权限 → Flutter 展示确认卡片 → 用户确认 → Kotlin 后端执行实际业务操作 → 写入业务数据和完整审计记录 ``` ## 5. 移动端技术方案 ### 5.1 选择 Flutter 移动端确定使用 Flutter，不采用 React Native，也不分别开发 Kotlin Android 和 Swift iOS 客户端。 选择 Flutter 的主要理由： - 一套代码同时覆盖 iOS 和 Android。 - 复杂表单、审批时间线、流程图和工作台在双端保持一致。 - 渲染行为可控，便于形成统一企业设计系统。 - 具备拍照、扫码、定位、推送、生物识别和安全存储等成熟能力。 - 相比维护两套原生客户端，可降低长期研发和测试成本。 - Dart 强类型体系适合大型、长期维护的企业应用。 ### 5.2 客户端架构 采用 Feature-first + Clean Architecture： ```text mobile/ ├── app/ # 初始化、环境、主题、路由 ├── core/ # 网络、安全、存储、错误模型 ├── design_system/ # 颜色、字号、间距和通用组件 └── features/ ├── auth/ # 登录、设备和身份 ├── workspace/ # 工作台 ├── assistant/ # AI 助手 ├── approval/ # 待办与审批 ├── form/ # 动态表单 ├── workflow/ # 流程详情 ├── knowledge/ # 企业知识 ├── notification/ # 消息中心 ├── contact/ # 组织与通讯录 └── profile/ # 用户设置 ``` 每个业务功能内部保持以下结构： ```text feature/ ├── data/ # API、DTO、本地数据 ├── domain/ # 实体、仓库接口、用例 └── presentation/ # 页面、组件、状态控制器 ``` ### 5.3 一级导航 移动端固定设置四个一级入口： ```text 工作台 | AI 助手 | 待办 | 我的 ``` - 工作台：常用服务、日程、公告、数据卡片和快捷操作。 - AI 助手：对话、任务发起、知识查询和执行确认。 - 待办：审批、抄送、任务、提醒及状态跟踪。 - 我的：个人信息、权限、设备、安全和偏好设置。 ### 5.4 离线与弱网 Drift + SQLite 保存： - 未提交表单草稿 - 最近访问的非敏感数据 - 待上传附件状态 - 客户端操作队列 - 消息与页面缓存 所有写操作必须携带幂等键。客户端断网恢复后可以安全重试，但不能因此重复发起流程或重复审批。 高敏感数据不进入普通缓存；必要的本地数据采用操作系统安全能力保护。 ### 5.5 推送与安全存储 - iOS 使用 APNs。 - Android 使用 FCM；如需适配特殊终端，可在通知服务中增加厂商通道。 - 服务端维护统一通知抽象，不让业务模块直接调用具体推送平台。 - Access Token、Refresh Token 和设备密钥存入 iOS Keychain 或 Android Keystore。 - 高风险操作支持系统生物识别二次确认。 ## 6. Kotlin 核心后端 ### 6.1 架构形式 核心后端采用： ```text 模块化单体 + 领域驱动的模块划分 + 六边形架构 + 领域事件 + 异步任务 ``` 初始模块： ```text backend/ ├── boot # 应用启动与配置 ├── identity # 用户身份和账号 ├── organization # 组织、岗位和人员关系 ├── authorization # 角色、权限和数据范围 ├── workflow # Flowable 适配和流程管理 ├── form # 表单模型和版本 ├── approval # 审批业务 ├── document # 文件元数据与文档业务 ├── knowledge # 知识库和权限 ├── notification # 站内消息和通知 ├── integration # 外部系统适配 ├── ai-orchestration # AI 上下文和工具执行 └── audit # 审计事件和查询 ``` 模块之间通过应用服务接口和领域事件协作。一个模块不得直接读取或修改另一个模块拥有的数据库表。 ### 6.2 Spring 编程模型 业务接口采用 Spring MVC，不以 WebFlux 作为核心编程模型。Flowable、jOOQ 和企业集成大量使用阻塞式接口，采用 MVC 能降低事务、调试和维护复杂度。 AI 流式输出使用 SSE；实时消息和状态更新使用 WebSocket，不需要为此将整个系统改为响应式架构。 ### 6.3 数据访问 确定使用 jOOQ，不采用 JPA/Hibernate。 原因包括： - 与 Kotlin 的空安全和不可变数据模型配合更自然。 - 支持类型安全 SQL。 - 复杂筛选、统计、报表和关联查询更透明。 - 能充分利用 PostgreSQL 的 JSONB、数组、CTE 和窗口函数。 - SQL 性能更容易分析和优化。 数据库连接由 HikariCP 管理，数据库外部增加 PgBouncer 控制连接总量。 ## 7. Flowable 工作流方案 ### 7.1 Flowable 职责 Flowable 负责： - BPMN 流程执行 - 用户任务 - 会签和或签 - 条件分支 - 子流程 - 定时任务 - 超时提醒与升级 - 流程撤回和终止控制 - 流程版本管理 - DMN 决策表 ### 7.2 业务数据边界 完整表单和业务数据存放在自有业务表中。Flowable 只保存流程运行所需的少量变量，例如： ```text businessId applicantId departmentId amount riskLevel formVersion ``` 不得将完整表单 JSON、附件内容或大量业务字段长期放入流程变量，以免造成运行时表膨胀、查询困难和升级风险。 ### 7.3 流程发布 流程生命周期固定为： ```text 草稿 → BPMN/DMN 静态校验 → 测试环境运行 → 业务负责人审核 → 正式发布 → 版本冻结 ``` 运行中的流程固定引用已发布版本。新版本不能直接改变正在执行的旧流程实例。 AI 可以根据自然语言生成 BPMN 或决策表草案，但不能自动发布生产流程。 ## 8. PostgreSQL 数据方案 ### 8.1 扩展组件 | 扩展 | 用途 | |---|---| | pgvector | 文档和知识向量检索 | | pg_trgm | 模糊查询和相似文本搜索 | | unaccent | 搜索文本规范化 | | uuid-ossp | UUID 支持 | | pg_stat_statements | SQL 性能分析 | ### 8.2 Schema 划分 ```text identity organization authz workflow form business knowledge integration audit flowable ``` Flowable 使用独立的 `flowable` Schema。业务模块根据归属访问对应 Schema，但仍由同一个 PostgreSQL 集群统一管理事务和备份。 ### 8.3 数据建模规范 - 主键统一采用 UUIDv7。 - 所有业务表包含 `tenant_id`。 - 所有可修改实体包含创建时间、更新时间和乐观锁版本号。 - 所有写请求包含业务幂等键。 - 使用 `timestamptz` 保存时间，并统一以 UTC 入库。 - 金额采用 `numeric`，禁止使用浮点类型。 - 高频查询字段采用结构化列。 - 低频扩展字段可以存入 JSONB。 - 不采用“所有动态表单数据都存 JSONB”的设计。 - 审计数据与普通业务日志分离。 - 禁止在生产环境使用 ORM 或 Flowable 自动建表。 ### 8.4 动态表单 动态表单采用： - JSON Schema：字段、类型和数据约束。 - UI Schema：布局、控件和移动端展示规则。 - 受限规则表达式：显隐、只读、校验和字段联动。 - BPMN：表单提交后的业务流转。 规则表达式采用 CEL 或 FEEL 等受限语言，不允许直接执行用户提供的 JavaScript。 表单定义必须版本化。已提交记录必须保留提交时的表单版本和数据快照。 ### 8.5 高可用与备份 - PostgreSQL 采用主从或托管高可用部署。 - 配置持续归档和时间点恢复能力。 - 定期进行全量备份和恢复演练。 - 备份文件加密并与生产集群隔离。 - 使用 PgBouncer 控制连接规模。 - 使用 `pg_stat_statements` 和慢查询监控持续优化 SQL。 ## 9. AI 服务 ### 9.1 服务边界 AI 服务独立使用 Python + FastAPI + LangGraph： ```text ai-service/ ├── model_gateway/ # 模型统一接口、路由和故障切换 ├── retrieval/ # 检索、重排序和引用 ├── agents/ # 有状态任务编排 ├── tools/ # 工具定义，不直接实现核心业务 ├── guardrails/ # 输入输出和安全规则 ├── prompts/ # 提示词及版本 ├── evaluation/ # 离线评测和回归测试 └── telemetry/ # 调用、成本、延迟和质量监控 ``` 职责划分： - Kotlin：身份、权限、业务规则、事务和实际工具执行。 - Flowable：确定性流程执行和状态推进。 - Python：意图识别、任务规划、知识检索和内容生成。 - 大模型：生成建议和结构化调用请求，不直接拥有业务权限。 ### 9.2 模型网关 模型网关提供统一内部协议，并兼容主流 OpenAI API 风格接口。网关负责： - 云端模型和私有模型切换 - 按任务选择模型 - 超时、重试和熔断 - 速率和成本控制 - 敏感信息处理 - 提示词版本记录 - 模型调用审计 - 输出结构校验 核心业务代码不得直接调用具体模型供应商 SDK。 ### 9.3 Agent 运行规则 - Agent 任务状态持久化，不能仅存在内存。 - 每个工具都有确定的输入 Schema、权限要求和风险等级。 - 工具调用由 Kotlin 后端重新鉴权。 - 任何写操作都必须具备幂等机制。 - 中高风险操作必须人工确认。 - 长任务支持超时、取消、重试和人工接管。 - 工具执行失败后不能由模型无限重试。 - 所有关键步骤保存模型、提示词、参数、结果和确认记录。 ## 10. 企业知识与搜索 采用 PostgreSQL + pgvector + OpenSearch 的混合检索架构： - PostgreSQL：文档元数据、权限、版本、分片和向量。 - MinIO：原始文件、附件和预览文件。 - OpenSearch：全文检索、关键词匹配、过滤和聚合。 - pgvector：语义召回。 - AI 服务：混合召回、重排序、引用组织和答案生成。 每个文档分片至少携带： ```text tenant_id document_id document_version department_id security_level permission_tags effective_time ``` 知识查询必须先按照用户身份和数据范围生成过滤条件，再执行全文或向量召回。禁止先检索企业全部文档，再依赖大模型隐藏无权查看的内容。 AI 回答必须提供来源文档和版本引用。无法找到可靠依据时，应明确说明，而不是生成看似确定的企业制度答案。 ## 11. 身份与权限 ### 11.1 认证 Keycloak 负责身份协议、登录会话和统一认证，采用： ```text OAuth 2.1 + OpenID Connect + Authorization Code + PKCE ``` Keycloak 可以对接企业 LDAP、Active Directory、企业微信、钉钉或其他身份提供方。 ### 11.2 授权 业务后端采用： ```text RBAC + 数据范围 + ABAC ``` - RBAC：角色可以使用哪些功能和工具。 - 数据范围：本人、本部门、本部门及下级、项目或全公司。 - ABAC：根据金额、密级、时间、岗位、设备和业务属性判断。 必须支持： - 多岗位和多角色 - 临时授权 - 代理审批 - 权限生效与失效时间 - 项目成员权限 - 组织调整后的权限重算 - AI 工具级权限 - 敏感字段级权限 Keycloak 不负责所有业务授权。具体业务资源和数据范围仍由 Kotlin 后端判断。 ## 12. 消息与实时能力 ### 12.1 Kafka Kafka 承担： - 流程状态事件 - 审批结果事件 - 通知事件 - 文档解析和向量化任务 - AI 长任务 - 搜索索引更新 - 外部系统同步 - 审计事件投递 事件采用明确的版本号和 Schema。消费者必须实现幂等处理和死信机制。 ### 12.2 Redis Redis 用于： - 短期缓存 - API 限流 - 幂等令牌 - 分布式锁 - 在线状态 - 短期会话状态 - 短生命周期任务进度 Redis 不作为权威业务数据源。重要状态必须持久化到 PostgreSQL。 ### 12.3 通知 ```text 业务事件 → Kafka → 通知中心 → 站内消息 → APNs / FCM → Flutter 客户端 ``` 推送只用于提醒。完整通知内容及已读状态保存在通知中心，确保推送丢失后仍可查询。 ## 13. 文件与对象存储 文件内容统一存储到 MinIO，PostgreSQL 只保存元数据、业务关系、哈希、状态和审计信息。 上传过程： ```text Flutter 请求上传任务 → Kotlin 鉴权并生成临时凭证 → Flutter 直接分片上传 MinIO → Flutter 通知上传完成 → Kotlin 校验并创建文件记录 → Kafka 启动扫描、解析和预览任务 ``` 文件服务负责： - 文件类型和大小校验 - 哈希校验和去重 - 分片上传与断点续传 - 病毒扫描 - 敏感内容检测 - 图片压缩和缩略图 - PDF 预览 - Office 文档转换 - 水印 - 下载权限审计 - 生命周期和归档策略 下载使用短期签名 URL。敏感文件每次生成下载地址前必须重新鉴权。 ## 14. 多租户 即使首期只服务一个组织，核心业务表也保留 `tenant_id`。 初期采用： ```text 共享 PostgreSQL 集群 + 共享 Schema + tenant_id 行级隔离 ``` 高敏感表可额外启用 PostgreSQL Row-Level Security，但数据库策略不能替代应用层鉴权。 初期不采用每租户独立数据库。未来对隔离要求极高的客户，可以通过租户路由扩展至独立数据库或独立集群。 ## 15. API 设计 - 面向客户端采用 REST API。 - 接口使用 OpenAPI 3 描述并生成客户端类型。 - URL 包含显式 API 大版本，如 `/api/v1`。 - 使用统一错误结构和业务错误码。 - 分页统一采用游标或明确的分页对象。 - 写操作支持 `Idempotency-Key`。 - 资源更新采用版本号或 ETag 防止覆盖。 - 批量接口设置最大数量和速率限制。 - AI 流式回答使用 SSE。 - 实时待办和消息更新使用 WebSocket。 客户端不得直接调用 Flowable、Keycloak 管理端、MinIO 管理端或 AI 模型供应商接口。 ## 16. 安全基线 系统第一版必须包含： - 全链路 TLS。 - Access Token 短有效期。 - Refresh Token 轮换和复用检测。 - 设备注册、设备撤销和远程注销。 - API 限流和异常行为监控。 - 写接口防重放和幂等控制。 - 数据传输加密与静态加密。 - 高敏感字段应用层加密。 - 日志敏感字段脱敏。 - 完整审批和工具调用审计。 - 高风险操作二次确认或生物识别。 - 外部文档不可信标记。 - 提示词注入检测和工具参数约束。 - AI 输出结构验证。 - AI 不能直接将自然语言输出作为数据库语句或业务指令执行。 - Secret 统一保存在 Vault，不写入代码仓库或容器镜像。 ## 17. 审计体系 每个关键操作至少记录： - 租户和用户 - 登录身份与代理身份 - 设备和会话 - 操作时间和来源 IP - 业务对象与操作类型 - 操作前后关键状态 - 权限判断结果 - 幂等键和关联追踪 ID - Flowable 流程实例和任务 ID - AI 模型、提示词版本和工具调用 - 人工确认记录 - 执行结果和失败原因 审计事件写入独立审计表，并通过 Kafka 异步归档。普通管理员不得修改或删除审计记录。 ## 18. 可观测性 OpenTelemetry 统一采集 Trace、Metric 和 Log 关联信息： - Prometheus：指标存储。 - Grafana：仪表盘和告警。 - Loki：日志聚合。 - Tempo：分布式追踪。 - Sentry：Flutter 崩溃和前端异常。 重点监控： - API 延迟、错误率和吞吐量 - PostgreSQL 连接、锁和慢查询 - Flowable 待执行任务、失败任务和定时任务积压 - Kafka 消费延迟和死信数量 - Redis 命中率和内存 - 文档解析及索引积压 - AI 请求延迟、Token 消耗、成本、失败率和人工拒绝率 - 移动端启动速度、崩溃率和网络失败率 所有请求使用统一 Trace ID，贯穿 Flutter、APISIX、Kotlin、AI 服务、Kafka 消费者和外部系统调用。 ## 19. 部署方案 ### 19.1 环境 ```text development testing staging production ``` 生产数据库、Kafka、对象存储、搜索引擎和密钥系统不得与非生产环境共享。 ### 19.2 Kubernetes 部署单元 - APISIX 网关 - Kotlin OA Backend - AI Service - Document Worker - Notification Worker - Integration Worker - Keycloak - PostgreSQL 或外部高可用数据库 - PgBouncer - Redis - Kafka - MinIO - OpenSearch - 可观测性组件 核心后端初期作为一个部署单元运行多个副本。AI、文档、通知和集成任务根据实际负载独立扩容。 ### 19.3 发布 - GitLab CI 执行代码检查、测试、构建和镜像扫描。 - Helm 管理 Kubernetes 发布配置。 - 数据库变更使用 Flyway，并在应用发布前单独执行。 - 生产发布采用滚动或金丝雀策略。 - 高风险变更必须提供回滚方案。 - 数据库迁移遵循向前兼容，避免新版本发布期间旧实例无法运行。 ## 20. 测试策略 ### 20.1 后端 - Kotest：单元测试和业务规则测试。 - MockK：外部依赖模拟。 - Testcontainers：PostgreSQL、Kafka、Redis 和其他集成测试。 - Flowable 测试：流程路径、条件分支、会签、超时和撤回。 - 契约测试：移动端、AI 服务和外部系统接口。 - k6：API 和关键流程压力测试。 权限和流程规则优先使用真实数据库和真实 Flowable 引擎做集成测试，避免仅依赖 Mock 得到错误信心。 ### 20.2 Flutter - 领域和状态管理单元测试。 - Widget 组件测试。 - Golden UI 回归测试。 - iOS 和 Android 集成测试。 - 弱网、断网、后台恢复和 Token 过期测试。 - 上传中断和幂等重试测试。 ### 20.3 AI - 固定评测集。 - 意图识别准确率。 - 知识引用正确率。 - 无权限信息泄漏测试。 - 工具选择与参数正确率。 - 提示词注入测试。 - 不同模型版本回归测试。 - 高风险操作人工确认覆盖率。 ## 21. 第一阶段不引入的技术 为保证可交付性，第一阶段明确不引入： - 全面微服务 - 服务网格 - GraphQL - 自研 Kubernetes Operator - 独立向量数据库 - 多 Agent 自主协作网络 - Event Sourcing - 自研工作流引擎 - 自研身份认证系统 - 用户脚本或动态 JavaScript 表单规则 - 大模型直接访问业务数据库 - 大模型自主发布流程 ## 22. 建议实施阶段 ### 阶段一：基础平台 - Flutter 应用骨架和设计系统 - Keycloak 登录、设备注册和组织同步 - 组织、人员、岗位、角色和数据权限 - PostgreSQL、Flyway、jOOQ 和审计基础设施 - APISIX、Kubernetes、监控和日志 ### 阶段二：OA 核心 - 动态表单 - Flowable 流程设计、发布和执行 - 待办、已办、抄送和流程详情 - 文件上传、预览和通知中心 - 移动端离线草稿和弱网恢复 ### 阶段三：AI 助手 - 模型网关 - 企业知识库和混合检索 - 带引用的制度问答 - 表单自动填写和材料检查 - AI 操作确认卡片 - 工具权限和 AI 审计 ### 阶段四：自动化与集成 - ERP、CRM、财务、人力和邮件集成 - 跨系统任务编排 - 低风险任务自动执行 - 异常监控、任务补偿和人工接管 - AI 质量、成本和业务收益评估 ## 23. 最终技术基线 ```text 客户端： Flutter + Riverpod + GoRouter + Dio + Drift 核心业务： Kotlin + Spring Boot + Flowable + jOOQ AI： Python + FastAPI + LangGraph 数据： PostgreSQL + pgvector + PgBouncer + Flyway Redis + OpenSearch 基础设施： Kafka + MinIO + Keycloak + APISIX + Vault 部署： Docker + Kubernetes + Helm + GitLab CI 运维： OpenTelemetry + Prometheus + Grafana + Loki + Tempo + Sentry ``` 技术架构的核心边界如下： - Flutter 负责统一移动体验。 - Kotlin 负责确定性业务、权限和事务。 - Flowable 负责可审计的流程执行。 - Python AI 服务负责理解、检索、规划和生成。 - PostgreSQL 保存权威业务数据。 - Kafka 承担异步事件和系统解耦。 - MinIO 保存文件，OpenSearch 与 pgvector 提供混合检索。 - Keycloak 负责身份协议，Kotlin 后端负责业务授权。 - AI 永远不能绕过权限、确认和审计直接执行高风险操作。 该技术基线兼顾移动体验、企业级可靠性、AI 扩展能力、私有化部署和长期维护成本，可作为项目立项、原型开发和架构评审的统一依据。