Hermes Harness 架构深度解析 ✍ Aparna Dhinakaran🕐 2026-05-30📦 9.8 KB 🟢 已读 𝕏 文章列表 本文深入分析了 NousResearch 的 Hermes 开源 Agent Harness 架构。文章指出 Hermes 全面实现了包括上下文管理、子代理管理、会话持久化等在内的九大核心组件。作者详细探讨了其独特优势：统一的运行时支持多种模型提供商、复杂的三层系统提示词组装、基于 SQLite 的会话即基础设施设计，以及内置的消息网关和 Cron 系统。文章最后展望了其向一级编排能力演进的方向。 AgentHarness架构分析LLM上下文管理开源子代理系统设计 # Hermes Harness Architecture **作者**: Aparna Dhinakaran **日期**: 2026-05-29T17:04:38.000Z **来源**: [https://x.com/aparnadhinak/status/2060406977357070522](https://x.com/aparnadhinak/status/2060406977357070522) ---  Hermes (from @NousResearch) is one of the best open-source harnesses in the ecosystem right now. We wanted to look at the implementation directly and map what we found to the framework we use for analyzing harnesses. In our earlier piece, "What is an Agent Harness," we used a nine-part model: - outer iteration loop - context management and compression - skills and tools management - subagent management - built-in pre-packaged skills - session persistence and recovery - system prompt assembly with project context injection - lifecycle hooks - permission and safety layer  Hermes implements all nine. The interesting details are in how it implements them, and in the extra systems that sit outside this frame. ## The outer iteration loop The core loop is familiar: model call, tool dispatch, tool result append, repeat until final response or interrupt. Where Hermes is stronger than most open harnesses is provider abstraction. The same runtime can drive chat-completions style APIs, Anthropic Messages, Codex Responses, an out-of-process Codex app-server path, and Bedrock. Tool-call formats and provider quirks are normalized by transport adapters. At the loop level, the model surface looks consistent. For those of us, who really like having an open harness provider who supports all models, this open approach is much better than Claude Code. ## Context management and compression Hermes has a full compression path, not a simplistic context trim. Older turns are summarized by an auxiliary model. Head and tail segments are protected by token budget. Tool outputs that are older than a configurable threshold are pruned before summarization. The summary budget scales with compressed content at roughly twenty percent, with a two-thousand-token floor and a twelve-thousand-token ceiling. In practice this avoids spending too much context on tiny compressions while still giving large compressions enough room to be useful.  Compression is also a session lifecycle event. On compression, Hermes closes the current SQLite session row, creates a child session seeded by the summary, rotates the session ID, and records parent-child lineage. Plugin context engines and memory providers are notified that a boundary moved. If a long conversation compresses multiple times, you get a lineage chain instead of one repeatedly rewritten transcript. This is pretty unique relative to other harness architectures we've reviewed. ## Skills and tools management Tool registration and tool exposure are separate concerns in Hermes. Tools register into a central registry at import time. A separate toolset layer decides what the model actually sees in a given run. That exposed set is scoped by platform and scenario, and can be narrowed again for delegated runs. A profile has its own enabled footprint.  This separation matters operationally. You can keep a broad installed tool library while keeping any single run's model-visible surface small enough to manage for token cost and safety. ## Subagent management Delegation primitives are solid. A child run gets its own task ID, its own terminal context, and returns a structured summary to the parent. Dangerous commands default to deny in delegated contexts, and recursion depth is capped. The current limit is lifecycle ownership. Most child work still lives under the parent call path. When the parent is done, the child is done. There is not yet a durable, externally steerable child-run plane with independent control semantics. ## Session persistence and recovery This is where Hermes departs most from editor-first harnesses. Session state is stored in SQLite with FTS5 search and WAL journaling, with fallback behavior for filesystems that cannot support WAL coordination. Sessions track source tags for turns, parent-child lineage for compression splits, and metadata the gateway can use to resolve routing before the model runs.  That design effectively treats sessions as runtime infrastructure, not just transcripts for resume. CLI, messaging platforms, and scheduled jobs can all attach to the same session plane. A message can be routed to the right session before inference. A scheduled job can write to a session even with no active terminal. Hermes also exposes a model-facing session_search tool for focused recall over prior sessions. This is a concrete example of pushing context management decisions into the model loop itself rather than relying only on static injection. ## System prompt assembly and project context injection Hermes explicitly composes the system prompt in three tiers: stable, context, and volatile. The stable tier carries identity (SOUL.md when present), tool guidance for enabled tools only, skills index content, environment hints (like Tmux/container detection), and platform hints. The context tier reads project files from cwd (AGENTS.md, CLAUDE.md, .cursorrules) and runs prompt-injection scanning before loading that content. The volatile tier carries memory snapshots, user profile material, external memory-provider blocks, and a timestamp line with model/provider metadata.  The tiering itself is explicit in code, which makes invariants easier to reason about. Stable stays stable, context stays cwd-derived, volatile changes turn-by-turn. Prompt rebuild is tied to compression and related invalidation points, which helps keep prompt prefixes cache-friendly across normal turns. ## Lifecycle hooks Hermes has two hook surfaces with different trust models. First, plugin lifecycle hooks run inside the harness process and can block, rewrite, or pass through operations at events like pre/post tool call, gateway pre-dispatch, and approval request/response. Second, filesystem-driven gateway hooks let users install shell or Python scripts that run on events like gateway startup, agent step, and command-triggered paths.  Architecturally, both surfaces serve the same purpose: policy enforcement, auditing, and host side-effects should execute independently of model cooperation. ## What Hermes adds beyond the framework Three subsystems stand out beyond the nine-component harness model. The first is the messaging gateway. Hermes supports a broad platform adapter surface (Telegram, Discord, Slack, WhatsApp, and others) and routes traffic through a shared session model. This feels like a user interface experience that was successful with OpenClaw, designed for user interaction with long running agents. The second is the profile system. A profile is an isolated agent root. Two profiles on the same machine behave like two different agents from a state and footprint perspective.  The third is cron as a first-class subsystem. Jobs are durable, gated by the same permissions machinery as interactive sessions, delivered through gateway paths, and isolated per profile. That forces unattended operation concerns into the main architecture rather than leaving them as peripheral scripts. ## Where we think Hermes should go next The obvious next step is moving from strong delegation to first-class orchestration. delegate_task already produces useful worker behavior and structured returns. What is still missing is durable child-run control: run IDs, explicit lifecycle management, external steering, and cleanup semantics that survive parent completion. Hermes already has much of the substrate through session infrastructure and gateway routing. Promoting child runs to first-class control-plane objects is the most natural next architectural step. It is one of the gaps we see versus the OpenClaw agent orchestraction layer. ## To close Hermes already has excellent execution quality and a strong systems foundation for an open harness. It is probably one of the best open model harnesses in the ecosystem. The pace of shipping is ... insane, and most of the hard substrate work is already in place. Excited to see agent orchestration layer mature on top of that base. Hermes can already support much broader long-lived agent workloads than typical coding harnesses handle today, excited to see where it goes. This piece references my previous What is an Agent Harness, as framing, and is informed by Swarm management in agent harnesses, plus Anthropic's posts on Managed Agents ## 相关链接 - [Aparna Dhinakaran](https://x.com/aparnadhinak) - [@aparnadhinak](https://x.com/aparnadhinak) - [24K](https://x.com/aparnadhinak/status/2060406977357070522/analytics) - [@NousResearch](https://x.com/@NousResearch) - [What is an Agent Harness,](https://x.com/aparnadhinak/status/2046980769747533830) - [What is an Agent Harness,](https://x.com/aparnadhinak/status/2046980769747533830) - [Swarm management in agent harnesses](https://arize.com/blog/swarm-management-of-agent-harnesses/) - [Managed Agents](https://www.anthropic.com/engineering/managed-agents) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [1:04 AM · May 30, 2026](https://x.com/aparnadhinak/status/2060406977357070522) - [24.1K Views](https://x.com/aparnadhinak/status/2060406977357070522/analytics) - [View quotes](https://x.com/aparnadhinak/status/2060406977357070522/quotes) --- *导出时间: 2026/5/30 10:39:43* --- ## 中文翻译 # Hermes 架构解析 **作者**: Aparna Dhinakaran **日期**: 2026-05-29T17:04:38.000Z **来源**: [https://x.com/aparnadhinak/status/2060406977357070522](https://x.com/aparnadhinak/status/2060406977357070522) ---  Hermes（来自 @NousResearch）是当前生态系统中最好的开源框架之一。我们希望直接审视其实现，并将发现的内容映射到我们用于分析框架的框架中。 在我们之前的文章《什么是 Agent 框架》中，我们使用了一个九部分模型： - 外部迭代循环 - 上下文管理和压缩 - 技能和工具管理 - 子 Agent 管理 - 内置预打包技能 - 会话持久化和恢复 - 注入项目上下文的系统提示组装 - 生命周期钩子 - 权限和安全层  Hermes 实现了全部九个部分。其有趣之处在于它如何实现它们，以及位于此框架之外的额外系统。 ## 外部迭代循环 核心循环很熟悉：模型调用、工具分派、工具结果追加、重复直到最终响应或中断。 Hermes 比大多数开源框架强的地方在于提供商抽象。同一个运行时可以驱动聊天补全风格的 API、Anthropic Messages、Codex Responses、进程外 Codex 应用服务器路径以及 Bedrock。工具调用格式和提供商的特殊习性通过传输适配器进行规范化。在循环级别，模型表面看起来是一致的。对于我们这些真正喜欢支持所有模型的开放框架提供商的人来说，这种开放方法比 Claude Code 好得多。 ## 上下文管理和压缩 Hermes 拥有完整的压缩路径，而不是简单的上下文修剪。 较早的轮次由辅助模型进行总结。头部和尾部片段受 token 预算保护。早于可配置阈值的工具输出会在总结之前被修剪。摘要预算以大约二十百分之的比例随压缩内容缩放，下限为两千个 token，上限为一万两千个 token。实际上，这避免了在微小的压缩上花费过多的上下文，同时仍然为大型压缩提供了足够的空间以发挥作用。  压缩也是一个会话生命周期事件。在压缩时，Hermes 关闭当前的 SQLite 会话行，创建一个由摘要作为种子的子会话，轮换会话 ID，并记录父子血统。插件上下文引擎和内存提供者会收到边界移动的通知。如果长对话压缩多次，你会得到一个血统链，而不是一个重复重写的记录。相对于我们审查过的其他框架架构，这是相当独特的。 ## 技能和工具管理 工具注册和工具暴露在 Hermes 中是两个独立的问题。 工具在导入时注册到中央注册表中。单独的工具集层决定模型在给定运行中实际看到的内容。该暴露集由平台和场景限定范围，并且可以再次缩小以用于委托运行。一个配置文件有其自己的启用地盘。 这种分离在操作上很重要。您可以保留一个广泛的已安装工具库，同时保持任何单次运行的模型可见表面足够小，以便管理 token 成本和安全性。 ## 子 Agent 管理 委托原语很可靠。子运行获得其自己的任务 ID、自己的终端上下文，并向父级返回结构化摘要。危险的命令在委托上下文中默认为拒绝，并且递归深度受到限制。 目前的限制在于生命周期所有权。大多数子工作仍然位于父调用路径下。当父级完成时，子级就完成了。目前还没有一个持久的、可外部引导的子运行平面，具有独立的控制语义。 ## 会话持久化和恢复 这是 Hermes 与编辑器优先框架最不同的地方。 会话状态存储在 SQLite 中，具有 FTS5 搜索和 WAL 日志记录，对于不支持 WAL 协调的文件系统有回退行为。会话跟踪轮次的源标签、压缩分割的父子血统，以及网关可以在模型运行前用来解析路由的元数据。  该设计实际上将会话视为运行时基础设施，而不仅仅是用于恢复的记录。CLI、消息平台和计划作业都可以附加到同一个会话平面。消息可以在推理前路由到正确的会话。计划作业即使没有活动的终端也可以写入会话。 Hermes 还公开了一个面向模型的 session_search 工具，用于对以前的会话进行重点回忆。这是将上下文管理决策推入模型循环本身而不仅仅依赖静态注入的一个具体例子。 ## 系统提示组装和项目上下文注入 Hermes 明确地分三层组成系统提示：稳定层、上下文层和易变层。 稳定层携带身份（如果存在则为 SOUL.md）、仅针对已启用工具的工具指导、技能索引内容、环境提示（如 Tmux/容器检测）和平台提示。上下文层从 cwd 读取项目文件（AGENTS.md、CLAUDE.md、.cursorrules），并在加载该内容之前运行提示注入扫描。易变层携带内存快照、用户配置文件材料、外部内存提供者块以及带有模型/提供商元数据的时间戳行。  分层本身在代码中是明确的，这使得不变量更容易推理。稳定层保持稳定，上下文层保持 cwd 派生，易变层逐轮变化。提示重建与压缩和相关的失效点绑定，这有助于使提示前缀在普通轮次中保持缓存友好。 ## 生命周期钩子 Hermes 有两个具有不同信任模型的钩子表面。 首先，插件生命周期钩子在框架进程内运行，并可以在预/后工具调用、网关预分派和批准请求/响应等事件处阻塞、重写或通过操作。其次，文件系统驱动的网关钩子允许用户安装 shell 或 Python 脚本，这些脚本在网关启动、代理步骤和命令触发路径等事件上运行。  从架构上讲，两个表面都服务于相同的目的：策略执行、审计和主机副作用应独立于模型合作执行。 ## Hermes 在框架之外添加的内容 除了九部分框架模型外，还有三个子系统脱颖而出。 第一个是消息网关。Hermes 支持广泛的平台适配器表面（Telegram、Discord、Slack、WhatsApp 等），并通过共享会话模型路由流量。这感觉像是一种在 OpenClaw 上成功的用户界面体验，专为用户与长时间运行的代理交互而设计。 第二个是配置文件系统。配置文件是一个隔离的代理根。同一台机器上的两个配置文件在状态和足迹方面表现得像两个不同的代理。  第三个是作为一流子系统的 cron。作业是持久的，由与交互式会话相同的权限机制控制，通过网关路径传递，并按配置文件隔离。这将无人值守操作的 concerns 强制进入主架构，而不是将它们保留为外围脚本。 ## 我们认为 Hermes 下一步应该去哪里 显而易见的下一步是从强大的委托转向一流的编排。 delegate_task 已经产生了有用的工人行为和结构化返回。目前仍然缺少的是持久的子运行控制：运行 ID、显式的生命周期管理、外部引导，以及幸免于父级完成的清理语义。Hermes 已经通过会话基础设施和网关路由拥有了许多底层。将子运行提升为一流的控制平面对象是最自然的下一个架构步骤。这是我们看到的与 OpenClaw 代理编排层相比的差距之一。 ## 结束语 Hermes 已经拥有出色的执行质量和强大的系统基础，是一个开源框架。它可能是生态系统中最好的开源模型框架之一。发布的速度......令人难以置信，而且大多数困难的底层工作已经完成。很高兴看到代理编排层在此基础上成熟。Hermes 已经可以支持比当今典型编码框架处理范围更广的长生命周期代理工作负载，很高兴看到它的发展。 本文参考了我之前的《什么是 Agent 框架》作为框架，并从代理框架中的 Swarm 管理以及 Anthropic 关于托管代理的帖子中获得了信息 ## 相关链接 - [Aparna Dhinakaran](https://x.com/aparnadhinak) - [@aparnadhinak](https://x.com/aparnadhinak) - [24K](https://x.com/aparnadhinak/status/2060406977357070522/analytics) - [@NousResearch](https://x.com/@NousResearch) - [What is an Agent Harness,](https://x.com/aparnadhinak/status/2046980769747533830) - [What is an Agent Harness,](https://x.com/aparnadhinak/status/2046980769747533830) - [Swarm management in agent harnesses](https://arize.com/blog/swarm-management-of-agent-harnesses/) - [Managed Agents](https://www.anthropic.com/engineering/managed-agents) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [1:04 AM · May 30, 2026](https://x.com/aparnadhinak/status/2060406977357070522) - [24.1K Views](https://x.com/aparnadhinak/status/2060406977357070522/analytics) - [View quotes](https://x.com/aparnadhinak/status/2060406977357070522/quotes) --- *导出时间: 2026/5/30 10:39:43*
如 如何优化你的 AI Harness：配置、框架与子代理指南 文章指出工程师的关注点已从 IDE 转向 AI Harness，并介绍了提升 Harness 输出质量的关键方法。核心策略包括：保持配置文件（如 .md）精简，采用渐进式披露原则以节省上下文；利用 R.P.I 框架（Research, Plan, Implement）像资深工程师一样分解问题；以及通过子代理清理主上下文窗口。文章强调，Harness 的核心在于工程判断力。 技术 › 工具与效率 ✍ Alex Ker🕐 2026-04-19 AIAgentHarnessLLM工程化Prompt上下文管理子代理Claude Code最佳实践
A Agent Harness 拆解：AI Agent 的工程化基础设施 本文深入探讨了 Agent Harness 的概念，即包裹在 LLM 外部、将无状态模型转化为可用智能体的完整软件基础设施。文章引用了 Anthropic、OpenAI 和 LangChain 的实践，详细拆解了生产级 Harness 的 12 个核心组件（如编排循环、记忆系统、上下文管理、验证循环等），并阐述了如何通过优化这层“操作系统”来解决遗忘、工具调用失败和上下文腐烂等工程难题。 技术 › Harness Engineering ✍ 土豆本豆🕐 2026-05-21 AgentHarnessLLM架构设计LangChainClaudeOpenAI上下文管理工程化Agent拆解
你 你不知道的 Agent：原理、架构与工程实践 本文深入剖析了 Agent 系统的工程实现，强调 Harness（测试与约束基础设施）比模型能力更关键。文章详细阐述了 Agent Loop 的稳定性、上下文分层管理以避免 Context Rot、工具设计的 ACI 原则、记忆系统的多维度分类，以及基于失败案例的评测体系。最后通过 OpenClaw 案例，展示了如何利用 Prompt Caching 和按需加载 Skills 来优化系统架构。 技术 › Agent ✍ 阿里云开发者🕐 2026-05-02 AgentLLM工程实践Harness上下文管理OpenClaw工具设计评测体系Prompt Caching
模 模型是引擎，系统是车身：AI 架构工程随笔 文章反驳了 Kyle Kingsbury 关于 LLM 不可靠的结论。作者认为，裸模型仅是“引擎”，其不可预测性需通过“车身”工程（如 Harness、Resolver、确定性工具）来解决。不应测试模型本身，而应测试由模型、路由和工具组成的完整系统。 技术 › Hermes ✍ nash_su🕐 2026-04-20 AI架构LLMAgentHarness工程化系统设计OpenClaw方法论
C Claude Code 工程化最佳实践与架构指南 本文系统性地介绍了 Claude Code 的工程化实战知识库，涵盖了从基础配置到高级架构设计的方方面面。内容解读了创建者的定制技巧，深入解析了 Command、Agent、Skills 的核心架构与 Memory 作用域，并针对 Monorepo 场景提供了上下文管理策略。文章还总结了上下文管理、Agent 设计、调试方法及权限安全的实践经验，并分享了如何利用高级 API 特性（如程序化工具调用、动态过滤）来显著降低 Token 消耗并提升准确率。 技术 › Claude Code ✍ shanraisshan🕐 2026-02-23 AgentMCPMemory最佳实践上下文管理架构设计DevOpsLLM开源
B BestBlogs 早报｜实现周期骤缩后，创业者如何重选问题 本期早报探讨了 AI 智能体缩短实现周期后，创业者的机遇与挑战。文章涵盖 Sam Altman 对创业窗口的判断、GPT-5.6 的效率工程实践，以及如何通过 Skill Harness 将模型能力封装为可维护的产品功能。 技术 › Skill ✍ ginobefun🕐 2026-07-30 GPT-5.6Agent创业效率工程ProductHarnessSkillLLMOpenAI
浪 浪费20亿Token之后，我做了一个帮自己定义目标的Skill 作者分享了一个名为Leader.skill的开源工具，旨在解决Agent交互中目标定义模糊的问题。该工具基于“目标七问”方法论，将模糊需求转化为清晰的目标任务书，支持多模型组合（如Claude规划、GPT执行），显著提升长程任务的完成率与Token利用率。 技术 › Skill ✍ 数字生命卡兹克🕐 2026-07-27 AgentGoal Engineering目标定义自动化开源LLM效率工具方法论ClaudeGPT
构 构建智能代理的三层架构：Loop、Graph与Harness 本文提出解决Agent重复读取数据和Token浪费的三层架构方案：Loop负责单元工作的收集-行动-验证闭环；Graph通过分发和并行管理复杂任务；Harness作为运行时环境提供工具和上下文隔离。文中提供了具体的代码实现思路和实战演示。 技术 › Agent ✍ Archive🕐 2026-07-25 AgentLoopGraphHarness架构设计上下文管理Token优化验证机制代码实现
T The context gold rush: Why everyone is building the same thing 文章分析了当前 AI 领域的“淘金热”——上下文管理。作者指出，从 Jevons 悖论到数据主权，多因素驱动了初创公司和大企业竞相构建公司大脑或 LLM 知识库。尽管切入角度各异（如个人知识库、代理内存、可观测性工具等），但核心目标一致：为未来的智能体劳动力提供数据上下文层。文章认为该领域潜力巨大，但也面临产品同质化。 技术 › Agent ✍ Sam Z Liu🕐 2026-07-24 上下文管理Agent公司大脑LLM数据主权竞争格局
5 5步构建低Token消耗的自治Agent系统 文章介绍了构建消耗Token减少90%的自管理Agent系统的五个步骤：将上下文移出窗口、使用子代理处理脏活、利用自管理内存、避免破坏缓存以及手动管理上下文。强调了通过优化上下文管理和缓存机制来降低成本和提升效率的重要性。 技术 › Agent ✍ codila🕐 2026-07-17 AgentToken优化上下文管理缓存机制Claude Code子代理自管理内存
B BestBlogs 早报 · 07-17｜Bun 借 AI 重写、Hook 堵越权、Nemotron 登顶检索 本期早报聚焦 AI 工程落地，精讲 Bun 用 64 个智能体 11 天重写 53.5 万行代码、腾讯 DECO 用 Hook 治理 LLM 偷懒越权、NVIDIA Nemotron 登顶检索榜。此外涵盖 Kimi K3、Inkling 模型、全双工语音等速览，强调竞争焦点从模型参数向工程实践迁移。 技术 › Harness Engineering ✍ ginobefun🕐 2026-07-17 AI工程BunRustAgentNVIDIALLM检索Hook开源模型评测
如 如何构建自动纠错 AI 循环 文章介绍如何构建一个 AI 自我纠错系统，通过分离生成、判断和管理三个角色，避免人工介入验证。关键在于利用独立的标准（如测试套件）进行结构化验证，而非简单的重复提问，从而实现自动化错误捕捉与修复。 技术 › Agent ✍ CyrilXBT🕐 2026-07-17 AI架构自我纠错Agent提示词工程自动化系统设计LLM流程优化