BeeWeave开源：为AI Agent打造越用越懂你的知识创作台

故事的起点，源于一段真实的体验。

在过去的一段时间里，我持续使用 Claude Code、Codex、OpenClaw 这类 AI Agent 进行调研、内容创作和知识整理。它们确实很强大，真的很强大。你丢给它一堆资料，它能快速提炼总结；给它一个主题，它能起草初稿；让它分析一个代码仓库，它也能迅速摸清整体架构。

但有一个反复出现的困扰：每次开启一个新会话，许多事情都要从头再讲一遍。

我之前研究过什么，对某个问题形成了哪些判断，上一篇文章遗留下了哪些线索，哪些资料可信，哪些坑已经踩过——Agent 往往对此一无所知。上一轮对话聊得热火朝天，窗口一关闭，下一轮对话又像初次见面一样陌生。

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

一两天还能忍受，时间一长，真的让人精疲力尽。

因此，便有了 BeeWea ve。

它并非另一个聊天机器人，也不是给 Markdown 文件简单套上一层搜索框。BeeWea ve 是一个为 AI Agent 原生打造的知识创作平台，旨在解决一件更具体的事：让素材获取、内容创作、知识沉淀和上下文复用，形成一个持续运转的完整闭环。

收集，创作，沉淀，复用，然后再去收集更优质的材料。

如同蜜蜂采蜜，也像将一根根零散的线编织成网。这正是 BeeWea ve 这个名字的由来。

我真正想解决的，并非单纯的记忆问题

很多人看到知识库与 AI Agent 结合，第一反应可能是“Agent 记忆”功能。一开始我也容易顺着这个思路去思考，但做着做着，我越来越觉得，仅有记忆是远远不够的。

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

你收藏了两百篇文章，但真正动笔写作时，依然是从空白页面开始。你和 Agent 聊了十几个小时，换到另一个 Agent，之前形成的判断又无法传递过去。你完成了一个项目，经验却散落在对话、代码注释、会议记录和你的脑海里，过上两个月，还得重新“考古”挖掘。

这才是真正让人感到难受的地方。

知识工作并非将信息存储起来就结束了。它至少还需要经历筛选、创作、验证、沉淀以及再次调用这几个环节。少了其中任何一环，所谓的知识库很容易变成一个装修精美的仓库——东西都在，却拿不出来。

BeeWea ve 想要做的，不是替 Agent 保存所有东西，而是建立一套完整的知识生产流程。原始材料可以粗糙，草稿可以反复修改，但最终沉淀下来的内容，应当是稳定、可链接、可查询，并且能够被不同的 Agent 再次使用。

这个区别至关重要。记忆关注的是“别忘了”，而 BeeWea ve 更关心的是“下一次能不能做得更好”。

两个目录，将混乱与知识清晰分离

BeeWea ve 的核心结构其实并不复杂，甚至有些朴素。整个工作区主要划分为两个部分：

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

workbench/ 是创作台。网页剪藏、临时灵感、对话导出、文章草稿、演示文稿以及待处理资料都先放置在这里。这个区域允许混乱，也允许内容不完整——因为真实的创作过程，本来就不是一开始就井井有条的。

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

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

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

所以，BeeWea ve 接受一个事实：输入阶段应该足够随意，而知识层则必须足够克制。一边承接混乱，一边保护质量。这两个目录，就是整个系统最基础的边界。

它是如何运转起来的

BeeWea ve 并非一条简单将文件从 A 搬到 B 的流水线，而是一个循环。

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

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

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

下一次开始写作或研究前，AI Agent 会先查询这个 vault。于是，新的任务不再从零开始，而是站在过去积累的上下文上继续前行。查询时如果发现证据不足，又会暴露出新的问题，指引下一轮的材料收集。

这个循环大致如下：

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

真正产生复利的，并非某一篇笔记，而是每一次工作都能为下一次工作留下一点东西。一篇文章不只是发布完就结束了，它还会变成后续研究的知识来源。一次项目复盘也不只是躺在归档目录里，它可以在下一次遇到类似决策时，被 Agent 找回来。

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

并非绑定某一个 Agent，而是让它们共享一套上下文

这两年，AI Agent 的更新迭代实在太快了。今天你可能主要用 Claude Code，明天 Codex 的某项能力更顺手，后天又将一部分自动化任务交给了 OpenClaw。工具切换本身并没什么，我甚至觉得这已经是常态。真正麻烦的是，每换一个工具，知识也跟着被锁在了里面。

BeeWea ve 选择将知识存放在普通的 Markdown 文件中，把工作方法做成 Agent 技能，再通过各个 Agent 支持的规则和技能入口接入。当前，bwe setup 支持 Claude Code、Codex、Cursor、Gemini、Kiro、Hermes、OpenClaw、Pi、GitHub Copilot CLI、Windsurf、Trae 以及通用 AGENTS.md Agent 等目标。

同一个 vault，可以被不同的 AI Agent 查询；同一套知识整理流程，也可以在不同的环境里调用。这一点我坚持得很彻底——模型会变，Agent 产品会变，今天流行的交互入口也会变，但你积累的文章、概念、项目判断和引用关系，不应该跟着某个产品一起消失。

Markdown 看起来不够花哨，甚至有些老派。但它透明、可迁移、可进行 Git 管理，也能直接用 Obsidian 打开。老派，有时反而意味着一种安全感。

41 项技能，不是 41 个需要记忆的按钮

BeeWea ve 0.5.1 当前内置了 41 项技能。看到这个数字，可能有朋友会觉得，完了，又是一套需要背诵命令的复杂系统。我非常理解这种感受——我自己也不喜欢为了用工具，先读上一百页说明书。BeeWea ve 的设计方向，不是让人记住 41 条命令，而是让 AI Agent 根据自然语言任务，自动调用合适的工作流程。

