OpenClaw在全球范围内正掀起一场现象级的AI狂潮。线上线下，无论是开发者还是科技前沿关注者，都在追逐这个爆款。安装OpenClaw后不知到怎么养龙虾？那么这篇文章就是给你量身定制的。
这两天我刷到谷歌高级AI产品经理、拥有9.9万星标GitHub开源项目Awesome LLM Apps的作者Shubham Saboo，给出了他经过40天实战打磨的OpenClaw Agent终极落地方案，这是我目前看到的最牛批的方案，大家不妨一阅，实操路线图附在文后
这位谷歌老哥的OpenClaw Agent每天都在进化。不靠微调提示词，不靠切换底层模型，更没有重构系统架构。
他只做一件事：与智能体交谈，给出反馈，然后看着它们把这些反馈记录下来。
40天前，他的内容智能体还会写出满是表情符号和标签的推文，研究智能体甚至无法在海量信息中提取有效信号。纠正它们错误的时间，甚至比他自己动手做还要长。
但今天，名为Kelly的智能体能够完全使用他的口吻撰写草稿，名为Dwight的智能体每天早晨能准时提交7个极具阅读价值的故事。8个智能体全天候24小时自动运行。他要做的只是打开Telegram，审核草稿，喝杯咖啡。
从第1天到第40天，底层模型没有任何变化。真正产生质变的，是一堆每周都在不断丰富演进的Markdown文件。
openclaw 龙虾
这就是支撑这套系统的完整技术栈。
这套完整的操作系统仅由三个核心层级构成：
第一层：身份层。定义智能体是谁（涵盖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，她还有6个额外的文件来精确定义她如何创作内容：写作风格指南、帖子格式参考、真实案例展示、每日任务分配。
Dwight则拥有目标受众档案和研究协议。随着角色定义的不断完善，每个智能体的文件夹都会不断扩充。建议从AGENTS.md起步，只有当你发现某个错误模式反复出现需要纠正时，才添加新的专家级文件。
HEARTBEAT.md（自愈机制）
智能体团队构成了基础设施，而基础设施是会出故障的。
以下是主控智能体Monica的HEARTBEAT.md：
Monica在每次心跳周期都会运行此文件，检查两件事：浏览器是否存活，定时任务是否真的在执行。
这两者息息相关。如果浏览器崩溃，Dwight就无法进行数据搜集。如果Dwight错过了搜集，Kelly和Rachel就会根据过时的信息起草内容。如果定时任务在后台静默停止，整个操作表面上看起来很健康，但实际上什么都没发生。
最后一种情况确确实实发生在了第三周。调度程序出现了bug，任务在队列中推进但从未执行，几个小时都没被发现。
此后便加入了心跳检测机制，在一个地方同时捕获这两种故障模式。这个机制在后来已经多次发挥了作用。
第一天不需要建立这个机制。在经历第一次故障后再建立，因为只有痛过，你才会确切知道需要监控什么。
真正奏效的记忆系统是一个建立在文件系统之上的三层架构。
第一级：MEMORY.md（经过梳理的长期记忆）
这里存放的不是原始日志，不是发生过的所有琐事，而是真正重要的核心内容。
摘自Monica的MEMORY.md：
注意惨痛教训这个部分。Monica曾经误删过一个项目文件夹。现在这个错误被永久记录在了她的长期记忆中。她再也不会犯同样的错误。一次修正，永久存储，预防了未来所有会话中重复同样的错误。
摘自Kelly的MEMORY.md：
坏案例部分是Kelly在被纠正后自己写下的。她记录下了自己的错误以避免重蹈覆辙。单单这一部分的价值，就超过了任何提示词工程指南。
出于安全考虑，MEMORY.md仅在直接会话中加载，不在群聊等共享上下文中加载。务必将敏感偏好设置排除在全局加载的文件之外。
千万不要在第一天就去写MEMORY.md。它是从反馈中生长出来的。给出反馈，智能体将其记录在每日记忆中，提取重要信息存入MEMORY.md，它在每次会话中加载，从此这个修正意见就不需要再被提及。
第二级：memory/YYYY-MM-DD.md（每日会话日志）
这是原始笔记。记录了今天发生了什么，起草了什么内容，收到了什么反馈。
每日日志是原材料，MEMORY.md是精炼后的成品。两者缺一不可。
这里有一条维护法则。每日日志积累得极快，如果不进行修剪，智能体的上下文就会急剧膨胀。Kelly的上下文曾一度飙升至16.1万个Token，导致输出质量暴跌。后来不得不将其压缩到4万个Token。现在每两周必须审查并归档一次旧的每日日志。
每次会话只需加载今天和昨天的日志，智能体不需要每次都携带全部历史记录。
第三级：结构化的记忆文件夹
在根目录下，记忆按人员进行组织：
随着系统的壮大，可以按人员或项目来组织结构。
Shared Context（跨智能体知识共享层）
这是最新加入的层级，也是彻底改变游戏规则的一步。这是一个所有智能体在会话启动时都会读取的单一文件夹。
THESIS.md记录了当下的世界观：关注什么，已经写了什么，还缺什么。Dwight阅读它来确定研究优先级，Kelly阅读它来匹配思维方式，Ryan阅读它来构思文章主题。所有智能体都向同一个事实源对齐。
FEEDBACK-LOG.md是跨智能体的修正层。当告诉Kelly不要使用破折号时，这个反馈对Rachel、Ryan和Pam同样适用。与其分别纠正四个智能体，不如写一次让所有智能体共同读取。
智能体之间不需要API调用，也不需要消息队列。只有文件。
Dwight将研究成果写入。Kelly读取它，Rachel读取它，Pam读取它。文件系统就是协同调度的核心。
一个智能体写入，其他智能体读取。交接的媒介就是磁盘上的Markdown文件。
遵循单一写入者原则。永远不要让两个智能体同时向同一个文件写入。每个共享文件的设计都必须是一个写入者，多个读取者。这直接根除了所有你原本需要费力调试的协同冲突。
时间调度是这套机制顺畅运转的保障。Dwight在早上8点和下午4点运行。Kelly和Rachel在下午5点运行。Dwight必须先运行，因为所有人都在等他的输出。一旦顺序出错，下游智能体读取到的就是过时的或空的文件。
完整目录结构一览：
因为这些文件不是静态的，它们在不断进化。
Kelly的SOUL.md在第一天只是个粗糙的草图。到了第40天，里面已经包含了具体的语气示例、她自己整理的被拒模式列表，以及一个绝不再提建议板块，记录了她已经涵盖过的所有主题。
Dwight的原则在第一天只写着寻找热门趋势。到了第10天，原则变成了如果目标开发者读者今天不能直接用它采取行动，就跳过。到了第20天，他加入了验证步骤：检查代码库创建日期，检查Hacker News发布时间戳，追溯信息发现的原始出处。
在第20天之前并没有共享上下文层。因为不断向多个智能体重复同样的修正，所以才建立了THESIS.md和FEEDBACK-LOG.md。瞬间，一次修正就可以在全网传播。这一个微小的改变，比任何提示词优化节省的时间都要多。
第1天和第40天使用的模型是完全一样的。它并不会因为你使用的时间变长而自动变得更聪明。但是包裹着它的这些文件变得更丰富、更敏锐、更贴合你的确切需求。这种不断积累的上下文环境，才是真正的技术护城河。使用同一个模型的人，根本无法复制这种能力。
你必须通过每天亲自下场与智能体交谈来赢取这条护城河。
不要试图在一个周末把所有东西都建好。
今天。 安装OpenClaw。写一个SOUL.md，一个IDENTITY.md，一个USER.md。挑一个你最重复的日常任务。设置一个定时任务。让它跑起来。
3天后。 智能体初期的输出会很平庸。开始给出具体的反馈。确保这些反馈落实在记忆文件中，而不仅仅停留在聊天框里。
1周后。 创建AGENTS.md。定义会话启动程序。添加内存管理规则。
2周后。 启动MEMORY.md。回顾每日日志。哪些错误反复出现？将它们提取成永久条目。这个时候，你就会开始感受到复利的威力。
3周后。 加入第二个智能体。建立基于文件的协同机制：第一个智能体写入共享文件，第二个智能体读取。随着模式的显现，添加角色专属指南。
同期。 构建共享上下文层。在达到这一步之前，你一定会感受到这种需求。向多个智能体重复同样的修正就是最明显的信号。建立代表当前思维的THESIS.md和用于跨智能体修正的FEEDBACK-LOG.md。
4周后。 在遭遇第一次故障后添加HEARTBEAT.md。因为痛过，所以你确切知道需要监控什么。
你要做的仅仅是与智能体交谈。剩下的事情，交给文件系统。
发布者：Ai探索者，转载请注明出处：https://javaforall.net/258236.html原文链接：https://javaforall.net
