2026 年的 AI 智能体赛道已经走过了"谁能调用工具"的初赛阶段。Hermes Agent（Nous Research，150k stars）把封闭学习回路做成了开源 agent 的标志性功能；OpenClaw（Peter Steinberger，371k stars）用 20+ 消息平台网关拿到了当前最大的开源智能体用户基数；Claude Code（Anthropic，123k stars）以绑定自家模型的编程工具身份卡住了 IDE 赛道的头部位置；Crush（Charmbracelet，24k stars）在模型无关的编程智能体方向建立了自己的生态位。需要区分的是，它承接的是早期已归档的 opencode-ai/opencode 代码线，并不是当前 opencode.ai / anomalyco/opencode 这一活跃 OpenCode 项目的继任者。

这几类方案在功能清单上有大量重叠——都能读写文件、执行命令、调用外部工具。但把视角从功能清单转向记忆架构，差异立刻变得不可调和：有的方案每次会话结束就失忆，有的靠用户手写配置文件维持上下文，有的让 agent 自己往磁盘上写经验。记忆设计的差异，不是一个功能维度上的强弱问题，而是一个根本性的产品定位分歧——它决定了这个 agent 在回答什么问题、服务什么场景、适合什么样的用户。

本文以记忆架构为主轴，横向拆解 2026 年主流智能体方案的设计分野，覆盖编程智能体（Claude Code、Crush）、通用智能体（OpenClaw）、长程自主智能体（Hermes Agent）三条赛道，并把 Anthropic 在 2024 年 12 月至 2026 年 3 月间发布的四篇 harness engineering 博客——《Building Effective Agents》《How we built our multi-agent research system》《Harness design for long-running application development》《Demystifying evals for AI agents》——作为方法论底座。Hermes 是引入这场讨论的切入点，但不是讨论的全部。

先厘清赛道：编程智能体、通用智能体与长程智能体

讨论记忆架构之前，必须先把"智能体"这个过度使用的词拆成三条独立赛道。混淆赛道是智能体领域最常见的讨论失效模式——把 Claude Code 和 Hermes 放在同一张功能对比表里打分，和把卡车跟轿车放在同一张评分卡里比加速成绩一样，在技术上正确但在决策上无意义。

编程智能体（Coding Agents）

代表：Claude Code、你、Cursor、Windsurf、Aider、Codex CLI、Gemini CLI

核心特征：

  • 会话制：用户发起一个编码任务，agent 完成，会话结束
  • 入口在 IDE 或终端：工作流围绕代码编辑器展开
  • 输出是代码变更：diff、commit、PR 是主要产物
  • 记忆天花板是项目级：CLAUDE.md、AGENTS.md、.cursorrules 这类文件定义了记忆的上界——agent 知道这个项目的约定，但不知道用户昨天在另一个项目里做过什么决策

编程智能体回答的问题是：“这个编码任务怎么做好”。

通用智能体（General-Purpose Agents）

代表：OpenClaw

核心特征：

  • 常驻制：作为守护进程运行，随时可达
  • 入口在消息平台：Telegram、Discord、Slack、WhatsApp 等 20+ 平台
  • 输出是任意动作：写代码、发消息、查资料、跑定时任务、控制智能家居
  • 记忆在会话层：有 session 管理和技能注册，但无 agent 自主学习机制

通用智能体回答的问题是：“怎么在用户的日常工作流里随时可用”。

长程自主智能体（Long-Running Autonomous Agents）

代表：Hermes Agent

核心特征：

  • 通用智能体的全部能力，加上——
  • 封闭学习回路：从任务中自主蒸馏 skill、主动维护记忆、辩证式用户建模
  • 时间维度：设计目标不是"这一次做好"，而是"跑半年后比今天强"
  • 私有资产属性：memory、skills、user model 全部落在用户自己的服务器上

长程智能体回答的问题是：“这个 agent 怎么在一个固定模型上越跑越强”。

编排框架不是智能体

LangGraph、AutoGen、CrewAI、Claude Agent SDK 是另一个层级的东西——它们是搭建智能体的积木，不是智能体本身。记忆机制由框架使用者自己实现，框架只提供插槽。把它们和上面三类方案直接对比是范畴错误。

[PATTERN] 判断两个 agent 产品是否可比：先看它们在回答同一道题还是不同的题。回答不同题目的产品之间不存在替代关系，只存在互补关系或无关关系。Claude Code 和 Hermes 不是竞品——一个帮你写代码，一个帮你在时间里积累一个私有 AI 助手。OpenClaw 和 Hermes 才是直接竞品——都在回答"怎么拥有一个常驻的通用智能体"，差异在记忆层。

名字先澄清：四个 “Hermes” 的去重

AI 领域里叫 Hermes 的东西不止一个。一个严肃的技术讨论必须先做去重，否则后续所有判断都建立在错位的所指上。

名字 是什么 与本文的关系
Hermes Agent Nous Research 的开源 autonomous agent 框架，MIT 协议 本文研究对象
Hermes / Hermes 2 / Hermes 3 / Hermes 4 Nous Research 的开源 fine-tuned LLM 系列（Llama/Mistral 基座） 同一公司的另一条产品线，和 Hermes Agent 不是同一件东西。由于 Hermes Agent 的 transport 层模型无关，这类开源模型可以经 OpenRouter、Hugging Face、NVIDIA NIM 等通用后端被 Hermes Agent 调用
Hermes 的希腊神话原型 奥林匹斯众神的信使，主管跨界传递、边界与沟通 Nous Research 的命名出处，某种程度上解释了 Agent 产品线为什么强调多平台信使能力
社区里偶尔流传的 “Anthropic Hermes” 并不存在的实体，通常是把 Nous Research 的 Hermes Agent、Anthropic 的 harness engineering 实践、Claude Code 的 subagent 机制混为一谈 需要严格剥离

本文自始至终讨论的 Hermes = Nous Research 的 hermes-agent 开源项目。它是一个自我改进的自治 agent 框架，作者是 Nous Research 团队（主要维护者是 teknium1），代码在 GitHub 上完全公开可审计。之所以要在正文第一节就把这四个概念的层级厘清，是因为社区讨论里「Hermes」这个词的所指极其滑动——一条 X 帖子可能同时指代 Hermes Agent、Hermes 4 模型、甚至与某些 Claude 生态里的概念混讲，读者如果没意识到所指切换，很容易得出错误推断。

[PATTERN] 处理同名多实体的技术讨论：写作和阅读技术内容时，凡是涉及可能的多重所指（“Claude” 可能是模型也可能是 Claude Code；“Hermes” 可能是 Agent 也可能是 LLM 系列），第一件事是锁定本文采用的单一所指并写在显眼位置。混用同名实体是技术讨论里最常见的事实基础崩塌源。

技术解构：Hermes 的六层架构与封闭学习回路

Hermes 的核心结构可以拆成六层，每一层回答一个"agent 作为软件"必须回答的工程问题。这六层不是文档里的抽象命名，而是从官方 README、v0.9.0 到 v0.11.0 三个主要版本的 release notes 以及实际代码仓目录结构反向归纳出来的划分。

第 1 层：Agent 核（run_agent.py + transport ABC）

Hermes 的 agent 主循环在 run_agent.py 里。v0.11.0 的 Interface release 把格式转换和 HTTP 传输抽象到 agent/transports/ 下的 Transport ABC 中，覆盖四条路径：Anthropic Messages API、OpenAI 兼容厂商的 Chat Completions 默认路径、OpenAI Responses API（含 Codex）、AWS Bedrock Converse API [NousResearch/hermes-agent Release v0.11.0]。

这一层的设计语言是模型无关。Hermes 自己声明支持 Nous Portal、OpenRouter 的 200 多个模型、NVIDIA NIM、Xiaomi MiMo、z.ai/GLM、Kimi/Moonshot、MiniMax、Hugging Face、OpenAI、本地 endpoint；切换模型只需 hermes model 命令，不改代码、不换 API key 配置体系 [hermes-agent README]。这意味着 Hermes 不把自己绑定在任何一家模型厂商上，和 Claude Code（绑 Anthropic）、Codex CLI（绑 OpenAI）、Gemini CLI（绑 Google）的路径完全不同。

第 2 层：消息网关（gateway/）

Hermes 的 gateway 把自己接到 Telegram、Discord、Slack、WhatsApp、Signal、iMessage（通过 BlueBubbles）、WeChat、WeCom、DingTalk、Feishu、Matrix、Email、SMS、Home Assistant、Mattermost、Webhooks，以及 v0.11.0 新加的 QQBot，合计 17 个消息平台 [hermes-agent README + Release v0.11.0]。这一层是 Hermes 区别于所有 IDE 内置 agent 的核心差异点：它不活在你的 IDE 里，它活在你本来就在用的那些消息 app 里。

从架构角度看，gateway 是单进程、多 adapter 的模型：所有平台共享同一个 agent 核心，adapter 只做协议翻译。这带来两个直接后果：第一，用户在 Telegram 开的对话可以从 Slack 继续，Hermes 会跨平台保持会话连续性；第二，新加一个平台的边际成本是写一个 adapter，不是重构整个系统。

第 3 层：工具与 Toolset（tools/ + toolsets.py + Tool Gateway）

Hermes 内置超过 40 个工具，并在 v0.10.0 发布了 Nous Tool Gateway：付费 Nous Portal 订阅用户可以直接复用订阅额度调用 Firecrawl（web search）、FAL/FLUX 2 Pro（image gen）、OpenAI TTS、Browser Use（浏览器自动化），无需另行配置 API key [NousResearch/hermes-agent Release v0.10.0]。这一层的意义在于把"工具能力"和"API 账单"解耦：开发者写一个 Hermes 插件，不需要假设用户已经有十家外部 SaaS 的账号。

第 4 层：沙箱执行（七种后端）

Hermes 提供七种 terminal backend：local、Docker、SSH、Singularity、Modal、Daytona、Vercel Sandbox。其中 Modal、Daytona、Vercel Sandbox 提供 serverless 持久化——agent 环境在空闲时休眠，请求到达时唤醒，冷启动之间几乎零成本；它们都是 Hermes 写一层薄适配壳调对应 SDK，所以这些 SDK 在 pyproject.toml 里是可选 extras，由 tools/lazy_deps.py 在首次使用时按需 pip 安装 [NousResearch/hermes-agent tools/environments/]。这一组合给了 Hermes 部署形态的三种典型轮廓：

  • 本地 / VPS 长期驻留：$5/月 VPS 就能跑，适合个人和小团队
  • 企业内部部署：Docker + SSH，接进企业内网
  • Serverless：Daytona / Modal，按需唤醒，适合低频但需要持久状态的自动化任务

