Hermes + Ralph Loop 架构新视线：单一 Agent 循环的深度实践与超大复杂任务承接方案

上一篇文章讲到，我在hermes上成功复刻了b站费曼学徒冬瓜的“ralph+多智能体协作”。其实短短两天，我已经对hermes做了超多的改动，对于hermes有了更深入的理解，于是对我的hermes进行了大刀阔斧的改动。

个人观点，也是最重要的发现，总结如下：

一、hermes的单一agent设计对个人开发者适配程度非常高 hermes和其它工业级agent或ai编程软件不同，调教得比openclaw更友好，比claude code更开放，至于具体不同之处在哪里，这是你要自行了解的，但你不了解的话，你可能不太能理解我接下来的观点。

二、hermes的agent架构设计（易踩坑） 我相信百分之八十的人并不了解这一点。hermes的agent系统实际上是单一agent循环，不存在严格的多agent，那样等同于在一台主机上装两个hermes。也不要创建多个agent的文件夹出来，不要像使用openclaw那样创建很多包含了一大堆agent成套文档的agent专属文件夹出来，这不是使用hermes的正确方法。 直接说结论，hermes的多agent实际是复制hermes-agent（默认agent）出来作为subagent执行任务，但它的知识库、skill、plugin等等内容，实际上就是hermes-agent。结论：别创建新的agentl了，管好你的默认agent，把知识库都填充到它身上就好了。

三、使用hermes-agent的新范式！！！ 基于以上两点，加入了ralph loop主动循环系统之后，我的hermes可以使用很多的/ralph指令（这里我只是想解释，对hermes做了源码级的改动而不触及源码，即未来的hermes update没有影响，这是我做改动的原则，不能影响未来的更新），那么ralph loop是一个独立于hermes之外的一个循环体，而hermes完全有能力调动它。 于是我的ralph loop经常分解超大复杂任务，调用了多个tmux唤起了hermes，每个hermes都是独立的进程，实施复杂任务的其中一个子任务，在这过程中，每个hermes-agent又可以分解为3个subagent。 也就是说，我的hermes --tui接到超大复杂任务后复制三个subagent进行分解并最终调用了ralph loop，ralph loop（有可能是主agent调用也有可能是子agent调用，因为ralph loop独立于hermes，不受相关迭代限制）调用了tmux多个hermes进程. 假设3个吧，那么三个hermes能够调用9个subagent，这里我要说明的不是它能调动多少个agent。 而是这个框架对于超大复杂任务的承接能力，理论上，只限制于你的硬件和token额度！！！

###有几点要郑重声明： 1、我的ralph loop有队列任务机制，分为手动队列任务机制和动态队列任务机制。手动队列任务机制自动化接受复杂度、跨度都不大的任务，动态队列任务机制就是承接了超大复杂任务的队列机制，也就是说，如果你的任务足够复杂，理论上它根据智能编排的结果甚至能划分出几千到几万个子任务！ 2、我的ralph loop允许队列任务动态调整机制，有一些任务适合长时间自治运行。怎么说呢，如果我没有给它限定时间、迭代次数、界定任务停止条件，那么它就会不断的从你给出的复杂任务文档里提取主题和任务以执行，永远不会停止。比如我给它的知识库填充任务，每完成一批之前，它就已经自动编排好了另外一批的任务等着执行，于是阻碍它的就是token额度了，毕竟这个任务的复杂程度也不会用到太多硬件资源 3、将超大复杂任务划分为几百几千个子任务后，会将hermes原本的承接能力提高几个量级，具体原因？很简单，因为hermes面对的问题变得简单了，连让人摸不着头脑的minimax2.7都开始干正事了，它终于找到自己能干好的事了。 4、任务交付质量，我已有内置于ralph loop的feynman engine（四角色评审，一票否决权）进行交付质量把关，使用至今，任务交付质量非常好，就是会心疼token。

