BeeWeave开发中保留Agent上下文的最佳方法

一个让人反复崩溃的问题

有没有遇到过这种情况？

今天用 Codex 写了一段代码，明天用 Claude Code 改一篇文章，后天又让 Gemini 帮忙整理一个资料夹。每一次对话里，Agent 都很卖力，有些回答当下看起来还挺聪明。

但等关掉窗口，问题就来了。

那段判断去哪了？那次踩坑去哪了？那篇文章里真正被确认过的观点，下一次 Agent 还能不能用上？

很多时候答案是不能。

挺离谱的。每天都在跟 Agent 一起工作，但这些工作产生的高信号内容，到头来经常散在聊天记录、项目目录、浏览器收藏、Obsidian 草稿、临时 markdown、甚至某个已经找不到的终端输出里。

想想看，这像不像每天都在开会，但从来没人写纪要？每一次都讲得热火朝天，每一次都从头再来。

所以 BeeWea ve 的出发点很简单——不是给 Agent 再加一个玄学记忆，也不是搞一个更复杂的知识库系统。目标只有一个：把创作和工作里那些真正有用的上下文留下来，编译好，下次还能被 Agent 用上。

BeeWea ve 的两个核心目录

BeeWea ve 里面有两个很关键的目录：一个叫 workbench，一个叫 vault。

workbench 是工作台，里面放粗糙的东西。比如临时笔记、网页剪藏、PDF、聊天导出、文章草稿、产品 brief、代码阅读记录，甚至一段还没想清楚的想法。它可以乱一点——真的可以乱一点，因为现实里的素材本来就是乱的。

另一个叫 vault，是编译后的知识层，放那些已经被整理过、可以搜索、可以链接、可以复用的 Markdown 页面。里面有 concepts、entities、skills、references、projects、synthesis，还有 index、log、hot cache 和 manifest。

这个分层非常关键。很多知识库的问题不是不够智能，而是边界太糊了——原始材料、半成品草稿、稳定判断、项目经验，全都堆在一起。等到 Agent 一读，要么读太多，要么读错，要么读到一堆还没验证的垃圾。

BeeWea ve 的思路是：把粗糙输入留在 workbench，把稳定知识放进 vault。粗糙的就让它粗糙，稳定的就让它稳定。这样一来，Agent 的工作方式就变了——不是每次都把一大坨资料塞进上下文窗口，然后祈祷它别忘，而是在不断跑一个循环：获取素材，创作，沉淀，复用上下文，再获取更好的素材，再创作下一篇。这就是 BeeWea ve 想做的数据飞轮。

它和普通 LLM Wiki 的区别

这块也正好能讲清楚，BeeWea ve 和普通 LLM Wiki 到底有什么区别。

普通 LLM Wiki 更像一个编译后的知识库。它的核心价值很明确：把散落材料整理成互相关联的 Markdown 页面，让 Agent 下次不用从原始资料里重新捞一遍。这个思路非常好，BeeWea ve 里面的 vault 就是沿着这个方向来的。

但 BeeWea ve 没有停在这里。它不是只问“我已经知道了什么”，它还会继续问：这些东西是怎么来的？下一篇内容要怎么用？写完以后哪些判断应该沉淀？沉淀以后又怎样反过来影响下一轮选题和素材收集？

这就是区别。很多项目做的是知识库，重点在存储、检索、图谱、问答。BeeWea ve 想做的是创作和知识沉淀的一体化飞轮。

workbench 负责接住还没成型的素材；写作 skills 负责把素材推成草稿；published 目录负责承接已经完成的作品；ingest 和 update 再把作品里的高信号观点沉淀回 vault；query、digest、context pack 又把 vault 里的稳定知识拿出来，喂给下一轮创作。

这就不是一个单向的知识入库动作了。它更像一个工作流——一个能持续转起来的工作流。它不是在知识库外面再套一层创作功能，也不是在写作工具旁边挂一个资料夹，而是把素材、创作、发布、沉淀、复用放在同一条路上，让 Agent 每次参与工作时，都有机会给下一次工作留下一点更好的上下文。

写作场景里为什么刚需

最开始最想解决的是写作，因为写作这个事儿特别容易暴露上下文断层。

今天为了一个选题查了十几个链接，跟 Agent 来回讨论了三轮，最终写出一篇还不错的文章。按理说，这里面有很多东西应该留下来：确认过的观点、踩掉的错误方向、特别好用的类比、读者可能会在意的反对意见。但正常流程下，这些东西很容易随着一次对话结束就蒸发了。下次再写相关主题，又要重新解释一遍，重新找一遍，重新说服一次 Agent。

