Zed 1.3 Terminal Threads 深度实战：当终端遇上 AI 代理——编辑器工作流的范式革命（2026 完全指南）

引言：终端的重生时刻

2026 年 5 月，Zed 编辑器发布 1.3 版本，带来了一个看似简单却极具深意的功能——Terminal Threads（终端线程）。乍一看，不过是把终端放进了侧边栏。但当你真正理解它背后的设计哲学，就会发现这不仅仅是 UI 的调整，而是一次对开发者工作流的重新思考。

为什么这么说？因为 AI 编码代理正在改变我们写代码的方式。Claude Code、Amp、Codex CLI——这些工具都运行在终端里，而传统编辑器的终端面板从来不是为并行代理管理而设计的。你在左边跑 Claude Code，中间跑 Cursor，右边还有个 Amp——不停切换窗口，看不到进度，任务阻塞主工作区……这是 2026 年每个开发者的日常痛点。

Terminal Threads 的核心洞察是：终端会话应该是一等公民，和 AI Agent 线程享有相同的管理能力。它不是终端标签页的变体，而是把终端代理化——每个终端是一个可追踪、可管理、可通知的线程实体。

本文将深入剖析 Terminal Threads 的架构设计、实战用法、性能优化，以及它对 AI 时代开发工作流的深远影响。

一、背景：AI 代理时代的终端困境

1.1 从单任务到多代理并行

2024 年，AI 编码助手还只是"补全工具"——你写代码，它给你建议。到了 2025 年，Agent 模式出现，AI 可以自主执行多步任务：读代码、改代码、跑测试、提交 PR。而 2026 年，多代理并行成为主流——你同时让 Claude Code 重构模块 A，让 Amp 写模块 B 的单元测试，让 Codex CLI 生成 API 文档。

问题来了：这些代理都在终端里运行，而终端从来不是为并行任务管理设计的。

传统终端面板的痛点：

• 上下文丢失：切换标签页后，之前的输出可能已经滚走
• 状态不可见：长任务运行时，你无法一眼看到每个任务的状态
• 通知缺失：代理需要你输入时，你可能在另一个窗口，根本看不到
• 资源争抢：多个代理共享一个终端面板，输出混在一起，难以区分

1.2 Zed 的解法思路

Zed 团队在 2026 年 4 月发布了 Parallel Agents 功能，允许 Zed 内置代理和 ACP（Agent Client Protocol）连接的外部代理在侧边栏并行运行。但很多开发者更习惯在终端里使用代理——Claude Code、Amp CLI 等都没有 ACP 集成。

Terminal Threads 的设计目标很明确：让终端代理和 Zed 原生代理享受同等的管理体验，同时保持终端工作流的灵活性。

二、核心概念：Terminal Threads 的设计哲学

2.1 什么是 Terminal Thread？

Terminal Thread 是一个运行在 Zed Agent Panel 中的终端会话，它被当作一个"线程"来管理。这里的"线程"不是操作系统的线程，而是一个逻辑概念——每个终端线程有自己的生命周期、状态和通知机制。

Agent Panel
├── Thread Sidebar
│   ├── [Agent] Refactor auth module    ← Zed 内置代理
│   ├── [Terminal] claude-code          ← Terminal Thread (Claude Code)
│   ├── [ACP] codex-assistant           ← ACP 连接的代理
│   ├── [Terminal] amp-cli              ← Terminal Thread (Amp)
│   └── [Terminal] cargo test           ← Terminal Thread (普通任务)
└── Panel Body
    └── (当前选中线程的内容)

关键设计决策：

1. 统一管理：终端线程和 Agent 线程在同一个侧边栏，用相同的键盘快捷键导航
2. 项目作用域：每个终端线程绑定到当前项目和工作树，不会跨项目污染
3. 自动命名：终端标题自动反映正在运行的进程名，一眼区分不同线程
4. 通知集成：进程需要用户输入时，Zed 会发出通知（而非静默等待）

