Hermes 高级用法：用多 Profile 协作搭建 OPC Agent 团队

✍ 知野🕐 2026-04-30📦 12.2 KB 🟢 已读 𝕏 文章列表

本文探讨了如何利用 Hermes 的多 Profile 协作功能，将多个 Agent 组织成一支 OPC（一人公司）团队。文章指出，单一 Agent 存在幻觉、记忆污染和角色混乱等问题，因此建议引入类似公司架构的四角色模型：Coordinator（协调员）、Researcher（研究员）、Writer（作家）和 Builder（构建者）。文章详细阐述了 Profile、Subagent、Project 和 Wiki 四个核心概念的区别，并提供了构建稳定 Agent 工作系统的具体配置方法，旨在建立清晰的角色边界和可长期运行的协作体系。

# Hermes 高级用法：用多 Profile 协作 + Wiki 共享记忆，搭建你的 OPC Agent 团队（上篇） **作者**: 知野 **日期**: 2026-04-29T09:03:10.000Z **来源**: [https://x.com/knoYee_/status/2049414174783193349](https://x.com/knoYee_/status/2049414174783193349) --- ![Image](/doc/1312/image/img_684683840b0f.jpg) # 上篇：多 Profile 协作：如何把 Agent 组织成一支 OPC 团队最近 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 也可以理解成： - 项目经理 - 研究员 - 作家 - 工程师 ![Image](/doc/1312/image/img_8d1cc9a63190.jpg) ## 角色 1：协调员 Coordinator Coordinator 就是项目经理。它的核心职责是： 1. 定义目标：明确最终要达成什么。 2. 拆分任务：把大目标拆成可执行的小任务。 3. 路由任务：判断每个任务应该交给谁。 4. 汇总结果：把不同角色的产出整合成最终结果。 5. 检查边界：避免记忆污染和文件冲突。 Coordinator 不应该沉迷于亲自查资料、写文章、写代码。它最重要的职责是： > 让整个系统有序运行。 ## 角色 2：研究专员 Researcher Researcher 就是研究员。它的核心职责是： 1. 收集证据：从多个来源获取信息。 2. 对比来源：交叉验证，确保信息可靠。 3. 标记不确定性：明确指出哪些信息尚未验证。 4. 提炼事实：区分事实、观点和推测。一个好的 Researcher，可以显著降低整个系统的幻觉。它不应该直接写最终稿，也不应该直接做最终决策。它要做的是提供可靠的原材料。 ## 角色 3：作家 Writer Writer 负责把原材料转化成清晰内容。它的核心职责是： 1. 搭建文章结构。 2. 优化表达方式。 3. 提炼主线和观点。 4. 让内容适合目标读者。 5. 把复杂概念讲清楚。当 Writer 不需要再负责规划和查资料，它的输出质量会明显提升。因为它可以专注于一件事： > 把内容讲清楚。 ## 角色 4：构建者 Builder Builder 更像工程师。它的核心职责是： 1. 实现：把计划变成可运行的代码、页面或系统。 2. 调试：定位并修复问题。 3. 测试：确保输出稳定可靠。 4. 交付：生成最终可用的结果。当 Builder 不需要再负责讲故事、做研究、定方向时，它的实现质量也会提高。因为它可以专注于落地。 # 四、完整工作流一套典型的多 Profile 工作流是： 1. Coordinator 拆解并规划任务； 2. Researcher 收集来源、验证主张； 3. Writer 把研究结果转化成清晰内容； 4. Builder 负责最终实现或交付； 5. 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。这些 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 的基本搭建就告一段落了。我们做了三件事： 1. 明确为什么不能让一个 Agent 全包； 2. 区分 Profile、Subagent、Project、Wiki 四个概念； 3. 搭建 Coordinator、Researcher、Writer、Builder 四角色模型。但这还只是“团队层”。一个团队要长期运行，光有员工还不够。它还需要： - 共享文档； - 项目空间； - 任务看板； - 决策记录； - 复盘机制。也就是下一篇要讲的重点： > 如何用 Wiki 构建你的 OPC 共享记忆系统。 ## 相关链接 - [@knoYee_](https://x.com/knoYee_) - [22K](https://x.com/knoYee_/status/2049414174783193349/analytics) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [5:03 PM · Apr 29, 2026](https://x.com/knoYee_/status/2049414174783193349) - [22.2K Views](https://x.com/knoYee_/status/2049414174783193349/analytics) - [View quotes](https://x.com/knoYee_/status/2049414174783193349/quotes) --- *导出时间: 2026/4/30 16:37:11*

🔗 相关文档