看着机器人干活：Bot Screen 把每台服务器的桌面搬进客户端

你的机器人凌晨三点在某个后台卡住了，原因是“需要一个登录”。它在聊天里告诉你这件事，然后结束回合——剩下的你只能靠猜：它到底停在哪一页、有没有把上一个表单提交错。等你有空去处理，会话已经冷却，它甚至可能已经点了别的按钮。Bot Screen 解决的就是这个“看不见”的问题：在无头的 Linux 服务器上，每个 profile 现在都有自己的桌面，实时串流进 Hermes Desktop。你可以看着它做，也可以在它需要你的时候接管鼠标键盘，办完再交还。

它到底是什么

一句话：每个机器人都有自己的 Xfce 桌面，跑在网关那台机器上。

  • computer_use（桌面自动化）和“有头”浏览器（browser.headed: true）操作的就是这块屏幕；
  • 屏幕通过 noVNC 串流到 Hermes Desktop 的一个面板里；
  • 每个 profile 有各自的屏幕、各自的浏览器配置、各自的 cookie；
  • 关键的一点：屏幕活在网关主机上，不在你的笔记本上。你合上电脑、关掉客户端，机器人照旧在服务器上干活。

这就是它和“远程桌面连回自己机器”的根本区别：机器人在服务器上跑，桌面也在服务器上，你的客户端只是一扇窗。

拿它干什么：登录、2FA、验证码、付款

机器人在这些步骤上不该自己动手，也不该傻等：

  1. 它遇到登录、2FA、验证码或付款步骤时，在回复里说明情况并结束回合；
  2. 这条请求通过你常用的聊天渠道送达（Telegram、Slack、Desktop 都行）；
  3. 你有空时打开面板，点 Take over——边框变红，键盘鼠标归你；
  4. 登录、过验证码、确认付款；
  5. 点 Hand back，机器人重新接管，并在继续之前重新抓一次屏幕。

有意思的两个细节：机器人从不挂起等你在它那边阻塞——接管永远由你发起，它不会把一个工具调用开着悬在那里；两个观看者同时接管时，最近的一次接管获胜，之前的控制器退回观看模式。而“连接掉线”和“交还”是两回事：笔记本合盖、Wi-Fi 断了，控制权仍然在你手上（机器人被挡在屏幕外），直到你重连并交还；如果重载后显示仍是“人持有控制”，面板会给出 Hand back (force)。

怎么开始用

前提：网关主机是 Linux。 macOS 和 Windows 主机本身就有真实显示器，这块面板不会出现。

桌面组件（TigerVNC 的 Xvnc 加 Xfce 核心组件）不会静默安装——hermes update 和全新安装都不会动你的机器。缺组件时，Desktop 的面板会显示 Install on host，一次点击在那台主机上跑包管理器（它会在一个遮罩卡片里向你索要那台主机的 sudo 密码，密码只发往那台主机且不会被保存）。

官方 Docker 镜像（同时也支撑 Hermes Cloud）属于另一种情况：网关以非特权用户运行、镜像里没有 sudo，面板会直接把 apt-get 那行命令打给你，由运维在容器里以 root 执行一次：

docker exec -u 0 <container> apt-get install -y \
  tigervnc-standalone-server xfce4-panel xfwm4 xfdesktop4 xfce4-settings \
  xfce4-terminal dbus-x11 x11-xserver-utils x11-utils xauth fonts-dejavu-core

命令行一侧的对应命令：

hermes computer-use screen status     # 装了吗？在跑吗？谁持有控制？
hermes computer-use screen start      # 启动当前 profile 的屏幕
hermes computer-use screen stop       # 停止（有人持有控制时会拒绝）
hermes computer-use screen stop --force   # 强制停止，也能清掉卡住的租约
hermes computer-use screen install [-y]   # 调用 apt/dnf/pacman 安装
hermes -p research computer-use screen start   # 启动另一个 profile 的屏幕

屏幕默认是关闭的，没有任何东西会替你启动它。bot_desktop.auto_start 默认 false：打开它之后，机器人在无显示器的主机上第一次需要 computer_use（或第一次开有头浏览器）时会自动拉起屏幕。官方特意保留默认关闭——否则“为了别的目的装了 TigerVNC”就会莫名其妙多出一个屏幕。

bot_desktop:
  geometry: "1440x900"      # 屏幕分辨率，客户端会缩放适配面板
  auto_start: false         # true = 首次 computer_use / 有头浏览器时自动启动
  min_free_memory_mb: 1536  # 可用内存低于此值拒绝启动（0 = 不检查）
  idle_stop_minutes: 30     # 无人使用的屏幕多久后停掉（0 = 一直保留）

内存账要算清楚

