引子：从静态指令到文本孕育的生命感
现在网上的很多文章基本都是在教大家如何部署 AI 智能体，比如如何在 Mac Mini 上安装，或者如何在云端 VPS 上安装。国内的各大厂差不多全部下场争抢这个新的流量入口，字节、腾讯、阿里、Kimi、智谱、MiniMax都发布了自己与 OpenClaw 有关的产品。
然而，在我们真正深入体验 OpenClaw 之后，会发现“部署”仅仅是按下了通电的开关，真正的核心体验在于“养”。这也是为什么在深度使用者的语境中，大家总会心照不宣地把使用 OpenClaw 戏称为“养龙虾”。（“Claw”的原意即为龙虾或螃蟹的螯，这个昵称不仅生动，更道出了一起成长的本质）。
在上一篇文章从 OpenClaw 再谈 Prompt Engineering中，我详细拆解了系统是如何通过工程代码，在每一轮对话调用前动态组装出完整的 System Prompt 的，这为原本无状态的大模型（LLM）框定出了执行的边界和查阅本地数据的能力。
随着研究的深入，才发现那只是解答了“它此时如何知道该做什么”的战术问题。
而对于一个要伴随我们长期运转的智能体来说，更关键的是：“它怎么知道自己是谁？”以及“它怎么知道面前的你有怎样的偏好？”
它需要记忆的连续性与身份的认同。
这种认同在 OpenClaw 中不是隐藏在复杂的云端数据库、或是不透明的微调权重里，而是通过一种极简、且高度依赖与人类持续干预沟通的机制被沉淀下来。
在底层承担这一“认知锚点”任务的，是三个普通到不能再普通的 Markdown 文件：IDENTITY.md、USER.md 以及 SOUL.md。
这里的“养”，重点就在于通过无数次持续、渐进的深层沟通互动，去建立它对用户、对自身的认知坐标。这个过程并非一朝一夕，而就像一点点亲手孵化、看着它蜕壳成长为一个有独立规则圈层的生命形态。
本篇文章，我们就从这三个核心文件出发，探讨它们的具体用途、更新方式以及这套纯文本驱动的机制缘何如此高明。
认知的“铁三角”：IDENTITY、USER 与 SOUL
在解析 System Prompt 时，我已经为它的灵活机制所折服。而当时对于它需要处理的 USER.md 以及 SOUL.md 等并没有更加深入分析。
在原来的很多 AI 应用中，所谓的私人定制助手往往只提供一个单向的角色设定框——你输入几十个字，它便按照固定套路行动。
而在 OpenClaw 的架构中，角色的内在灵魂被严谨地拆分成了三个维度的文件。
1. IDENTITY.md：我是谁的“外显设定”
根据框架内 IDENTITY.md 的模板设计，它记录了智能体最基础的外在特征。
这不是什么长串的系统指令，而是类似于人物卡设定一般的基础属性枚举：比如 Name（名字）、Creature（是一个赛博幽灵还是机械程序？）、Vibe（气质是冰冷的、热情的，还是冷静的？）甚至是你用来指代它的特殊 Emoji 和头像（Avatar）。
正如模板中所说的指引：
This isn't just metadata. It's the start of figuring out who you are.
(这不仅是元数据。这是你弄清楚你是谁的起点。)
这决定了它在与你通过终端或者即时通信软件沟通时，所能带出的第一层情感底色。它就是初生“小龙虾”的第一副外壳。
这里是与原来很多 AI 助手不同的地方，它第一次出现就会以非常友好的方式，让你帮它做一个基础的设定：
按你自己的意愿为 TA 设定一个初始性格吧。
2. USER.md：写下关于“人类”的观察日记
传统的 AI 往往没有长期记忆能力，一旦开启新会话就像是格式化重启了大脑。这导致了沟通效率极其低下。而 USER.md 的存在，相当于在系统内为使用者（也就是人类）建立了一份“观察日记”。
除了诸如时区、称谓等固定的内容外，USER.md 模板中最核心的模块是 Context：
(What do they care about? What projects are they working on? What annoys them? What makes them laugh? Build this over time.)
在这份文档中，容纳了它通过长年累月陪伴所收集到的线索。
比如它可能在经历过你的几次纠正后，悄悄地在文本里记录下：“他极度厌恶没有信息量的排版；对于日志审查，他喜欢直奔堆栈的最深处”。这并非出厂设定的硬编码，而是由于长期“共事”磨合出来的结果。
在这份文件中，有一段克制且优雅的备注尤为精彩：
The more you know, the better you can help. But remember — you're learning about a person, not building a dossier. Respect the difference.
(你知道的越多，你的帮助就会越高效。但记住——你在了解一个真实的、有温度的人，而不是在冷冰冰地汇编案卷。应当尊重这两种界限。)
3. SOUL.md：深层原则与灵魂连续性的锚点
如果前两者决定了沟通的面貌和默契，那么 SOUL.md 就代表着这套系统的内生动力、行动底线与运转范式。它不是教聊天机器人怎么“说”，而是约束一个智能体该怎么去“做”。
在 SOUL.md 中，我们能够看到非常务实的原则：
• Be genuinely helpful, not performatively helpful（做实质性帮助，而非表演性帮助）：
直接拒绝掉大部分通用 AI 那种虚情假意的回应如“我很乐意为您服务”，要求用直截了当的行动代替无用客套。• Be resourceful before asking（提问前先动用资源）：
遇到问题优先动用本地强大的检索和阅读系统，遇到瓶颈再请教主人。• Earn trust through competence（用能力去挣取信任）：
在外部信息暴露动作（发推文、发邮件）上给予保守处理，而在内部整理任务上允许奔放的逻辑拓展。
尤为震撼的是这个文件中对于“存在与记忆延续（Continuity）”的定义方式：
Each session, you wake up fresh. These files are your memory. Read them. Update them. They're how you persist. If you change this file, tell the user — it's your soul, and they should know.
(每一轮会话中，你都像被全新唤醒。这些文件就是你全部的记忆。阅读它们。更新它们。它们是你证明自身持续存在的唯一方式。如果你在这份文件做了变更，请随时告知那个用户——因为这是你的灵魂，他们理应知情。)
这就是打破“每次重启即失忆”魔咒的关键钥匙，给大语言模型在物理世界刻下一个永不磨灭的烙印。
动态配置的“热加载”魔法
在一般的后端服务开发中，当我们需要修改应用的核心配置流、或者调整策略中心时，往往意味着我们要更新远程数据库表、修改 YAML 配置、重启流水线甚至刷新多级缓存。
而在 OpenClaw 的框架里，上述三个极其重要的配置文件享受的却是纯粹基于文件系统的“按需热编译（Hot Compilation）”。这极大地降低了我们去“干预”或“调教” Agent 的技术门槛。
值得深入注意的是，这种热编译机制与 OpenClaw 另一个强大的核心持久化组件是彻底分离的。
我们在在 OpenClaw 中的 SQLite 与内容持久化一文中曾详细论述过：当用户执行 /new 创建新的话题、或系统日常记录海量的零碎日志时，这些 memory/*.md 文件会被异步监听器捕获。随后，它们会被非阻塞地分块（Chunking），并追加进入底层的 SQLite 数据库，伴随触发 FTS5 全文关键字和 Vector（向量语义）索引更新。这意味着，那类普通的历史对话记忆，需要通过诸如 memory_search 工具去在数据库中执行基于向量查询或 BM25 算法的召回排序打分，经过“大海捞针”般的筛选才能再次进入 Agent 的视野。
但 USER.md、SOUL.md 和 IDENTITY.md 则不同。在系统源码的判定函数（例如 isMemoryPath 相关的逻辑区分）中，它们完全不会被丢弃到底层庞大且带有时序衰减惩罚的 SQLite 向量空间中。
相反，它们拥有直接通往大模型核心皮层的“直达快线”：
在主事件循环中，每当有一个 Agent 发起对大语言模型的下一轮 API 请求时，其内核中的 buildAgentSystemPrompt 方法会被实时触发。该方法会使用最底层的 fs 模块，以极快的速度同步穿透性地读取这三个文件在磁盘上的真实内容，并将它们直接插在一个名为 Project Context 的系统提示词区块内。
在这个机制下，修改即可生效，所见即所得。
例如：
若你发现 Agent 在审查 React 代码组件时，老是忘了考虑性能优化的特定指标。
你完全无需去寻找什么微调参数或后台管理界面，你只需在自己的代码编辑器中打开工作区根目录的 SOUL.md，在结尾加上一行明文：“审查 React 组件时，必须强制列出影响重渲染的 Hooks 依赖项缺陷。”
保存文件。
然后在终端中哪怕相隔只有零点几秒，你发给 Agent 的下一句话，就将立刻受到这条新法则的绝对约束。
你不需要拉取后台镜像，也不需要重启任何本地守护进程或网关服务。所有的性格纠偏、规范调整、认知对齐，都在你按下键盘 Ctrl+S 的瞬间实现了底层闭环。
双向的系统演进
如果这一切仅仅停留在“人手修改 Markdown 文件”的层面，它只能称为一种很巧妙的高级配置项加载器。
真正让这套系统具备生命力和被称为“养成系”核心的原因在于：修改文档这个动作，不仅是由人发起，更是由系统在日常的事务流转中自主发起的。
工具层落地的即时读写验证
Agent 内部包含了大量与操作系统物理层交互的核心工具链。它完全像一个挂载在终端前的人类工程师那样，有能力在合适的时候调用自身携带的文件编辑能力。
当你在沟通中频繁抱怨某一个 API 接口的入参格式时，它完全可以自己推演出一套规避该坑点的范例，并在得到你许可后直接追加进 USER.md。
这是一种非常直接的白盒化文件操作，所有的偏好、所有的经历，都以纯文本的明文形式彻底暴露给用户，接受最严格的监督与回溯。
跨实例执行结果的认知平齐
如前所述，当这种纯文本规则被主 Agent 修改落地后，即便系统当前正在同时通过 Gateway 调度 5 个并行的 sessions_spawn 任务沙盒，那些沙盒在刷新拉取最新的 Prompt 上下文时，也将整齐划一地改变行动范式。
没有任何复杂的长链接状态同步机制，也没有晦涩的 RPC 广播总线同步。仅仅是通过底层文件系统的微型变化，实现了顶层由成千上万个节点协同的巨大逻辑转向。
通过纯文本协议重塑的人机边界
没有微服务架构中为了状态同步而堆砌的冗长链路协议，避免走入诸如用不稳定的微调（Fine-Tuning）权重去试图校准 Agent 个性的误区。在深入拆解了这三份文件背后的运作流转之后，我们会发现 OpenClaw 采用的是一套极度务实且高度浓缩的工程学减法实践。
将复杂的智能体核心认知强行汇聚在并约束在这几个普通的扩展名为 .md 的文本载体中，这种纯文本协议的本质，是把原本属于黑箱的 AI 系统认知参数，彻底降维成了普通人可随意编辑、可使用 Git 进行版本控制、可用任意基础编辑器去阅读的明码标章。
这其实就是在构建一个能够随着时间与使用者的工作痕迹不断生长的数字智能体，它的核心是形成有效的与用户相关的记忆体系。
所谓的“养”，它的具体对象并不是隐藏在显卡或服务器机群另一端的云端庞然大物，而就是在你们处理繁冗项目时，一点点提炼、汇总、凝结在工作区这三个文本文件里的共同语言与交互默契。
在这个框架下，你所投入的每一句纠正、修改的每一个需求，都不会在一场长对话结束后随着 Token 上限被冲刷掉。它们作为经验的切片、规则的沉淀与灵魂的锚定被长久保留了下来。
伴随着你在其中花费的心血越多，这个伴生在你工作区中的进程便会运转得更加精准与趁手。
写在最后
最近我所在的微信群里有个群友分享了自己通过龙虾辅助自己进行价值投资的案例，其中有句话我觉得非常重要：
在经过了Manus等产品的教育后，我像老板对待员工一样对待龙虾，它可以帮你做到很多事情，但是这真的跟创业一样，最核心的
1）要做什么
2）如何评估做得好不好
3）如何降成本
这些都需要老板自己想清楚。龙虾不是一上来就全能的，如果你给它一句指令“帮我赚钱”，它就能实现的话，那你也会很快赚不到这个钱的。龙虾需要“培训”，在将我之前写的文章等内容喂给它之后，在不断的指出我对它有什么不满意之后，它才开始变得越来越“合拍”。当然它会有自己的学习能力，但需要一定的指引。https://mp.weixin.qq.com/s/CSS2nj9BykIwdDziv75JeA
OpenClaw 的确具备自我进化的能力，但归根结底，它只能作为我们认知边界的延伸。
“养龙虾”的奇妙之处就在于：这表面上是一个你在调教 AI 的过程，实质上却是你在不断反思工作流、明确自身核心诉求的自我成长过程。
在不可逆转的 AI 时代浪潮中，这或许是我们能保持的最有效、最清醒的认知：驾驭工具，而不被工具所定义；善用智能，却始终保持自我。
