自动安装脚本最怕的不是失败，而是停在一个没人能输入的密码提示上。
NousResearch/hermes-agent issue #25816 讲的就是这个问题：用户在 Debian 上用一个专门的非 sudo 系统用户 hermes 安装 Hermes，安装器跑到 Playwright Chromium 依赖步骤时突然要求输入 sudo 密码。
日志停在这里：
✓ Node.js dependencies installed
→ Installing browser engine (Playwright Chromium)...
→ Playwright may request sudo to install browser system dependencies (shared libraries).
→ This is standard Playwright setup — Hermes itself does not require root access.
Installing dependencies...
Switching to root user to install dependencies...
[sudo] password for hermes:问题是：这个 hermes 用户本来就是专门用于跑服务的非 sudo 用户。
它没有 sudo 密码，也不该有 sudo 权限。
于是安装器直接卡死。
表面问题：Playwright 要装 Chromium 依赖
Hermes 安装流程里有一步：
install_node_deps其中会执行类似：
npx playwright install --with-deps chromium--with-deps 在 Debian / Ubuntu 这类系统上可能会调用 apt 安装浏览器系统依赖。
这一步需要 root 权限。
如果当前用户没有免密 sudo，就会出现：
[sudo] password for hermes:对交互式普通用户来说，这可能只是输入密码。
但对 dedicated service user 来说，这就是死局。
真正严重的点：它卡在 setup_path 之前
这个 issue 最值得写的地方，不是 Playwright 安装失败。
而是安装顺序。
issue 中指出，main() 的调用顺序大概是：
install_deps
install_node_deps # 卡在这里
setup_path # 还没执行这意味着 Playwright 这个浏览器相关的可选步骤卡住后，后面的 setup_path() 根本没有机会运行。
结果是：
1. hermes 命令没有被放进 PATH； 2. 用户不能运行 hermes doctor； 3. 直接跑原始入口可能绕过 venv launcher； 4. 最后出现看似不相关的 Python 依赖错误。
例如：
ModuleNotFoundError: No module named 'dotenv'用户可能会误以为是 Python 包没装好。
但真正原因是安装流程前面被可选浏览器步骤卡断，launcher shim 没创建。
为什么这是安装器设计问题？
浏览器能力通常是增强功能，不应该阻断核心 CLI 安装。
换句话说：
没有 Chromium，Hermes 可以先安装好；
没有 hermes 命令，用户连排查入口都没有。所以更合理的优先级应该是：
1. 先保证核心命令可用； 2. 再安装可选浏览器能力； 3. 如果浏览器依赖装不了，给出清晰手动命令； 4. 不要让非 sudo 用户停在 sudo prompt 上。
这个问题为什么常见于服务用户安装？
很多生产环境会创建一个专门用户：
useradd --system --create-home hermes然后把服务、配置、数据目录都放在这个用户下。
这样做的好处是：
- 权限最小化；
- 不用 root 跑 Agent；
- 日志和数据归属清楚；
- systemd 服务更容易隔离。
但这种用户通常：
- 没有 shell 登录密码；
- 不在 sudoers；
- 不能执行
apt install； - 也不应该被要求安装系统包。
所以安装脚本遇到这种环境时，不能假设用户能完成 sudo prompt。
更合理的行为：先检测 sudo -n
issue 里提到，Hermes 的其他安装步骤已经有类似思路：
sudo -n true这条命令的意义是：
检查当前用户是否可以免交互 sudo。如果不行，就不要进入会卡住的 sudo prompt。
对 Playwright 步骤也应该类似：
- 如果有 passwordless sudo：可以自动安装系统依赖；
- 如果没有：跳过
--with-deps，提示用户手动安装； - 如果没有 TTY：默认跳过，不要阻塞；
- 如果有 TTY：可以询问是否安装浏览器引擎。
用户侧怎么判断自己踩中了这个坑？
如果你的安装卡在：
Installing browser engine (Playwright Chromium)然后出现：
[sudo] password for hermes:同时你使用的是：
- Debian / Ubuntu；
- dedicated service user；
- 非 sudo 用户；
- systemd 服务账号；
那基本就是这个问题。
另一个典型信号是：中断安装后发现：
hermes doctor不存在。
这说明安装还没跑到 PATH / launcher 配置阶段。
临时规避方案
在修复版本前，可以考虑几种方式。
方案一：先用有 sudo 权限的管理员安装系统依赖
让管理员手动安装 Playwright 所需依赖，然后服务用户只安装 Hermes 本体。
这符合权限分离：系统包由管理员装，服务用户只跑应用。
方案二：跳过浏览器步骤，先保证 Hermes CLI 可用
如果安装器支持环境变量或参数跳过 Playwright，优先跳过浏览器工具。
核心目标是先拿到：
hermes
hermes doctor浏览器能力可以稍后补。
方案三：不要用非 sudo 用户跑全自动安装器
如果安装器当前没有 graceful fallback，可以先用普通管理用户完成安装，再调整运行用户和服务权限。
这不是最优雅，但比半安装状态更可控。
方案四：升级到包含相关 PR 的版本
评论里指出这是 #22152 的重复问题，并提到：
- PR
#25814 - PR
#23500
都在处理这个方向。
升级时重点看安装器是否已经：
- 避免卡在 sudo prompt；
- 把 Playwright 设为可选步骤；
- 在非交互环境下跳过浏览器安装；
- 保证
setup_path()不被可选步骤阻断。
对 DeepAI API 中转站用户的边界说明
这篇问题发生在 Hermes 安装器和 Playwright 浏览器依赖步骤，不在模型 API 层。
DeepAI API 中转站能帮你解决的是：
- OpenAI-compatible Base URL；
- API Key 管理；
- 模型调用入口统一；
- 在支持自定义 Base URL 的客户端中切换模型。
但它不能修复：
- 安装器卡在 sudo prompt；
- systemd 服务用户没有 sudo 权限；
- Playwright 系统依赖安装；
- PATH launcher 没创建。
所以排查这类问题时，要先分层：
安装器 / 系统依赖 / PATH和：
模型 API / Base URL / API Key不是同一层。
FAQ
为什么 Hermes 安装要装 Playwright？
Playwright 用于浏览器相关能力，例如网页自动化或浏览器工具。它是增强能力，不应该阻断核心 CLI 安装。
为什么非 sudo 用户会卡住？
因为 npx playwright install --with-deps chromium 可能调用系统包管理器，需要 root 权限。非 sudo 用户无法完成密码提示。
为什么中断后 hermes doctor 不存在？
因为安装流程卡在 install_node_deps，还没执行后面的 setup_path()，launcher shim 没创建。
ModuleNotFoundError: No module named dotenv 是根因吗？
通常不是。它可能是你绕过 launcher 直接运行原始入口导致系统 Python 被使用。根因仍是安装未完成。
最理想修复是什么？
Playwright 浏览器步骤应可选、可跳过、非致命；在没有免密 sudo 或没有 TTY 时，不应阻塞整个安装。
总结
#25816 的核心教训是：
可选浏览器步骤，不应该卡死核心安装流程。对安装器来说，最重要的不是把所有增强能力一次装完，而是保证失败可恢复、命令可用、诊断入口存在。
如果一个非 sudo 服务用户因为 Playwright 的 sudo prompt 卡住，最后连 hermes doctor 都没有，那问题就不只是 Playwright，而是安装器的容错顺序需要调整。