最核心的三个操作其实很好理解：

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

beewea ve-ingest 负责将输入材料蒸馏成可复用的知识。beewea ve-query 负责在开始工作前，从已有知识中取回相关上下文。beewea ve-update 负责将项目里新形成的稳定经验同步回来。

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

你正在读的这篇文章，就是一个真实案例

讲了这么多工作流，还是用一个正在发生的例子来展示最直接——就是你现在看到的这篇文章。

我没有从一个空白对话框开始，也没有把 BeeWea ve 的项目资料和写作要求全部重新复制给 AI Agent。首先，我将过去已经发布的一篇关于 GoHumanLoop 的文章，放入 workbench/articles/published/，将其作为这次写作的风格参考。然后，我只提出了一个任务：根据这篇文章的写法，撰写一篇介绍 BeeWea ve 开源项目的文章，并将草稿放进 workbench/articles/drafts/。

AI Agent 收到任务后，先读取了那篇 GoHumanLoop 文章，拆解出它的推进方式：项目介绍，问题场景，实现机制，安装运行，再回到使用效果和边界。接着，它并没有只凭一句描述硬写，而是去核对 BeeWea ve 的项目说明、本机安装版本、CLI 命令、内置技能、支持的 Agent 以及 GitHub 远程仓库。确认事实后，再将这些信息重新组织成了现在这篇文章。

这一步特别关键：参考文章提供的是“我习惯怎么讲”，项目资料提供的是“这次到底要讲什么”。一个负责风格和结构，一个负责事实，二者都留存在工作区里，不需要每次手动拼成一大段提示词。

写完后，草稿被保存为 Markdown 文件，进入 workbench/articles/drafts/，并执行了一轮禁用词、结构、内容和“活人感”检查。然后，我阅读草稿后又补了一条反馈：“使用 BeeWea ve 的典型案例，就是你在写的这篇内容。” 于是，AI Agent 回到同一份草稿，保留了前面的结构，补上了你现在读到的这一节。

你敢信？一篇介绍 BeeWea ve 的文章，正在用 BeeWea ve 的工作流完成它自己。

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

从旧文章中复用写法，基于项目事实生成新稿，根据人的反馈继续修改，发布后再把成果沉淀回知识库。这一整圈跑下来，BeeWea ve 想做的事就不再只是一张架构图了——它真的发生在了这篇文章里。有点套娃，但我还挺喜欢这个套娃，因为系统真的开始用自己的输出来改进下一轮的输入了。

从安装到第一次查询

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

pip install beewea vebwe setup

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

安装完成后，可以先查看当前信息：bwe info。如果手里已经有一些资料，将它们放入 workbench/inbox/，然后在 AI Agent 中调用 ingest：/beewea ve-ingest workbench/inbox。等 vault 中有了内容，就可以开始查询：/beewea ve-query 我对 Human-in-the-loop 已经形成了哪些观点。

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

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

当然，说得轻松，不代表知识库会自动长好。刚开始使用时，分类可能不合适，标签也可能混乱，Agent 蒸馏出来的页面需要人工判断。素材越多，去重、链接和质量控制就越重要。BeeWea ve 提供了 lint、dedup、cross-linker、stage-commit 和 graph analyse 等流程，但它不会替你决定什么知识真正重要。这件事必须诚实：工具可以降低维护成本，却不能替代你的判断力。

它适合谁，又不适合谁

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

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

但如果你长期使用多个 AI Agent，持续写文章、做研究、开发产品或推进项目，它会更有价值。尤其是以下几类人，应该很容易理解为什么要做它：你在 Claude Code 里完成了研究，却想把上下文带给 Codex；你写了几十篇文章，却发现每次选题仍在重复查资料；你有一个很大的 Obsidian 仓库，但 AI Agent 不知道该从哪里读起；你做完项目积累了很多经验，可下一次真正需要时又想不起来。

我自己就是这些问题的集合体。所以，BeeWea ve 并非从一个宏大的知识管理理论开始的，它是从一次次重复解释、重复搜索和重复遗忘里长出来的。先解决自己的痛点，再看看能不能帮到有相似困扰的人。

我为什么现在将它开源

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

但我还是决定现在就把它开源。因为知识工作这件事，不应该只围绕某一个模型、某一家平台或某一种笔记习惯来设计。大家使用 AI Agent 的方式差异很大——有人写作，有人开发，有人做学术研究，也有人管理一家公司的项目知识。闭门造车，想把流程想得完美，基本不可能。

BeeWea ve 更像一个可以共同试验的底座。你可以贡献更好的 ingest 策略、新的 Agent 历史导入器、vault 质量检查、图谱分析，也可以为某个真实工作场景打造一项足够专注的技能。该仓库采用 MIT 许可证，代码、技能、bootstrap 模板和浏览器捕获扩展都在 GitHub 上。

如果你愿意尝试，欢迎将 BeeWea ve 真正安装起来，用自己的资料跑一轮。只有进入真实的写作、研究和项目现场，它的问题和价值才会暴露出来。如果你觉得这个方向有点意思，欢迎到 GitHub 点一个 Star。遇到 Bug、流程不顺或文档看不懂，欢迎直接提 Issue。你要是愿意贡献代码、文档、新的 Agent 适配或一个真实好用的技能，更欢迎提交 Pull Request。

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

我不敢说这已经是 AI Agent 时代知识管理的最终答案。说实话，我们离得还远。但我始终坚信一件事：未来真正拉开差距的，不只是你用了多强的模型，还包括你有没有把每一次工作留下的东西，变成下一次工作的起点。模型每天都在变强，属于你的上下文，也该开始生长了。