终极Hermes指南——从一名特工到一支拥有4个不同角色、30天后依然保持协调的团队
单个全能智能体注定失败
我运行过一个全能智能体十四天。这个智能体同时承担研究员、作家、程序员和协调员四个角色。它跑在单个Claude Sonnet 4.6模型上。到了第十四天，所有角色都混成一个声音。大部分操作者遇到这种情况会责怪提示词写得不好。但问题不在提示词，也不在模型本身。问题是一个智能体背着五个角色跑在共享记忆上。所有人都说“优化提示词就能解决”，却没人提到真正修复问题的Hermes基础组件：独立角色配置文件。
共享记忆让研究员的习惯污染程序员。作家的风格传染给协调员。你的编程智能体不应该继承研究员的默认行为。研究员不应该携带作家的风格习惯。只有每个角色的状态完全隔离，专业分工才能持久。我用一周时间搭建了一个四人团队：协调员加Alan、Mira和Turing。四个角色干净交接，一天内整理了一千三百一十七个书签。搭建方法是对的，但它只告诉你第一天怎么做。这篇指南从第二天开始，带你走过操作层，让四人团队在第三十天仍然保持清晰。操作层包含交接合同、每个角色的记忆关键绩效指标、每个岗位的策略门禁，还有四种没人晒截图的失败模式。如果你忽略操作层，你的团队会在一个月内塌缩成一个模糊的智能体。
团队思维模型必须彻底更换
错误思维模型是：我需要一个全能天才人工智能，让它干所有事。正确思维模型是：我需要一个小团队，每个成员有清晰角色、明确交接方式、减少上下文污染。Hermes角色配置文件让这个模型变成现实。配置文件不是角色皮肤。每个配置文件同时隔离七种状态：配置、会话、记忆、技能、人格、定时任务状态、网关状态。这个隔离机制很重要，因为多智能体系统在共享记忆和语气时会快速失败。你的编程智能体不应该继承研究员的研究习惯。研究员不应该携带作家的风格偏好。只有当状态保持隔离时，专业分工才能持久。
四个角色对应真实功能分工。Hermes是协调员，负责计划、拆解任务、路由请求、综合结果。它是交通指挥员，不是瓶颈。Alan是研究专家，以来源为先，保持怀疑态度，对不确定性敏感。它保护团队不受幻觉式自信的伤害。Mira是叙事架构师，负责清晰度、结构和受众意识，把验证过的材料转化成沟通内容。Turing是构建者和调试员，负责实现、日志、差异对比、可复现性。它关心测试，不关心叙事润色。这种分工有效是因为它镜像了真实工作。协调员不必是好作家。作家不必调试代码。工程师不必说服任何人。每个角色每周变得更清晰，因为它的记忆始终聚焦在自己的主题上。
搭建四个专业角色配置文件的七个步骤
第一步：从一个正常工作的Hermes开始。在克隆之前确保你的基础Hermes安装是健康的。模型提供方配置正确，认证正常工作，普通会话可用。你从这个基础克隆，所以这里任何问题都会破坏四个配置文件。
第二步：创建专业角色配置文件。在终端运行以下命令：
bash
hermes profile create alan --clone
hermes profile create mira --clone
hermes profile create turing --clone
--clone标志从你的工作基础复制配置文件和SOUL.md文件。每个新配置文件仍然获得自己独立的记忆和会话历史。
第三步：在磁盘和命令行界面验证。运行hermes profile list和ls ~/.hermes/profiles/。你应该在~/.hermes/profiles/下面看到alan、mira、turing三个文件夹。你的主Hermes保持为协调员。
第四步：为每个角色编写真实的SOUL.md文件。这一步把配置文件变成真正的智能体。编辑每个SOUL.md文件，让它携带持久的身份：语气、默认行为、优势、优先级以及该智能体必须避免什么。一个强力的分工是这样的：Hermes（协调员）负责计划、委派、综合、最终质量检查，听起来结构分明且果断。Alan（研究）负责证据、验证、深度、不确定性，听起来以来源为先且持怀疑态度。Mira（作家）负责清晰度、结构、受众，听起来清晰且具有受众意识。Turing（工程师）负责实现、调试、测试、可复现性，听起来精确且面向测试。
如果你只改名字不改SOUL.md文件，你就没有团队，你只有四个带着标签的克隆体。
第五步：把项目上下文保存在AGENTS.md文件中，不要放在SOUL.md文件里。SOUL.md文件定义智能体是谁。AGENTS.md文件定义它当前在做什么项目。永远不要混用两者。项目特定上下文放在AGENTS.md文件中：代码库结构、编程规范、工作流规则和当前优先级。身份保持稳定，项目上下文轮换。
第六步：添加一个团队参考文件。一个共享文件记录团队成员名单和配置文件之间如何交接。本指南末尾有模板。
第七步：分别运行各个配置文件。运行hermes -p alan、hermes -p mira、hermes -p turing。每个都在隔离状态中运行。Alan不继承Mira的草稿。Turing不继承Alan的研究会话。只有当你实际分开使用它们时，好处才会显现。
角色交接合同防止上下文污染
配置文件专业分工，这意味着它们也必须干净地交接工作。没有合同的交接就变成“Alan把四十千字节的原始研究倾倒进Mira的会话，现在Mira又变成了研究员”。一份交接合同是每对角色之间的一个文件，存储在~/.hermes/team/handoffs/<从角色>-to-<到角色>.md，包含四个字段。
第一个字段是输入形状：接收配置文件期望什么格式。例如Alan到Mira：一份带有来源网址的已验证声明的排序列表，不是原始摘录。第二个字段是输出形状：接收配置文件将返回什么。Mira到Hermes：一份带有变更日志的草稿章节，不是完成品文章。第三个字段是失败动作：如果输入格式错误怎么办。可以选择阻塞、要求人工审核、用调整后的提示词重试。第四个字段是验证门禁：在交接完成前必须成立的一个断言。Alan到Mira的验证门禁是每个声明都带有来源网址。Turing到Hermes的验证门禁是每个修复都带有通过的测试。
有了交接合同，你可以观察边界，看到它什么时候腐烂。没有交接合同，专业分工在两周内溶解。
每个配置文件的记忆关键绩效指标
Hermes配置文件隔离记忆，这是必要条件但不是充分条件。记忆在每个配置文件内部腐烂，就像单个维基百科超过一百页后腐烂一样。Alan的研究笔记变旧。Mira的草稿片段堆积。Turing的调试会话积累死分支。每周对每个配置文件运行一次记忆审核。
在终端运行以下命令：
for p in alan mira turing; do
hermes -p $p memory-kpi --json | jq '.source_backed_pct, .stale_notes, .contradiction_notes'
done
如果你在Hermes旁边运行LACP工具，你在控制平面层获得相同的原始功能。无论哪种方式，你要关注的数字是陈旧笔记数。一旦它超过某个配置文件中总笔记数的百分之十五，在该配置文件开始从过时上下文中引用自己之前，安排一次大脑解析过程。
每个角色的策略门禁限制权限
不同角色承担不同风险。研究是读取。写作是起草。工程是执行。协调是决策。单个策略不可能适用于所有四个角色。每个角色需要自己的策略门禁。
Alan（研究）的风险等级是安全。它可以读取网页、读取代码库、只写入research/文件夹。不能运行shell命令。不能写入它的沙箱之外。Mira（作家）的风险等级是安全。它可以读取研究输出，只写入drafts/文件夹。不能读取密钥，不能执行代码。Turing（工程师）的风险等级是审核。它可以读取代码库、运行沙箱测试、写入功能分支。每次向主分支提交都需要明确的协调员批准。Hermes（协调员）的风险等级是关键。它是唯一可以批准Turing提交、合并分支或触发超过预算上限的付费应用程序接口调用的配置文件。
在每个配置文件的config.yaml中编码这个策略，或者在运行LACP工具时的工具层编码。规则是：没有配置文件获得超过其角色所需的权限，协调员是唯一可以扩大任何其他配置文件范围的角色。
网关消息实现远程监督
配置文件系统是一个本地组织架构图。网关把它变成一个你可以用手机监督的操作系统。将每个配置文件连接到自己的消息身份。Alan把研究发现发布到#research频道。Mira把草稿放到#drafts频道。Turing把测试结果和拉取请求链接发布到#engineering频道。Hermes综合成#summary频道，并在关键操作上请求人工批准。
现在你可以走去吃午饭，回来时知道哪个配置文件做了什么、按什么顺序做的、在哪里停止了。消息传递把四个本地配置文件变成一个实时多智能体控制面板。
四个四人团队的三十天失败模式
过去几个月我观察的每个四人团队至少遇到其中一种失败模式。所有四种都可以预防。
失败模式一：配置文件漂移。SOUL.md文件不断累积编辑。一周前Mira是“清晰且具有受众意识”。今天Mira是“清晰、具有受众意识、技术精确并且愿意起草实现笔记”。恭喜，Mira慢慢变成了Turing。修复方法：每周对比每个SOUL.md文件和它第一天的版本。任何新增责任必须有明确的批准日志条目，否则就回滚。
失败模式二：交接腐烂。合同文件存在，但没人强制执行它。Alan又开始向Mira发送原始转录稿。Mira开始请求Turing“就检查这一件事”。边界溶解。修复方法：将每个交接文件连接到工具层。如果输入不符合声明的形状，让交接失败并要求人工审核。合同只有能阻塞才是真实的。
失败模式三：SOUL.md文件膨胀。每个角色增长边缘案例。Turing增加一段关于“我们如何处理Python2遗留代码”的段落。Alan增加三段关于“何时跳过同行评审来源”的段落。一个月内，每个SOUL.md文件变成两千字节的特殊案例，智能体在噪音中丢失了原始身份。修复方法：将SOUL.md文件限制在四百字。超出部分放入AGENTS.md文件或每个领域的参考文件。身份保持稳定，上下文轮换。
失败模式四：定时任务冲突。配置文件运行定时任务。Alan每周拉取研究摘要。Mira每周重新生成草稿。Turing运行夜间测试扫描。Hermes运行每日协调过程。到第四周，其中两个在凌晨三点冲突，因为没人协调时间表。修复方法：一个共享文件~/.hermes/team/cron.md，列出每个配置文件中每个计划任务的确切时间、持续时间和依赖关系。错开冲突。在向任何配置文件添加新定时任务之前检查这个文件。
团队参考文件模板保存六个月后还能用
一个文件，一个目的：向你自己和六个月后使用系统的任何人解释你的团队。把以下内容保存为~/.hermes/team-agents.md。
~/.hermes/team-agents.md
# 团队成员名单 |
把这个文件放在版本控制下。每个团队成员的编辑都通过一次提交。在第九十天你会感谢自己。
操作手册总结
目标：运行一个在第三十天之后仍然保持清晰的四人Hermes团队。
输入：正常工作的Hermes基础、配置文件命令行界面、SOUL.md和AGENTS.md的分离、交接合同、每个角色的策略、网关消息。
过程：用--clone构建四个配置文件，为每个角色编写独特的SOUL.md文件，把项目上下文保存在AGENTS.md文件中，在~/.hermes/team/handoffs/编码交接合同，在每个config.yaml中编码每个角色的策略，每周运行每个配置文件的记忆关键绩效指标，对比每个SOUL.md文件和第一天版本，错开定时任务，通过提交强制执行team-agents.md文件。
输出：四个隔离的配置文件、每个角色的策略阻塞、交接合同文件、错开的定时任务时间表、消息路由、版本化团队参考。
护栏：没有记录原因就不能编辑SOUL.md文件，没有声明的输入形状就不接受交接，没有协调员批准就不能扩大任何角色，不检查共享时间表就不能添加定时任务。
最终思考
大多数多智能体设置安静地失败。第一天看起来都很好，第七天工作得很棒，到第三十天就模糊在一起。配置文件系统不是失败的原因，失败的是它上面的操作层，而没人写过这个操作层。我上周发布的搭建方法是对的。这篇指南的其余部分是维护合同：腐烂时能阻塞的交接合同、每个配置文件的记忆关键绩效指标、匹配角色的策略上限、以及一个能存活未来六个月的团队参考文件。配置文件是功能特性。边界是护城河。