AIOA/AI原生OA技术架构方案.md

# 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 扩展能力、私有化部署和长期维护成本，可作为项目立项、原型开发和架构评审的统一依据。