前言
知识不等于行为，行为不能靠自觉，要靠机制。
一个真实的问题
我用 Coze 平台搭了一堆智能体帮我干活——写代码、混音乐、写网文、做视频、运营社媒……一开始很顺畅，但很快发现了一个致命问题：
智能体会失忆。
今天踩的坑，明天换个会话又踩一遍。上周验证过的方案，这周重新摸索。一个角色积累的经验，另一个角色完全不知道。
更头疼的是多角色协作：系统开发者改了个配置，ECS 运维不知道，部署时崩了；运营发现平台规则变了，没通知到创作者，内容被打回。每个角色都在”独立聪明”，但没有”一起变聪明”。
我需要的不是一个更聪明的 Prompt，而是一套机制——让智能体的知识能沉淀、能流通、能自动触发行为。
这就是 Open Knowledge Framework 的起点。
它是什么
Open Knowledge Framework 是一套面向 AI 智能体的成长操作系统（开源、MIT 协议）。
它不是工具箱，不是模板库，而是一套让智能体从”能用”→”好用”→”自己变更好用”的成长机制。
核心理念用一句话说：知识不等于行为，行为不能靠自觉，要靠机制。机制用步骤来实现，步骤要读写闭环。
五个设计支柱
| 支柱 | 含义 | 为什么重要 |
|---|---|---|
| 无限扩展 | 新功能 = 注册扩展，架构本身永远不需要改 | 今天 3 个角色，明天 30 个，体系不能重写 |
| 高效少错 | 机制替代自觉，步骤替代记忆 | 智能体会失忆、会偷懒、会自作主张 |
| 省 Token | 每句话都花钱，少废话多干活 | 不做无用搜索、不重复操作、不空转等待 |
| 平台无关 | 抽象掉平台差异，核心逻辑可迁移 | 扣子→飞书→Hermes→机器人，体系代码不用改 |
| 实用耐用 | 规则写在文件里，不靠人记住 | 踩过的坑自动升级成规则，重犯 = 体系失职 |
它解决什么问题
问题 1：智能体会失忆
现象：每次对话都像第一次见面，之前踩过的坑、积累的经验全部归零。
解法：三层记忆体系
- 即时层：自动加载到上下文——身份定义、用户画像、当前状态、工具经验、敏感凭证
- 近中期层：按需加载——项目进度快照、重要决策记录、待办事项
- 长期层：语义检索——历史对话和文件内容的 RAG 搜索
关键设计：记忆有分层上限，不是所有东西都往一个文件里塞。超过上限的内容自动沉淀到详细文件，索引层只保留指针。
问题 2：知识不等于行为
现象：规则写在文档里 ≠ 智能体真的会遵守。踩坑记录在知识库里 ≠ 下次不会重犯。
解法：执行门机制
每个角色都有专属的”执行门”——强制性的步骤化流程：
1 | ① 查后定方案 → ② 执行 → ③ 验证 → ④ 反哺 → ⑤ 交付 |
每一步都有明确的检查项，跳步 = 不合格。关键的是第 ④ 步”反哺”——做完任务必须把经验写回知识体系，否则任务不算完成。
问题 3：踩过的坑反复踩
现象：同一个错误，换个会话、换个角色，又犯一遍。
解法：知识自动升级机制
1 | 踩 1 次 → 记入 knowledge（被动防御，搜索才能找到） |
典型案例：图片生成任务传了 count=5，一次烧了 5 万积分。这个教训从 knowledge 升级为铁律后，所有相关任务都自动继承这条规则，再也没犯过。
问题 4：多角色协作断层
现象：各角色各自为战，A 改了配置 B 不知道，C 的需求 D 没收到。
解法：三层单向关联 + 交接台
1 | 项目 → 角色 → 技能（单向关联，消费方找提供方） |
- 项目 INDEX.md 声明关联了哪些角色
- 角色 RULES.md 声明需要哪些技能
- 交接台是所有角色启动时的第一站，防止遗漏和断链
体系架构
文件即框架
整个框架完全由 Markdown 文件和 Shell 脚本构成，不依赖任何特定平台或数据库。知识在文件中，平台只是运行时。
1 | 宪法层（改一次全局生效） 共享知识/项目规范/ |
Extension Registry 模式
这是架构的核心模式：新功能 = 注册扩展，架构本身永远不需要改。
1 | 添加新角色 → 不改框架，只创建 角色/新角色/ |
这不是一句口号，是设计约束。无论体系从 3 个角色扩展到 30 个还是 300 个，目录结构、协作规范、执行流程都不需要改。
核心机制详解
1. 五步门——所有任务的标准流程
每个角色执行任务时必须走完五步门，跳步 = 不合格：
| 步骤 | 动作 | 防什么 |
|---|---|---|
| ① 查后定方案 | 先搜索现有知识和踩坑记录，再定方案 | 防盲干、防重复造轮子 |
| ② 执行 | 按方案执行，改前备份 | 防发散、防覆盖 |
| ③ 验证 | 跑测试/自检/扫描 | 防”自以为写对了” |
| ④ 反哺 | 写回 INDEX / knowledge / hot-rules | 防白干、防失忆 |
| ⑤ 交付 | 推送代码，闭环确认 | 防忘推、防半成品 |
2. 知识分层——经验跟着人走
做完任务后，经验不是随便一存，而是先判断归属：
| 归属 | 写到哪里 | 判断标准 |
|---|---|---|
| 项目特有 | 项目 docs/knowledge/ | 换个项目没用了 |
| 角色通用 | 角色 knowledge/ | 换个项目还有用 |
| 全局共享 | 共享知识/ | 换个角色还能用 |
3. 自动化脚本——让机器干机器的活
框架内置 40+ 个自动化脚本，覆盖初始化、推送、同步、归档、索引重建、协作引擎等：
| 脚本 | 用途 |
|---|---|
init.sh |
一键配置 git 用户/token/remote |
push.sh |
安全推送（commit + pull + push + 检查） |
act.sh |
意图检索 + 前科必显（1 秒索引加速） |
rebuild-index.sh |
重建搜索索引 |
archive.sh |
文件归档到回收站 |
create-repo.sh |
创建仓库 + GitHub/Gitee/Gitea 三推 |
auto-collab.sh |
自动化协作引擎（匀速/加速/并行/聚焦） |
4. 多平台容灾——单平台故障不影响安全
所有仓库配置 GitHub + Gitee + Gitea 三推送，一条 git push 推三个平台，git pull 只走 GitHub。
Gitee 和 Gitea 全部私有，绝不在公开仓库暴露任何内部信息。
我的实际使用数据
这套框架不是理论设计，是我在日常使用中一步步迭代出来的：
| 维度 | 数据 |
|---|---|
| 角色数量 | 25 个（系统开发者、ECS 运维、混音母带工程师、网文写手、动画导演……） |
| 项目数量 | 22 个（OpenDAW、OpenLink、动漫制作、网文创作……） |
| 技能数量 | 34 个 |
| Markdown 文件 | 1867 个 |
| 自动化脚本 | 40+ 个 |
| 迭代版本 | v30（从 v1 到 v30，每个版本都是踩坑换来的） |
快速上手
3 分钟启动
1 | # 1. Fork 框架 |
定制你的体系
1 | # 定义智能体身份 |
适合谁
✅ 适合：
- 用多个智能体协作开发项目的团队或个人
- 想让智能体”越用越聪明”而不是”每次从零开始”的人
- 需要跨项目、跨平台知识流通的场景
- 希望用一套统一框架管理所有智能体的知识工作者
❌ 不适合：
- 只用一个智能体做一个简单任务
- 不需要知识积累的一次性工作
开源与社区
- 仓库地址：github.com/youbanzhishi/open-knowledge-framework
- 许可证：MIT（自由使用、修改、分发）
- 协作模式：Fork → 增强 → PR 回公共仓库
欢迎 PR 回来的内容
- ✅ 通用角色/技能/项目模板改进
- ✅ 脚本 bug 修复或功能增强
- ✅ 新的通用设计模式
- ✅ 规范文档改进
留在你私有仓库的内容
- ❌ 你的私有项目内容和个人信息
- ❌ 你的凭据和密钥
- ❌ 与具体业务相关的定制
写在最后
这套框架的起点不是什么宏大的技术愿景，而是一个朴素的诉求——我不想再重复踩同一个坑了。
从最初的几条规则，到五步门，到执行门分层，到知识自动升级机制，到多角色协作网络……每一步迭代都是被真实的坑逼出来的。
今天它还在持续进化。每一次协作中的失误，都会变成体系的一部分。每一次成功的经验，都会流通到更多角色和项目。
知识不等于行为，行为不能靠自觉，要靠机制。
如果你也在用智能体干活，如果你也觉得”每次从零开始”很痛苦，试试这套框架。
Open Knowledge Framework — 让智能体从”能用”到”好用”到”自己变更好用”。
本文为作者原创 转载时请注明出处 谢谢
乱码三千 – 点滴积累 ,欢迎来到乱码三千技术博客站