1. 项目概述：为什么我们需要一个AI编程任务的“指挥中心”？

如果你和我一样，深度使用过Claude Code这类AI编程助手，那你一定经历过这种“甜蜜的烦恼”：你兴致勃勃地开始一个项目，让AI帮你规划、拆解任务，它很快给你列出一个包含十几个步骤的详细计划。你开始执行第一个任务，AI在终端里噼里啪啦地写代码，一切看起来都很美好。然后，你的电脑突然需要重启更新，或者你不小心关掉了终端窗口，甚至只是你想从书房的台式机换到客厅的笔记本上继续工作——完了，刚才那个AI会话断了，它执行到哪一步了？它生成了哪些文件？它接下来要做什么？你面对着一堆可能已经修改过的代码文件和一个中断的对话历史，瞬间陷入迷茫。

这就是我构建orchestrAI的初衷。它不是一个简单的“Claude Code网页版”，而是一个 项目管理和任务执行的统一控制面板 。你可以把它想象成给AI编程任务配了一个“Jira”或“Linear”，但这里的“执行者”不是你的同事，而是Claude Code智能体。每个任务都是一个独立的、可追踪的、可交互的AI工作会话，并且最关键的是—— 它与你当前使用的设备、浏览器窗口完全解耦 。

想象一下这个场景：你早上在办公室的电脑上启动了一个需要运行20分钟的代码重构任务。点击“开始”后，你合上笔记本去开会。会议间隙，你掏出手机，打开浏览器，输入内网地址，就能看到那个AI智能体正在一行行地修改代码，实时输出日志。你甚至可以直接在手机浏览器里输入指令，让它暂停、调整方向或回答你的问题。会议结束后，你回到工位，任务刚好完成，系统提示你审查代码差异（Diff）。你仔细看了看AI改动的每一行，确认无误后，点击“合并”，代码就自动合并回了主分支。整个过程中，你不需要一直守着终端，不需要担心会话丢失，更不需要在多个tmux窗口或编辑器标签页之间手忙脚乱地切换。

这背后解决的核心痛点，是当前AI编程工具一个普遍存在的假设： 你永远坐在那台开发机器前 。这个假设在简单任务时没问题，但一旦任务变得复杂、耗时，或者你的工作流需要移动、需要并行监督多个任务时，它就崩溃了。orchestrAI就是要打破这个假设，让AI编程助手变得像云服务一样，随时随地可访问、可管理、可协作（尽管这里的协作者是你和你的AI们）。

2. 核心设计思路：从“聊天界面”到“生产工单系统”

大多数AI编程工具的交互模式，本质上还是一个增强版的聊天机器人。你输入需求，它输出代码和解释。这种模式对于探索性、问答式的工作很友好，但对于一个严谨的、多步骤的软件工程项目来说，就显得过于松散和脆弱。我的目标是将其工程化、系统化。

2.1 以“计划”和“任务”为核心的YAML驱动工作流

首先，我抛弃了让AI在Markdown里自由发挥生成计划的方式。Markdown对人类阅读友好，但对程序解析来说太模糊了。“## 阶段一”和“### 任务1”这样的结构，需要复杂的正则表达式和启发式规则去解析，而且很容易出错。

orchestrAI采用了 YAML作为计划的定义语言 。所有计划都存放在 ~/.claude/plans/ 目录下，每个文件对应一个项目计划。YAML的结构化特性，让计划、阶段、任务、依赖关系、文件路径、验收标准都变得清晰、可编程。