桌面本身很便宜，浏览器才是开销。官方镜像里的实测：

项目 占用
网关空转 约 300 MB
Xvnc + Xfce 约 220 MB
接管时人工打开的 Chromium 0.5–1 GB（单页约 550 MB）
CPU 几乎可忽略（空闲桌面约 0.01 核）
磁盘（Debian 13，装完这些包） 约 930 MB

按“一个开着浏览器并处于接管状态的屏幕”算，请预留 1.1–1.5 GB。官方给的经验值是：4 GB 能跑桌面，8 GB 接管加浏览器才舒服。启动前 Hermes 会检查主机（或容器 cgroup，取更紧的那个）的可用内存是否达到 min_free_memory_mb；不够就不启动，并在面板里说明原因——已经在跑的屏幕不会被这个检查关掉。无人使用超过 idle_stop_minutes（默认 30 分钟）会自动停掉，下次用时再回来。

2026-09-23 起的新变化：镜像分了两种

托管部署（Fly Machines、Azure 容器实例这类）在运行时装不了任何东西，只能把包打进镜像。CI 现在为每个版本发布两个变体：

  • 不带后缀的标签（:latest、:v*）——不含桌面组件；
  • -desktop 标签（:latest-desktop、:v*-desktop）——含 TigerVNC、Xfce 和发行版 Chromium。

托管部署拉带后缀的镜像，就拿到了 Bot Screen。需要注意的现状是：调度器目前还没有替你选 -desktop，所以托管实例默认仍是精简版——你自己指定标签是可以用的。想自己做镜像也很简单，官方的构建参数默认关闭，保证 docker build . 依旧精简：

docker build --build-arg HERMES_BOT_DESKTOP=1 -t hermes-agent:screen .

第二天（9 月 24 日）又补了一条相关改动：所有镜像（包括不带桌面的精简标签）都改带完整版 Chromium，不再用 Playwright 的 headless shell——一个固定的浏览器同时服务无头浏览和有头的 Bot Screen，代价是镜像更大。

浏览器会话能在接管前后延续

这是 Bot Screen 最实用的一点：机器人的浏览器工具和面板上的 Browser 图标是同一个浏览器。每个 bot 有自己持久的用户数据目录（<HERMES_HOME>/bot-desktop/browser-profile），接管时你打开的窗口和 cookie 罐就是机器人之后会用的那一套——你登录的东西，它在本次运行和之后所有会话里都能直接使用，直到站点让登录过期。

想让它自己的浏览过程也显示在屏幕上，把 browser.headed 设为 true。要注意停靠栏（dock）只在屏幕第一次启动时“播种”一次，守卫是面板布局文件 <HERMES_HOME>/bot-desktop/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml：这个文件存在时，改 AGENT_BROWSER_EXECUTABLE_PATH 或 AGENT_BROWSER_PROFILE 之后重启屏幕并不会重新固定 Browser 图标——删掉它，下次 screen start 会按当时安装的东西重建停靠栏。

安全边界：它是工作台，不是沙箱

官方文档把这件事说得非常直白，值得照抄一遍给你：

屏幕的 RFB socket、X 显示、浏览器配置和控制租约文件都属于网关的 OS 用户。任何以该用户身份运行的进程——同一主机上的另一个机器人，包括机器人自己的 terminal 工具——都能直接触达它们，绕过面板和租约。租约是 computer_use 与浏览器工具上的工具级围栏，不是操作系统级的。

还有一条更宽的边界：Chromium 的 DevTools 端口（面板里的 Browser 和每次 agent-browser 启动都会在回环地址上广告一个）对主机上任何本地用户可达，因为 Chromium 对它的监听方式就是这样。要给每个机器人独立 OS 用户隔离不在当前范围内——如果你需要那层隔离，或者主机上有不受信任的本地用户，请把机器人放到不同主机上。

两条时间细节也值得知道：WebSocket 桥会把租约判断缓存最多 250 毫秒；观看者用的一次性 display_ticket 有效期 30 秒，且故意作为 URL 查询参数传递（noVNC 无法协商 WebSocket 子协议），所以反向代理的访问日志可能记下一个已失效的票据。

一句话总结安全性：别在你不信任的机器人屏幕里输入秘密。

小结

Bot Screen 把“机器人卡在登录页”从一次盲猜，变成一次点击接管、办完交还的常规操作；屏幕留在服务器上，你的笔记本可关可走。默认关闭、空闲自动回收、内存门槛明确，这三点让它不至于悄悄吃掉一台小机器的内存。想继续读：先看 Bot Mode 指南理解 profile 与机器人身份，再看 Docker 共享容器，以及本站 v0.21.5 发版页里这一窗口的其他变化。