Theo 为何从终端转向图形化智能体工作流

我一生中大部分时间都优先使用终端。还没开始写代码时，我就用终端运行 Minecraft 服务器、连接远程机器。我花了很多精力配置 GNU screen，后来转向 tmux。虽然我也喜欢用鼠标浏览代码，但多年来日常工作主要在命令行里完成。

最近我发现，电脑重启后，我工作了八个多小时都没有打开终端。这让我很意外。变化并不是因为我突然讨厌终端，而是编程智能体改变了我的工作方式，也改变了我对工具的需求。

我知道有人会指出，我参与开发了 T3 Code，一个开源的智能体图形界面。这层关系值得说明。我之所以开发它，正是因为遇到了下面这些问题；我也会讨论其他促使我形成这一观点的产品。

一个早期影响来自 Antigravity 的智能体管理器。虽然我对产品整体并不满意，但它有一个独立视图，可以显示多个项目中的智能体活动，这引起了我的注意。侧边栏能集中展示不同窗口里的会话，为组织并行工作提供了新的思路。

当时我用 Cursor 发送提示词，但仍会回到终端查看差异、检查 Git 历史和运行代码。找到正确的 worktree 路径很麻烦，于是我要求提供更方便的复制方式。我的工作基本分成两半：用图形界面提问，用终端处理其他事情。

Codex 应用进一步强化了这种想法。它按项目组织工作，让我在不同 worktree 中并行运行多个会话，需要时还能打开终端。我仍然可以在那里查看 Git 历史，同时获得更清楚的工作概览。

当时我仍在终端里使用 Claude Code，借助 cmux 等工具管理会话；tmux 也是很难放下的习惯。不过在 Codex 应用里，我可以粘贴并看到截图、选择和复制带格式的文本、滚动内容，还能点击切换任务。这些小体验累积起来很重要。

同时处理多个任务时，记住面板和快捷键本身就成了一项工作。我为五个任务记住的布局，出现第六个任务时可能就不够用了。Cmux 给终端加上侧边栏，在解决这个问题上更进一步；我现在仍用它方便地访问远程 SSH 连接。

文字易读、按项目组织的图形界面，让我更愿意同时处理多件事。但 Codex 应用是闭源的，这让我担心：出现功能退化或不喜欢的变化时，我不能直接自己修复。团队确实回应了反馈，但这一限制对我仍然重要。

在视频录制时，我觉得 OpenCode 和 Pi 等开源工具提供了出色的终端体验，而成熟的图形界面通常与某一家提供商绑定。不同官方客户端提供的功能和订阅安排也不一样。产品和提供商政策可能变化，这里描述的是我当时的体验。

结果是，我使用 Claude 模型时待在终端，使用 Codex 时又切换到图形应用。有时即使另一个模型可能更适合任务，我也会因为喜欢图形界面而选择 OpenAI 模型。我希望能方便地追踪工作，又不必让界面决定模型选择。

我经常找不到终端会话和 worktree，甚至要让智能体帮忙找回之前启动的工作。一台 Linux 机器上曾有大约 30 个 tmux 终端，分别处理不同任务。给会话改名当然有帮助，但维护命名体系仍需要投入注意力。

以前，终端配置可能需要预先花时间，之后就能靠熟悉的习惯减少负担。而我现在的工作变化很快：项目有新有旧，同时处理的任务可能只有一个，也可能有十个。我自己搭建的固定面板布局已经不太适合这种变化。

我花了不少精力，才让图片能够经过 cmux、SSH 和 tmux 粘贴。最终它变得比较稳定，但为发送一张截图付出这么多配置成本并不理想。在图形界面里，我可以直接粘贴并看到图片；我的许多提示词都会附带错误截图或应用画面。

我最大的挫折来自网络状况不理想时的 SSH 远程交互。有一次，即使网络速度很快，输入仍然出现卡顿；原因是连接走了 Wi-Fi，而不是我预期的有线网络。SSH 依然强大而有用，但我不想在日常智能体工作中反复排查这类细节。

我仍然使用终端工具，包括手机上的 SSH 客户端，它们在调试时很有价值。我知道还有 Mosh 等其他方案，但对我来说，在手机终端里长时间处理智能体任务并不舒服。我批评的是自己选择的使用体验，并不是说远程终端工具无法改进。

