把 AI 放进知识库，但别交出整座仓库：Brainstorm 的本地优先桌面与能力账本
很多“AI 知识库”产品的默认路径是：把笔记、文件和向量索引交给云端，再让模型在整份工作区里检索。它用起来快，却把一个常被忽略的问题留给了用户：当笔记里同时有项目方案、客户资料、私钥线索和私人记录时，究竟是谁决定一个 Agent 能读到什么？
Brainstorm 是一个仍处于 Beta 阶段的本地优先桌面软件。它把笔记、数据库、任务、日历、文件、图谱等应用放进同一个桌面，但把“AI 可以碰哪些数据”当成底层架构问题，而不是聊天框的权限开关。项目以 AGPL-3.0-or-later 发布；官网当前下载页列出 v0.12.0，支持 macOS、Windows 与 Linux。
不是把所有应用塞进一个壳
Brainstorm 的资料模型很直接：数据保存在自己磁盘上的 vault 中，不同应用读取和写入同一组对象。一条笔记可以在 Graph 中表现为节点，在 Database 中成为一行；这不是把内容复制到多个应用，而是同一份对象的不同视图。同步是可选的，官方描述其端到端加密 relay 只处理加密后的字节。
这种组织方式对知识管理很实用，但也扩大了 AI 的潜在读取面。一个能替你整理会议纪要的 Agent，若天然拥有整个 vault 的访问权，也可能顺手读到与任务无关的资料。Brainstorm 的设计把这个风险拆成三层：
- 应用层：每个应用在独立沙箱窗口运行，并声明需要的能力；
- Shell 层：Electron 主进程和受信任的 dashboard renderer 管理窗口、应用注册表与能力账本；
- 核心服务层：存储、文档和搜索在隔离 worker 进程中运行。
关键不是“应用有没有一个权限对话框”，而是每一次宿主服务调用都会经过 IPC broker。调用带着调用者身份；broker 检查 vault 内可撤销、可记录的授权，再决定是否转发。官方 README 明确把无法验证的请求处理为不可用，而不是默认放行。这是一种 fail closed 的边界：系统不知道你是否有权，就不把数据交出去。
能力账本怎样改变 Agent 的使用方式
传统插件式知识库常把授权建模为“插件装上了，所以它能访问工作区”。能力账本更像一次显式委托：应用或 AI 要访问的对象、服务和范围都应被授予，并留下记录。对开发者而言，这让权限不再只是一份隐含配置，而是可以审查和撤销的系统状态。
可以把一个整理项目资料的流程拆成下面三步：
- 在 vault 中建立项目笔记、任务和文件对象；
- 仅给负责该项目的应用或 Agent 授予读取这些对象、写入草稿的能力；
- 审阅 Agent 生成的对象后再确认保留，而不是让它直接修改所有资料。
Brainstorm 当前发布说明也体现了这个“先提议、再批准”的方向：Agent 可以把笔记、任务、事件、书签或联系人作为草稿对象写入 vault，用户决定保留哪些内容。它降低了自动化的摩擦，但没有把“模型说它要做什么”当作授权依据。
模型与密钥也应留在边界内
知识库权限即使做得很细，密钥处理仍可能成为旁路。Brainstorm 的 shell 把 AI broker 作为模型调用的统一路径：可接本地 Ollama，也可使用 Anthropic、OpenAI、Gemini 或 GLM 的自有密钥。根据项目 README，密钥封存在操作系统 keychain 中，应用本身看不到它们；同时每个应用可配置消费预算，AI 触及的对象会留下 provenance 记录。
这并不等于“本地就绝对私密”。如果选择远程模型，发送给模型的上下文仍会离开设备；本地优先解决的是数据存放、授权与密钥暴露面，而不是神奇地消除外部推理的风险。因此实际部署时，应先把“哪些任务必须使用本地模型”“哪些对象可发给云模型”写成团队规则。
把权限设计成可执行的工作流
能力账本最有价值的地方，是它能把抽象的“最小权限”落到日常流程。以一次项目复盘为例：负责人可以先在 Notes 中整理材料，在 Database 中标注允许进入总结的对象，再让 Agent 只获得这些对象的读取能力和“创建草稿任务”的写入能力。输出先落为待审对象，确认后才进入正式项目计划。这样一来，模型的上下文边界、写入边界和人的审批点都是明确的。
这比在一条很长的提示词里写“不要读取私人文件”可靠得多。提示词属于模型行为约束，可能被误解、遗忘或受到外部内容干扰；授权检查则在模型请求数据之前发生。两者并不互斥：提示词可以规定工作目标，broker 与能力账本负责拒绝超出目标的数据访问。
在团队环境中，还应把撤销视为正常操作而不是事故响应。临时给自动化应用开放一个目录后，任务结束就收回授权；成员离开项目或供应商更换模型端点时，也应重新审核相关能力。Brainstorm 把授权记录为 vault 范围的状态，因而更容易把这种复核纳入例行维护，而不是靠记忆追踪谁曾经拥有访问权。把每次授权变更连同用途、有效期和复核人写入团队操作记录，也能让权限收敛成为持续实践。
不要把“同一份数据”误解为“所有人都能看”
同一对象空间会带来很强的互操作性：日历、图谱和数据库不再维护各自的副本。但互操作性不应自动推导为广泛读取权限。项目 README 所描述的沙箱、身份标记调用和 broker 正是在分开这两件事：对象可以共享引用关系，访问仍然要经过授权。
这也给自定义应用开发划出了一条实用边界。应用作者应在 manifest 与功能设计阶段最小化所需能力，例如一个只负责把会议纪要转为任务的应用，并不需要浏览整个文件系统或读取全部联系人。若功能需要扩大范围，应该让用户看到新的授权请求及其用途，而不是在版本更新时静默扩大访问面。对本地 AI 工具而言，这种“能力增量可见”往往比单次安装时勾选一个总开关更可审计。
从源码启动一个隔离的开发环境
项目源码使用 Bun workspace。官方 README 给出的最小开发命令如下：
bun install bun run dev
bun run dev 会以热重载方式启动 shell；项目还提供 bun run build、bun run test、bun run typecheck 与 bun run lint。仓库中 packages/shell 承载 Electron shell、preload、dashboard renderer 与 workers；apps/ 放置独立构建的第一方应用。开发自定义应用时，应该把应用当作不可信 renderer：通过声明的能力和 broker 请求宿主服务，不要为了方便绕过授权链直接访问 vault。
适合谁，以及不适合谁
Brainstorm 适合想把笔记、任务和文件放在本地，同时希望把 AI 行为纳入可治理边界的个人开发者和小团队。它尤其适合需要分阶段引入 Agent 的场景：先让 Agent 提议和归类，再逐步扩大它可写入的对象范围。
代价也很清楚。它是 Beta 软件，官方提醒用户为重要内容保留备份；Windows 构建当前未签名，安装时会遇到 SmartScreen 提示。AGPL-3.0-or-later 也意味着若将修改后的软件通过网络向用户提供，需要理解其 copyleft 义务。更重要的是，能力账本提升了可控性，却不会替团队完成数据分级、模型供应商评估或提示注入防护。
真正值得借鉴的不是某个桌面界面，而是这条架构原则：让 Agent 成为知识系统的一等参与者之前，先让授权、密钥、预算和来源记录成为一等能力。这样，当 AI 从“帮你找一条笔记”走向“替你写入项目对象”时，系统仍知道它在何处、因何而获得权限。