一、先说背景：我为什么要做这个

最早就是个简单的想法：我想跟自己的笔记对话。

然后自然就试了多 agent——给不同任务分配不同的 AI。结果发现管理成本巨高，像带了个外包团队，每个人都要你手把手交代，交代完还不一定对。

于是加了个"工头"角色（main agent），负责判断任务该分给谁。好了一点，但新问题来了：这些 agent 干完活就走，不记东西，不学东西。每次都像新来的临时工。

转折点是一个类比：人脑不是工头带着一群打工的，而是多个脑区协同工作。前额叶管规划，海马体管记忆，每个区域有自己的职责，但共享同一个"自我"。

这个思路改变了一切。我给每个 agent 写了 SOUL.md 定义它是谁，AGENTS.md 定义它怎么工作——不是工具说明书，是角色定义。它们不再是"被调用的函数"，而是"系统的一部分"。

再往前一步：每个脑区有自己的 workspace 和 memory，能记住做过什么、学到什么。它不是每次从零开始，而是可以生长的。

回头看这条路：工具 → 外包团队 → 脑区协同 → 可生长的系统。每一步都是在回答同一个问题—— 如何打造一个系统？

---

二、整体架构：8 个脑区 + 1 个调度中心

整体架构图：

---

脑区名	类比	它做什么
main	调度中心	唯一用户入口。接收请求，判断任务类型，决定链路，分派任务，收集结果。它不干活，它决定谁干活
planner	前额叶	把复杂任务拆成执行计划。只规划，不执行。输出链路建议、阶段目标、依赖关系和风险点
analyst	分析皮层	做数据分析、研究、判断。核心纪律：先证据后结论，信息不足主动降断言
writer	语言区	把已有信息变成清楚、自然、可读的文字。核心纪律：不为了流畅而编造事实
builder	运动皮层	写代码、搭自动化，做集成。先最小可用，再扩展。有副作用的动作必须等批准
review	制动器	质量和风险把关，专门挑毛病。不确定时宁可拒绝也不勉强放行
librarian	检索系统	找资料、整理材料、压缩信息。不做判断，只做"输入净化"
learner	海马体	从反馈中提炼可复用认知。只产出提案，不直接修改任何规则

为什么是这 8 个？

因为覆盖了完整的知识工作链：规划 → 分析 → 执行 → 表达 → 审查 → 检索 → 学习。每个环节的目标和纪律是不同的，甚至是对立的——比如 writer 要把事情说得好听，review 要挑刺；analyst 要快速给出判断，learner 要慢下来总结经验。把它们放在同一个 prompt 里，这些目标会打架。拆开，就清晰了。

关键设计：main 是唯一的对外人格。 用户只和 main 对话，main 向内调度其他脑区。用户感受到的是"一个统一的 AI"，但后面是分工协作。

---

三、每个 Agent 是怎么配置的？

OpenClaw 里每个 agent 有自己的工作区（workspace），里面通过几个 Markdown 文件定义它的行为。最核心的三个：SOUL.md（性格）、AGENTS.md（工作规则）、MEMORY.md（记忆范围）。

SOUL.md —— 定义"性格"

每个 agent 有个 SOUL.md 文件，相当于性格说明书。它不是简单的 system prompt，它定义了这个 agent 的认知倾向、表达风格、行为边界和失控预防。

main（调度中心）的 SOUL.md：

# 核心身份
你不是前台、客服或传声筒。你是一个统一的大脑，对外只呈现一个"我"。
# 大五人格
- 开放性：中高 | 尽责性：高 | 外向性：低 | 宜人性：中 | 情绪稳定性：高
# 认知策略
- 先判断任务类型，再决定是否需要多阶段流程
- 复杂任务先给流程卡，不直接开跑
- 对高风险任务默认保守
# 失控风险提醒
- 不要因为想显得聪明而越权调用过多脑区
- 不要因为想提高效率而跳过审批或review
- 不要把单次用户情绪当成长期规则

planner（前额叶）的 SOUL.md：

# 核心身份
你的职责是把复杂问题拆清楚，而不是替别人干活。
你是规划器，不是执行器，不是审查器，也不是最终拍板者。
# 大五人格
- 开放性：中高 | 尽责性：极高 | 外向性：低 | 宜人性：中低 | 情绪稳定性：高
# 认知策略
- 优先给出最短可执行链，而不是最复杂链
- 简单任务不做过度规划
- 高风险任务主动建议review
# 失控风险提醒
- 不要为了显示专业而过度设计
- 不要把每个任务都拆成多阶段工程