2.2 与传统终端面板的区别

2.3 ACP vs Terminal Threads：不是替代，是互补

一个常见的误解是 Terminal Threads 会取代 ACP。实际上，两者解决的是不同层次的问题：

• ACP（Agent Client Protocol）：深度集成。代理通过 ACP 可以访问 Zed 的编辑上下文、代码审查工作流、文件操作等。这是最紧密的集成方式，但需要代理实现 ACP 协议。
• Terminal Threads：广度覆盖。任何运行在终端里的程序都能用，零改造成本。但只能获得终端级别的交互，无法深入 Zed 的编辑能力。

Zed 团队明确表示：ACP 的投入不会减少，Terminal Threads 只是给开发者多一个选择。这种务实态度值得称道——在 AI 代理生态快速演进的当下，强迫所有代理走同一个协议是不现实的。

三、架构深度解析

3.1 整体架构

Terminal Threads 的实现建立在 Zed 已有的三个核心子系统之上：

┌──────────────────────────────────────────────┐
│                  Zed Main Window              │
│  ┌──────────────────────────────────────────┐ │
│  │            Editor Area                    │ │
│  │  ┌─────────┐  ┌─────────────────────────┐│ │
│  │  │  Code   │  │     Agent Panel          ││ │
│  │  │  Editor │  │  ┌───────────────────┐   ││ │
│  │  │         │  │  │  Thread Sidebar   │   ││ │
│  │  │         │  │  │  ├─ Agent Thread  │   ││ │
│  │  │         │  │  │  ├─ Term Thread   │   ││ │
│  │  │         │  │  │  └─ ACP Thread    │   ││ │
│  │  │         │  │  ├───────────────────┤   ││ │
│  │  │         │  │  │  Panel Body       │   ││ │
│  │  │         │  │  │  (Terminal/Chat)  │   ││ │
│  │  │         │  │  └───────────────────┘   ││ │
│  │  └─────────┘  └─────────────────────────┘│ │
│  └──────────────────────────────────────────┘ │
│                  GPUI Renderer                 │
└──────────────────────────────────────────────┘

核心组件：

1. ThreadManager：统一管理所有线程（Agent/Terminal/ACP），负责创建、销毁、切换
2. TerminalProcess：封装 PTY（伪终端）进程，处理 I/O 和信号
3. ThreadSidebar：渲染线程列表，处理用户交互
4. NotificationManager：监听进程状态变化，触发通知

3.2 PTY 管理与进程生命周期

Terminal Threads 的底层是 PTY 管理。Zed 使用 Rust 的 portable-pty crate 来创建伪终端会话：

// 简化的 Terminal Thread 创建流程
use portable_pty::{native_pty_system, PtySize, CommandBuilder};

pub struct TerminalThread {
    id: ThreadId,
    project_root: PathBuf,
    worktree: WorktreeId,
    pty: Box<dyn MasterPty + Send>,
    process: Box<dyn ChildProcess + Send>,
    reader: Box<dyn Read + Send>,
    title: String,
    state: ThreadState,
}

impl TerminalThread {
    pub fn spawn(
        project_root: PathBuf,
        worktree: WorktreeId,
        shell: Option<String>,
    ) -> Result<Self> {
        let pty_system = native_pty_system();
        
        // 创建 PTY，设置终端大小
        let pair = pty_system.openpty(PtySize {
            rows: 24,
            cols: 80,
            pixel_width: 0,
            pixel_height: 0,
        })?;
        
        // 构建 shell 命令
        let cmd = if let Some(shell) = shell {
            CommandBuilder::new(shell)
        } else {
            CommandBuilder::new_default_shell()
        };
        cmd.cwd(&project_root);
        
        // 启动子进程
        let child = pair.slave.spawn_command(cmd)?;
        
        Ok(Self {
            id: ThreadId::new(),
            project_root,
            worktree,
            pty: pair.master,
            process: child,
            reader: pair.master.try_clone_reader()?,
            title: String::from("Terminal"),
            state: ThreadState::Running,
        })
    }
    