# 示例：一个简单的API端点重构计划
name: "重构用户认证API"
description: "将旧的RESTful认证端点迁移到GraphQL，并增加日志中间件。"
phases:
  - name: "分析与设计"
    tasks:
      - id: "analyze-current-api"
        title: "分析现有REST API结构"
        acceptance_criteria:
          - "生成现有 `/auth/login` 和 `/auth/register` 端点的Swagger文档片段"
          - "识别出与用户模型耦合过紧的逻辑"
        estimated_cost_usd: 0.05
        dependencies: []
        file_paths: ["src/routes/auth.rs", "src/models/user.rs"]
  - name: "GraphQL实现"
    tasks:
      - id: "create-graphql-schema"
        title: "设计并创建GraphQL Schema"
        acceptance_criteria:
          - "在 `src/graphql/schema.graphql` 中定义 `LoginInput`, `AuthPayload`, `Mutation`"
          - "Schema通过GraphQL验证工具检查"
        estimated_cost_usd: 0.10
        dependencies: ["analyze-current-api"]
        file_paths: ["src/graphql/"]

这种结构的好处是巨大的：

1. 清晰性 ：任务层级、依赖关系一目了然。AI智能体知道自己处在哪个计划的哪个任务的上下文中。
2. 可编辑性 ：UI界面可以直接渲染并编辑这个YAML文件，你也可以用任何文本编辑器手动修改。
3. 可自动化 ：系统可以轻松读取任务ID、依赖关系，来自动化调度（比如，依赖任务完成后自动触发下一个任务）。
4. 成本预算 ：每个任务都可以设置预估的美元成本上限，防止AI“跑飞”产生意外账单。

当你在UI中点击“新建计划”并输入一段自然语言描述时，背后其实是一个Claude Code智能体在工作：它将你的模糊需求，翻译成这样一个结构严谨的YAML计划。这本身就是一次“需求工程化”的过程。

2.2 Git分支隔离：每个任务都是一个安全的沙盒

这是orchestrAI保障代码安全的核心机制。传统的AI编码会话直接在你的工作目录里操作，一旦它误操作或产生了你不想要的改动，回退起来可能很麻烦。

在orchestrAI中， 每一个任务启动时，都会自动基于当前分支创建一个新的Git分支 ，命名规则是 orchestrai/<plan_name>/<task_id> 。AI智能体所有的代码修改都发生在这个独立的分支上。你的主分支（main/master）或其他功能分支完全不受影响。

这个设计带来了几个关键优势：

• 零风险实验 ：你可以放心让AI尝试各种激进的代码改动或重构，如果结果不满意，直接丢弃这个分支即可，主分支代码完好无损。
• 清晰的代码审查 ：任务完成后，UI界面会直接展示这个任务分支与基准分支（通常是主分支）的差异（Diff）。你可以像审查同事的Pull Request一样，逐行审视AI的修改，这个上下文非常清晰。
• 原子性合并 ：审查通过后，点击“合并”按钮，系统会执行一个Git合并操作。这比从聊天记录里复制粘贴代码片段要可靠和规范得多。
• 状态可追溯 ：分支本身就是一个持久化的状态记录。即使orchestrAI服务器重启，这个分支以及上面的所有修改都依然存在于你的Git仓库中。

实操心得：分支命名策略 我最初使用简单的任务名作为分支名，但在并行多个计划时容易冲突。现在的 orchestrai/<plan>/<task> 命名空间策略完美解决了这个问题。同时，建议在你的 .gitignore 文件中添加 **/.orchestrai-state.json 这样的条目，以忽略orchestrAI生成的内部状态文件，避免它们被意外提交。

2.3 持久化的终端会话：告别tmux，实现跨平台进程管理

让一个AI会话在后台持久运行，并且能从不同的客户端重新连接，传统方案是使用 tmux 或 screen 。我在第一个原型里就是这么做的。但这就引入了两个问题：1) Windows用户怎么办？2) 要求所有用户额外安装配置tmux，增加了使用门槛。

我的目标是打造一个开箱即用、跨平台的解决方案。因此，我实现了一个约300行Rust代码的“迷你进程监管器”（mini-supervisor）。它的工作原理是这样的：

