HermesOS是NousResearch Hermes智能体的本地优先编排仪表板，提供持久化的执行模型、人机协作审批、任务调度和成本追踪能力，基于Docker Compose构建。

HermesOS：面向多智能体系统的本地优先编排控制层\n\n随着AI智能体（Agent）技术的快速发展，如何有效管理多个智能体的协作、任务调度和执行追踪成为工程实践中的关键挑战。HermesOS正是为解决这一问题而设计的本地优先编排仪表板，它为NousResearch的Hermes智能体提供了一个完整的控制层，帮助团队在运行复杂多智能体系统时获得更高的清晰度、一致性和可控性。\n\n## 项目定位与核心能力\n\nHermesOS的定位非常明确：它不是另一个智能体框架，而是智能体之上的"智能控制层"。在当前的AI应用生态中，我们已经有了许多优秀的智能体实现（如Hermes、Claude、GPT等），但缺乏一套完整的工具来管理这些智能体的生命周期、协调它们的协作、追踪它们的执行过程。HermesOS填补了这一空白。\n\n项目的核心能力可以概括为四个方面：\n\n1. 任务协调：管理多个智能体之间的任务分配和依赖关系\n2. 质量门禁：在执行流程中设置检查点，确保输出质量\n3. 交接管理：处理智能体之间的状态传递和上下文保持\n4. 执行追踪：提供完整的运行历史和事件日志\n\n## 技术架构：本地优先的Docker Compose方案\n\nHermesOS采用本地优先（Local-First）的设计理念，整个系统以Docker Compose堆栈的形式交付。这种设计选择带来了几个显著优势：数据隐私得到保障、无需依赖外部云服务、部署简单且可离线运行。\n\n### 组件构成\n\n堆栈包含五个核心组件：\n\nhermes：Hermes智能体网关，负责与底层智能体进行通信\n\npostgres：PostgreSQL数据库，用于持久化存储所有状态数据。这是"持久化执行模型"的关键支撑，即使系统重启，运行状态和会话数据也不会丢失\n\ndashboard-api：基于Express + Prisma的后端API，包含一个工作循环（worker loop）用于处理异步任务\n\ndashboard-web：基于Next.js的前端仪表板，提供用户交互界面\n\nworker：负责任务调度和执行的后台工作进程\n\n### 数据模型设计\n\nHermesOS的数据模型设计体现了其对"可观测性"和"可追溯性"的重视。核心实体包括：\n\nProject（项目）：最高级别的组织单元，一个项目可以包含多个会话和运行\n\nSession（会话）：与智能体的交互会话，支持发送消息并通过SSE（Server-Sent Events）实时监视Hermes作业状态\n\nProjectRun（运行）：一个持久的多步骤运行实例，这是HermesOS区别于简单聊天界面的关键特性。运行具有明确的生命周期和状态机\n\nRunStep（运行步骤）：运行中的单个步骤，每个步骤有独立的索引（index）和状态\n\nRunEvent（运行事件）：追加式的事件日志，用于观测和调试。这种追加式（Append-Only）的设计是事件溯源（Event Sourcing）模式的体现，确保了历史记录的完整性\n\nSchedule（调度）：可附加到会话或运行的持久化调度配置，支持间隔调度和每日多次执行\n\n## 持久化执行模型详解\n\nHermesOS最具特色的设计之一是其持久化执行模型。在传统的智能体交互中，如果系统崩溃或重启，正在进行的任务往往会丢失上下文，需要从头开始。HermesOS通过以下机制解决了这一问题：\n\n### 状态持久化\n\n所有运行状态都存储在PostgreSQL中，通过Prisma ORM进行管理。这意味着即使容器重启，运行状态也能够恢复。\n\n### Hermes连续性\n\n在与Hermes智能体的交互中，HermesOS使用了Responses API（/v1/responses）并维护previous_response_id来实现对话连续性。具体实现上：\n\n- 每个RunStep记录其hermesResponseId\n- 每个ProjectRun记录其hermesLastResponseId\n- 下一步执行时，将hermesLastResponseId作为previous_response_id传入，确保上下文不丢失\n\n### 工作进程机制\n\n执行流程采用声明式的工作队列模式：\n\n1. 创建ProjectRun时，首先生成一个初始的"plan"步骤（index=0）\n2. 工作进程从数据库中认领（claim）待处理的工作\n3. 逐个执行步骤，并将日志追加到RunEvent\n4. 支持失败重试和超时处理\n\n这种设计使得HermesOS能够处理长时间运行的任务，即使过程中断也能从中断点恢复。\n\n## 调度系统：数据库驱动的定时任务\n\nHermesOS的调度系统是另一个亮点。与简单的定时任务不同，它采用了数据库驱动的设计：\n\n### 调度配置\n\nSchedule表存储了nextRunAt（下次运行时间）、配置Blob（config）和锁定字段。这种设计支持：\n\n- 间隔调度：每X分钟/小时/天运行一次\n- 每日多次：每天从指定时间开始运行N次，UI会显示每日时间预览\n- Cron-like表达式：支持星期几+具体时间的组合\n\n### 工作进程调度\n\n工作进程定期检查到期的调度任务，认领后从调度的runTemplate创建运行实例。这种设计确保了调度的高可用性——即使某个工作进程失败，其他进程也能接管。\n\n## 人机协作与审批流程\n\nHermesOS明确支持"人在回路"（Human-in-the-Loop）的交互模式。在复杂的智能体工作流中，完全自动化的执行往往存在风险，需要在关键节点引入人工审批。\n\n虽然当前文档没有详细说明审批流程的具体实现，但从架构设计可以看出其预留了扩展点：\n\n- 运行步骤的状态机可以很容易地加入"等待审批"状态\n- 前端仪表板可以展示待审批事项\n- 事件日志可以记录审批决策\n\n## 成本估算与使用追踪\n\n对于生产环境中的智能体系统，成本控制是一个重要考量。HermesOS内置了成本估算功能：\n\n- 从token总数估算成本，使用环境变量配置的费率\n- 支持简单定价（每1K tokens）和分离定价（输入/输出分别计价，每1M tokens）\n- 可以在概览页面查看使用情况和成本估计\n\n这种透明度对于团队管理AI预算、优化成本结构非常有价值。\n\n## 部署与使用\n\nHermesOS的部署非常简单，遵循现代容器化应用的最佳实践：\n\nbash\n# 创建本地环境文件\ncp .env.example .env\n\n# 启动堆栈\ndocker compose up -d --build\n\n# 访问仪表板\n# Dashboard Web: http://localhost:3000\n# Dashboard API: http://localhost:4000\n\n\n在UI中，用户需要设置API密钥（本地开发默认使用devkey），然后可以创建项目、建立会话、启动运行，并可选地为会话或运行启用自动化调度。\n\n## 未来发展方向\n\n根据项目文档，HermesOS团队规划了几个重要的发展方向：\n\n### 调度增强\n\n- 支持星期几+具体时间选择的类Cron UX\n- 每日N次执行支持时间窗口（如仅在09:00-17:00之间）\n- 错过执行的补偿策略和并发控制\n\n### 工作进程强化\n\n- 严格的生命周期状态转换（enqueue → claim → start → complete/fail）\n- 容量限制（最大并发运行数、最大并发步骤数）\n- 更好的重试和清理机制\n- 可选地将工作进程作为独立服务运行以实现隔离\n\n### 实时体验\n\n- WebSocket中心或SSE改进，确保时间线在所有地方即时更新\n\n### 使用数据作为一等公民\n\n- 持久化使用条目（tokens + 估算USD），不仅限于消息作业，还包括运行步骤\n- 从数据库渲染使用情况\n\n### 安全增强\n\n- 用真正的认证策略（cookies/session/JWT或签名令牌）替代SSE使用的查询字符串API密钥模式\n\n## 结语\n\nHermesOS代表了AI智能体基础设施演进的一个重要方向：从关注单个智能体的能力，转向关注多智能体系统的编排和管理。它的本地优先设计、持久化执行模型、数据库驱动的调度系统，以及对人在回路的支持，使其成为构建生产级智能体应用的坚实基础。\n\n对于正在探索智能体工作流编排的团队来说，HermesOS提供了一个立即可用的参考实现，同时也展示了一种可能的技术演进路径。随着AI智能体从实验走向生产，类似HermesOS这样的控制层将变得越来越重要。