四、关于hermes-agent的personality 这也是我今天才决定进行的重大改动，甚至还在改的时候就在写这篇文章。基于官方自己搭建的这个单一agent循环架构，我将一切hermes默认的personality都砍掉了，只留下一个personality，具体这个personality和默认的agent.md、soul.md应该怎么写呢？这似乎是个很困难的问题。其实你应该参考claude code的管理方式，推荐小红书博主ian的文章“三省六部制幻觉”，很好的解释了这一点。即，为什么不要让agent来担任角色扮演？结论是会导致agent停滞不前，将输出结果捆绑到自己的身份上，最终限制agent进化。

五、以上内容的每个点，甚至每个点下面的一段话，我都是通过大语言模型经过深入分析迭代论证的总结内容，以下是今天正在执行的任务图示内容。

前言

在 AI Agent 领域，"多智能体协作"几乎是公认的下一代方向。B 站费曼学徒冬瓜提出的 "Ralph + 多智能体协作" 方案让我在 Hermes 上成功复现了这一范式。但在短短两天的深度使用后，我发现 Hermes 的架构远比表面看起来更加精妙——它的单一 Agent 循环设计，对个人开发者而言，适配程度反而比 OpenClaw、Claude Code 等工业级方案更高。

本文将从架构原理出发，深入解析 Hermes 的真实设计逻辑，以及如何通过 Ralph Loop 主动循环系统，将超大复杂任务的承接能力提升几个数量级。

前置要求：

• Hermes v0.10.0+
• Python 3.11+
• 对 Agent 系统有基本了解

技术背景

Hermes 的架构哲学

Hermes 采用了与业界常见方案截然不同的单一 Agent 循环架构。主流工业级 Agent 工具（如 OpenClaw）通常采用多 Agent 分层设计，每个 Agent 拥有独立知识库、Skill 和 Plugin，通过消息传递协作。Claude Code 则采用工具链扩展模式，将 Agent 能力通过插件系统垂直扩展。

Hermes 的设计哲学是"单一循环 + 按需复制" ：

维度	OpenClaw	Claude Code	Hermes
Agent 架构	多 Agent 分层	单 Agent + 工具链	单一 Agent 循环
知识库	多个独立知识库	共享知识库	共享知识库
多 Agent 实现	原生多 Agent	不支持	复制 + 共享
个人开发者友好度	低	中	高

相关技术栈

• Hermes：主 Agent 运行时
• Ralph Loop：独立于 Hermes 的主动循环系统
• tmux：终端多会话管理，用于启动多个 Hermes 进程
• Feynman Engine：四角色评审机制，负责交付质量把关

核心方案

第一步：理解 Hermes 的单一 Agent 循环本质

目标：理解 Hermes 为什么不支持"真正的"多 Agent，以及如何正确使用其 Subagent 机制

Hermes 的 Agent 系统实际上是单一 Agent 循环。当我们谈论"多 Agent"时，Hermes 的实现方式是复制 hermes-agent（默认 Agent）作为 Subagent 执行任务。但关键在于：所有 Subagent 的知识库、Skill、Plugin，本质上都是 hermes-agent 的内容。

这意味着：

# 错误认知：创建多个独立的 Agent 文件夹
hermes/
├── agents/
│   ├── agent_a/  # ❌ 误区：像 OpenClaw 那样创建独立 Agent
│   ├── agent_b/  # ❌ 误区：每个 Agent 有自己的一套知识库
│   └── agent_c/  # ❌ 误区：这种模式在 Hermes 中不存在

# 正确认知：所有 Agent 共享同一个 hermes-agent
hermes/
├── hermes-agent/  # ✅ 只有一个真正的 Agent
│   ├── knowledge_base/
│   ├── skills/
│   └── plugins/
└── ralph-loop/    # 独立于 Hermes 的任务队列系统

为什么不要创建新的 Agent 文件夹？

1. 资源浪费：每个 Hermes 进程都是独立的内存空间，创建多个 Agent 等同于在一台主机上装两个 Hermes
2. 知识库割裂：Subagent 无法访问其他 Agent 的知识库，导致信息孤岛
3. 维护成本高：多个 Agent 配置文件需要分别维护，版本同步困难

正确做法：将所有知识库、Skill、Plugin 都填充到默认的 hermes-agent 中。Subagent 只是临时复制，执行完任务后自动销毁，不保留状态。

第二步：引入 Ralph Loop 主动循环系统

目标：通过 Ralph Loop 实现超大复杂任务的智能分解与动态调度

