Hermes高级用法：用多 Profile 协作 与 Wiki 共享记忆: 搭建你的 OPC Agent 团队（上篇）

最近 OPC 的概念很火。

OPC，也就是 One-Person Company，一人公司。

它的核心不是一个人单打独斗，而是一个人借助多个 Agent，像管理一支小团队一样，去完成一个或多个复杂任务。

那么问题来了：

如何构建一套可靠的多 Profile 协作架构？

今天这篇文章，我先带你梳理 Hermes 多 Profile 协作的核心逻辑。

这不是简单地“多开几个 Agent”，而是要建立一套稳定、清晰、可长期运行的 Agent 工作系统。

每一个想做 OPC 的人，都应该认真思考这个问题。

一、为什么要使用多 Profile 协作？

一个 Agent 当然可以完成很多事情。

它可以查资料、写文章、写代码、做图、做复盘。

但如果所有任务都交给一个 Agent，长期看会出现三个问题。

1. 幻觉问题

一个 Agent 最大的问题是：

自己写，自己审，自己觉得自己没问题。

所以我们需要建立一套团队运作体系，让不同 Profile 承担不同任务，从不同角度看同一个问题。

比如：

Researcher 负责事实；Writer 负责表达；Builder 负责实现；Coordinator 负责统筹。

这样系统更容易发现漏洞，也更不容易陷入单一 Agent 的自我确认。

2. 避免记忆污染

一个 Agent 同时做所有项目、所有环节，记忆很容易混在一起。

比如它同时记住：

文章要讲故事；代码要优先可运行；产品要先做 MVP；研究要标注来源。

这些经验本身没有错，但它们属于不同任务、不同环节、不同项目。

如果全部混进一个 memory，时间久了就会互相污染、互相矛盾。

最后的结果就是：

写代码时带着内容创作的习惯；写文章时带着工程实现的思维；做研究时又提前开始下结论。

这就是记忆污染。

3. 避免角色混乱

一个 Agent 同时负责研究、规划、写作、执行、审查、复盘，很容易角色混乱。

典型表现是：

该研究的时候，它开始写结论；该写作的时候，它又重新查资料；该审查的时候，它开始替自己的输出辩护；该做项目管理的时候，它沉迷于细节执行。

所以，多 Profile 的本质不是“更多 Agent”，而是更清晰的角色边界。

二、先搞懂四个概念：Profile、Subagent、Project、Wiki

在搭建团队之前，我们要先分清四个概念：

ProfileSubagentProjectWiki

这四个概念如果混在一起，后面的系统一定会乱。

1. Profile：长期员工

Profile 可以理解成系统中的长期员工。

每个 Profile 都是一个独立 Agent，拥有自己的身份、记忆、技能和运行配置。

比如：

Coordinator 是协调员；Researcher 是研究员；Writer 是作家；Builder 是构建者。

它们不是同一个 Agent 的不同聊天窗口，而是不同角色、不同职责、不同记忆边界的长期成员。

所以，多 Profile 实质上是在搭建一支 Agent 团队。

2. Subagent：临时工

Subagent 是临时 Agent。

它更像是临时派出去的小助手，适合处理复杂任务中的局部问题。

比如你要写一篇深度文章，可以临时派出几个 Subagent：

一个查传统 RAG；一个查 Agentic RAG；一个查 LLM Wiki；一个检查逻辑漏洞。

Subagent 干完就结束，不需要长期人格，也不需要长期记忆。

所以可以简单理解为：

Profile 是长期员工。Subagent 是临时外包。

3. Project：项目空间

Project 是长期任务的项目空间。

如果你同时推进多个长期任务，比如：

Twitter Growth；Vibe Coding；内容增长系统；产品 Demo。

那每个长期任务都应该有自己的项目空间。

注意：

运行多个长期任务时，关键不是多建 Profile，而是先划分好项目空间。

不要为每个项目复制一套 Profile。

正确做法是：

同一套 Profile 团队，服务多个 Project folder。

这样才能避免 Profile 数量爆炸，也能避免长期记忆污染。

4. Wiki：共享记忆层

多 Profile 的记忆不相通，那复杂任务怎么推进？

答案是：

共享 Wiki。

Wiki 就像一家公司的共享文档。

不同员工有不同的大脑，但他们可以通过共享文档同步：

项目进度；任务状态；决策记录；知识沉淀。

在 Hermes 多 Profile 系统里，Wiki 不是普通笔记库，而是一个有组织、可维护、可长期运行的共享记忆系统。

它记录：

项目状态；任务进度；决策记录；研究材料；最终产出；通用方法论。

所以，一个稳定的 Agent 团队，实际上是由多 Profile 和共享 Wiki 共同组成的。

三、四角色模型：像真实公司一样组织 Agent

多 Profile 该如何分工？

我推荐一个经过验证的四角色模型：

CoordinatorResearcherWriterBuilder

也可以理解成：

项目经理研究员作家工程师

角色 1：协调员 Coordinator

Coordinator 就是项目经理。

它的核心职责是：

定义目标：明确最终要达成什么。拆分任务：把大目标拆成可执行的小任务。路由任务：判断每个任务应该交给谁。汇总结果：把不同角色的产出整合成最终结果。检查边界：避免记忆污染和文件冲突。

Coordinator 不应该沉迷于亲自查资料、写文章、写代码。

它最重要的职责是：

让整个系统有序运行。