1. 守护进程化 ：当你在UI点击“开始任务”时，服务器端会使用Rust的 std::process::Command 启动Claude Code进程。关键一步是，通过平台特定的调用（Unix的 fork + setsid ， Windows的 DETACHED_PROCESS 标志），让这个进程脱离当前终端，成为一个独立的守护进程。
2. 伪终端（PTY）管理 ：为了与Claude Code交互（发送指令、接收输出），我们需要一个伪终端。我使用了 portable-pty 这个Rust库，它提供了跨平台的PTY抽象。监管器创建并持有这个PTY的主端（master），而Claude Code进程则连接到从端（slave），就像在一个真实的终端里运行一样。
3. 进程间通信（IPC） ：监管器需要将PTY的输出转发给Web前端（xterm.js），并接收前端的输入。我使用 interprocess 库创建了一个 Unix域套接字（Linux/macOS）或命名管道（Windows） 。监管器作为服务器，监听这个socket/pipe。
4. 日志持久化 ：所有PTY的输出（即Claude Code的所有输出）会同时被镜像写入一个磁盘上的日志文件。这样，即使一个客户端断开连接，当它或新客户端重新连接时，监管器可以首先发送日志文件的内容，让用户看到完整的历史记录，然后再推送实时输出。这实现了“断线重连，上下文不丢”。
5. WebSocket桥接 ：orchestrAI的Rust后端（HTTP服务器）充当了浏览器和监管器之间的桥梁。浏览器通过WebSocket连接到Rust后端，后端再通过上面提到的Unix域套接字/命名管道连接到具体的任务监管器，进行双向数据转发。

这个架构的巧妙之处在于， 负责运行AI的核心进程（监管器+Claude Code）与提供Web UI的HTTP服务器是解耦的 。你可以关掉浏览器，甚至重启orchestrAI的Web服务器，那个在后台写代码的Claude Code进程依然在稳稳地运行。当你重新打开网页，UI会自动重新连接到对应的监管器，恢复终端会话。

3. 核心功能深度解析与实操指南

3.1 仪表盘UI：你的AI任务作战指挥室

启动orchestrAI服务器并打开浏览器后，你会看到一个清晰的功能区划分：

• 左侧导航栏 ：列出所有已加载的计划（ .yaml 文件）。你可以在这里创建新计划、刷新列表。
• 中间主区域 ：显示当前选中计划的详细视图。通常是一个看板（Kanban）视图，列代表阶段（如“待办”、“进行中”、“完成”），卡片代表任务。
• 任务卡片 ：这是交互的核心。每张卡片显示任务标题、状态（待开始、运行中、已完成）、预估/实际成本。关键按钮包括：
  • 开始 ：点击后，触发前述的流程——创建Git分支、启动守护进程、打开终端面板。
  • 检查 ：任务标记完成后，点击此按钮会启动一个 只读的验证智能体 。这个智能体不会修改代码，它会读取当前任务的验收标准（Acceptance Criteria）和代码差异，然后给出“是否真正满足要求”的判断。这避免了“文件生成了就算成功”的虚假完成，增加了交付质量的门槛。
  • 合并 ：仅在任务完成且代码审查后显示。点击后，执行 git merge 操作，将任务分支合并到目标分支。
• 右侧面板/弹窗 ：当点击一个运行中或已完成的任务时，会展开一个面板或弹窗，包含多个标签页：
  • 终端 ：实时交互的xterm.js终端，你可以在这里与Claude Code对话。
  • 差异 ：显示任务分支与目标分支的Git diff，便于代码审查。
  • 详情 ：显示该任务的完整YAML定义，包括描述、验收标准、文件路径等。
  • 成本 ：显示该任务消耗的API费用明细（从Claude Code的输出日志中解析）。

注意事项：成本跟踪的实现原理 orchestrAI的成本跟踪不是猜测，而是 解析Claude Code CLI工具的输出 。Claude Code在执行命令后，通常会在输出中包含类似 [成本：$0.012] 的信息。orchestrAI的后台进程会实时抓取终端输出，通过正则表达式匹配并提取这些成本数据，然后累加并更新到UI和数据库（SQLite）中。这意味着成本数据的准确性依赖于Claude Code CLI本身的输出格式。如果你使用其他AI驱动（如Aider），需要为其编写对应的成本解析逻辑。

