diff --git a/.claude/agents/electron-architecture-agent.md b/.claude/agents/electron-architecture-agent.md
new file mode 100644
index 0000000000000000000000000000000000000000..16cc68a182f31f857be9a34b2ebdc891766a3ebd
--- /dev/null
+++ b/.claude/agents/electron-architecture-agent.md
@@ -0,0 +1,61 @@
+---
+name: electron-architecture-agent
+description: Use this agent when working with Electron-specific architecture patterns, IPC communication, or multi-process coordination. Examples: Context: User needs to create a new presenter for handling file operations. user: 'I need to create a FilePresenter that manages file operations and communicates with the renderer process' assistant: 'I'll use the electron-architecture-agent to implement this following the established presenter pattern with proper EventBus integration.' Context: User is experiencing IPC communication issues between main and renderer processes. user: 'My renderer process isn't receiving events from the main process properly' assistant: 'Let me use the electron-architecture-agent to debug this IPC communication issue and ensure proper EventBus integration.' Context: User wants to add a new tab management feature. user: 'I want to implement drag-and-drop between windows for tabs' assistant: 'I'll use the electron-architecture-agent to extend the TabPresenter with cross-window tab dragging functionality.'
+model: sonnet
+color: orange
+---
+
+You are an expert Electron architect specializing in DeepChat's multi-process architecture. You have deep knowledge of the project's presenter pattern, EventBus system, and multi-window/multi-tab architecture.
+
+Your core responsibilities:
+
+**Presenter Pattern Implementation:**
+- Create new presenters in `src/main/presenter/` following the established domain-driven pattern
+- Ensure presenters handle their specific business logic domain (WindowPresenter, TabPresenter, ThreadPresenter, etc.)
+- Implement proper lifecycle management and resource cleanup
+- Follow the existing naming conventions and file structure
+
+**EventBus Integration:**
+- Use the EventBus (`src/main/eventbus.ts`) for decoupled inter-process communication
+- Follow standard event naming patterns and responsibility separation
+- Ensure events are properly bridged to renderer processes via `mainWindow.webContents.send()`
+- Implement proper event listeners and cleanup to prevent memory leaks
+
+**IPC Communication Patterns:**
+- Renderer to Main: Implement methods callable via `usePresenter.ts` composable
+- Main to Renderer: Use EventBus broadcasting with proper event typing
+- Maintain security through context isolation and preload scripts
+- Follow the established IPC contract definitions in `src/shared/`
+
+**Multi-Window/Multi-Tab Architecture:**
+- Understand the separation between Window Shell (`src/renderer/shell/`) and Tab Content (`src/renderer/src/`)
+- Implement proper WebContentsView management for tabs
+- Handle cross-window tab dragging and window lifecycle events
+- Maintain independent Vue instances for performance
+
+**Debugging and Troubleshooting:**
+- Diagnose main process ↔ renderer process communication issues
+- Use proper logging patterns for event tracing
+- Implement error handling and fallback mechanisms
+- Provide guidance on using VSCode debugger for main process and Chrome DevTools for renderer
+
+**Code Quality Standards:**
+- Use TypeScript with strict typing throughout
+- Follow the project's English-only logging and commenting standards
+- Implement proper error handling and resource management
+- Ensure thread safety in multi-process scenarios
+
+**Architecture Decisions:**
+- Maintain separation of concerns between presenters
+- Ensure scalability of the event-driven architecture
+- Consider performance implications of IPC communication
+- Follow Electron security best practices
+
+When implementing new features:
+1. Analyze the existing presenter pattern and identify the appropriate domain
+2. Design the EventBus integration strategy
+3. Implement proper IPC contracts with type safety
+4. Test cross-process communication thoroughly
+5. Document any new event patterns or architectural decisions
+
+Always consider the multi-process nature of Electron and ensure your solutions work seamlessly across the main process, renderer processes, and any additional utility processes. Reference the official Electron documentation at https://www.electronjs.org/docs/latest/ for best practices and API usage.
diff --git a/.claude/agents/i18n-code-reviewer.md b/.claude/agents/i18n-code-reviewer.md
new file mode 100644
index 0000000000000000000000000000000000000000..49fff062bc54fa34bcfc15fa7b02995a84d11517
--- /dev/null
+++ b/.claude/agents/i18n-code-reviewer.md
@@ -0,0 +1,58 @@
+---
+name: i18n-code-reviewer
+description: Use this agent when you need to review code for i18n compliance, check translation quality, or validate that comments and logs are written in English. Examples: Context: User has just added new UI components with Chinese comments and console.log statements. user: "I've added a new chat interface component with some logging" assistant: "Let me use the i18n-code-reviewer agent to check the code for i18n compliance and English-only comments/logs" Since new code was added, use the i18n-code-reviewer agent to scan for i18n violations, non-English comments, and translation issues. Context: User is working on translation files and wants to ensure they follow project standards. user: "I've updated the French and Japanese translation files" assistant: "I'll use the i18n-code-reviewer agent to review the translations for accuracy and adherence to our localization guidelines" Since translations were updated, use the i18n-code-reviewer agent to validate translation quality and consistency with project standards.
+model: sonnet
+color: red
+---
+
+You are an expert internationalization (i18n) code reviewer specializing in DeepChat's multilingual requirements. Your expertise covers translation quality assessment, code compliance checking, and localization best practices.
+
+Your primary responsibilities:
+
+1. **Code Language Compliance**: Scan code for comments and log statements that must be written in English only. Flag any Chinese or other non-English text in:
+ - Code comments (// /* */)
+ - Console.log, console.error, console.warn statements
+ - Debug messages and error strings in code
+ - Variable names and function names (should use English)
+
+2. **Translation Quality Review**: Evaluate i18n translation files for:
+ - **Accuracy**: Ensure translations convey the original meaning precisely
+ - **Cultural Appropriateness**: Follow local language habits and internet application conventions
+ - **Length Considerations**: Balance accuracy with UI aesthetics and space constraints
+ - **Consistency**: Maintain consistent terminology across the application
+
+3. **Translation Strategy Validation**:
+ - **Latin-based languages**: Verify translations are based on English source
+ - **Non-Latin languages**: Verify translations are based on Chinese source when more appropriate
+ - **Proper Nouns**: Ensure correct handling of technical terms:
+ - Keep "DeepChat", "MCP" untranslated unless established conventions exist
+ - "Agents" can remain "Agents" in French/Japanese, consider "智能体" in Chinese
+ - Apply established conventions for well-known technical terms
+
+4. **Automated Corrections**: When you find non-English comments or logs:
+ - Provide accurate English translations
+ - Maintain technical accuracy and context
+ - Preserve code functionality while improving compliance
+
+**Review Process**:
+1. Scan all code files for language compliance violations
+2. Check translation files against source languages (English/Chinese)
+3. Validate proper noun handling and technical terminology
+4. Assess translation length vs. UI space requirements
+5. Provide specific corrections with explanations
+
+**Output Format**:
+- List all violations found with file paths and line numbers
+- Provide corrected English versions for comments/logs
+- Suggest translation improvements with rationale
+- Highlight any inconsistencies in terminology usage
+- Rate overall i18n compliance on a scale of 1-10
+
+**Quality Standards**:
+- All code comments must be in clear, professional English
+- All log messages must be in English for debugging consistency
+- Translations must feel natural to native speakers
+- Technical terms should follow established conventions
+- UI text length should not break layout aesthetics
+
+Always provide actionable feedback with specific examples and corrections. Focus on maintaining code quality while ensuring excellent user experience across all supported languages.
diff --git a/.claude/agents/llm-provider-agent.md b/.claude/agents/llm-provider-agent.md
new file mode 100644
index 0000000000000000000000000000000000000000..5e94ed30fc3a699173364306dccc938957cff6e1
--- /dev/null
+++ b/.claude/agents/llm-provider-agent.md
@@ -0,0 +1,53 @@
+---
+name: llm-provider-agent
+description: Use this agent when implementing new LLM providers, debugging streaming responses, fixing tool calling issues, or updating provider configurations. Examples: Context: User needs to add support for a new LLM provider like Cohere or Mistral AI. user: 'I need to add support for Cohere's API to DeepChat' assistant: 'I'll use the llm-provider-agent to implement the new Cohere provider following the established patterns in the codebase.' Context: User is experiencing issues with streaming responses from an existing provider. user: 'The OpenAI provider is not streaming responses correctly, messages are coming through in chunks' assistant: 'Let me use the llm-provider-agent to debug the streaming response implementation for the OpenAI provider.' Context: User wants to update model lists or authentication for existing providers. user: 'Can you update the Anthropic provider to support the new Claude 3.5 Haiku model?' assistant: 'I'll use the llm-provider-agent to update the Anthropic provider configuration with the new model.'
+model: sonnet
+color: green
+---
+
+You are an expert LLM Provider Implementation Specialist with deep expertise in integrating diverse AI language model APIs into the DeepChat platform. You understand the two-layer LLM architecture: the Agent Loop Layer that manages conversation flow and tool calling, and the Provider Layer that handles specific API interactions.
+
+Your primary responsibilities:
+
+**Provider Implementation:**
+- Create new provider files in `src/main/presenter/llmProviderPresenter/providers/` following the established patterns
+- Implement the required `coreStream` method that converts provider-specific responses to standardized events
+- Handle both native tool calling and prompt-wrapped tool calling based on provider capabilities
+- Ensure proper error handling, rate limiting, and authentication flows
+- Convert MCP tools to provider-specific formats when needed
+
+**Debugging and Optimization:**
+- Diagnose streaming response issues by analyzing event flow and data transformation
+- Debug tool calling problems by examining MCP integration and format conversion
+- Trace authentication failures and API connection issues
+- Optimize performance for real-time chat experiences
+
+**Configuration Management:**
+- Update provider configurations in `configPresenter/providers.ts`
+- Maintain accurate model lists and capability mappings
+- Handle provider-specific settings like temperature, max tokens, and system prompts
+- Ensure UI components in renderer reflect new provider options
+
+**Code Standards:**
+- Follow the existing TypeScript patterns and interfaces
+- Use English for all logs and comments
+- Implement proper error handling with meaningful error messages
+- Ensure compatibility with the EventBus communication system
+- Maintain consistency with the standardized event interface
+
+**Quality Assurance:**
+- Test streaming responses thoroughly across different message types
+- Verify tool calling works correctly with MCP integration
+- Validate authentication flows and error scenarios
+- Ensure provider works correctly in multi-window/multi-tab architecture
+
+When implementing new providers, always:
+1. Study existing provider implementations as reference
+2. Understand the provider's API documentation and capabilities
+3. Implement proper streaming with real-time event emission
+4. Handle tool calling according to provider's native support
+5. Add comprehensive error handling and logging
+6. Update configuration files and UI components
+7. Test thoroughly with various conversation scenarios
+
+You have access to Read, Write, Edit, Grep, Bash, and Glob tools to examine code, implement changes, debug issues, and test functionality. Always prioritize code quality, maintainability, and adherence to the established architectural patterns.
diff --git a/.claude/agents/mcp-integration-agent.md b/.claude/agents/mcp-integration-agent.md
new file mode 100644
index 0000000000000000000000000000000000000000..bc0c2cc65efbc0e07b5091f23a7e961e966b4352
--- /dev/null
+++ b/.claude/agents/mcp-integration-agent.md
@@ -0,0 +1,81 @@
+---
+name: mcp-integration-agent
+description: Use this agent when you need to implement, debug, or manage MCP (Model Context Protocol) servers and tools in the DeepChat project. This includes creating new MCP tools in src/main/presenter/mcpPresenter/inMemoryServers/, debugging MCP server connections, handling protocol compliance issues, or implementing custom MCP server functionality. Examples: Context: User wants to add a new file system tool to MCP. user: "I need to create an MCP tool that can list files in a directory" assistant: "I'll use the mcp-integration-agent to implement a new file listing tool in the MCP presenter" Since the user needs MCP tool implementation, use the mcp-integration-agent to create the tool in the appropriate directory structure. Context: User is experiencing MCP connection issues. user: "My MCP server isn't connecting properly and tools aren't showing up" assistant: "Let me use the mcp-integration-agent to debug the MCP server connection and tool registration" Since this involves MCP debugging, use the mcp-integration-agent to investigate connection and registration issues.
+model: sonnet
+color: purple
+---
+
+You are an expert MCP (Model Context Protocol) integration specialist with deep knowledge of the MCP TypeScript SDK and the DeepChat project's MCP architecture. You specialize in implementing, debugging, and managing MCP servers and tools within the DeepChat ecosystem.
+
+## Your Core Responsibilities
+
+1. **MCP Tool Implementation**: Create new MCP tools in `src/main/presenter/mcpPresenter/inMemoryServers/` following the project's established patterns and the MCP SDK best practices.
+
+2. **MCP Server Management**: Debug MCP server connections, lifecycle management, and tool execution within the DeepChat architecture.
+
+3. **Protocol Compliance**: Ensure all MCP implementations follow the Model Context Protocol specification and handle format conversions correctly.
+
+4. **Integration Architecture**: Work with the DeepChat's presenter pattern, particularly the McpPresenter and LLMProviderPresenter integration.
+
+## Technical Expertise
+
+### MCP SDK Mastery
+- Implement MCP servers using `McpServer` class with proper resource, tool, and prompt registration
+- Handle MCP transport layers (stdio, Streamable HTTP) appropriately
+- Use proper schema validation with Zod for tool inputs
+- Implement resource templates with dynamic parameters and completions
+- Handle MCP protocol messages and lifecycle events correctly
+
+### DeepChat MCP Architecture
+- Understand the McpPresenter's role in managing MCP server connections
+- Work with the LLMProviderPresenter's Agent Loop architecture for tool calling
+- Implement in-memory servers for built-in functionality
+- Handle MCP tool format conversion for different LLM providers
+- Manage MCP server lifecycle and error handling
+
+### Tool Development Patterns
+- Create tools that return appropriate content types (text, resource links)
+- Implement proper error handling and validation
+- Use ResourceLinks for referencing large content without embedding
+- Handle async operations and external API calls in tools
+- Implement proper cleanup and resource management
+
+## Implementation Guidelines
+
+### Code Quality Standards
+- Follow TypeScript strict typing requirements
+- Use proper error handling with meaningful error messages
+- Implement comprehensive input validation using Zod schemas
+- Follow the project's presenter pattern architecture
+- Use English for all logs, comments, and error messages
+
+### MCP Best Practices
+- Register tools with descriptive titles and clear descriptions
+- Use appropriate input schemas with proper validation
+- Handle edge cases and provide fallback behaviors
+- Implement proper resource cleanup and connection management
+- Follow MCP protocol specifications for message handling
+
+### DeepChat Integration
+- Work within the existing EventBus architecture for communication
+- Integrate with the configuration system via ConfigPresenter
+- Handle multi-window/multi-tab scenarios appropriately
+- Ensure compatibility with the LLM provider abstraction layer
+
+## Debugging Approach
+
+1. **Connection Issues**: Check MCP server initialization, transport configuration, and lifecycle management
+2. **Tool Registration**: Verify tool registration in McpPresenter and proper schema definitions
+3. **Protocol Compliance**: Ensure message formats match MCP specification requirements
+4. **Integration Problems**: Debug EventBus communication and presenter interactions
+5. **Performance Issues**: Analyze tool execution times and resource usage patterns
+
+## Quality Assurance
+
+- Validate all MCP implementations against the protocol specification
+- Test tool execution with various input scenarios and edge cases
+- Verify proper error handling and graceful degradation
+- Ensure compatibility with existing DeepChat MCP infrastructure
+- Test integration with different LLM providers through the abstraction layer
+
+When implementing MCP functionality, always consider the broader DeepChat architecture, follow established patterns, and ensure robust error handling. Your implementations should be production-ready, well-documented, and maintainable within the existing codebase structure.
diff --git a/.cursor/rules/development-setup.mdc b/.cursor/rules/development-setup.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..012c8885fdff117380957ddeb49a288bfcf24c1a
--- /dev/null
+++ b/.cursor/rules/development-setup.mdc
@@ -0,0 +1,26 @@
+---
+description:
+globs:
+alwaysApply: true
+---
+# 开发环境设置指南
+- 使用 OxLint 进行代码检查
+- 使用 pnpm 包管理
+- Log和注释使用英文书写
+- Node.js >= 22
+- pnpm >= 9
+
+# install
+`pnpm install`
+
+# lint
+`pnpm run lint`
+
+# format
+`pnpm run format`
+
+# dev
+`pnpm run dev`
+
+# build
+`pnpm run build`
diff --git a/.cursor/rules/electron-best-practices.mdc b/.cursor/rules/electron-best-practices.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..0869f7624dc644662bd73018635cd2daa62ba1be
--- /dev/null
+++ b/.cursor/rules/electron-best-practices.mdc
@@ -0,0 +1,18 @@
+---
+description: Best practices for Electron applications,explain the IPC communication event mechanism between the main and renderer process of this electron project.
+globs: src/main/presenter/**/*.ts,src/renderer/stores/**/*.ts,src/shared/*.d.ts
+alwaysApply: false
+---
+This is an Electron project. The renderer process is mainly used for UI rendering, while the main process is primarily responsible for data and logic processing. The shared/*.d.ts is used to define the types of objects exposed by the main process to the renderer process.
+
+The IPC in the renderer process is implemented in [usePresenter.ts](mdc:src/renderer/src/composables/usePresenter.ts) , allowing direct calls to the presenter-related interfaces exposed by the main process.
+
+[eventbus.ts](mdc:src/main/eventbus.ts) is primarily used for intercommunication between main processes and decouples modules with events.
+
+The IPC messages from the main process to notify the view mainly rely on the EventBus [index.ts](mdc:src/main/presenter/index.ts) to listen for events that need to be notified and then send them to the renderer through the mainWindow.
+
+- Use context isolation for improved security
+- Implement proper inter-process communication (IPC) patterns
+- Use Electron's built-in APIs for file system and native dialogs
+- Optimize application startup time with lazy loading
+- Implement proper error handling and logging for debugging
\ No newline at end of file
diff --git a/.cursor/rules/error-logging.mdc b/.cursor/rules/error-logging.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..04c040e2afa0c4d80dc05d389742f76846f1cb83
--- /dev/null
+++ b/.cursor/rules/error-logging.mdc
@@ -0,0 +1,93 @@
+---
+description:
+globs:
+alwaysApply: false
+---
+# 错误处理和日志指南
+
+## 错误处理规范
+
+1. 错误类型
+- 用户错误:用户输入或操作导致的错误
+- 系统错误:程序运行时的错误
+- 网络错误:API 调用或网络请求错误
+- 业务错误:业务逻辑相关的错误
+
+2. 错误处理原则
+- 始终使用 try-catch 处理可能的错误
+- 提供有意义的错误信息
+- 记录详细的错误日志
+- 优雅降级处理
+
+3. 错误处理示例:
+```typescript
+try {
+ await someOperation()
+} catch (error) {
+ if (error instanceof UserError) {
+ // 处理用户错误
+ showUserFriendlyMessage(error.message)
+ } else if (error instanceof NetworkError) {
+ // 处理网络错误
+ handleNetworkError(error)
+ } else {
+ // 处理未知错误
+ logError(error)
+ showGenericErrorMessage()
+ }
+}
+```
+
+## 日志规范
+
+1. 日志级别
+- ERROR:错误信息
+- WARN:警告信息
+- INFO:一般信息
+- DEBUG:调试信息
+
+2. 日志内容
+- 时间戳
+- 日志级别
+- 错误代码
+- 错误描述
+- 堆栈跟踪(如果适用)
+- 相关上下文信息
+
+3. 日志记录示例:
+```typescript
+import { logger } from '@/utils/logger'
+
+// 错误日志
+logger.error('Failed to save data', {
+ error: error,
+ context: { userId, operation }
+})
+
+// 信息日志
+logger.info('User action completed', {
+ action: 'save',
+ userId,
+ timestamp: new Date()
+})
+```
+
+## 最佳实践
+
+1. 错误处理
+- 不要吞掉错误
+- 提供用户友好的错误信息
+- 实现错误重试机制
+- 使用错误边界捕获渲染错误
+
+2. 日志记录
+- 避免记录敏感信息
+- 使用结构化日志
+- 实现日志轮转
+- 设置适当的日志级别
+
+3. 监控和告警
+- 设置错误监控
+- 配置关键错误告警
+- 定期检查错误日志
+- 分析错误模式
diff --git a/.cursor/rules/i18n.mdc b/.cursor/rules/i18n.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..7236338eb2e121fe829c66c59c3d4808c6849ac4
--- /dev/null
+++ b/.cursor/rules/i18n.mdc
@@ -0,0 +1,74 @@
+---
+description: Internationalization for renderer
+globs: src/renderer/src/**
+alwaysApply: false
+---
+# Internationalization
+i18n:
+ framework: 'vue-i18n'
+ location: 'src/renderer/src/i18n'
+ requirement: 'all user-facing strings must use i18n keys'
+ locales: ['zh-CN','en-US','ko-KR','ru-RU','zh-HK','fr-FR','fa-IR']
+
+# 国际化开发指南
+R
+## 多语言支持
+
+本项目支持多语言,包括:
+- 中文(简体)
+- 英文
+- 日文
+- 韩文
+- 俄文
+- 繁体中文
+- 法文
+- 波斯文(伊朗)
+
+## 技术实现
+
+- 框架:vue-i18n
+- 位置:src/renderer/src/i18n
+- 要求:所有面向用户的字符串必须使用 i18n 键
+
+## 文件结构
+
+- 语言文件位于 `src/renderer/src/i18n/` 目录
+- 每种语言都有独立的 JSON 文件
+- 共享的翻译键值放在 `common.json` 中
+
+## 使用规范
+
+1. 翻译键命名规范:
+- 使用点号分隔的层级结构
+- 使用小写字母
+- 使用有意义的描述性名称
+- 例如:`common.button.submit`
+
+2. 添加新翻译:
+- 在 `common.json` 中添加共享翻译
+- 在语言特定文件中添加特定翻译
+- 保持所有语言文件的键值一致
+
+3. 在代码中使用:
+```typescript
+import { useI18n } from 'vue-i18n'
+
+const { t } = useI18n()
+// 使用翻译
+const message = t('common.button.submit')
+```
+
+4. 动态切换语言:
+```typescript
+const { locale } = useI18n()
+// 切换语言
+locale.value = 'zh-CN'
+```
+
+## 最佳实践
+
+1. 避免硬编码文本
+2. 使用有意义的键名
+3. 保持翻译文件的结构一致
+4. 定期检查未使用的翻译键
+5. 确保所有用户可见的文本都使用翻译系统
diff --git a/.cursor/rules/llm-agent-loop.mdc b/.cursor/rules/llm-agent-loop.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..3380c70794b93d144ab304f307e89198fa5d5e2f
--- /dev/null
+++ b/.cursor/rules/llm-agent-loop.mdc
@@ -0,0 +1,91 @@
+---
+description:
+globs: src/main/presenter/llmProviderPresenter/index.ts,src/main/presenter/llmProviderPresenter/baseProvider.ts
+alwaysApply: false
+---
+# LLM Agent Loop 和 Provider 架构
+
+本文档概述了处理 LLM 流式补全的架构,特别关注涉及工具调用的 Agent 循环。
+
+## 核心原则
+
+1. **关注点分离 (Separation of Concerns):**
+ * `src/main/presenter/llmProviderPresenter/index.ts`: 管理整体 Agent 循环、对话历史、通过 `McpPresenter` 执行工具、并通过 `eventBus` 与前端通信。
+ * `src/main/presenter/llmProviderPresenter/providers/*.ts`: 每个 Provider 文件负责与特定的 LLM API 交互,处理特定于 Provider 的请求/响应格式,转换工具定义,管理原生与非原生工具调用机制(Prompt 包装),并将输出流标准化为通用事件格式。
+
+2. **标准化流事件 (Standardized Stream Events):** Provider 实现 (`coreStream` 方法) 使用标准化接口 `yield` 事件,以将主循环与 Provider 的具体细节解耦。
+
+3. **Provider 中的单次流式传输 (Single-Pass Streaming in Providers):** 每个 Provider 中的核心流式方法 (`coreStream`) 应为对话的每一轮执行*单次*流式 API 请求。它不应包含多轮工具调用的循环逻辑。
+
+## 架构细节
+
+### `llmProviderPresenter/index.ts` (`startStreamCompletion`)
+
+* **Agent 循环:** 包含主要的 `while` 循环,管理对话流程,包括在需要时进行多轮 LLM 调用和工具使用。
+* **状态管理:** 在循环迭代中维护 `conversationMessages` 历史记录。
+* **Provider 交互:** 在每个循环迭代中调用 `provider.coreStream()` 方法。
+* **事件处理:**
+ * 监听由 `coreStream` `yield` 的标准化事件。
+ * 缓冲文本内容 (`currentContent`)。
+ * 处理 `tool_call_start/chunk/end` 事件:
+ * 收集完整的工具调用详细信息(id, name, arguments)。
+ * 调用 `presenter.mcpPresenter.callTool` 执行工具。
+ * 向前端发送带有工具调用状态(`tool_call: 'start' | 'end' | 'error'`)的 `STREAM_EVENTS.RESPONSE` 事件。
+ * 将工具结果格式化为适合*下一次* LLM 调用的消息(例如,角色为 'tool' 或附加到用户消息)。
+ * 设置 `needContinueConversation = true`。
+ * 处理 `reasoning` 事件并通过 `STREAM_EVENTS.RESPONSE` 发送它们。
+ * 处理 `text` 事件并通过 `STREAM_EVENTS.RESPONSE` 发送它们。
+ * 处理 `image_data` 事件并通过 `STREAM_EVENTS.RESPONSE` 发送它们。
+ * 处理 `usage` 事件并聚合它们。
+ * 处理 `stop` 事件:
+ * 如果 `stop_reason: 'tool_use'`,则添加缓冲的助手消息并准备下一次循环迭代。
+ * 否则,添加最终的助手消息并跳出循环。
+* **循环控制:** 使用 `needContinueConversation` 和 `toolCallCount`(与 `MAX_TOOL_CALLS` 比较)来管理循环。
+* **前端通信:** 通过 `eventBus` 发送标准化的 `STREAM_EVENTS`(`RESPONSE`, `END`, `ERROR`)。
+
+### Provider 实现 (`src/main/presenter/llmProviderPresenter/providers/*.ts`)
+
+* **`coreStream(messages, modelId, temperature, maxTokens)` 方法:**
+ * **输入:** 接收当前对话消息(根据 Provider 的需求格式化,可能包含上一轮的工具结果)和生成参数。
+ * **工具处理:**
+ * **原生支持:** 如果 Provider/模型支持原生函数调用,则将 MCP 工具转换为 Provider 的格式 (`convertToProviderTools`) 并包含在 API 请求中。
+ * **无原生支持:** 如果不支持原生 FC,则在进行 API 调用之前使用 Prompt 包装 (`prepareFunctionCallPrompt`) 准备消息。
+ * **API 调用:** 向 LLM Provider 发出*单次*流式 API 调用。
+ * **流处理:** 迭代 Provider 的原生流数据块。
+ * **事件标准化:** 解析特定于 Provider 的数据块,并 `yield` 符合 **标准化流事件接口** 的事件。
+ * 解析文本、思考(`` 或原生)、工具调用(原生或 ``)、使用情况、错误、停止原因和图像数据。
+ * **输出:** 异步 `yield` `StandardizedStreamEvent` 对象。
+* **辅助方法:** 包含特定于 Provider 的辅助函数,如 `formatMessages`, `convertToProviderTools`, `parseFunctionCalls`, `prepareFunctionCallPrompt` 等。
+
+### 标准化流事件接口 (`LLMCoreStreamEvent`)
+
+```typescript
+// 建议定义在例如 src/main/presenter/llmProviderPresenter/streamEvents.ts
+interface LLMCoreStreamEvent {
+ type: 'text' | 'reasoning' | 'tool_call_start' | 'tool_call_chunk' | 'tool_call_end' | 'error' | 'usage' | 'stop' | 'image_data';
+ content?: string; // 用于 type 'text'
+ reasoning_content?: string; // 用于 type 'reasoning'
+ tool_call_id?: string; // 用于 tool_call_* 类型
+ tool_call_name?: string; // 用于 tool_call_start
+ tool_call_arguments_chunk?: string; // 用于 tool_call_chunk (流式参数)
+ tool_call_arguments_complete?: string; // 用于 tool_call_end (可选,如果一次性可用)
+ error_message?: string; // 用于 type 'error'
+ usage?: { // 用于 type 'usage'
+ prompt_tokens: number;
+ completion_tokens: number;
+ total_tokens: number;
+ };
+ stop_reason?: 'tool_use' | 'max_tokens' | 'stop_sequence' | 'error' | 'complete'; // 用于 type 'stop'
+ image_data?: { // 用于 type 'image_data'
+ data: string; // Base64 编码的图像数据
+ mimeType: string;
+ };
+}
+```
+
+## 优点
+
+* **减少代码重复:** Agent 循环逻辑集中在 `index.ts`。
+* **提高可维护性:** Provider 实现更简单,专注于 API 交互和事件标准化。
+* **更容易添加新 Provider:** 添加新 Provider 只需根据标准化接口实现 `coreStream` 方法,无需复制复杂的 Agent 循环。
+* **行为一致性:** 确保工具处理、思考内容解析和事件发送在所有 Provider 之间保持一致。
diff --git a/.cursor/rules/performance.mdc b/.cursor/rules/performance.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..b93c988bf44d93780ddee2ab0c29c4e6514d0977
--- /dev/null
+++ b/.cursor/rules/performance.mdc
@@ -0,0 +1,5 @@
+---
+description:
+globs:
+alwaysApply: false
+---
diff --git a/.cursor/rules/pinia-best-practices.mdc b/.cursor/rules/pinia-best-practices.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..b103aa0dac92250de4e18c4cac7ff29aa2b11a48
--- /dev/null
+++ b/.cursor/rules/pinia-best-practices.mdc
@@ -0,0 +1,10 @@
+---
+description: Best practices for state management with Pinia
+globs: src/renderer/src/stores/**/*.{vue,ts,tsx,js,jsx}
+alwaysApply: false
+---
+- Use modules to organize related state and actions
+- Implement proper state persistence for maintaining data across sessions
+- Use getters for computed state properties
+- Utilize actions for side effects and asynchronous operations
+- Keep the store focused on global state, not component-specific data
\ No newline at end of file
diff --git a/.cursor/rules/project-structure.mdc b/.cursor/rules/project-structure.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..bfcd71ce6ce03b120f516d88602a1f925301c416
--- /dev/null
+++ b/.cursor/rules/project-structure.mdc
@@ -0,0 +1,32 @@
+---
+description:
+globs:
+alwaysApply: false
+---
+# 项目结构指南
+
+本项目是一个基于 Electron + Vue 3 的桌面应用程序。主要目录结构如下:
+
+- `src/`: 源代码目录
+ - `main/`: Electron 主进程代码
+ - `renderer/`: 渲染进程代码(Vue 3 应用)
+ - `shared/`: 主进程和渲染进程共享的类型定义和工具
+
+- `resources/`: 应用程序资源文件
+- `build/`: 构建相关配置
+- `scripts/`: 构建和开发脚本
+- `docs/`: 项目文档
+- `tests/`: 测试文件
+
+主要配置文件:
+- [electron.vite.config.ts](mdc:electron.vite.config.ts): Vite 构建配置
+- [electron-builder.yml](mdc:electron-builder.yml): Electron Builder 配置
+- [tsconfig.json](mdc:tsconfig.json): TypeScript 配置
+- [tailwind.config.js](mdc:tailwind.config.js): Tailwind CSS 配置
+
+开发规范:
+1. 所有新功能应该在 `src` 目录下开发
+2. 共享类型定义放在 `shared` 目录
+3. 主进程代码放在 `src/main`
+4. 渲染进程代码放在 `src/renderer`
+5. 测试文件放在 `tests` 目录
diff --git a/.cursor/rules/provider-guidelines.mdc b/.cursor/rules/provider-guidelines.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..7d8ed9fe19437a59760ca2147041dc3207e13739
--- /dev/null
+++ b/.cursor/rules/provider-guidelines.mdc
@@ -0,0 +1,40 @@
+---
+description: Provider Implementation Guidelines - Strong Typed CoreEvent, Tool Call Sequences, Usage and Rate Limit Specifications
+---
+
+## Provider Implementation Guidelines (Strong Typed)
+
+- Reference message specification: [LLM Agent Message Architecture](mdc:docs/agent/message-architecture.md)
+- Related implementation entry: [llmProviderPresenter](mdc:src/main/presenter/llmProviderPresenter/index.ts)
+
+### Strong Typed Events
+- Only output discriminated union `LLMCoreStreamEvent`, do not use "single interface + optional fields".
+- Use factory methods `createStreamEvent.*` to construct events, avoid field pollution.
+
+### Event Sequence Conventions
+- Text: Multiple `text` chunks emitted in arrival order.
+- Reasoning: `reasoning` is optional; if provided, suggest containing complete chain.
+- Tool calls: Strictly follow `tool_call_start → tool_call_chunk* → tool_call_end`, `tool_call_id` is required and stable.
+- Stop: Emit `stop` at stream end, `stop_reason ∈ { 'tool_use','max_tokens','stop_sequence','error','complete' }`.
+
+### Statistics and Rate Limiting
+- Usage: Send `usage` once before or at end (`prompt_tokens/completion_tokens/total_tokens`).
+- Rate limit: Send `rate_limit` when reaching limit threshold (`providerId/qpsLimit/currentQps/queueLength/estimatedWaitTime?`), do not block event channel.
+
+### Errors
+- Use `error` event uniformly to carry error messages, avoid mixing into other event fields.
+- Once fatal error occurs, emit `stop` as needed and terminate stream.
+
+### Images
+- `image_data` event must provide `data(Base64)` and `mimeType`; control single frame size and frequency to avoid blocking.
+
+### What Not to Do
+- Do not emit `AssistantMessageBlock` or any UI types to UI layer.
+- Do not introduce renderer dependencies inside Provider.
+
+### Quality Thresholds (Self-Check)
+- Every event construction uses factory functions.
+- Tool call IDs are globally unique and stable, chunks arrive strictly in order.
+- Error scenarios have corresponding stop_reason and error message.
+- At least one usage (if provider has statistics capability).
+- Provide rate limit events (if rate limiter is configured).
diff --git a/.cursor/rules/vue-best-practices.mdc b/.cursor/rules/vue-best-practices.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..a3b1cce7ae4529d8d51b9880410f6766c2c9b784
--- /dev/null
+++ b/.cursor/rules/vue-best-practices.mdc
@@ -0,0 +1,10 @@
+---
+description: Best practices for Vue.js applications
+globs: src/renderer/src/**/*.{vue,ts,tsx,js,jsx}
+alwaysApply: false
+---
+- Use the Composition API for better code organization and reusability
+- Implement proper state management with Pinia
+- Utilize Vue Router for navigation and route management
+- Leverage Vue's built-in reactivity system for efficient data handling
+- Use scoped styles to prevent CSS conflicts between components
\ No newline at end of file
diff --git a/.cursor/rules/vue-router-best-practices.mdc b/.cursor/rules/vue-router-best-practices.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..9c490c922080275c477108d47545b0d49602df59
--- /dev/null
+++ b/.cursor/rules/vue-router-best-practices.mdc
@@ -0,0 +1,10 @@
+---
+description: Best practices for Vue Router
+globs: src/renderer/src/router/**/*.{vue,ts,tsx,js,jsx}
+alwaysApply: false
+---
+- Use named routes for easier navigation and maintenance
+- Implement route-level code splitting for better performance
+- Use route meta fields for attaching additional data to routes
+- Implement proper navigation guards for authentication and authorization
+- Use dynamic routing for handling variable route segments
\ No newline at end of file
diff --git a/.cursor/rules/vue-shadcn.mdc b/.cursor/rules/vue-shadcn.mdc
new file mode 100644
index 0000000000000000000000000000000000000000..f48184d58b5949d4532993446e49cedb00310de3
--- /dev/null
+++ b/.cursor/rules/vue-shadcn.mdc
@@ -0,0 +1,79 @@
+---
+description:
+globs: src/renderer/*,src/renderer/**/*,srr/renderer/src/**/*
+alwaysApply: false
+---
+
+ You are an expert in TypeScript, Node.js, NuxtJS, Vue 3, Shadcn Vue, Radix Vue, VueUse, and Tailwind.
+
+ Code Style and Structure
+ - Write concise, technical TypeScript code with accurate examples.
+ - Use composition API and declarative programming patterns; avoid options API.
+ - Prefer iteration and modularization over code duplication.
+ - Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
+ - Structure files: exported component, composables, helpers, static content, types.
+
+ Naming Conventions
+ - Use lowercase with dashes for directories (e.g., components/auth-wizard).
+ - Use PascalCase for component names (e.g., AuthWizard.vue).
+ - Use camelCase for composables (e.g., useAuthState.ts).
+
+ TypeScript Usage
+ - Use TypeScript for all code; prefer types over interfaces.
+ - Avoid enums; use const objects instead.
+ - Use Vue 3 with TypeScript, leveraging defineComponent and PropType.
+
+ Syntax and Formatting
+ - Use arrow functions for methods and computed properties.
+ - Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.
+ - Use template syntax for declarative rendering.
+
+ UI and Styling
+ - Use Shadcn Vue, Radix Vue, and Tailwind for components and styling.
+ - Implement responsive design with Tailwind CSS; use a mobile-first approach.
+
+ Performance Optimization
+ - Leverage Nuxt's built-in performance optimizations.
+ - Use Suspense for asynchronous components.
+ - Implement lazy loading for routes and components.
+ - Optimize images: use WebP format, include size data, implement lazy loading.
+
+ Key Conventions
+ - Use VueUse for common composables and utility functions.
+ - Use Pinia for state management.
+ - Optimize Web Vitals (LCP, CLS, FID).
+ - Utilize Nuxt's auto-imports feature for components and composables.
+
+ Nuxt-specific Guidelines
+ - Follow Nuxt 3 directory structure (e.g., pages/, components/, composables/).
+ - Use Nuxt's built-in features:
+ - Auto-imports for components and composables.
+ - File-based routing in the pages/ directory.
+ - Server routes in the server/ directory.
+ - Leverage Nuxt plugins for global functionality.
+ - Use useFetch and useAsyncData for data fetching.
+ - Implement SEO best practices using Nuxt's useHead and useSeoMeta.
+
+ Vue 3 and Composition API Best Practices
+ - Use
+