最近，一人公司模式（OPC）的概念在AI工作流与效率工具领域备受关注。

OPC，即 One-Person Company，代表一人公司的运营理念。

从本质上看，OPC 并非要求单打独斗完成所有工作，而是让个人通过调度多个智能体（Agent），如同管理一支小型团队，去应对那些仅凭一人之力难以完成的复杂任务。

但这引出了一个关键问题：

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

今天这篇文章，我们将从 Hermes 多 Profile 协作的核心逻辑切入。它远不止是“多开几个 Agent 窗口”那么简单，而是要搭建一个稳定、清晰、可长期运转的 Agent 工作体系。对于任何希望实践 OPC 模式的人来说，这都是一个必须深入思考的课题。

一、为何需要采用多 Profile 协作？

单一 Agent 固然能完成许多工作，如查资料、写文章、编代码、制图、复盘等，看似无所不能。但如果将所有任务都压在同一个 Agent 身上，时间一长，三个问题就会逐渐暴露。

1. 幻觉与自我确认偏差

单一 Agent 最大的弊端是什么？自己产出内容，自己审核，还认为自己毫无问题。这好比让一个学生既当运动员又当裁判，难免出现评判偏差。因此，我们需要建立一套团队运作机制：让不同的 Profile 承担不同职责，从多角度审视同一个问题。

举个例子：

• Researcher（研究员）负责核实事实与数据；
• Writer（作家）负责打磨语言表达；
• Builder（构建者）负责动手实现落地；
• Coordinator（协调员）负责统筹全局与任务调度。

如此一来，系统更容易发现潜在漏洞，也大大降低了单一 Agent 陷入“自我确认”陷阱的风险。

2. 防止记忆污染

当一个 Agent 同时处理所有项目与环节时，其记忆很容易变得混乱。它可能同时记住：“文章需要讲故事”、“代码要优先保证可运行”、“产品要先做 MVP”、“研究需要标注来源”。这些经验本身都没有错，但它们分属不同任务、不同环节、不同项目。如果全部塞进同一个记忆库，时间一长就会互相干扰、彼此矛盾。最终结果就是：写代码时带着内容创作的思维，写文章时又带着工程实现的逻辑，做研究时却提前下结论。这就是典型的记忆污染问题。

3. 避免角色混乱

设想一下，一个 Agent 同时承担研究、规划、写作、执行、审查、复盘等所有角色，它的角色定位必然模糊。典型表现是：该做研究时，它开始写结论；该写文章时，它又重新去查资料；该审查时，它却开始为自己的输出辩解；该做项目管理时，它却陷入细节执行中。因此，多 Profile 的本质并非“更多的 Agent”，而是“更清晰的职责边界”。

二、先理清四个核心概念：Profile、Subagent、Project、Wiki

在组建 Agent 团队之前，必须明确分清 Profile、Subagent、Project 和 Wiki 这四个概念。如果将它们混淆，后续系统必然会陷入混乱。

1. Profile：长期雇员

Profile 可以理解为系统中的“长期员工”。每个 Profile 都是一个独立的 Agent，拥有自己的身份、记忆、技能和运行配置。例如，Coordinator 是协调员，Researcher 是研究员，Writer 是作家，Builder 是构建者。它们不是同一个 Agent 的不同对话窗口，而是不同角色、不同职责、不同记忆边界的固定成员。因此，多 Profile 本质上就是在搭建一支专业的 Agent 团队。

2. Subagent：临时外包

Subagent 是“临时工”性质的 Agent。它更像是一支临时派出的小分队，适合处理复杂任务中的局部问题。比如，要写一篇深度文章，可以临时派出几个 Subagent：一个负责查询传统 RAG，一个负责研究 Agentic RAG，一个负责检查逻辑漏洞。Subagent 完成任务后即结束，无需长期人格或长期记忆。简单来说：Profile 是长期正式员工，Subagent 是短期外包人员。

3. Project：项目空间

Project 是承载长期任务的项目空间。如果你同时推进多个长期任务，例如 Twitter 增长、Vibe Coding、内容增长系统、产品 Demo 等，那么每个长期任务都应该拥有独立的项目空间。需要注意：同时运行多个长期任务时，关键不在于创建多个 Profile，而在于先划分好项目空间。不要为每个项目都复制一套 Profile。正确的做法是：同一套 Profile 团队，服务于多个 Project 文件夹。这样既能避免 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.md、USER.md、memory.md、config.yaml、skills/ 文件夹、.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 等。这些技能专门服务于协调员这个角色。如果某个技能是通用技能，例如 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 四角色模型。

但这还只是“团队层”的搭建。一个团队要长期稳定运行，光有成员还不够。它还需要共享文档、项目空间、任务看板、决策记录和复盘机制。这些，就是我们接下来要探讨的重点：

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