大家好，我是孟健。
装完 Hermes Desktop 的第一感受是：它不是我需要的那个东西。
这不是差评，是适用范围的问题。
01 我以为它会替代 Telegram，结果没有
官方介绍 Hermes Desktop 的时候，列了一堆让人心动的东西：原生桌面 UI，同时跑多个对话，工具调用实时可视化，右侧 preview rail 预览文件，拖拽上传附件，管理面板覆盖 providers、API keys、model、toolsets、MCP、gateway、sessions、skills、cron、profiles、messaging，一个界面全管了。
官方的定位词是"operational command center"。听起来就是那种让所有事情一目了然的控制台------早上打开 Desktop，左边列着所有活跃的 Agent session，右边实时显示哪个任务在跑、哪个 cron 快触发了，发个指令，实时看到 Agent 回应。
我以为我会把入口从 Telegram 切过来。
我的真实场景是：Hermes 跑在远程 Linux 服务器上，本地是 Windows，通过内网穿透连接。多个 Agent 并行，各自对应不同的 Telegram 群组，任务通过 TG 调度，结果也通过 TG 送回来。
这个场景和"本地图形化管理"这个设计意图，从一开始就是两件事。
然后我装了，用了一周，打开了 Telegram，继续用 Telegram。
界面再好看，改变不了我的工作流入口。
02 Desktop 真正适合的是本地用户
要公平地说，Hermes Desktop 确实解决了一个真实问题。
如果你不想碰命令行，不想改 YAML，不想记 hermes profile list 这些命令，但你又想用 Hermes，Desktop 是一个很好的起点。
它把所有配置图形化了。想加一个 MCP 服务，点一下。想看当前有哪些 skills，列表里全在。想管理 cron 任务、切换 profile，不用翻目录，直接在 UI 里操作。复用的是同一个 Hermes core，config、API keys、sessions、memory 全都共享，不是阉割版，也不是两套系统。
对本地单机用户来说，这是降低门槛的正确方向。
问题在于，这不是我的主要痛点。我的 Hermes 跑在远程服务器上。
03 远程链路里，每一层都可能成为故障点
在说具体坑之前，有一件事要先说清楚：Hermes Desktop 连的是 Dashboard 的 backend，不是 Telegram/Discord gateway。
Dashboard 默认跑在 127.0.0.1:9119。本地用户没感觉，因为 Desktop 和 Dashboard 在同一台机器上，自动就通了。但只要引入远程服务器，链路就拉长了：Desktop 在本地，Dashboard 在服务端，中间还有内网穿透、系统代理、Host 校验。每一层都可能单独出问题，叠加起来就是两个小时白给。
Desktop 层 --- 要先找到 backend 地址，默认指向本地。改成远程地址这一步本身不复杂，但完成这一步不等于完成连接验证，后面还有很多关。
Dashboard 层 --- Dashboard 的 HTTP 状态返回 200，不等于 WebSocket 连接正常，也不等于 chat session 可用。我在 desktop.log 里看到 Remote Hermes backend is ready 的时候，以为全好了，结果聊天还是没有响应。这条日志只代表 HTTP 握手完成，WebSocket 是独立的连接，需要单独验证。另外，desktop.log 是累计日志，里面有大量旧条目，需要手动对齐时间戳才能确认当前状态，不能直接相信里面的成功信息。
WebSocket 层 --- WebSocket 依赖持久的 TCP 连接。中间如果有代理或 NAT 设备在切断空闲连接，WebSocket 会悄悄断掉，Desktop 端可能没有明显报错，只是消息发出去之后没有回应。这类故障最难察觉。
Tailscale/VPN 层 --- 内网穿透的端口转发规则会影响流量如何到达服务端。我一度以为问题出在 Hermes 本身，查了很久才发现是穿透层的配置没对齐。这类问题很隐蔽，因为连接看上去是通的，但流量走的路径不对。
Windows 代理层 --- Windows 端访问 /api/status 返回 502，查了半天，是本地代理把流量截走了。配了 bypass-list 之后才恢复。这类问题和 Hermes 没关系，在应用层完全看不出来，只能从网络层排查。
Host header 层 --- 代理问题刚解决，又报 Invalid Host header. Dashboard requests must use the hostname the server was bound to.。Dashboard 只认它绑定时用的 hostname，经过代理转发之后 Host header 变了，直接被拒。这是安全机制，不是 bug，但对调试过程很不友好。
每一关单独看都不难，但叠在一起，时间就消失了。
完成连接验证，和连接稳定可用，是两件不同的事。
另外还有一些远程场景的边界问题：Desktop 远程模式下，语音输入有硬超时限制，在 CPU-only 的服务器上不可靠；文件面板在远程模式下会把远端目录和本地文件系统混在一起，实际上很难用；如果 dashboard 自己重启了，Desktop 里的 session 会直接断掉，报错也不直观。这些不是致命问题，但都是 public preview 阶段的现实。
04 桌面 UI 替代不了异步通知
即使全部连通，我还是会回到 Telegram。原因不在 UI 好不好看，在于工作模式的根本差异。
Desktop 是同步的。它要求你坐在屏幕前，打开界面，盯着对话进行。这是"现场操作"的模型，适合需要长时间专注处理一件事的场景。但我和 Agent 的交互模式和这个完全不同。
早上起来，手机里看 Telegram，Agent 昨晚跑完没有，有没有 BLOCKED 的任务需要我拍板，有没有产出需要确认。白天随手发指令------"帮我看一下这个文档"、"把这个 issue 加到 backlog"、"今天优先级是这个"------丢给 Telegram，几秒钟，继续干别的。Agent 完成了，TG 里 DONE；遇到问题，TG 里 BLOCKED，我看到了再回。
这是异步调度，Agent 在后台跑，我随时可以不在线。
桌面 UI 的通知机制是被动的：你得打开它，才知道发生了什么。即使有系统托盘通知，也是碎片式的，没有对话上下文，没有任务状态的完整视图。Telegram 的通知带着消息内容，打开就是当前任务状态，不需要再跳转到另一个地方去找上下文。
多 Agent 并行的情况下差异更明显。我有十几个 profiles 对应不同角色，日常是并行运作的。用 Telegram，每个 group 对应一个 Agent，切换群就是切换上下文，通知独立，互不干扰。Desktop 的多会话是标签页，使用感受上还是串行的。
对我来说，调度优先于操作，异步优先于同步。Telegram 在这两点上都更强。
05 它的适用边界
说清楚适合谁：
适合用 Desktop 的人：
- 本地跑 Hermes，不想碰终端的用户
- 想可视化管理 skills、cron、profile、MCP 配置的用户
- 单机使用，不涉及远程连接
- 想要一个"设置中心"式入口的用户
暂时不适合把 Desktop 当主力入口的人：
- Hermes 跑在远程服务器
- 多 Agent 并行、重度 Telegram/Discord gateway 用户
- 在手机和多设备之间频繁切换
- 生产流程已经稳定，不想再多一层连接状态管理
我属于后者。
Public preview 阶段的产品，评判标准应该是"适不适合你的工作流"，而不是能不能完成连接验证。对我来说，暂时不适合。但这和产品方向对不对，是两件事。
06 我不会卸载，但会降级为辅助工具
留下来，但明确边界。
Desktop 作为辅助管理界面是有价值的：偶尔打开看 sessions、检查 profile 配置、调整 cron 任务、管理 skills。这些场景用 Desktop 比敲命令舒服，比改 YAML 直观。当我需要整理一批 MCP 配置，或者检查某个 skill 的参数设置，Desktop 是合适的工具。
但以下场景，Desktop 进不了我的主流程：
- 发送任务指令：继续走 Telegram
- 多 Agent 状态监控：继续走 Telegram 群组
- 重要任务触发和确认：继续走 CLI 或 Telegram
- Agent 产出审核：继续在 Telegram 里完成
Hermes Desktop 解决的是"GUI 入口"的问题，这个方向是对的。但我更关心的问题是：Agent 在跑吗？结果送到我手里了吗？我能从任意设备发指令吗？这些 Telegram 已经在做了，而且做得足够好。
本地用户，值得装。远程重度用户，先别期待太高。
👋 我是孟健，前腾讯 T11 / 前字节技术 Leader，现在全职做 AI 编程。
🔥 更多 AI 编程实战：
- GitHub：@mengjian-github
- 专栏：AI编程实战
觉得有用？点赞+收藏 就是最大支持 🙏