我开源了 BeeWeave，给 AI Agent 搭一个越用越懂你的知识创作台

GitHub 项目地址 ： github.com/ptonlix/bee...

事情是这样的。

过去一段时间，我一直在用 Claude Code、Codex、OpenClaw 这些 Agent 做研究、写文章、整理知识。

它们很强，真的很强。你把资料扔进去，它能总结。你给一个主题，它能起草。你让它分析一个仓库，它也能很快摸清结构。

但我反复遇到一个很烦的问题。

每开一个新会话，很多事情都要重新讲一遍。

我以前研究过什么，我对某个问题已经形成了什么判断，上一篇文章留下了哪些线索，哪些资料可信，哪些坑已经踩过，Agent 往往不知道。上一轮对话里聊得热火朝天，窗口一关，下一轮又像第一次见面。

这种感觉有点像，你每次去公司，都要给一个能力很强的新同事重新做入职培训。

一天两天还能忍。时间长了，真的顶不住。。

所以我做了 BeeWeave。

它不是另一个聊天机器人，也不是给 Markdown 文件套一层搜索框。BeeWeave 是一个 Agent 原生的知识创作台，想解决的是一件更具体的事，让素材获取、内容创作、知识沉淀和上下文复用连成一个持续运转的闭环。

收集，创作，沉淀，复用，再去收集更好的材料。

像蜜蜂采蜜，也像把一根根散线织成网。

这就是 BeeWeave 这个名字的来历。

我真正想解决的，不是记忆

很多人看到知识库和 Agent 放在一起，第一反应可能是 Agent Memory。

我一开始也很容易顺着这个方向想。但做着做着，我越来越觉得，只有记忆还不够。

聊天记录当然是一种记忆。收藏夹也是，网页剪藏也是，几十个塞满资料的文件夹也是。问题在于，记住不等于能用。

你收藏了两百篇文章，真正写稿时还是从空白页开始。你和 Agent 聊了十几个小时，换到另一个 Agent，之前形成的判断又带不过去。你做完一个项目，经验散在对话、代码注释、会议记录和脑子里，过两个月还得重新考古。

这才是让我难受的地方。

知识工作不是把信息存进去就结束了。它至少还要经历筛选、创作、验证、沉淀和再次调用。少了其中一环，所谓的知识库很容易变成一个装修精美的仓库。

东西都在。

就是拿不出来。

BeeWeave 想做的不是替 Agent 保存所有东西，而是建立一套知识生产流程。原始材料可以粗糙，草稿可以反复改，但最终沉淀下来的内容，应该稳定、可链接、可查询，也能被不同 Agent 重新使用。

我觉得这个区别挺重要。

记忆关注的是「别忘了」。BeeWeave 更关心「下一次能不能做得更好」。

两个目录，把混乱和知识分开

BeeWeave 的核心结构其实不复杂，甚至有点朴素。

整个工作区主要分成两个部分。

project/
├── workbench/
│   ├── inbox/
│   ├── articles/
│   ├── ppt/
│   └── library/
└── vault/
    ├── concepts/
    ├── entities/
    ├── references/
    ├── synthesis/
    ├── projects/
    └── _staging/

workbench/ 是创作台。

网页剪藏、临时想法、对话导出、文章草稿、演示文稿和待处理资料都先放在这里。这个区域允许混乱，也允许内容不完整。因为真实的创作过程，本来就不是一上来便井井有条。

vault/ 是编译后的知识层。

只有相对稳定、以后还值得复用的内容，才会进入这里。它们会被整理成概念、实体、引用、项目记录和综合分析，并通过 Markdown 与 Wikilink 连接起来。

为什么一定要分两层？

因为我踩过一个很典型的坑。只要所有材料都直接进入知识库，知识库迟早会被半成品淹没。随手记的一句话、网页原文、重复观点和真正形成的判断混在一起，搜索结果看着很多，能直接拿来用的却很少。

反过来，如果要求每条输入一开始就整理得很漂亮，捕获成本又会高得离谱。看到一个有意思的东西，还得先想分类、标签和归档位置，到头来大概率变成「等有空再整理」。

然后就没有然后了。。。

所以 BeeWeave 接受一个事实，输入阶段应该足够随意，知识层则必须足够克制。

一边承接混乱，一边保护质量。

这两个目录，就是整个系统最基础的边界。

它怎么跑起来

BeeWeave 不是一条把文件从 A 搬到 B 的流水线，而是一个循环。

先把网页、笔记、PDF、会话记录或项目发现放进 workbench/inbox/。材料不需要精修，先接住再说。

然后让 Agent 基于这些材料进行研究或创作。长文草稿进入 workbench/articles/drafts/，短内容、演示文稿和资料也有各自的位置。这里不是知识的终点，而是观点真正发生碰撞的地方。

等文章发布，或者项目中的某个判断已经稳定，再把高信号内容蒸馏进 vault/。BeeWeave 会把可复用的概念、事实、关系和项目经验组织成互相连接的 Markdown 页面。

下一次开始写作或研究前，Agent 先查询这个 vault。

