上一篇我们讲了 Hermes高级用法：用多 Profile 协作 + Wiki 共享记忆，搭建你的 OPC Agent 团队（上篇）。
核心观点是：
- 不要让一个 Agent 同时承担所有角色。
更稳的方式是，把 Agent 组织成一支小团队：
- Coordinator 负责协调；
- Researcher 负责研究；
- Writer 负责表达；
- Builder 负责构建。
但这会带来一个新问题：
- 多 Profile 之间记忆不相通，那它们怎么长期协作？
答案是：
- 用 Wiki 作为共享记忆层。
一、Wiki 是什么？
在这套系统里，Wiki 不是普通笔记库。
它是整个 OPC 系统的：
- 共享知识库；
- 项目管理层；
- 长期记忆层。
它管理三类东西：
- 知识；
- 资料；
- 产出。
更具体地说，Wiki 负责记录：
- 项目背景；
- 任务状态；
- 推进日志；
- 重要决策；
- 中间材料；
- 最终产出；
- 跨项目方法论；
- 原始资料。
可以把它理解成一家公司的共享文档系统。
在这个系统里：
- Profile 是员工；
- Project 是项目办公室；
- Wiki 是公司资料库；
- Coordinator 是总控。
这样，多个 Profile 即使记忆不相通，也能通过 Wiki 协同工作。
二、Wiki 的整体结构
一个完整的 Wiki，建议包含 8 个部分：
index.mdschema.mdsystem/projects/pages/raw/assets/archive/
Pasted image 20260428214948.png这几个部分看起来多，但每一层都有明确作用。
它们共同解决的是一个核心问题：
- 信息到底应该放在哪里？
如果不分层，所有东西都会混在一起。
比如：
- 项目状态会污染用户画像；
- 临时想法会污染长期知识；
- 角色经验会污染项目规则；
- 原始资料会和最终结论混在一起。
所以 Wiki 的第一原则是：
- 分层，就是防污染。
三、index.md：Wiki 入口
index.md 是整个 Wiki 的首页。
它不存具体内容，只做导航。
它告诉人和 Agent：
- 系统区在哪里；
- 当前有哪些项目；
- 通用知识在哪里；
- 原始资料在哪里；
- 最近重点是什么。
index.md 的作用是让任何 Profile 一进入 Wiki，就知道该从哪里开始读。
它是地图，不是仓库。
四、schema.md：Wiki 规范
schema.md 是 Wiki 的宪法。
它规定：
- 文件怎么命名；
- 内容写到哪里；
- 哪些文件只读；
- 哪些文件可以改；
- 什么信息不能乱写；
- 页面状态如何标记。
有了 schema.md，整个 Wiki 才能长期稳定运行。
否则每个 Profile 都按自己的理解写文件，很快就会乱。
比如，schema.md 可以规定：
- Raw 只读不改；
- Project 文件只记录对应项目的信息；
- Pages 只记录跨项目可复用的方法论；
- System 只记录全局管理信息；
- 不确定的信息先进入 inbox，不直接进入 pages。
这就是规则层。
五、system：全局管理层
system 是 Wiki 的全局管理区。
它不是某个具体项目，而是整个系统的管理中枢。
system 里建议包含 6 个核心文件：
dashboard.mdagent-log.mdweekly-review.mdmemory-routing.mdskill-registry.mduser-profile.md
1. dashboard.md：总控面板
dashboard.md 记录所有项目的当前状态。
它回答：
- 现在有哪些项目？
- 每个项目进展如何？
- 下一步做什么？
- 谁负责？
- 有没有阻塞？
dashboard.md 通常只应该由 Coordinator 更新。
其他 Profile 可以读取，但不要随便修改。
这样可以避免多个角色同时改总控面板，造成冲突。
2. agent-log.md：全局 Agent 行为日志
agent-log.md 记录所有 Profile 做过什么。
比如：
- Researcher 查了什么资料；
- Writer 写了什么草稿；
- Builder 交付了什么文件；
- Coordinator 更新了哪些状态。
它的作用是让多 Profile 的行为可追踪。
当系统运行久了，你可以回头看到：
- 谁在什么时候做了什么；
- 产出在哪里；
- 任务是否完成。
这对长期 OPC 系统非常关键。
3. weekly-review.md：周期复盘
weekly-review.md 不是单纯记录流水账。
它的作用是把一周的行动转化成策略。
它应该总结：
- 本周完成了什么；
- 哪些地方卡住了；
- 哪些经验可以复用；
- 哪些决策需要调整；
- 下周重点是什么。
真正有价值的 OPC 系统，不只是执行任务，而是要能从任务中沉淀方法。
weekly-review.md 就是做这件事的地方。
4. memory-routing.md：记忆写入规则
memory-routing.md 是防污染的核心文件。
它规定不同信息应该写到哪里。
比如：
- 角色身份写入 soul.md；
- 用户长期偏好写入 USER.md 或 system/user-profile.md；
- 角色通用经验写入 memory.md；
- 项目规则写入 AGENTS.md；
- 项目背景写入 context.md；
- 项目任务写入 tasks.md；
- 项目过程写入 log.md；
- 项目决策写入 decisions.md；
- 临时材料写入 inbox/；
- 正式产出写入 outputs/；
- 跨项目方法论写入 pages/；
- 原始资料写入 raw/。
这套规则决定了系统能不能长期稳定运行。
5. skill-registry.md：技能清单
skill-registry.md 记录整个系统有哪些可复用 skills，以及它们应该分配给谁。
它可以防止一个问题：
- 所有 Profile 都装一堆技能，最后角色边界再次混乱。
比如：
- dashboard-update 只应该给 Coordinator；
- source-validation 应该给 Researcher；
- article-structure 应该给 Writer；
- code-builder 应该给 Builder。
高风险技能，比如：
- delete-files
- deploy-production
- bulk-memory-edit
需要严格限制。
skill-registry.md 的作用，就是让能力分配可控。
6. user-profile.md：统一用户画像
user-profile.md 记录所有 Profile 都应该知道的长期用户偏好。
比如：
- 用户偏好中文交流；
- 用户喜欢直白、清晰、有判断力的解释；
- 用户常用 Obsidian；
- 用户喜欢 Markdown；
- 用户长期关注 Hermes、LLM Wiki、OPC、多 Agent 协作。
这和每个 Profile 自己的 USER.md 不一样。
Profile 里的 USER.md 是单个角色对用户的理解。
system/user-profile.md 是整个系统共享的用户画像源头。
六、projects：长期项目层
system 负责全局管理。
projects 负责具体项目。
每个长期项目都应该有自己的项目空间。
比如：
projects/twitter-growth/projects/vibe-coding/
每个项目空间建议包含：
AGENTS.mdcontext.mdtasks.mdlog.mddecisions.mdinbox/outputs/
1. AGENTS.md：项目规则
AGENTS.md 说明在这个项目下，Agent 应该如何协作。
它记录：
- 项目目标；
- 项目定位；
- 工作规则；
- 文件写入边界；
- 禁止事项。
比如 Twitter Growth 项目的 AGENTS.md，可以规定：
- 追热点时必须判断是否符合账号长期定位；
- Researcher 的中间材料写入 inbox/；
- Writer 的结构方案写入 inbox/；
- Builder 的正式产出写入 outputs/；
- Coordinator 负责更新 tasks.md 和 log.md。
AGENTS.md 回答的是：
- 这个项目应该怎么做？
2. context.md：项目背景
context.md 是项目说明书。
它回答：
- 这个项目是什么？
- 为什么做？
- 目标是什么？
- 当前阶段是什么？
- 核心约束是什么？
任何 Profile 进入项目之前，都应该先读 context.md。
否则它不知道自己正在参与什么项目。
3. tasks.md：项目任务池
tasks.md 记录当前项目的任务状态。
它通常分为：
- Doing
- Todo
- Done
每个任务最好写清楚：
- 任务编号；
- 负责人；
- 当前状态；
- 依赖关系；
- 输出路径。
这样 Coordinator 才能管理项目进度，不会让任务散落在聊天记录里。
4. log.md：项目推进记录
log.md 是单个项目的推进日志。
它记录这个项目每天或每次迭代发生了什么。
比如：
- Researcher 完成了热点研究；
- Writer 完成了文章大纲；
- Builder 完成了登录页草稿；
- Coordinator 更新了任务状态。
注意：
project log 和 agent-log 不一样。
- project log 记录某个项目的推进过程；
- agent-log 记录所有 Profile 的全局行为。
5. decisions.md：项目决策
decisions.md 记录项目已经确定的方向。
它的作用是防止系统反复摇摆。
比如：
- 内容定位是什么；
- 产品 MVP 范围是什么；
- 技术栈选什么；
- 哪些方向已经明确不做。
长期项目最怕每次对话都重新决策。
decisions.md 就是为了避免这个问题。
6. inbox：中间材料
inbox/ 放半成品、草稿、研究材料和未确认结论。
比如：
- 热点研究；
- 竞品笔记；
- 大纲草稿；
- 粗糙想法；
- Subagent 输出。
这些东西还没有被确认，所以不能直接进入 pages/ 或 outputs/。
inbox/ 的作用是承接不确定性。
7. outputs：正式产出
outputs/ 放已经确认可以交付或使用的内容。
比如：
- 最终文章；
- 推文草稿；
- 代码结果；
- 产品文案；
- Demo 文件。
可以简单理解为：
- inbox 是中间材料。outputs 是正式产出。
七、pages：通用知识层
pages/ 放跨项目可复用的方法论。
比如：
research-methods.mdwriting-methods.mdbuilding-methods.mdcoordination-methods.mdcontent-growth-system.mdproduct-building-system.md
什么内容可以进入 pages/？
必须满足三个条件：
- 跨项目可复用；
- 不是临时结论；
- 经过验证或抽象。
比如：
- 内容项目不能只追热点，还要判断热点是否符合长期定位。
这可以进入 pages/。
但：
- 今天某个 AI Agent 话题很火，可以写一条推文。
这不能进入 pages/。
它应该进入某个具体项目的 inbox/。
pages/ 是知识层，不是临时笔记层。
八、raw：原始资料层
raw/ 放原始资料。
比如：
- 论文；
- 文章；
- 网页快照；
- 数据表；
- 会议记录。
raw/ 的原则是：
- 只读不改。
它是事实来源，不是加工层。
研究材料可以从 raw/ 中提取，但不要直接改 raw/。
否则你会失去原始证据。
九、assets：素材附件层
assets/ 放非文本素材。
比如：
- 图片；
- 架构图；
- 截图；
- 封面图；
- 图表。
如果文章需要引用图片，就放到：
assets/images/
如果是系统架构图，就放到：
assets/diagrams/
如果是操作截图，就放到：
assets/screenshots/
十、archive：归档层
archive/ 放不活跃、过期或废弃的内容。
比如：
- 旧项目；
- 旧草稿；
- 废弃方案；
- 过期资料。
不要轻易删除重要内容。
先归档。
长期系统不是靠“删干净”维持秩序，而是靠“分层和归档”维持秩序。
十一、Profile 层和 Wiki 层的边界
到这里，我们可以清楚看到：
Profile 层和 Wiki 层有明显边界。
Profile 负责：
- Agent 是谁；
- Agent 怎么运行；
- Agent 有什么经验；
- Agent 有什么技能。
Wiki 负责：
- 所有 Agent 的项目；
- 共享知识；
- 原始资料；
- 任务状态；
- 决策记录；
- 最终产出。
一句话：
- Profile 是员工。Wiki 是公司系统。
如果你把项目状态写进 Profile，记忆会污染。
如果你把角色经验写进项目，知识会分散。
如果你把临时材料写进 pages，长期知识会变脏。
所以，分层不是形式主义。
- 分层就是系统稳定性的来源。
十二、实际使用时怎么运转？
讲到这里，很多人会有一个现实疑问：
- 这套架构听起来很好，但日常用起来会不会很麻烦？
主要有两个问题：
- 多 Profile 是不是要频繁手动切换？
- 多 Profile 协作会不会很耗 Token？
先说第一个。
多 Profile 确实需要切换，但不是乱切。
判断标准很简单：
- 换项目，不一定换 Profile。换角色，才需要换 Profile。
比如 Researcher 上午研究 Twitter 热点，下午研究 Vibe Coding 竞品，这两个都是研究任务，不一定要换 Profile，只需要切换 Project context。
但如果从“查资料”变成“写最终稿”，那就应该从 Researcher 切到 Writer。
所以，多 Profile 协作的关键不是频繁切窗口，而是清楚知道：
- 当前任务该交给哪个角色。
这时，Web UI 的作用就很明显了。
如果全部靠终端来切 Profile，使用成本会比较高。
而 Web UI 更像一个控制台，你可以在里面更方便地切换：
- Coordinator
- Researcher
- Writer
- Builder
终端更适合搭系统、改配置、调试路径。
Web UI 更适合日常协作、切换 Profile、继续会话。
可以简单理解为：
- 终端是施工现场。Web UI 是办公室。Wiki 是公司文档。
第二个问题是 Token 成本。
多 Profile 协作一定会比单 Agent 更耗 Token。
因为每个 Profile 都需要读取自己的身份、项目上下文和 Wiki 资料。
解决方式不是放弃多 Profile，而是做分层：
- 主模型负责复杂推理；
- 副模型负责总结、整理、归档；
- 简单任务可以交给本地模型；
- Wiki 负责保存长期上下文，避免每次重复粘贴。
也就是说：
- 不要让模型记住所有东西。要让模型按需读取正确的信息。
这样，多 Profile + Wiki 才能真正跑得起来，而不是变成一个高成本玩具。
十三、这一篇的核心结论
Hermes 的高级用法，不是多开几个 Agent，而是用多 Profile 做角色分工，用 Wiki 做共享记忆。
这套系统的目标不是复杂，而是让一个人也能管理一支稳定协作的 Agent 团队。
十四、下一步我要做什么？
后续，我们来：
- 搭建一个体系；
- 用 Web UI 管理多个 Profile；
- 用主副模型和本地模型节省 Token。