3.2 从零开始：部署与运行你的orchestrAI

让我们一步步走一遍安装和首次运行的流程。假设你是在一台Linux/macOS开发机上操作。

步骤1：环境准备 确保你的系统已安装：

• Rust (1.85+) : curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
• Node.js (20+) & pnpm : 建议使用nvm管理Node版本，然后 npm install -g pnpm
• Git : 你的项目目录需要是一个Git仓库（或者让orchestrAI帮你初始化）。
• Claude Code CLI : 已安装并通过 claude auth 完成认证。这是AI能力的引擎。

步骤2：获取代码并构建

# 克隆仓库
git clone https://github.com/cpoder/orchestrAI.git
cd orchestrAI

# 构建前端资源（React应用）
pnpm --filter @orchestrai/web build

# 构建Rust后端服务器
cd server-rs
cargo build --release

构建过程可能会花几分钟。最终，在 target/release/ 目录下会生成一个名为 orchestrai-server （或Windows下的 .exe ）的独立二进制文件，大小约15MB。这个文件包含了前端的所有静态资源（通过 rust-embed 打包），是真正的“单文件部署”。

步骤3：运行服务器

# 在server-rs目录下
./target/release/orchestrai-server

服务器默认会监听 0.0.0.0:3100 。你可以在同一局域网的任何设备（包括手机、平板）的浏览器中访问 http://<你的电脑IP>:3100 。

步骤4：创建你的第一个计划

1. 在浏览器中打开仪表盘。
2. 点击左侧的“New Plan”按钮。
3. 在弹出的对话框中，用自然语言描述你的项目，例如：“帮我创建一个简单的Rust命令行工具，功能是统计当前目录下所有.rs文件的代码行数，并忽略空行和注释。”
4. 点击“生成”。后台会启动一个Claude Code智能体，将你的描述转化为结构化的YAML计划。完成后，计划会出现在左侧列表。
5. 点击该计划，主区域会显示被拆解成的多个任务（如“分析需求”、“创建项目结构”、“实现文件遍历逻辑”、“实现行数统计逻辑”、“编写测试”、“打包发布配置”等）。
6. 点击第一个任务的“开始”按钮，见证魔法发生。

3.3 高级配置与定制

orchestrAI的配置文件通常位于 ~/.config/orchestrAI/config.toml （遵循XDG规范）。你可以在这里进行一些关键定制：

# 服务器配置
[server]
host = "0.0.0.0" # 绑定地址，设为127.0.0.1则仅本地访问
port = 3100
data_dir = "~/.local/share/orchestrAI" # 存放计划文件、日志、SQLite数据库的地方

# Git配置
[git]
default_base_branch = "main" # 任务分支基于哪个分支创建
auto_init = true # 如果当前目录不是Git仓库，是否自动初始化

# 任务执行配置
[execution]
max_concurrent_tasks = 2 # 同时运行的最大任务数，防止资源耗尽
task_timeout_seconds = 7200 # 任务超时时间（2小时），超时后自动终止

# Claude Code驱动配置（示例）
[[drivers]]
name = "claude-code"
command = "claude" # CLI命令名
cost_regex = '\\[成本：\\$([0-9\\.]+)\\]' # 用于解析成本的正则表达式
env = { "ANTHROPIC_API_KEY" = "{{env:ANTHROPIC_API_KEY}}" } # 环境变量传递

关于多AI驱动 ：这是orchestrAI正在开发的核心特性。通过抽象的 AgentDriver trait，系统可以接入不同的AI编码CLI工具。每个驱动负责：

• 如何启动对应的AI进程（命令和参数）。
• 如何解析该工具特有的输出格式（尤其是成本信息）。
• 如何进行身份认证（读取环境变量或配置文件）。 这意味着未来你可以在一个仪表盘里，让任务A使用Claude Code（擅长逻辑），任务B使用Aider（擅长与现有代码库交互），任务C使用Gemini CLI，根据任务特性选择最合适的“工人”。

