最近在 X 上刷到一条爆火的帖子，YC 现任 CEO Garry Tan 分享了他如何将 OpenClaw 调教成一个“再也不用教第二遍”的智能体。帖子的标题就是 How I get my claw to be a durable AI agent I never have to instruct twice。
看完之后我沉默了好一会儿。倒不是因为方法有多高深莫测，而是突然意识到，我们大多数人使用 AI 代理的方式，可能从根本上就出了问题。每天让它干活，干完关掉，下次任务又得从头开始解释。表面上看效率还行，但代理本身没有任何积累。它没有在成长，只是每次都像个临时工一样，碰巧猜对了你的指令。
这或许也是很多开发者的共同体验：每天用 Claude Code 写代码、用 Cursor 改 bug，但每次开启新会话，都得把项目背景重讲一遍。用了两个月，代理对你的项目依然一无所知。这本质上不是在用“助理”，而是在日复一日地招聘和培训“临时工”。
不只是帖子，背后是一个完整的开源项目
这条帖子之所以在中文圈迅速传播，很大程度上得益于博主 @yanhua1010 做了一条清晰的中文转述。但如果你只看到了帖子，那就错过了真正的宝藏。我多翻了一层，发现 Garry Tan 不只是说说而已，他同步开源了一个名为 GBrain 的项目（github.com/garrytan/gbrain），这才是整件事的工程化实现。
而且这远非一个简单的概念验证（demo）。GBrain 是 Garry Tan 自己运行了相当长时间的生产级配置，管理着超过 10000 篇 Markdown 文件、3000 多个人物档案、跨度 13 年的日历数据、5800 条 Apple Notes，以及所有的会议记录和原创想法。他将这套完整的基础设施打包成了 GBrain，并以 MIT 协议开源，任何人都可以免费使用。
它是专为 OpenClaw 和 Hermes Agent 这两大智能体系统设计的“记忆骨架”。看完这个仓库我才恍然大悟，为什么之前尝试过的各种 AI 代理记忆方案，总感觉差了那么一口气。
那么，到底差在哪里？
超越“记住”：构建可追溯的“知道为什么”
当前许多人构建 AI 代理记忆的思路，核心就是增加 memory 功能——让它记住你的偏好、常用命令和项目背景。
这当然比没有强。但如果只停留在这一步，代理就像一个记性还不错但缺乏深度的人：知道你说过什么，却不知道这个信息是如何被确认的、是否已经过期、以及是否仍然可信。
GBrain 做了一件非常巧妙的事：它将每一条知识拆分为两层。上层是 compiled truth，即当前最可靠的结论，比如“张三是 XX 公司的 CTO，主管基础架构”。下层则是一条 append-only 的时间线，忠实记录了这个结论是如何一步步积累而来的——何时首次出现在邮件里，何时在会议中被确认，又何时因为组织架构调整而被更新。
你想想看，这和单纯的“我记得你说过张三是 CTO”完全不是一个量级。一个有完整的证据链支撑，另一个只是模糊的印象。当代理查询信息时，它给你的回答是“根据 3 月 15 日的会议纪要和 4 月 2 日的邮件确认”，而不是“我好像记得你提过”。
这就是“记忆”与“知识系统”的本质区别。记忆是“知道”，而系统是“知道，并且明确知道为何知道”。
三层架构：清晰的责任边界
这套系统具体是如何运作的？GBrain 的分层设计值得单独拿出来细说。
整个架构清晰地分为三层：
-
底层：Brain Repo
这是一系列存储在 Git 仓库中的 Markdown 文件，是 唯一信源（source of truth）。人类可以随时打开阅读、直接编辑。无论上层的代理如何运行，这一层始终掌握在人类手中。
-
中层：GBrain 数据库
使用 PGLite（WebAssembly 版本的 PostgreSQL）实现，真正做到零配置、约 2 秒启动。它支持向量搜索、关键词匹配以及混合排序，确保信息检索既快速又准确。
-
上层：AI 代理
代理通过 MCP（Model Context Protocol）协议与下面两层进行交互。何时读取信息、何时写入新知识、遇到新实体是否创建页面，所有这些行为都遵循预定义的 Skillpack 规则。
这种分工是整个项目最精妙的地方：人负责定义真相，数据库负责高效检索，代理负责持续维护。即使代理更换了会话甚至更换了底层模型，知识库依然独立存在。这与简单地在 system prompt 里塞入更多上下文有本质不同，它是在对话之外构建了一个独立、持久的知识层。
工作流哲学：先手动，再自动化
那条爆火的帖子里，最让我佩服的不是“禁止一次性工作”这个原则本身，而是其背后严谨的工作流。
对于同一类任务，第一次先手动操作几个样本（通常是 3 到 10 个）。完成并给人确认输出无误后，再将其编纂成正式的 SKILL.md 文件。如果确认这是一个周期性任务，再评估是否要将其加入 cron 实现自动化。即使是第一次自动运行，也需要密切观察，一旦跑偏可以及时纠正。
GBrain 项目中的 GBRAIN_SKILLPACK.md 文件，正是这套思路的工程化实践。它指导代理：每条消息进来，先查询大脑（知识库）；检测是否有新实体（人名、公司名等），若有则主动创建或更新对应页面。项目甚至设置了每日 cron 任务，让代理自动维护和梳理整个知识图谱。
先构建原型，再评估效果，接着编纂规范，最后实现自动化。这个顺序至关重要。许多开发者（包括我自己）都曾踩过相反的坑：试图将整个流程一步到位全自动化，反复调整几十版 prompt，最终效果可能还不如一开始老老实实手动跑几轮、摸清每个步骤的边界和异常情况。急于求成往往只会产出一堆难以维护的半成品脚本，修改起来比手动操作更累。
AGENTS.md 的本质：一份进化协议
这就引出了一个核心问题：我们该如何编写 AGENTS.md？很多人将其写成了语气指南、文件优先级列表和禁止事项清单。这没错，但这只是“行为守则”。
真正有价值的部分，是告诉代理 遇到重复性任务时该如何演进。目标不应仅仅是完成眼前这次工作，而是要判断“这件事以后还会不会发生”。如果会，应该将经验沉淀到哪里？那些做过两三次的高频任务、步骤稳定的流程、反馈清晰且对错分明的操作，最应该被提炼固化为 skill。反之，那些一年用一两次的低频操作、涉及生产数据的高风险任务、目标尚不明确的探索性工作，则不必急于自动化。
GBrain 的做法令人印象深刻。代理在每次对话中都会主动检测是否有新实体出现，对于反复出现的人名、公司名、项目名，它会主动创建 Wiki 页面或补充现有页面。几周下来，知识图谱开始自我生长，实体间的交叉引用越来越密集，查询返回的结果也愈发精准。
Garry Tan 将这种现象称为 compounding effect（复合效应）。我觉得这个词非常贴切——知识是会产生复利的。你今天让代理多整理一条信息，不仅帮助了当下的任务，也惠及了未来所有与此信息相关的查询。
为什么这个方案能引起共鸣？
归根结底，是因为我们真的受够了。每次开启新会话都要重新“培训”一遍代理，短期尚可忍受，长期使用则令人无比烦躁。你最终会发现，自己不是在用工具提升效率，而是在反复扮演培训老师的角色。
Garry Tan 做对了一件事：他没有停留在“如何写出更好的 prompt”这个层面，而是动手构建了一套开源的 AI 代理知识基础设施。对于许多在 智能 & 数据 & 云 领域探索的开发者而言，这提供了切实可行的工程路径。
GBrain 支持通过 CLI 全局安装，也可以通过 MCP 协议接入 Claude Code、Cursor、Claude Desktop 等工具。本地使用 PGLite 即可零配置运行，数据量增长后可以无缝迁移到 Supabase（约 25 美元/月可获得 8GB 容量）。在 OpenClaw 或 Hermes Agent 中，通常只需一行命令即可完成安装。
我的判断是，下一步，开发者之间的差距将不再取决于谁的 prompt 写得更加巧妙，而在于谁先将 “如何将重复性工作经验有效沉淀” 的机制，深度整合进自己的 AI 代理系统中。
记忆当然重要，但仅有记忆是不够的。
一个懂得将经验固化为技能、推动知识库持续自主生长的 AI 代理，才开始像一个可以长期合作的“同事”，而非用完即弃的“临时工”。对于热衷于在 人工智能 前沿进行 开源实战 的 开发者 来说，GBrain 提供了一个值得深入研究和借鉴的范本。
相关资源：
发表于 3 小时前
|
查看: 11|
回复: 0