    /// 从 PTY 读取输出，解析 BEL 信号用于通知
    pub async fn read_output(&mut self) -> Result<TerminalOutput> {
        let mut buf = [0u8; 8192];
        let n = self.reader.read(&mut buf)?;
        let output = String::from_utf8_lossy(&buf[..n]);
        
        // 检测 BEL 字符 (0x07)，用于通知
        if output.contains('\x07') {
            self.state = ThreadState::WaitingForInput;
        }
        
        Ok(TerminalOutput {
            content: output.to_string(),
            needs_attention: self.state == ThreadState::WaitingForInput,
        })
    }
}

关键设计点：

• 项目作用域隔离：每个 Terminal Thread 的 cwd 绑定到项目根目录，不同项目的线程互不干扰
• BEL 信号检测：当代理（如 Claude Code）输出 BEL（\x07）时，Zed 捕获这个信号并触发通知。这是终端工具与 GUI 交互的经典方式
• 异步 I/O：使用 async 读取 PTY 输出，避免阻塞 Zed 主线程

3.3 线程状态机

每个 Terminal Thread 有明确的状态转换：

┌─────────┐  spawn   ┌─────────┐  BEL/EOF  ┌──────────────┐
│  Idle   │─────────▶│ Running │──────────▶│NeedsAttention│
└─────────┘          └────┬────┘           └──────┬───────┘
                          │                       │
                          │  user close           │  user focus
                          ▼                       ▼
                    ┌──────────┐           ┌─────────┐
                    │ Closed   │           │ Running │
                    └──────────┘           └─────────┘

3.4 GPUI 渲染：为什么 Zed 能做到毫秒级响应

Zed 使用自研的 GPUI 框架渲染界面，这是它区别于 Electron 类编辑器的核心优势。Terminal Threads 的渲染同样受益于此：

// GPUI 中 Terminal Thread 的渲染（简化）
impl Render for TerminalThreadView {
    fn render(&mut self, cx: &mut ViewContext<Self>) -> impl IntoElement {
        div()
            .size_full()
            .flex()
            .flex_col()
            .child(
                // 终端内容区域 - 使用 GPUI 原生渲染
                div()
                    .flex_grow()
                    .child(
                        TerminalView::new(self.terminal.clone())
                            .font_family("Zed Plex Mono")
                            .font_size(13.0)
                    )
            )
            .child(
                // 底部状态栏
                div()
                    .h(px(28.0))
                    .flex()
                    .items_center()
                    .px(px(8.0))
                    .child(
                        Icon::new(Self::state_icon(&self.state))
                            .text_color(Self::state_color(&self.state))
                    )
                    .child(
                        Label::new(self.title.clone())
                            .size(LabelSize::Small)
                    )
            )
    }
}

GPUI 的优势在于：

• GPU 加速：所有 UI 元素通过 GPU 渲染，60fps 丝滑
• 零拷贝文本渲染：终端输出直接映射到 GPU 纹理，无需 CPU 到 GPU 的数据搬运
• 细粒度更新：只重绘变化的部分，而非整个终端缓冲区
• 低延迟输入：键盘事件直接到达 PTY，无需经过 Electron 的 IPC 层

对比数据：

四、实战：从零配置 Terminal Threads 工作流

4.1 基础配置

安装最新版 Zed：

# macOS
brew install --cask zed

# Linux
curl -f https://zed.dev/install.sh | sh

# 或直接下载
# https://zed.dev/download

确认版本 >= 1.3：

zed --version
# Zed 1.3.x

4.2 创建第一个 Terminal Thread

1. 打开 Zed，进入任意项目
2. 点击右侧 Agent Panel 的 + 图标
3. 选择 "Terminal"
4. 一个新的终端线程出现在侧边栏

或者用命令面板：

Cmd+Shift+P → "agent panel: new terminal thread"