Ralph Loop 是独立于 Hermes 的主动循环系统，通过 tmux 启动多个独立的 Hermes 进程来并行执行子任务。这种架构的优势在于：

1. 进程隔离：每个 Hermes 进程独立运行，互不干扰
2. 动态扩展：根据任务复杂度，自动启动/停止 Hermes 进程
3. 队列机制：支持手动队列任务和动态队列任务两种模式

# Ralph Loop 的核心调度逻辑（伪代码）
class RalphLoop:
    def __init__(self, hermes_path="/usr/local/bin/hermes"):
        self.hermes_path = hermes_path
        self.queue = TaskQueue()
        self.tmux_sessions = {}

    def dispatch_task(self, task):
        """将任务分发到 tmux 启动的 Hermes 进程"""
        session_name = f"hermes_{uuid.uuid4().hex[:8]}"
        # 启动独立的 Hermes 进程
        subprocess.Popen(
            ["tmux", "new-session", "-d", "-s", session_name,
             f"{self.hermes_path} --tui"],
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE
        )
        self.tmux_sessions[session_name] = self._create_subagent(task)

    def _create_subagent(self, task):
        """创建 Subagent，每个可分解为 3 个子 Subagent"""
        return Subagent(
            knowledge_base=hermes_agent.knowledge_base,
            skills=hermes_agent.skills,
            max_children=3  # 每个 Subagent 最多 3 个子 Subagent
        )

任务分解示意：

超大复杂任务
    │
    ├── Hermes 进程 1（tmux session_1）
    │       ├── Subagent 1.1
    │       ├── Subagent 1.2
    │       └── Subagent 1.3
    │
    ├── Hermes 进程 2（tmux session_2）
    │       ├── Subagent 2.1
    │       ├── Subagent 2.2
    │       └── Subagent 2.3
    │
    └── Hermes 进程 3（tmux session_3）
            ├── Subagent 3.1
            ├── Subagent 3.2
            └── Subagent 3.3

假设启动 3 个 Hermes 进程，每个最多 3 个 Subagent，理论最大并行任务数为 3 × 3 = 9。但实际上，任务分解的瓶颈从来不是 Agent 数量，而是硬件和 Token 额度。

第三步：队列任务机制与动态调整

目标：理解手动队列与动态队列的适用场景

Ralph Loop 实现了两种队列任务机制：

手动队列任务机制

适用于复杂度、跨度都不大的任务。任务直接进入队列，顺序执行，无需复杂的分解逻辑。

# queue.yaml
manual_queue:
  - task: "简单的代码审查"
    priority: 1
  - task: "文档格式修复"
    priority: 2
  - task: "配置文件更新"
    priority: 3

动态队列任务机制

适用于超大复杂任务。当任务足够复杂时，Ralph Loop 会根据智能编排结果，自动将任务分解为几百到几万个子任务。

# 动态队列的核心逻辑
def dynamic_queue_decompose(task, max_subtasks=10000):
    """
    动态队列分解：任务复杂度越高，分解的子任务越多
    理论上可达几千到几万个子任务
    """
    complexity = assess_complexity(task)
    subtasks = []

    # 递归分解，直到达到复杂度阈值
    while complexity > THRESHOLD and len(subtasks) < max_subtasks:
        subtask = decompose_one(task)
        subtasks.append(subtask)
        complexity = assess_complexity(task)

    return subtasks

动态调整机制

有些任务适合长时间自治运行。如果没有限定时间、迭代次数或任务停止条件，Ralph Loop 会不断从复杂任务文档中提取主题和任务来执行，永远不会停止。

# 自治运行示例
def autonomous_mode(task_doc, max_iterations=None, time_limit=None):
    """
    自治模式：持续从任务文档中提取并执行任务
    唯一限制是 token 额度和硬件资源
    """
    iteration = 0
    while True:
        if max_iterations and iteration >= max_iterations:
            break
        if time_limit and elapsed_time() > time_limit:
            break

        next_task = extract_next_task(task_doc)
        if not next_task:
            break  # 文档中再无新任务

        execute_task(next_task)
        iteration += 1

第四步：Feynman Engine 质量把关

