docs: update OCR architecture documentation with IPC details

Update both English and Chinese versions of the OCR architecture documentation to reflect current implementation where IPC serves as API layer. Clarify direct communication between renderer and business layer, and enhance data flow diagrams with new components and security aspects.

docs/technical/ocr-architecture.md

@@ -9,17 +9,18 @@ Cherry Studio's OCR (Optical Character Recognition) system is a modular, extensi
 
 ## Architecture Layers
 
-The OCR architecture follows a strict layered approach where each layer only communicates with adjacent layers:
+The OCR architecture follows a layered approach where data interactions occur through RESTful APIs, while IPC serves as part of the API layer, allowing the renderer to interact directly with the business layer:
 
 ### 1. API Layer
-**Location**: `src/main/data/api/handlers/`
+**Location**: `src/main/data/api/handlers/`, `src/main/ipc.ts`, `src/preload/index.ts`
 
-- **IPC Bridge**: Secure communication between main and renderer processes
+- **IPC Bridge**: Serves as API layer connecting renderer to main process
+- **Request Routing**: Routes IPC calls to appropriate service methods
 - **Type Safety**: Zod schemas for request/response validation
-- **Error Handling**: Centralized error propagation
-- **Entry Point**: All OCR operations enter through this layer
+- **Error Handling**: Centralized error propagation across process boundaries
+- **Security**: Secure communication sandbox between renderer and main processes
 
-### 2. OCR Service Layer
+### 2. OCR Service Layer (Business Layer)
 **Location**: `src/main/services/ocr/`
 
 - **OcrService**: Main business logic orchestrator and central coordinator
@@ -28,6 +29,7 @@ The OCR architecture follows a strict layered approach where each layer only com
 - **Lifecycle Management**: Handles provider initialization and disposal
 - **Validation**: Ensures provider availability and data integrity
 - **Orchestration**: Coordinates between providers and data services
+- **Direct IPC Access**: Renderer can directly invoke business layer methods via IPC
 
 ### 3. Provider Services Layer
 **Location**: `src/main/services/ocr/builtin/`
@@ -53,17 +55,18 @@ The OCR architecture follows a strict layered approach where each layer only com
 ### 5. Frontend Layer
 **Location**: `src/renderer/src/services/ocr/`, `src/renderer/src/hooks/ocr/`
 
-- **Service Facade**: Frontend OCR service for IPC communication
+- **Direct IPC Communication**: Direct interaction with business layer via IPC
 - **React Hooks**: Custom hooks for OCR operations and state management
 - **Configuration UI**: Settings pages for provider configuration
+- **State Management**: Frontend state synchronization with backend data
 
 ## Data Flow
 
 ```mermaid
 graph TD
-    A[Frontend UI] --> B[OcrService Renderer]
-    B --> C[API Layer - IPC Handler]
-    C --> D[OCR Service Layer]
+    A[Frontend UI] --> B[Frontend OCR Service]
+    B --> C[API Layer - IPC Bridge]
+    C --> D[OCR Service Layer - Business Logic]
     D --> E[Data Layer - Provider Repository]
     D --> F[Provider Services Layer]
     F --> G[OCR Processing]
@@ -77,8 +80,15 @@ graph TD
     style D fill:#e1f5fe
     style F fill:#f3e5f5
     style E fill:#e8f5e8
+    style C fill:#fff3e0
 ```
 
+**Key Flow Characteristics:**
+- **Direct Business Access**: Frontend communicates directly with OCR Service layer via IPC
+- **IPC as API Gateway**: IPC bridge functions as the API layer, handling routing and validation
+- **Data Isolation**: Only business layer interacts with data persistence
+- **Provider Independence**: OCR providers remain isolated from data concerns
+
 ## Provider System
 
 ### Provider Registration

docs/technical/ocr-architecture.zh.md

@@ -9,17 +9,18 @@ Cherry Studio 的 OCR（光学字符识别）系统是一个模块化、可扩
 
 ## 架构分层
 
-OCR 架构遵循严格的分层方法，每层只与相邻层通信：
+OCR 架构采用分层方法，其中数据交互通过 RESTful API 进行，而 IPC 作为 API 层的一部分，允许 Renderer 直接与业务层交互：
 
 ### 1. API 层
-**位置**: `src/main/data/api/handlers/`
+**位置**: `src/main/data/api/handlers/`, `src/main/ipc.ts`, `src/preload/index.ts`
 
-- **IPC 桥接**: 主进程和渲染进程之间的安全通信
+- **IPC 桥接**: 作为 API 层连接 Renderer 到主进程
+- **请求路由**: 将 IPC 调用路由到相应的服务方法
 - **类型安全**: 使用 Zod 模式进行请求/响应验证
-- **错误处理**: 集中式错误传播
-- **入口点**: 所有 OCR 操作都通过此层进入
+- **错误处理**: 跨进程边界的集中式错误传播
+- **安全**: Renderer 和主进程之间的安全通信沙盒
 
-### 2. OCR 服务层
+### 2. OCR 服务层（业务层）
 **位置**: `src/main/services/ocr/`
 
 - **OcrService**: 主要业务逻辑协调器和中央协调器
@@ -28,6 +29,7 @@ OCR 架构遵循严格的分层方法，每层只与相邻层通信：
 - **生命周期管理**: 处理提供商初始化和销毁
 - **验证**: 确保提供商可用性和数据完整性
 - **协调**: 协调提供商和数据服务之间的交互
+- **直接 IPC 访问**: Renderer 可通过 IPC 直接调用业务层方法
 
 ### 3. 提供商服务层
 **位置**: `src/main/services/ocr/builtin/`
@@ -50,20 +52,21 @@ OCR 架构遵循严格的分层方法，每层只与相邻层通信：
 - **JSON 配置**: 多态的 `config` 字段存储提供商特定的设置
 - **数据访问**: 仅由 OCR 服务层访问
 
-### 5. 前端层
+### 5. Renderer 层
 **位置**: `src/renderer/src/services/ocr/`, `src/renderer/src/hooks/ocr/`
 
-- **服务门面**: 用于 IPC 通信的前端 OCR 服务
+- **直接 IPC 通信**: 通过 IPC 与业务层直接交互
 - **React Hooks**: 用于 OCR 操作和状态管理的自定义钩子
 - **配置 UI**: 提供商配置的设置页面
+- **状态管理**: Renderer 状态与后端数据同步
 
 ## 数据流
 
 ```mermaid
 graph TD
-    A[前端 UI] --> B[OcrService 渲染进程]
-    B --> C[API 层 - IPC 处理器]
-    C --> D[OCR 服务层]
+    A[Renderer UI] --> B[Renderer OCR 服务]
+    B --> C[API 层 - IPC 桥接]
+    C --> D[OCR 服务层 - 业务逻辑]
     D --> E[数据层 - 提供商仓储]
     D --> F[提供商服务层]
     F --> G[OCR 处理]
@@ -77,8 +80,15 @@ graph TD
     style D fill:#e1f5fe
     style F fill:#f3e5f5
     style E fill:#e8f5e8
+    style C fill:#fff3e0
 ```
 
+**关键流程特征**:
+- **直接业务访问**: Renderer 通过 IPC 与 OCR 服务层直接通信
+- **IPC 作为 API 网关**: IPC 桥接作为 API 层，处理路由和验证
+- **数据隔离**: 只有业务层与数据持久化交互
+- **提供商独立性**: OCR 提供商保持与数据关注点的隔离
+
 ## 提供商系统
 
 ### 提供商注册