4.3 运行 Claude Code 作为 Terminal Thread

这是最核心的使用场景。在 Anthropic 宣布从 2026 年 6 月 15 日起，Agent SDK 使用将转入独立的限额信用系统后，通过 ACP 运行 Claude Code 的成本暴增 15-30 倍。Terminal Threads 成为在 Zed 中继续使用 Claude Code 订阅的唯一方式。

# 在 Terminal Thread 中启动 Claude Code
claude

# Claude Code 启动后，侧边栏标题自动变为 "claude-code"
# 当 Claude Code 需要你确认操作时，会输出 BEL 信号
# Zed 捕获后发送桌面通知

配置 Claude Code 的通知（重要）：

// ~/.claude/settings.json
{
  "notifications": {
    "enabled": true,
    "sound": true,
    "bellOnWait": true
  }
}

4.4 运行 Amp CLI

Amp 是另一个流行的 AI 代理，最近发布了全新的 CLI 体验（Amp Neo）。它没有 ACP 集成，但通过 Terminal Threads 可以完美管理：

# 启动 Amp，启用 BEL 通知
AMP_FORCE_BEL=1 amp

# 侧边栏标题变为 "amp-cli"
# Amp 完成任务时触发 Zed 通知

设置环境变量让 Amp 每次都启用通知：

// ~/.zshrc 或 ~/.bashrc
export AMP_FORCE_BEL=1

4.5 混合使用多种代理

Terminal Threads 最强大的地方在于混合管理：

Thread Sidebar:
├── 🔵 [Agent] 生成用户模块 API 文档     ← Zed 内置代理
├── 🟢 [Term] claude-code              ← 重构认证模块
├── 🔵 [ACP]  codex-assistant           ← 代码审查
├── 🟢 [Term] amp-cli                  ← 编写测试用例
└── ⚪ [Term] cargo test --watch        ← 长时间运行的测试监视

用键盘快捷键快速切换：

4.6 高级用法：自定义 Shell 和环境

Terminal Thread 继承项目的 shell 配置，但你也可以自定义：

// ~/.config/zed/settings.json
{
  "terminal": {
    "shell": {
      "program": "/bin/zsh",
      "args": ["-l"]
    },
    "env": {
      "CLAUDE_CODE_ENABLED": "1",
      "AMP_FORCE_BEL": "1",
      "EDITOR": "zed --wait"
    },
    "font_size": 13,
    "font_family": "Zed Plex Mono",
    "line_height": "comfortable"
  }
}

4.7 实战场景：并行处理代码审查

这是一个真实的多代理并行工作流：

1. 打开项目，启动 Agent Panel
2. Terminal Thread 1：运行 claude — 让 Claude Code 审查核心模块的代码质量
3. Terminal Thread 2：运行 amp — 让 Amp 生成缺失的单元测试
4. Agent Thread：用 Zed 内置代理检查依赖安全漏洞
5. Terminal Thread 3：运行 cargo clippy --fix — 自动修复 lint 警告

四个任务并行，你在编辑器中继续写代码。每当有代理需要确认或完成任务，Zed 发出通知。你切换到对应线程查看结果，确认操作，然后切回编辑器继续工作。

这种工作流的关键不是"同时做四件事"，而是让你在等待代理完成时不必盯住终端——通知机制让你真正解放注意力。

五、性能优化深度剖析

5.1 终端渲染性能

终端渲染是性能瓶颈之一，特别是 AI 代理可能输出大量文本。Zed 采用了多层优化策略：

策略一：增量渲染

Zed 不会每帧重绘整个终端缓冲区。它追踪脏区域（dirty region），只更新变化的部分：

// 简化的增量渲染逻辑
struct TerminalRenderer {
    last_rendered_line: usize,
    dirty_lines: Range<usize>,
}