于是新的任务不再从零开始，而是站在过去积累的上下文上继续往前走。查询时发现证据不足，又会暴露新的问题，指引下一轮材料收集。

这个循环大概是这样。

收集素材
   ↓
Agent 参与研究与创作
   ↓
把稳定知识编译进 vault
   ↓
下一次任务先查询已有知识
   ↓
发现缺口，再收集更好的材料

你想想看，真正产生复利的不是某一篇笔记，而是每一次工作都能给下一次工作留下一点东西。

一篇文章不只是发布完就结束。它还会变成后续研究的知识来源。一次项目复盘也不只是躺在归档目录里，它可以在下一次遇到类似决策时被 Agent 找回来。

这才是我想要的数据飞轮。

不是绑定一个 Agent，而是让它们共用一套上下文

这两年 Agent 更新得太快了。

今天你可能主要用 Claude Code，明天 Codex 某项能力更顺手，后天又把一部分自动化交给 OpenClaw。工具切换本身没什么，我甚至觉得这是常态。

真正麻烦的是，每换一个工具，知识也跟着被锁在里面。

BeeWeave 选择把知识留在普通的 Markdown 文件中，把工作方法做成 Agent Skills，再通过各个 Agent 支持的规则和技能入口接进去。

当前 bwe setup 支持 Claude Code、Codex、Cursor、Gemini、Kiro、Hermes、OpenClaw、Pi、GitHub Copilot CLI、Windsurf、Trae 和通用 AGENTS.md Agent 等目标。

同一个 vault，可以被不同 Agent 查询。同一套知识整理流程，也可以在不同环境里调用。

这块我非常坚持。

模型会变，Agent 产品会变，今天流行的交互入口也会变。但你积累的文章、概念、项目判断和引用关系，不应该跟着某个产品一起消失。

Markdown 看起来不花哨，甚至有点老派。可它透明、可迁移、可 Git 管理，也能直接用 Obsidian 打开。

老派有时候反而是一种安全感。

41 个 Skills，不是 41 个按钮

BeeWeave 0.5.1 当前内置了 41 个 Skills。

看到这个数字，可能有朋友会觉得，完了，又是一套需要背命令的复杂系统。

我非常理解这种感觉。我自己也不喜欢为了用工具先读一百页说明书。BeeWeave 的设计方向不是让人记住 41 条命令，而是让 Agent 根据自然任务调用合适的工作流程。

最核心的三个动作其实很好理解。

/beeweave-ingest workbench/inbox
/beeweave-query 我对 Agent 上下文工程已经知道什么
/beeweave-update

beeweave-ingest 负责把输入材料蒸馏成可复用知识。

beeweave-query 负责在开始工作前，从已有知识中取回相关上下文。

beeweave-update 负责把项目里新形成的稳定经验同步回来。

围绕这三个动作，BeeWeave 还提供网页捕获、长文写作、社交内容改写、文章发布、知识综合、去重、交叉链接、图谱分析、状态检查、历史会话导入和上下文打包等 Skills。

你正在看的文章，就是一个真实案例

讲了这么多工作流，还是拿一个正在发生的例子最直接。

就是你现在看到的这篇文章。

我没有从一个空白对话框开始，也没有把 BeeWeave 的项目资料和写作要求全部重新复制给 Agent。我先把过去已经发布的一篇 GoHumanLoop 文章放在 workbench/articles/published/，把它作为这次写作的风格参考。

然后我只提出了一个任务，根据这篇文章的写法，写一篇介绍 BeeWeave 开源项目的文章，并把草稿放进 workbench/articles/drafts/。

Agent 收到任务后，先读取那篇 GoHumanLoop 文章，拆出它的推进方式。项目介绍，问题场景，实现机制，安装运行，再回到使用效果和边界。

接着，它没有只凭我的一句描述硬写，而是去核对 BeeWeave 的项目说明、本机安装版本、CLI 命令、内置 Skills、支持的 Agent 和 GitHub 远程仓库。确认事实后，再把这些信息重新组织成现在这篇文章。

这一步我觉得特别关键。

参考文章提供的是「我习惯怎么讲」，项目资料提供的是「这次到底要讲什么」。一个负责风格和结构，一个负责事实，二者都留在工作区里，不需要我每次手动拼成一大段 Prompt。

写完后，草稿被保存成 Markdown 文件，进入 workbench/articles/drafts/，并做了一轮禁用词、结构、内容和活人感检查。

然后，我看完草稿又补了一条反馈。

「使用 BeeWeave 的典型案例，就是你在写的这篇内容。」

于是 Agent 回到同一份草稿，保留前面的结构，补上了你现在读到的这一节。

你敢信？？？

一篇介绍 BeeWeave 的文章，正在用 BeeWeave 的工作流完成自己。

现在它还只是一份草稿。等我确认发布，它会进入 workbench/articles/published/。发布后的文章还可以继续被 ingest 回 vault，里面关于 Agent 原生知识创作台、workbench 与 vault 双层结构、跨 Agent 上下文复用的稳定内容，会成为下一次写作和研究可以直接调用的知识。