通过 Codex 移动应用远程控制，我可以在电脑上启动任务，再用手机查看进度或继续会话，同时去做其他事情。我喜欢这种自由，但当时也遇到了漏洞，以及桌面端和机器支持方面的限制。

我想要的功能包括粘贴图片、使用自己的模型和订阅、可靠的远程控制、Linux 和移动端支持、良好的性能与电池表现，以及清楚地管理大量并发任务的方式。我的 Linux 机器在频繁创建 worktree 的开发中感觉尤其快，但这些比较反映的是我自己的硬件和配置。

Julius 和我开发 T3 Code，是因为我们有很多相同的烦恼。我最初尝试构建原生图形界面，但在大型可滚动文本视图上遇到困难。后来我尝试用 Electron 构建，并使用 WebSocket 通信，让探索远程控制更容易；这成了 T3 Code 早期粗糙的版本。

最初几个月，我仍然大量使用 Codex 应用。Julius 则从不同的出发点继续改进 T3 Code：他更喜欢在编辑器里操作 Git，也不想为每种智能体记住不同的终端界面。尽管我们偏好不同，我认为他是一位非常出色的开发者。

Theo 认为 Julius 改进了 worktree 支持和多个智能体工具的集成。目标是在一个界面里管理多家提供商及其本机运行工具。Theo 表示，项目当时使用官方 SDK 并遵循相关提供商安排，同时也提到一项可能的政策变化尚未确定；可用性和条款不能假定永远不变。

真正改变我日常工作的是：选择一台机器、向它发送任务，然后合上笔记本电脑。T3 Code 可以从另一台电脑、网页或移动应用连接到正在运行的实例。远程机器仍需完成设置并保持运行；界面只是访问这些工作的方式。

以前，如果马上要开会或出门，我会推迟启动智能体。笔记本发热、风扇噪声和不稳定的网络会让会话变得很不方便。我以前常在 Uber 车上写代码，但合上电脑或断网可能中断智能体任务，之后还得设法继续。

任务从几分钟延长到几个小时后，这种限制更加明显：我不得不围绕笔记本能打开多久来安排工作。现在，我可以让另一台机器开始工作，关闭本地 T3 Code 客户端，稍后重新打开或使用网页查看正在进行的任务。我还能继续会话、查看历史、添加图片，必要时打开终端。

Theo 演示了通过 Tailscale 配对，并介绍了一个用于认证机器、启动后台实例的 connect 命令。他表示，录制时展示的后台配置支持 Linux，Mac 支持仍在计划中。命令、提供商政策和平台支持都与版本有关，视频之后可能已经变化。

如果有一台闲置电脑，可以考虑让它运行智能体工具，再从更方便的界面连接。这正是令我兴奋的工作方式：执行任务的机器和查看任务的设备不必是同一台。

我也在意能否修改自己使用的工具。我记得编辑器从闭源产品转向 Atom 和 VS Code 等可定制开源项目的变化。随着 AI 开发转向闭源产品，我感觉这种自由正在减少；但同时，只要能获得源码，智能体又让定制工具变得更容易。

我投入 T3 Code，源于这种挫折，也源于对开源 AI 开发工具的期待。我承认它未来可能有商业潜力，但我所希望的是构建一个实用、可定制的界面。我认为，对于今天自己的工作，图形界面是更合适的形式。

你不必使用我的项目才能验证这个想法。试试功能完善的图形智能体界面，看看同时处理多个任务时，切换会话、审阅结果和添加图片是否更容易。不同的人和工作流也可能得出不同结论。

在我的工作中，远程执行和更方便的导航改变了我组织编程任务的方式。我观察到，合并的拉取请求从每周大约三四个，增加到工作繁忙时一天最多 20 个。这是我的个人观察，并不能证明仅靠图形界面就造成了增长，也不能保证其他人获得同样结果。

我仍然热爱终端，也怀念过去频繁使用它的日子。我的观点是，以命令和面板为中心的界面，未必是管理大量持续进行的智能体任务的最佳默认选择。我鼓励熟悉终端的开发者挑战自己的习惯，亲自试试图形工作流。