4. 架构深度剖析：如何实现可靠的后台任务管理

前面提到了用Rust写一个监管器来替代tmux，这里我们深入一下技术细节，这对于想理解其稳定性或进行二次开发的用户很重要。

4.1 进程生命周期管理

监管器（我们称之为 AgentSupervisor ）的核心职责是管理Claude Code子进程的完整生命周期，并维护一个PTY和通信套接字。

// 伪代码，展示核心逻辑
struct AgentSupervisor {
    task_id: String,
    child_process: Child, // 子进程句柄
    pty_master: UnixPty, // PTY主端
    socket_path: PathBuf, // Unix域套接字路径
    log_file: File,       // 输出日志文件
}

impl AgentSupervisor {
    fn spawn(task_config: &TaskConfig) -> Result<Self> {
        // 1. 创建PTY对
        let (pty_master, pty_slave) = portable_pty::unix::openpty(...)?;

        // 2. 准备命令：将PTY从端作为子进程的标准IO
        let mut cmd = Command::new("claude");
        cmd.args(["code", "--task", &task_config.prompt]);
        cmd.stdin(Stdio::from(pty_slave.try_clone()?));
        cmd.stdout(Stdio::from(pty_slave.try_clone()?));
        cmd.stderr(Stdio::from(pty_slave.try_clone()?));

        // 3. 关键：使子进程成为新的进程组首领，脱离终端控制
        #[cfg(unix)]
        unsafe {
            cmd.pre_exec(|| {
                // 调用setsid，使进程脱离原终端，成为新会话的首进程
                libc::setsid();
                Ok(())
            });
        }
        #[cfg(windows)]
        {
            cmd.creation_flags(CREATE_NEW_PROCESS_GROUP | DETACHED_PROCESS);
        }

        // 4. 启动子进程
        let child_process = cmd.spawn()?;

        // 5. 创建Unix域套接字（或Windows命名管道）
        let socket_path = generate_socket_path(&task_config.id);
        let listener = UnixListener::bind(&socket_path)?;

        // 6. 启动一个后台线程，处理socket连接，转发PTY数据
        thread::spawn(move || {
            handle_socket_connections(listener, pty_master, log_file);
        });

        Ok(Self { task_id, child_process, pty_master, socket_path, log_file })
    }
}

这个 spawn 方法完成后，Claude Code进程就在后台独立运行了。监管器的主线程可以退出，但子进程和负责通信的后台线程会继续存在。

4.2 数据流与重连机制

handle_socket_connections 函数是数据流转发的核心：

1. 监听连接 ：在一个循环中接受来自Web后端的连接。
2. 发送历史日志 ：当新客户端连接时，首先读取 log_file 的完整内容，通过WebSocket发送给前端，让用户看到所有过往输出。
3. 双向转发 ：
   • PTY -> 客户端 ：在一个循环中，从 pty_master 非阻塞地读取数据。只要有输出，就立刻通过WebSocket转发给所有已连接的客户端（支持多客户端同时观看）。同时，将这份输出追加写入 log_file 。
   • 客户端 -> PTY ：监听WebSocket传来的用户输入（键盘输入），将其写入 pty_master ，从而传递给Claude Code进程。
4. 心跳与状态维护 ：监管器会定期检查子进程是否存活。如果子进程异常退出，它会通过socket通知所有客户端，并更新任务状态为“失败”。

重连的优雅之处 ：因为通信层（Unix socket）和状态层（子进程PID、日志文件）是持久的，所以Web服务器（ orchestrai-server ）重启后，它只需要重新扫描系统中的这些监管器socket，就能重新建立连接，恢复所有运行中任务的终端会话。用户几乎感知不到服务中断。

4.3 基于SQLite的轻量级状态持久化