HermesOS：面向多智能体系统的本地优先编排控制层\n\n随着AI智能体（Agent）技术的快速发展，如何有效管理多个智能体的协作、任务调度和执行追踪成为工程实践中的关键挑战。HermesOS正是为解决这一问题而设计的本地优先编排仪表板，它为NousResearch的Hermes智能体提供了一个完整的控制层，帮助团队在运行复杂多智能体系统时获得更高的清晰度、一致性和可控性。\n\n项目定位与核心能力\n\nHermesOS的定位非常明确：它不是另一个智能体框架，而是智能体之上的"智能控制层"。在当前的AI应用生态中，我们已经有了许多优秀的智能体实现（如Hermes、Claude、GPT等），但缺乏一套完整的工具来管理这些智能体的生命周期、协调它们的协作、追踪它们的执行过程。HermesOS填补了这一空白。\n\n项目的核心能力可以概括为四个方面：\n\n1. 任务协调：管理多个智能体之间的任务分配和依赖关系\n2. 质量门禁：在执行流程中设置检查点，确保输出质量\n3. 交接管理：处理智能体之间的状态传递和上下文保持\n4. 执行追踪：提供完整的运行历史和事件日志\n\n技术架构：本地优先的Docker Compose方案\n\nHermesOS采用本地优先（Local-First）的设计理念，整个系统以Docker Compose堆栈的形式交付。这种设计选择带来了几个显著优势：数据隐私得到保障、无需依赖外部云服务、部署简单且可离线运行。\n\n组件构成\n\n堆栈包含五个核心组件：\n\nhermes：Hermes智能体网关，负责与底层智能体进行通信\n\npostgres：PostgreSQL数据库，用于持久化存储所有状态数据。这是"持久化执行模型"的关键支撑，即使系统重启，运行状态和会话数据也不会丢失\n\ndashboard-api：基于Express + Prisma的后端API，包含一个工作循环（worker loop）用于处理异步任务\n\ndashboard-web：基于Next.js的前端仪表板，提供用户交互界面\n\nworker：负责任务调度和执行的后台工作进程\n\n数据模型设计\n\nHermesOS的数据模型设计体现了其对"可观测性"和"可追溯性"的重视。核心实体包括：\n\nProject（项目）：最高级别的组织单元，一个项目可以包含多个会话和运行\n\nSession（会话）：与智能体的交互会话，支持发送消息并通过SSE（Server-Sent Events）实时监视Hermes作业状态\n\nProjectRun（运行）：一个持久的多步骤运行实例，这是HermesOS区别于简单聊天界面的关键特性。运行具有明确的生命周期和状态机\n\nRunStep（运行步骤）：运行中的单个步骤，每个步骤有独立的索引（index）和状态\n\nRunEvent（运行事件）：追加式的事件日志，用于观测和调试。这种追加式（Append-Only）的设计是事件溯源（Event Sourcing）模式的体现，确保了历史记录的完整性\n\nSchedule（调度）：可附加到会话或运行的持久化调度配置，支持间隔调度和每日多次执行\n\n持久化执行模型详解\n\nHermesOS最具特色的设计之一是其持久化执行模型。在传统的智能体交互中，如果系统崩溃或重启，正在进行的任务往往会丢失上下文，需要从头开始。HermesOS通过以下机制解决了这一问题：\n\n状态持久化\n\n所有运行状态都存储在PostgreSQL中，通过Prisma ORM进行管理。这意味着即使容器重启，运行状态也能够恢复。\n\nHermes连续性\n\n在与Hermes智能体的交互中，HermesOS使用了Responses API（/v1/responses）并维护previous_response_id来实现对话连续性。具体实现上：\n\n- 每个RunStep记录其hermesResponseId\n- 每个ProjectRun记录其hermesLastResponseId\n- 下一步执行时，将hermesLastResponseId作为previous_response_id传入，确保上下文不丢失\n\n工作进程机制\n\n执行流程采用声明式的工作队列模式：\n\n1. 创建ProjectRun时，首先生成一个初始的"plan"步骤（index=0）\n2. 工作进程从数据库中认领（claim）待处理的工作\n3. 逐个执行步骤，并将日志追加到RunEvent\n4. 支持失败重试和超时处理\n\n这种设计使得HermesOS能够处理长时间运行的任务，即使过程中断也能从中断点恢复。\n\n调度系统：数据库驱动的定时任务\n\nHermesOS的调度系统是另一个亮点。与简单的定时任务不同，它采用了数据库驱动的设计：\n\n调度配置\n\nSchedule表存储了nextRunAt（下次运行时间）、配置Blob（config）和锁定字段。这种设计支持：\n\n- 间隔调度：每X分钟/小时/天运行一次\n- 每日多次：每天从指定时间开始运行N次，UI会显示每日时间预览\n- Cron-like表达式：支持星期几+具体时间的组合\n\n工作进程调度\n\n工作进程定期检查到期的调度任务，认领后从调度的runTemplate创建运行实例。这种设计确保了调度的高可用性——即使某个工作进程失败，其他进程也能接管。\n\n人机协作与审批流程\n\nHermesOS明确支持"人在回路"（Human-in-the-Loop）的交互模式。在复杂的智能体工作流中，完全自动化的执行往往存在风险，需要在关键节点引入人工审批。\n\n虽然当前文档没有详细说明审批流程的具体实现，但从架构设计可以看出其预留了扩展点：\n\n- 运行步骤的状态机可以很容易地加入"等待审批"状态\n- 前端仪表板可以展示待审批事项\n- 事件日志可以记录审批决策\n\n成本估算与使用追踪\n\n对于生产环境中的智能体系统，成本控制是一个重要考量。HermesOS内置了成本估算功能：\n\n- 从token总数估算成本，使用环境变量配置的费率\n- 支持简单定价（每1K tokens）和分离定价（输入/输出分别计价，每1M tokens）\n- 可以在概览页面查看使用情况和成本估计\n\n这种透明度对于团队管理AI预算、优化成本结构非常有价值。\n\n部署与使用\n\nHermesOS的部署非常简单，遵循现代容器化应用的最佳实践：\n\nbash\n创建本地环境文件\ncp .env.example .env\n\n启动堆栈\ndocker compose up -d --build\n\n访问仪表板\nDashboard Web: http://localhost:3000\nDashboard API: http://localhost:4000\n\n\n在UI中，用户需要设置API密钥（本地开发默认使用devkey），然后可以创建项目、建立会话、启动运行，并可选地为会话或运行启用自动化调度。\n\n未来发展方向\n\n根据项目文档，HermesOS团队规划了几个重要的发展方向：\n\n调度增强\n\n- 支持星期几+具体时间选择的类Cron UX\n- 每日N次执行支持时间窗口（如仅在09:00-17:00之间）\n- 错过执行的补偿策略和并发控制\n\n工作进程强化\n\n- 严格的生命周期状态转换（enqueue → claim → start → complete/fail）\n- 容量限制（最大并发运行数、最大并发步骤数）\n- 更好的重试和清理机制\n- 可选地将工作进程作为独立服务运行以实现隔离\n\n实时体验\n\n- WebSocket中心或SSE改进，确保时间线在所有地方即时更新\n\n使用数据作为一等公民\n\n- 持久化使用条目（tokens + 估算USD），不仅限于消息作业，还包括运行步骤\n- 从数据库渲染使用情况\n\n安全增强\n\n- 用真正的认证策略（cookies/session/JWT或签名令牌）替代SSE使用的查询字符串API密钥模式\n\n结语\n\nHermesOS代表了AI智能体基础设施演进的一个重要方向：从关注单个智能体的能力，转向关注多智能体系统的编排和管理。它的本地优先设计、持久化执行模型、数据库驱动的调度系统，以及对人在回路的支持，使其成为构建生产级智能体应用的坚实基础。\n\n对于正在探索智能体工作流编排的团队来说，HermesOS提供了一个立即可用的参考实现，同时也展示了一种可能的技术演进路径。随着AI智能体从实验走向生产，类似HermesOS这样的控制层将变得越来越重要。