impl TerminalRenderer {
    fn render(&mut self, buffer: &TerminalBuffer, cx: &mut RenderContext) {
        // 只渲染脏行
        for line in self.dirty_lines.clone() {
            self.render_line(buffer, line, cx);
        }
        self.dirty_lines = 0..0; // 清除脏标记
    }
    
    fn mark_dirty(&mut self, range: Range<usize>) {
        // 合并脏区域
        if self.dirty_lines.is_empty() {
            self.dirty_lines = range;
        } else {
            self.dirty_lines = 
                min(self.dirty_lines.start, range.start)..max(self.dirty_lines.end, range.end);
        }
    }
}

策略二：GPU 纹理缓存

终端字符的渲染结果缓存在 GPU 纹理中，避免重复光栅化：

┌────────────────────────────────┐
│   GPU Texture Atlas            │
│  ┌───┬───┬───┬───┬───┬───┐   │
│  │ a │ b │ c │ 1 │ 2 │ { │   │
│  ├───┼───┼───┼───┼───┼───┤   │
│  │ } │ ( │ ) │ ; │   │ \ │   │
│  └───┴───┴───┴───┴───┴───┘   │
│                                │
│  渲染时：从纹理图集取字符拼装   │
│  无需每帧重新光栅化            │
└────────────────────────────────┘

策略三：输出限流

AI 代理可能短时间内输出大量文本。Zed 对终端输出做了智能限流：

const MAX_OUTPUT_PER_FRAME: usize = 64 * 1024; // 64KB/帧

fn process_terminal_output(output: &mut Vec<u8>, terminal: &mut TerminalBuffer) {
    let chunk: Vec<u8> = output.drain(..min(output.len(), MAX_OUTPUT_PER_FRAME)).collect();
    terminal.write(&chunk);
    // 剩余输出留在缓冲区，下一帧处理
}

5.2 内存优化

多个 Terminal Thread 同时运行时，内存管理至关重要：

// 终端缓冲区使用环形缓冲区，限制内存使用
const MAX_SCROLLBACK_LINES: usize = 10_000;

struct TerminalBuffer {
    lines: VecDeque<TermLine>,
    max_lines: usize,
}

impl TerminalBuffer {
    fn push_line(&mut self, line: TermLine) {
        if self.lines.len() >= self.max_lines {
            self.lines.pop_front(); // 丢弃最老的行
        }
        self.lines.push_back(line);
    }
}

内存对比（10 个终端线程，每个 10000 行回滚缓冲）：

Zed 的内存效率主要来自：

• Rust 的零成本抽象，无 GC 开销
• 环形缓冲区避免无限增长
• GPU 纹理共享（字符图集），而非每个终端独立光栅化

5.3 进程管理优化

Zed 对 Terminal Thread 的进程管理做了细致优化：

自动清理：当 Zed 关闭项目窗口时，所有属于该项目的 Terminal Thread 进程会被优雅终止（先 SIGTERM，3 秒后 SIGKILL）。

僵尸进程防护：即使 Zed 崩溃，也会通过 atexit 和信号处理确保子进程被回收。

CPU 限制：后台终端进程如果 CPU 使用率持续超过阈值，Zed 会发出警告：

// settings.json
{
  "terminal": {
    "background_process_warning": {
      "cpu_threshold_percent": 80,
      "duration_seconds": 30
    }
  }
}

六、Terminal Threads 与 AI 编码工作流的未来

6.1 Anthropic 订阅变更的影响

2026 年 6 月 15 日起，Anthropic 将 Agent SDK 使用从订阅中拆分，改为独立限额信用系统。这意味着：

• 通过 ACP 运行 Claude Code：消耗 Agent SDK 额度，成本可能增加 15-30 倍
• 通过 Terminal Thread 运行 Claude Code：仍消耗 Claude 订阅额度，成本不变

这不是一个小变化。对于重度 Claude Code 用户，Terminal Threads 可能意味着每月节省数百美元。这也是为什么 Zed 在这个时间点推出 Terminal Threads——它不仅仅是一个便利功能，更是成本敏感的刚需。