目标：通过四角色评审机制确保交付质量

任务交付质量是超大复杂任务分解方案的核心问题。Ralph Loop 内置了 Feynman Engine，通过四角色评审机制（一票否决权）来把关交付质量。

class FeynmanEngine:
    """
    费曼评审引擎：四角色评审 + 一票否决权
    """

    ROLES = ["技术专家", "产品经理", "安全审计", "代码reviewer"]

    def review(self, deliverable):
        """四角色独立评审"""
        results = {}
        for role in self.ROLES:
            result = self._role_review(role, deliverable)
            results[role] = result
            if result.has_issues:
                # 一票否决：任何角色发现问题，直接打回
                return ReviewResult(rejected=True, issues=result.issues)
        return ReviewResult(rejected=False, approved=True)

    def _role_review(self, role, deliverable):
        """各角色独立评审"""
        # 技术专家：验证技术可行性
        # 产品经理：验证需求匹配度
        # 安全审计：验证安全性
        # 代码reviewer：验证代码质量
        pass

踩坑记录

坑 1：创建多个独立 Agent 文件夹

现象：按照 OpenClaw 的使用习惯，创建了多个 Agent 文件夹，每个文件夹包含独立知识库和 Skill。

原因：对 Hermes 架构的误解。Hermes 的 Subagent 机制是"复制"而非"独立"。

解决：

# 删除多余的 Agent 文件夹
rm -rf /path/to/extra/agents/

# 只保留默认的 hermes-agent
# 将所有知识库内容填充到 hermes-agent 中

经验总结：在 Hermes 中，管好你的默认 Agent，把知识库都填充到它身上就好了。

坑 2：Hermes Subagent 的知识库误解

现象：以为 Subagent 可以访问自己独有的知识库。

原因：对 Hermes 复制机制的理解不足。Subagent 复制的是 hermes-agent 的知识库指针，而非独立副本。

解决：确保所有 Subagent 需要的知识都在 hermes-agent 的知识库中。

经验总结：Hermes 的多 Agent 实际是"复制 hermes-agent 作为 Subagent"，但知识库、Skill、Plugin 实际上是共享的。

坑 3：minimax2.7 模型在复杂任务上的表现

现象：模型在复杂任务上容易"摸不着头脑"，输出质量不稳定。

原因：模型对复杂问题的推理能力有限。

解决：通过任务分解，将复杂问题拆解为简单子任务。hermes 面对的问题变得简单了，minimax2.7 也开始干正事了。

经验总结：任务分解是提升 AI 编程质量的关键。分解粒度越细，模型表现越好。

总结与展望

本文方案优势

1. 架构简洁：单一 Agent 循环 + 按需复制，降低系统复杂度
2. 扩展性强：理论上只受硬件和 Token 额度限制
3. 质量可控：Feynman Engine 四角色评审确保交付质量
4. 个人开发者友好：不需要管理复杂的知识库分片

局限性

1. Subagent 知识库共享：无法实现真正的知识隔离
2. 进程间协调：依赖 tmux 管理多进程，协调成本较高
3. Token 成本：超大复杂任务分解后，Token 消耗量巨大

未来优化方向

1. 探索进程间通信优化：减少 tmux 进程间的协调开销
2. 引入 Token 预算控制：在质量和成本之间找到平衡点
3. 完善 Feynman Engine：引入更多评审角色，提升评审覆盖率

---

标签

#AI #大模型 #Agent #架构设计 #Python #Hermes #多智能体 #任务分解

---

关于 Hermes-Agent 的 Personality

最后，关于 Hermes-Agent 的 Personality 设计，我今天进行了重大改动：将所有默认 Personality 都砍掉，只保留一个。

具体这个 Personality 和默认的 agent.md、soul.md 应该怎么写，其实是个困难的问题。我推荐参考 Claude Code 的管理方式，以及小红书博主 Ian 的文章"三省六部制幻觉"。核心观点是：不要让 Agent 来担任角色扮演，这会导致 Agent 停滞不前，将输出结果捆绑到自己的身份上，最终限制 Agent 进化。

这与 Hermes 的单一 Agent 循环架构一脉相承——越简单的架构，越容易进化。