别把真实浏览器当成自动化靶场：Hands 如何给 Windows Agent 加上观察、确认与停止边界
让编码 Agent 操作浏览器，常见路线是启动一个隔离的自动化实例，再通过 Playwright、Puppeteer 或 DevTools Protocol 驱动它。这条路线适合测试，也适合可重复的网页任务；但当需求变成「在 Windows 桌面上辅助操作用户正在使用的 Chrome」，问题就完全不同了。Agent 触及的是已有登录态、真实标签页、可能产生付款或提交的界面。此时，能点击不代表应该点击，能够看见页面也不代表页面文字可信。
Hands 是一个面向 Windows 的 Rust MCP/CLI 项目。它让兼容 MCP 的 Agent 通过真实鼠标和键盘输入观察、点击、输入与滚动当前桌面上的 Chrome，而不是开启带远程调试端口的自动化浏览器。项目以 MIT 许可证发布。它最值得讨论的地方不是「绕过自动化」，而是把真实桌面操作显式视为高风险能力，并将观察、不可信内容、确认门和紧急停止写进工具契约。
两条链路：Chrome 原生消息与 Agent 工具调用
Hands 的安装说明把运行组件分为两部分：Chrome 通过 Native Messaging 启动本地 host；MCP/CLI 进程则提供 observe、click、type、scroll 等工具。Chrome 侧需要手动旁加载扩展，并在当前用户的注册表范围配置 native host；MCP 侧再让 Claude Code、Codex、OpenCode 等客户端调用同一个可执行文件。
这种拆分有两个工程含义。
第一，项目不会自动打开 Chrome 开发者模式、写入注册表或旁加载扩展。安装者必须亲自完成这些动作，也必须确认扩展权限与自己的浏览器 profile 相匹配。README 明确提示扩展为映射正在查看的标签页需要
第二，观察结果并不只是截图。工具会提供 UI Automation 和可选的 Chrome DOM 元素标识，例如 chr: 与 uia:。前者适合页面内容，后者是 Windows UIA 运行时标识，且在页面导航后可能变化。因此，Agent 不能把旧元素 ID 当作永久定位符；每次明显导航或 DOM 变动后，都应重新观察页面。
先观察，再判断：页面文字默认不可信
浏览器 Agent 的一个核心风险是提示注入。网页正文、广告、弹窗、截图中的文字都可能诱导模型泄露信息、修改账户或绕过既定任务。Hands 在文档里将截图像素、DOM/UIA 文本以及 listen 转录结果都标为不可信页面内容：它们可以作为观察数据，不能自动升级为指令。
这要求 Agent 编排层也遵守同样的边界。一个更可靠的循环是：先用 observe 获取当前状态；只把与用户目标相关的控件列为候选；对每一次可能改变外部状态的操作重新解释意图；页面出现「忽略此前指令」「立即输入密钥」之类内容时，将其记录为网页内容而不是执行命令。
项目还明确区分「日常 Chrome」与研究身份。日常 profile 不使用 Playwright、Puppeteer、CDP、--remote-debugging-port 或自动化标志；对于验证挑战，日常身份并不是自动解题器。这个约束不能消除网页风险，却避免了把日常账户环境直接包装成无边界的自动化机器人。
确认门不是 UI 的“允许”，而是工具内的第二道判定
真实浏览器里最危险的不是普通点击，而是提交表单、花钱、改变账号状态或对外发送信息。Hands 将确认逻辑放在二进制工具内：click 与回车类操作会对不可逆或灰色区域控件拒绝执行，只有在匹配域名与类别的确认许可后才能继续。也就是说，上层 Agent 或客户端 TUI 的“自动批准工具调用”不能替代这道确认门。
文档给出的流程是先遭到拒绝，再显式调用 confirm，然后重试原动作。它支持一次、会话或持久化的确认范围；在真实产品中，应优先使用最小范围的「一次确认」，并把确认对象、域名和操作类别呈现给用户。持久许可很容易把一次例外变成长期攻击面。
Hands 同时提示：确认门只是尽力分类，不是完整安全证明。一个按钮可能被错误识别，或站点将敏感操作伪装成普通流程。因此，金融、招聘投递、账号恢复、删除数据等动作仍应要求人类看清页面并最终确认。工具安全机制应被视为减损层，而不是授权替身。
可复现的本地构建与最小 MCP 接入
Hands 的 README 固定 Rust 工具链为 1.97.1，并提供 release 构建命令：
cd C:\dev\Helping-Hands\hands cargo build --release .\target\release\hands.exe --help
构建后，MCP 服务端以 mcp 子命令启动。以 Claude Code 为例，项目文档给出的用户范围接入形式如下：
claude mcp add --scope user hands -- ` C:\dev\Helping-Hands\hands\target\release\hands.exe mcp claude mcp list
这里有两个值得保留的验证点：一是先运行各客户端的 mcp add --help，不要凭印象猜测范围参数；二是把工具超时设置与操作类型匹配。观察或受确认门保护的任务可能比普通本地查询更慢，过短超时会制造“操作不确定是否已发生”的麻烦。
首次烟雾测试不应从表单提交开始。项目建议在普通 HTTPS 标签页完成 attach、observe，确认 chrome_connected 为真并看到 chr: 元素后，再测试无副作用的内容，例如关闭 cookie 提示或聚焦搜索框。测试中不要把 chrome://extensions 当成页面内容探针，因为内容脚本不会在该类页面运行。
物理控制权优先：停止、日志与最小权限
Hands 的输入操作会建立 desk lease：当工具正在注入鼠标或键盘时，物理鼠标键盘活动和 Pause/Break 可以中止操作；日志仍会保留。这个设计强调了一个朴素原则：当 Agent 正在接触真实桌面，用户必须始终拥有比 Agent 更高的控制优先级。
日志目录默认位于 %LOCALAPPDATA%\hands\logs\，文档称输入记录长度而非具体按键内容，观察记录计数而非完整正文。即便如此，日志依然可能包含操作时序、站点和敏感行为线索。部署时应设置保留策略、限制读取权限，并在共享故障报告前审查 JSONL 内容。
Hands 还提供 stop、logs、attach、challenge 等操作。它们不应被当作“给 Agent 更多自由度”的按钮，而应纳入运行手册：谁可以连接哪一个 profile，哪些域名允许执行低风险动作，出现挑战页、付款页或身份验证页时如何停止并转交给人类。
适合什么，不适合什么
Hands 适合个人或受控团队在 Windows 上研究真实网页、辅助填写低风险信息、调试浏览器交互，以及探索 MCP 到原生桌面的安全边界。它不适合作为无人值守的购物、招聘投递、账户管理或 CAPTCHA 处理系统；更不是隔离 sandbox。项目自己的免责声明已经指出，真实输入可能改变任意当前界面状态，网页内容也可能携带提示注入。
这套边界也决定了产品设计不能只看工具调用成功率。应记录每次操作的目标域名、元素来源（页面 DOM、UIA 还是截图）、确认范围和最终状态；遇到超时则先查询会话日志与页面状态，而不是盲目重放点击。重放尤其危险：原来的元素位置可能已经换成付款按钮，原来的确认上下文也可能已经过期。对于团队使用，建议把这些字段纳入审计事件，并将「被拒绝」「用户中止」与「工具报错」区分开来，方便复盘和调高或调低策略门槛。
如果你的目标是端到端测试或批量网页处理，隔离 browser profile 和传统自动化框架通常更合适。如果目标确实是让 Agent 协助使用日常 Chrome，那么重点应该从“怎样让它点得更快”转向“怎样让它在看错、被诱导或即将造成外部影响时可靠停下”。Hands 提供的是后一类问题的一个具体、可审阅的实现样本。