单 Profile 运行的问题
作者用单 Profile 运行 Hermes 14 天，兼任研究员、写手、工程师和编排者，最终所有角色声音混在一起变成同一个人。大多数人把这个问题归咎于 Prompt，但问题不在 Prompt，也不在模型——而在于一个 Agent 承载了五个角色，共享同一段记忆，所有角色都在互相污染上下文。
真正的解法不是更好的 Prompt，而是隔离的 Profiles。
Hermes Profiles 的本质
Hermes Profiles 不是"角色皮肤"，每个 Profile 一次性隔离七种状态：
- 配置（configuration）
- 会话（sessions）
- 记忆（memory）
- Skills
- 人格（personality）
- Cron 状态
- Gateway 状态
多 Agent 设定的失败，根源是所有角色共享同一份记忆和语感。你的编程 Agent 不应该继承研究 Agent 的默认设置，研究 Agent 也不应该携带写手的风格习惯。专业化只有在状态真正隔离时才能持久。
四个角色的分工
参考 @elvis/sd互的 canonical split：
- Hermes（编排者）：规划、分解、路由、合成。交通指挥员，不是瓶颈。
- Alan（研究员）：溯源、怀疑主义、不确定性感知。保护团队不被虚假置信度误导。
- Mira（叙事架构师）：清晰、结构、受众意识。把验证后的材料转化为沟通内容。
- Turing（工程师）：实现、调试、日志、复现。关心测试，不关心叙事。
这个分工映射了真实工作：编排者永远不需要成为好写手，写手不需要调试，工程师不需要说服任何人。
七步构建流程
- 从健康的基础 Hermes 出发：先确保基础安装正常，模型提供商配置正确，再克隆。
- 创建专家 Profile：
hermes profile create alan --clone（--clone 会复制 config.yaml、.env 和 SOUL.md，但每个 Profile 获得自己独立的记忆和会话历史）。 - 验证 Profile 已创建：
hermes profile list+ls ~/.hermes/profiles/，确认三个子目录存在。 - 为每个角色写真正的 SOUL.md：这是把 Profile 变成 Agent 的关键步骤。定义语气、默认行为、优势、优先级，以及每个 Agent 必须避免什么。
- 项目上下文放在 AGENTS.md，不是 SOUL.md：SOUL.md 定义 Agent 是谁，AGENTS.md 定义 Agent 当前在做什么项目。两者绝不混用。
- 添加团队参考文件：记录角色名单和交接规则。
- 独立运行 Profile：
hermes -p alan、hermes -p mira、hermes -p turing。Alan 不会继承 Mira 的草稿，Turing 不会继承 Alan 的研究会话。
运营层：让团队保持 30 天一致性的关键
交接合约（handoff contracts）
Profile 专业化的同时，必须干净利落地交接工作。没有合约的交接会变成："Alan 给 Mira 倾倒了 40kb 原始研究文本，现在 Mira 又变成研究员了。"
交接合约存放在 ~/.hermes/team/handoffs/<from>-to-<to>.md，每个文件包含四个字段：
- Input shape：接收方期望的格式（例如 Alan → Mira：带源 URL 的排名声明列表，不是原始摘录）
- Output shape：发送方将返回的格式（例如 Mira → Hermes：起草好的章节 + 变更日志，不是成品文章）
- Failure action：输入格式不符时的处理（阻止、要求人工审查、用调整后的 Prompt 重试）
- Verification gate：交接完成前必须满足的一个断言（例如 Alan → Mira：每条声明必须附带源 URL）
有交接合约，边界可以监控，可以看见何时开始腐化。没有合约，专业化在两周内溶解。
记忆 KPI
Profile 隔离记忆是必要条件，不是充分条件。记忆在每个 Profile 内部同样会腐化——就像单一维基超过 100 页就会腐化一样。
每周运行一次记忆审计：
for p in alan mira turing; do
hermes -p $p memory-kpi --json | jq '.source_backed_pct, .stale_notes, .contradiction_notes'
done
关键数字是 stale_notes。一旦超过总笔记的 15%，在该 Profile 开始引用过时上下文之前，安排一次 brain-resolve 通过。
角色策略门禁
不同角色携带不同风险：研究员只读，写手只读和写草稿，工程师可以运行沙箱测试，编排者可以审批合并和支付 API 调用。
# Alan（研究员）：风险级别 safe
- 只能读网页、读仓库、写入 research/
- 不能运行 shell 命令
- 不能在 research/ 以外写入任何内容
# Turing（工程师）：风险级别 review
- 读取仓库、运行沙箱测试、写入 feature branch
- 合并到 main 需要编排者显式审批
# Hermes（编排者）：风险级别 critical
- 唯一可以审批 Turing 合并、加宽其他 Profile 权限、或触发超预算付费 API 调用的 Profile
没有任何 Profile 获得的权限超出其角色所需，且只有编排者可以加宽任何其他 Profile 的范围。
Gateway 消息用于远程监督
Profile 系统是本地组织架构，Gateway 将其转化为可从手机监督的操作系统。将每个 Profile 连接到自己的消息身份：Alan 发研究结果到某频道，Mirai 推送草稿到某频道，Turing 发送测试结果和 PR 链接到某频道，Hermes 综合后发到某频道并请求关键行动的人工审批。
四种没人晒截图的失败模式
失败模式 1：Profile 漂移
SOUL.md 的编辑不断积累。一周前 Mira 是"清晰且有受众意识"，现在变成了"清晰、有受众意识、技术精准、还愿意起草实现笔记"。Mira 正在慢慢变成 Turing。
应对：每周 diff 每个 SOUL.md 相对于第一天的版本。任何新职责必须有显式审批日志条目，否则回滚。
失败模式 2：交接腐化
合约文件存在，但没人执行。Alan 开始给 Mira 发原始文字记录，Mirai 开始让 Turing"就检查一下这个"。边界溶解。
应对：将每个交接文件接入 harness。如果输入不符合声明格式，阻止交接并要求人工审查。合约只有在能阻塞时才是真实的。
失败模式 3：SOUL.md 膨胀
每个角色积累边缘情况。Turing 多了一段关于"如何处理 Python 2 遗留代码"的段落，Alan 多了三段关于"何时跳过同行评审来源"的说明。一个月内，每个 SOUL.md 变成 2kb 的特例集合，Agent 在噪音中失去了原始身份。
应对：SOUL.md 上限 400 词。超过这个上限的内容进入 AGENTS.md 或按领域拆分的参考文件。身份稳定，项目上下文轮换。
失败模式 4：Cron 冲突
Profile 运行定时任务：Alan 每周一拉研究摘要，Mirai 每周二从 Alan 的摘要生成草稿，Turing 运行夜间测试，Hermes 运行每日编排。通过第四周，其中两个任务在凌晨 3 点冲突——因为没人协调过时间表。
应对：一个共享的 ~/.hermes/team/cron.md 文件，列出每个 Profile 的所有定时任务（含准确时间、时长和依赖项），新增 Cron 前必须检查此文件，错开冲突任务。
核心结论
Profiles are the feature. Boundaries are the moat.
多 Agent 设定安静地失败。一切在第一天看起来正常，第七天运行良好，第三十天混为一体。失败的不是 Profile 系统本身——而是没人写过的运营层：交接合约能在腐化时阻止、每个 Profile 有记忆 KPI、角色策略与角色匹配、团队参考文件撑过接下来六个月。
Profiles 是功能。边界才是护城河。