基于Tauri构建跨Git Worktree的AI编程助手桌面应用

1. 项目概述：一个桌面应用如何解决多分支AI编程的混乱

如果你和我一样，日常开发工作流重度依赖git worktree来并行处理多个功能分支或Bug修复，同时又热衷于使用各类AI编程助手（比如Cursor、Claude Code、GitHub Copilot Chat，甚至是本地部署的开源模型）来加速编码，那你一定体会过这种“甜蜜的烦恼”。我们经常需要快速切换上下文，在几个不同的工作树（worktree）之间跳转，每个工作树可能对应着不同的项目状态、不同的代码库，甚至不同的AI助手配置。问题来了：你如何高效地管理这些分散在不同工作树中的AI助手会话？当你在feature/login工作树下用Copilot Chat深入讨论了认证逻辑，切换到hotfix/payment-bug时，之前的对话上下文就丢失了，你需要重新向AI解释这个完全不同的代码库和问题背景。这种上下文断裂极大地拖慢了效率。

这个项目的核心，就是构建一个桌面应用程序，旨在成为管理跨git worktree的AI编程代理的“中央控制台”。它不是一个IDE插件，而是一个独立的、常驻系统托盘的应用。它的愿景是：无论你当前在哪个终端、哪个IDE窗口、哪个git worktree目录下工作，这个应用都能感知你的上下文，并为你提供一个统一的、历史记录完整的、可快速切换的AI编程助手交互界面。想象一下，你为每个重要的git worktree都绑定了一个专属的AI代理会话，包含了该分支特定的代码库知识、过往的问题讨论历史。一键切换，无缝衔接，这才是AI赋能编程该有的流畅体验。

这个工具适合任何使用git worktree进行多任务开发的软件工程师、独立开发者或技术负责人。无论你是维护一个大型单体仓库（monorepo）的不同功能，还是在几个不同的客户项目间穿梭，它都能帮你把最宝贵的“与AI的对话上下文”这个资产，从混乱的临时记忆中解放出来，进行结构化、持久化的管理。

2. 核心设计思路：解耦、上下文感知与统一接口

2.1 为什么是桌面应用，而非IDE插件？

这是第一个关键设计决策。市面上大多数AI编程工具都以IDE插件（VS Code、JetBrains全家桶）的形式存在。它们深度集成，体验流畅，但有一个致命缺陷：强绑定于特定的编辑器实例和文件系统路径。当你使用git worktree时，你实际上是在同一个本地仓库的不同路径下工作（例如~/project/.git指向主工作树，而~/project-featureA是一个链接到同一.git文件夹的独立工作树）。IDE插件通常只关注当前打开的文件夹，很难自动、可靠地识别并关联到其他git worktree的路径。

一个独立的桌面应用可以解决这个问题：

1. 系统级监控：它可以常驻后台，通过监听文件系统事件或定期扫描，主动发现并追踪所有从同一仓库根目录衍生出的git worktree列表。
2. 上下文无关的UI：应用窗口或托盘菜单可以独立于任何IDE存在。你可以从系统托盘快速切换当前“焦点工作树”，而无需改变IDE里打开的项目。
3. 统一会话管理：所有与AI的交互都经由这个桌面应用中转。它维护一个会话池，键（Key）是工作树路径，值（Value）是对应的AI对话历史和配置。这样，会话的生命周期就与工作树绑定，而非与某个IDE窗口绑定。

2.2 核心架构：三层解耦模型

为了实现健壮性和可扩展性，我采用了清晰的三层架构：

[表示层 (UI)] <-> [控制层 (Core)] <-> [数据层 & 外部服务]

1. 表示层 (Presentation Layer)：使用跨平台桌面框架（如Tauri或Electron）构建。Tauri是我的首选，因为它用Rust构建后端，前端可以用任何Web技术（React, Vue, Svelte），最终打包的应用体积小、性能高、内存占用少。UI需要提供：

   • 工作树列表视图（显示路径、分支名、是否有活跃AI会话）。
   • 当前活跃工作树的AI聊天主界面。
   • 会话历史管理面板。
   • 全局快捷方式配置（例如，设置一个全局热键唤出AI输入框）。

