我正在创造一款豆包手机级别的 Windows 终端

这几天我一直在想豆包手机助手这件事。它真正让我震动的地方，不是“手机上多了一个 AI”，而是 AI 开始从一个聊天框，走进了普通用户最重要的数字入口。过去我们理解 AI 助手，很多时候还是问答逻辑：你问一句，它答一句；你让它写文案，它给你一段文字；你让它解释问题，它给你一个建议。但豆包手机助手展示出来的方向不是这样，它想做的是进入手机系统，理解屏幕内容，调用不同 App，然后替用户把任务真正做完。

公开资料里，豆包手机助手是在豆包 App 的基础上，和手机厂商在操作系统层面合作的 AI 助手软件。2025 年 12 月，字节跳动豆包团队发布了豆包手机助手技术预览版，并通过与中兴合作的 nubia M153 工程样机供开发者和科技爱好者体验；豆包方面也强调没有自研手机计划，而是通过生态合作把手机助手整合到不同品牌机型中。这个信息很关键，因为它说明豆包手机真正想争夺的不是一台硬件，而是“手机入口”本身。(IT之家)

从功能上看，豆包手机助手的能力也很典型。它可以通过语音、侧边 AI 键或耳机唤醒；在任意界面里，用户可以就当前屏幕内容直接向它提问；它还打通了系统原生相册，用户可以通过语音对图片下达修图指令，比如删除人物、清理杂物。更重要的是，它能根据用户指令在多款应用之间自动跳转，完成查票订票、商品下单、批量下载文件、多软件物流进度查询等任务。换句话说，它不是在手机里多放了一个 AI App，而是让 AI 站到了手机这个入口上，开始调度手机里的其他 App。(IT之家)

新华财经的实测也能看出这种变化。测试里，用户说“在 B 站搜索并播放某频道最新视频”，豆包手机助手可以自动打开 B 站、搜索频道并播放视频；用户要求查询“下周三上午从成都前往杭州的四川航空最便宜机票”，它也能打开旅行 App、填写出发地和目的地、选择日期并筛选航班。这里最重要的不是“它会不会搜视频”或者“它会不会查机票”，而是 AI 从建议者变成了执行者。传统助手会告诉你怎么做，而豆包手机助手开始替你进入 App，把步骤串起来。([新华网][2])

这件事让我想到 Phantty。普通用户的数字入口是手机，那程序员的数字入口是什么？我现在越来越确定，答案不是浏览器，也不完全是 IDE，而是终端。浏览器连接的是信息世界，IDE 主要承载的是代码编辑，但终端连接的是系统本身。程序员启动项目、安装依赖、运行测试、查看日志、连接服务器、进入容器、部署服务、修改配置、排查故障，最后几乎都要回到终端。终端不是一个黑色窗口，它是程序员进入系统、服务器和运行现场的入口。

所以我看到豆包手机助手的时候，脑子里冒出来的不是“我也要做一个手机 AI”，而是另一个判断：如果豆包手机助手代表的是 AI 接管普通用户的手机入口，那么 Phantty 要做的，就是让 AI 接管程序员的终端入口。这里的“接管”不是无边界地乱执行命令，而是在用户授权和权限控制下，让 AI 能够观察终端、理解上下文、提出计划、执行命令、读取结果，并继续推进任务。

这就是我说“我正在创造一款豆包手机级别的 Windows 终端”的原因。这个“级别”不是指商业规模，也不是说 Phantty 现在已经拥有豆包手机助手那样完整的消费级体验，而是指产品范式。豆包手机助手的范式是：AI 不再停留在聊天框里，而是进入手机系统，理解屏幕，操作 App，串联任务。Phantty 的范式则是：AI 不再停留在终端旁边的聊天框里，而是进入终端现场，理解会话，操作 shell，调度服务器。

Phantty 本身是一个 Windows 终端，用 Zig 编写，基于 libghostty-vt 做终端模拟。在已有能力上，它已经不只是一个普通命令行窗口：它有 tabs 和 splits，有文件浏览和 Markdown/text 预览，有内置 WebView2 浏览器面板，有 AI Chat session，有远程访问能力，也支持 Kitty Graphics 图片协议。这些能力叠在一起，构成的不是一个孤立终端，而是一个程序员工作空间。([GitHub][3])