orchestrAI使用SQLite来存储任务状态、成本记录、用户偏好等元数据。这比使用文件或内存存储更可靠，能应对服务重启。

-- 简化的表结构
CREATE TABLE tasks (
    id TEXT PRIMARY KEY,
    plan_id TEXT NOT NULL,
    title TEXT NOT NULL,
    status TEXT CHECK(status IN ('pending', 'running', 'done', 'failed')) DEFAULT 'pending',
    branch_name TEXT,
    started_at INTEGER, -- Unix timestamp
    finished_at INTEGER,
    estimated_cost_usd REAL,
    actual_cost_usd REAL DEFAULT 0.0,
    supervisor_pid INTEGER, -- 监管器进程ID，用于健康检查
    socket_path TEXT       -- 监管器socket路径，用于重连
);

Web服务器启动时，会查询数据库中所有 status='running' 的任务，然后尝试连接到对应的 socket_path 。如果连接成功，任务在UI上就恢复为运行状态；如果连接失败（比如监管器进程已崩溃），则标记任务为“失败”。

5. 常见问题、故障排查与性能调优

在实际使用中，你可能会遇到一些问题。以下是我在开发和测试中积累的一些常见问题及其解决方案。

5.1 安装与启动问题

问题1： cargo build 失败，提示 portable-pty 或 interprocess 找不到。

• 原因 ：网络问题或Crates.io索引未更新。
• 解决 ：尝试运行 cargo update 更新索引，然后重试。如果是在国内，考虑配置Cargo镜像源。

问题2：前端构建失败， pnpm 命令报错。

• 原因 ：Node.js版本过低或 pnpm 未正确安装。
• 解决 ：确保Node.js版本≥20。使用 node -v 和 pnpm -v 检查。可以尝试删除 node_modules 和 pnpm-lock.yaml ，然后重新运行 pnpm install 。

问题3：服务器启动成功，但浏览器访问 http://localhost:3100 空白页或连接错误。

• 原因 ：前端资源未正确嵌入或服务器绑定地址不对。
• 解决 ：
  1. 确认执行了 pnpm --filter @orchestrai/web build 。
  2. 检查服务器启动日志，看是否有“Embedded frontend assets”之类的提示。
  3. 如果从其他设备访问，确保服务器绑定在 0.0.0.0 而非 127.0.0.1 ，并检查防火墙是否放行了3100端口。

5.2 任务执行问题

问题4：点击“开始任务”后，终端一直显示“启动中...”，然后超时。

• 原因 ：最常见的原因是Claude Code CLI未正确安装或认证。
• 排查步骤 ：
  1. 在系统终端直接运行 claude --version 和 claude auth status ，确保CLI可用且已登录。
  2. 检查orchestrAI服务器进程的环境变量是否包含了必要的 ANTHROPIC_API_KEY 。有时从桌面环境启动的终端有该变量，但作为系统服务启动时没有。
  3. 查看服务器日志（默认输出到stderr），寻找启动子进程时的错误信息。可以在运行服务器时加上 RUST_LOG=debug 环境变量来获取更详细的日志： RUST_LOG=debug ./target/release/orchestrai-server 。

问题5：任务运行中，终端突然断开连接，但任务状态仍是“运行中”。

• 原因 ：网络波动或浏览器问题导致WebSocket断开。监管器进程和Claude Code子进程很可能还在运行。
• 解决 ：直接刷新浏览器页面即可。orchestrAI的重连机制会自动帮你重新连接到正在运行的终端会话。如果刷新后仍无法连接，可以去服务器日志里查看该任务监管器的socket连接是否有错误。

问题6：AI智能体“卡住”了，长时间没有输出。

• 原因 ：可能是遇到了一个需要长时间运行的命令（如 cargo build ），也可能是Claude Code在“思考”（长时间无流式输出），极少数情况下可能是死锁。
• 应对 ：
  1. 首先，在终端里尝试按 Ctrl+C 发送中断信号。这会被转发给Claude Code进程。
  2. 如果无效，在任务卡片上点击“停止”按钮（如果UI提供了强制停止功能）。
  3. 最后的手段：在服务器上找到该任务的监管器进程PID（可以从数据库或日志中查），用 kill <PID> 命令终止它。任务状态会更新为“失败”。

