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. 总体架构

              Flutter iOS / Android
                       │
                    HTTPS
                       │
                 Apache APISIX
                       │
              Keycloak 身份认证
                       │
        ┌──────────────┴──────────────┐
        │                             │
 Kotlin + Spring Boot            Python AI 服务
  核心业务与权限                   检索、规划、生成
        │                             │
     Flowable                      模型网关
        │                             │
        ├──────────────┬──────────────┤
        │              │              │
   PostgreSQL        Kafka          Redis
        │              │              │
     pgvector       异步事件       缓存与锁
        │
  ┌─────┴──────────┐
  │                │
MinIO          OpenSearch
文件存储         全文检索

主要调用路径：

用户操作
  → Flutter 客户端
  → APISIX 网关
  → Kotlin 核心后端
  → 身份、权限和数据范围校验
  → 业务服务或 Flowable
  → PostgreSQL 事务提交
  → Kafka 发布领域事件
  → 通知、索引、AI 或外部集成异步处理

AI 操作路径：

用户自然语言请求
  → 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：

mobile/
├── app/                 # 初始化、环境、主题、路由
├── core/                # 网络、安全、存储、错误模型
├── design_system/       # 颜色、字号、间距和通用组件
└── features/
    ├── auth/            # 登录、设备和身份
    ├── workspace/       # 工作台
    ├── assistant/       # AI 助手
    ├── approval/        # 待办与审批
    ├── form/            # 动态表单
    ├── workflow/        # 流程详情
    ├── knowledge/       # 企业知识
    ├── notification/    # 消息中心
    ├── contact/         # 组织与通讯录
    └── profile/         # 用户设置

每个业务功能内部保持以下结构：

feature/
├── data/                # API、DTO、本地数据
├── domain/              # 实体、仓库接口、用例
└── presentation/        # 页面、组件、状态控制器

5.3 一级导航

移动端固定设置四个一级入口：

工作台 | AI 助手 | 待办 | 我的

• 工作台：常用服务、日程、公告、数据卡片和快捷操作。
• AI 助手：对话、任务发起、知识查询和执行确认。
• 待办：审批、抄送、任务、提醒及状态跟踪。
• 我的：个人信息、权限、设备、安全和偏好设置。

5.4 离线与弱网

Drift + SQLite 保存：

• 未提交表单草稿
• 最近访问的非敏感数据
• 待上传附件状态
• 客户端操作队列
• 消息与页面缓存

所有写操作必须携带幂等键。客户端断网恢复后可以安全重试，但不能因此重复发起流程或重复审批。

高敏感数据不进入普通缓存；必要的本地数据采用操作系统安全能力保护。

5.5 推送与安全存储

• iOS 使用 APNs。
• Android 使用 FCM；如需适配特殊终端，可在通知服务中增加厂商通道。
• 服务端维护统一通知抽象，不让业务模块直接调用具体推送平台。
• Access Token、Refresh Token 和设备密钥存入 iOS Keychain 或 Android Keystore。
• 高风险操作支持系统生物识别二次确认。

6. Kotlin 核心后端

6.1 架构形式

核心后端采用：

模块化单体
+ 领域驱动的模块划分
+ 六边形架构
+ 领域事件
+ 异步任务

初始模块：

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 只保存流程运行所需的少量变量，例如：

businessId
applicantId
departmentId
amount
riskLevel
formVersion

不得将完整表单 JSON、附件内容或大量业务字段长期放入流程变量，以免造成运行时表膨胀、查询困难和升级风险。

7.3 流程发布

流程生命周期固定为：

草稿
  → BPMN/DMN 静态校验
  → 测试环境运行
  → 业务负责人审核
  → 正式发布
  → 版本冻结

运行中的流程固定引用已发布版本。新版本不能直接改变正在执行的旧流程实例。

AI 可以根据自然语言生成 BPMN 或决策表草案，但不能自动发布生产流程。

8. PostgreSQL 数据方案

8.1 扩展组件

扩展	用途
pgvector	文档和知识向量检索
pg_trgm	模糊查询和相似文本搜索
unaccent	搜索文本规范化
uuid-ossp	UUID 支持
pg_stat_statements	SQL 性能分析

8.2 Schema 划分

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：

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 服务：混合召回、重排序、引用组织和答案生成。

每个文档分片至少携带：

tenant_id
document_id
document_version
department_id
security_level
permission_tags
effective_time

知识查询必须先按照用户身份和数据范围生成过滤条件，再执行全文或向量召回。禁止先检索企业全部文档，再依赖大模型隐藏无权查看的内容。

AI 回答必须提供来源文档和版本引用。无法找到可靠依据时，应明确说明，而不是生成看似确定的企业制度答案。

11. 身份与权限

11.1 认证

Keycloak 负责身份协议、登录会话和统一认证，采用：

OAuth 2.1
+ OpenID Connect
+ Authorization Code
+ PKCE

Keycloak 可以对接企业 LDAP、Active Directory、企业微信、钉钉或其他身份提供方。

11.2 授权

业务后端采用：

RBAC + 数据范围 + ABAC

• RBAC：角色可以使用哪些功能和工具。
• 数据范围：本人、本部门、本部门及下级、项目或全公司。
• ABAC：根据金额、密级、时间、岗位、设备和业务属性判断。

必须支持：

• 多岗位和多角色
• 临时授权
• 代理审批
• 权限生效与失效时间
• 项目成员权限
• 组织调整后的权限重算
• AI 工具级权限
• 敏感字段级权限

Keycloak 不负责所有业务授权。具体业务资源和数据范围仍由 Kotlin 后端判断。

12. 消息与实时能力

12.1 Kafka

Kafka 承担：

• 流程状态事件
• 审批结果事件
• 通知事件
• 文档解析和向量化任务
• AI 长任务
• 搜索索引更新
• 外部系统同步
• 审计事件投递

事件采用明确的版本号和 Schema。消费者必须实现幂等处理和死信机制。

12.2 Redis

Redis 用于：

• 短期缓存
• API 限流
• 幂等令牌
• 分布式锁
• 在线状态
• 短期会话状态
• 短生命周期任务进度

Redis 不作为权威业务数据源。重要状态必须持久化到 PostgreSQL。

12.3 通知

业务事件
  → Kafka
  → 通知中心
  → 站内消息
  → APNs / FCM
  → Flutter 客户端

推送只用于提醒。完整通知内容及已读状态保存在通知中心，确保推送丢失后仍可查询。

13. 文件与对象存储

文件内容统一存储到 MinIO，PostgreSQL 只保存元数据、业务关系、哈希、状态和审计信息。

上传过程：

Flutter 请求上传任务
  → Kotlin 鉴权并生成临时凭证
  → Flutter 直接分片上传 MinIO
  → Flutter 通知上传完成
  → Kotlin 校验并创建文件记录
  → Kafka 启动扫描、解析和预览任务

文件服务负责：

• 文件类型和大小校验
• 哈希校验和去重
• 分片上传与断点续传
• 病毒扫描
• 敏感内容检测
• 图片压缩和缩略图
• PDF 预览
• Office 文档转换
• 水印
• 下载权限审计
• 生命周期和归档策略

下载使用短期签名 URL。敏感文件每次生成下载地址前必须重新鉴权。

14. 多租户

即使首期只服务一个组织，核心业务表也保留 tenant_id。

初期采用：

共享 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 环境

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. 最终技术基线

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