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

事情是这样的。

过去一段时间，在持续使用 Claude Code、Codex、OpenClaw 这些 Agent 做研究、写文章、整理知识。它们很强，真的很强。你把资料扔进去，它能总结；给一个主题，它能起草；让它分析一个仓库，它也能很快摸清结构。

但一个反复出现的困扰是：每开一个新会话，很多事情都要重新讲一遍。

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

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

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

所以有了 BeeWea ve。

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

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

像蜜蜂采蜜，也像把一根根散线织成网。这就是 BeeWea ve 这个名字的来历。

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

很多人看到知识库和 Agent 放在一起，第一反应可能是 Agent Memory。一开始也容易顺着这个方向想，但做着做着，越来越觉得，只有记忆还不够。

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

你收藏了两百篇文章，真正写稿时还是从空白页开始。你和 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 页面。

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

这个循环大概是这样：

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

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

这才是想要的数据飞轮。

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

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

BeeWea ve 选择把知识留在普通的 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 个按钮

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

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

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

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

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

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

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

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

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

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

写完后，草稿被保存成 Markdown 文件，进入 workbench/articles/drafts/，并做了一轮禁用词、结构、内容和活人感检查。然后，看完草稿又补了一条反馈：“使用 BeeWea ve 的典型案例，就是你在写的这篇内容。” 于是 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 安装 Skills 和项目规则。

安装完成后，可以先查看当前信息：bwe info。如果手里已经有一些资料，把它们放进 workbench/inbox/，然后在 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。它强调的是蒸馏和复用，不是单纯囤积。

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

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

我为什么现在把它开源

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

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

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

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

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

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