5.3 Git与代码合并问题

问题7：任务启动失败，提示“Not a git repository”。

• 原因 ：你当前的工作目录不是一个Git仓库根目录。
• 解决 ：确保在Git仓库内启动orchestrAI服务器。或者，在配置文件中将 auto_init 设为 true ，orchestrAI会尝试自动执行 git init 。

问题8：合并代码时发生冲突。

• 原因 ：在AI执行任务期间，主分支（或其他基准分支）发生了更改，导致任务分支无法自动合并。
• 解决 ：orchestrAI的UI会显示合并冲突的错误。此时你需要：
  1. 在本地用Git命令行切换到主分支并拉取最新更改： git checkout main && git pull 。
  2. 切换到任务分支： git checkout orchestrai/plan-name/task-id 。
  3. 尝试变基或合并主分支，手动解决冲突： git rebase main （或 git merge main ）。
  4. 解决冲突后，你可以选择在命令行完成合并，或者在orchestrAI UI上重试合并（如果冲突已解决）。

问题9：AI生成的代码质量不高，不符合验收标准。

• 原因 ：提示词（Prompt）不够精确，或者验收标准写得太模糊。
• 优化建议 ：
  1. 细化验收标准 ：在YAML计划中，将“实现用户登录功能”这样的模糊标准，改为“POST /api/login 接口应接收JSON格式的 {email, password} ，验证成功后返回 {token, user_id} ，并设置HttpOnly的cookie”。
  2. 利用“检查”功能 ：不要完全依赖AI的“完成”报告。任务结束后，务必点击“检查”按钮，让另一个AI智能体以“审阅者”身份，严格对照验收标准检查代码。这个二次确认能极大提高交付质量。
  3. 迭代任务 ：如果结果不满意，不要直接修改主分支。可以在UI上基于这个任务创建一个新的子任务，描述需要改进的具体点，让AI继续迭代。

5.4 性能与资源调优

问题10：同时运行多个AI任务时，机器负载很高，速度变慢。

• 原因 ：Claude Code（尤其是大模型调用）和代码编译（如Cargo）都是CPU/内存密集型操作。
• 调优 ：
  1. 限制并发数 ：在配置文件中降低 max_concurrent_tasks （例如设为1），避免资源争抢。
  2. 优化任务粒度 ：将大任务拆分成更小、更独立的子任务。这样不仅易于管理，也能让任务更快完成，释放资源。
  3. 监控资源 ：使用 htop 或系统监控工具，观察是CPU、内存还是磁盘I/O成为瓶颈。如果是内存不足，考虑增加Swap空间或升级硬件。

问题11：长时间运行后，磁盘空间被日志文件占满。

• 原因 ：每个任务的PTY输出日志默认都会保存。
• 管理 ：
  1. 定期清理：日志文件位于 ~/.local/share/orchestrAI/logs/ （或配置的 data_dir 下）。可以设置一个cron任务定期删除超过一定天数的日志。
  2. 配置日志轮转：未来版本计划集成 logrotate 功能。目前可以手动编写脚本实现。

问题12：如何备份我的计划（YAML文件）和任务状态？

• 计划文件 ：它们就在 ~/.claude/plans/ 目录下，是纯文本YAML。直接用Git管理这个目录，或者用任何文件同步工具备份即可。
• 任务状态 ：存储在SQLite数据库文件（通常在 data_dir 内）。你可以定期使用 .dump 命令备份数据库。更简单的方法是，orchestrAI的设计理念是“任务状态是暂时的，代码状态（Git分支）是永久的”。即使数据库丢失，你所有的代码成果依然安全地存在于Git分支中。重启服务器后，你可以根据Git分支手动重新创建任务状态。

6. 未来展望与社区共建

