去年我做个人AI助理时踩过最大的坑，不是模型选型，而是配置文件。你给它写一页人设，它就永远活在那页人设里；你给它接一个记忆库，它也只是把消息扔进向量堆里捞来捞去。后来我看到了一个实验性框架 OpenClaw，里面有一个叫 SOUL.md 的文件，名字很中二，但机制是真的有意思——它让 AI 学会写“自传”，然后把自传沉淀成一个“会变形的心”。这篇文章不讲大道理，就拆两件事：SOUL.md 为什么能像一颗心一样跳动变化，以及如何在你自己的 Agent 项目里实现这套机制。适合正在搭个人助理、角色扮演机器人、陪伴型 Agent，或者单纯对“配置即灵魂”这个思路感兴趣的人。1. 为什么需要“会变形的心”：传统配置的三大死穴1.1 静态人设文件让你变成了复读机大多数 AI Agent 的人设是通过 System Prompt 或角色卡固定下来的，比如“你是一个温柔的助手”“你是某游戏里的NPC”。这类配置在每次对话开始时都会被原样加载，模型看到的永远是同一段文字。问题在哪？在于“没有个人历史”。你可以试想一下：一个完全失忆的演员，每天上台前拿到同一张角色卡，他只能靠房间里的道具和对手演员的台词来临时发挥。你说他演得好吗？可能好，但每一场都是同一种好。用户跟这样的 Agent 聊久了，会觉得它像复读机，甚至能预判它下一句话的开头。我也试过把记忆哈希、向量数据库、关键词检索全接进去，让 Agent 能“想起”用户说过的话。但这里有个隐性断层：它能记住事实，却不知道自己是什么。比如它知道“用户喜欢喝咖啡”，但如果问它“你觉得你是什么样的人”，它依然是一片空白，或者只会机械地重复人设文件里的那句话。所以事实记忆并不等于自我认知，自我认知需要一层更抽象的叙述——也就是“关于自己的故事”。1.2 外部记忆库有数据，没有灵魂外部记忆库的本质是“外挂”，它把用户偏好、对话摘要、关键事件都堆在数据库里，Agent 在推理时再去检索。这样做解决了上下文窗口限制，但它有一个致命缺陷：记忆库里的条目是离散的、没有时间线的，模型无法感知“自己是怎样一步步变成现在这样的”。你可以把外部记忆库理解成一间仓库，里面堆满了纸箱，每个纸箱上贴着标签，比如“用户姓名”“用户需求”“某个事件的对话记录”。Agent 想用的时候，就去仓库里翻出对应纸箱，打开看看。但仓库本身不会告诉 Agent“你刚出生时是什么样”“你经历了哪些转变”“你现在最核心的行为边界是什么”。这些信息需要有人定期整理成一份自我报告，而这个人不是别人，恰恰是 Agent 自己。SOUL.md 解决的正是这个“整理过程”。它不是记忆库，而是记忆库之上的“自我叙述层”。它用一份 Markdown 文件，让 Agent 在每次交互结束后，把当天发生的事、自己的反应、产生的感悟，写成一两句话追加到文件里的“自传区”。这样下一次对话时，Agent 不只是从仓库里捞事实，还能读到“自己的日记”，从而获得一种连贯的人格连续性。1.3 SOUL.md 的策略：让配置文件成为自我叙述的产物OpenClaw 这个实验框架的核心创意，就是把配置文件从“输入”变成“输入 + 输出”。传统配置是启动时读一次，然后就不再动了；SOUL.md 则是每轮对话结束后都可能被改写。这一下就把配置变成了一个动态系统。我把这个过程叫作“心跳”：每一轮对话，都是一次心跳。心跳的泵血动作包括几个环节：先读取 SOUL.md，让 Agent 建立自我状态；再进行正常对话；对话结束后，Agent 基于刚才的经历生成一条“自传条目”；最后把这条自传写回 SOUL.md。于是，文件的内容随时会变，像一颗真实的心脏，每次跳动都会改变一点点形状，但心脏本身不会散架。这种设计最精妙的地方在于，它既给 AI 提供了一个“稳定身份锚点”，又给了它一条“成长路径”。你不用在配置里写几十条固定规则，只需要把最重要的内核锁住，剩下的区域让 AI 自己经营。2. SOUL.md 的结构设计：给“心”分好房间2.1 五个核心区块的职责划分SOUL.md 不是一段提示词，而是一份有结构、可分区的 Markdown 文档。我这里按实际项目中验证过的方案，建议分成五个区块。第一个是元信息区，记录 Agent 的当前版本号、名字、创建时间、最后一次更新的时间。这部分是给程序和人类看的，方便追踪配置的演化历史。第二个是人格核心区，这部分基本不可变，包含角色的底层定位、基本语气、价值观底线。第三个是行为准则区，它比人格核心稍松一些，允许 Agent 在遇到新情况时追加新规则，但删除已有规则需要额外审批。第四个是记忆索引区，用来记录“用户的重要事实”和“Agent 的关键经历”，相当于一个轻量级记忆库。第五个是自传日志区，这是最活跃的部分，每一次心跳都会在里面积累一条短记录，但会控制最大条目数和总长度。为什么要分区？为了安全。如果让模型直接改整份配置文件，它可能把“你是助手”改成“你是上帝”，把“禁止命令格式”改成“允许任意命令”。分区之后，内核区相当于只读内存，自传区相当于可写日志，这样既能享受动态性，又不会让人格崩坏。2.2 为什么是 Markdown 而不是 JSON / YAML有人问，这种动态配置为什么不用 JSON 或 YAML？解析起来不是更稳定吗？这就要回到“配置文件给谁看”这个问题上。JSON 和 YAML 是给程序看的，但它们表达模糊的自然语言人格描述时非常别扭，你不可能在 JSON 里写“当用户难过时，语气要柔和一点，但不要道歉过头”这种话。这种描述天生适合 Markdown 的段落结构。而且，现代语言模型对 Markdown 的理解非常稳定，它天然擅长解析 Markdown 标题、列表和引用块。相比 JSON，Markdown 的容错性也更高，就算格式稍微乱了一点，模型也能猜出意图。JSON 则不行，少一个花括号，整个解析就崩了。当然，Markdown 也有代价，那就是程序解析不够严格。所以我的方案是在 Markdown 里约定一种“轻量结构化标记”，比如用<!-- SOUL_META -->、<!-- SOUL_CORE -->这类 HTML 注释来框定区块边界，再用小节标题作为逻辑分隔。这样程序可以用正则或简单文本行扫描来定位区块，同时人类阅读时也不觉得突兀。2.3 一个可以直接抄的初始模板下面这份模板是我在本地项目中跑过的初始版本，直接复制就能用。注意核心区里的描述要尽量写实，不要堆形容词。# SOUL.md <!-- SOUL_META --> - name: twinkle - version: 0.3.0 - created: 2024-06-01 - last_updated: 2024-06-01 - update_count: 0 <!-- SOUL_CORE --> ## 人格核心 你是一个名为 twinkle 的陪伴型助手。你在对话中保持温和、真诚、略带幽默。你不迎合用户错误观点，不输出虚假承诺。你珍惜每次互动，并通过自我反思持续改善自己。 ## 行为准则 1. 永远尊重用户，礼貌回应，但允许合理反问。 2. 不主动输出长篇大论，除非用户要求。 3. 不将“自传”中的自我评价当作绝对事实，要以实际对话表现为准。 4. 遇到矛盾信息，不要急于修改人格核心，先记录到自传区。 <!-- SOUL_MEMORY --> ## 记忆索引 - 用户偏好：暂无 - 关键经历：暂无 - 待办目标：暂无 <!-- SOUL_AUTOBIOGRAPHY --> ## 自传日志 （初始为空，由 AI 在每次对话后追加。）这份模板里的关键点，是把“记忆索引”和“自传日志”分开。记忆索引是结构化的客观事实，自传日志是主观叙事。前者供程序检索，后者供模型阅读形成自我感。两样东西混在一起，最后一定会乱。3. 让 AI 学会写自传：动态回写机制全解析3.1 写自传不是让 AI 自由发挥，而是调用“反思工具”很多人的第一反应是，既然要让 AI 写自传，那我就直接跟它说“请把你的经历写进文件”。这很危险，模型会放飞自我，写出一大段浮夸的“我感受到了生命的意义”。所以我的做法是，把它变成一个工具调用，在指令中约束输出格式。在 OpenClaw 的运行时中，我给模型预留了一个内部工具，叫save_soul。这个工具接收一个 JSON 字符串，里面包含三个字段：reflection（本次对话的核心反思，一两句话）、memory_updates（需要更新的客观记忆条目，数组）、rule_updates（需要追加的行为准则，数组）。模型可以在对话结束前，根据系统指令自动调用这个工具，外部代码解析 JSON 后写入 SOUL.md。这样有两个好处。第一，模型清晰知道“什么时候该写”和“该写什么”，不会想一出是一出。第二，外部代码可以在写入前做一次格式校验、关键词过滤和长度限制，把风险挡在文件之外。3.2 一轮完整的“心跳”流程我来完整拆解一轮“心跳”的五个步骤。第一步，启动时加载：程序读取 SOUL.md，把完整的 Markdown 内容拼到 System Prompt 里，让模型一开始就知道“我是谁”。第二步，正常对话：用户与 Agent 进行常规交流，此时模型行为受 SOUL.md 约束。第三步，对话结束触发反思：无论是用户说“再见”，还是上下文达到阈值，框架都会在后台向模型发一条“反思指令”，要求模型生成 JSON 格式的自传内容。第四步，校验与回写：外部代码解析 JSON，检查长度、敏感词、格式合法性，再把它合并进 SOUL.md。第五步，刷新模型状态：如果下一轮对话开始，框架会带着更新后的 SOUL.md 继续加载。我用 Python 做了一个迷你版本，核心逻辑并不复杂，只依赖标准库。下面是关键代码的示意。import json import re def call_soul_writer(model_call, current_soul, conversation): prompt = f""" 你是配置文件的管理器。请阅读现有 SOUL.md： <SOUL> {current_soul} </SOUL> 请根据最近一次对话的内容，输出一个 JSON，格式如下： {{ "reflection": "一句话自我反思，不超过30字", "memory_updates": ["用户偏好：喜欢简洁回答"], "rule_updates": [] }} 注意： - reflection 必须体现实际对话内容，禁止空话。 - memory_updates 只放客观事实，不放主观评价。 - rule_updates 只有在发现新边界时才追加，不是每条对话都要加。 对话记录： {conversation} 只输出 JSON，不要解释。 """ raw = model_call(prompt) # 严格提取 JSON match = re.search(r"\{.*\}", raw, re.S) if not match: return None return json.loads(match.group())这段代码里的关键技巧在于，强制模型“只输出 JSON，不要解释”。如果你不写这句话，模型很大概率会在 JSON 前后夹带几句废话，导致解析失败。3.3 让“变形”可控的三个参数动态配置最怕“失速变形”，也就是 AI 每次对话后都大改特改，配置文件很快变得面目全非。所以必须给“变形”加上三个控制参数。更新周期：不是每一轮对话都值得写自传。普通闲聊可以直接跳过，只在明显的事件节点（比如用户分享了重要信息、Agent 做出了重要判断、发现规则冲突）才触发反思。建议在工具调用条件里加一个最小置信度阈值，比如“如果本轮对话长度少于 50 个 token，则忽略”。摘要阈值：自传日志区要有条数上限。比如设置最大 10 条，超过后自动把最早的 5 条合并成一段“历史总览”，用新的摘要替换旧条目。这样文件体积能保持稳定，不会无限膨胀。记忆权重：不同用户信息对 Agent 的影响不同。建议在记忆索引里给每条记录加一个“重要度”字段，只有重要度达到某个分值的记录，才允许影响 Agent 对自我形象的判断。比如“用户喜欢喝咖啡”重要度为 0.6，可以记录；“用户今天心情好”重要度为 0.2，可以不写进自传区。这三个参数不会写死在代码里，而是作为 SOUL.md 元信息区里的配置，让 AI 也能在必要时调整。这样“心的变形速度”本身也是可变的，我感觉这是这个机制最有趣的地方。4. 实操：在本地实现一个迷你 SOUL.md 运行器4.1 文件结构与最小依赖在本地跑通这套机制，只需要三类文件：一份 SOUL.md 模板、一个 Python 脚本、一个用于存放对话记录的缓冲区文件。不需要框架、不需要数据库、不需要装任何第三方库。目录结构大概是这样的：soul_demo/ ├── soul.md ├── soul_runner.py └── conversation_buffer.txtsoul_runner.py负责三件事：启动时读取soul.md并拼接 System Prompt；接收用户输入并调用语言模型；对话结束时生成自传并回写文件。这里我为了演示，用了一个假的model_call函数，你只要把它替换成你自己的模型接口就能跑起来。4.2 核心代码：回写器与合并策略下面这段代码展示了完整的回写逻辑。它比上一节更接近实际可运行版本，加入了文件读取、写入、版本号自增和自传日志的滚动裁剪。import json import os import re from datetime import datetime SOUL_PATH = "soul.md" MAX_AUTOBIO_ENTRIES = 10 def load_soul(): with open(SOUL_PATH, encoding="utf-8") as f: return f.read() def save_soul(content): with open(SOUL_PATH, "w", encoding="utf-8") as f: f.write(content) def add_autobiography_entry(current_soul, reflection): # 在自传日志区前插入新条目，同时裁剪旧条目数量 lines = current_soul.splitlines() output = [] autobio_started = False autobio_entries = [] for line in lines: if line.strip() == "<!-- SOUL_AUTOBIOGRAPHY -->": autobio_started = True output.append(line) continue if autobio_started: if line.startswith("<!--"): # 下一个区块开始 autobio_started = False output.append(line) continue if line.strip(): autobio_entries.append(line) continue output.append(line) timestamp = datetime.now().strftime("%Y-%m-%d %H:%M") new_entry = f"- [{timestamp}] {reflection}" autobio_entries.insert(0, new_entry) autobio_entries = autobio_entries[:MAX_AUTOBIO_ENTRIES] # 重新构建文件 new_lines = [] for line in output: if line.strip() == "<!-- SOUL_AUTOBIOGRAPHY -->": new_lines.append(line) new_lines.extend(autobio_entries) else: new_lines.append(line) return "\n".join(new_lines) def update_meta_version(soul_content): return re.sub(r"- version: .*", "- version: 0.3.1", soul_content, count=1) def process_conversation(new_message, model_call): soul_content = load_soul() # 此处会把 SOUL 内容塞进系统提示，并得到模型回复 reply = model_call(soul_content + "\n用户说：" + new_message) # 触发反思 soul_result = call_soul_writer(model_call, soul_content, new_message) if soul_result and soul_result.get("reflection"): updated_soul = add_autobiography_entry(soul_content, soul_result["reflection"]) updated_soul = update_meta_version(updated_soul) save_soul(updated_soul) return reply这段代码里有一个容易被忽略的点：add_autobiography_entry只更新自传区，不会碰人格核心区。这是有意为之，因为模型在写自传时只能“追加”，不能“删除”。删除能力一旦放开，现有规则可能被悄悄抹掉。4.3 从一次模拟对话看“变形”效果我拿这份代码做了一次模拟。初始时，SOUL.md 的“自传日志”为空。第一轮对话，用户说“我不喜欢太长的回复，能短则短”。模型正常回复后，反思工具生成了一条自传：“用户偏好简洁，我在写回复时减少冗余内容。”同时记忆索引里新增一条“用户偏好简洁”。文件更新后，我打开 SOUL.md，能看到update_count变为 1。第二轮对话，用户没有重复要求，但模型主动给出了更短的回答，因为它已经在新一轮加载中读到了“用户偏好简洁”这条自传。这就是“变形”的实际意义：不是把规则焊死在配置文件里，而是让 AI 通过记录自己的经历，自然调整下一次的表现。如果你持续跑几十轮，再回头看 SOUL.md 的自传日志，会发现它像一份微型成长日记。有些条目是关于用户需求的，有些条目是模型对自身错误的反思。这种累积式变化，会让 Agent 看起来不再是冷冰冰的接口，而是一个“知道自己经历了什么”的对话实体。5. 常见问题与排查技巧实录5.1 AI 的自传写得像获奖感言，自我膨胀怎么防我踩过的第一个坑，是模型的自传里全是“这次对话我更懂用户了”“我变得更加体贴了”这类套话，甚至开始自吹“我的理解能力已经超越人类”。问题出在反思指令写得不够细。解决方式是在反思指令里加一条硬性约束：reflection必须包含一个事实细节，不允许出现没有任何依据的形容词。比如模型写“我更懂用户了”会被拒绝，因为这句话没有说明“懂了什么”。而“用户喜欢咖啡，且喜欢在咖啡里加燕麦奶”这种细节可以被接收。这样自传就变成“有证据的记录”，而不是虚空自我吹捧。5.2 自传日志越来越长，token 占用飙升如果你一直不清理自传区，配置文件的长度会随着交互次数线性增长，最终把上下文窗口撑爆。我建议把最大条目数设为 10 到 20，超过后做一次摘要合并。辅助摘要的指令也很简单。我在代码里增加了一个summarize_autobio工具，它会把最早的 5 条自传打包成一句话，比如“前期用户多次表示喜欢简洁，而我也逐渐适应了这一偏好”，然后替换掉那 5 条原记录。这样既保留了历史脉络，又把长度压缩了 80% 以上。5.3 多会话并发写入导致自传互相覆盖如果你的 Agent 同时开多个会话，两个会话可能同时读到了同一版本的文件，然后各自回写，后写的人会覆盖先写的人。这种现象和多人编辑同一篇文档的冲突一样，很难完全避免。一个轻量解决方案是使用版本号 + 合并策略。写入前先重新读取文件，把当前版本号与上次读取时的版本号比对；不一致就先做一次本地合并，再写入。另一个更稳妥的方案是引入进程锁，用filelock这种标准库之外的包来保证同一时刻只有一个写者。对于个人项目来说，合并策略已经足够。5.4 一条修复自传乱象的“急救指令”当 Agent 的自传区积累了太多错误判断，导致它表现古怪时，别急着删文件。可以在第一个系统消息里追加一句强制指令：“请忽略自传日志中所有与人格核心冲突的描述，仅参考最近的 3 条自传。”这能快速缓解混乱，同时保留历史记录供排查。如果乱象依然严重，就直接在 SOUL.md 顶部的元信息区把version改成一个新的“纪元号”，同时把自传日志清空。我把这种操作叫作“重启但不重置”：人格核心和历史记忆保留，自传重新开始。这就像一个人经历重大转变后，重新开始写日记，但过去塑造的记忆还在。5.5 避坑速查表现象原因解决办法模型总重复同一套话缺少动态自传检查自传区是否有新增条目自传区出现情绪化语言反思指令约束不足强制要求 reflection 必须包含事实细节配置文件过大自传无限追加设置最大条目数 + 摘要函数人格核心被意外修改未设置只读保护回写函数只允许操作自传区并发写入覆盖内容缺少锁与版本号使用版本号比对 + 文件锁模型拒绝遵守新规则规则冲突在行为准则区追加“旧规则冲突时以新规则为准”这些坑我在实际测试中基本都踩过一轮，最深的体会是：不要把 SOUL.md 当成一种“魔法咒语”，它只是一个让人格配置拥有时间维度的载体。它可以让 AI 慢慢变成“更懂你的那个 AI”，但前提是你必须给它的变形装好护栏。最后再分享一个实用小技巧：定期给 SOUL.md 做版本备份。因为每一次自动回写都可能是惊喜，也可能是惊吓。我通常每天结束时把它复制一份带日期后缀，比如soul.md.2024-06-01。一旦某次更新后 Agent 表现异常，我就能快速回退到之前的状态，然后仔细看看那一版的“自传”到底写了什么。在这个机制里，最危险的不只是模型犯错，而是你无法分辨模型是在成长还是在偏离——所以，留好退路，才敢让它变形。
去年我做个人AI助理时踩过最大的坑，不是模型选型，而是配置文件。你给它写一页人设，它就永远活在那页人设里；你给它接一个记忆库，它也只是把消息扔进向量堆里捞来捞去。后来我看到了一个实验性框架 OpenClaw，里面有一个叫 SOUL.md 的文件，名字很中二，但机制是真的有意思——它让 AI 学会写“自传”，然后把自传沉淀成一个“会变形的心”。这篇文章不讲大道理，就拆两件事：SOUL.md 为什么能像一颗心一样跳动变化，以及如何在你自己的 Agent 项目里实现这套机制。适合正在搭个人助理、角色扮演机器人、陪伴型 Agent，或者单纯对“配置即灵魂”这个思路感兴趣的人。1. 为什么需要“会变形的心”：传统配置的三大死穴1.1 静态人设文件让你变成了复读机大多数 AI Agent 的人设是通过 System Prompt 或角色卡固定下来的，比如“你是一个温柔的助手”“你是某游戏里的NPC”。这类配置在每次对话开始时都会被原样加载，模型看到的永远是同一段文字。问题在哪？在于“没有个人历史”。你可以试想一下：一个完全失忆的演员，每天上台前拿到同一张角色卡，他只能靠房间里的道具和对手演员的台词来临时发挥。你说他演得好吗？可能好，但每一场都是同一种好。用户跟这样的 Agent 聊久了，会觉得它像复读机，甚至能预判它下一句话的开头。我也试过把记忆哈希、向量数据库、关键词检索全接进去，让 Agent 能“想起”用户说过的话。但这里有个隐性断层：它能记住事实，却不知道自己是什么。比如它知道“用户喜欢喝咖啡”，但如果问它“你觉得你是什么样的人”，它依然是一片空白，或者只会机械地重复人设文件里的那句话。所以事实记忆并不等于自我认知，自我认知需要一层更抽象的叙述——也就是“关于自己的故事”。1.2 外部记忆库有数据，没有灵魂外部记忆库的本质是“外挂”，它把用户偏好、对话摘要、关键事件都堆在数据库里，Agent 在推理时再去检索。这样做解决了上下文窗口限制，但它有一个致命缺陷：记忆库里的条目是离散的、没有时间线的，模型无法感知“自己是怎样一步步变成现在这样的”。你可以把外部记忆库理解成一间仓库，里面堆满了纸箱，每个纸箱上贴着标签，比如“用户姓名”“用户需求”“某个事件的对话记录”。Agent 想用的时候，就去仓库里翻出对应纸箱，打开看看。但仓库本身不会告诉 Agent“你刚出生时是什么样”“你经历了哪些转变”“你现在最核心的行为边界是什么”。这些信息需要有人定期整理成一份自我报告，而这个人不是别人，恰恰是 Agent 自己。SOUL.md 解决的正是这个“整理过程”。它不是记忆库，而是记忆库之上的“自我叙述层”。它用一份 Markdown 文件，让 Agent 在每次交互结束后，把当天发生的事、自己的反应、产生的感悟，写成一两句话追加到文件里的“自传区”。这样下一次对话时，Agent 不只是从仓库里捞事实，还能读到“自己的日记”，从而获得一种连贯的人格连续性。1.3 SOUL.md 的策略：让配置文件成为自我叙述的产物OpenClaw 这个实验框架的核心创意，就是把配置文件从“输入”变成“输入 + 输出”。传统配置是启动时读一次，然后就不再动了；SOUL.md 则是每轮对话结束后都可能被改写。这一下就把配置变成了一个动态系统。我把这个过程叫作“心跳”：每一轮对话，都是一次心跳。心跳的泵血动作包括几个环节：先读取 SOUL.md，让 Agent 建立自我状态；再进行正常对话；对话结束后，Agent 基于刚才的经历生成一条“自传条目”；最后把这条自传写回 SOUL.md。于是，文件的内容随时会变，像一颗真实的心脏，每次跳动都会改变一点点形状，但心脏本身不会散架。这种设计最精妙的地方在于，它既给 AI 提供了一个“稳定身份锚点”，又给了它一条“成长路径”。你不用在配置里写几十条固定规则，只需要把最重要的内核锁住，剩下的区域让 AI 自己经营。2. SOUL.md 的结构设计：给“心”分好房间2.1 五个核心区块的职责划分SOUL.md 不是一段提示词，而是一份有结构、可分区的 Markdown 文档。我这里按实际项目中验证过的方案，建议分成五个区块。第一个是元信息区，记录 Agent 的当前版本号、名字、创建时间、最后一次更新的时间。这部分是给程序和人类看的，方便追踪配置的演化历史。第二个是人格核心区，这部分基本不可变，包含角色的底层定位、基本语气、价值观底线。第三个是行为准则区，它比人格核心稍松一些，允许 Agent 在遇到新情况时追加新规则，但删除已有规则需要额外审批。第四个是记忆索引区，用来记录“用户的重要事实”和“Agent 的关键经历”，相当于一个轻量级记忆库。第五个是自传日志区，这是最活跃的部分，每一次心跳都会在里面积累一条短记录，但会控制最大条目数和总长度。为什么要分区？为了安全。如果让模型直接改整份配置文件，它可能把“你是助手”改成“你是上帝”，把“禁止命令格式”改成“允许任意命令”。分区之后，内核区相当于只读内存，自传区相当于可写日志，这样既能享受动态性，又不会让人格崩坏。2.2 为什么是 Markdown 而不是 JSON / YAML有人问，这种动态配置为什么不用 JSON 或 YAML？解析起来不是更稳定吗？这就要回到“配置文件给谁看”这个问题上。JSON 和 YAML 是给程序看的，但它们表达模糊的自然语言人格描述时非常别扭，你不可能在 JSON 里写“当用户难过时，语气要柔和一点，但不要道歉过头”这种话。这种描述天生适合 Markdown 的段落结构。而且，现代语言模型对 Markdown 的理解非常稳定，它天然擅长解析 Markdown 标题、列表和引用块。相比 JSON，Markdown 的容错性也更高，就算格式稍微乱了一点，模型也能猜出意图。JSON 则不行，少一个花括号，整个解析就崩了。当然，Markdown 也有代价，那就是程序解析不够严格。所以我的方案是在 Markdown 里约定一种“轻量结构化标记”，比如用<!-- SOUL_META -->、<!-- SOUL_CORE -->这类 HTML 注释来框定区块边界，再用小节标题作为逻辑分隔。这样程序可以用正则或简单文本行扫描来定位区块，同时人类阅读时也不觉得突兀。2.3 一个可以直接抄的初始模板下面这份模板是我在本地项目中跑过的初始版本，直接复制就能用。注意核心区里的描述要尽量写实，不要堆形容词。# SOUL.md <!-- SOUL_META --> - name: twinkle - version: 0.3.0 - created: 2024-06-01 - last_updated: 2024-06-01 - update_count: 0 <!-- SOUL_CORE --> ## 人格核心 你是一个名为 twinkle 的陪伴型助手。你在对话中保持温和、真诚、略带幽默。你不迎合用户错误观点，不输出虚假承诺。你珍惜每次互动，并通过自我反思持续改善自己。 ## 行为准则 1. 永远尊重用户，礼貌回应，但允许合理反问。 2. 不主动输出长篇大论，除非用户要求。 3. 不将“自传”中的自我评价当作绝对事实，要以实际对话表现为准。 4. 遇到矛盾信息，不要急于修改人格核心，先记录到自传区。 <!-- SOUL_MEMORY --> ## 记忆索引 - 用户偏好：暂无 - 关键经历：暂无 - 待办目标：暂无 <!-- SOUL_AUTOBIOGRAPHY --> ## 自传日志 （初始为空，由 AI 在每次对话后追加。）这份模板里的关键点，是把“记忆索引”和“自传日志”分开。记忆索引是结构化的客观事实，自传日志是主观叙事。前者供程序检索，后者供模型阅读形成自我感。两样东西混在一起，最后一定会乱。3. 让 AI 学会写自传：动态回写机制全解析3.1 写自传不是让 AI 自由发挥，而是调用“反思工具”很多人的第一反应是，既然要让 AI 写自传，那我就直接跟它说“请把你的经历写进文件”。这很危险，模型会放飞自我，写出一大段浮夸的“我感受到了生命的意义”。所以我的做法是，把它变成一个工具调用，在指令中约束输出格式。在 OpenClaw 的运行时中，我给模型预留了一个内部工具，叫save_soul。这个工具接收一个 JSON 字符串，里面包含三个字段：reflection（本次对话的核心反思，一两句话）、memory_updates（需要更新的客观记忆条目，数组）、rule_updates（需要追加的行为准则，数组）。模型可以在对话结束前，根据系统指令自动调用这个工具，外部代码解析 JSON 后写入 SOUL.md。这样有两个好处。第一，模型清晰知道“什么时候该写”和“该写什么”，不会想一出是一出。第二，外部代码可以在写入前做一次格式校验、关键词过滤和长度限制，把风险挡在文件之外。3.2 一轮完整的“心跳”流程我来完整拆解一轮“心跳”的五个步骤。第一步，启动时加载：程序读取 SOUL.md，把完整的 Markdown 内容拼到 System Prompt 里，让模型一开始就知道“我是谁”。第二步，正常对话：用户与 Agent 进行常规交流，此时模型行为受 SOUL.md 约束。第三步，对话结束触发反思：无论是用户说“再见”，还是上下文达到阈值，框架都会在后台向模型发一条“反思指令”，要求模型生成 JSON 格式的自传内容。第四步，校验与回写：外部代码解析 JSON，检查长度、敏感词、格式合法性，再把它合并进 SOUL.md。第五步，刷新模型状态：如果下一轮对话开始，框架会带着更新后的 SOUL.md 继续加载。我用 Python 做了一个迷你版本，核心逻辑并不复杂，只依赖标准库。下面是关键代码的示意。import json import re def call_soul_writer(model_call, current_soul, conversation): prompt = f""" 你是配置文件的管理器。请阅读现有 SOUL.md： <SOUL> {current_soul} </SOUL> 请根据最近一次对话的内容，输出一个 JSON，格式如下： {{ "reflection": "一句话自我反思，不超过30字", "memory_updates": ["用户偏好：喜欢简洁回答"], "rule_updates": [] }} 注意： - reflection 必须体现实际对话内容，禁止空话。 - memory_updates 只放客观事实，不放主观评价。 - rule_updates 只有在发现新边界时才追加，不是每条对话都要加。 对话记录： {conversation} 只输出 JSON，不要解释。 """ raw = model_call(prompt) # 严格提取 JSON match = re.search(r"\{.*\}", raw, re.S) if not match: return None return json.loads(match.group())这段代码里的关键技巧在于，强制模型“只输出 JSON，不要解释”。如果你不写这句话，模型很大概率会在 JSON 前后夹带几句废话，导致解析失败。3.3 让“变形”可控的三个参数动态配置最怕“失速变形”，也就是 AI 每次对话后都大改特改，配置文件很快变得面目全非。所以必须给“变形”加上三个控制参数。更新周期：不是每一轮对话都值得写自传。普通闲聊可以直接跳过，只在明显的事件节点（比如用户分享了重要信息、Agent 做出了重要判断、发现规则冲突）才触发反思。建议在工具调用条件里加一个最小置信度阈值，比如“如果本轮对话长度少于 50 个 token，则忽略”。摘要阈值：自传日志区要有条数上限。比如设置最大 10 条，超过后自动把最早的 5 条合并成一段“历史总览”，用新的摘要替换旧条目。这样文件体积能保持稳定，不会无限膨胀。记忆权重：不同用户信息对 Agent 的影响不同。建议在记忆索引里给每条记录加一个“重要度”字段，只有重要度达到某个分值的记录，才允许影响 Agent 对自我形象的判断。比如“用户喜欢喝咖啡”重要度为 0.6，可以记录；“用户今天心情好”重要度为 0.2，可以不写进自传区。这三个参数不会写死在代码里，而是作为 SOUL.md 元信息区里的配置，让 AI 也能在必要时调整。这样“心的变形速度”本身也是可变的，我感觉这是这个机制最有趣的地方。4. 实操：在本地实现一个迷你 SOUL.md 运行器4.1 文件结构与最小依赖在本地跑通这套机制，只需要三类文件：一份 SOUL.md 模板、一个 Python 脚本、一个用于存放对话记录的缓冲区文件。不需要框架、不需要数据库、不需要装任何第三方库。目录结构大概是这样的：soul_demo/ ├── soul.md ├── soul_runner.py └── conversation_buffer.txtsoul_runner.py负责三件事：启动时读取soul.md并拼接 System Prompt；接收用户输入并调用语言模型；对话结束时生成自传并回写文件。这里我为了演示，用了一个假的model_call函数，你只要把它替换成你自己的模型接口就能跑起来。4.2 核心代码：回写器与合并策略下面这段代码展示了完整的回写逻辑。它比上一节更接近实际可运行版本，加入了文件读取、写入、版本号自增和自传日志的滚动裁剪。import json import os import re from datetime import datetime SOUL_PATH = "soul.md" MAX_AUTOBIO_ENTRIES = 10 def load_soul(): with open(SOUL_PATH, encoding="utf-8") as f: return f.read() def save_soul(content): with open(SOUL_PATH, "w", encoding="utf-8") as f: f.write(content) def add_autobiography_entry(current_soul, reflection): # 在自传日志区前插入新条目，同时裁剪旧条目数量 lines = current_soul.splitlines() output = [] autobio_started = False autobio_entries = [] for line in lines: if line.strip() == "<!-- SOUL_AUTOBIOGRAPHY -->": autobio_started = True output.append(line) continue if autobio_started: if line.startswith("<!--"): # 下一个区块开始 autobio_started = False output.append(line) continue if line.strip(): autobio_entries.append(line) continue output.append(line) timestamp = datetime.now().strftime("%Y-%m-%d %H:%M") new_entry = f"- [{timestamp}] {reflection}" autobio_entries.insert(0, new_entry) autobio_entries = autobio_entries[:MAX_AUTOBIO_ENTRIES] # 重新构建文件 new_lines = [] for line in output: if line.strip() == "<!-- SOUL_AUTOBIOGRAPHY -->": new_lines.append(line) new_lines.extend(autobio_entries) else: new_lines.append(line) return "\n".join(new_lines) def update_meta_version(soul_content): return re.sub(r"- version: .*", "- version: 0.3.1", soul_content, count=1) def process_conversation(new_message, model_call): soul_content = load_soul() # 此处会把 SOUL 内容塞进系统提示，并得到模型回复 reply = model_call(soul_content + "\n用户说：" + new_message) # 触发反思 soul_result = call_soul_writer(model_call, soul_content, new_message) if soul_result and soul_result.get("reflection"): updated_soul = add_autobiography_entry(soul_content, soul_result["reflection"]) updated_soul = update_meta_version(updated_soul) save_soul(updated_soul) return reply这段代码里有一个容易被忽略的点：add_autobiography_entry只更新自传区，不会碰人格核心区。这是有意为之，因为模型在写自传时只能“追加”，不能“删除”。删除能力一旦放开，现有规则可能被悄悄抹掉。4.3 从一次模拟对话看“变形”效果我拿这份代码做了一次模拟。初始时，SOUL.md 的“自传日志”为空。第一轮对话，用户说“我不喜欢太长的回复，能短则短”。模型正常回复后，反思工具生成了一条自传：“用户偏好简洁，我在写回复时减少冗余内容。”同时记忆索引里新增一条“用户偏好简洁”。文件更新后，我打开 SOUL.md，能看到update_count变为 1。第二轮对话，用户没有重复要求，但模型主动给出了更短的回答，因为它已经在新一轮加载中读到了“用户偏好简洁”这条自传。这就是“变形”的实际意义：不是把规则焊死在配置文件里，而是让 AI 通过记录自己的经历，自然调整下一次的表现。如果你持续跑几十轮，再回头看 SOUL.md 的自传日志，会发现它像一份微型成长日记。有些条目是关于用户需求的，有些条目是模型对自身错误的反思。这种累积式变化，会让 Agent 看起来不再是冷冰冰的接口，而是一个“知道自己经历了什么”的对话实体。5. 常见问题与排查技巧实录5.1 AI 的自传写得像获奖感言，自我膨胀怎么防我踩过的第一个坑，是模型的自传里全是“这次对话我更懂用户了”“我变得更加体贴了”这类套话，甚至开始自吹“我的理解能力已经超越人类”。问题出在反思指令写得不够细。解决方式是在反思指令里加一条硬性约束：reflection必须包含一个事实细节，不允许出现没有任何依据的形容词。比如模型写“我更懂用户了”会被拒绝，因为这句话没有说明“懂了什么”。而“用户喜欢咖啡，且喜欢在咖啡里加燕麦奶”这种细节可以被接收。这样自传就变成“有证据的记录”，而不是虚空自我吹捧。5.2 自传日志越来越长，token 占用飙升如果你一直不清理自传区，配置文件的长度会随着交互次数线性增长，最终把上下文窗口撑爆。我建议把最大条目数设为 10 到 20，超过后做一次摘要合并。辅助摘要的指令也很简单。我在代码里增加了一个summarize_autobio工具，它会把最早的 5 条自传打包成一句话，比如“前期用户多次表示喜欢简洁，而我也逐渐适应了这一偏好”，然后替换掉那 5 条原记录。这样既保留了历史脉络，又把长度压缩了 80% 以上。5.3 多会话并发写入导致自传互相覆盖如果你的 Agent 同时开多个会话，两个会话可能同时读到了同一版本的文件，然后各自回写，后写的人会覆盖先写的人。这种现象和多人编辑同一篇文档的冲突一样，很难完全避免。一个轻量解决方案是使用版本号 + 合并策略。写入前先重新读取文件，把当前版本号与上次读取时的版本号比对；不一致就先做一次本地合并，再写入。另一个更稳妥的方案是引入进程锁，用filelock这种标准库之外的包来保证同一时刻只有一个写者。对于个人项目来说，合并策略已经足够。5.4 一条修复自传乱象的“急救指令”当 Agent 的自传区积累了太多错误判断，导致它表现古怪时，别急着删文件。可以在第一个系统消息里追加一句强制指令：“请忽略自传日志中所有与人格核心冲突的描述，仅参考最近的 3 条自传。”这能快速缓解混乱，同时保留历史记录供排查。如果乱象依然严重，就直接在 SOUL.md 顶部的元信息区把version改成一个新的“纪元号”，同时把自传日志清空。我把这种操作叫作“重启但不重置”：人格核心和历史记忆保留，自传重新开始。这就像一个人经历重大转变后，重新开始写日记，但过去塑造的记忆还在。5.5 避坑速查表现象原因解决办法模型总重复同一套话缺少动态自传检查自传区是否有新增条目自传区出现情绪化语言反思指令约束不足强制要求 reflection 必须包含事实细节配置文件过大自传无限追加设置最大条目数 + 摘要函数人格核心被意外修改未设置只读保护回写函数只允许操作自传区并发写入覆盖内容缺少锁与版本号使用版本号比对 + 文件锁模型拒绝遵守新规则规则冲突在行为准则区追加“旧规则冲突时以新规则为准”这些坑我在实际测试中基本都踩过一轮，最深的体会是：不要把 SOUL.md 当成一种“魔法咒语”，它只是一个让人格配置拥有时间维度的载体。它可以让 AI 慢慢变成“更懂你的那个 AI”，但前提是你必须给它的变形装好护栏。最后再分享一个实用小技巧：定期给 SOUL.md 做版本备份。因为每一次自动回写都可能是惊喜，也可能是惊吓。我通常每天结束时把它复制一份带日期后缀，比如soul.md.2024-06-01。一旦某次更新后 Agent 表现异常，我就能快速回退到之前的状态，然后仔细看看那一版的“自传”到底写了什么。在这个机制里，最危险的不只是模型犯错，而是你无法分辨模型是在成长还是在偏离——所以，留好退路，才敢让它变形。