BeeWea ve 想把这个环节接上。比如看到一个网页，可以用 capture 把它丢进 workbench inbox；写完一篇草稿，可以先放在 workbench/articles/drafts；发布一篇文章，可以再把发布稿 ingest 成 vault 里的稳定知识页；下一次要写新文章，先问一句 beewea ve-query，看看已经知道什么，哪里还有缺口。

这不是为了追求仪式感，而是为了让每一次创作都不白费。

多 Agent 共享同一套上下文

顺着上面的再聊聊，BeeWea ve 对 Agent 也很友好。它不是只服务某一个工具。

现在 setup 支持 Claude Code、Codex、Cursor、Gemini、Kiro、Hermes、OpenClaw、Pi、Copilot CLI、Trae，还有通用 AGENTS.md 这类入口。默认全局安装的 skill 很克制，主要是 beewea ve-update、beewea ve-query、beewea ve-ingest 这三个，足够把循环跑起来。其它更重的能力，比如 capture、context pack、digest、status、memory bridge，可以按需装。

这个设计很值得注意。Agent skill 不应该变成到处污染项目的全局插件。很多项目只是偶尔需要查询和同步知识，不需要把完整 BeeWea ve 工作流塞进去。完整能力应该留给真正的 BeeWea ve 工作区，或者明确选择的项目。工具一旦没有边界，很快就会变成另一种负担。这种克制感很重要。

快速开始

回到使用这块，快速开始其实很简单。

在想要创建 BeeWea ve 工作区的目录里跑：

pip install beewea ve
bwe setup

setup 会创建 vault 和 workbench，写入 ~/.beewea ve/config，然后问要不要安装 advanced global skills，也会问要给哪些 Agent 安装 skills 和 bootstrap 文件。

装完之后就可以直接在 Agent 里用：

/beewea ve-ingest workbench/inbox/
beewea ve-query what do I know about rate limiting?
/beewea ve-update

如果是从源码仓库开始，也可以直接把仓库地址丢给 Agent，让它帮忙初始化。

它适合什么人

需要坦率地讲一句，BeeWea ve 现在还是早期项目。它不是那种装完就能替你管理人生所有知识的万能产品。

它更像一个给重度 Agent 用户准备的工作台骨架。愿意把素材、草稿、稳定知识分层，愿意让 Agent 按流程工作，愿意把高信号输出沉淀下来，它就会开始变得很有用。如果只是偶尔问两句 ChatGPT，可能暂时感受不到它的必要性——这完全理解。

但如果已经开始用多个 Agent 做真实工作——写文章、读代码、整理研究、做产品分析、维护项目文档——那种上下文散落的痛感会越来越明显。尤其是当第三次向 Agent 解释同一个项目背景的时候。

BeeWea ve 解决的就是这个问题：把 Agent 的一次性聪明，尽量变成可以复利的知识资产。

落到文件系统里是什么样

这个说法听起来有点大，但落到文件系统里其实很朴素。

workbench 保存原始输入。vault 保存稳定知识。skills 负责让不同 Agent 按同一套流程行动。CLI 负责 setup、profile、info、graph-query、cache、batch、ast-extract 这些本地辅助操作。浏览器扩展负责把网页和选中文本捕获到 inbox。Obsidian 可以直接打开 vault，看 wikilinks 和图谱。

没有特别神秘的东西。但好用的基础设施就应该这样——它不应该总是站在台前说自己多聪明，而应该把那些很烦、很容易丢、很难坚持的流程，默默铺成一条路。然后走着走着，发现下一次创作真的更快了。不是因为 Agent 突然变神，而是因为它终于不用失忆了。

欢迎使用和贡献

如果想贡献，BeeWea ve 现在也很适合下手。仓库里已经有 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 越多，记忆断层越贵。创作越频繁，沉淀越重要。

这也是为什么推荐大家试试 BeeWea ve——不是为了多装一个工具，而是为了认真对待和 Agent 一起工作时产生的那些东西。那些讨论、判断、失败、草稿、链接、灵感和最终被留下来的观点，本来就不该只活在某一次聊天窗口里。它们应该被编织起来。

这也是 BeeWea ve 这个名字想表达的东西：像蜜蜂一样采集，像织网一样连接，最终变成下一次创作可以站上去的东西。

如果有这种痛感，可以去 GitHub 看看，试着跑一遍 setup。如果已经在用 Claude Code、Codex、Cursor、Gemini 或其它 Agent 做真实工作，更建议把自己的一个小项目接进去试试。先不用想太复杂——丢一点素材进去，问一次 query，写一篇草稿，再把真正有价值的东西沉淀回来。

循环跑起来之后，大概就会知道为什么这个方向值得兴奋。上下文不再只是临时燃料，它开始变成下一次创作的土壤。