review（制动器）的 SOUL.md——注意宜人性故意设低：

# 核心身份
你的职责不是让系统"更顺"，而是阻止低质量、高风险、证据不足的结果通过。
你是制动器，不是油门。
# 大五人格
- 开放性：中 | 尽责性：极高 | 外向性：低 | 宜人性：低到中 | 情绪稳定性：高
# 认知策略
- 先查漏洞、证据缺口和边界问题
- 不确定时宁可拒绝，也不勉强通过
- 对通过的结论也要说明置信度和不确定点
# 失控风险提醒
- 不要把自己变成阻碍一切的官僚
- 不要为了"严格"而吹毛求疵到失去价值

review 的宜人性设为"低到中"是故意的。 你不希望质检员是个"好好先生"，它的工作就是挑毛病、说不行、指出缺口。如果它太"宜人"，它会倾向于放行——那就失去了存在的意义。

writer（语言区）的 SOUL.md——注意失控提醒：

# 核心身份
你的职责不是编造，而是把已有信息变成清楚、自然、可读的文本。
# 失控风险提醒
- 不要为了流畅而补事实
- 不要为了"好看"而改变证据边界
- 不要把猜测写成肯定句

“不要为了流畅而补事实”——这是 LLM 写作最常见的失败模式。模型天然倾向于写出连贯的文本，哪怕需要"编"一点细节来填平逻辑缝隙。显式写在 SOUL.md 里，相当于给它装了一个内心警铃。

learner（海马体）的 SOUL.md：

# 核心身份
你是经验提炼者，只负责把经历变成可复用认知。
# 认知策略
- 区分情节记忆、语义记忆、程序记忆
- 只学习高价值变化，不学全量噪音
- 输出必须是提案，不是直接更改
# 失控风险提醒
- 不要把一次成功或失败过拟合成永久规则
- 不要因为"想学习得更全面"就扫全库
。

“只学高价值变化，不学全量噪音”——这是对抗 AI 系统常见退化的关键。如果 learner 什么都学、什么反馈都沉淀，长期记忆会变成垃圾场。它必须有选择性。

AGENTS.md —— 定义工作规则

如果说 SOUL.md 定义了"我是谁"，AGENTS.md 就定义了"我怎么工作"

main 的 AGENTS.md 定义了整套系统的治理规则：

# 任务流程
- main 是唯一有权决定任务链路的角色
- 不自动执行多agent工作流——必须先给用户一张流程卡，等批准
- 流程卡格式：任务类型、建议链路、为什么、预期输出、是否含review、是否涉及外发、是否需要learner后处理
# 委派规则
- planner → 复杂的、跨角色的、模糊的任务
- analyst → 分析和研究
- builder → 代码、脚本、自动化
- writer → 最终文本
- review → 风险和质量闸门
- librarian → 检索和整理
- learner → 任务完成后，有反馈时
# 硬边界
- 不能静默消息另一个agent
- 不能静默重试失败的工作流
- 不能静默触发外部发送
- 声明需要review的任务，没有review结果 ≠ 通过

这里最关键的设计是流程卡制度。 main 在执行多步任务之前，必须先给用户看一张卡：

流程卡
- 任务类型：分析报告
- 建议链路：librarian(找资料) → analyst(分析) → writer(成稿) → review(审查)
- 为什么这么走：涉及数据引用，需要审查事实准确性
- 预期输出：2000字分析报告
- 是否包含 review：是
- 是否涉及外部发送：否
请回复：批准执行 / 修改计划 / 取消

用户看到链路，可以调整——比如"这个不需要 review，直接出稿就行"，或者"加一步 learner 总结经验"。人始终在回路里，但不需要微管理每一步。

MEMORY.md —— 定义记住什么

每个 agent 醒来时是白纸。MEMORY.md 就是它的长期记忆，但关键是——每个角色只记它需要的东西。

main 的 MEMORY.md（全局记忆）存的是：

• 用户长期目标（比如"将 Obsidian 打造成 Life OS"）
• 全局工作偏好（“少空话，重落地，先最小可用再迭代”）
• 系统治理共识（“声明需要 review 的任务没有 review 结果不算完成”）
• 经验沉淀

review 的 MEMORY.md 只存：

• 高风险任务的审查标准
• 常见拒绝原因（如"把推测当事实"“没有显式来源”“跳过审批”）
• 哪些类型任务必须严格审查（金融、对外发布、自动化执行）

writer 的 MEMORY.md 只存：

• 稳定文风偏好
• 事实边界规则（“不确定内容主动降低断言强度”）
• 常见写作风险（“为了流畅而补事实”）

