初级
如何搭建真正随时间进化的 OpenClaw 智能体（我经过 40 天实践后的完整技术栈）
如何搭建真正随时间进化的 OpenClaw 智能体（我经过 40 天实践后的完整技术栈）
如何搭建真正随时间进化的 OpenClaw 智能体（我经过 40 天实践后的完整技术栈）#
我的智能体每天都在变得更聪明。
而我只需要和它们对话。
不需要调整提示词。
不需要更换模型。
不需要重构架构。
只是对话。
给予反馈。
看着它们记录下来。
40 天前，我的内容智能体起草的推文还带着表情符号和话题标签。
我的研究智能体把有效信息淹没在噪音里。
我花在纠正它们上的时间，比我自己完成任务还要多。
如今，Kelly 能以我完全一致的风格起草内容。
Dwight 每天早上提供 7 个值得一读的故事。
八个智能体 7x24 小时运行。
我打开 Telegram，审阅草稿，喝着咖啡。
第 1 天和第 40 天用的是同一个模型。
区别在于一套 Markdown 文件，它们每周都在变得更丰富。
这就是那套技术栈。
技术栈#
整个操作系统由三层构成：
- 第一层：身份：这个智能体是谁（SOUL.md, IDENTITY.md, USER.md）
- 第二层：操作：这个智能体如何工作（AGENTS.md, HEARTBEAT.md, 角色专用指南）
- 第三层：知识：这个智能体学到了什么（MEMORY.md, 每日日志, shared-context/）
仅此而已。
没有编排框架。
没有消息队列。
没有数据库。
磁盘上的 Markdown 文件。
文件系统就是集成层。
第一层：身份#
SOUL.md （智能体是谁）
它定义了智能体是谁、做什么以及如何表现。
这是 Dwight（我的研究智能体）文件的精简版：
电视角色技巧。
每个智能体都以一个电视角色命名。
当我告诉 Claude “你有 Dwight Schrute 的气质”时，它已经从训练数据中知道这意味着什么。
严谨、专注、对待工作极其认真。
这是免费加载的 30 季角色发展。
保持在 60 行以内。
SOUL.md 在每次会话中都会加载。
如果太长，它会占用本应用于实际工作的上下文。
身份、角色、原则、关系、氛围。
这就是你需要的全部。
这是一个入门模板：
从一个智能体开始。
选择你最重复的日常任务。
写一个粗略的草稿。
第一个版本会很平庸。
接下来一个月，你会根据观察到的情况重写十次。
IDENTITY.md （快速参考卡片）
SOUL.md 是完整的个性。
IDENTITY.md 是名片。
姓名、角色、氛围、一句话简介。
小文件。
当你运行 8 个智能体时，它能极大改善体验。
这是智能体在 Telegram 中给你发消息时显示的内容。
USER.md （智能体为谁工作）
每个智能体都需要知道它在帮助谁。
USER.md 包含你的偏好、背景以及塑造智能体行为的上下文。
写一次。
每个智能体都会读取它。
个人细节比你想象的要重要。
时区意味着智能体不会在凌晨 3 点安排事情。
饮食偏好意味着当 Pam 起草关于团队聚餐的通讯稿时，她不会建议牛排馆。
这些细节会累积起来。
第二层：操作#
AGENTS.md （行为规则）
SOUL.md 是智能体是谁。
AGENTS.md 是它如何运作。
会话启动例程、文件读取顺序、记忆管理、安全规则。
这是每个智能体都继承的根级 AGENTS.md：
然后每个智能体添加自己的规则。
Kelly 的 AGENTS.md 在此基础上扩展了她特定的工作流：
智能体在会话之间没有记忆。
一切从头开始。
如果修正没有写入文件，下次会话中它就不存在。
AGENTS.md 明确这一点，以便智能体记录下所有内容。
专用文件是智能体变得敏锐的地方。
Kelly 不仅有 AGENTS.md。
她还有六个额外文件，精确定义了她如何创建内容：写作风格指南、帖子格式参考、真实示例、每日任务。
Dwight 有目标受众画像和研究协议。
随着角色定义越来越清晰，每个智能体的文件夹也在增长。
从 AGENTS.md 开始。
只有当你注意到某个模式需要反复修正时，才添加专用文件。
HEARTBEAT.md （用于自我修复）
智能体团队是基础设施。
基础设施会出故障。
Monica 的 HEARTBEAT.md：
Monica 在每次心跳时运行这个。
她检查两件事：浏览器是否存活，以及 cron 作业是否真的运行了。
它们是关联的。
如果浏览器挂了，Dwight 就无法进行他的研究扫描。
如果 Dwight 错过一次扫描，Kelly 和 Rachel 就会基于过时的信息起草内容。
如果 cron 作业静默停止运行，整个操作表面上看起来健康，但实际上什么都没发生。
最后一种情况正是我在第三周遇到的。
调度器有一个 bug。
作业在队列中前进但从未执行。
我几个小时都没注意到。
之后，我构建了心跳机制，在一个地方捕获这两种故障模式。
自那以后，它已经多次发挥作用。
第一天你不需要这个。
在你第一次故障后构建它。
你会确切知道要监控什么，因为你已经体会过什么会出问题。
第三层：知识#
有效的记忆系统是一个基于文件的三层系统。
第一层：MEMORY.md （精选的长期记忆）
不是原始日志。
不是所有发生过的事情。
是那些重要的东西。
来自 Monica 的 MEMORY.md：
注意“Hard Lessons”部分。
Monica 删除了一个项目文件夹。
现在这个错误永久存在于她的长期记忆中。
她再也不会这么做了。
一次修正，存储一次，防止未来所有会话中出现同样的错误。
来自 Kelly 的 MEMORY.md：
Kelly 在收到修正后自己写了“BAD”部分。
她记录自己的错误，以免重复。
仅这一部分就比任何提示工程指南都更有价值。
安全说明。
MEMORY.md 只在直接会话中加载，不在群聊等共享上下文中加载。
将敏感偏好排除在随处加载的文件之外。
不要在第一天就写 MEMORY.md。
它从反馈中成长。
给予反馈 → 智能体将其记录在每日记忆中 → 将重要内容提炼到 MEMORY.md → 每次会话都加载它 → 同样的修正永远不需要再给。
第二层：memory/YYYY-MM-DD.md （每日会话日志）
原始笔记。
今天发生了什么。
起草了什么。
收到了什么反馈。
每日日志是原材料。
MEMORY.md 是精炼产品。
两者都需要。
维护规则。
每日日志积累得很快。
如果不修剪，智能体的上下文会急剧膨胀。
Kelly 的日志曾达到 161,000 个 token。
输出质量直线下降。
我不得不将其压缩到 40,000。
现在我每两周审查并归档旧的每日日志。
只加载今天的日志和昨天的。
智能体不需要每次会话都加载其全部历史。
第三层：有组织的记忆文件夹
在根级别，我按人员组织记忆：
随着你的设置增长，按人员或项目组织。
共享上下文（跨智能体知识层）
这是最新的补充，也是改变一切的一环。
一个所有智能体在会话开始时都会读取的文件夹。
THESIS.md 是我当前的世界观。
我关心什么、我已经写过什么、还有哪些空白。
Dwight 读取它以确定研究优先级。
Kelly 读取它以匹配我的思路。
Ryan 读取它以提议文章。
每个智能体都对齐到同一个真相来源。
FEEDBACK-LOG.md 是跨智能体修正层。
当我告诉 Kelly “不要用破折号”时，这个反馈同样适用于 Rachel、Ryan 和 Pam。
我不需要单独修正四个智能体，而是写一次，所有智能体都会读取。
智能体如何协调#
智能体之间没有 API 调用。
没有消息队列。
只有文件。
Dwight 将研究写入 intel/DAILY-INTEL.md。
Kelly 读取它。
Rachel 读取它。
Pam 读取它。
协调机制就是文件系统。
一个智能体写入。
其他智能体读取。
交接就是磁盘上的一个 Markdown 文件。
单一写入者规则。
永远不要让两个智能体写入同一个文件。
设计每个共享文件时，确保一个写入者和多个读取者。
这可以防止你原本需要调试的所有协调冲突。
调度使其生效。
Dwight 在上午 8 点和下午 4 点运行。
Kelly 和 Rachel 在下午 5 点运行。
Dwight 先运行，因为所有人都依赖他的输出。
如果顺序错了，下游智能体就会读取过时或空白的文件。
完整的目录结构#
为什么这有效#
这些文件不是静态的。
它们在进化。
Kelly 第一天的 SOUL.md 是一个粗略的草稿。
到第 40 天，它包含了具体的语音示例、她自己写的被拒绝模式列表，以及一个“NEVER SUGGEST AGAIN”部分，列出了她已涵盖的所有主题。
Dwight 第一天的原则是“找到趋势”。到第 10 天，变成了“如果 Alex 今天不能用它做点什么，就跳过它。”（Alex 是我们的目标读者画像，我们为其制作内容的开发者。）到第 20 天，他增加了验证步骤：检查仓库创建日期、检查 Show HN 时间戳、追踪 X 上的发现到原始来源。
共享上下文层直到第 20 天才出现。
我当时在向多个智能体重复同样的修正。
然后我构建了 THESIS.md 和 FEEDBACK-LOG.md，突然间，一次修正就传播到了所有地方。
这一项改变节省的时间，比任何提示优化都多。
第 1 天和第 40 天的模型是相同的。
它不会因为你使用时间更长而变得更聪明。
但它周围的文件变得更丰富、更锐利、更贴合你的确切需求。
这种积累的上下文就是护城河。
没有人能通过使用相同的模型来复制它。
你通过每天出现并与你的智能体对话来赢得它。
如何开始#
不要在一个周末内构建所有这些。
我没有。
今天。
安装 OpenClaw。
写一个 SOUL.md、一个 IDENTITY.md、一个 USER.md。
选择你最重复的日常任务。
设置一个 cron 作业。
让它运行。
3 天后。
你的智能体输出会很平庸。
开始给予具体反馈。
确保反馈落地到记忆文件中，而不仅仅是聊天里。
1 周后。
创建 AGENTS.md。
定义会话启动例程。
添加记忆管理规则。
2 周后。
开始写 MEMORY.md。
回顾你的每日日志。
哪些修正反复出现？
将它们提炼成永久条目。
这时你会感受到复利开始生效。
3 周后。
添加你的第二个智能体。
设置基于文件的协调：第一个智能体写入共享文件，第二个智能体读取它。
随着模式出现，添加角色专用指南。
大约在同一时间。
构建共享上下文层。
在此之前你会感受到需求。
向多个智能体重复同样的修正就是信号。
THESIS.md 用于你当前的思考。
FEEDBACK-LOG.md 用于跨智能体修正。
4 周后。
在你第一次故障后添加 HEARTBEAT.md。
你会确切知道要监控什么，因为你已经体会过什么会出问题。
你需要做的只是和你的智能体对话。
文件会完成剩下的工作。
如果你还没读过第一篇文章，我强烈建议你现在就去读。
> 引用的推文
> https://t.co/gupiw10kRV
> https://x.com/i/web/status/2022014147450614038
我将发布更多关于 OpenClaw、自主 AI 智能体团队以及 AI 产品经理和开发者不断发展的前景的内容。
关注我 @Saboo_Shubham_ 以保持关注。