从旧文章中复用写法，基于项目事实生成新稿，根据人的反馈继续修改，发布后再把成果沉淀回知识库。

这一整圈跑下来，BeeWeave 想做的事就不再是一张架构图了。

它真的发生在了这篇文章里。

有点套娃。

但这个套娃我还挺喜欢，因为系统真的开始用自己的输出改进下一轮输入了。

从安装到第一次查询

BeeWeave 已经发布到 PyPI，要求 Python 3.9 或更高版本。最快的安装方式只有两步。

pip install beeweave
bwe setup

在你准备作为知识工作区的目录中运行 bwe setup，它会创建 vault/ 和 workbench/，写入 BeeWeave 配置，并询问要为哪些 Agent 安装 Skills 和项目规则。

安装完成后，可以先查看当前信息。

bwe info

如果手里已经有一些资料，把它们放进 workbench/inbox/，然后在 Agent 中调用 ingest。

/beeweave-ingest workbench/inbox

等 vault 中有了内容，就可以开始查询。

/beeweave-query 我对 Human-in-the-loop 已经形成了哪些观点

如果你有工作和个人两套知识库，也可以创建命名 profile，用 @work 或 @research 把单次请求路由到指定工作区，不需要来回修改默认配置。

整个过程没有数据库服务要维护，也没有必须购买的云端存储。核心资产就是你本地的一组 Markdown 文件。

当然，我说得轻松，不代表知识库会自动长好。

刚开始用时，分类可能不合适，标签也可能混乱，Agent 蒸馏出来的页面需要人工判断。素材越多，去重、链接和质量控制越重要。BeeWeave 提供了 lint、dedup、cross-linker、stage-commit 和 graph analyse 等流程，但它不会替你决定什么知识真正重要。

这件事必须诚实。

工具可以降低维护成本，却不能替代判断力。

它适合谁，又不适合谁

如果你只想和模型临时聊几句，聊完就走，BeeWeave 可能太重了。新建两个目录、维护一套 vault，反而增加负担。

如果你习惯把所有资料丢进一个搜索产品，只要能搜到原文就满足，那也不一定需要 BeeWeave。它强调的是蒸馏和复用，不是单纯囤积。

但如果你长期使用多个 Agent，持续写文章、做研究、开发产品或推进项目，它会更有价值。

尤其是下面这类人，应该很容易理解我为什么要做它。

你在 Claude Code 里完成了研究，却想把上下文带给 Codex。你写了几十篇文章，却发现每次选题仍在重复查资料。你有一个很大的 Obsidian 仓库，但 Agent 不知道该从哪里读起。你做完项目积累了很多经验，可下一次真正需要时又想不起来。

我自己就是这些问题的集合体。。

所以 BeeWeave 并不是从一个宏大的知识管理理论开始的。它是从一次次重复解释、重复搜索和重复遗忘里长出来的。

先解决我自己的痛点，再看看能不能帮到有相似困扰的人。

我为什么现在把它开源

坦率的讲，BeeWeave 还很早。

它现在是 Beta 阶段，很多流程还有继续打磨的空间。不同 Agent 对 Skills 的支持方式不完全一样，大规模 vault 的检索质量也会受到内容结构、标签和可选语义搜索配置影响。工作流越复杂，越需要使用者理解 workbench/ 与 vault/ 的边界。

但我还是决定现在把它开源。

因为知识工作这件事，不应该只围绕某一个模型、某一家平台或某一种笔记习惯来设计。大家用 Agent 的方式差异很大，有人写作，有人开发，有人做学术研究，也有人管理一家公司的项目知识。

闭门把流程想完整，基本不可能。

BeeWeave 更像一个可以共同试验的底座。你可以贡献更好的 ingest 策略、新的 Agent 历史导入器、vault 质量检查、图谱分析，也可以为某个真实工作场景做一项足够专注的 Skill。

仓库采用 MIT License，代码、Skills、bootstrap 模板和浏览器捕获扩展都在 GitHub 上。

如果你愿意尝试，欢迎把 BeeWeave 真正装起来，用自己的资料跑一轮。只有进入真实的写作、研究和项目现场，它的问题和价值才会暴露出来。

如果你觉得这个方向有点意思，欢迎到 GitHub 点一个 Star。遇到 Bug、流程不顺或文档看不懂，欢迎直接提 Issue。你要是愿意贡献代码、文档、新的 Agent 适配或一个真实好用的 Skill，更欢迎提交 PR。

使用、Star、Issue、PR，都欢迎。

开源项目不是作者一个人关在房间里想出来的，它是在真实使用和一次次反馈里长出来的。你留下的每一个问题和改进，都可能让下一个使用 BeeWeave 的人少踩一个坑。

我不敢说这已经是 Agent 时代知识管理的答案。

说实话，我们还差得远。

但我始终坚信一件事。未来真正拉开差距的，不只是你用了多强的模型，还包括你有没有把每一次工作留下的东西，变成下一次工作的起点。

模型每天都在变强。

属于你的上下文，也该开始生长了。

GitHub 项目地址

github.com/ptonlix/bee...