前两天同时在跑三个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），还有完全手动的普通终端。
语言游戏考察
让我们停下来思考一下这里的语言使用。
当我们说「终端」时，我们在说什么？
- 传统意义上的终端：一个命令行界面，用于执行系统命令
- 现代语境中的终端：AI助手的运行环境，自动化任务的执行场所
- 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一周，最大的感受是：它改变了我与终端的关系。
以前终端是一个「用完即走」的工具。你需要执行命令时打开它，执行完后就忘掉它。
现在终端变成了一个「常驻伙伴」。它一直在侧边栏里，默默地工作，随时准备给你反馈。
这种心理模式的转变，比技术本身更有价值。
- 终端不应该是一个临时的工具，而是一个持续的工作环境。
- 并行的任务应该被可视化，而不是被隐藏。
- AI助手需要一个稳定的运行场所，而不是临时的会话。
- 然而，可视化的能力有其边界。
- 对于超出边界的需求…
…
这不是一个孤立的功能，而是一个更大愿景的体现：让编辑器成为一个真正的AI工作操作系统。
也许再过几个月，Terminal Threads会成为AI编程编辑器的标配功能。
但至少现在，它给了我们一个理由，重新思考终端在开发工作流中的角色。
因为在侧边栏的那个小小空间里，藏着一种新的工作方式。
一种让并行变得可见、让等待变得安心、让混乱变得有序的方式。
新时代的编程体验，一定会到来的。
而且它可能就从侧边栏的一个终端线程开始。