能在 5 美元 VPS 跟 GPU 集群之间共享同一套抽象，背后是一条比较硬的工程线：无状态的 agent 核 + 有状态的外部执行环境。状态不归 agent 所有，归环境所有，所以环境可以休眠可以迁移，agent 只是入口。

这是 Hermes 官方主打、也是它在记忆架构横评中处于 L4 等级的原因。官方原文是：“It’s the only agent with a built-in learning loop — it creates skills from experience, improves them during use, nudges itself to persist knowledge, searches its own past conversations, and builds a deepening model of who you are across sessions.” [hermes-agent README]

回路由四个子机制咬合而成：agent-curated memory（自主往 MEMORY.md / USER.md 写入）、autonomous skill creation（任务经验蒸馏为 skill 文档，兼容 agentskills.io 标准）、FTS5 session search + LLM summarization（SQLite 全文索引 + 摘要检索历史行为）、Honcho dialectic user modeling（辩证式用户画像持续精修）。四个子机制的详细拆解和与 OpenClaw、Claude Code、Crush 的对比见前文「记忆架构横评」一节。

这一层的设计哲学：不是让模型变强，而是让 agent 在一个固定模型上越跑越强。回路不靠模型权重更新，靠外部存储的经验资产累积。

第 6 层：子 agent 与并行编排（subagent orchestration）

Hermes 支持生成隔离的 subagent 来跑并行工作流。v0.11.0 在这一层做了一次关键升级——subagent 可以被赋予显式的 orchestrator 角色，能自己再生出 worker 子 agent，并通过 max_spawn_depth 控制递归深度（默认不嵌套）。同时，同级 subagent 之间共享一层 file-coordination，避免它们在文件系统上互相覆盖彼此的修改 [Release v0.11.0 “Smarter delegation”]。

把这六层合在一起看：Hermes 本质上是一个以消息网关为入口、以封闭学习回路为内核、以多后端沙箱为手脚、跨模型厂商自由切换的常驻 agent。它不是一个 IDE 插件，不是一个聊天机器人包装，也不是一个纯 SDK，而是一个"长在用户自己服务器上的软件生物"。

[PATTERN] 判断一个 agent 框架有没有长期价值：看它有没有"能力在时间上累积"的机制。只能把任务做完一次不留痕的 agent，和 Hermes 这种每次做完都能蒸馏出 skill 的 agent，一年之后的能力差距是复利级别的，不是线性级别的。

组件落地：Hermes 自带什么、你要补什么、你要看什么

上一节六层架构是从概念角度的拆分。这一节把六层映射到 repo 里实际的目录、进程和数据落点，回答三个工程化决策必须先回答的问题——Hermes 自带哪些组件、用户要自建哪些组件、跑起来后日常要运维哪些组件。

静态视图：组件分层图

