把一块云电脑交给 Hermes：Sai 插件让没有 API 的后台也能自动化

月底对账那天，你打开一个五年前的后台系统：没有 API 文档，登录靠验证码，报表要一层层点进去导出。你想让 agent 帮你跑一遍，它却连“打开浏览器”这一步都卡住——因为这里没有可以 POST 的接口，只有一张网页。屏幕，是人类操作这些系统的唯一入口，也一直是 agent 的盲区。

Sai by Simular 补的正是这块。它是一个跑在云电脑上的 computer-use agent：你给它一句话任务，它像人一样打开网页、点按钮、填表单，做完以后用文字把结果告诉你。Hermes 这边要做的只是把这个能力接进来，而接入方式已经收进了官方插件目录。

没有 API 的世界比你想的大

我们习惯把“自动化”理解成调接口。但真实工作里，大量系统注定不会有漂亮的 API：内部老后台、只给管理员用的控制台、必须登录才能看到的 SaaS 页面、需要手工填写的申报表。这些东西的共同点是——人能点，机器不能调。

传统解法是写 Selenium 脚本，为每个页面维护一套选择器，页面一改版就全挂。Sai 的路子不一样：它不依赖你维护选择器，而是让模型看着屏幕决定下一步。代价是慢（每一次点击都要经过一次模型判断），好处是脆性低、上手快。

Hermes 的定位因此很清楚：调度、上下文、记忆、审批都在本地，真正“动手点屏幕”这件事外包给一块云端电脑。任务描述、文件、API key 会发到 api.simular.ai，云电脑在那里执行。

装之前先确认三件事

第一是 Node.js。这个插件本身没有一行自己的代码，它是一个 Agent Plugins v1 包（plugin.json + mcp.json + skills/），真正的能力来自 npm 上的 @simular-ai/sai-mcp，版本锁在 0.4.0，通过 npx 启动。所以机器上要有 Node.js 22.12 以上和 npm。

第二是 Sai 的 API key。在 platform.simular.ai 注册后到 API Keys 页面创建，形如 sapi_...。免费计划自带一台云电脑和每日额度，够用来验证流程。

第三是 数据边界。这一点值得在装之前就想清楚：任务内容、你让它上传的文件、API key 都会离开本机发到 Simular 的 API；任务占用的额度来自你的 Sai 账号。它不是一个本地工具，而是一次明确的服务调用。

三条命令装好

插件在 Hermes 的官方目录里，名字就叫 simular-sai：

hermes plugins install simular-sai --no-enable
hermes plugins enable simular-sai

第一条从目录拉取并锁定到仓库的固定 commit（365b247，插件版本 0.1.2），--no-enable 让它先装好但保持关闭——这样你有机会先把 key 配好再启用。第二条打开它。

key 有两种放法：桌面端的 Settings > Plugins 里填，或者写进当前 profile 的 .env：

SAI_API_KEY=sapi_your_key_here

然后重启网关，让新进程带上环境变量。想先确认装对了没有，可以看它声明了什么：

hermes plugins info simular-sai

输出里会写清版本、锁定的 commit、依赖的 Hermes 版本（>=0.21.6）以及那段重要的数据披露。插件目录本身是怎么运作的，之前那篇 插件目录指南 讲得更细。

一次任务是怎么跑完的

装好之后，Hermes 多了一个 MCP server（名为 sai）和一个技能（simular-sai:sai）。技能负责判断“什么时候该把活交出去”，MCP server 负责实际的动作：启动任务、等它跑完、回答权限请求、必要时停止、上传文件、列出可用的电脑和模型，以及把屏幕临时交给一个人。

一句典型的话就能触发：

用 Sai 打开我的云电脑上的记事本，输入 Hello from Sai，然后告诉我窗口标题。

背后的流程大致是：

  1. 起任务。Hermes 把目标和上下文一起交给 Sai，Sai 在云电脑上开始操作。
  2. 等结果。任务不是瞬间完成的，需要轮询等待；这一步会消耗时间，别指望它像调 API 那样毫秒级返回。
  3. 应答权限。Sai 在自己的云电脑上执行命令或写文件时会先要许可，这个许可由 Hermes 代表你回答。也就是说，一次任务的“审批链”有两层——Hermes 自己的工具审批，加上 Sai 内部的审批。
  4. 取回文本。任务结束时，Sai 返回的是文字结果，不是截图或视频。
  5. 可选：人工接管。如果某一步必须真人操作，sai_live_link 会给你一个链接，拿到链接的人可以在链接过期前直接操作那块云电脑。

还有一个细节挺实用：任务运行中，本地会在 127.0.0.1 上起一个实时视图（watch_url），你能看到云电脑上正在发生什么，而 API key 不会进入浏览器。

几个容易踩的边界

不要把它当浏览器用。 如果你只是要抓一个公开页面、填一个你能直接调接口的表单，用浏览器的 CDP 工具快得多，也便宜得多。Sai 的价值在于“没有接口 + 需要真人式操作”的交集。

上传是有上限的。 sai_upload 让 agent 把本地文件送到云电脑，单文件上限 25 MB。别指望用它搬数据集。

live link 是真正的“钥匙”。 sai_live_link 返回的链接，任何拿到它的人都能操作你的云电脑，直到 expires_at。技能里明确要求 agent 只把链接给你本人，但这条规则最终靠模型执行——贴到群里就收不回来了。

没有 trust: untrusted 门禁。 这是设计取舍：sai-mcp 的工具没有 readOnlyHint，如果套上不受信门禁，每次轮询 sai_task_wait 都要你点一次确认，任务根本跑不动。替代方案是 Sai 自己的 needs_approval：命令执行和写文件仍然会先问。

它不便宜，也不该高频使用。 每次点击都是一次模型推理。适合“一天跑三次、每次十分钟”的活，不适合“每分钟跑一次”的活。想省 token 的日常任务，还是走 Hermes 自己的工具链。

什么时候值得用

我的判断标准很简单：如果一个流程，你每个月都要手动做、每次都要登录、都要点七八个页面、都没有 API——那就值得把它交给 Sai 试一次。反过来，凡是能用 curl 或 Hermes 内置工具解决的，就不要绕这一圈。

安装本身只是一条命令的事，真正需要花时间想的是：你打算把哪些任务交出去，以及那些任务里有没有不该出现在别人服务器上的东西。把这两件事想清楚，剩下的配置十分钟就能完成。如果你更关心插件在权限上的隔离边界，可以再看看 插件隔离与宿主边界 那篇。