角色 2：研究专员 Researcher

Researcher 就是研究员。

它的核心职责是：

收集证据：从多个来源获取信息。对比来源：交叉验证，确保信息可靠。标记不确定性：明确指出哪些信息尚未验证。提炼事实：区分事实、观点和推测。

一个好的 Researcher，可以显著降低整个系统的幻觉。

它不应该直接写最终稿，也不应该直接做最终决策。

它要做的是提供可靠的原材料。

角色 3：作家 Writer

Writer 负责把原材料转化成清晰内容。

它的核心职责是：

搭建文章结构。优化表达方式。提炼主线和观点。让内容适合目标读者。把复杂概念讲清楚。

当 Writer 不需要再负责规划和查资料，它的输出质量会明显提升。

因为它可以专注于一件事：

把内容讲清楚。

角色 4：构建者 Builder

Builder 更像工程师。

它的核心职责是：

实现：把计划变成可运行的代码、页面或系统。调试：定位并修复问题。测试：确保输出稳定可靠。交付：生成最终可用的结果。

当 Builder 不需要再负责讲故事、做研究、定方向时，它的实现质量也会提高。

因为它可以专注于落地。

四、完整工作流

一套典型的多 Profile 工作流是：

Coordinator 拆解并规划任务；Researcher 收集来源、验证主张；Writer 把研究结果转化成清晰内容；Builder 负责最终实现或交付；Coordinator 最后检查、汇总、归档。

这个结构之所以强大，是因为它反映了真实工作流程。

现实里，一个稳定团队也不会让同一个人同时当项目经理、研究员、作家、工程师和审稿人。

Agent 团队也是一样。

五、开始构建每个 Profile

当角色分工确定后，就可以开始构建每个 Profile。

每个 Profile 通常包含：

soul.mdUSER.mdmemory.mdconfig.yamlskills/.env

看到这么多东西，很多人会头大。

接下来，我以“协调员 Coordinator”为例，讲一下每个文件分别负责什么。

1. soul.md：协调员是谁

soul.md 是 Profile 的核心身份文件。

它定义这个 Profile：

是谁；负责什么；有什么边界；不应该做什么。

比如 Coordinator 的 soul.md 需要说明：

它是协调员；它负责拆分任务、规划项目、汇总结果；它维护 dashboard 和 agent-log；它不直接执行研究任务；它不直接写最终内容；它不直接实现代码。

注意：

如果你同时推进多个项目，不要把具体项目内容写进 soul.md。

否则极容易造成角色污染。

soul.md 写的是：

这个 Agent 是谁。

不是：

这个项目现在在做什么。

2. USER.md：协调员理解的用户是谁

USER.md 记录的是这个 Profile 对用户的理解。

比如：

用户偏好中文交流；用户喜欢结构清晰的 Markdown；用户不喜欢空泛概念；用户希望输出适合复制到 Obsidian。

注意：

这里的 USER.md 是“协调员这个角色所理解的用户形象”，不是整个系统唯一的用户画像。

如果需要所有 Profile 共享用户画像，应该放到 Wiki 的：

system/user-profile.md

3. memory.md：协调员学到的通用经验

memory.md 记录的是这个 Profile 在长期工作中总结出来的通用经验。

比如：

复杂任务应该先拆解；不同 Profile 不要同时修改同一个正式文件；中间材料先进入 inbox；最终产出再进入 outputs。

但这里不应该写具体项目经验。

比如：

Twitter 今天写了 3 条推文；Vibe Coding 登录页已经完成。

这些内容不属于 memory.md，而应该放到项目空间里。

memory.md 记录的是：

通用经验，不是项目状态。

4. skills：协调员的技能库

skills 是可复用的任务流程。

Coordinator 的 skills 可以包括：

任务拆解；项目优先级判断；交接单生成；dashboard 更新；weekly review；memory audit。

这些 skills 专门服务于协调员这个角色。

如果某个 skill 是通用技能，比如：

project-context-loader；memory-routing。

可以分别加入多个 Profile 的 skills list。

但不要把所有技能都塞给所有 Profile。

否则角色边界又会乱掉。

5. config.yaml：协调员如何运行

config.yaml 是 Profile 的运行配置。

它规定这个 Profile 如何工作，比如：

使用什么模型；默认工作目录是什么；允许读写哪些文件；是否自动加载 skills；哪些文件不能修改。

注意：

config.yaml 不是写任务内容的地方。

它回答的是：

这个 Profile 怎么运行？

不是：

这个项目要做什么？

6. .env：协调员的密钥

.env 只放密钥。

比如：

API Key；Token；SMTP 密码；外部服务凭证。

不要把这些内容写进 .env：

项目状态；用户偏好；任务说明；文章内容。

也不要把密钥写进：

soul.mdUSER.mdmemory.mdAGENTS.mdWiki

因为这些文件可能会进入模型上下文。

上篇小结

到这里，多 Profile 的基本搭建就告一段落了。

我们做了三件事：

明确为什么不能让一个 Agent 全包；区分 Profile、Subagent、Project、Wiki 四个概念；搭建 Coordinator、Researcher、Writer、Builder 四角色模型。

但这还只是“团队层”。

一个团队要长期运行，光有员工还不够。

它还需要：

共享文档；项目空间；任务看板；决策记录；复盘机制。

也就是下一篇要讲的重点：

如何用 Wiki 构建你的 OPC 共享记忆系统。