Hermes 的多 Agents 是一套边界清晰的三层架构：
第一层是执行内核：AIAgent。无论外部接入多少种形态的终端，最终负责思考和工具调度的，都是这套底层的运行核心。
第二层是临时派生：delegate_task。它像是一个同步的方法调用，专门用来处理当前回合内的短任务和并发请求，即用即毁，不保留长期记忆。
第三层是长效协作：Profile + Kanban。这套机制赋予了 Agent 持久的身份标识和跨节点的任务流转能力，用来支撑复杂的长期协同工程。
要让这套三层架构顺畅运转，必须首先理清：状态究竟存储在何处？上下文如何实现安全隔离？各个节点如何确保输出物可被验收？
一、先看 ~/.hermes/目录结构
Hermes 的全局配置默认存放在 ~/.hermes/ 下，涵盖 config.yaml、.env、auth.json、SOUL.md、memories/、skills/、cron/、sessions/ 和 logs/。
从多 Agent 视角看，它的结构大致如下：
~/.hermes/
├── config.yaml # 模型、终端、压缩、工具等配置
├── .env # API keys、平台 token、secret
├── auth.json # OAuth 凭证
├── SOUL.md # 默认 agent 身份
├── memories/
│ ├── MEMORY.md # agent 自己的长期记忆
│ └── USER.md # 用户画像和偏好
├── skills/ # agent 创建或安装的技能
├── cron/ # 定时任务
├── sessions/ # gateway session 相关文件
├── state.db # SQLite session/message/state 数据库
├── kanban.db # 多 Profile 协作任务板
├── logs/
└── profiles/
└── coder/
├── config.yaml
├── .env
├── SOUL.md
├── memories/
├── skills/
└── state.db
Profile 维护的是状态目录，而非限制性的工作目录。它为 Hermes 提供一套独立的配置、API 密钥、记忆库、技能和网关状态；但实际的工作目录由 terminal.cwd 决定，Profile 本身不干预文件系统访问权限。换言之，coder profile 拥有专属设定，但这并不意味着它只能在 ~/.hermes/profiles/coder/ 目录下活动。
Profile 定义了“这个 agent 的身份”。
二、AIAgent：运行机制的核心枢纽
Hermes 提供多种入口：CLI、Gateway、Cron、ACP、Batch Runner、API Server 和 Python Library。
然而，真正承担执行任务重任的是 run_agent.py 中的 AIAgent。
Hermes的架构中，所有入口最终都会交由 AIAgent(run_agent.py) 处理，随后经过提示词构建、提供商解析、工具分发、会话存储和工具后端等模块。
将这一流程简化为一条链路：
Hermes 的第一个底层逻辑十分清晰：只要系统处于“思考、调用工具、返回结果”的循环中，核心运行的始终是 AIAgent。
所谓多 Agent，本质上是在不同入口、状态和上下文下，启动多个 AIAgent 实例。
三、Prompt：Agent 身份差异的来源
既然底层都是 AIAgent，为何表现出 coder、researcher 或 personal assistant 这样的行为差异？
关键在于提示词的组装机制。
Hermes 的 system prompt 并非静态文本，而是通过多层组装构建而成。它涵盖 SOUL.md 身份描述、工具指引、Honcho 区块、系统消息、内存快照、用户画像快照、技能索引、项目背景文件、时间戳及平台提示。
具体而言：
Agent 行为 = 基础模型能力
+ SOUL.md 身份
+ MEMORY / USER 长期记忆
+ skills 可调用技能
+ 项目上下文文件
+ 当前 session 历史
+ 当前任务 prompt
+ 可用工具集合
这一过程中，有几个容易被忽视的细节：
第一，SOUL.md 定义身份而非规则引擎。它会塑造 agent 的语气、偏好和工作方式，但无法强制实施访问控制。
第二，长期记忆是在 session 启动瞬间注入的一份“冻结快照”。存在 ~/.hermes/memories/ 里的 MEMORY.md 和 USER.md，只会在对话刚开始时被拼进系统提示词。这就意味着，哪怕中途触发了新记忆并写入了磁盘，当前这轮对话的“人设”也不会立刻跟着刷新。
第三，skills 采用按需加载机制。作为独立知识文档存放在 ~/.hermes/skills/ 中，采用渐进式披露策略。这有效避免了为每个子 agent 加载全量技能而引发的上下文膨胀问题。
Agent 的个性分化并非魔术，而是源于不同 Profile 下 SOUL.md、记忆、技能、工作目录及工具权限的具体组合。
准确地说，Agent 并非单纯的模型，而是“模型 + 状态 + 工具 + 记忆 + 工作边界”的复合体。
四、Session：记录历史，而非界定身份
在 Hermes 的设计中，Session 承担着记录会话历史的职能。
具体来说，系统依靠 ~/.hermes/state.db 这个 SQLite 数据库来承载这些数据。里面存放了完整的聊天记录、会话元数据和模型配置，并原生支持 FTS5 全文搜索。为了兼顾性能与可查性，它还开启了 WAL 模式，甚至能直接追踪会话之间的血缘关系。
这解决了核心痛点：Agent 启动时如何获取历史上下文。
如果在命令行（CLI）里启动，它能直接顺着上次的话题往下聊；要是从外部平台接入，Gateway网关就会先通过聊天 ID 认出这是哪场对话，然后单独拉起一个 AIAgent，把历史记录原封不动地喂给它。
Session 只是用来决定“这次运行要带着哪段历史”，它本身并不能算作一个独立的 Agent。
你可以基于同一个 Profile 创建多个 Session，它们共享身份配置与记忆库，但分别维系着不同的对话历史。若配置多个 Profile，每个 Profile 将拥有独立的数据库、记忆及网关状态，这就真正形成了“长期存在的虚拟员工”。
一言以蔽之：Session 构建时间线，Profile 塑造身份。
五、delegate_task：当前回合内的临时任务委派
delegate_task 既不是长期身份，也不提供持续通信渠道。它更像是在当前回合内临时拉起的一组子 AIAgent 实例：父节点下放任务、上下文及工具边界，子节点独立执行后返回总结报告。
这里有三个关键问题：创建机制、并发处理、能力边界。
1. 任务的边界与上下文移交
delegate_task 生成的子代理具备隔离的上下文、受限的工具集及独立的终端会话。每个子代理开启的都是全新的对话，它们在完成任务后仅将最终报告返回给父级上下文。
也就是说，系统并没有把完整的上下文直接复制过去。子 Agent 就像个刚被拉进群的临时工，对主 Agent 之前的操作和提过的要求一无所知，全凭你传过去的 goal（目标）和 context（背景）来办事。
这就带来了一个非常实在的避坑原则：给子 Agent 派活儿时，千万别偷懒跟它说“去查查刚才提到的那个问题”，你必须把背景信息原原本本地重新交代一遍。
例如进行代码审查时，父节点需要传递以下内容：
goal:
Review the authentication module for security issues and fix any found.
context:
Project path: /home/user/webapp
Files:
- src/auth/login.py
- src/auth/jwt.py
- src/auth/middleware.py
Stack:
- Flask
- PyJWT
- bcrypt
Focus:
- SQL injection
- JWT validation
- password handling
- session management
After changes:
Run pytest tests/auth/
Return:
- changed files
- found issues
- verification result
- residual risks
这种详尽的描述是必要的上下文移交过程。多 Agent 模式的效能折损，往往源于父节点误判了子节点的信息掌握程度，导致子节点只能盲猜执行。
2. 并发策略的克制与成本考量
delegate_task 还支持批量派活。你可以直接甩过去一个任务列表，系统会自动用多线程并发拉起多个子 Agent。
不过系统设了上限，默认最多只能同时跑 3 个。要是你一次性塞进去太多任务，它不会偷偷把超载的部分截掉，而是会直接报错。干完活以后，结果会老老实实按你派发的顺序排好返回。
delegation:
model: "google/gemini-flash-2.0"
provider: "openrouter"
max_concurrent_children: 3
max_spawn_depth: 1
orchestrator_enabled: true
这体现了克制的设计理念。系统默认限制了任务层级（max_spawn_depth 为 1），避免无限发散。开启深度嵌套和协调者角色不仅需要显式配置，更会带来指数级上升的成本。
多 Agent 面临的现实约束在于：并发数量与智能程度并不成正比。单 Agent 虽然响应较慢，但能维持高一致性的上下文；多 Agent 在提升处理速度的同时，不可避免地推高了交接、验证和合并的整体成本。
3. 同步执行，非持久队列
容易踩坑的一点是，delegate_task 采用同步执行，且不具备持久化能力。
任务执行被限制在父节点的当前回合内，父节点阻塞等待结果。一旦中断，子任务随即销毁。
适用的场景：
-
并行检索多份资料并汇总 -
同步审查不同模块 -
专注运行自动化测试 -
需要在当前回合内快速产出供父节点决策的依据
不适用的场景：
-
需要长达数小时执行的长期项目 -
涉及人类异步反馈的任务 -
需跨会话反复推进的项目 -
要求任务具备断点续传能力
delegate_task 本质上其实是函数调用。活儿一旦派出去，主节点就只能在原地等着，必须等所有结果都成功交卷了，流程才能接着往下跑。
六、Profile：塑造稳定的角色身份
对于需要长期稳定存在的角色，比如专门的编码助手或资料研究员，Profile 提供了理想的承载框架。
Profile 维护了独立的系统主目录，为角色配置专属的配置文件、环境变量、设定档、记忆库、工具及数据库。这就具备了“AI 员工”的雏形。
只要系统一直跑下去，Profile 带来的身份差异就会越来越大。你想想，一个天天帮你整理日常笔记的助理 Agent，和一个整天泡在特定代码库里的开发 Agent，它们各自攒下来的“上下文”绝对是天差地别的。
正是这种异构的上下文沉淀,构成了多Agent的核心价值。多Agent发挥作用的关键,在 于各个身份承载了差异化的认知背景。
七、Kanban：建立稳固的任务协作机制
Profile 赋予了多 Agent 身份，但真正落实协作依赖于任务状态管理。
Hermes 提供的 Kanban，作为共享的任务看板，解决了跨 Profile 的状态同步问题。在 ~/.hermes/kanban.db 中，每个任务记录了交接凭证与元数据，执行者以完整的操作系统进程存在。
相比于当前回合内同步执行的 delegate_task，Kanban 充当了一个跨角色、跨时间维度的任务状态机。
Agent 通过环境配置激活特定的 kanban_* 工具集，直接操作任务的创建、认领、阻塞与完结。
这套机制直击了协作中的核心难点：任务跟踪、责任归属、执行进度以及异常处理。
八、工具权限收敛与系统可控性
多 Agent 系统的稳定运行，必须辅以严密的权限控制。
Hermes 的工具注册中心集中管理各类调用，处理工具集的分发与可用性校验。模型在发起工具调用时，系统层级会优先拦截敏感请求并过滤不安全指令。
delegate_task 中的子任务受限于严格的权限边界。不仅运行在独立的终端会话中，且默认禁止叶子节点使用关键的系统改写工具。
这种看似繁琐的约束，实则防范了短任务对系统长期记忆的意外篡改，阻断了任务分支的无限发散。通过精细的权限收敛，系统的整体可控性得到了切实保障。
九、面向生命周期的任务拆解
在实操中，千万别为了玩“角色扮演”去硬凑几个表面的虚拟角色。真正务实的做法是：跟着任务的生命周期走，用任务去倒推你需要什么样的 Agent 架构。
1. 单 Agent 优先
对于需要连贯思维推理的任务，如架构权衡或代码整体重构，单 Agent 因免除了上下文交接成本而具备更高的稳定性。无需强制引入复杂的协作架构。
2. delegate_task 的适用场景
其适用场景通常具备明显特征：任务边界清晰、预期输出明确、无需调用长期记忆及异步反馈，且父节点依赖返回结果继续决策。
parent:
我需要撰写 Hermes 机制解析文章。
child A:
提取官方 delegation 资料，总结其生命周期及并发约束。
child B:
查阅 profiles 文档，对比 Profile 与临时工作区的差异。
child C:
研究 Kanban 工作流，梳理交接凭证的具体要求。
子节点无需了解全局逻辑，只需聚焦产出结构化的证据材料。
3. Profile 的长期价值
对于需长期沉淀特定领域经验的角色，Profile 发挥着无可替代的作用。通过日常任务的持续输入，角色设定会愈发成熟稳定。
4. 基于 Kanban 的长效协作
遇到跨越多个阶段和不同角色的复杂工程任务，Kanban 是首选。
researcher:
调研现有实现和外部文档，完成研究阶段任务。
architect:
基于移交材料拟定设计方案，并创建开发任务。
coder:
实现编码细节，提交变更清单与测试反馈。
reviewer:
复查实现结果，补充残余风险说明，必要时驳回重构。
多 Agent 体系的真实组织能力，并不体现在角色的命名上，而是深深植根于这套严谨的任务状态流转机制之中。
写在最后
总体而言，Hermes 的架构机制可概括为以下层次：
简而言之：Hermes 依赖 delegate_task 解决临时并行任务的效率问题，依靠 Profile 和 Kanban 筑牢长期协作的根基。短效任务凭借返回值完成决策闭环，而长线协作必须借助状态机加以管理。
缺乏清晰边界与有效验证手段的多 Agent 系统，反而会陷入更深层次的失控。
文章评论