From c177e8be2ff0d1d2f1f8c3915d64084a6587026a Mon Sep 17 00:00:00 2001 From: Hongyu Shi Date: Sat, 11 Oct 2025 17:03:50 +0800 Subject: [PATCH] =?UTF-8?q?=E4=BF=AE=E5=A4=8D=E8=AE=BE=E8=AE=A1=E6=96=87?= =?UTF-8?q?=E6=A1=A3=E4=B8=AD=E7=9A=84=E4=B8=80=E4=BA=9B=E9=94=99=E8=AF=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Authored by GPT-5-Codex. Signed-off-by: Hongyu Shi --- design/call/api.md | 27 ++++++++++++++----- design/services/activity.md | 39 ++++++++++++++------------- design/services/flow.md | 29 ++++++++++++-------- design/services/personal_token.md | 44 +++++++++++++++++-------------- design/services/session.md | 2 +- design/services/tag.md | 32 +++++++++++----------- design/services/user.md | 10 ++++--- documents/design/appcenter.md | 4 +-- 8 files changed, 108 insertions(+), 79 deletions(-) diff --git a/design/call/api.md b/design/call/api.md index 99431a850..23afe330a 100644 --- a/design/call/api.md +++ b/design/call/api.md @@ -72,7 +72,7 @@ classDiagram class APIOutput { +http_code: int - +result: dict | str + +result: dict } CoreCall <|-- API @@ -165,9 +165,9 @@ flowchart TD CheckSession -->|不存在| Error[抛出CallError] CheckSession -->|存在| InitVars[初始化认证变量] - InitVars --> req_header[req_header = {}] - InitVars --> req_cookie[req_cookie = {}] - InitVars --> req_params[req_params = {}] + InitVars --> req_header["req_header = {}"] + InitVars --> req_cookie["req_cookie = {}"] + InitVars --> req_params["req_params = {}"] req_header --> CheckAuth{检查_auth} req_cookie --> CheckAuth @@ -311,7 +311,7 @@ sequenceDiagram alt session_id不存在 Auth->>Auth: 抛出CallError - Auth-->>-API: 错误 + Auth-->>API: 错误 else session_id存在 Auth->>Auth: 初始化req_header/cookie/params @@ -432,7 +432,7 @@ graph TB JSON --> JSONHandler[json参数] Form --> FormHandler[data参数] - Multipart --> MultipartHandler[data + files参数] + Multipart --> MultipartHandler[data参数（files参数尚未接入输入模型）] style ContentType fill:#673ab7,color:#fff style JSON fill:#9c27b0,color:#fff @@ -477,12 +477,19 @@ graph LR S2xx --> S201[201 Created] S2xx --> S202[202 Accepted] S2xx --> S204[204 No Content] + S2xx --> S203[203 Non-Authoritative Information] + S2xx --> S205[205 Reset Content] S2xx --> S206[206 Partial Content] + S2xx --> S207[207 Multi-Status] + S2xx --> S208[208 Already Reported] + S2xx --> S226[226 IM Used] S3xx --> S301[301 Moved Permanently] S3xx --> S302[302 Found] + S3xx --> S303[303 See Other] S3xx --> S304[304 Not Modified] S3xx --> S307[307 Temporary Redirect] + S3xx --> S308[308 Permanent Redirect] style Success fill:#4caf50,color:#fff style S2xx fill:#66bb6a @@ -535,12 +542,18 @@ graph TB | `url` | str | 必填 | API接口的完整URL | | `method` | HTTPMethod | 必填 | HTTP方法 | | `content_type` | ContentType | None | Content-Type | -| `timeout` | int | 300 | 超时时间（秒），最小30 | +| `timeout` | int | 300 | 超时时间（秒），必须大于30 | | `body` | dict | {} | 已知的部分请求体 | | `query` | dict | {} | 已知的部分请求参数 | | `enable_filling` | bool | True | 是否需要自动参数填充 | | `to_user` | bool | False | 是否将输出返回给用户 | +## 实现注意事项 + +- 认证信息虽然会在 `_apply_auth` 中生成 Header/Cookie/Query 三类数据，但当前实现仅将 Cookie 和 Query 透传至 `httpx` 请求，Header 信息尚未写入请求参数，依赖 Header 的认证策略暂时无效。 +- `files` 参数作为占位符传入 `_make_api_call`，但 `APIInput` 尚未提供文件字段，Multipart 上传只能提交表单字段，文件内容暂未接入。 +- 当外部返回的响应体不是合法 JSON 时会抛出 `CallError`，不会返回原始字符串结果。 + ### 配置关系图 ```mermaid diff --git a/design/services/activity.md b/design/services/activity.md index 6786b0060..143ebc691 100644 --- a/design/services/activity.md +++ b/design/services/activity.md @@ -2,12 +2,12 @@ ## 概述 -Activity模块是Euler Copilot框架中的用户活动控制系统，负责管理系统的并发限制和用户限流。该模块实现了双重限流机制：单用户滑动窗口限流和全局并发任务限制，确保系统在高负载情况下的稳定性和公平性。 +Activity 模块是 openEuler Intelligence 框架中的用户活动控制系统，负责管理系统的并发限制和用户限流。该模块实现了单用户滑动窗口限流和全局并发任务限制，确保系统在高负载情况下的稳定性和公平性。 ## 核心功能 - **全局并发控制**: 限制系统同时执行的任务数量，防止系统过载 -- **单用户限流**: 基于滑动窗口的用户请求频率限制 +- **单用户限流**: 基于滑动窗口的用户请求频率限制（当前仅在活动检测阶段执行） - **活动状态管理**: 跟踪和管理用户活动状态 - **资源保护**: 通过限流机制保护系统资源 @@ -38,10 +38,13 @@ Activity模块是Euler Copilot框架中的用户活动控制系统，负责管 #### 静态方法 -- `is_active(user_sub)`: 检查系统是否达到并发上限 -- `set_active(user_sub)`: 设置用户活动状态 +- `is_active(user_sub)`: 先按用户滑动窗口统计，再按全局并发统计，达到任一阈值即返回 `True` +- `set_active(user_sub)`: 在未超过全局并发上限时登记一个活动任务，内部使用 SQLAlchemy `merge` 以 userSub 为键写入最新时间戳 - `remove_active(user_sub)`: 移除用户活动状态 +> **注意** +> 当前实现仅在 `is_active` 阶段执行滑动窗口校验；`set_active` 只进行一次全局并发计数后写入数据库。 + ## 时序图 ```mermaid @@ -79,11 +82,14 @@ sequenceDiagram Note over Activity, DB: 设置活动状态 Activity->>DB: SELECT COUNT(*) FROM framework_session_activity DB-->>Activity: 返回当前活跃任务数 - Activity->>Activity: 再次检查并发限制 + Activity->>Activity: 检查是否超过MAX_CONCURRENT_TASKS - alt 并发检查通过 - Activity->>DB: INSERT INTO framework_session_activity
(userSub, timestamp) - DB-->>Activity: 插入成功 + alt 并发超限 + Activity-->>Router: 抛出ActivityError + Router-->>Client: 返回503错误 + else 系统仍可处理 + Activity->>DB: MERGE INTO framework_session_activity
(userSub, timestamp) + DB-->>Activity: 插入或更新成功 Activity-->>Router: 设置成功 Router-->>Client: 处理请求 @@ -93,9 +99,6 @@ sequenceDiagram Activity->>DB: DELETE FROM framework_session_activity
WHERE userSub=? DB-->>Activity: 删除成功 Activity-->>Router: 清理完成 - else 并发检查失败 - Activity-->>Router: 抛出ActivityError - Router-->>Client: 返回503错误 end end end @@ -150,9 +153,9 @@ flowchart TD E -->|超过限制| D E -->|未超过| F[Activity.set_active] - F --> G{并发再次检查} + F --> G{并发检查} G -->|检查失败| H[抛出ActivityError] - G -->|检查通过| I[插入活动记录] + G -->|检查通过| I[插入/更新活动记录] I --> J[处理用户请求] J --> K[请求完成] @@ -190,11 +193,11 @@ flowchart LR H -->|否| J[通过] end - subgraph "双重检查机制" - K[set_active调用] --> L[插入前再次检查并发] - L --> M{并发检查通过?} - M -->|是| N[插入记录] - M -->|否| O[抛出异常] + subgraph "登记活跃任务" + K[set_active调用] --> L[统计当前活跃任务数] + L --> M{超过上限?} + M -->|是| O[抛出异常] + M -->|否| N[插入/更新记录] end E --> F diff --git a/design/services/flow.md b/design/services/flow.md index 8f435fd46..f682d7853 100644 --- a/design/services/flow.md +++ b/design/services/flow.md @@ -2,7 +2,7 @@ ## 1. 概述 -FlowManager 模块是 Euler Copilot Framework 中负责工作流（Flow）管理的核心模块。该模块提供了完整的工作流生命周期管理功能，包括创建、读取、更新、删除工作流，以及节点元数据管理、服务管理等功能。 +FlowManager 模块是 openEuler Intelligence 框架中负责工作流（Flow）管理的核心模块。当前实现重点覆盖已有 Flow 的读取、更新、删除，以及节点元数据管理、服务管理等功能（独立的“新建 Flow”流程尚未单独提供专用接口）。 ### 1.1 核心组件 @@ -174,13 +174,15 @@ sequenceDiagram FM->>FM: is_flow_config_equal() FM->>FL: save(app_id, flow_id, flow) FL->>FS: 写入 YAML 文件 - FL->>DB: 更新 Flow 记录 + FL->>DB: 以 appId 为范围删除旧 Flow 记录并写入最新元数据 FL->>DB: 更新 AppHashes FL-->>FM: 保存成功 FM-->>API: 更新完成 API-->>Client: 返回更新结果 ``` +Note: 上述流程不会自动触发向量索引同步，如需同步需在业务层额外调用 `_update_vector` 或传入 embedding 模型。 + ### 3.2 节点和服务管理流程 ```mermaid @@ -282,7 +284,7 @@ sequenceDiagram FL->>FS: 检查文件是否存在 FL->>FS: 删除 YAML 文件 FL->>DB: 删除 Flow 记录 - FL->>DB: 删除向量数据(如果有) + FL->>DB: 删除向量数据(仅当调用方向 FlowLoader.delete 传入 embedding_model 时) FL->>DB: commit FL-->>FM: 删除成功 @@ -481,15 +483,20 @@ Authorization: Bearer | 方法 | 功能 | 异常 | |------|------|------| -| `load` | 从文件系统加载工作流 | `FileNotFoundError`, `RuntimeError` | -| `save` | 保存工作流到文件系统 | - | -| `delete` | 删除工作流文件和数据 | - | +| `load` | 从文件系统加载工作流，并刷新数据库中的基本元数据 | `FileNotFoundError`, `RuntimeError` | +| `save` | 保存工作流到文件系统，并在数据库中以“先删后插”方式写入最新元数据 | - | +| `delete` | 删除工作流文件和数据库记录（不传 embedding_model 时不会触发向量清理） | - | | `_load_yaml_file` | 加载YAML文件 | - | | `_validate_basic_fields` | 验证基本字段 | - | -| `_process_edges` | 处理边的转换 | - | -| `_process_steps` | 处理步骤的转换 | `ValueError` | -| `_update_db` | 更新数据库记录 | - | -| `_update_vector` | 更新向量数据 | - | +| `_process_edges` | 将 YAML 的 `from/to/type` 转换为内部字段，分支通过 `stepId.branchId` 字符串表示 | - | +| `_process_steps` | 处理步骤的类型和文档信息 | `ValueError` | +| `_update_db` | 同步 FlowInfo 和 AppHashes（覆盖同一 appId 的旧记录） | - | +| `_update_vector` | 预留的向量更新方法（当前调用路径未触发） | - | + +> **实现提示** +> +> - FlowLoader 的 `save`/`load` 都会调用 `_update_db`，该方法会删除同一 `appId` 下的旧 `FlowInfo` 记录后再写入新记录，调用侧需要在保存多个 Flow 时显式传入完整集合。 +> - 向量数据的增量更新需要外部显式调用 `_update_vector` 或在删除时传入 embedding 模型；默认调用路径不会同步向量索引。 ## 6. 状态管理 @@ -763,4 +770,4 @@ FlowManager 模块提供了完整的工作流管理功能，具有以下特点: ✅ **扩展性强**: 支持自定义节点和边类型 ✅ **数据一致性**: 数据库与文件系统双重存储保证一致性 -该模块是 Euler Copilot Framework 工作流引擎的核心组件，为上层应用提供了稳定可靠的工作流管理服务。 +该模块是 openEuler Intelligence 框架工作流引擎的核心组件，为上层应用提供了稳定可靠的工作流管理服务。 diff --git a/design/services/personal_token.md b/design/services/personal_token.md index c06651cce..a5ba63c6f 100644 --- a/design/services/personal_token.md +++ b/design/services/personal_token.md @@ -1,6 +1,6 @@ # 个人令牌（API Key）服务设计 -本文档描述 Euler Copilot Framework 中与账号 API Key（Personal Token）相关的鉴权策略、核心流程、接口规范以及错误返回约定。实现参考： +本文档描述 openEuler Intelligence 框架中与账号 API Key（Personal Token）相关的鉴权策略、核心流程、接口规范以及已知限制。实现参考： - `apps/services/personal_token.py`：个人令牌生成、校验 - `apps/dependency/user.py`：请求依赖校验（`verify_personal_token`、`verify_session`） @@ -10,10 +10,8 @@ ## 架构与职责 - 个人令牌用于对用户调用进行鉴权，是接口级依赖；受保护路由在鉴权通过后再处理请求。 -- 生效范围与优先级约定： - - 会话（Session）：仅在浏览器场景生效（前端 Web 应用）。 - - 个人令牌（API Key）：在客户端与 Shell 场景生效（CLI、Agent、集成脚本等）。 - - 二者不能组合使用；若请求同时携带，会优先以 API Key 进行鉴权并忽略会话态。 +- 依赖执行顺序为：`verify_session`（可选，遇到 `Bearer` 开头的 Authorization 时解析出 session_id）→ `verify_personal_token`（必选）。`verify_personal_token` 会直接把 `Authorization` 头的完整内容视作个人令牌。 +- 当前实现要求客户端发送的 `Authorization` 头只能包含纯个人令牌字符串；若携带 `Bearer ` 会被视为无效令牌并返回 401。 - 个人令牌的生成与更新由 `PersonalTokenManager.update_personal_token` 负责；校验由 `verify_personal_token` 委托 `PersonalTokenManager.get_user_by_personal_token` 完成。 ## 流程图（重置 API Key） @@ -23,12 +21,14 @@ flowchart TD A[客户端: POST /api/auth/key] --> B[依赖注入: verify_session] B --> C[依赖注入: verify_personal_token] C --> D[AuthRouter.change_personal_token] - D --> E[PersonalTokenManager.update_personal_token] - E -->|成功| F[DB: 更新 User.personalToken] - F --> G[返回新 api_key] - E -->|失败| H[记录异常并返回 500] + D --> E[PersonalTokenManager.update_personal_token] + E -->|成功| F[DB: UPDATE framework_user] + F --> G[返回新 api_key] + E -->|失败| H[记录异常并返回 500] ``` +Note: 现实实现中 `update_personal_token` 使用 `User.id` 作为过滤条件且缺少显式 `commit`，导致数据库更新不会落库；接口仍返回“新 api_key”。 + ## 时序图（受保护资源访问） ```mermaid @@ -39,11 +39,11 @@ sequenceDiagram participant PTM as PersonalTokenManager participant DB - Client->>Router: 调用受保护接口（携带 Authorization ） + Client->>Router: 调用受保护接口（携带 Authorization ） Router->>Dep: verify_session Dep-->>Router: 注入 request.state.session_id / user_sub（可选） Router->>Dep: verify_personal_token - Dep->>PTM: get_user_by_personal_token(token) + Dep->>PTM: get_user_by_personal_token(token) PTM->>DB: SELECT userSub WHERE personalToken == token DB-->>PTM: userSub 或 None PTM-->>Dep: userSub 或 None @@ -109,11 +109,9 @@ curl -X POST \ ### 2) 受保护资源的通用调用方式 -- 多数路由（如 `GET /api/user`、`PUT /api/user/llm` 等）要求通过任一鉴权方式方可访问。 -- 使用与优先级： - - 客户端/Shell：仅携带 API Key；`Authorization: `。 - - 浏览器：由会话完成鉴权；`Authorization: Bearer ` 由前端/网关注入。 - - 若两者同时出现，以 API Key 优先，忽略会话态。 +- 大多数受保护路由（如 `GET /api/user`、`PUT /api/user/llm` 等）必须提供合法的个人令牌；缺失时直接返回 401。 +- `Authorization` 头的值应为纯个人令牌字符串，不应带 `Bearer` 等前缀。 +- 会话 `Bearer` 头若与个人令牌同时存在，会被整体按个人令牌解析，最终导致 401。 请求示例（以 `GET /api/user` 为例，客户端/Shell）： @@ -140,7 +138,7 @@ curl -X GET \ ## 安全与最佳实践 -- 会话仅在浏览器场景生效，API Key 仅在客户端与 Shell 场景生效；不要同时携带，若同时携带则以 API Key 为准。 +- 当前实现只接受个人令牌鉴权；需要会话鉴权时，必须调整依赖逻辑或提供回退方案。 - 后端不回显旧密钥，仅在重置操作时返回新密钥一次；客户端需妥善保存。 - 个人令牌长度固定 16 位，可按需在前后端增加强度与轮换策略。 - 服务侧可结合访问频率限制与审计日志，及时发现异常使用。 @@ -155,10 +153,16 @@ curl -X GET \ - 校验通过后，将用户唯一标识写入请求上下文，供后续处理使用。 - 重置个人令牌（POST /api/auth/key） - - 在受保护路由中，由会话与个人令牌依赖共同保护；请求到达后，为当前用户生成新令牌。 + - 在受保护路由中，同时执行会话解析与个人令牌校验；当前只有个人令牌校验会真正影响放行。 - 生成方式为对随机 UUID 进行哈希处理并截取固定长度（16 位十六进制字符串）。 - - 将新令牌写入数据库并作为响应返回；若数据库更新失败，返回服务器错误。 + - 理论上应将新令牌写入数据库并返回响应；但由于实现缺陷实际不会持久化。 - 令牌-用户映射与更新 - “令牌查用户”：按“令牌等于用户表中的个人令牌字段”的条件检索，返回匹配到的用户标识；异常会被记录并视为查找失败。 - - “更新令牌”：按用户标识定位记录并写入新生成的令牌；更新异常会被记录并返回失败。 + - “更新令牌”：按用户标识定位记录并写入新生成的令牌；当前实现缺少 `commit` 且使用 `User.id` 过滤（与传入的 `user_sub` 类型不符），导致数据库值保持不变。 + + ## 已知限制与建议 + + 1. **Session 依赖仅作补充**：`verify_session` 不会放行缺少个人令牌的请求，浏览器若只携带 `Bearer ` 会被 `verify_personal_token` 拒绝。若需要仅依靠会话鉴权，需要调整依赖顺序或放宽 `verify_personal_token` 的空值处理。 + 2. **令牌更新未持久化**：`update_personal_token` 返回的新令牌不会写回数据库（缺少 `commit` 且过滤字段不符），调用方应当在修复代码前避免依赖该接口更新数据。 + 3. **令牌格式固定**：个人令牌固定为 16 位十六进制字符串，当前没有长度或复杂度配置项；若需要更强安全性，需要扩展生成逻辑与存储字段长度。 diff --git a/design/services/session.md b/design/services/session.md index abb7289b9..163768cd6 100644 --- a/design/services/session.md +++ b/design/services/session.md @@ -2,7 +2,7 @@ ## 概述 -Session模块是Euler Copilot框架中的会话管理系统，负责创建、删除和验证用户会话。该模块实现了基于数据库的会话存储机制，支持会话创建、会话删除、用户信息获取以及黑名单用户检查功能，确保系统安全性和用户身份验证的可靠性。 +Session 模块是 openEuler Intelligence 框架中的会话管理系统，负责创建、删除和验证用户会话。该模块实现了基于数据库的会话存储机制，支持会话创建、会话删除、用户信息获取以及黑名单用户检查功能，确保系统安全性和用户身份验证的可靠性。 ## 核心功能 diff --git a/design/services/tag.md b/design/services/tag.md index 8b840dcf2..a6df9c7a6 100644 --- a/design/services/tag.md +++ b/design/services/tag.md @@ -2,11 +2,11 @@ ## 概述 -Tag模块是openEuler Intelligence框架中的用户标签管理系统，用于管理用户分类标签的定义、创建、更新和删除操作。该模块支持标签的CRUD操作，并提供用户标签关联功能。 +Tag 模块是 openEuler Intelligence 框架中的用户标签管理系统，用于管理用户分类标签的定义、更新和删除操作，并提供用户标签关联功能。当前公开的管理 API 仅支持查询/修改/删除已有标签，新增标签需通过后端内部调用 `TagManager.add_tag` 完成。 ## 核心功能 -- **标签管理**: 创建、查询、更新、删除标签 +- **标签管理**: 查询、更新、删除标签（新增操作需后端内部调用） - **用户标签关联**: 管理用户与标签的关联关系 - **标签统计**: 统计标签使用频次 - **权限控制**: 仅管理员可进行标签管理操作 @@ -64,12 +64,12 @@ erDiagram #### POST /api/tag -- **功能**: 添加或更新标签 +- **功能**: 更新已有标签定义 - **权限**: 管理员 - **请求体**: `PostTagData` - `tag`: 标签名称 - `description`: 标签描述 -- **逻辑**: 如果标签不存在则创建，存在则更新 +- **逻辑**: 标签存在时更新 `definition` 和 `updatedAt`；标签不存在时抛出 `ValueError`（接口返回 500）。 #### DELETE /api/tag @@ -87,8 +87,8 @@ erDiagram - `get_all_tag()`: 获取所有标签 - `get_tag_by_name(name)`: 根据名称获取标签 - `get_tag_by_user_sub(user_sub)`: 获取用户的所有标签 -- `add_tag(data)`: 添加新标签 -- `update_tag_by_name(data)`: 更新标签定义 +- `add_tag(data)`: 添加新标签（当前路由未调用） +- `update_tag_by_name(data)`: 更新标签定义，标签不存在时抛出 `ValueError` - `delete_tag(data)`: 删除标签 ## 时序图 @@ -108,19 +108,20 @@ sequenceDiagram Service-->>Router: 返回标签数据 Router-->>Client: 返回JSON响应 - Note over Client, DB: 标签创建/更新流程 + Note over Client, DB: 标签更新流程 Client->>Router: POST /api/tag Router->>Service: update_tag_by_name(data) Service->>DB: SELECT * FROM framework_tag WHERE name=? DB-->>Service: 返回查询结果 alt 标签不存在 - Service->>DB: INSERT INTO framework_tag + Service-->>Router: 抛出异常 + Router-->>Client: 返回500错误 else 标签存在 Service->>DB: UPDATE framework_tag SET definition=?, updatedAt=? + DB-->>Service: 操作完成 + Service-->>Router: 返回操作结果 + Router-->>Client: 返回成功响应 end - DB-->>Service: 操作完成 - Service-->>Router: 返回操作结果 - Router-->>Client: 返回成功响应 Note over Client, DB: 标签删除流程 Client->>Router: DELETE /api/tag @@ -158,7 +159,7 @@ flowchart TD B -->|验证成功| D{请求类型} D -->|GET| E[获取标签列表] - D -->|POST| F[创建/更新标签] + D -->|POST| F[更新标签] D -->|DELETE| G[删除标签] E --> H[TagManager.get_all_tag] @@ -168,12 +169,11 @@ flowchart TD F --> L[TagManager.update_tag_by_name] L --> M{标签是否存在} - M -->|不存在| N[创建新标签] + M -->|不存在| N[返回500错误] M -->|存在| O[更新标签定义] - N --> P[INSERT操作] O --> Q[UPDATE操作] - P --> R[返回成功响应] - Q --> R + N --> R[返回错误响应] + Q --> R[返回成功响应] G --> S[TagManager.delete_tag] S --> T{标签是否存在} diff --git a/design/services/user.md b/design/services/user.md index 742d6bd7c..ec646910e 100644 --- a/design/services/user.md +++ b/design/services/user.md @@ -2,7 +2,7 @@ ## 概述 -User模块是Euler Copilot框架中的核心用户管理模块，负责处理用户信息的CRUD操作、用户LLM配置管理、用户标签管理等功能。该模块采用分层架构设计，包含数据模型层、服务层和路由层。 +User 模块是 openEuler Intelligence 框架中的核心用户管理模块，负责处理用户信息的CRUD操作、用户LLM配置管理、用户标签管理等功能。该模块采用分层架构设计，包含数据模型层、服务层和路由层。 ## 架构设计 @@ -170,11 +170,13 @@ sequenceDiagram end ``` +Note: 该流程不会校验 Function LLM 是否存在；当新的 embedding LLM 未找到时，系统仅记录错误日志，接口仍返回成功。 + #### 核心逻辑 -1. **模型验证**: 验证用户选择的LLM模型是否存在 -2. **数据更新**: 更新用户表中的functionLLM和embeddingLLM字段 -3. **向量化处理**: 当embedding模型变化时，自动触发向量化过程 +1. **模型验证**: 当前实现不会主动校验 Function LLM/Embedding LLM 是否存在；仅在后续向量化阶段尝试按 ID 查询模型 +2. **数据更新**: 将请求中的 `functionLLM`、`embeddingLLM` 直接写入用户表 +3. **向量化处理**: 当 embedding 模型发生变化时尝试初始化新模型并触发向量化；若模型缺失将记录错误但不回滚已保存的字段 ### 3. 用户标签管理 diff --git a/documents/design/appcenter.md b/documents/design/appcenter.md index 60a81eb4a..25ecbf082 100644 --- a/documents/design/appcenter.md +++ b/documents/design/appcenter.md @@ -1,8 +1,8 @@ -# openEuler Copilot Framework AppCenter 设计文档 +# openEuler Intelligence 框架 AppCenter 设计文档 ## 1. 整体设计 -AppCenter 是 openEuler Copilot Framework 的应用中心模块, 主要提供以下功能: +AppCenter 是 openEuler Intelligence 框架的应用中心模块, 主要提供以下功能: - 应用的 CRUD 操作 (创建、读取、更新、删除) - 应用收藏管理 -- Gitee