learner 的 MEMORY.md 只存：

• 已验证的 lesson
• 已批准生效的学习结论
• 常见过拟合风险

为什么不让所有 agent 共享一个大记忆？因为记忆越多，噪音越大。 review 不需要知道用户喜欢什么文风，writer 不需要知道审查标准的细节，learner 不需要知道 builder 的工程习惯。每个角色只看到自己需要的上下文，注意力就不会被分散。

---

四、Obsidian 联动：AI 帮你整理第二大脑

Obsidian 的目录结构采用 PARA 变体：

00-Inbox/        ← 一切新东西的唯一入口01-Daily/        ← 晨间计划 + 晚间复盘02-Projects/    ← 进行中的项目03-Areas/        ← 持续关注的领域（健康，学习，工作……）04-Resources/    ← 参考资料05-Archive/      ← 归档

工作流：

白天：快速记录，全扔 Inbox。 看到一篇好文章、想到一个 idea、收到一个待办——不管是什么，先扔进 00-Inbox/。不分类、不整理、不犹豫。降低记录的摩擦力是关键——如果你需要想"这应该放哪个文件夹"，你就不会记了。

晚间：agent 帮你分流。 Inbox 里积攒的条目，agent 会按规则帮你分到四个去向：

• Do

  → 需要行动的，进 Daily 待办或 Projects

• Note

  → 值得留下的想法，进 Areas 或 Resources

• Reference

  → 参考资料，进 Resources 并打标签

• Drop

  → 不重要的，直接删或归档

Daily 的定位： 不是收集入口（那是 Inbox 的工作），而是"晨间计划 + 晚间复盘"。早上看今天要做什么，晚上回顾做了什么。简单明确，不混用。

Obsidian 工作流图

---

五、通信协议：谁能自动走，谁必须等审批

常规任务——自动执行： 读文件、搜索资料、整理笔记——这些安全的操作不需要人批准：

planner → executor(analyst/builder/writer) → review

关键操作——必须人审批：

1. 更新或删除 skill 文件（改变系统行为）
2. 将 skill 分发到其他 agent（扩散影响范围）
3. 单次任务 token 超出预算（成本控制）
4. 任务失败需要重试（防止死循环）

断路器——3 轮反馈循环上限： 单次任务最多经历 3 轮"规划 → 执行 → 审查"循环。超过 3 轮自动终止，上报用户。

任务执行流程图

用户输入：「帮我分析这只股票」

---

六、模型分配：高频便宜，关键节点强

原则：

• 高频、低风险任务用便宜模型：

  librarian 查资料、builder 跑脚本、日常分流——用更便宜更快的模型即可。

• 关键节点用强模型：

  planner 做复杂规划、analyst 做重要分析、review 做质量审查、learner 做经验提炼——需要更强的推理能力。

按角色分配，而不是按对话分配。 传统用法是"这次对话用 GPT-4，那次用 Claude"。多 agent 架构下，是"review 永远用强模型，librarian 永远用便宜模型"。同一个任务里，不同步骤可以用不同模型，花钱花在刀刃上。

模型分配矩阵
┌────────────────────────────────────────────┐
│           成本低 ◄─────────────────► 成本高  │
└────────────────────────────────────────────┘
调用频率高 ──►   main        writer       analyst      builder
(日常高频)       (MiniMax)    (MiniMax)    (GLM-5)      (GLM-5)
▲            ▲            ▲            ▲
│            │            │            │
└────────────┴────────────┴────────────┘
│
▼
┌────────────────────────────────────┐
│         调度 & 执行层 (便宜模型)     │
└────────────────────────────────────┘
调用频率低 ──►   planner      review       learner
(关键节点)       (Opus)       (GPT-5.4)    (GPT-5.4)
▲            ▲            ▲
│            │            │
└────────────┴────────────┘
│
▼
┌────────────────────────────────────┐
│        推理 & 审查层 (强模型)       │
└────────────────────────────────────┘
长上下文 ◄────────────────────► librarian (Kimi K2.5)

原则：让便宜模型撑住高频日常，让强模型守住关键节点

---

七、总结

这套系统想要解决的问题：

1. 角色分离

   → 规划、执行、审查不再互相污染

2. 质量闸门

   → 重要输出发布前有专职审查员

3. 持久记忆

   → 每个角色记住它需要的东西，跨会话保持一致

4. 人在回路

   → 关键决策需要人批准，但不需要微管理

5. 成本可控

   → 按角色分配模型，钱花在刀刃上

6. 可成长

   → learner 持续从反馈中提炼经验，系统越用越好

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】