部署与运维：把 brain 跑起来，并让它不崩

前面 13 课讲的全是「brain 里有什么、怎么用」。最后一课讲最现实的一件事：这东西往哪跑、谁碰得到、崩了怎么办。你辛辛苦苦攒的知识库，最怕两件事——丢了，或者被人乱碰。gbrain 的部署哲学把这两件事都提前想了。

一、本地优先：你的知识默认只在你机器上

gbrain 是本地优先（local-first）架构：brain 的主体（markdown 文件 + 一个本地数据库）就跑在你自己的机器上¹。人类维护的内容（你自己写的笔记、规则文件）是普通 markdown，进入 git 版本控制——所以即便数据库坏了，你的知识也还在 git 里，可恢复（这正是第 1 课「系统事实源」的延续）。

谁都碰不到你的 brain，除非你主动把它暴露出去。gbrain 提供一个可选的 HTTP 服务（serve-http），把 brain 通过 MCP 接口协议（让 agent 连上 brain 的标准协议）暴露给远程 agent 或同事——但这层是可选的、需要显式启动的，不是默认开着²。

二、暴露出去时的授权：OAuth 客户端 scope

当你真要分享，gbrain 用 OAuth 客户端做授权：每个客户端 token 被限定在被授予的来源（source）范围内、且有 slug 围栏（写只能写指定路径前缀）。这就是第 12 课讲的访问控制——部署层面它落地为「你给谁发了一个只看得某 source 的 token」²。

对使用者：你不用担心「一开服务全世界都能看我日记」，授权粒度是 token 级别的，发之前想清楚给谁、给多大范围。

三、autopilot：让 brain 自己定时打理

你不会每天手动跑「抽实体、嵌入、清理孤儿页」。gbrain 的 autopilot 是一个定时任务（cron），按你设的周期自动触发第 8、9 课讲的 dream cycle——把各个来源的新内容抽干净、嵌入、清理孤儿、跑校准采样。它的预算（budget）是双上限的：每个来源有上限，整个 brain 还有个硬上限兜底，防止某天内容爆量把 API 账单烧穿³。

这层自动化是「运维省力」的关键：你只管往 source 里丢内容，brain 自己保持整洁。

四、doctor：本地体检，崩之前先报警

gbrain 内置一个 doctor（医生）自检命令，像体检一样扫描你的 brain 健康度：数据库 schema 版本对不对、队列有没有卡住、同步是否过期（24 小时警告、72 小时失败）、PGLite 数据目录有没有损坏、技能契约是否齐全等等⁴。它把「快要出事」的信号提前标成 warn/fail，而不是等你发现知识丢了才慌。

还有一层更硬的持久化安全网：hardenBrainRepo（加固脑库）会装一个 git 自动 push 钩子 + 一个不碰数据库的 pull 定时任务，保证你 brain 仓库的工作区变更被持续提交并推送到远端——即使本地机器废了，知识也在远端 git 里⁵。注意它刻意把 push 钩子放在 git 钩子目录、不进仓库本身，避免「拉下来的提交改写你 token 旁边的代码」这种供应链风险。

五、一个建筑师的可抄点

gbrain 部署哲学最值得抄的是三条：(1) 本地优先，知识进 git，远程是可选显式层——默认不暴露，天然缩小攻击面；(2) 授权在 token 级、scope 在来源级——分享可控；(3) 运维靠 doctor 自检 + autopilot 自动 + git 持久化兜底——少手动、早报警、不丢数据。

你造自己的工具时，别一上来就「云端 SaaS 默认公开」，那是灾难温床。先把数据留本地、进版本控制，远程按需开、授权按 token 收，再配自检与自动备份。这套顺序能省掉大部分安全事故。

六、这一课带走的

• gbrain 本地优先：大脑在你机器上跑，markdown 进 git，默认谁都碰不到。
• 远程暴露是可选的 HTTP 服务，靠 OAuth 客户端 token 授权（来源 scope + slug 围栏）。
• autopilot 定时跑 dream cycle 自动打理，预算双上限防烧钱。
• doctor 自检提前报警，hardenBrainRepo 把 brain 仓库自动 push 到远端防丢。

练习题

参考出处