2. 控制层 (Core Layer)：这是应用的大脑，用Rust（如果选Tauri）或Node.js（如果选Electron）编写。它负责：

   • 工作树发现与管理：调用git worktree list命令解析输出，维护一个内部的工作树状态表。
   • 上下文感知：通过监听当前活动窗口或结合终端pwd命令（需用户授权），自动推断开发者当前正在哪个工作树下编码，并自动切换应用内的“焦点工作树”。
   • AI代理抽象：定义一个统一的AIAgent接口。不同的AI服务（OpenAI API、Anthropic Claude API、本地Ollama、甚至是Cursor的内部协议）都实现这个接口。控制层负责路由用户请求到正确的AI代理实例，并管理会话状态。
   • 会话持久化：将每个工作树的AI对话历史、自定义指令（System Prompt）等序列化存储到本地数据库（如SQLite）或文件中。

3. 数据层 & 外部服务层：

   • 本地存储：使用SQLite存储元数据（工作树信息、会话列表）和结构化数据。对于较长的对话历史，可以考虑用文件存储（如JSONL格式），SQLite中只存索引和摘要。
   • 外部AI服务：通过各AI服务商提供的官方SDK或API进行通信。这里需要妥善处理API密钥的安全存储（使用操作系统的密钥链，如macOS的Keychain、Linux的Secret Service、Windows的Credential Manager）。

2.3 关键技术选型与理由

• 桌面框架：Tauri > Electron

  • 理由：Electron成熟但体积庞大（每个应用打包一个Chromium）。Tauri利用系统Webview，最终二进制文件可以小到几MB，内存占用更低，启动更快。对于这种需要常驻后台、快速响应的工具类应用，性能优势明显。Rust后端也保证了核心逻辑的稳定性和安全性。

• 状态管理：前端使用Zustand或Valtio

  • 理由：应用状态相对复杂（工作树列表、当前会话、AI响应流、设置项）。需要一种轻量级、响应式、易于与Rust后端同步的状态管理方案。Zustand的API简洁，Valtio的Proxy模式很直观，两者都能很好地满足需求。

• 本地数据库：SQLite +diesel或sqlx(Rust)

  • 理由：SQLite无需服务器，单文件，非常适合桌面应用。diesel是一个全功能的ORM，适合复杂查询；sqlx是异步的，编译时检查SQL，更安全。考虑到需要频繁读写会话历史，异步操作可能更有优势，我倾向于sqlx。

• Git操作：直接调用git命令行 vslibgit2绑定

  • 理由：初期为了快速验证，直接使用std::process::Command调用git worktree list --porcelain等命令是最简单的。输出格式稳定，解析容易。后期如果需要对Git有更精细的控制（如监听.git文件变化），可以考虑集成git2-rs这样的Rust绑定库。

注意：安全第一：处理AI API密钥时，绝对不要硬编码在代码中或明文存储在配置文件里。务必使用Tauri或操作系统提供的安全存储API。在代码示例中，也应用占位符代替真实密钥。

3. 核心功能拆解与实现要点

3.1 工作树的自动发现与状态同步

这是应用的基石。不能依赖用户手动添加工作树，必须自动、准确。

实现方案：

1. 定期扫描与增量更新：启动一个后台任务（例如每30秒），对用户配置的“监控根目录”（通常是多个项目仓库的父目录）进行扫描。使用git -C <path> worktree list --porcelain命令。--porcelain格式输出稳定，易于机器解析。

   # 示例输出 worktree /Users/me/project/main HEAD abcdef1234567890 branch refs/heads/main worktree /Users/me/project/feature-login HEAD fedcba0987654321 branch refs/heads/feature/login detached

   解析后，我们可以得到每个工作树的绝对路径、对应的HEAD提交和分支名（如果是分离头状态则标记为detached）。

2. 文件系统监听（优化）：仅靠轮询不够实时。可以集成notify(Rust crate) 库，监听监控根目录下的子目录创建、删除事件。一旦检测到可能的新工作树目录，立即触发一次git worktree list来验证和更新内部状态。

