一个让我反复崩溃的问题
事情是这样的。
最近我一直在折腾一个小仓库，叫 BeeWeave。
地址在这里，github.com/ptonlix/bee...
它现在还很早期，但我是真的觉得这个方向挺重要的。
因为我自己已经被同一个问题折磨很久了。
你今天用 Codex 写了一段代码，明天用 Claude Code 改一篇文章，后天又让 Gemini 帮你整理一个资料夹。每一次对话里，Agent 都很努力，甚至有些回答当下看起来还挺聪明。
但等你关掉窗口，问题就来了。
那段判断去哪了？
那次踩坑去哪了？
那篇文章里真正被你确认过的观点，下一次 Agent 还能不能用上？
很多时候答案是，不能。
挺离谱的。
我们明明每天都在跟 Agent 一起工作，但这些工作产生的高信号内容，到头来经常散在聊天记录、项目目录、浏览器收藏、Obsidian 草稿、临时 markdown、甚至某个已经找不到的终端输出里。
你想想看，这玩意像不像每天都在开会，但从来没人写纪要。
每一次都讲得热火朝天。
每一次都从头再来。
所以我写 BeeWeave 的出发点很简单，不是给 Agent 再加一个玄学记忆，也不是搞一个更复杂的知识库系统。
我就是想把创作和工作里那些真的有用的上下文，留下来，编译好，下次还能被 Agent 用上。
BeeWeave 的两个核心目录
BeeWeave 里面有两个很关键的目录。
一个叫 workbench。
一个叫 vault。
workbench 是工作台，里面放粗糙的东西。
比如临时笔记、网页剪藏、PDF、聊天导出、文章草稿、产品 brief、代码阅读记录，甚至一段你还没想清楚的想法。
它可以乱一点。
真的可以乱一点。
因为现实里的素材本来就是乱的。
另一个叫 vault。
vault 是编译后的知识层，放那些已经被整理过、可以搜索、可以链接、可以复用的 Markdown 页面。里面有 concepts、entities、skills、references、projects、synthesis，还有 index、log、hot cache 和 manifest。
这个分层我觉得非常关键。
很多知识库的问题不是不够智能，而是边界太糊了。原始材料、半成品草稿、稳定判断、项目经验，全都堆在一起。等到 Agent 一读，要么读太多，要么读错，要么读到一堆还没验证的垃圾。
BeeWeave 的思路是，把粗糙输入留在 workbench，把稳定知识放进 vault。
粗糙的就让它粗糙。
稳定的就让它稳定。
这一下，Agent 的工作方式就变了。
你不是每次都把一大坨资料塞进上下文窗口里，然后祈祷它别忘。
你是在不断跑一个循环。
获取素材，创作，沉淀，复用上下文，再获取更好的素材，再创作下一篇。
这就是 BeeWeave 想做的数据飞轮。
它和普通 LLM Wiki 的区别
这块也正好能讲清楚，BeeWeave 和普通 LLM Wiki 到底有什么区别。
我自己的理解是，普通 LLM Wiki 更像一个编译后的知识库。
它的核心价值很明确，把散落材料整理成互相关联的 Markdown 页面，让 Agent 下次不用从原始资料里重新捞一遍。这个思路非常好，我也很认同，BeeWeave 里面的 vault 就是沿着这个方向来的。
但 BeeWeave 没有停在这里。
它不是只问，我已经知道了什么。
它还会继续问，这些东西是怎么来的，下一篇内容要怎么用，写完以后哪些判断应该沉淀，沉淀以后又怎样反过来影响下一轮选题和素材收集。
这就是区别。
很多项目做的是知识库，重点在存储、检索、图谱、问答。
BeeWeave 想做的是创作和知识沉淀的一体化飞轮。
workbench 负责接住还没成型的素材。
写作 skills 负责把素材推成草稿。
published 目录负责承接已经完成的作品。
ingest 和 update 再把作品里的高信号观点沉淀回 vault。
query、digest、context pack 又把 vault 里的稳定知识拿出来，喂给下一轮创作。
你看，这就不是一个单向的知识入库动作了。
它更像一个工作流。
一个能持续转起来的工作流。
这也是我觉得 BeeWeave 有意思的地方。它不是在知识库外面再套一层创作功能，也不是在写作工具旁边挂一个资料夹。它是把素材、创作、发布、沉淀、复用放在同一条路上，让 Agent 每次参与工作时，都有机会给下一次工作留下一点更好的上下文。
写作场景里为什么刚需
说真的，我一开始最想解决的是写作。
因为写作这个事儿特别容易暴露上下文断层。
你今天为了一个选题查了十几个链接，跟 Agent 来回讨论了三轮，最终写出一篇还不错的文章。按理说，这里面有很多东西应该留下来。
比如你确认过的观点。
比如你踩掉的错误方向。
比如一个特别好用的类比。
比如读者可能会在意的反对意见。
但正常流程下，这些东西很容易随着一次对话结束就蒸发了。下次你再写相关主题，又要重新解释一遍，重新找一遍，重新说服一次 Agent。
我当时就有点绷不住。
不是哥们，我都跟 Agent 合作这么久了，怎么还像第一天认识一样？？？
BeeWeave 想把这个环节接上。
比如你看到一个网页，可以用 capture 把它丢进 workbench inbox。
比如你写了一篇草稿，可以先放在 workbench/articles/drafts。
比如你发布了一篇文章，可以再把发布稿 ingest 成 vault 里的稳定知识页。
比如你下一次要写新文章，先问一句 beeweave-query，看看我已经知道什么，哪里还有缺口。
这不是为了追求仪式感。
而是为了让每一次创作都不白费。
多 Agent 共享同一套上下文
顺着上面的再聊聊，BeeWeave 对 Agent 也很友好。
它不是只服务某一个工具。
现在 setup 支持 Claude Code、Codex、Cursor、Gemini、Kiro、Hermes、OpenClaw、Pi、Copilot CLI、Trae，还有通用 AGENTS.md 这类入口。默认全局安装的 skill 很克制，主要是 beeweave-update、beeweave-query、beeweave-ingest。
这三个就够你把循环跑起来。
其它更重的能力，比如 capture、context pack、digest、status、memory bridge，可以按需装。
我很喜欢这个设计。
因为我一直觉得，Agent skill 不应该变成到处污染项目的全局插件。很多项目只是偶尔需要查询和同步知识，不需要把完整 BeeWeave 工作流塞进去。完整能力应该留给真正的 BeeWeave 工作区，或者你明确选择的项目。
这个克制感很重要。
工具一旦没有边界，很快就会变成另一种负担。
快速开始
回到使用这块，快速开始其实很简单。
你在想创建 BeeWeave 工作区的目录里跑，
bash
pip install beeweave
bwe setupsetup 会创建 vault 和 workbench，写入 ~/.beeweave/config，然后问你要不要安装 advanced global skills，也会问你要给哪些 Agent 安装 skills 和 bootstrap 文件。
装完之后，你就可以直接在 Agent 里用，
text
/beeweave-ingest workbench/inbox
/beeweave-query what do I know about rate limiting?
/beeweave-update如果你是从源码仓库开始，也可以直接把仓库地址丢给 Agent，让它帮你初始化，
text
https://github.com/ptonlix/beeweave - set up my BeeWeave workspace它适合什么人
这块需要坦率的讲一句，BeeWeave 现在还是早期项目。
它不是那种你装完就能替你管理人生所有知识的万能产品。
不是。
它更像一个给重度 Agent 用户准备的工作台骨架。你愿意把素材、草稿、稳定知识分层，你愿意让 Agent 按流程工作，你愿意把高信号输出沉淀下来，它就会开始变得很有用。
如果你只是偶尔问两句 ChatGPT，可能暂时感受不到它的必要性。
我非常理解。
但你如果已经开始用多个 Agent 做真实工作，写文章、读代码、整理研究、做产品分析、维护项目文档，那种上下文散落的痛感应该会越来越明显。
尤其是当你发现自己第三次向 Agent 解释同一个项目背景的时候。
一时间无语凝噎。
BeeWeave 解决的就是这个问题。
它把 Agent 的一次性聪明，尽量变成可以复利的知识资产。
落到文件系统里是什么样
这个说法听起来有点大，但落到文件系统里其实很朴素。
workbench 保存原始输入。
vault 保存稳定知识。
skills 负责让不同 Agent 按同一套流程行动。
CLI 负责 setup、profile、info、graph-query、cache、batch、ast-extract 这些本地辅助操作。
浏览器扩展负责把网页和选中文本捕获到 inbox。
Obsidian 可以直接打开 vault，看 wikilinks 和图谱。
没有特别神秘的东西。
但我有时候觉得，好用的基础设施就应该这样。
它不应该总是站在台前说自己多聪明。它应该把那些很烦、很容易丢、很难坚持的流程，默默铺成一条路。
然后你走着走着，发现自己的下一次创作真的更快了。
不是因为 Agent 突然变神。
而是因为它终于不用失忆了。
欢迎使用和贡献
如果你想贡献，BeeWeave 现在也很适合下手。
仓库里已经有 Python CLI、skills、bootstrap、docs、browser extension、tests 和 OpenSpec。现在特别欢迎的方向包括更好的 ingest 策略、新的 Agent 历史导入器、vault lint 检查、图谱分析，还有围绕真实知识工作流的 focused skills。
添加一个新 skill 的路径也很直接。
在 .skills/wiki//SKILL.md 或 .skills/workbench//SKILL.md 里写好 skill，加上 name 和 description，跑 bwe setup 或 bash setup.sh，再在 Agent 里用自然触发语测试。
就这么朴素。
MIT 许可，PR welcome。
我自己也还在摸索它最好的形态。
可能有些地方还会变，可能有些流程现在看着还有点笨，可能某些 skill 的边界后面还要根据真实使用继续调整。
但这个方向我挺相信的。
我为什么相信这个方向
因为我们正在进入一个很奇怪的阶段，个人和团队每天都能调动越来越多的 Agent，但真正稀缺的东西反而变成了上下文、判断和可追溯的长期记忆。
Agent 越多，记忆断层越贵。
创作越频繁，沉淀越重要。
这也是为什么我想推荐大家试试 BeeWeave。
不是为了多装一个工具。
而是为了认真对待你和 Agent 一起工作时产生的那些东西。
那些讨论、判断、失败、草稿、链接、灵感和最终被你留下来的观点，本来就不该只活在某一次聊天窗口里。
它们应该被编织起来。
这也是 BeeWeave 这个名字想表达的东西。
像蜜蜂一样采集。
像织网一样连接。
最终变成下一次创作可以站上去的东西。
如果你也有这种痛感，可以去 GitHub 看看，顺手 star 一下，试着跑一遍 setup。
如果你已经在用 Claude Code、Codex、Cursor、Gemini 或其它 Agent 做真实工作，更建议你把自己的一个小项目接进去试试。
先不用想太复杂。
丢一点素材进去。
问一次 query。
写一篇草稿。
再把真正有价值的东西沉淀回来。
循环跑起来之后，你大概会知道我为什么兴奋。
上下文不再只是临时燃料。
它开始变成下一次创作的土壤
