8.0
热点
AI SCORE
技术实践2026-08-28 01:26
Hermes Agent生产级大规模部署架构指南
dev.to · AI#Agent#生产部署#架构
Editor brief · 编辑速览
文章提出生产环境托管Hermes Agent的五层平面架构（区别于单VM单Agent的传统做法），涵盖健康恢复、容错、权限隔离等工程挑战。
让一个 Hermes Agent 完成一项有用的任务是一个产品里程碑。
让一群 Hermes Agents 在真实业务系统周围保持健康、可恢复和安全地运行，则是一个运维问题。
一旦 Agent 开始负责演示之后仍然需要继续的工作，这两者之间的差异就会显现出来：
它会维护一个工作空间和任务历史；
它会连接到模型提供商和外部工具；
它会通过浏览器、API、文件和消息渠道执行操作；
它可能产生无法简单重放副作用；
它必须能够承受提供商故障、运行时崩溃、升级和凭证过期。
一台能启动 Hermes 的服务器只是第一层。生产环境托管必须保留 Agent 正确完成工作的能力。
如果需要先了解框架层面的介绍，[Hermes agents, explained] 涵盖了 Hermes 是什么以及它与临时 Agent 任务有何不同。本指南专注于围绕它构建的生产层。
本指南提出了一种架构，可以在不复制常见的「每个 Agent 一台 VM」方案的情况下实现这一目标。
不要把 Hermes 部署当作一个进程加一个配置文件来处理。将其拆分为五个具有不同职责的平面。
Hermes production environment
|
+-- Runtime plane
| process, version, dependencies, compute
|
+-- State plane
| workspace, memory, task ledger, restore points
|
+-- Inference plane
| provider, model, fallback routes, budgets
|
+-- Tool plane
| integrations, browser, credentials, approvals
|
+-- Operations plane
health, logs, recovery, upgrades, human handoff
这种分离很重要，因为各个平面的故障模式不同。
运行时可能存活而其提供商却受到速率限制。模型可能正常响应而浏览器会话却卡在登录后面。工具可能成功而 Agent 却未能记录结果。一个替换进程可能完美启动而它所需要的工作空间却缺失。
如果所有五个平面被捆绑成一个模糊的「Agent 在线」状态，运维人员只能从用户那里得知故障。如果将它们分开建模，每个故障都有一个清晰的信号和恢复路径。
Hermes 进程应该易于替换，而不会破坏它所服务的 Agent。
固定运行时版本，而不是追随无限制的最新版本。在旁边记录配置版本，并从可重复的定义而非一系列手动 shell 命令来构建实例。
运行时平面应该只包含执行当前实例所需的内容：
固定的 Hermes 版本；
系统和语言依赖项；
活动配置引用；
资源预留和限制；
健康端点或监督信号；
持久状态的挂载或连接。
避免让运行中的机器成为重要文件的唯一存在地。如果替换一个故障进程意味着要从刚发生故障的磁盘上重建它的个性、凭证、内存和工作，那说明运行时并不是一次性的。
测试很简单：平台能否终止一个不健康的 Hermes 进程，在其他地方重新创建它，重新连接其状态和工具，并恢复服务而无需手动考古？
Hermes 有多种形式的状态，它们并不都值得相同的保留策略。
在选择存储之前先对状态进行分类：
Hermes 在破坏性操作之前包含可选的文件系统检查点。这对项目变更是有用的保护，但它不是完整的连续性策略。生产环境仍然需要备份、保留规则，以及一个解释文件系统之外发生的事情的任务账本。
对于每个活动任务，至少记录：
{
"task_id": "research-1842",
"state": "waiting_for_approval",
"last_safe_step": "sources_collected",
"pending_action": "send_report",
"workspace_version": "ws-91",
"updated_at": "2026-08-27T16:00:00Z"
}
这条记录给替换运行时提供了一个比转录本更可靠的分析依据。
Hermes 可以跨多个模型提供商、聚合器和 OpenAI 兼容端点工作。它还支持辅助任务的备用路由和独立模型。
这种灵活性是有价值的，但提供商兼容性并不等同于行为等效。
新路由可能改变：
结构化输出的可靠性；
延迟和速率限制；
每个已完成任务的成本。
为每个 Agent 角色定义一个能力契约。浏览器操作员、编码 Agent、支持 Agent 和研究 Agent 不应该仅仅因为四个模型都返回文本就继承相同的备用方案。
在工作开始前，将备用方案用于已知的路由失败（如中断或速率限制）。不要在一次模糊的外部操作之后盲目切换提供商。不同的模型并不知道第一条路由是否已经发送了邮件、更改了记录或提交了表单。
多提供商支持应该是托管架构内部的一种弹性机制，而不是忽略状态和副作用的理由。
工具平面是 Hermes Agent 接触真实世界的地方。
保持面向模型的接口稳定，即使底层集成发生变化。每个工具应该定义：
严格的输入模式；
明确的读写分类；
超时和重试策略；
幂等性行为；
审批要求；
可以独立于模型响应记录的结果。
例如，一个 send_email 工具不应该向每个 Agent 暴露一个全局邮箱凭证。工具层应该解析正确的发件人身份、验证收件人和审批策略、附加操作 ID、发送一次，然后持久化外部引用。
{
"operation_id": "invoice-2026-184-client-42",
"tool": "send_email",
"state": "completed",
"external_reference": "message-93821",
"agent_id": "billing-agent-42"
}
当模型或运行时在发送后发生故障，下一个进程可以检查此记录而不是再次发送。
这个模式对于浏览器自动化尤其重要。页面点击可能成功，即使浏览器后来超时。恢复应该在重复操作之前检查目标状态。
自主 Agent 需要凭证，但凭证不应该成为普通的工作空间文件。
为每个 Agent 和集成使用范围受限的访问。保持生产、预发和评估凭证的分离。独立于业务系统凭证轮换提供商密钥，并在 Agent 停用时移除访问权限。
操作环境应该能够回答：
哪个 Agent 可以使用此凭证？
哪些工具可以接收它？
它是只读的还是具有写能力的？
上次使用是什么时候？
它的 OAuth 会话是否已过期？
在受保护操作之前需要什么审批？
永远不要依赖模型从提示中记住访问策略。在工具和凭证层强制执行边界。
一个健康的进程是必要的，但它是一个微弱的生产信号。
主机可能报告 Hermes 在线，而实际上：
活动提供商拒绝请求；
Agent 无法访问所需的工具；
浏览器卡在登录界面；
OAuth 令牌已过期；
任务循环在无进展地重复；
Agent 声称完成但没有创建预期结果。
使用分层健康检查：
基础设施健康：计算环境是否可达？
运行时健康：Hermes 是否以预期版本和配置运行？
推理健康：所选路由是否能在延迟预算内响应？
工具健康：所需依赖项能否认证并执行安全检查？
任务健康：Agent 是否在向定义的完成条件推进？
第五层是用户关心的层。
对于 recurring 工作流，添加综合任务来 exercise 真实路径而不产生副作用。一个支持 Agent 可能会读取一个 seeded 工单，对其进行分类，并产生一份草稿回复。一个浏览器 Agent 可能会登录一个测试账户并验证一个已知元素。一个研究 Agent 可能会检索一个受控页面并返回校验和。
按任务类、Helmet 版本、提供商路由和工具依赖跟踪成功。这使得回归在影响整个舰队之前就可见。
重启进程只是第一个恢复操作。
一个有用的恢复阶梯从最便宜的 safe 操作移到最具侵入性的操作：
1. 重试只读依赖调用
2. 刷新陈旧的会话或凭证
3. 切换符合条件的推理路由
4. 重启 Hermes 进程
5. 在相同的持久状态周围重新创建运行时
6. 恢复已知良好的工作空间或配置版本
7. 暂停副作用并请求人工审查
每个步骤都应该有 limit。无尽的重试可能产生速率限制风暴、重复操作和虚假的可用性印象。
恢复也需要上下文。任务开始前的提供商中断可以安全地路由绕过。表单提交后的超时是一个模糊的写操作。前者可以积极地自动化。后者需要协调。
记录每个恢复尝试的原因、动作和结果。否则同一个破碎的实例可以循环重启而没有人知道实际发生了什么故障。
Agent 运行时升级可以改变不仅仅是启动行为。它可以影响工具定义、提供商路由、内存、提示、浏览器行为和存储状态的形状。
不要一次性升级所有 Agent。
针对候选版本重放一组经过清理的已完成任务。
首先运行内部或低风险 Agent。
用可逆工作对一小批生产环境进行金丝雀测试。
比较完成率、工具错误、延迟、恢复和人工升级。
按任务类扩展，而不仅仅是按舰队百分比。
保持之前的运行时、配置和工作空间版本可用以进行回滚。
当不同工作流有不同风险容忍度时，按 Agent 固定版本是有用的。研究舰队可以在计费或客户通信舰队之前采用新版本。
回滚单元必须包含所有耦合部分。仅仅恢复 Hermes 二进制文件而留下不兼容的配置或更改的工作空间并不是完整的回滚。
Hermes 工作负载不是平坦的。一个 Agent 可以安静地等待，然后调用多个工具、处理一个大结果、打开浏览器会话或分叉辅助工作。
保证基线 CPU 和内存；
高于基线的短期突发；
昂贵任务的并发限制；
恢复和升级的空间；
当提供商或工具容量受到约束时进行背压。
每个 Agent 专用 VM 很简单，但它通常会迫使在限制突发的小型机器和大部分时间空闲的大型机器之间做出糟糕的选择。当预留、限制、准入控制和噪声邻居保护被明确设计时，共享容量可以更高效。
目标不是最大密度。是在负载下可预测的任务完成。
一些 Hermes 任务应该停止而不是自动恢复。
为以下情况创建明确的交接状态：
缺失或冲突的指令；
需要用户操作的过期凭证；
结果未知的外部操作；
等待审批的受保护决策；
所有符合条件的模型路由上的重复行为故障；
无法安全恢复的工作空间冲突。
交接应该包含任务、当前状态、证据、已采取的操作，以及人工所需的最少决策。
这比让进程在线而 Agent 循环或无声地放弃任务要好。
你可以在通用云基础设施上构建这个架构。问题是运营它是否是你产品优势的一部分。
Hermes 的生产平台需要的不仅仅是计算：
可重复的运行时配置；
持久化和版本化的工作空间；
提供商路由和备用策略；
范围受限的集成和浏览器会话；
副作用跟踪；
分层健康检查；
恢复和回滚；
升级、容量控制和人工交接。
如果这些能力是你的产品的核心，构建它们可能有意义。如果它们是你实际销售的 Agent 服务的底层基础设施，托管托管可以消除大量差异化的工作。
Molted 的托管 Hermes 托管将 Hermes 提供为托管生产环境，具有版本化的工作空间、自动恢复、浏览器自动化、1,000+ 集成、每个 Agent 的电子邮件和语音、生命周周期控制，以及托管云或本地部署。
相关比较不是托管环境与 VM 标价之间的比较，而是完整操作层与构建和维护它所需的工程和值班负载之间的比较。
在为企业客户或业务关键工作流托管 Hermes Agents 之前，验证以下内容。
在生产环境中托管 Hermes 不仅仅是保持一个 Python 进程运行。
它是关于在 Agent 周围保持一个可靠的运行边界：可替换的运行时、持久状态、弹性推理、受治理的工具、可观察的工作，以及理解副作用的恢复。
分别构建这些平面，一起测试它们，并使每次变更都可逆。这就是将一个有用的 Hermes Agent 转变为一个团队可以在规模上操作的服务的关键。
相关链接
Hermes agents, explained
Hermes Agent provider integrations
Hermes Agent fallback providers
Hermes Agent checkpoints and rollback
Kylian Cros 是 Molted 的联合创始人兼 CMO/GTM。Molted 为自主 Agent 提供托管运营环境，包括 Hermes 和 OpenClaw 舰队。