最近 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
在搭建团队之前，我们要先分清四个概念：
- Profile
- Subagent
- Project
- Wiki
这四个概念如果混在一起，后面的系统一定会乱。
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 该如何分工？
我推荐一个经过验证的四角色模型：
- Coordinator
- Researcher
- Writer
- Builder
也可以理解成：
- 项目经理
- 研究员
- 作家
- 工程师
角色 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.md
- USER.md
- memory.md
- AGENTS.md
- Wiki
因为这些文件可能会进入模型上下文。
上篇小结
到这里，多 Profile 的基本搭建就告一段落了。
我们做了三件事：
- 明确为什么不能让一个 Agent 全包；
- 区分 Profile、Subagent、Project、Wiki 四个概念；
- 搭建 Coordinator、Researcher、Writer、Builder 四角色模型。
但这还只是“团队层”。
一个团队要长期运行，光有员工还不够。
它还需要：
- 共享文档；
- 项目空间；
- 任务看板；
- 决策记录；
- 复盘机制。
也就是下一篇要讲的重点：