前两天我在同时跑三个 AI 助手时，遇到了一个熟悉的困境。

左边终端跑着 Claude Code，中间是 Cursor，右边还有个 Amp。每个都在不同的项目里干活，但我得不停地在它们之间切换。更糟的是，一旦某个助手开始长时间运行任务，我就看不到它的进度，只能盲等。

我就在想…要是这些终端能像浏览器标签页一样，随时可见、随时切换，该多好。

没想到，Zed 最近刚好加了这样一个新特性。

它叫 Terminal Threads（终端线程），把终端以托管线程的形式放在侧边栏里。

一开始我以为就是个普通的 UI 改进。但仔细用了之后，我发现这个设计触及了一个更深层的问题——我们如何在同一个编辑器里管理多个并行的工作流？

---

这是什么新特性？

简单来说，Terminal Threads 让你可以在 Zed 的侧边栏里同时运行多个终端会话。

每个终端都是一个独立的「线程」，你可以

• 同时看到多个终端的输出
• 快速在不同终端之间切换
• 让 AI 助手在后台持续运行，而不会阻塞你的主工作区
• 为不同的任务分配专用的终端

如果你不熟悉这个概念，可以把它理解为「终端的标签页」。

但不是浏览器那种需要点击才能看到的标签页，而是始终可见、始终活跃的侧边栏面板。

这意味着你可以让 Claude Code 在一个终端里重构代码，Amp 在另一个终端里运行测试，还有一个专门的构建终端在编译项目。

所有这些都同时可见，互不干扰。

---

为什么要做这个？

你可能会问，传统的终端不也能开多个 tab 吗？为什么要专门做个侧边栏的终端线程？

这里涉及一个关键的设计决策。

问题一：AI 助手的并行需求

当你在用 AI 编程助手时，经常会遇到这种情况：

Claude Code 正在分析一个大项目，这个过程可能需要几分钟。传统做法是你得等它完成，或者切换到另一个终端去做别的事。但这样一来，你就看不到它的进度了。

有了 Terminal Threads，Claude Code 可以在侧边栏的一个终端里持续运行，你可以在主编辑区继续写代码，时不时瞥一眼侧边栏看看进度。

问题二：上下文的隔离

不同的任务需要不同的上下文。

比如你可能有一个终端专门用来跑开发服务器，一个用来执行 Git 命令，一个用来运行测试。如果它们都挤在底部的同一个面板里，很容易混淆。

Terminal Threads 让你可以为每个任务分配一个专用的终端，保持清晰的边界。

问题三：与 ACP Agents 的互补

Zed 已经有 ACP（Agent Control Protocol）Agents，这是一种更自动化的 AI 代理。但有时候你不需要全自动的代理，你只需要一个普通的终端来手动执行命令。

Terminal Threads 提供了这种灵活性：既有全自动的 ACP Agents，也有半自动的终端工具（如 Amp、Claude Code），还有完全手动的普通终端。

---

语言游戏考察

让我们停下来思考一下这里的语言使用。

当我们说「终端」时，我们在说什么？

1. 传统意义上的终端：一个命令行界面，用于执行系统命令
2. 现代语境中的终端：AI 助手的运行环境，自动化任务的执行场所
3. Zed Terminal Threads 中的终端：侧边栏中托管的、并发的、可视化的工作线程

这三种「终端」不是同一件事，但它们之间有家族相似。

注意这里的用法：「托管的线程」。这不是简单的多 tab，而是一种架构层面的重新设计。

「Thread」的语法

在日常语言中，「thread」意味着「线」「线索」「线程」。

但在 Zed 的语境下，「thread」有更具体的含义：它是一个独立执行的、可管理的、可视化的工作单元。

我们可以说 Terminal Thread 是一个「有生命的终端」。它会持续运行，会输出信息，会在侧边栏里占据一个位置，就像一个活着的进程。

我们不能说它只是一个「窗口」或「面板」，因为这些词暗示了被动性。Terminal Thread 是主动的，它在做事，在工作，在进化。

---