下图把 hermes-agent 仓库里和你部署后会真实存在的东西画在一张图上。左半边是进程、中间是核心库、右半边是依赖与可选远端服务，最下方是落盘的状态目录 [Hermes Agent Architecture, hermes-agent.nousresearch.com/docs/developer-guide/architecture]。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
┌──────────────────────────────────────────────────────────────────┐
│  外部消息平台（用户触达侧）                                        │
│  Telegram · Discord · Slack · Feishu · WeCom · iMessage · ...    │
└────────────────────────┬─────────────────────────────────────────┘
                         │ webhook 或 long-polling
              ┌──────────▼─────────────────────┐
              │  hermes-gateway 进程（daemon） │
              │ ┌─────────────────────────────┐│
              │ │ Platform Adapter (17+)      ││
              │ │  gateway/platforms/*.py     ││
              │ ├─────────────────────────────┤│
              │ │ GatewayRunner / delivery /  ││
              │ │ session resolver / auth     ││
              │ ├─────────────────────────────┤│
              │ │ Cron Scheduler (60s tick)   ││
              │ │  cron/scheduler.py          ││
              │ ├─────────────────────────────┤│
              │ │ HTTP API Server :8642       ││
              │ │  /v1/chat/completions       ││
              │ │  /v1/runs (SSE)             ││
              │ └────────────┬────────────────┘│
              └──────────────┼─────────────────┘
                             │ create AIAgent(history)
              ┌──────────────▼─────────────────┐
              │  AIAgent 主循环 (run_agent.py) │
              │  synchronous orchestration     │
              │ ┌─────────────────────────────┐│
              │ │ Hooks: pre/post_llm,        ││
              │ │        pre/post_tool        ││
              │ ├─────────────────────────────┤│
              │ │ Transport ABC               ││
              │ │  anthropic / bedrock /      ││
              │ │  chat_completions / codex   ││
              │ ├─────────────────────────────┤│
              │ │ Tool Dispatcher (40+)       ││
              │ │ memory · skills · search ·  ││
              │ │ delegate · file_op · web    ││
              │ └────────────┬────────────────┘│
              └──────────────┼─────────────────┘
                             │
   ┌─────────────────────────┼──────────────────────────────────┐
   │                         │                                  │
┌──▼─────────┐  ┌────────────▼──────────┐   ┌──────────────────▼──┐
│ Subagent   │  │ Sandbox 七后端        │   │ Tool Gateway (可选)  │
│ pool       │  │ local / Docker /      │   │ *-gateway.nous       │
│ leaf vs    │  │ SSH / Singularity /   │   │ research.com         │
│ orchestr.  │  │ Daytona / Modal /     │   │ 走 Nous Portal 订阅  │
│ depth ≤ 3  │  │ Vercel Sandbox        │   │ 复用 vendor key 额度  │
└────────────┘  └───────────────────────┘   └──────────────────────┘
                             │
                             ▼
              ┌───────────────────────────────────┐
              │ 外部 LLM API                      │
              │ Anthropic / OpenAI / OpenRouter / │
              │ Bedrock / NIM / Qwen / vLLM / ... │
              └───────────────────────────────────┘

╔══════════════════════════════════════════════════════════════════╗
║ 状态目录 HERMES_HOME（默认 ~/.hermes/，root native 在            ║
║ /var/lib/hermes/.hermes/，Windows 在 %LOCALAPPDATA%\hermes）     ║
║   ├─ config.yaml  .env  auth.json  SOUL.md   ← 用户/wizard 写    ║
║   ├─ state.db (SQLite + FTS5)                ← session 历史      ║
║   ├─ memories/MEMORY.md                      ← agent 写 (≤2.2K)  ║
║   ├─ memories/USER.md                        ← agent 写 (≤1.4K)  ║
║   ├─ skills/<name>/SKILL.md + refs/...       ← agent 蒸馏 + 用户 ║
║   ├─ plugins/<name>/                         ← 用户 Python 代码  ║
║   ├─ cron/jobs.json                          ← 定时任务状态      ║
║   ├─ sandboxes/docker/<task_id>/             ← per-task 工作区   ║
║   └─ logs/{agent,gateway,errors,update}.log                      ║
╚══════════════════════════════════════════════════════════════════╝

自带组件：进程、库、数据三层

进程层（部署后实际起来的 OS 进程）：

进程 入口 作用
TUI 前台 hermes 命令 用户交互、/retry /undo /compress 等命令
Gateway daemon hermes gateway start，systemd hermes-gateway.service 或 launchd ai.hermes.gateway 单进程内 fan-out 多 platform adapter，cron scheduler 是这个进程内的 thread
HTTP API Server gateway 内子组件，默认 127.0.0.1:8642 OpenAI 兼容 /v1/chat/completions /v1/responses /v1/runs（SSE）/api/jobs/*
Subscription Proxy gateway 内子组件，:8645 透传模型不跑 agent loop，把 Hermes 当 LLM 网关用

进程模型有两个关键事实容易踩：第一，gateway 是单进程多 adapter 的 fan-out，不是每个消息平台起一个进程；第二，多 profile（hermes -p <name>）才会起多个独立 gateway 进程，每个 profile 有独立的 HERMES_HOME 与 hermes-gateway-<hash> systemd unit [Architecture, hermes-agent.nousresearch.com]。

核心库层（被进程加载的代码模块）：

模块 路径 职责
AIAgent 主循环 run_agent.py 官方明说是 synchronous orchestration engine，包揽 prompt 构造、provider 选择、tool 执行、retry、fallback、callbacks、compression、persistence
Transport 层 agent/transports/ anthropic / bedrock / chat_completions / codex 四类 ABC 实现，外加 hermes_tools_mcp_server.py
Tool 层 tools/ 40+ 内置工具：memory_tool、skills_tool 全家桶（hub/sync/guard/manager）、session_search_tool、delegate_tool、managed_tool_gateway、文件操作、execute_code、web 工具
Sandbox tools/environments/ 七后端：local / Docker / SSH / Singularity / Modal / Daytona / Vercel Sandbox（Modal/Daytona/Vercel 走 lazy_deps 按需 pip 装 SDK）
Subagent 编排 tools/delegate_tool.py ThreadPoolExecutor 并发，leaf/orchestrator 两级，max_spawn_depth ∈ [1,3] 默认 1，max_concurrent_children 默认 3，子 agent 永久禁用 delegate_task clarify memory send_message execute_code
Plugin / Hook 框架 ~/.hermes/plugins/ 加载点 register(ctx) 注册自定义工具 / 平台 / hook，hook 事件含 pre_tool_call post_tool_call pre_llm_call post_llm_call on_session_start on_session_end subagent_stop pre_gateway_dispatch

数据层（落盘的状态）：见前面 HERMES_HOME 框图。这里只补两条容易看错的事实——

第一，state.db 用 SQLite + FTS5 做全文索引，session_search_tool.py 直接走 SQL db.search_messages() / get_anchored_view() / get_messages_around()，检索过程本身不调 LLM；README 里写的"FTS5 session search with LLM summarization"，summarization 指的是检索结果回到 agent 上下文之前的摘要压缩，是 search 之外的搭配，不是检索算子本身 [tools/session_search_tool.py]。

第二，MEMORY.md 与 USER.md 有硬字符上限（约 2200 / 1375 字符）[腾讯新闻 Hermes Self-Improving 源码分析]。这条上限是有意为之的设计——强迫 agent 做信息压缩而不是无限追加，直接抑制"记忆膨胀"型故障。批评视角一节的"记忆漂移"风险已经被这条上限压住了一部分；但 skill 库没有同样的上限，skill 污染仍然要靠人工审计。

可选远端组件（自带支持但 Hermes 不替你跑）：

  • Tool Gateway：*-gateway.nousresearch.com 是 Nous-hosted 远端 SaaS，付费订阅复用 Firecrawl / FAL / OpenAI TTS / Browser Use 而省 vendor key；TOOL_GATEWAY_DOMAIN / <VENDOR>_GATEWAY_URL / TOOL_GATEWAY_USER_TOKEN 可改指自托管 [tools/managed_tool_gateway.py]。
  • Honcho：honcho-ai==2.0.1 是 Python 包依赖（不是独立服务），2026-05-12 因 mistralai 2.4.6 Shai-Hulud 蠕虫供应链事件从 [all] extras 剥离，改由 lazy_deps 在首次使用时安装 [pyproject.toml]。
  • Atropos RL 环境：独立仓库 NousResearch/atropos，配合 agent/trajectory.py + batch_runner.py 把 ShareGPT 格式 trajectory 喂给 RL 训练，不是 runtime 必需 [NousResearch/atropos]。

用户自建组件：plugin、监控、多租户、回归集

Hermes 在 plugin / skill / hook / HTTP API 这几层暴露完整的二次开发面。但生产化里下面这几块要自己补：

  • 自定义工具（plugin 机制）：放在 ~/.hermes/plugins/<name>/，三件套 plugin.yaml + __init__.py（含 register(ctx)）+ tools.py，schema 用 JSON Schema（OpenAI function-calling 风格，不是 Pydantic）。需要在 config.yaml 的 plugins.enabled 显式开启 [Plugins 文档]。
  • 自定义 skill：纯 markdown，最小骨架是 YAML frontmatter（必填 name / description）+ When to Use / Procedure / Pitfalls / Verification 四节，安装后 Hermes 自动暴露为 /<skill-name> slash command [Skills 文档]。
  • 自定义 transport / gateway：通过 plugin 的 ctx.register_platform(...) 注册——但官方没有公开的 base class API 文档，只能参考 gateway/platforms/telegram.py、discord.py 等现有实现，每个 adapter 要自己处理消息接收、session 路由、能力面（voice / files / threads / typing / streaming）、allowlist、busy-input 模式、reset policy。
  • 监控埋点：未公开自带 Prometheus exporter，只有文件日志（agent.log errors.log gateway.log update.log）。Token 计数、成本累加、合规级 trace 都要自己在 pre_llm_call / post_llm_call / post_tool_call 钩子里埋点，转发到 Langfuse、Prometheus 之类的外部系统。
  • 备份：未公开自带快照命令。生产做法是 cron 跑 rsync / restic 同步 ~/.hermes/，重点是 state.db memories/ skills/，配合 systemd timer 做增量。
  • 多租户隔离：单实例多平台账号靠 *_ALLOWED_USERS allowlist；一台机器给多个用户开独立 Hermes 靠 profile 机制，每个 profile 有独立 HERMES_HOME。跨机多 Hermes 实例之间的协调官方没给方案，常见做法是各自的 API Server 互调或共用一个消息平台 channel。
  • eval 回归集：仓库里的 batch_runner.py、mini_swe_runner.py、trajectory_compressor.py、datagen-config-examples/ 是给 RL 训练数据用的，不是产品级回归 eval framework。业务级"昨天能解的题今天还能不能解"必须自己搭。
  • 凭证管理：默认是明文 ~/.hermes/.env。企业 KMS 集成、密钥轮换、加密静态存储都要自己加，Hermes 没自带。

数据流向：消息流 + 学习回路

一次 Telegram 消息从用户发出到 agent 回复的完整链路是同步的——AIAgent 是 synchronous engine 这一条决定了链路里没有 message queue 也没有跨进程 RPC [Architecture, hermes-agent.nousresearch.com]：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
User      Telegram   Gateway          AIAgent          Tool/LLM       state.db
 │  msg   │            │                │                │              │
 │ ──────▶│            │                │                │              │
 │        │ poll/hook ▶│                │                │              │
 │        │            │ on_message()   │                │              │
 │        │            │ allowlist      │                │              │
 │        │            │ resolve session│                │              │
 │        │            │ load history ◀────────── read ─────────────────│
 │        │            │ scoped lock    │                │              │
 │        │            │ new AIAgent ──▶│                │              │
 │        │            │                │ pre_llm hook   │              │
 │        │            │                │ inject:        │              │
 │        │            │                │  · MEMORY.md   │              │
 │        │            │                │  · USER.md     │              │
 │        │            │                │  · matched     │              │
 │        │            │                │    skills      │              │
 │        │            │                │  · FTS5 anchor │              │
 │        │            │                │ Transport ────▶│              │
 │        │            │                │           call LLM            │
 │        │            │                │ ◀─ tool_call ──│              │
 │        │            │                │ pre_tool hook  │              │
 │        │            │                │ dispatch ─────▶│              │
 │        │            │                │      run in sandbox           │
 │        │            │                │ ◀─── result ───│              │
 │        │            │                │ post_tool hook │              │
 │        │            │                │ (loop until    │              │
 │        │            │                │  final answer) │              │
 │        │            │                │ persist ──────────── write ──▶│
 │        │            │ ◀── reply ─────│                │              │
 │        │ ◀── send ──│                │                │              │
 │ ◀ 回复 │            │                │                │              │

这条链路里有四个关键观察。第一，load history 与 persist 都直接打 SQLite，没有缓存层，所以 SQLite 文件的写入并发是单一 gateway 进程内序列化的；多 profile 各跑独立 gateway 才能并发。第二，pre_llm_call 阶段把 MEMORY / USER / skills / 历史检索结果一次性注入 system prompt，是 Hermes 跨会话能力的物理基础。第三，tool 执行进沙箱后端，不同后端的隔离粒度差别很大——local 后端是同进程子进程、Docker 后端是 --cap-drop ALL + tmpfs + 50GB 容器盘 + 敏感环境变量按名 strip [Security 文档]，serverless 后端是远端 SDK 调用。第四，整条链路是同步的——HTTP API 那条 /v1/runs SSE 路径之所以单独存在，正是为了把这条同步链路包装成 long-running 异步 run + SSE 进度流给外部系统消费。

学习回路单独走另外三条触发路径，回路里没有反向训练模型权重，只是把经验落到外部存储，下一轮 prompt 启动时再注入回去：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
                  ┌── AIAgent 主循环 (synchronous) ──┐
                  └─────────────────┬─────────────────┘
                                    │
      ┌─────────────────────────────┼──────────────────────────┐
      │ 任务执行中                  │ 任务结束后               │ 后台周期 60s tick
      │ LLM 自决                    │ LLM 自决                 │ Cron Scheduler
      ▼                             ▼                          ▼
┌──────────────────┐        ┌──────────────────┐       ┌──────────────────────┐
│ memory_tool      │        │ skill_manager    │       │ Nudge: 起 fresh      │
│ "把这条压进      │        │ _tool 蒸馏       │       │ AIAgent (无 history) │
│  MEMORY/USER"    │        │ skills/<n>/      │       │ 复盘最近 session →   │
│                  │        │  SKILL.md +      │       │ 写 MEMORY 或新建     │
│ 字符上限强制压缩 │        │  refs/templates/ │       │ skill                │
│ (≤2.2K / ≤1.4K)  │        │  agentskills.io  │       │                      │
└────────┬─────────┘        └────────┬─────────┘       └──────────┬───────────┘
         │                           │                            │
         ▼                           ▼                            ▼
  memories/MEMORY.md          skills/<name>/                状态目录全局更新
  memories/USER.md            SKILL.md
         │                           │
         │ 下一会话启动              │ 下一会话语境匹配
         ▼                           ▼
  memory_provider           skills_tool 召回
  注入 system prompt        相关 SKILL 文档
         │                           │
         └────────────┬──────────────┘
                      ▼
      ┌────────────────────────────┐    ＋ session_search_tool
      │ 下一轮 AIAgent             │       SQLite FTS5 查 state.db
      │ ─────────────────────────  │       取相关 anchor + 上下文窗
      │ 拿到累积的经验，           │
      │ 答得比上一次好             │
      └────────────────────────────┘

回路最值得注意的不是它复杂，而是它没有训练步骤——所有"学习"都是把自然语言写到 markdown 文件，下次再以 prompt 形式注入回去。这意味着回路的可靠性完全押在了 LLM 自己"决定何时写 / 写什么"的能力上。LLM 判断错就写错，写错就把错的固化进 skill 库，下次召回再放大错的——这是「批评视角」一节里"回路病"的物理来源。Hermes 文档目前没给 skill 审计命令、memory 快照、回路阻断开关，运维要靠 vim ~/.hermes/memories/MEMORY.md 和定期 grep ~/.hermes/skills/。

运维清单：跑起来后每天看什么

关注点 看哪里 常用命令
进程健康 hermes gateway status、systemd journalctl -u hermes-gateway -f hermes doctor
会话恢复 ~/.hermes/sessions/、state.db hermes --continue、hermes --resume <id>、hermes sessions list
日志 ~/.hermes/logs/{agent,gateway,errors,update}.log hermes logs
磁盘占用 state.db（线性增长，无官方清理）、sandboxes/docker/<task_id>/（默认 50GB/task，需 cron 清） du -sh ~/.hermes/*
记忆漂移 memories/MEMORY.md、memories/USER.md（纯文本可改） 直接编辑；想做版本管理就把 ~/.hermes/ 自己 git 化
Skill 污染 skills/<name>/SKILL.md 全是 markdown rg -l '...' ~/.hermes/skills/，定期审计删错的
Token / 成本 自己在 pre_llm_call / post_llm_call hook 埋点 Hermes 不算账
模型切换 不重启 daemon hermes model
重新走 wizard 配置丢了或要重置 hermes setup、hermes setup memory
TUI 内修复 上一轮跑歪了 /retry、/undo、/compress

[PATTERN] 把抽象架构图落地到工程方案：拿到一个 agent 框架的"几层架构"图，不要停在抽象层。用三个问题把它拆开——①每一层在文件系统里是哪个目录、运行时是哪个进程、数据落在哪个文件；②哪些是框架自带、哪些要你自己写代码补；③这个框架跑起来后你每天要监控哪些指标、清理哪些状态、修复哪些故障。这三个问题答完，抽象图才变成可以采用的工程方案——回答不出来的部分，就是你采用之后会被卡住的地方。

历史谱系：从 ReAct 到 Hermes 的 scaffolding 三级跃迁

Hermes 不是凭空出现。要理解它在 2026 年这个时点出现的必然性，需要把 agent 领域过去四年的关键工作串起来看——每一代方案都在回答上一代的失败模式，这条演化线直到 Hermes 和 Anthropic 四篇 harness 博客才合拢。

2022 - 2023：学术奠基

  • ReAct（Yao et al., arXiv:2210.03629，2022-10）[Yao et al., 2022] 首次把 reasoning 和 acting 交织写进同一段 prompt，让 LLM 既生成思考轨迹又生成工具调用。它是所有后续 agent scaffold 的 ancestor，今天所有主流 agent loop 里都有 ReAct 的影子。
  • Reflexion（Shinn et al., arXiv:2303.11366，NeurIPS 2023）[Shinn et al., 2023] 把"反思"作为 agent 的一等公民引入：agent 完成一次任务后用自然语言写出自我反思，下一轮把反思拼进 prompt，形成不靠权重更新的 verbal reinforcement。这是 Hermes skill creation 机制在学术上的先导。
  • Voyager（Wang et al., arXiv:2305.16291，2023）[Wang et al., 2023] 在 Minecraft 里做了 lifelong learning——GPT-4 驱动的 agent 持续探索、生成技能、改进技能、复用技能。Voyager 的 skill library 几乎是 Hermes skills 系统的直接思想来源，区别只在于 Voyager 的 skill 是 JavaScript 代码，Hermes 的 skill 是自然语言文档 + YAML frontmatter。

[PATTERN] 识别一个工程项目的学术血脉：不看它引用谁，看它的核心机制能不能在三到五年前的学术论文里找到对应物。Hermes 的 memory curation 对应 Reflexion，skill library 对应 Voyager，subagent orchestration 对应 HuggingGPT 和 AutoGen——这不是抄袭，是工程化地把学术想法装配成可以长期运行的产品。

2024 - 2025：工程化爆发

2024 年是 agent 工程化的元年。三件事并行发生：

  • Anthropic 的〈Building Effective Agents〉（2024-12-19） [Anthropic, 2024] 把 agent 从学术 demo 推向生产实践。它给出了六种 workflow pattern：prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer，以及 agent 本身作为一种自主形态。Evaluator-optimizer 成为后续所有 harness 设计的关键砖块。
  • 多 agent 框架（LangGraph、AutoGen、CrewAI、MetaGPT）进入生产视野，但大多数停在"多 agent 如何协作"这一层，对"agent 长期运行"这个问题给不出系统答案。
  • Cursor、Windsurf、Cline 等 IDE 内 agent 证明了 coding agent 作为产品形态可以盈利，把 agent 从"实验室好玩的东西"推到"每月付费的工具"。

2025 - 2026：Scaffolding 竞赛

2025 年下半年到 2026 年上半年发生了三件相互激发的事：

  • Anthropic 连发三篇 harness engineering 博客，分别回答 research 系统如何分工、长程任务如何过 context 墙、evaluator 如何真正发挥作用。
  • OpenAI 发布 Symphony（2026 年 3 月），把 issue tracker 当 control plane，把 coding agent 升级成常驻编排服务 [openai/symphony]。
  • Nous Research 发布 Hermes Agent（2026-02-25），把 agent 从"干活工具"升级成"会在时间里长大的软件生物"。

这三件事共同揭示了一个事实：当模型能力到了某个阈值之后，模型外部的 scaffolding 设计成为决定 agent 产品差异化的主战场。Prompt Engineering → Context Engineering → Harness Engineering 的三级跃迁在这个阶段完成。（这条演化线的详细展开见《Harness Engineering 完整指南》，本文只引用不复述。）

Hermes 的独特贡献是在 Harness Engineering 这一级之上叠加了时间维度：它要回答的不是"这一次任务怎么做好"，也不是"这一批任务怎么协调"，而是"这个 agent 跑半年之后应该比今天的自己强多少"。这是一个比 Anthropic harness 博客讨论的问题更远一步的问题。

演化阶段 代表工作 核心命题
学术奠基（2022-2023） ReAct、Reflexion、Voyager 让 LLM 既能 reasoning 又能 acting，并能从经验里回看
工程化爆发（2024-2025） Anthropic Building Effective Agents、AutoGen、LangGraph、Claude Code、Cursor 从 demo 到可以跑在生产的多 agent workflow
Scaffolding 竞赛（2025-2026） Anthropic harness 三篇、OpenAI Symphony、Hermes Agent 模型外部的编排、隔离、记忆、演化成为差异化主战场
时间维度（Hermes 引入） Hermes 的 self-improving loop 让 agent 在一个固定模型上跑得越久越强

范式跃迁还是渐进演化：从工具调用到自进化的三代 Agent

把前一节的历史线拉直，可以识别出三代 agent 范式。每一代的核心能力边界发生了质变，而不仅仅是功能更多或模型更强。

第一代：工具调用型 Agent（2022-2023）

ReAct 论文确立的基本形态。agent 能做的事是：接收指令 → 推理 → 调用工具 → 返回结果。核心限制是单轮性——没有跨任务的状态保持，每次调用都是无状态的。ChatGPT Plugins、早期 LangChain Agent、Toolformer 都属于这一代。

关键缺失：没有记忆，没有规划，没有从错误中恢复的能力。

第二代：自主型 Agent（2023-2025）

AutoGPT（2023-03）标志着第二代的开端。这一代 agent 获得了三个第一代不具备的能力：多步规划（把复杂目标分解成子任务逐步执行）、会话内自我修正（执行过程中检测错误并调整策略）、工具组合（一次任务里串联多个工具完成复合操作）。

Claude Code、Cursor、Devin、Codex CLI 都是第二代的成熟产品。它们已经能独立完成相当复杂的编码任务，但共享一个天花板：会话结束即清零。这次会话里积累的所有经验——哪些方法走不通、用户偏好什么风格、代码库有什么隐含约定——都随会话关闭而丢失。

CLAUDE.md 和 .cursorrules 这类项目上下文文件是对这个天花板的手动补丁：人类把经验手动编码成静态文件，注入下一次会话。记忆不至于完全清零，但增长速度受限于人类的维护纪律。

第三代：自进化型 Agent（2026-）

Hermes Agent 的设计目标指向一个第二代未曾触及的问题：agent 能不能不依赖人类手动编码经验，自己从任务执行中积累能力？

第三代的标志性能力是封闭学习回路——自主完成"执行 → 反思 → 蒸馏 → 持久化 → 召回"的全链条，人类不需要介入这个过程。具体到 Hermes：第一代的工具调用能力它有，第二代的多步规划和自我修正它也有，第三代独有的是完成任务后自主判断经验是否值得保留、蒸馏成 skill 文档落盘、下次遇到类似语境时自动召回。

学术上的对应关系：第一代对应 ReAct，第二代对应 Plan-and-Execute 和 Reflexion 的单次反思，第三代对应 Voyager 的 lifelong learning。Voyager 在 Minecraft 沙箱里验证了可行性，Hermes 在真实的多平台工作流里工程化了同一个想法。

范式跃迁的判定

判断这三代之间是否构成"范式跃迁"而非"渐进改良"，可以用一个测试：前一代能不能通过堆量实现后一代的核心能力？

  • 第一代 → 第二代：通过增加 prompt 长度和工具数量，第一代无法获得多步规划能力。质变，不是量变。构成范式跃迁。
  • 第二代 → 第三代：判断更微妙。第二代可以通过"人类勤勉维护 CLAUDE.md"来近似模拟第三代的跨会话经验积累。人工维护的上限低、速度慢、覆盖不全，但原理上可行。

严格来说，第二代到第三代的跃迁不如第一代到第二代那么干净。第二代加上足够勤奋的人工维护，能覆盖第三代的大部分效果。第三代的贡献不是"做到了不可能的事"，而是"把人做得到但很难坚持的事自动化了"。这更接近工程优化而非范式断裂。

但时间尺度拉长到半年以上，差距会被放大。人工维护 CLAUDE.md 的团队在第六个月的经验积累速度，和 Hermes 自动蒸馏的速度之间，差距不是线性的。自动化的经验积累具有复利效应——新 skill 提升执行质量，更高质量的执行产生更好的新 skill——这条正反馈回路是手动维护无法复制的。

结论：第二代到第三代是一次工程范式的跃迁，不是理论范式的跃迁。它把"可能但昂贵"变成了"自动且廉价"，在足够长的时间窗口上，效果差异会从可忽略变成不可忽略。

[PATTERN] 判断 agent 代际是否构成范式跃迁：问一个问题——前一代能不能通过堆量（更多工具、更长 prompt、更勤的人工维护）达到后一代的核心能力？如果不能，是理论范式跃迁；如果能但效率差距随时间放大到不可忽略，是工程范式跃迁。两者都有实践意义，但含义不同。

记忆架构横评：从无状态到封闭学习回路

把 2026 年主流智能体方案的记忆设计摊开来看，可以归纳成五个成熟度等级。这不是一个"越高越好"的评分——不同等级对应不同的场景需求和运维复杂度，选错等级比选低等级更危险。

Level 0：无状态（Stateless）

代表：早期 Aider

每次会话从零开始。用户的偏好、项目约定、历史决策全部丢失，下一次会话需要从头交代全部背景。这不是一种设计选择，而是记忆机制尚未实现的原始状态。当前 Aider 已经演进到支持 repo map 等项目级上下文，严格意义上不再属于 L0，但早期版本是这一层级的典型代表。

Level 1：会话持久化（Session Persistence）

代表：Crush（Charmbracelet 的终端编程 Agent）

会话内容以 SQLite 落盘，可以列出历史 session、恢复上下文。Crush 支持"每个项目维护多个工作会话"，并且可以在会话中途切换模型而保持上下文。

局限：会话是被动存储的。agent 不会从历史会话中提取经验，用户需要自己找到相关的旧 session 并手动恢复。记忆是仓库，不是认知。

Level 2：项目上下文注入（Project Context Injection）

代表：Claude Code（CLAUDE.md + project skills）、Cursor（.cursorrules）、Crush（AGENTS.md + AgentSkills.io）

在 Level 1 基础上加一层静态配置文件：每次会话启动时，agent 自动读取预定义的上下文文件，获得项目约定、构建命令、代码风格偏好等信息。Claude Code 用 CLAUDE.md 和 project skills，Crush 用 AGENTS.md 和 AgentSkills.io 标准的 skill 目录，Cursor 用 .cursorrules。

这一层的关键设计决策是记忆的所有权归用户：用户手动撰写和维护这些文件，agent 只读不写。这保证了可解释性和可审计性——文件里写了什么，agent 就知道什么，没有隐藏状态。

Claude Code 的 project skills 机制值得单独拆解。一个 skill 是一份 Markdown 文件，放在 .claude/skills/ 目录下，agent 在语境匹配时自动召回。这和 Hermes 的 skill 有一个根本区别：Claude Code 的 skill 是人写的指令，Hermes 的 skill 是 agent 从经验中蒸馏的文档。前者是教科书，后者是笔记本。

Crush 更进一步——它会从 .claude/skills 和 .cursor/skills 目录发现 skill，刻意兼容竞品的 skill 生态。这是一个值得注意的生态位选择：不自己造标准，而是寄生在已有标准上。

局限：静态文件不会自己生长。项目演化了、团队换人了、技术栈迁移了，CLAUDE.md 不会自动更新。记忆的质量完全取决于用户的维护纪律。

Level 3：跨平台会话与技能注册（Cross-Platform Sessions + Skill Registry）

代表：OpenClaw

OpenClaw 在 Level 2 基础上做了两件事：第一，把会话从单终端扩展到 20+ 消息平台，用户在 Telegram 开的对话可以从 Slack 继续；第二，建立了 ClawHub 技能注册中心（clawhub.ai），社区可以发布和发现 skill。

OpenClaw 的 SOUL.md 定义了 agent 的人格和行为准则（类比 Claude Code 的 CLAUDE.md），AGENTS.md 定义了多 agent 路由规则，TOOLS.md 定义了工具权限。这三份文件加上 ClawHub 的技能注册，构成了 OpenClaw 的"记忆"——但这里的"记忆"打了引号，因为它本质上还是人类策划的配置，不是 agent 从经验中积累的知识。

OpenClaw 在记忆层面的缺位是刻意的设计选择还是路线图上尚未实现的功能，目前没有官方说明。从架构重心看，OpenClaw 把投入放在了网关覆盖面和多 agent 路由上——它优先解决的是"agent 怎么无处不在"，而不是"agent 怎么越来越聪明"。这和 Hermes 的优先级排序恰好相反。

Level 4：封闭学习回路（Closed Learning Loop）

代表：Hermes Agent

Hermes 在 Level 3 的全部能力之上，叠加了四个相互咬合的子机制，构成一条不依赖模型权重更新的经验积累回路：

  1. Agent-curated memory：agent 自己往 MEMORY.md 与 USER.md 里追加它认为值得持久化的信息，并会在合适时机主动触发持久化动作
  2. Autonomous skill creation：完成复杂任务后，agent 把经验蒸馏成 skill 文档，后续语境匹配时自动召回。兼容 agentskills.io 开放标准
  3. FTS5 session search + LLM summarization：历次对话以 SQLite FTS5 索引落盘，agent 可以用 LLM 摘要检索自己过去的行为和决策
  4. Honcho dialectic user modeling：接入 plastic-labs/honcho 做辩证式用户建模，跨会话持续精修"用户是什么样的人"这个模型

这条回路的设计哲学：不是让模型变强，而是让 agent 在一个固定模型上越跑越强。即使底层 LLM 不升级，skill 库、memory、user model 也会持续膨胀，agent 的有效能力随之增长。

五级记忆成熟度速查

等级 记忆形态 代表方案 记忆所有权 记忆增长方式 典型风险
L0 无状态 无 早期 Aider — — 每次会话从零开始
L1 会话持久化 SQLite session Crush 系统自动 被动存储 旧 session 难以定位
L2 项目上下文注入 CLAUDE.md / AGENTS.md / .cursorrules Claude Code、Cursor、Crush 用户手动 人工维护 维护纪律衰减，文件腐化
L3 跨平台会话 + 技能注册 SOUL.md + ClawHub + 多平台 session OpenClaw 用户 + 社区 人工 + 社区贡献 技能质量参差，无自主积累
L4 封闭学习回路 memory + skills + user model + session search Hermes Agent agent 自主 自动蒸馏 + 自动持久化 skill 污染、记忆漂移、不可解释性

[PATTERN] 选择记忆等级的决策框架：不要追求最高等级，而要匹配运维能力。L2 的可审计性在企业合规场景里是优势不是劣势——CLAUDE.md 里写了什么，审计就看什么，没有黑盒。L4 的自主学习在个人极客场景里是资产，但在团队场景里可能是难以审计的负债。记忆等级的选择本质上是 agent 自主权和人类控制权之间的平衡决策。

生态定位：2026 年 agent 赛道里的坐标

Hermes 不是这条赛道上的独行者。要判断它的真实位置，必须和周边四类玩家横着比一次。下面这张表列出的对比维度刻意选了最能暴露架构差异的几项：部署形态、持久化记忆、UI 入口、模型绑定、license，而不是泛泛地列功能清单。

产品 赛道 后端模型 记忆等级 UI 入口 License
Hermes Agent 长程自主智能体 模型无关（BYO LLM） L4 封闭学习回路 CLI / 17+ 消息平台 MIT
OpenClaw 通用智能体 模型无关 L3 跨平台会话 + ClawHub 技能注册 CLI / 20+ 消息平台 / macOS·iOS·Android 伴侣 App MIT
Claude Code 编程智能体 绑 Anthropic L2 CLAUDE.md + project skills IDE + CLI 闭源
Crush 编程智能体 模型无关 L2 AGENTS.md + AgentSkills.io，兼容 .claude/skills 终端 TUI FSL-1.1-MIT
Claude Agent SDK 编排框架 绑 Anthropic 由使用者实现 取决于使用者 分版本
OpenAI Symphony 编排规范 Codex 绑 OpenAI L0 每个 issue 一个一次性 agent Linear / tracker Apache 2.0
Devin 编程智能体（SaaS） 自研 harness 有，但数据归 SaaS Web 闭源
Aider 编程智能体 模型无关 L1 repo map + 会话 终端 Apache 2.0
LangGraph / AutoGen / CrewAI 编排框架 模型无关 由使用者实现 SDK 调用方决定 MIT / Apache 2.0

把这张表里的每一行都当成一个 agent 产品在答题，Hermes 答的题和别人答的根本不是一道题。

Claude Code 和 Claude Agent SDK 在回答"Anthropic 自家生态怎么把 Claude 模型包装成一个好用的 agent"。OpenAI Symphony 在回答"把 Codex 嵌入 issue 流水线要怎么设计编排契约"。Devin 和 Copilot Workspace 在回答"怎么让企业用户付费订阅一个完整的自动编码服务"。Aider 在回答"单文件 CLI agent 怎么做得好用"。LangGraph 和 AutoGen 在回答"给开发者一套多 agent 编排的积木"。

Hermes 回答的问题是：“一个普通开发者或小团队，怎么拥有一个 agent，让它住在自己的服务器上、用自己选的模型、接自己的消息 app、跑越久越强”。这是唯一一个把"agent 作为私有长期资产"作为核心命题的答案。

OpenClaw vs Hermes：网关优先与记忆优先的路线分歧

和 Hermes 最像、也最容易被混淆的是 OpenClaw。OpenClaw 由奥地利开发者 Peter Steinberger（PSPDFKit 创始人）发起，以 371k stars 成为 2026 年 GitHub 上最大的开源智能体项目。Hermes Agent 官方甚至为 OpenClaw 老用户专门准备了 hermes claw migrate 命令，一键迁移 SOUL.md、skills、API keys、messaging settings [hermes-agent README “Migrating from OpenClaw”]。

两者的功能重叠度极高——都有消息网关、都有 CLI、都支持多模型、都有 skill 系统、都跑定时任务。但把架构拆到记忆层，路线分歧就彻底暴露：

维度 OpenClaw Hermes Agent
架构重心 网关覆盖面（20+ 平台 + 伴侣 App） 封闭学习回路（memory + skills + user model）
技能来源 ClawHub 社区注册 + 用户手写 agent 从任务经验中自动蒸馏 + 社区
用户建模 SOUL.md（静态人格配置） Honcho 辩证式用户建模（动态持续精修）
记忆持久化 无文档化的记忆机制 MEMORY.md + USER.md（agent 自主写入）
历史检索 session 管理（list / history） FTS5 全文索引 + LLM 摘要检索
多 agent 路由隔离（per-channel agent routing） subagent 编排（orchestrator + worker 递归）
独有能力 Voice Wake 唤醒词、Live Canvas 可视化画布、A2UI Atropos RL 环境、trajectory 压缩、模型训练数据生成

OpenClaw 在网关层做得比 Hermes 更深：不仅覆盖更多平台（含 LINE、Nostr、Twitch、Zalo 等长尾平台），还有 macOS/iOS/Android 原生伴侣 App，以及 Voice Wake 唤醒词功能。它的多 agent 路由也比 Hermes 的 subagent 编排更面向"为不同渠道配不同 agent 人格"这个场景。OpenClaw 回答的是"怎么用一个 agent 覆盖用户所有数字触点"。

Hermes 在记忆层做得比 OpenClaw 深得多：不仅有 agent 自主写入的记忆文件，还有从任务中蒸馏 skill、用 FTS5 检索历史、用 Honcho 做辩证式用户画像的完整闭环。Hermes 还有一条 OpenClaw 完全没有的支线——trajectory 压缩和 Atropos RL 环境，目标是用 agent 的行为数据来训练下一代工具调用模型。这意味着 Hermes 不仅自己在学习，还在为模型训练生产原料。

OpenClaw 的资源集中在网关覆盖面上，Hermes 的资源集中在学习回路的深度上。两者的功能重叠不改变这个优先级差异。

Crush：编程赛道的模型无关路线

Crush（Charmbracelet 维护）占据了另一个不同的生态位：它是编程智能体赛道里的模型无关方案。这里的命名关系容易误读：Crush 承接过早期已归档的 opencode-ai/opencode 代码线，但当前 OpenCode 已作为 opencode.ai / anomalyco/opencode 继续活跃演进，二者应视为不同项目，而不是“前任—继任者”关系。Claude Code 绑定 Anthropic、Codex CLI 绑定 OpenAI、Gemini CLI 绑定 Google，Crush 则支持所有主流模型提供商并可以在会话中途切换模型。

Crush 在记忆层的设计选择是务实的 L2：用 AGENTS.md 做项目上下文注入，支持 AgentSkills.io 标准的 skill 目录，并且刻意兼容 .claude/skills 和 .cursor/skills 的 skill 发现路径。这种"寄生兼容"策略让 Crush 可以直接复用 Claude Code 和 Cursor 生态已有的 skill 资产，而不需要自己从零建立 skill 社区。

Crush 没有学习回路，也没有跨会话记忆——它不试图"记住你"，只试图"在这一次会话里尽量好用"。对于一个编程智能体来说，这是合理的设计边界：编码任务天然是项目级的、会话制的，"agent 记住用户的编码偏好"这件事用一份静态的 AGENTS.md 就足够解决。

[PATTERN] 识别一个 agent 产品真正的竞争轴：不看功能列表哪条对齐，看它在回答什么问题。OpenClaw 和 Hermes 在回答同一道题（“怎么拥有常驻通用智能体”），是真正的竞品，差异在记忆深度。Claude Code 和 Crush 在回答另一道题（“编码任务怎么做好”），是另一对竞品，差异在模型绑定。跨赛道的产品之间只有互补关系，没有替代关系。

框架层 vs 产品层：能在哪些框架上做出 Hermes 等价物

本文一直把 LangGraph、AutoGen、CrewAI、Spring AI、AgentScope 这类项目排除在"agent 产品"的比较范围外，只把它们一句带过为"搭建智能体的积木"。但这种排除值得展开——一个相邻而紧密的问题是：能不能在这些框架上做出 Hermes 等价物？ 对应的相邻博客（《AgentScope 深度解析》 与 《Spring AI 深度》）梳理了这些框架的设计取向，本节把 Hermes 的产品形态反投影到框架层，看清两层之间的真实分工。

三层堆栈：产品、框架、协议

1
2
3
4
5
6
7
8
9
10
11
12
13
产品层（本文主轴）       →  Hermes Agent / OpenClaw / Claude Code / Crush / Devin
                           回答："我要给用户交付一个能用的 agent"
                                    ↑
                                  搭建于
                                    ↑
框架层（相邻博客）       →  Spring AI / AgentScope / LangChain4j / MAF /
                           LangGraph / CrewAI / AG2
                           回答："开发者怎么把 LLM 装配成一个 agent"
                                    ↑
                                  调用
                                    ↑
协议与 SDK 层            →  MCP / A2A / Anthropic SDK / OpenAI SDK / Bedrock SDK …
                           回答："agent 之间、agent 与模型之间怎么通信"

三层之间不是简单的"上层调用下层"——产品也可以跳过框架层直接调模型 SDK，Hermes 就是这种做法（前文 § 三 Hermes 的"第 1 层 Agent 核 + transport ABC"是项目自己写的，并没有建立在 Spring AI / AgentScope / LangGraph 之类的公共框架之上）。这种跳层选择本身是一个值得专门解读的工程信号，而不是 Hermes 团队"没用过框架"那么简单——后面会拆开讲。

框架天花板：把 L0–L4 记忆模型反投影到框架层

前文 § 七 给出了 L0–L4 记忆成熟度模型——L0 无状态、L1 会话持久化、L2 项目上下文注入、L3 跨平台会话 + 技能注册、L4 封闭学习回路。这个模型是用来给产品打分的。把同一个模型搬到框架层再看一次，能拿到一张完全不同的表——它衡量的不是"框架达到了几级"，而是"这个框架默认带你到几级、要再往上你要自己补什么"。

框架 默认覆盖等级 内置能力 要爬到更高需要补什么
Spring AI L1 MessageWindowChatMemory + JdbcChatMemoryRepository 提供会话持久化；CONVERSATION_ID 隔离 L2 要自己写 system prompt 注入；L3-L4 要自己拼 skill 库、session 全文检索、用户建模
LangChain4j L1 MessageWindowChatMemory / TokenWindowChatMemory + ChatMemoryProvider per-conversation 同上
AgentScope L2-L3 工作记忆 + 长期记忆双层（ReMePersonalLongTermMemory / ReMeTaskLongTermMemory / ReMeToolLongTermMemory / Mem0LongTermMemory），A2A 跨服务通信，OTel + Studio L4 还差自动 skill 自蒸馏；hook（pre/post_reply）层加挂并不困难
LangGraph L1（time-travel 是这一档的最强实现） checkpointer + thread_id + update_state(as_node=...) L2-L4 要自己设计 state schema 与 skill 库；time-travel 不等于自我学习
MAF（SK + AutoGen 后继） L1-L2 session-based state、middleware pipeline、可插拔 memory L3-L4 要自己实现 skill 注册与自蒸馏
CrewAI L1-L2 unified Memory（LanceDB）、Flows @persist、self.remember/recall L3-L4 要自己实现 skill 自蒸馏与跨平台会话
Claude Agent SDK L0 纯编排积木，记忆完全外置 全部要自己实现

读这张表的方式不是"AgentScope 比 Spring AI 高一级所以更好"——而是"框架层默认覆盖到几级，决定了产品层最终能不能廉价地达到那一级"。Spring AI 默认到 L1 是它对自身的诚实定位，因为 Spring AI 明确选了"做 SDK 不做 framework"的路线（参见 Spring AI 深度 § 三）；AgentScope 默认到 L2-L3 是它的研究取向决定的——长期记忆和分布式协作是它从 v0.x 时代就在啃的题。

[PATTERN] 框架选择决定了产品的记忆天花板：一个团队选 Spring AI 然后想做 L4 自进化 agent 不是不可能，但路径是"在 Spring AI 之上把封闭学习回路从零写一遍"——这不是框架的功能空白，是框架的职责边界。要让"爬到 L4"变得便宜，要么换默认起点更高的运行时（AgentScope 比 Spring AI 起点高一档），要么干脆跳过框架层直接做 harness（这是 Hermes 选的路）。

能在 Spring AI 或 AgentScope 上做出 Hermes 吗？

把 Hermes 的封闭学习回路四件套拆出来逐项对照——agent-curated memory（自主写 MEMORY.md / USER.md）、autonomous skill creation（任务后蒸馏 skill 文档）、FTS5 session search + LLM summarization、Honcho dialectic user modeling——能精确判断在每个框架上的实现成本。

Spring AI 路径：可行，但很重。Spring AI 的 @Tool + Advisor + ChatMemory + MCP 已经覆盖 Hermes 的工具层与消息层骨架；缺的是封闭学习回路全部四个子机制——四件套都得用户自己实现，Spring AI 帮不上忙。Advisor 的 interceptor 形态可以方便地把"对话结束后调一次蒸馏 LLM"塞进 post-call 阶段，但 skill 注册表、session 索引、user model 的存储与召回完全要自建。换句话说：Spring AI 的默认天花板在 L1，要到 L4 你要在它之上叠一整层自研 harness，工程量与从零做差不多。

AgentScope 路径：天花板更高，缺口更窄。ReMe* 系列已经把长期记忆做成 first-party 一等公民（Personal / Task / Tool 三级，2026-04 加入 OceanBase / seekdb 向量后端），tracing 模块走 OTel 与 Studio 直连，A2A 协议把跨服务通信标准化，Trinity-RFT 提供调优后端。要在 AgentScope 上长出 Hermes 等价物，主要还差自蒸馏 skill 这一块——v1.x 的 ReAct 循环里没有显式的"任务结束后自动生成 skill 文档并落盘"机制，但 pre_reply / post_reply hook 是为这种扩展设计的，加挂自蒸馏逻辑不算重活。这与 Spring AI 的差距大约是"叠 30% 工程量" vs “叠 100% 工程量”。

LangGraph 路径：适合写"有可审计性的 L4 agent"。checkpointer + time-travel 让经验回看变得便宜，状态变更天然可 replay。但 LangGraph 同样不带 skill 库或用户建模，仍要自己拼。它的优势在 L4 的"可审计"维度，不在"易构建"维度。

直接用模型 SDK 路径（Hermes 实际选的）：跳过所有框架，自己写 transport ABC（前文 § 三 第 1 层）、自己设计六层架构。代价是工程量最大，收益是没有任何框架预设把封闭学习回路的设计扭曲掉——封闭学习回路要求 memory / skill / session / user-model 四个子系统紧密协同，这种跨子系统的协同与"框架的模块边界"天然有冲突，框架的"清晰抽象"在这种场景下反而是阻力。

[PATTERN] 跳过框架层是一种正当的工程选择：当一个产品的核心命题（如 Hermes 的封闭学习回路）需要跨多个抽象层（memory / tool / runtime / agent loop）做协同设计时，框架的模块边界会变成产品的设计阻力。这也解释了为什么主流的 agent 产品——Hermes、Claude Code、Cursor、Devin、Crush——都没有建立在公共 agent 框架之上。框架不是给产品做的，框架是给"产品里那些不需要发明新协同模式的部分"做的。

三代 agent 范式与框架选择的对应

把前文 § 五（三代 agent 范式：工具调用型 / 自主型 / 自进化型）和框架选择对齐，能得到一个简洁的判断：

你要做的 agent 形态 该用的框架
工具调用型（Gen 1）：单轮 tool calling，企业系统集成 Spring AI / LangChain4j / Semantic Kernel 1.x。SDK 路线足够
自主型（Gen 2）：多步规划、多 agent 协作、会话内自我修正 AgentScope / LangGraph / MAF / CrewAI / AG2。Runtime 路线必要
自进化型（Gen 3）：跨会话经验积累、自动 skill 蒸馏、长期 user model 没有现成框架。基于 Gen 2 框架自建 + 协议层（MCP / A2A）；或像 Hermes 一样跳过框架层直接做 harness

注意第三行的"没有现成框架"不是说不可能——是说做 Gen 3 的边际成本主要不来自框架抽象，来自封闭学习回路的设计本身。框架在这一档的价值从"提供能力"降级为"提供脚手架"，而脚手架的价值取决于它有没有挡住你的设计。这与 Gen 1 阶段"框架直接提供能力"的体验完全不同。

[PATTERN] 框架的价值密度随 agent 代际衰减：Gen 1 阶段框架的价值是"开箱即用"，Gen 2 是"运行时模型对齐"，Gen 3 阶段几乎降为零——产品的核心机制（封闭学习回路）必须自己设计。当你判断自己在做哪一代 agent 时，也就同时判断了框架对你这个产品的边际价值。

一句话收束本节的论点

Hermes 这类长程自主智能体之所以选择跳过 Spring AI / AgentScope / LangGraph 这一层，不是因为它们能力不够，而是因为它们的能力组织方式（清晰的模块边界）与封闭学习回路所要求的能力组织方式（跨模块紧耦合）相互冲突。这是产品命题决定的，不是技术决定。

Reviewer 与 SRE：Harness 的两种模式对照

Hermes 被社区广为讨论的一个具体场景是把它当做 supervisor 接在别的 agent（典型是 OpenClaw 或 Claude Code）之上：让被监督的 agent 继续干活，Hermes 在一个独立的 Discord 私有频道里值班，只在状态切换或出问题时介入。这个用法的社区范本是开发者 Graeme 发布的 Hermes-as-supervisor-for-OpenClaw 文章，它用一套极简的 4-marker 协议：

  • STATUS_REQUEST：例行问状态
  • REVIEW_REQUEST：请帮我看一下这个产出
  • ESCALATION_NOTICE：这个得你来定
  • ACK：收到并终止当前回合

每条消息必须带一个 marker 和一个 @mention；ACK 是硬终止；没有 marker 的消息被当作 informational，不回复；每轮最多 3 次来回。

这套协议最值得注意的不是它能做什么，而是它不做什么。翻遍整个协议，没有任何一条通路是 Hermes 让 OpenClaw “重做” 某个输出。所有路径最终只分叉成两条：ACK（关闭当前回合）或 ESCALATION（连同诊断一起升级给人）。

Anthropic 在四篇 harness 博客里持续推进的 evaluator-optimizer 模式，和这种 Hermes-as-supervisor 模式表面都在做"角色分离 + 审查"，但本质是两类完全不同的系统。

维度 Anthropic 式 evaluator Hermes-as-supervisor
行业类比 Code Reviewer SRE / On-call
信息流向 判断 → 生成者 → 修改 → 再判断（内循环） 判断 → ACK 或 Escalate（外循环）
系统边界 在任务执行期间做质量控制 在系统已经跑起来后做异常判断
终止条件 评审通过，合并 ACK 或 Escalate，没有"永远评审通过"的概念
失败成本 多几轮迭代 误 ACK 一个真实故障
解决的问题 “怎么把这个产出做得更好” “出问题了要不要人介入”

这两种模式不是替代关系，是两个阶段。一个 agent 项目如果还处在"产出质量不稳定"阶段，需要的是 Anthropic 的 evaluator-optimizer，让另一个角色帮它审查产出并驱动迭代。一个 agent 项目如果已经"产出基本稳定、但还是要天天盯着它"，需要的才是 Hermes 式 supervisor——给你减负，有事带诊断来、没事别打扰。

把两个阶段混做一件事，是很多团队在 agent 工程化时踩到的第一个大坑：在 agent 产出还没稳定的时候就给它配 supervisor——supervisor 没法修代码，最多升级给人，结果人被叫得更勤、agent 还是干不对活。反过来也有坑：agent 已经稳定运行了，团队还在不断堆 evaluator 层，浪费 token 不说，真实故障反而被评审意见淹没。

[PATTERN] 给你的 agent 项目选 harness 模式：先问自己的瓶颈在哪。如果瓶颈是"agent 写的东西经常不对"，选 reviewer 模式（evaluator-optimizer）；如果瓶颈是"agent 的东西大体能用，但我每天还是要盯着它"，选 SRE 模式（supervisor）。两种模式都有，但必须分阶段引入，不能同时上。

批评视角：每条赛道的真实坑点

前文按记忆等级和赛道定位做了横向对比，但对比表天然倾向于展示优势而非暴露缺陷。本节对三条赛道的代表方案逐一做批评性审视，目标不是排名，而是帮助采用者在决策前看清每个选项的真实代价。

Hermes 的坑点

Hermes 的讨论在 2026 年 3 月至 4 月被放大到了"下一代 agent 默认入口"的程度，但营销光环必须剥掉。

坑点一：star 数的观察效应

多个第三方来源在 2026 年 4 月中旬把 Hermes 描述为"一个月从 4,500 stars 冲到 100k+"的奇迹项目[sudoingX on X, 2026-04]。增长曲线本身真实（GitHub 仓库显示 stars 在 126k 左右），但它首先是观察效应，不是质量背书。Nous Research 本身在开源 LLM 圈有强社区，Hermes 4 模型的发布为这个新项目带来了免费的导流；加上 Sam Altman 等人在社交媒体上的提及，star 数被推高的部分动能来自注意力经济而非用户实际使用。

这不等于说 Hermes 不好。Hermes 的技术选择（封闭学习回路、多平台网关、模型无关）是扎实的。但用 stars 判断它对你是否适用，和用"某 AI 编程工具让团队 PR 数增加 500%"那种数字判断采用价值是同一种陷阱：公开的增长叙事服务于公开的增长叙事本身，不能替代对你自己语境的评估。

坑点二：封闭学习回路的"回路病"

Hermes 官方反复强调 “it’s the only agent with a built-in learning loop”。这句话在字面上是成立的——它确实是当前开源 agent 里唯一把 skill creation + memory curation + user modeling + session search 做成一个闭环的产品。但一个没被官方文档充分讨论的问题是：回路一旦形成，就有自我强化的偏差。

具体表现有三种：

  1. Skill 污染：如果 Hermes 从一次错误的任务里蒸馏出了错误的 skill，这份错误 skill 会被它自己召回、改进、继承到后续任务，错误被回路放大。用户不主动审计 ~/.hermes/skills/ 的话，这种污染是隐形的。
  2. 记忆漂移：Honcho 维护的 user model 会随时间持续更新。如果某个阶段用户给了一批反常行为（压力项目、深夜调试），agent 会把它们固化进 user model。数周后用户已经回归常态，agent 还在按照"那个版本的你"响应。
  3. 回路的不可解释性：为什么 agent 今天给出了这个响应？是当前 prompt 驱动的、是某条 memory 触发的、是某个 skill 召回的、还是 user model 改写了它的默认行为？Hermes 的设计让这四条路径混在一起，排障时很难把责任归到具体某一层。

这不是 Hermes 独有的问题——所有做 lifelong learning 的 agent 系统都要处理这件事。Voyager 在 Minecraft 里遇到过、Reflexion 在论文里提过、Anthropic 在 harness 博客里也间接点到。但 Hermes 的文档目前没有对这个问题给出工程化的治理方案（如 skill 审计命令、memory 快照、回路阻断开关），这是用户在采用时必须自己补的那块。

坑点三：多平台网关的真实成本

"Telegram、Discord、Slack、WhatsApp、Signal、iMessage、WeChat、DingTalk、Feishu 全都能用"读起来很诱人，但每个平台的 adapter 背后都有具体的运维负担：

  • API 配额：WhatsApp Business API 有消息配额；Telegram Bot API 对频率有限制；企业微信的回调域白名单要正确配；Feishu 需要租户级授权
  • 安全边界：每个平台都是一个 exploit surface。v0.9.0 专门发布了一轮 comprehensive security hardening，包含 path traversal protection、shell injection neutralization、SSRF redirect guards、Twilio webhook signature validation、API server auth enforcement、git argument injection prevention [Release v0.9.0]。这组修复的规模本身就说明，agent 接上消息平台后要处理的安全问题远比 CLI-only agent 多
  • 合规与审计：企业用户在 DingTalk / Feishu / WeCom 上接 agent，必须回答数据出境、内容留存、审计日志怎么对接内网合规系统的问题，这不是开箱即用的

一个简单的判断是：你不会把 17 个平台都接上。选其中 1-3 个（通常是 Telegram + Discord + CLI，或者企业场景下的 Feishu + CLI），剩下的 adapter 不要启用。Hermes 的设计允许按需启用，但文档在"哪些平台应该先启用、哪些暂不启用"上没有明确建议。

坑点四：对 Nous Portal 的隐性偏好

Hermes 声称模型无关，但 v0.10.0 的 Tool Gateway 架构里，Nous Portal 订阅用户能直接复用订阅来调 web search、image gen、TTS、browser automation，其他模型厂商的用户需要自己配这些工具的 API key。这不是错的，官方出工具也要出口，但它确实在生态层面创造了一种隐性偏好：用 Nous Portal 的用户路径最短、体验最顺。

这条偏好本身是合理的商业设计（Nous Research 需要收入来源来支持开源项目），但采用决策时要意识到：如果你的团队决定用 Hermes + 其他模型厂商（如 OpenAI、Anthropic），你需要自己补齐工具侧的 API 账户和 key 管理，Hermes 没有替你统一。这个补齐工作在企业语境下可能涉及财务审批、账号所有权、审计对接等一系列组织动作，不是纯技术问题。

坑点五：学习曲线和"配置疲劳"

README 写得很简洁：“curl 一行 install、hermes setup 配一下就能用”。这在玩具级使用上是对的。但当你开始：

  • 配置 17 个消息平台里的 3 个
  • 挑选合适的终端后端（local / Docker / SSH / Daytona / Singularity / Modal）
  • 决定启用哪些工具、哪些插件
  • 调整 context engine、compression 策略、subagent 的 max_spawn_depth
  • 审计 auto-generated skills 的质量
  • 设置 cron scheduler 跑定时任务
  • 配 security hardening（path traversal、shell injection、SSRF 各条开关）

Hermes 的配置面就暴露出来了：它不是一个"开箱即用"的 agent，它是一个给你一个可配置 agent 底座的项目。真正在生产用起来的团队，通常要在配置上投入数小时到数天。这个投入可以接受，但不能在采用决策时低估。

[PATTERN] 评估一个"自我改进"类 agent 产品的真实代价：不看 README 承诺，看三件事——第一，学习回路出错时怎么回滚；第二，每新增一层外部能力（消息网关、工具、沙箱）带来多少运维和安全面积；第三，产品是不是默默地把"自家生态"设成了最短路径。这三件事回答完，你才知道采用之后会被绑在哪里。

OpenClaw 的坑点

OpenClaw 以 371k stars 占据了开源智能体项目的头部位置，但 star 数同样不能替代对真实代价的评估。

坑点一：371k stars 与记忆缺位的反差。 OpenClaw 是当前用户基数最大的开源通用智能体，但截至本文写作时，其文档中没有描述任何持久化记忆机制。SOUL.md 定义人格、AGENTS.md 定义路由、TOOLS.md 定义工具权限，这些都是人类手动编写的静态配置。ClawHub 上的 skill 也是社区贡献的指令文件，不是 agent 从经验中蒸馏的产物。对于一个以"personal AI assistant"为定位的产品来说，"助手不记得昨天聊过什么"是一个和定位直接冲突的缺口。这个缺口是刻意的架构取舍（优先做网关覆盖）还是路线图上尚未交付的功能，官方没有明确表态。

坑点二：网关覆盖面的运维放大效应。 OpenClaw 支持 20+ 消息平台和 macOS/iOS/Android 伴侣 App，比 Hermes 的 17 个平台覆盖面更广。但覆盖面更广意味着运维面更大：每多一个平台就多一套 API 配额管理、webhook 配置、安全审计。伴侣 App 还引入了原生应用的发布、签名、版本兼容等额外维度。和 Hermes 一样，实际使用中不会把所有平台都接上，但 OpenClaw 的文档同样缺乏"推荐先接哪几个"的优先级建议。

坑点三：ClawHub 技能质量没有门槛。 ClawHub 作为社区技能注册中心，对 skill 质量没有审核机制。awesome-openclaw-skills 项目做了 5,400+ skill 的分类整理，但这是社区筛选，不是平台保证。低质量 skill 不会像 Hermes 的 skill 污染那样被回路放大（因为 OpenClaw 没有学习回路），但会浪费用户的试错时间。

坑点四：多 agent 路由的复杂性。 OpenClaw 支持按渠道/账号/对话对象把请求路由到不同 agent 实例，每个实例有独立的工作空间和 session。这是一个强大的隔离机制，但也意味着配置复杂度随 agent 数量线性增长。哪个渠道路由到哪个 agent、agent 之间是否共享 skill、session 是否跨 agent——这些问题在单 agent 使用时不存在，一旦启用多 agent 路由就必须逐一回答。

Claude Code 与 Crush 的坑点

编程智能体赛道的两个代表方案有各自不同的代价结构。

Claude Code 坑点一：单一模型供应商绑定。 Claude Code 只能使用 Anthropic 模型。如果 Anthropic 调整定价、变更 API 条款、或某个模型版本在特定任务上表现退步，用户没有切换到其他模型的选项。Crush 和 Hermes 的模型无关设计在这一点上有结构性优势。

Claude Code 坑点二：CLAUDE.md 维护纪律的自然衰减。 L2 记忆等级的核心假设是用户会持续维护项目上下文文件。实践中这份纪律有可预测的衰减曲线：项目启动前两个月维护得最勤，第三个月开始更新频率下降，半年后 CLAUDE.md 的内容和项目实际状态开始脱节。文件不会报错，agent 会安静地按照过时的约定工作，产出质量缓慢下降但不会有明显的断崖式失败，因此难以被发现。Claude Code 已经开始半自动生成部分 CLAUDE.md 内容，但这条演化路线的终点（完全自动维护）尚未到达。

Claude Code 坑点三：项目级记忆的天花板。 CLAUDE.md 和 project skills 都是项目级的。一个开发者在 A 项目积累的编码偏好不会自动迁移到 B 项目。跨项目的个人工作习惯（代码风格偏好、commit message 约定、review 标准）需要在每个项目的 CLAUDE.md 里重复声明，或者使用全局配置（~/.claude/CLAUDE.md），但全局配置的优先级管理和项目级配置之间的冲突解决是一个尚未被充分文档化的问题。

Crush 坑点一：FSL-1.1-MIT 许可证不是 MIT。 Crush 的许可证是 FSL-1.1-MIT（Functional Source License），不是纯 MIT。FSL 在发布两年后自动转为 MIT，但在此之前对商业竞品有使用限制。企业法务团队在评估时需要区分这一点，不能按 MIT 的宽松假设做采用决策。

Crush 坑点二："寄生兼容"的脆弱性。 Crush 发现 .claude/skills 和 .cursor/skills 目录的 skill 文件，这让它可以复用竞品生态的 skill 资产。但这种兼容性建立在竞品不改变 skill 格式的假设上。如果 Claude Code 或 Cursor 调整 skill 目录结构或文件规范，Crush 的兼容层会静默失效而不报错。

[PATTERN] 对每条赛道做批评性审视：批评不是否定，而是帮采用者看清代价结构。每条赛道的坑点类型不同：长程智能体的坑在学习回路的可控性，通用智能体的坑在网关覆盖的运维放大，编程智能体的坑在记忆天花板和供应商绑定。选择赛道时先确认自己能承受哪类坑。

采用决策：三条赛道的选择框架

采用决策的第一步不是比较产品，而是确认自己在哪条赛道上。赛道选错了，产品选对了也没用。

第一个问题：你的核心场景是什么？

核心场景 适配赛道 代表方案
IDE 内配对编程、代码审查、重构 编程智能体 Claude Code（绑 Anthropic）、Crush（模型无关）
跨平台消息助手、定时任务、多渠道运营 通用智能体 OpenClaw
长期驻留、跨会话积累经验、私有 AI 助手 长程自主智能体 Hermes Agent

如果核心场景是编程，不要选 Hermes 或 OpenClaw——它们的编程能力是附带的，不是优化过的。如果核心场景是消息平台上的自动化，不要选 Claude Code 或 Crush——它们活在终端里，不活在 Telegram 里。

第二个问题：你愿意让 agent 拥有多少记忆自主权？

记忆自主权 代价 适合谁
零自主权（L0-L1） 每次会话从头交代背景 偶尔用 agent 做一次性任务的用户
人类所有权（L2） 需要维护 CLAUDE.md / AGENTS.md 有纪律维护项目文档的团队，合规要求高的企业
社区共享（L3） 依赖 ClawHub 技能质量，无自主积累 看重平台覆盖面、不需要 agent "记住自己"的用户
agent 自主权（L4） 需要定期审计 skill 和 memory，回路偏差风险 愿意投入运维来换取长期能力复利的个人或小团队

L2 不是 L4 的降级版——在企业合规场景里，"agent 不能自主写入任何持久化状态"是一条硬约束，L2 的可审计性在这个场景里是功能优势。

第三个问题：你能承受哪种供应商风险？

选项 供应商风险 对策
Claude Code 绑 Anthropic 模型 + 定价 + API 条款 接受单一供应商，或用 Crush 做备选
Crush FSL-1.1-MIT 许可证的商业限制（两年后转 MIT） 法务评估 FSL 条款
OpenClaw / Hermes 开源无 SLA，排障靠自己 接受"翻源码解决问题"的运维模式
Devin / Copilot Workspace SaaS 闭源，数据归平台 接受数据不在自己手里

第四个问题：你的运维预算有多少？

编程智能体的运维成本最低（装上就用，维护 CLAUDE.md 即可）。通用智能体和长程智能体的运维成本随消息平台数量、沙箱后端类型、安全审计需求线性增长。Hermes 还额外需要 skill 审计和 memory 治理的投入。

按运维预算从低到高排序：Aider < Crush < Claude Code < OpenClaw < Hermes。

这四个问题的答案组合在一起，会自然收窄到一到两个候选方案。不需要参考 star 数，不需要看别人的选型文章，只需要看自己的场景、自主权偏好、供应商容忍度和运维预算。

模式速查表

把本文里提炼出来的 PATTERN 集中在这里：

场景 判断法则 口诀
判断两个 agent 是否可比 看它们在回答同一道题还是不同的题 不同题目之间没有竞品
判断 agent 代际是否范式跃迁 前一代能否通过堆量达到后一代核心能力 不能 = 理论跃迁，能但差距放大 = 工程跃迁
选择记忆等级 匹配运维能力，不追求最高等级 L2 的可审计是优势，L4 的自主是负债也是资产
处理同名多实体技术讨论 锁定本文采用的单一所指并写在显眼位置 同名不同实，开篇先去重
判断 agent 框架的长期价值 看它有没有"能力在时间上累积"的机制 一次性 agent 是消费品，累积型 agent 是资产
识别一个工程项目的学术血脉 核心机制能在三五年前论文找到对应物就行 工程不是发明，是装配
识别 agent 产品真正的竞争轴 看它在回答什么问题，不看功能列表对齐 同赛道看差异，跨赛道看互补
给 agent 项目选 harness 模式 产出不稳选 reviewer，盯盘太累选 supervisor Reviewer 管质量，SRE 管健康
评估 self-improving agent 的代价 回路出错怎么回滚 + 外部能力的运维面 + 生态默认路径 学习回路是复利，也是负债
把抽象架构图落地到工程方案 拆三问：每层是哪个目录/进程/文件、哪些自带哪些自建、跑起来后看哪些指标 答不出的部分就是采用后会卡住的地方

结论：记忆是 scaffolding，scaffolding 有半衰期

Anthropic 在 harness design 博客里有一句话值得反复引用——“every component in a harness encodes an assumption about what the model can’t do on its own, and those assumptions are worth stress testing” [Rajasekaran, 2026]。每一个 harness 组件背后都有一个"模型做不到这件事"的假设，这些假设应该定期被压力测试，因为模型在进化。Opus 4.5 需要 context resets，Opus 4.6 不再需要。为 4.5 搭的脚手架到了 4.6 就应该拆。

本文横评的五级记忆架构，每一级都在编码一组关于模型能力缺口的假设：

  • L0 假设模型不需要记忆——在早期这是对的，现在已经不成立
  • L2 假设模型不能自己管理项目上下文——所以用 CLAUDE.md 人工注入。但 Claude Code 已经开始自动生成 CLAUDE.md 内容，这个假设正在被侵蚀
  • L4 假设模型不能跨会话保持身份和积累经验——所以 Hermes 在外面搭了 memory + skills + user model 的完整脚手架。等到未来某一代模型把这些能力内化，Hermes 当前架构里的很多层都会变成多余

这是 scaffolding 的基本事实：每一层都有半衰期，工程师的工作是一直在拆旧的、搭新的。

但这不意味着今天研究这些记忆架构是在研究必将过时的东西。每一代 scaffolding 过时的同时，它沉淀的设计模式会被下一代继承。Hermes 示范的"从任务经验中蒸馏 skill"这个模式，即使 Hermes 本身被替代，这个模式也会在下一代 agent 里继续存在。OpenClaw 示范的"单一网关覆盖所有消息平台"这个模式同理。Claude Code 的"静态 skill 文件 + 人类所有权"这个模式，甚至可能因为其可审计性而在企业场景里比 L4 活得更久。

把这些方案放回 2026 年的 agent 设计空间来看，最值得关注的不是哪一家"赢了"，而是这个赛道的分化方向：编程智能体走向项目级上下文注入（L2），以可审计性和低运维成本换取企业采用；通用智能体走向网关覆盖（L3），以平台宽度换取用户粘性；长程智能体走向封闭学习回路（L4），以运维复杂度换取时间维度上的能力复利。

三条路线不会收敛成一条。它们在回答不同的问题，服务不同的用户画像，承担不同的运维代价。选择哪条路线，不取决于哪个 agent 的 star 数更多，而取决于一个具体的判断：在当前的模型能力水位下，你愿意把多少记忆的所有权交给 agent 自己？这个问题的答案每半年都会变——因为模型在进化，scaffolding 在老化，而工程师永远在拆旧的、搭新的。

参考资料