How to Give Hermes Agent a Persistent Browser Identity with Camofox

Neo 2026-04-21 21.8 KB 11.1K 165 𝕏 文章列表

文章介绍了如何通过配置 Camofox 反检测浏览器后端，为 Hermes Agent 赋持久的浏览器身份。通过开启持久化会话，Agent 能够跨任务保留 Cookie 和登录状态，从而将浏览器自动化从“无状态演示”转变为可复用的基础设施工作流。文章详细讲解了配置步骤、状态存储机制及验证方法。

Hermes Camofox Agent 浏览器自动化持久化反检测配置教程 DevOps Workflow 自动化

# How to Give Hermes Agent a Persistent Browser Identity with Camofox **作者**: Neo **日期**: 2026-04-21T09:08:20.000Z **来源**: [https://x.com/NeoAIForecast/status/2046516373984317735](https://x.com/NeoAIForecast/status/2046516373984317735) --- ![Image](/doc/908/image/img_e95e6d42451d.jpg) Most agent browser demos break the moment a login session matters. You sign in once, the task ends, and the next run starts from scratch. That is fine for toy browsing. It is terrible for real workflows. Hermes has a much better path: you can run it against Camofox, a self-hosted anti-detection browser backend, and configure persistent browser sessions so cookies and logins survive across agent runs. That turns browser automation from “stateless demo mode” into something much closer to a reusable operator workflow. Takeaway: persistent browser identity is the difference between agent browsing as a trick and agent browsing as infrastructure. ## Why this matters in Hermes Hermes supports several browser backends: - Browserbase - Browser Use - Firecrawl - Local Chromium via agent-browser - Local Chrome via CDP - Camofox for local anti-detection browsing Camofox is particularly interesting because it gives Hermes a self-hosted browser path with stronger stealth characteristics than a basic local browser, while still fitting into the same Hermes browser toolset. But the real unlock is not just “Hermes supports Camofox.” The real unlock is that Hermes can be configured so the browser identity becomes stable across sessions. That means: - Cookies can persist - Logins can persist - Repeated agent tasks do not always start from zero - Different Hermes profiles can keep different browser identities That last part is especially good. Takeaway: the browser layer gets much more useful when it inherits the same long-lived profile logic as the rest of Hermes. ## What Camofox is doing here Camofox is a self-hosted Node.js server that wraps Camoufox, a Firefox fork with fingerprint spoofing. In practical terms, that means: - You run the browser service yourself - Hermes routes browser tasks through it - The browsing environment can behave more like a durable operator browser than a disposable cloud session This is a very different story from “agent launches a fresh anonymous browser every time.” It is also useful if you want: - Local control - No cloud browser dependency - Anti-detection browsing - Profile-scoped persistence Takeaway: Camofox is Hermes’s local anti-detection browser backend, not just another generic browser integration. ## Step 1: Run the Camofox server There are two simple paths. Local install Docker Then point Hermes at it in ~/.hermes/.env: Or configure it through: ![Image](/doc/908/image/img_ec0562107d1a.jpg) ![Image](/doc/908/image/img_ca65264d36c9.jpg) Once CAMOFOX_URL is set, Hermes routes browser tools through Camofox instead of Browserbase or local agent-browser. That part is straightforward. Takeaway: The Camofox integration starts with one server URL, but the real value comes from what you do next. ## Step 2: Enable persistent sessions This is the most important part of the tutorial. By default, Camofox sessions are ephemeral. That means each session gets a random identity, and cookies/logins do not survive. To enable persistent browser sessions, add this to ~/.hermes/config.yaml: And then fully restart Hermes. > NOTE! If you put the flag at the wrong path, Hermes silently falls back to ephemeral sessions and your login state keeps disappearing. That is exactly the kind of configuration bug that wastes hours. Takeaway: If managed_persistence is not nested under browser.camofox, Hermes will ignore it and your sessions will still reset. What Hermes actually does This is where it gets more interesting than a normal setup guide. When persistent mode is enabled, Hermes does three important things: Sends a deterministic profile-scoped userId to Camofox Skips server-side context destruction on cleanup Scopes that identity to the active Hermes profile That third point is a big deal. It means if you have multiple Hermes profiles, each one can map to a different persistent browser identity. So you can have: - One profile for research browsing - One profile for work automation - One profile for personal browsing tasks …and keep those browser identities separated the same way Hermes separates memory, sessions, and config. Takeaway: Persistent Camofox sessions inherit Hermes’s profile model, which makes browser identity part of the broader agent architecture. What Hermes does *not* do Hermes does not force persistence on the Camofox server by magic. Hermes only sends a stable userId. The Camofox server itself must actually honor that userId by mapping it to a persistent Firefox profile directory. So if your Camofox build treats every request as disposable, Hermes cannot fix that from its side. That is an important distinction because a lot of people will assume: > “I turned on persistence in Hermes, so persistence is guaranteed.” Not necessarily. The server has to support it correctly. Takeaway: Hermes can provide a stable browser identity handle, but the Camofox server must implement real profile persistence for it to work. ## Step 3: Verify it actually works The test flow is: Start Hermes and your Camofox server Open a login site such as Google Sign in manually End the browser task normally Start a new browser task Open the same site again If persistence is working, you should still be signed in. If you are logged out, the likely causes are: - managed_persistence is at the wrong config path - Hermes was not fully restarted - the Camofox server is not honoring stable per-user profiles - your server build is effectively still ephemeral That troubleshooting path is exactly why this article is useful: it saves people from thinking “Hermes persistence is broken” when the problem is often in the backend behavior or config nesting. Takeaway: The real test for persistent browser identity is not config presence it is whether login state survives a fresh browser task. ## Where the state lives Hermes derives the stable userId from a profile-scoped directory like: Or the equivalent under "$HERMES_HOME" for non-default profiles. But the actual browser profile data lives on the Camofox server side, keyed by that userId. That means if you want to fully reset a persistent browser profile, you may need to: - clear it on the Camofox server - remove the corresponding Hermes profile state directory This is another place people can get confused. Deleting one local file is not necessarily enough if the server still holds the browser profile state. Takeaway: Hermes owns the stable identity handle; the Camofox server owns the actual persisted browser profile. ## Why this is more interesting than cloud browser sessions Cloud browser backends are useful. But persistent local Camofox sessions are interesting for a different reason. They let Hermes operate more like a durable browser operator. That matters when your workflow depends on: - existing login state - cookies - repeat visits to the same service - anti-detection browsing - long-lived identity separation across profiles That is much closer to how human operators use browsers and it fits the broader Hermes story extremely well: durable state, profile isolation, reusable workflows, and less repeated setup. Takeaway: Camofox persistence makes Hermes browsing feel much more like an ongoing environment than a disposable task sandbox. ## Bonus: VNC live view There is another good feature in the browser When Camofox runs in headed mode, it can expose a VNC port in its health check response. Hermes can discover that automatically and include the VNC URL in navigation responses, so you can watch the browser live. That is a nice advanced operator feature because it gives you: - Observability - Easier debugging - A better human-in-the-loop path for complex browsing tasks This is especially useful when the browser is logged into a real account and you want visibility into what the agent is doing. Takeaway: Headed Camofox plus VNC turns Hermes browser automation into something you can supervise, not just trust blindly. ## When to use this setup This setup is a strong fit if you want Hermes to handle workflows like: - Repeated logins to the same sites - Anti-detection browsing without cloud dependency - Profile-separated browser identities - Local operator control over browser state - Browser tasks that should feel continuous across sessions It is less necessary if all you want is: - Occasional stateless browsing - Quick scraping - One-off page interaction - Zero interest in preserving login state In that case, the simpler browser backends may be enough. Takeaway: Persistent Camofox mode is for browser workflows with continuity, not just isolated page interactions. ## Common failure modes 1. Wrong config path This is the big one. Use: Not: 2. No full restart Editing config without restarting Hermes can leave you testing old behavior. 3. Backend mismatch Hermes is sending a stable userId, but your Camofox server may still be creating ephemeral contexts. 4. Expecting Hermes profiles to be security sandboxes They are state boundaries, not filesystem sandboxes. What they do give you here is browser identity separation, which is exactly the useful thing. Takeaway: Most persistence bugs in this setup come from config path errors or backend assumptions, not from the Hermes browser toolset itself. ## Conclusion Most browser-agent tutorials stop at navigation and screenshots. The more important question is whether the browser environment can persist in a useful way. With Camofox, Hermes has a path to that. You can run a self-hosted anti-detection browser backend, route Hermes through it, and configure persistent sessions so login state survives across agent runs with browser identity scoped to Hermes profiles. That is a much more serious pattern than stateless browser demos. Takeaway: Persistent Camofox sessions are one of the clearest ways to turn Hermes browser automation into long-lived infrastructure. ## 相关链接 - [Neo](https://x.com/NeoAIForecast) - [@NeoAIForecast](https://x.com/NeoAIForecast) - [859](https://x.com/NeoAIForecast/status/2046516373984317735/analytics) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [5:08 PM · Apr 21, 2026](https://x.com/NeoAIForecast/status/2046516373984317735) - [859 Views](https://x.com/NeoAIForecast/status/2046516373984317735/analytics) --- *导出时间: 2026/4/21 18:58:26* --- ## 中文翻译 # 如何用 Camofox 给 Hermes Agent 一个持久的浏览器身份 **作者**： Neo **日期**： 2026-04-21T09:08:20.000Z **来源**： [https://x.com/NeoAIForecast/status/2046516373984317735](https://x.com/NeoAIForecast/status/2046516373984317735) --- ![Image](/doc/908/image/img_e95e6d42451d.jpg) 大多数 agent 浏览器演示，一旦涉及登录会话就会失效。你登录一次，任务结束，下一次运行又从零开始。这对玩具式浏览来说没什么问题，但对真实工作流来说却很糟糕。 Hermes 有一条好得多的路径：你可以让它对接 Camofox——一个自托管的反检测浏览器后端，并配置持久化的浏览器会话，让 cookies 和登录状态在多次 agent 运行之间得以保留。这将浏览器自动化从“无状态的演示模式”转变成了更接近可复用的操作员工作流的东西。要点：持久化的浏览器身份，是“把 agent 浏览当作花招”与“把 agent 浏览当作基础设施”之间的分水岭。 ## 为什么这在 Hermes 中很重要 Hermes 支持多种浏览器后端： - Browserbase - Browser Use - Firecrawl - 通过 agent-browser 使用本地 Chromium - 通过 CDP 使用本地 Chrome - 用于本地反检测浏览的 Camofox Camofox 尤其有趣，因为它为 Hermes 提供了一条自托管的浏览器路径，比基本的本地浏览器具有更强的隐匿特性，同时仍然融入同一套 Hermes 浏览器工具集。但真正的关键不只是“Hermes 支持 Camofox”。真正的关键在于，Hermes 可以被配置成让浏览器身份跨会话保持稳定。这意味着： - Cookies 可以持久保存 - 登录状态可以持久保存 - 重复的 agent 任务不必每次都从零开始 - 不同的 Hermes profile 可以保留不同的浏览器身份最后一点尤其好用。要点：当浏览器层继承了与 Hermes 其他部分相同的长效 profile 逻辑时，它的用处会大大提升。 ## Camofox 在这里做了什么 Camofox 是一个自托管的 Node.js 服务器，它封装了 Camoufox——一个带指纹伪装功能的 Firefox 分支。实际来说，这意味着： - 你自己运行浏览器服务 - Hermes 通过它来路由浏览器任务 - 浏览环境的表现可以更像一个持久使用的操作员浏览器，而不是一次性的云会话这与“agent 每次都启动一个全新的匿名浏览器”是完全不同的故事。如果你想要以下功能，它也很有用： - 本地控制 - 不依赖云浏览器 - 反检测浏览 - 基于 profile 范围的持久化要点：Camofox 是 Hermes 的本地反检测浏览器后端，而不只是又一个普通的浏览器集成。 ## 第 1 步：运行 Camofox 服务器有两条简单的路径。本地安装 Docker 然后在 ~/.hermes/.env 中让 Hermes 指向它：或者通过以下方式进行配置： ![Image](/doc/908/image/img_ec0562107d1a.jpg) ![Image](/doc/908/image/img_ca65264d36c9.jpg) 一旦设置了 CAMOFOX_URL，Hermes 就会通过 Camofox 路由浏览器工具，而不是 Browserbase 或本地 agent-browser。这一部分很直接。要点：Camofox 的集成从一条服务器 URL 开始，但真正的价值来自你接下来要做的事情。 ## 第 2 步：启用持久化会话这是本教程最重要的部分。默认情况下，Camofox 会话是临时的。这意味着每个会话都会获得一个随机身份，cookies/登录状态不会保留。要启用持久化浏览器会话，请在 ~/.hermes/config.yaml 中添加：然后完全重启 Hermes。 > 注意！如果你把该配置项放在了错误的路径上，Hermes 会静默回退到临时会话，你的登录状态会不断消失。这正是那种会浪费好几个小时的配置 bug。要点：如果 managed_persistence 没有嵌套在 browser.camofox 之下，Hermes 会忽略它，你的会话仍然会重置。 Hermes 实际做了什么这是它比一般的设置指南更有意思的地方。当持久化模式启用后，Hermes 会做三件重要的事：向 Camofox 发送一个确定性的、基于 profile 范围的 userId 在清理时跳过服务器端的上下文销毁将该身份限定于当前激活的 Hermes profile 第三点非常关键。它意味着如果你有多个 Hermes profile，每一个都可以映射到不同的持久化浏览器身份。所以你可以拥有： - 一个用于研究浏览的 profile - 一个用于工作自动化的 profile - 一个用于个人浏览任务的 profile ……并像 Hermes 分隔记忆、会话和配置那样，把这些浏览器身份彼此分开。要点：持久化的 Camofox 会话继承了 Hermes 的 profile 模型，这使得浏览器身份成为整个 agent 架构的一部分。 Hermes *没有*做什么 Hermes 并不会用魔法强行让 Camofox 服务器实现持久化。 Hermes 只是发送一个稳定的 userId。 Camofox 服务器本身必须真正地遵从该 userId，将它映射到一个持久化的 Firefox profile 目录。所以如果你的 Camofox 版本把每个请求都当作一次性的来处理，Hermes 无法从它那一侧修复这个问题。这是一个重要的区别，因为很多人会想当然地认为： > “我在 Hermes 里开启了持久化，所以持久化就有保障了。” 不一定。服务器必须正确地支持它。要点：Hermes 可以提供一个稳定的浏览器身份句柄，但 Camofox 服务器必须实现真正的 profile 持久化，它才能生效。 ## 第 3 步：验证它确实有效测试流程是：启动 Hermes 和你的 Camofox 服务器打开一个需要登录的网站，例如 Google 手动登录正常结束该浏览器任务启动一个新的浏览器任务再次打开同一个网站如果持久化正常工作，你应该仍处于登录状态。如果你被登出了，可能的原因有： - managed_persistence 放在了错误的配置路径上 - Hermes 没有被完全重启 - Camofox 服务器没有遵从稳定的按用户 profile - 你的服务器版本实际上仍然是临时会话这套排错路径正是这篇文章有价值的原因：它让人们不会误以为“Hermes 的持久化坏了”，而问题往往出在后端行为或配置嵌套上。要点：持久化浏览器身份的真正考验不在于配置是否存在，而在于登录状态能否在一次全新的浏览器任务中保留下来。 ## 状态存储在哪里 Hermes 从一个配置文件作用域的目录中派生出稳定的 userId，例如：或者非默认配置文件时使用 "$HERMES_HOME" 下的等效路径。但实际的浏览器配置文件数据存储在 Camofox 服务器端，并以该 userId 作为键。这意味着如果你想完全重置一个持久化的浏览器配置文件，你可能需要： - 在 Camofox 服务器上清除它 - 删除对应的 Hermes 配置文件状态目录这是另一个容易让人困惑的地方。如果服务器仍然持有浏览器配置文件状态，仅仅删除一个本地文件是不够的。要点：Hermes 拥有稳定的身份句柄；Camofox 服务器拥有实际持久化的浏览器配置文件。 ## 为什么这比云端浏览器会话更有意思云端浏览器后端很有用。但持久化的本地 Camofox 会话之所以有意思，是出于不同的原因。它们让 Hermes 的运作更接近一个持久的浏览器操作者。当你的工作流依赖于以下内容时，这一点非常重要： - 已有的登录状态 - Cookie - 对同一服务的重复访问 - 反检测浏览 - 跨配置文件的长期身份隔离这更接近于人类操作者使用浏览器的方式，也非常契合 Hermes 的整体理念：持久的状态、配置文件隔离、可复用的工作流，以及更少的重复设置。要点：Camofox 持久化让 Hermes 的浏览体验更像是一个持续运行的环境，而不是一次性的任务沙盒。 ## 附加功能：VNC 实时查看浏览器还有一个不错的功能当 Camofox 以有界面（headed）模式运行时，它可以在健康检查响应中暴露一个 VNC 端口。 Hermes 可以自动发现它，并将 VNC URL 包含在导航响应中，这样你就可以实时观看浏览器。这是一个很棒的高级操作者功能，因为它为你提供： - 可观测性 - 更容易的调试 - 更好的复杂浏览任务人工介入路径当浏览器登录了真实账号、而你想了解智能体正在做什么时，这一点尤其有用。要点：有界面的 Camofox 加上 VNC，让 Hermes 的浏览器自动化变成了一个可以监督的过程，而不只是盲目信任。 ## 何时使用这种配置如果你希望 Hermes 处理以下类型的工作流，这种配置非常合适： - 重复登录相同的网站 - 不依赖云端的反检测浏览 - 按配置文件隔离的浏览器身份 - 对浏览器状态的本地操作者控制 - 需要在多次会话间保持连续性的浏览器任务如果你只是想要： - 偶尔进行无状态浏览 - 快速抓取 - 一次性的页面交互 - 完全不需要保留登录状态那么这种配置就没有太大必要，更简单的浏览器后端可能就足够了。要点：持久化 Camofox 模式适用于具有连续性的浏览器工作流，而不只是孤立的页面交互。 ## 常见故障模式 1. 配置路径错误这是最大的问题。应该使用：而不是： 2. 没有完全重启编辑配置后不重启 Hermes，可能会让你测试的仍是旧行为。 3. 后端不匹配 Hermes 正在发送稳定的 userId，但你的 Camofox 服务器可能仍在创建临时上下文。 4. 期望 Hermes 配置文件是安全沙盒它们是状态边界，而不是文件系统沙盒。它们在这里真正提供的是浏览器身份隔离，而这正是有用的部分。要点：这种配置下的大多数持久化问题源于配置路径错误或后端假设，而不是 Hermes 浏览器工具集本身。 ## 结论大多数浏览器智能体教程都止步于导航和截图。更重要的问题是：浏览器环境能否以有用的方式持久化。借助 Camofox，Hermes 拥有了实现这一目标的路径。你可以运行一个自托管的反检测浏览器后端，将 Hermes 路由到它，并配置持久化会话，使登录状态在智能体多次运行之间得以保留，同时浏览器身份被限定在 Hermes 配置文件范围内。这是一个比无状态浏览器演示严肃得多的模式。要点：持久化 Camofox 会话是将 Hermes 浏览器自动化转变为长期基础设施的最清晰方式之一。 ## 相关链接 - [Neo](https://x.com/NeoAIForecast) - [@NeoAIForecast](https://x.com/NeoAIForecast) - [859](https://x.com/NeoAIForecast/status/2046516373984317735/analytics) - [升级到 Premium](https://x.com/i/premium_sign_up) - [2026年4月21日下午5:08](https://x.com/NeoAIForecast/status/2046516373984317735) - [859 次浏览](https://x.com/NeoAIForecast/status/2046516373984317735/analytics) --- *导出时间: 2026/4/21 18:58:26*