使用终端Agent

首先我们要创建一个终端Agent，选择 Zed Agent 下面的Terminal

比如这里输入pi来创建一个pi 的终端Agent。
pi 是一个极简、高度可扩展的终端 AI 编码助手，可以把它理解为一个轻量版、可定制的 Claude Code 或类似的终端 AI 开发工具。

进入pi之后，就可以像使用任何其他cli一样使用了

然后你就可以点击左边的右上角的+号创建新的终端Agent，比如amp

与此同时，你还可以创建更多的终端Agent，比如codex，cc

在左侧可以看到已经创建的所以的终端Agent

实际使用场景

我用 Terminal Threads 一周，发现了几个特别爽的使用场景。

场景一：AI 助手的并行工作

侧边栏显示：

▶ Claude Code - Refactoring
  $ claude-code "refactor auth module"
  [Analyzing codebase...]
  [Generating plan...]
  
▶ Amp - Testing
  $ amp "run tests for auth"
  [Running test suite...]
  ✓ 42 passed, 0 failed
  
▶ Build Watch
  $ npm run dev
  [Listening on port 3000]

我可以同时在主编辑区查看 Claude Code 的重构结果，而 Amp 在后台跑测试，Build Watch 在监控文件变化。

所有进度一目了然。

场景二：多项目并行开发

我经常需要同时维护两三个项目。以前我得开多个编辑器窗口，或者频繁切换工作目录。

现在我可以为每个项目分配一个专用的 Terminal Thread：

▶ Project A - Backend
  $ cd ~/projects/backend
  $ go run main.go
  
▶ Project B - Frontend  
  $ cd ~/projects/frontend
  $ npm start
  
▶ Project C - Docs
  $ cd ~/projects/docs
  $ mkdocs serve

切换项目就像切换侧边栏的线程一样简单。

场景三：长时间运行的任务

有些任务需要跑很久，比如数据库迁移、大规模数据处理、模型训练。

以前我会担心：如果我关掉终端，任务会不会中断？如果我想看进度，是不是得切回去？

有了 Terminal Threads，这些任务可以在侧边栏里持续运行，我可以随时瞥一眼看看状态，而不必中断手头的工作。

---

与传统终端的对比

很多人可能会拿 Terminal Threads 跟传统的终端 multiplexer（如 tmux、screen）比较。

说句公道话，它们各有优劣。

维度	Terminal Threads	tmux	传统终端 tab
可见性	始终可见	需切换 pane	需切换 tab
集成度	与编辑器深度集成	独立工具	浅层集成
学习曲线	低	高	低
AI 支持	原生支持	无	无
资源占用	低	中	低

Terminal Threads 的优势在于它与编辑器的深度集成。你不需要学习 tmux 的快捷键，不需要配置复杂的布局，一切都是开箱即用的。

---

写在最后

我用 Zed Terminal Threads 一周，最大的感受是：它改变了我与终端的关系。

以前终端是一个「用完即走」的工具。我需要执行命令时打开它，执行完后就忘掉它。

现在终端变成了一个「常驻伙伴」。它一直在侧边栏里，默默地工作，随时准备给我反馈。

这种心理模式的转变，比技术本身更有价值。

1. 终端不应该是一个临时的工具，而是一个持续的工作环境。
2. 并行的任务应该被可视化，而不是被隐藏。
3. AI 助手需要一个稳定的运行场所，而不是临时的会话。
4. 然而，可视化的能力有其边界。
5. 对于超出边界的需求…

…

这不是一个孤立的功能，而是一个更大愿景的体现：让编辑器成为一个真正的 AI 工作操作系统。

也许再过几个月，Terminal Threads 会成为 AI 编程编辑器的标配功能。

但至少现在，它给了我一个理由，重新思考终端在开发工作流中的角色。

因为在侧边栏的那个小小空间里，藏着一种新的工作方式。

一种让并行变得可见、让等待变得安心、让混乱变得有序的方式。

新时代的编程体验，一定会到来的。

而且它可能就从侧边栏的一个终端线程开始。