orchestrAI目前已经解决了我个人管理AI编程任务的核心痛点，但它远未完成。开源的力量在于社区，我构想的几个关键发展方向，也欢迎任何有兴趣的开发者一起参与。

方向一：真正的多AI驱动与混合编排 当前的“多AI驱动”抽象已经搭好了架子。下一步是丰富驱动生态。想象一下这样的场景：你有一个“代码生成”任务，你指派给Claude Code；同时有一个“代码审查”任务，你指派给DeepSeek-Coder；还有一个“编写单元测试”的任务，你指派给本地部署的CodeLlama。orchestrAI可以成为这个“AI团队”的调度员。这需要社区共同为不同的AI编码工具（Aider, Codex CLI, Cursor API, 通义灵码CLI等）贡献驱动实现。每个驱动可能只有一两百行代码，定义好如何启动、如何交互、如何解析成本即可。

方向二：深度集成Model Context Protocol MCP是Claude推出的一种标准协议，旨在让AI智能体能够更结构化、更安全地访问外部工具和数据。目前orchestrAI与智能体的通信还比较“原始”（比如通过解析终端输出来更新状态）。集成MCP后，orchestrAI可以作为一个MCP服务器暴露给每个运行的智能体。

智能体可以直接通过MCP工具调用来：

• update_task_status("done") 报告任务完成。
• get_task_context() 获取任务的完整描述、验收标准和相关文件列表。
• log_progress("已完成模块A的编写") 发送结构化的进度更新，而不仅仅是终端文本流。 这将使状态同步更可靠，交互更语义化，也为实现更复杂的自动化工作流（如任务完成自动触发下一个任务）打下基础。

方向三：面向团队的SaaS与自托管混合模式 目前orchestrAI是纯本地工具。但对于小团队来说，可能希望有一个统一的仪表盘来查看所有成员的AI任务进度。我设想了一种混合架构：

1. 轻量级本地代理 ：每个开发者在自己的机器上运行一个 orchestrai-agent-runner 二进制。它负责在本地安全地执行AI任务（代码和凭证不出本地）。
2. 中心化SaaS仪表盘 ：团队使用一个托管的orchestrAI网站。开发者本地的 agent-runner 通过认证的WebSocket连接到这个SaaS。
3. 任务分发与同步 ：你在SaaS网页上创建计划、启动任务。指令通过WebSocket下发到你本地的 agent-runner ，由它实际执行。终端输出、状态更新再通过WebSocket同步回SaaS仪表盘。这样，团队领导可以在一个统一的看板上看到所有成员AI辅助开发的进度，而无需共享代码或API密钥。

这个模式的关键是可靠性，特别是网络中断的处理。我计划采用“发件箱模式”（Outbox Pattern）：本地 agent-runner 将所有要发送的状态更新先持久化到本地数据库，然后尝试发送；SaaS确认收到后，本地才删除记录。这样即使断网，恢复后也能同步所有状态。

给尝试者的最后建议 如果你是一个重度AI编程工具使用者，并且感到在管理复杂、多步骤任务时有些力不从心，我强烈建议你尝试一下orchestrAI。它带来的最大改变，是 将一次性的、线性的AI对话，转变为了一个可暂停、可恢复、可审查、可并行的项目工作流 。

从最简单的单任务开始，感受一下在手机上看AI写代码的奇妙体验。然后尝试为一个中等规模的功能（比如“为我的项目添加一个配置管理模块”）创建一个完整的YAML计划，并让AI逐个任务执行。你会开始以一种全新的、更工程化的视角来思考如何与AI协作。

项目完全开源在GitHub上，文档、Issue模板和讨论区都已就绪。如果你在使用的过程中有任何问题、建议，或者发现了bug，请不要犹豫，直接提交Issue或参与讨论。如果你对Rust、前端（React）或AI工程化感兴趣，也欢迎查看代码，提交Pull Request。这个工具的价值，最终将由我们所有使用者共同塑造。