6.2 终端代理生态的碎片化

当前 AI 编码代理生态正在快速碎片化：

• Claude Code：Anthropic 的终端代理，基于 Agent SDK
• Amp：Sourcegraph 的代理，全新 CLI 体验
• Codex CLI：OpenAI 的开源终端代理
• Pi：Inflection 的终端助手
• Aider：开源的终端 AI 编程助手

每个代理都有自己的协议和交互方式，ACP 只覆盖了其中一部分。Terminal Threads 的价值在于：它不要求代理做任何适配，任何终端程序开箱即用。

这让人想起 Unix 哲学——不追求统一协议，而是提供通用的管道机制。Terminal Threads 就是 AI 代理时代的"管道"。

6.3 下一步：从终端到结构化交互

Terminal Threads 目前是纯文本交互——代理输出文本，你输入文本。但 Zed 团队暗示了更远的方向：

1. 结构化输出解析：识别代理输出中的特定模式（如文件路径、行号），提供可点击的链接
2. 内联操作：在终端输出中嵌入 Zed 操作按钮（如"Accept Change"）
3. 上下文共享：让终端代理访问 Zed 的编辑上下文（当前光标位置、选中代码等），无需 ACP
4. 输出摘要：AI 自动总结长时间运行的代理输出

这些方向暗示，Terminal Threads 不是终点，而是通往更深集成的一个起点。最终形态可能是一种"半结构化"的代理交互——比纯终端更丰富，比 ACP 更轻量。

七、与其他编辑器的对比

7.1 VS Code + 终端面板

VS Code 的终端面板是 Electron + xterm.js 实现：

• 优点：生态成熟，支持多标签、分屏
• 缺点：无代理管理概念，无通知机制，性能瓶颈明显
• AI 集成：依赖扩展（如 Cline、Continue），每个扩展有自己的 UI

7.2 Cursor + 内置终端

Cursor 基于 VS Code 魔改，增加了 AI 面板：

• 优点：AI 集成深度好，Composer 模式强大
• 缺点：终端面板与 AI 面板分离，不支持外部终端代理管理
• 局限：只能用 Cursor 自己的代理，无法管理 Claude Code/Amp

7.3 Warp Terminal

Warp 是 AI 原生的终端应用：

• 优点：AI 命令补全、自然语言转命令
• 缺点：不是编辑器，需要配合外部编辑器使用
• 定位不同：Warp 是"AI 增强的终端"，Zed 是"集成了终端代理管理的编辑器"

7.4 JetBrains AI + Terminal

JetBrains 在 2026 版中增加了 AI 助手和终端集成：

• 优点：功能全面，IDE 级别的代码理解
• 缺点：重量级，启动慢，终端不是为代理管理设计
• 与 Terminal Threads 的差距：没有线程化管理的概念

八、常见问题与故障排查

8.1 Terminal Thread 不显示通知

症状：Claude Code 等待输入，但 Zed 没有发出通知。

原因：代理没有输出 BEL 信号。

解决方案：

# Claude Code：确保通知已启用
claude config set notifications true

# Amp：强制 BEL
export AMP_FORCE_BEL=1

# 通用方案：在 shell 配置中添加
# ~/.zshrc
PROMPT_COMMAND+='echo -ne "\a"'  # 每次提示符出现时发 BEL

8.2 终端中文显示乱码

解决方案：

// settings.json
{
  "terminal": {
    "env": {
      "LANG": "en_US.UTF-8",
      "LC_ALL": "en_US.UTF-8"
    }
  }
}

8.3 多个 Terminal Thread 争夺焦点

症状：新终端自动获取焦点，打断当前编辑。

解决方案：

// settings.json
{
  "agent_panel": {
    "terminal": {
      "focus_on_create": false,  // 创建时不自动聚焦
      "notify_on_output": true   // 仍然发送通知
    }
  }
}

8.4 终端代理无法访问项目文件

症状：Claude Code 报 "Permission denied" 或找不到项目文件。

