昨晚我把 warp agent 跑起来之后，盯着它打出来的 pty 树看了十分钟。不是看它生成了什么，是看它到底怎么管终端。后来调出会话结构，我改口了：这玩意儿跟 Claude Code、Codex、Aider 不是一个物种。它真正的承重不在模型、不在路由、不在多代理编排，在最底层那件事——它把终端当成一块可重写的基础设施，而不是一个给 LLM 挂上去的命令执行口。这句话后面还会回来。
之前那些 agent CLI 为什么别扭，我基本都跑过。套路差不太多：起一个子进程，给个 shell，让 LLM 输出命令，执行完把 stdout 贴回给模型，循环。写测试、跑 lint、改两行代码，这个循环够用。一进真实终端就露馅。目录切换是老大难：每轮循环同一个 shell 进程，cd 之后状态还在，但你想在几个目录之间跳，或者同时跑两个全屏交互程序，这套“一个 shell 打天下”就绷不住。更别提到 SSH 远程机器——远程机器上没装对应的 agent 二进制，你只能靠模拟终端输入操作，每个字符都像隔着毛玻璃摸。这不是体验差一点，是结构上就错了。
Warp 干的事，是把这个错从结构上拆掉。它没另起炉灶写一个“给 agent 用的 shell”，直接把 Ghostty、Warp Terminal 这几年攒下来的 pty 管理和多路复用架构拿来给 agent 用。这个决定不是拍脑袋。它藏着一刀：agent 应该住在终端里，不是终端外面再套一个 agent。这句就是这个工具的承重墙。
我们一行行看终端这层。Warp Agent CLI 内部是一个类似 tmux 的多路复用器。你启动一个 agent 会话，它不是给你起一个 subprocess shell 就完事，而是撑起一个会话树，里面每个被 agent 调度的工作单元都分配一个独立的 pty。这些 pty 跟真实终端里的 pty 是同一个抽象层，不是模拟出来的。这是全部。没有这一步，后面那些“目录切换”“全屏应用”“SSH 不用装远程二进制”全是空话。
我拿它跑过一个多仓库例子，不算复杂，刚好能看出那个切换。先在 auth-service 里查 Nginx 配置，再切到 billing-service 改一个微服务的 Dockerfile。它做目录切换不是重新起个 shell 脚本去 cd，而是直接在一个持久会话里切 pty 的工作目录。这不是“执行了 cd 命令”，是会话状态本身就带着目录。你用惯 tmux 的 new-window -c 或 rename-session，会秒懂：它把 tmux 管会话的能力原封不动给了 agent。这一步在权限受限的云机器上特别扎眼——不需要给它装任何额外东西，它通过 SSH 隧道进到那台机器，靠你已有 SSH 凭证和远程机器上本来就有的 shell 跑命令。我之前被“不用装远程二进制”这个限制卡过：Claude Code 远程机器上没装 node、没装它的包，就只能走模拟终端输入那条邪路。Warp 把这个限制绕开了。
再讲一个让我意外的点：代理驱动全屏应用。它能自己开一个 sqlite REPL 待在旁边，该查的时候直接把 SQL 打进去，不把数据库客户端抽象成命令行参数；能开 gdb 设断点；能开 htop 盯着。这些是拿惯 agent CLI 的人最不敢想的场景。之前我们默认 agent 只会用“一次命令执行完、拿到 stdout 走人”的工具。全屏交互意味着 agent 得处理 raw terminal mode、ANSI 转义、长驻进程生命周期。Warp 能做，根子就在上面那层 pty：全屏应用跑在实际 pty 里，不是 agent 假装模拟一个。这一步把“agent 的能力上限”从“命令行工具能做什么”直接抬到“终端能做什么”。这个差距比换什么模型都大。
说到这儿你可能觉得我在写软文，那我补一刀。它的自然语言检测分类器、Tab 补全、多模型路由，我兴趣其实不大，尤其分类器。不是不重要，是这些属于锦上添花。分类器兜底的是“用户输入是 shell 还是自然语言”这个体验问题，不碰架构；路由是体验优化，换模型或者换 API 就行，今天它内置推荐，明天别人也能做。这些地方都能被追平。真正追不平的是终端基础设施这一层。Anthropic、OpenAI、哪怕微软，他们有模型、有云，但没有一个做了 5 年终端产品的团队，没有在 Ghostty 和 Warp Terminal 里被 pty、raw mode、秒级画屏、分屏管理这些鸡毛蒜皮磨出来的手感。这就是 Warp 的护城河。可能有人觉得我话说太满——Warp 又不是唯一做终端的公司。但剩下那些终端公司里，有几个会把自己的终端产品拆成 agent 的底层？这需要一种轻资产的自觉：不是把终端继续当应用做，而是把终端当基础设施开放出去。我到现在只看到 Warp 做了这个转身。
不过，云端多代理编排这层，我目前的态度是慢半拍。我能理解为什么叫 “Warp Agent CLI”——加了云端、加了多代理、加了网页端监控。但多代理编排不是它独有的东西。能协调 Claude Code 和 Codex 一起干活？听起来厉害，细想一层，里面每个子代理还是自己那个框架、自己的上下文窗口、自己的工具。Warp 做的协调，本质上是把一个复杂任务拆包，分给不同代理，再收回结果。这是编排层，别处能复现，不是承重墙。我觉得这一层被讲得太重了，尤其跟底下的 pty 架构比。拆开看，真正的差异是：别人想做这种编排，得先解决“agent 怎么住进终端”这件事；Warp 已经解决了。多代理编排是建在承重墙上的楼层，不是承重墙本身。
配置我也翻了。成本优化的自动路由听起来顺理成章——内置一些前沿模型、一些开放权重模型。开放权重这端，Warp 确实放了不少工作量，这也解释了为什么它愿意给你“API key 或 OpenAI 兼容端点”这个入口。老实说，18 美元一个月不便宜。但如果你已经有 OpenAI 端点，几乎不用为 Warp 本身付多少。这里它没明说的一层是：模型路由做成本优化，其实是在让你把“这个任务该用大模型还是小模型”的决策外包给它，省的是自己在多个 API 之间手动切来切去的心力。但这也不厚。靠路由省出来的那点钱，真实团队里根本算不过账。真正值钱的还是架构。
我承认对这个工具的判断变化过。一开始看它发布，只把它当成又一个带订阅制、带云端的 CLI，脑子里弹出来的是“又一个 Claude Code 变体”。跑了那十分钟 pty 树之后我改口了。它解决的早不是“能不能用大模型跑命令”——那个早解决了。它解决的是“agent 应该以什么姿态住在你的开发环境里”。之前的 agent 是访客，每次来都要重新解释一遍你是怎么工作的。Warp Agent CLI 是让它住了下来，有会话、有目录、有 raw mode 和 SSH 通道，该去哪去哪。这个差异，你只要在自己的环境里跑一次多仓库任务的切换，就能感觉到。
最后一句，你要是真好奇，别去看它那些截图和演示视频。去你自己的终端里装一个，跑起来看一眼它的会话树。墙我拆到这儿了，剩下的路你自己走。