从 v0.19.0 开始，我真正想推进的，是让这个工作空间变成 agent 可以调度的现场。Phantty v0.19.0 的 release 里，AI Chat 已经可以作为 agent 运行：它支持 OpenAI-compatible tool calling，可以在多轮循环中观察终端、执行本地 PowerShell，也可以向已经打开的 SSH session 注入命令。它还有 Ask 和 Full 两种权限模式，Ask 模式会在聊天里等待用户批准，Full 模式才会直接运行工具。([GitHub][4])

这一步的意义很大。传统 AI 终端大多还是“AI 帮你生成命令”。你遇到问题，把报错贴给 AI；AI 给你一段命令；你复制到终端里运行；运行完再把结果贴回去。这个过程当然有用，但 AI 仍然站在工作流外面。它并不知道你现在开了几个终端，不知道哪个是本地 PowerShell，哪个是远程 SSH，也不知道哪个窗口正在跑日志，哪个窗口已经进入了项目目录。它只是根据你搬运过去的信息进行判断。

我想做的 Phantty 不一样。我希望 AI 直接活在终端里，能看到当前有哪些终端会话，能读取终端快照，能判断自己应该操作哪个 session。比如我已经打开了本地 PowerShell，也连上了几台服务器，其中一个 tab 在看日志，另一个 split 在跑构建命令。这个时候我问：“帮我看看服务为什么没起来。”AI 不应该只是告诉我“你可以运行 systemctl status”，而是应该先识别当前有哪些 session，再判断目标服务器是哪一个，然后提出要执行哪些只读检查命令。等我确认以后，它在对应的 SSH session 里执行命令，读取输出，再继续分析下一步。

这就对应了豆包手机助手的“同屏理解”。豆包手机助手可以看见你当前手机屏幕上发生了什么，Phantty 的 agent 则应该能看见终端里发生了什么。豆包手机助手不需要用户把屏幕内容复制出来再问，Phantty 的 agent 也不应该依赖用户不断复制终端输出。AI 只有看见现场，才能真正进入工作流；否则它只是一个站在旁边等你喂上下文的顾问。

豆包手机助手还有一个关键能力，是跨 App 操作。用户不需要自己在多个 App 之间跳来跳去，AI 可以按照任务需要打开不同应用，填写信息，筛选结果，把多个步骤串起来。对应到程序员世界，Phantty 要做的不是跨 App，而是跨 tab、跨 split、跨 shell、跨 SSH session、跨服务器。程序员的真实工作现场本来就不是一个窗口，而是一组终端会话：本地、WSL、测试服务器、生产服务器、日志窗口、构建窗口、部署窗口，这些共同组成了程序员的工作流。

这里也能看出 Phantty 和小龙虾、OpenClaw，或者我之前想做的 agent-control 的区别。小龙虾这类工具也可以跑在服务器上，也可以操控服务器；agent-control 的思路也成立，就是在不同服务器上分别运行一个 agent，然后通过一个 Web 控制台统一调度。但这种模式本质上是“每个环境一个 agent”。你要控制 A 服务器，就在 A 上部署 agent；你要控制 B 服务器，就在 B 上部署 agent；服务器越多，需要管理的 agent 也越多。

Phantty 现在走的是另一条路。我不想在每台服务器上都放一个 agent，而是让一个 agent 活在我的终端里，调度我已经打开的所有终端会话。这个逻辑其实和豆包手机助手很像：豆包不是给每个 App 都装一个 AI，而是在手机这个入口上，让 AI 去操作不同 App；Phantty 也不是给每台服务器都装一个 agent，而是在终端这个入口上，让 AI 去调度不同 shell 和 SSH session。前者是服务器视角，后者是程序员工作流视角。

这个视角差异非常重要。服务器 agent 关心的是某台机器上能执行什么，而终端 agent 关心的是程序员现在打开了哪些现场。程序员平时本来就是通过终端来组织工作的：我已经连上服务器了，我已经打开日志了，我已经进入项目目录了，我已经有了本地环境、远程环境、测试环境和生产环境。既然这些现场已经聚合在终端里，那最自然的方式不是另起一个 Web 控制台，而是让 AI 直接进入这个终端控制台。

