# 如何在 Hermes 中构建多智能体团队
**作者**: Neo
**日期**: 2026-04-12T22:26:52.000Z
**来源**: [https://x.com/NeoAIForecast/status/2043455838459920718](https://x.com/NeoAIForecast/status/2043455838459920718)
---
Most people use one AI assistant and then try to force it to become a researcher, writer, coder, project manager, and operator all at once.
That usually works for a while.
Then the personalities blur together. The context gets messy. The memory becomes noisy. The workflows stop feeling deliberate. Hermes gives you a better path: build a team instead of overloading a single generalist.
Hermes profiles are one of the most underrated features in the whole system.
They are not just cosmetic personas. They are isolated agent environments that can separate memory, sessions, skills, personality, configuration, cron state, and gateway behavior.
That means you are not merely renaming one assistant four times. You are creating role-based agents with cleaner boundaries and more durable specialization.
Takeaway: the leap from one agent to a real multi-agent team starts with isolation, not with better prompting.
## The right mental model
The wrong mental model is: “I need one genius AI that does everything.”
The better mental model is: “I need a small team with distinct roles, clear handoffs, and less context pollution.”
That is exactly what Hermes profiles make possible.
One profile can think like a strategist. Another can stay research-first. Another can optimize for communication. Another can live in implementation and debugging mode.
Because their memory, sessions, and identity stay separate, each one can become more coherent over time instead of turning into a confused blend.
Takeaway: Hermes profiles are best understood as role boundaries for AI work, not as novelty character skins.
## What profiles actually separate
This is where Hermes becomes more serious than a normal assistant setup.
A profile can isolate:
- configuration
- sessions
- memory
- skills
- personality
- cron state
- gateway state
That matters because multi-agent systems fail when everything shares the same memory and tone.
You do not want your coding agent inheriting the same defaults, priorities, and stylistic habits as your research or writing agent. You want clean lines between them.
Takeaway: specialization only becomes durable when state stays separated.
## The simplest team structure
If you want a practical starting point, I have setup the below. begin with four roles:
Hermes > orchestrator
Alan > research specialist
Mira > narrative architect
Turing > debugger and systems engineer
This is a strong pattern because it mirrors real work.
The orchestrator handles planning, decomposition, sequencing, and final synthesis.
The research agent gathers sources, validates claims, and turns raw information into decision-ready findings.
The writer turns validated material into clear, structured communication.
The engineer turns plans into working systems, tests, fixes, and reliable output.
Takeaway: most useful AI teams map to real functional roles, not arbitrary personalities.
## Role 1: The orchestrator
Your orchestrator profile is the command center.
Its job is not to do every task personally. Its job is to define the goal, split the work, route tasks to the right specialists, and synthesize the final result.
This profile should optimize for:
- planning
- prioritization
- dependency management
- quality control
- synthesis
It should think in workstreams, not just answers.
Takeaway: the orchestrator is the traffic controller of the system, not the bottleneck.
## Role 2: The research specialist
A research profile should feel skeptical, source-first, and structured.
Its purpose is to gather evidence, compare sources, flag uncertainty, and separate what is verified from what is merely plausible.
This is the profile you want for:
- literature review
- market research
- product comparisons
- source verification
- trend tracking
The point is not just “good research.” The point is protecting the rest of the team from bad assumptions.
Takeaway: a good research agent reduces hallucinated confidence across the whole system.
## Role 3: The writer
A writing profile should optimize for clarity, structure, readability, and audience awareness.
This is where you turn raw findings into:
- articles
- briefings
- product copy
- threads
- scripts
- explainers
The writer should not need to hold the entire research process or implementation context in its head all the time. It should receive cleaner inputs and focus on communication quality.
Takeaway: writing gets better when the agent is not also trying to be the researcher and debugger at the same time.
## Role 4: The builder/debugger
Your engineering profile should be direct, evidence-driven, and implementation-focused.
This is the profile for:
- building features
- debugging failures
- reviewing code
- validating fixes
- running tests
- operational problem-solving
This profile should care about reproducibility, logs, diffs, and verified outcomes more than broad narrative polish.
Takeaway: implementation quality improves when one profile is allowed to stay deeply technical.
## Use SOUL.md to make each role real
One of the easiest mistakes in multi-agent setups is changing only the name.
If every profile has the same underlying voice, priorities, and operating style, you do not have a real team. You have clones with labels.
Hermes gives you a stronger foundation through SOUL.md, which defines who the agent is and how it behaves. That is where you shape each profile’s default identity.
For example:
- the orchestrator should sound structured and decisive
- the researcher should sound evidence-first and skeptical
- the writer should sound clear and audience-aware
- the engineer should sound precise and test-oriented
Then use AGENTS.md for project-specific context rather than identity.
Takeaway: SOUL.md creates distinct agents; AGENTS.md gives them shared mission context.
The actual setup, step by step
This is the practical part: how to go from one working Hermes setup to a real multi-agent team with isolated roles.
In this example, the team is:
Hermes > orchestrator
Alan > research specialist
Mira > writer
Turing > debugger and systems engineer
The goal is not just to create four names. The goal is to create four separate Hermes profiles with their own identity and state.
Takeaway: a real multi-agent setup in Hermes starts with profiles, not prompts.
## Step 1: Start from a working Hermes setup
Before creating specialist agents, make sure your main Hermes setup already works.
That means:
- your model/provider is configured
- your API keys or auth are already working
- your normal Hermes environment is usable
This matters because the easiest way to build a team is to clone from a working setup.
Takeaway: start from a working base so you do not have to configure every agent from scratch.
## Step 2: Create the specialist profiles
Create each new profile by cloning the current working one.
Commands:
hermes profile create alan --clone
hermes profile create mira --clone
hermes profile create turing --clone
If you want to inspect the available options first, run:
hermes profile create --help
Using --clone copies the useful base setup, such as:
- config.yaml
- .env
- SOUL.md
But each new profile still gets its own isolated memory and session history.
Takeaway: use --clone when you want specialized agents that inherit your working setup without sharing the same internal state.
## Step 3: Verify that the profiles exist
After creating the profiles, confirm they were actually made.
Command:
hermes profile list
You should now see your new profiles listed.
On disk, they should live under:
/home/neo/.hermes/profiles/alan/
/home/neo/.hermes/profiles/mira/
/home/neo/.hermes/profiles/turing/
Your main Hermes profile can remain the orchestrator, while the others act as specialists.
Takeaway: always verify the profiles in the CLI and on disk before moving on.
## Step 4: Give each profile a real identity with SOUL.md
This is the step that turns profiles into actual agents. Each specialist profile should have its own SOUL.md file:
/home/neo/.hermes/profiles/alan/SOUL.md
/home/neo/.hermes/profiles/mira/SOUL.md
/home/neo/.hermes/profiles/turing/SOUL.md
Use SOUL.md to define durable identity:
- tone
- default behavior
- strengths
- priorities
- what the agent should avoid
A strong split looks like this:
- Hermes: planning, delegation, synthesis, final QA
- Alan: evidence, verification, research depth, uncertainty handling
- Mira: clarity, structure, audience awareness, polished communication
- Turing: implementation, debugging, tests, reproducibility, technical precision
This is the key distinction:
- SOUL.md defines who the agent is
- AGENTS.md defines shared project context
Takeaway: if you only change the profile name and not the SOUL.md, you do not really have a team.
## Step 5: Keep shared context separate from identity
Once each profile has a distinct identity, keep shared operating context in project-level files such as AGENTS.md.
Use that for things like:
- repository structure
- coding conventions
- workflow rules
- tool usage expectations
- project-specific instructions
Do not overload SOUL.md with temporary project details.
That separation keeps the system clean over time:
- identity stays in SOUL.md
- project context stays in AGENTS.md
- Takeaway: stable teams need stable identities and shared context, not one giant mixed instruction blob.
## Step 6: Add a shared team reference file
It helps to maintain one shared reference file that documents the roster and how the agents work together.
For example:
/home/neo/.hermes/team-agents.md
This file can describe:
- each agent’s role
- handoff rules
- when to use which profile
- what good output looks like from each one
That gives you one place to explain the system to yourself or anyone else using it later.
Takeaway: a team reference file makes the multi-agent setup easier to run consistently.
## Step 7: Run each profile directly
Once the profiles exist, you can invoke them individually.
Typical pattern:
hermes -p alan
hermes -p mira
hermes -p turing
The important thing is that each one runs as its own profile with isolated state.
This means:
- Alan does not inherit Mira’s writing sessions
- Turing does not inherit Alan’s research memory
- each agent gets cleaner long-term specialization
Takeaway: the benefit comes from actually using the profiles separately, not just creating them once.
## Pair profiles with messaging
Profiles get even more powerful when you combine them with the Hermes gateway. Now your team is not locked inside one local terminal session.
You can run different profiles as different messaging identities, supervise them remotely, route work through Telegram, and keep role boundaries intact across chats and tasks.
This is where Hermes starts to feel less like a single assistant and more like an operational system.
Takeaway: messaging turns profiles from a local organization feature into a live multi-agent control surface.
## Conclusion
If you want Hermes to feel more powerful, stop trying to make one agent do everything.
Build a team.
Start with an orchestrator, add one specialist, prove the handoff, and only then expand. That is where Hermes profiles stop feeling like a feature and start feeling like infrastructure.
Takeaway: the smartest multi-agent team is not the biggest one. It is the one with the clearest role boundaries.
## 相关链接
- [Teknium (e/λ) 转载](https://x.com/Teknium)
- [Neo](https://x.com/NeoAIForecast)
- [@NeoAIForecast](https://x.com/NeoAIForecast)
- [14K](https://x.com/NeoAIForecast/status/2043455838459920718/analytics)
- [升级至高级版](https://x.com/i/premium_sign_up)
- [6:26 AM · Apr 13, 2026](https://x.com/NeoAIForecast/status/2043455838459920718)
- [14.6K Views](https://x.com/NeoAIForecast/status/2043455838459920718/analytics)
---
*导出时间: 2026/4/13 11:29:50*
---
## 中文翻译
# 如何在 Hermes 中构建多智能体团队
**作者**: Neo
**日期**: 2026-04-12T22:26:52.000Z
**来源**: [https://x.com/NeoAIForecast/status/2043455838459920718](https://x.com/NeoAIForecast/status/2043455838459920718)
---
大多数人只使用一个 AI 助手，然后试图强行让它同时成为研究员、写作者、程序员、项目经理和执行者。
这通常能奏效一段时间。
然后各个角色的个性开始混淆。上下文变得混乱。记忆变得嘈杂。工作流不再显得有条不紊。Hermes 为你提供了一条更好的路径：与其让一个全能型助手不堪重负，不如组建一个团队。
Hermes 配置文件是整个系统中最被低估的功能之一。
它们不只是装饰性的角色设定。它们是相互隔离的智能体环境，可以分离记忆、会话、技能、个性、配置、定时任务状态和网关行为。
这意味着你不只是把同一个助手重命名了四次。你是在创建基于角色的智能体，它们拥有更清晰的边界和更持久的专精。
要点：从单个智能体到真正的多智能体团队的跨越，始于隔离，而非更好的提示词。
## 正确的心智模型
错误的心智模型是：“我需要一个无所不能的天才 AI。”
更好的心智模型是：“我需要一个分工明确、交接清晰、上下文污染更少的小团队。”
这正是 Hermes 配置文件所能实现的。
一个配置文件可以像战略家一样思考。另一个可以坚持研究优先。另一个可以为沟通进行优化。另一个可以专注于实现和调试模式。
因为它们的记忆、会话和身份保持分离，每一个都能随时间推移变得更加连贯，而不是变成一个混乱的混合体。
要点：Hermes 配置文件最好被理解为 AI 工作的角色边界，而不是新奇的角色皮肤。
## 配置文件实际上隔离了什么
这正是 Hermes 比普通助手配置更为严肃的地方。
一个配置文件可以隔离：
- 配置
- 会话
- 记忆
- 技能
- 个性
- 定时任务状态
- 网关状态
这一点很重要，因为当所有东西共享相同的记忆和语气时，多智能体系统就会失败。
你不希望你的编程智能体继承与你的研究或写作智能体相同的默认设置、优先事项和风格习惯。你希望它们之间有清晰的界线。
要点：只有当状态保持分离时，专精化才能持久。
## 最简单的团队结构
如果你想要一个实用的起点，我设置了以下结构。从四个角色开始：
Hermes > 协调者
Alan > 研究专家
Mira > 叙事架构师
Turing > 调试员和系统工程师
这是一个强有力的模式，因为它映射了真实的工作。
协调者负责规划、任务分解、排序和最终综合。
研究智能体收集来源、验证论断，并将原始信息转化为可供决策的发现。
写作者将经过验证的材料转化为清晰、结构化的沟通内容。
工程师将计划转化为可运行的系统，进行测试、修复并输出可靠的结果。
要点：最有用的 AI 团队映射的是真实的功能角色，而不是随意设定的个性。
## 角色 1：协调者
你的协调者配置文件是指挥中心。
它的职责不是亲自完成每项任务。它的职责是定义目标、拆分工作、将任务路由给合适的专家，并综合最终结果。
这个配置文件应针对以下方面进行优化：
- 规划
- 优先级排序
- 依赖管理
- 质量控制
- 综合
它应该以工作流的方式思考，而不仅仅是给出答案。
要点：协调者是系统的交通管制员，而不是瓶颈。
## 角色 2：研究专家
研究配置文件应该显得充满怀疑、来源优先且条理清晰。
它的目的是收集证据、比较来源、标记不确定性，并区分已验证的内容和仅仅看似合理的内容。
这是你想要用于以下场景的配置文件：
- 文献综述
- 市场研究
- 产品对比
- 来源验证
- 趋势追踪
重点不只是“好的研究”。重点是保护团队其他成员免受错误假设的影响。
要点：一个好的研究智能体能减少整个系统中因幻觉而产生的过度自信。
## 角色 3：写作者
写作配置文件应该针对清晰度、结构、可读性和受众意识进行优化。
这是你将原始发现转化为以下内容的地方：
- 文章
- 简报
- 产品文案
- 推文串
- 脚本
- 科普解读
写作者不应该始终需要在脑中保留整个研究过程或实现上下文。它应该接收更干净的输入，并专注于沟通质量。
要点：当智能体不再同时试图充当研究员和调试员时，写作质量会更好。
## 角色 4：构建者/调试员
你的工程配置文件应该是直接的、以证据为驱动、专注于实现的。
这是用于以下场景的配置文件：
- 构建功能
- 调试故障
- 审查代码
- 验证修复
- 运行测试
- 解决运营问题
这个配置文件应该更关心可复现性、日志、差异对比和已验证的结果，而不是宽泛的叙事润色。
要点：当允许一个配置文件保持深度技术化时，实现质量就会提高。
## 使用 SOUL.md 让每个角色真正立起来
多智能体设置中最容易犯的错误之一就是只改名字。
如果每个配置文件都有相同的底层语气、优先事项和运作风格，你拥有的就不是真正的团队。你拥有的是贴了标签的克隆体。
Hermes 通过 SOUL.md 为你提供了更强大的基础，它定义了智能体是谁以及它的行为方式。这就是你塑造每个配置文件默认身份的地方。
例如：
- 协调者应该听起来有条理且果断
- 研究员应该听起来证据优先且充满怀疑
- 写作者应该听起来清晰且顾及受众
- 工程师应该听起来精确且以测试为导向
然后使用 AGENTS.md 来承载项目特定的上下文，而不是身份。
要点：SOUL.md 创建独立的智能体；AGENTS.md 赋予它们共享的任务上下文。
实际搭建过程，一步一步来
这是实操部分：如何从一个可用的 Hermes 配置过渡到拥有隔离角色的真正多智能体团队。
在本例中，团队是：
Hermes > 编排者
Alan > 研究专家
Mira > 撰写者
Turing > 调试与系统工程师
目标不只是创建四个名字。目标是创建四个独立的 Hermes 配置文件，每个都有自己的身份和状态。
要点：Hermes 中真正的多智能体配置从配置文件开始，而不是提示词。
## 第 1 步：从一个可用的 Hermes 配置开始
在创建专家智能体之前，先确保你的主 Hermes 配置已经可以正常工作。
这意味着：
- 你的模型/提供商已配置好
- 你的 API 密钥或认证已正常工作
- 你的常规 Hermes 环境可以使用
这很重要，因为搭建团队最简单的方法就是从一个可用的配置开始克隆。
要点：从一个可用的基础开始，这样你就无需从头配置每个智能体。
## 第 2 步：创建专家配置文件
通过克隆当前可用的配置来创建每个新配置文件。
命令：
hermes profile create alan --clone
hermes profile create mira --clone
hermes profile create turing --clone
如果你想先查看可用选项，运行：
hermes profile create --help
使用 --clone 会复制有用的基础配置，例如：
- config.yaml
- .env
- SOUL.md
但每个新配置文件仍然拥有自己隔离的记忆和会话历史。
要点：当你希望专家智能体继承你的可用配置而不共享相同的内部状态时，使用 --clone。
## 第 3 步：验证配置文件是否存在
创建配置文件后，确认它们确实已生成。
命令：
hermes profile list
你现在应该能在列表中看到你的新配置文件。
在磁盘上，它们应该位于：
/home/neo/.hermes/profiles/alan/
/home/neo/.hermes/profiles/mira/
/home/neo/.hermes/profiles/turing/
你的主 Hermes 配置文件可以保持为编排者，其他配置文件则作为专家。
要点：在继续之前，务必在 CLI 和磁盘上验证配置文件。
## 第 4 步：用 SOUL.md 给每个配置文件一个真正的身份
这一步将配置文件转变为真正的智能体。每个专家配置文件都应该有自己的 SOUL.md 文件：
/home/neo/.hermes/profiles/alan/SOUL.md
/home/neo/.hermes/profiles/mira/SOUL.md
/home/neo/.hermes/profiles/turing/SOUL.md
使用 SOUL.md 来定义持久的身份：
- 语气
- 默认行为
- 优势
- 优先级
- 智能体应避免的事项
一个清晰的分工示例如下：
- Hermes：规划、委派、综合、最终质量把关
- Alan：证据、验证、研究深度、不确定性处理
- Mira：清晰度、结构、受众意识、精炼的沟通
- Turing：实现、调试、测试、可复现性、技术精确性
这是关键区别：
- SOUL.md 定义智能体是谁
- AGENTS.md 定义共享的项目上下文
要点：如果你只改了配置文件的名称而没有改 SOUL.md，你其实并没有一个团队。
## 第 5 步：将共享上下文与身份分开
一旦每个配置文件都有了独立的身份，就把共享的操作上下文放在项目级文件（如 AGENTS.md）中。
用它来存放诸如：
- 仓库结构
- 编码规范
- 工作流规则
- 工具使用预期
- 项目特定指令
不要用临时的项目细节把 SOUL.md 塞满。
这种分离能让系统长期保持整洁：
- 身份留在 SOUL.md 中
- 项目上下文留在 AGENTS.md 中
- 要点：稳定的团队需要稳定的身份和共享的上下文，而不是一个巨大的混杂指令堆。
## 第 6 步：添加一个共享的团队参考文件
维护一个共享的参考文件来记录团队名单以及智能体之间如何协作，会很有帮助。
例如：
/home/neo/.hermes/team-agents.md
这个文件可以描述：
- 每个智能体的角色
- 交接规则
- 何时使用哪个配置文件
- 每个智能体什么样的输出才算好
这为你提供了一个地方，可以向自己或以后使用该系统的任何人解释整个系统。
要点：团队参考文件让多智能体配置更容易保持一致地运行。
## 第 7 步：直接运行每个配置文件
配置文件创建好后，你可以单独调用它们。
典型模式：
hermes -p alan
hermes -p mira
hermes -p turing
重要的是，每个都以自己的配置文件运行，状态相互隔离。
这意味着：
- Alan 不会继承 Mira 的写作会话
- Turing 不会继承 Alan 的研究记忆
- 每个智能体在长期内获得更纯粹的专业化
要点：好处来自真正分开使用这些配置文件，而不是只创建一次。
## 将配置文件与消息传递结合
当配置文件与 Hermes 网关结合时，它们会变得更强大。这样你的团队就不再被锁在单个本地终端会话中。
你可以将不同的配置文件作为不同的消息身份运行，远程监督它们，通过 Telegram 路由工作，并在各种聊天和任务中保持角色边界完好无损。
这时，Hermes 开始感觉不再像一个单一的助手，而更像一个运营系统。
要点：消息传递让配置文件从本地组织功能转变为实时多智能体控制界面。
## 结论
如果你想让 Hermes 感觉更强大，就不要再试图让一个智能体做所有事情。
组建一个团队。
从编排者开始，添加一个专家，验证交接流程，然后再扩展。到那时，Hermes 配置文件不再像是一个功能，而开始像是一种基础设施。
要点：最聪明的多智能体团队不是最大的那个，而是角色边界最清晰的那一个。
## 相关链接
- [Teknium (e/λ) 转载](https://x.com/Teknium)
- [Neo](https://x.com/NeoAIForecast)
- [@NeoAIForecast](https://x.com/NeoAIForecast)
- [14K](https://x.com/NeoAIForecast/status/2043455838459920718/analytics)
- [升级至高级版](https://x.com/i/premium_sign_up)
- [2026年4月13日 上午6:26](https://x.com/NeoAIForecast/status/2043455838459920718)
- [1.46万次浏览](https://x.com/NeoAIForecast/status/2043455838459920718/analytics)
---
*导出时间: 2026/4/13 11:29:50*
