diff --git a/docs/technical/ocr-architecture.md b/docs/technical/ocr-architecture.md
index 2caf0c4c24..6b6ad890e7 100644
--- a/docs/technical/ocr-architecture.md
+++ b/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
diff --git a/docs/technical/ocr-architecture.zh.md b/docs/technical/ocr-architecture.zh.md
index e69d94af3d..b70d251160 100644
--- a/docs/technical/ocr-architecture.zh.md
+++ b/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 提供商保持与数据关注点的隔离
+
 ## 提供商系统
 
 ### 提供商注册