Nyk（@nyk_builderz）分享了一个完整实验：用一个 Claude Profile 跑 researcher、writer、coder、orchestrator 四个角色，14 天后所有声音都混成了同一个。
大多数人在这里会怪 prompt。Nyk 的结论相反：不是 prompt 的问题，是一个 profile 被叫去做了四个人的工作。
为什么会失败
当一个 agent 同时扮演四个角色时，每个角色都有自己的语言模式、思维节奏和工作优先级。14 天后，前额皮质（orchestrator）和执行层（coder/writer）的声音开始在同一个 profile 里打架——不是你 prompt 不够好，是同一个大脑在同时处理四个完全不同的工作模式。
这不是 prompt 能解决的架构问题。
解法：角色拆分
核心思路是四周计划，逐步把一个 profile 拆成四个专业 profiles，同时保持团队一致性。
第一周：建立单一 profile 的核心行为模式，包括它如何思考、如何沟通、如何判断完成标准。这是后面拆分的 baseline。
第二周：引入第二个 profile（比如 researcher + orchestrator 合并），让它们开始通过消息传递协作。观察哪里出现了角色混淆。
第三周：拆分 researcher 和 writer，让 writer 只接收 research output，不参与研究过程。
第四周：所有四个 profile 完全独立运行，通过标准化接口通信。一致性通过共享的 system prompt 片段和输出格式规范维持。
保持一致性的关键
- 共享词汇表：所有 profiles 使用相同的术语定义（什么算「完成」、「高质量」、「相关」）
- 标准化接口：每个 profile 的输入输出格式是固定的，不是自由文本
- 连接层：orchestrator profile 是唯一知道所有其他 profiles 在做什么的，负责在它们之间路由信息
- 定期对检：每天或每隔几个 session，所有 profiles 重新对齐一次目标
这个框架的名字
Nyk 的框架叫 Hermes——一个多角色 agent 团队的协调协议。不是工具，是角色分工的操作系统。
他的核心洞察：大多数 operators 失败后去优化 prompt，但真正的问题是角色边界不清晰。 你不能通过更好的指令让同一个大脑同时做好四件事——你只能通过架构拆分让四个大脑各司其职。
这个框架和软件工程的微服务架构同构：不是让一个巨大的单片程序做所有事，而是让专门的服务通过明确定义的接口通信。