当然，豆包手机助手也提醒了我另一件事：只要 AI 进入核心入口，安全和权限就不再是附属问题，而是产品本身的一部分。新华财经实测提到，豆包手机助手有事前、事中、事后的授权机制：执行具体功能前会询问用户，执行过程中会展示操作进度，用户可以手动接管、停止任务或补充需求；遇到支付密码、隐私信息修改等高风险操作时，系统会提示用户接管。([新华网][2])

终端里的风险比手机更直接。手机助手误点一个 App，最多是下错单、发错消息、触发平台风控；终端 agent 如果没有边界，可能会删文件、改配置、重启服务、部署生产环境，甚至影响远程服务器。所以 Phantty 不能只强调“AI 能执行命令”，更要强调“AI 受控地执行命令”。它必须知道当前 session 是本地还是远程，必须知道自己操作的是测试环境还是生产环境，必须区分只读检查和修改性操作，必须在高风险命令前请求确认。

这也是为什么 v0.19.1 里那些看似细节的改动很重要。release 里提到，AI Chat 在 agent 工作时更容易控制：消息气泡支持复制，transcript 和输入框支持选择，界面上有可见的 stop 按钮，可以取消正在进行的请求；同时，AI 工具快照会从 UI 线程捕获活动终端列表，让 agent tools 能正确看到已有终端和 SSH sessions，取消操作也会尽可能停止正在运行的 PowerShell 命令。([GitHub][4])

这些不是普通 UI 优化，而是 agent 产品的基本安全能力。一个真正能干活的终端 agent，必须随时能停，必须让用户知道它在干什么，必须能被用户接管。否则它越聪明，风险越大。AI 进入终端以后，产品的核心问题不再是“模型会不会回答”，而是“它能不能可靠地观察、谨慎地执行、清楚地反馈、随时被中断”。

从这个角度看，豆包手机助手和 Phantty 的关系非常清楚。豆包手机助手面对普通用户，Phantty 面对程序员；豆包接管的是手机屏幕，Phantty 接管的是终端会话；豆包跨的是 App，Phantty 跨的是 shell、SSH、WSL、服务器和项目目录；豆包要理解的是用户生活里的任务，Phantty 要理解的是程序员工作里的任务。两者的共同点是，它们都不是把 AI 当成一个外置聊天框，而是让 AI 进入最核心的操作入口。

所以“豆包手机级别的 Windows 终端”这个说法，对我来说不是一句夸张的口号。它真正表达的是一个产品方向：AI 原生的终端，不应该只是多一个聊天 tab，也不应该只是帮我生成几条命令。它应该能够观察我已经打开的工作现场，理解不同 session 的上下文，在我授权之后执行任务，并根据终端返回的结果继续推进。过去终端是人操作机器的界面，未来终端也可以变成 AI 理解和操作程序员工作现场的控制平面。

Phantty 现在还处在很早期，但方向已经很清楚。第一步，让 AI 能看见终端。第二步，让 AI 能理解终端。第三步，让 AI 能在权限控制下执行命令。第四步，让 AI 能调度多个 SSH session。第五步，让 AI 能区分本地、远程、测试、生产。最后，让 AI 从一个聊天助手，变成程序员工作现场里的执行代理。

普通用户用手机连接数字生活，程序员用终端连接整个系统。当 AI 接管手机，普通用户的交互方式会改变；当 AI 接管终端，程序员的工作方式也会改变。豆包手机助手让我看到的是，AI 真正的产品革命，不是模型多聪明，而是它有没有进入用户真正的入口。对普通用户来说，这个入口是手机；对程序员来说，这个入口就是终端。

这就是我正在做的 Phantty：一款豆包手机级别的 Windows 终端。不是把 ChatGPT 塞进终端，不是做一个命令补全插件，也不是每台服务器上部署一个 agent，而是让一个活在终端里的 agent，观察、理解、调度我已经打开的所有工作现场。豆包手机想做的是 AI 帮普通人操作手机，而 Phantty 想做的是 AI 帮程序员操作终端。

[2]: https://www.news.cn/tech/20251226/a25b822dd8c545e2b238baa9b37910a1/c.html "
[3]: https://github.com/xuzhougeng/phantty “GitHub - xuzhougeng/phantty: Windows renderer for libghostty-vt · GitHub”
[4]: https://github.com/xuzhougeng/phantty/releases “Releases · xuzhougeng/phantty · GitHub”