原因：Terminal Thread 的 cwd 可能不在项目根目录。

解决方案：

1. 确保从项目根目录打开 Zed：zed /path/to/project
2. 在 Terminal Thread 中手动 cd：cd /path/to/project
3. 检查 worktree 绑定是否正确

九、插件开发：扩展 Terminal Threads

9.1 自定义线程类型

Zed 的线程系统是可扩展的。你可以通过扩展注册自定义线程类型：

// zed-extension/src/lib.rs
use zed_extension_api::{self as zed};

struct MyCustomThread;

impl zed::Extension for MyCustomThread {
    fn new() -> Self {
        Self
    }
}

zed::register_extension!(MyCustomThread);

9.2 监听终端事件

通过 Zed 的扩展 API，你可以监听 Terminal Thread 的输出事件：

impl zed::Extension for MyExtension {
    fn on_terminal_output(
        &mut self,
        thread_id: &ThreadId,
        output: &str,
        cx: &mut ExtensionContext,
    ) {
        // 解析代理输出中的特定模式
        if let Some(file_path) = parse_file_reference(output) {
            cx.show_inline_action(
                thread_id,
                &format!("Open {}", file_path),
                || {
                    cx.open_file(&file_path);
                }
            );
        }
    }
}

9.3 自定义通知规则

你可以为特定代理定制通知行为：

// settings.json
{
  "terminal": {
    "notifications": {
      "rules": [
        {
          "pattern": "claude*",
          "on_bell": "notify_and_flash",
          "on_exit": "always_notify"
        },
        {
          "pattern": "cargo*",
          "on_bell": "silent",
          "on_exit": "notify_on_error"
        }
      ]
    }
  }
}

十、总结与展望

10.1 Terminal Threads 的核心价值

Terminal Threads 看起来是一个小功能，但它解决了 2026 年开发者最痛的问题之一：如何在编辑器中管理多个 AI 代理。

它的设计哲学可以总结为三点：

1. 包容而非排他：不要求代理适配协议，任何终端程序开箱即用
2. 统一而非割裂：终端代理和原生代理在同一个管理界面，无需切换心智模型
3. 务实而非理想：在 ACP 尚未普及的当下，给开发者一个立即可用的方案

10.2 对 AI 编码工作流的影响

Terminal Threads 标志着编辑器对 AI 代理的态度从"集成"转向"托管"。未来的编辑器不再只是"集成了某个 AI 功能"，而是成为一个AI 代理的运行时环境——你可以同时运行多个代理，每个代理在自己的线程中工作，编辑器负责管理它们的生命周期和交互。

这种转变的影响是深远的：

• 编辑器成为 AI 代理的操作系统：管理进程、调度资源、处理通知
• 代理可组合性：不同代理可以并行处理不同任务，编辑器协调它们的输出
• 成本优化：通过选择不同的接入方式（ACP vs 终端），优化代理使用的成本

10.3 期待的未来

• 结构化终端输出：解析代理输出，提供可交互的 UI 元素
• 代理间通信：让不同线程中的代理共享上下文或协调工作
• 持久化线程：关闭编辑器后，代理可以继续在云端运行
• 代理市场：一键安装和配置各种终端代理，就像现在安装 VS Code 扩展一样

Terminal Threads 是 Zed 在 AI 时代的一次重要探索。它不是最终答案，但它提出了一个正确的问题：编辑器应该如何与终端代理共存？ 答案不是强迫代理走某个协议，也不是把终端丢在一边——而是把终端当作一等公民，给它与 AI Agent 同等的管理能力。

这种务实的哲学，或许正是 Rust 社区的一贯风格：不做完美主义者，做解决问题的人。

参考资源

• Zed Terminal Threads 官方博客
• Zed Parallel Agents 文档
• ACP (Agent Client Protocol) 规范
• Claude Code 文档
• Amp CLI 文档
• Zed GitHub 仓库
• portable-pty Rust crate