3. 状态维护：在内存和SQLite中维护一张worktrees表。

   CREATE TABLE worktrees ( id INTEGER PRIMARY KEY, path TEXT UNIQUE NOT NULL, git_dir TEXT, -- 关联的.git目录路径 branch_name TEXT, head_commit TEXT, is_detached BOOLEAN, last_active TIMESTAMP, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

   每次扫描后，对比数据库中的记录，进行增删改。last_active字段用于在UI中排序（最近使用的排前面）。

实操心得：

• git worktree list在包含大量工作树或网络路径时可能稍慢。可以考虑首次全量扫描，后续只针对有文件系统事件变动的路径进行增量查询。
• 解析--porcelain输出时，要注意处理边界情况，比如路径中包含空格的情况（输出中已用引号包裹）。
• 对于“游离”的工作树（即其对应的分支在主要仓库中已被删除），git worktree list仍然会列出，但状态可能异常。应用中最好能检测到这种状态并给用户视觉提示。

3.2 上下文的自动感知与切换

应用需要知道开发者“现在正在哪里写代码”，以自动激活对应的AI会话。

实现方案：

1. 基于活动窗口的焦点检测（推荐但需权限）：

   • macOS: 使用AppleScript或Accessibility API获取当前最前端应用的窗口信息，从中提取文件路径（如果应用是Finder、终端或支持的IDE）。
   • Windows: 使用GetForegroundWindow和GetWindowThreadProcessId等Win32 API。
   • Linux: 使用xdotool或wmctrl等命令行工具，或通过DBus接口。
   • Tauri：可以通过编写平台特定的Rust代码，并暴露给前端JavaScript调用。注意：此功能通常需要用户授予辅助功能权限，在应用首次启动时应引导用户开启。

2. 基于终端当前路径的检测（备选方案）：

   • 提供一个小的Shell脚本或函数，让用户添加到他们的Shell配置文件（如.zshrc或.bashrc）中。

   # 示例函数，将当前路径发送给桌面应用 function cda() { cd "$@" # 假设应用提供了一个本地HTTP API或Unix Socket来接收更新 curl -X POST -H "Content-Type: application/json" -d "{\"cwd\": \"$PWD\"}" http://localhost:9977/update-context 2>/dev/null || true }

   • 用户使用cda命令而非cd来切换目录时，应用就能收到更新。这种方法侵入性较强，但实现简单，无需特殊权限。

3. 手动切换（保底）：在应用的托盘菜单或主界面中，始终清晰列出所有已发现的工作树，允许用户一键点击切换“焦点工作树”。

实操心得：

• 自动感知是“锦上添花”，手动切换是“雪中送炭”。必须保证手动切换路径清晰、响应迅速。
• 如果采用活动窗口检测，必须处理好权限申请流程，并提供清晰的说明，告诉用户这个权限仅用于检测当前工作路径，不会记录或上传任何隐私数据。
• 可以结合两种方式：当自动检测失败或未开启时，优雅地回退到手动切换模式，并在UI上给出提示。

3.3 多AI代理的抽象与统一会话管理

用户可能同时使用多个AI服务（例如，用GPT-4处理复杂设计，用Claude写文档，用本地模型处理敏感代码）。应用需要统一管理。

实现方案：

1. 定义抽象接口（以Rust为例）：

   pub trait AiAgent: Send + Sync { // 发送消息并流式接收响应 async fn send_message_streaming( &self, conversation_id: &str, messages: Vec<ChatMessage>, system_prompt: Option<&str>, ) -> Result<Pin<Box<dyn Stream<Item = Result<String, ApiError>> + Send>>, ApiError>; // 获取当前模型列表（用于设置） async fn list_available_models(&self) -> Result<Vec<String>, ApiError>; // 代理的唯一标识符，如 "openai-gpt-4", "claude-3-opus", "local-llama3" fn id(&self) -> &str; } pub struct ChatMessage { pub role: Role, // user, assistant, system pub content: String, }

2. 实现具体代理：为每个支持的AI服务创建一个结构体，实现AiAgenttrait。

   • OpenAIAgent: 使用openai_apicrate，配置api_base,api_key,model。
   • ClaudeAgent: 使用anthropic-rscrate。
   • OllamaAgent: 通过HTTP调用本地Ollama服务的/api/chat端点。
   • CursorAgent(如果可能): 这比较棘手，因为Cursor的通信协议可能未公开。一种思路是模拟其本地WebSocket通信（需逆向工程），更现实的做法是将其视为一个“外部进程”，应用可以触发Cursor的快捷方式并获取焦点，但这超出了统一会话管理的范畴。初期可以暂不支持。

3. 会话管理：

   • 每个工作树 + AI代理类型组合可以定义一个唯一的会话。
   • 会话状态存储在SQLite中：

   CREATE TABLE chat_sessions ( id INTEGER PRIMARY KEY, worktree_id INTEGER NOT NULL, agent_id TEXT NOT NULL, -- 对应 AiAgent::id() system_prompt TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, last_used_at TIMESTAMP, UNIQUE(worktree_id, agent_id), FOREIGN KEY (worktree_id) REFERENCES worktrees(id) ON DELETE CASCADE ); CREATE TABLE chat_messages ( id INTEGER PRIMARY KEY, session_id INTEGER NOT NULL, role TEXT NOT NULL, content TEXT NOT NULL, timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (session_id) REFERENCES chat_sessions(id) ON DELETE CASCADE );

   • 当用户切换到某个工作树，并选择某个AI代理（如GPT-4）时，应用从数据库加载或创建对应的chat_session，并加载其关联的所有chat_messages，还原完整的对话上下文。

实操心得：

• 流式响应至关重要：AI生成代码或长文本时，用户不希望等待全部完成再看到结果。send_message_streaming必须返回一个Stream，前端通过SSE (Server-Sent Events) 或WebSocket实时显示生成内容。Tauri支持从Rust后端向前端发送事件流，非常适合此场景。
• 令牌（Token）计数与限制：在向AI服务发送请求前，最好能估算一下当前会话历史（messages）的令牌数，如果超过模型上下文窗口，需要实现一个简单的“摘要”或“滑动窗口”策略，丢弃最早的一些对话轮次，但保留系统提示和最近的关键对话。可以集成tiktoken-rs(用于OpenAI) 等库进行估算。
• 系统提示（System Prompt）的持久化：允许用户为每个会话设置自定义的系统提示（如“你是一个精通Rust和系统编程的专家，专注于代码安全性和性能”），并随会话保存。这是保持AI在不同工作树下行为符合预期的关键。

4. 桌面应用的具体实现步骤

4.1 使用Tauri搭建项目骨架

首先，确保你的系统已安装Rust和Node.js环境。

# 使用Tauri官方CLI创建项目 npm create tauri-app@latest ai-worktree-manager # 按照提示选择：前端框架（如Vite + React），Rust包管理器（Cargo），项目名称等。 cd ai-worktree-manager

项目结构大致如下：

src-tauri/ ├── Cargo.toml # Rust后端依赖和配置 ├── src/ │ ├── main.rs # 入口点，注册Tauri命令和事件 │ ├── lib.rs # 核心业务逻辑（工作树管理、AI代理等） │ ├── commands.rs # 暴露给前端的Rust函数 │ └── ... src/ ├── main.jsx # 前端入口 ├── App.jsx # 主组件 ├── components/ # React组件 └── ...

4.2 实现后端核心逻辑（Rust）

在src-tauri/src/lib.rs中，逐步构建核心模块。

1. 工作树管理模块 (worktree_manager.rs):

use std::path::PathBuf; use std::process::Command; use serde::{Deserialize, Serialize}; #[derive(Debug, Clone, Serialize, Deserialize)] pub struct WorktreeInfo { pub path: PathBuf, pub branch: Option<String>, // None 表示 detached HEAD pub head_commit: String, pub is_detached: bool, } pub struct WorktreeManager { monitor_root: PathBuf, // 内部状态缓存 } impl WorktreeManager { pub fn new(root: PathBuf) -> Self { /* ... */ } pub fn list_worktrees(&self) -> Result<Vec<WorktreeInfo>, Box<dyn std::error::Error>> { let output = Command::new("git") .args(["-C", self.monitor_root.to_str().unwrap(), "worktree", "list", "--porcelain"]) .output()?; let output_str = String::from_utf8(output.stdout)?; Self::parse_porcelain_output(&output_str) } fn parse_porcelain_output(output: &str) -> Result<Vec<WorktreeInfo>, Box<dyn std::error::Error>> { let mut worktrees = Vec::new(); let mut current = None; for line in output.lines() { if line.starts_with("worktree ") { if let Some(info) = current.take() { worktrees.push(info); } let path = line["worktree ".len()..].trim(); current = Some(WorktreeInfo { path: PathBuf::from(path), branch: None, head_commit: String::new(), is_detached: false, }); } else if line.starts_with("HEAD ") { if let Some(info) = &mut current { info.head_commit = line["HEAD ".len()..].trim().to_string(); } } else if line.starts_with("branch ") { if let Some(info) = &mut current { let branch_full = line["branch ".len()..].trim(); // 将 refs/heads/feature/xxx 转换为 feature/xxx info.branch = branch_full.strip_prefix("refs/heads/").map(|s| s.to_string()); } } else if line == "detached" { if let Some(info) = &mut current { info.is_detached = true; } } } if let Some(info) = current.take() { worktrees.push(info); } Ok(worktrees) } }

2. AI代理抽象与OpenAI实现 (agents/mod.rs,agents/openai.rs):

// src-tauri/src/agents/mod.rs pub mod openai; pub mod claude; pub mod ollama; use async_trait::async_trait; use futures::stream::BoxStream; use serde_json::Value; #[derive(Debug)] pub enum ApiError { Network(String), Api(String), Configuration(String), } #[async_trait] pub trait AiAgent: Send + Sync { async fn send_message( &self, messages: &[ChatMessage], model: &str, ) -> Result<String, ApiError>; // 更高级的流式响应版本 async fn send_message_streaming( &self, messages: &[ChatMessage], model: &str, ) -> Result<BoxStream<'static, Result<String, ApiError>>, ApiError>; fn name(&self) -> &str; } // src-tauri/src/agents/openai.rs use crate::agents::{AiAgent, ApiError, ChatMessage}; use async_openai::{Client, types::{CreateChatCompletionRequest, ChatCompletionRequestMessage, Role as OpenAIRole}}; use futures::stream::StreamExt; use std::pin::Pin; pub struct OpenAIAgent { client: Client, default_model: String, } impl OpenAIAgent { pub fn new(api_key: String, base_url: Option<String>, default_model: String) -> Self { let mut client_builder = Client::new().with_api_key(api_key); if let Some(url) = base_url { client_builder = client_builder.with_base_url(url); } Self { client: client_builder.build(), default_model, } } } #[async_trait] impl AiAgent for OpenAIAgent { async fn send_message_streaming( &self, messages: &[ChatMessage], model: &str, ) -> Result<Pin<Box<dyn futures::Stream<Item = Result<String, ApiError>> + Send>>, ApiError> { let request_messages: Vec<ChatCompletionRequestMessage> = messages.iter().map(|m| { ChatCompletionRequestMessage { role: match m.role { crate::agents::Role::User => OpenAIRole::User, crate::agents::Role::Assistant => OpenAIRole::Assistant, crate::agents::Role::System => OpenAIRole::System, }, content: m.content.clone(), name: None, } }).collect(); let request = CreateChatCompletionRequest { model: model.to_string(), messages: request_messages, stream: Some(true), ..Default::default() }; let stream = self.client.chat().create_stream(request) .await .map_err(|e| ApiError::Network(e.to_string()))?; let mapped_stream = stream.map(|item| { match item { Ok(response) => { // 解析流式响应中的delta content let content = response.choices[0].delta.content.clone().unwrap_or_default(); Ok(content) } Err(e) => Err(ApiError::Api(e.to_string())), } }); Ok(Box::pin(mapped_stream)) } // ... 实现其他trait方法 }

3. 数据库层 (database.rs): 使用sqlx与SQLite交互。定义好Worktree、ChatSession、ChatMessage等结构体，并实现CRUD操作。

4. 前端命令暴露 (commands.rs): 使用Tauri的#[tauri::command]宏将Rust函数暴露给前端JavaScript调用。

#[tauri::command] async fn get_worktrees(app_handle: tauri::AppHandle) -> Result<Vec<WorktreeInfo>, String> { let state: State<AppState> = app_handle.state(); let manager = state.worktree_manager.lock().await; manager.list_worktrees().map_err(|e| e.to_string()) } #[tauri::command] async fn send_ai_message( worktree_path: String, agent_id: String, message: String, app_handle: tauri::AppHandle, ) -> Result<(), String> { // 1. 根据worktree_path和agent_id找到或创建会话 // 2. 加载会话历史 // 3. 调用对应的AiAgent发送消息（流式） // 4. 将用户消息和AI回复存入数据库 // 5. 通过Tauri事件系统向前端实时推送流式响应 Ok(()) }

4.3 构建前端用户界面（React）

前端需要提供几个核心视图：

1. 侧边栏工作树列表：从后端获取get_worktrees并渲染。每个列表项显示分支名、路径缩写，并用不同颜色或图标指示是否有未读消息或是否为当前焦点。
2. 主聊天面板：显示当前活跃会话的消息历史。底部有一个输入框和发送按钮。当收到后端的流式响应事件时，动态更新最后一条AI消息的内容。
3. 会话设置面板：允许用户为当前工作树选择AI代理、配置API密钥（安全存储）、设置系统提示。
4. 系统托盘与全局快捷方式：配置Tauri的system-tray和global-shortcut模块。实现点击托盘图标显示/隐藏主窗口，以及设置一个全局热键（如Cmd+Shift+K）直接唤出主窗口并聚焦到输入框。

关键的前端-后端通信：

• 命令（Commands）：用于主动请求数据，如invoke('get_worktrees')。
• 事件（Events）：用于后端主动推送，如流式响应。在Rust端使用app_handle.emit_all("ai-stream", chunk)，在前端使用import { listen } from '@tauri-apps/api/event';来监听。

4.4 打包与分发

使用npm run tauri build命令，Tauri会为你的目标平台（Windows、macOS、Linux）生成安装包（如.dmg,.msi,.AppImage）。确保在tauri.conf.json中正确配置应用名称、标识符、图标和权限（如文件系统访问、全局快捷键）。

5. 开发中遇到的典型问题与解决方案

5.1 Git命令执行环境与路径问题

问题：在桌面应用环境中调用git命令，可能因为环境变量PATH设置不同，找不到git可执行文件。或者-C参数指定的路径包含特殊字符（如空格、中文）导致解析失败。

解决方案：

1. 使用绝对路径：在Rust中，尝试通过which::which("git")或搜索常见安装路径（如/usr/bin/git,C:\Program Files\Git\bin\git.exe）来定位git二进制文件。
2. 妥善处理路径：将路径传递给git -C前，确保其是绝对路径，并且用引号包裹。在Rust中，使用std::fs::canonicalize获取绝对路径，并在构建命令行参数时注意转义。
3. 提供手动配置：在应用设置中，允许用户手动指定git可执行文件的完整路径，作为备用方案。

5.2 流式响应与前端实时渲染的同步

问题：当AI回复速度很快时，前端频繁更新DOM可能导致界面卡顿。如何平滑地逐字显示流式内容？

解决方案：

1. 使用React状态批处理：不要每收到一个chunk就立即setState。可以设置一个缓冲区，每收到一定数量字符（如20个）或一个短时间间隔（如50毫秒）后，批量更新UI。
2. 虚拟化长消息：如果AI回复的代码块非常长，考虑使用类似react-window的虚拟滚动列表，只渲染可视区域内的内容。
3. 优化Tauri事件传递：避免在Rust端为每一个字符都发送一个事件。可以在Rust端进行简单的缓冲，合并小的chunk后再发送给前端。

5.3 多工作树下AI会话的隔离与性能

问题：用户可能同时打开十几个工作树，每个都创建了AI会话。内存中维护大量会话历史和模型客户端可能导致内存占用过高。

解决方案：

1. 懒加载会话：只在用户切换到某个工作树并点击对应AI代理时，才从数据库加载完整的会话历史到内存。当用户切换到其他工作树时，可以将非活跃会话的历史序列化回数据库，释放内存。
2. 限制历史消息长度：如前所述，实现一个基于令牌数的滑动窗口。在加载历史时，只加载最近N条消息或不超过上下文窗口限制的消息。
3. 提供会话归档功能：允许用户将不常用的会话“归档”，归档后其历史消息从数据库移至压缩的归档文件，进一步减少主数据库压力。

5.4 不同AI服务API的差异处理

问题：OpenAI、Claude、Ollama等服务的API参数、错误响应格式、流式接口细节各不相同。

解决方案：

1. 完善的错误封装：在ApiError枚举中定义清晰的变体（Network,Api,RateLimit,ContextLengthExceeded等）。在每个具体代理的实现中，将服务商特定的错误转换为统一的ApiError。
2. 配置驱动：为每种AI代理设计一个独立的配置结构体，通过UI让用户填写必要的参数（API端点、密钥、默认模型等）。将这些配置安全地存储起来。
3. 统一的流式处理抽象：AiAgenttrait 中的send_message_streaming方法返回一个BoxStream<Result<String, ApiError>>。在每个具体实现中，都需要将服务商特有的流式响应（如OpenAI的SSE、Ollama的JSON行）适配到这个统一的Stream接口。

5.5 系统托盘与全局快捷键的跨平台兼容性

问题：Tauri的系统托盘和全局快捷键API在不同平台（尤其是Linux的各个桌面环境）上行为可能不一致。

解决方案：

1. 功能降级：检测到某些功能不可用时（如某些Linux发行版上全局快捷键注册失败），在UI上明确提示用户，并提供替代方案（如聚焦到托盘图标菜单）。
2. 充分测试：必须在目标平台（至少是Windows、macOS和一个主流Linux发行版如Ubuntu）上进行实际测试。对于Linux，可以考虑提供AppImage或Flatpak包，它们能提供更一致的运行环境。
3. 遵循平台惯例：在macOS上，应用菜单和快捷键应遵循苹果的人机界面指南（例如，关于窗口放在应用菜单下）。在Windows上，托盘图标右键菜单是标准交互。适配这些细节能提升应用的专业感。

6. 进阶功能与未来迭代方向

当核心功能稳定后，可以考虑以下方向增强这个工具：

1. 代码库感知的增强提示（RAG）：集成简单的向量数据库（如lance或chroma），为每个工作树建立其代码库的语义索引。当用户提问时，自动检索相关代码片段，并作为上下文附加到提示词中，让AI的回答更精准。
2. 工作树间的知识迁移：允许用户将某个工作树下与AI讨论得出的设计决策、解决方案摘要，“推送”到另一个相关工作树，促进知识在分支间的流动。
3. 与终端/编辑器深度集成：提供CLI工具或编辑器插件（作为桌面应用的客户端），允许用户直接在终端或编辑器内快速向当前工作树绑定的AI代理提问，而无需切换窗口。
4. 提示词模板库：内置针对常见开发任务（如“代码审查”、“生成单元测试”、“解释复杂函数”）的优化提示词模板，用户可一键应用。
5. 成本与使用统计：对于使用按Token收费的API，应用可以估算每次对话的成本，并提供每日/每周的使用统计和预算提醒。

这个项目的本质，是将AI编程助手从一个被动的、上下文孤立的工具，转变为一个主动的、与你的开发工作流深度集成的智能伙伴。通过将AI会话与git worktree这一物理隔离的编码环境绑定，我们为并行开发任务赋予了持久的、专属的智能上下文。从技术实现上看，它融合了系统编程（Rust）、跨平台桌面开发、Git操作、多种AI服务集成以及数据库设计，是一个非常有挑战性也极具实用价值的全栈项目。