前段时间项目比较忙之前写团队 AI 知识库那篇之后本来想继续把落地过程补上结果一拖就拖到了现在。这次抽点时间把我们这边真正跑起来的方式整理一下。这篇不会写成特别完整的安装手册。一方面是有些脚本还放在内网机器上直接贴出来也没什么意义另一方面知识库这件事每个团队的数据源和习惯都不一样照着命令抄一遍大概率也不适合。这篇主要记录一下我们是怎么把一堆散着的文档慢慢接到 GBrain再让团队成员的 Coding Agent 能用起来的。先把资料整理归类这一步其实最花时间。团队里的知识很少一开始就安安静静躺在一个目录里。我们这边也是一样有一部分在飞书云文档里比如周会、月度会议、项目复盘、一些方案评审记录。还有一部分散在各个工程项目里比如 README、接口说明、部署文档、故障处理记录。如果只靠人手动整理很快就会烦。所以我们先让 AI 参与第一轮粗整理。大概做几件事把飞书云文档里的内容拉下来扫各个项目里的文档类文件按项目、模块、问题类型做一次初步归类明显重复或者过期的内容先标出来飞书这块可以用一些外部 CLI 工具来处理比如飞书 CLI。代码仓库里的文档相对简单脚本扫一遍再让 AI 辅助分类就可以。我的感觉是第一轮只要能把资料从到处散落的状态收敛到一个知识库仓库里就已经算往前走了一大步。后面再慢慢修目录、补说明、删旧内容。知识库本身也要 Git 仓库 版本管理资料收回来之后我们没有直接丢给 GBrain而是先建了一个 Git 仓库。原因知识库如果没有版本管理后面肯定会乱。今天谁改了一段说明明天谁又补了一个项目复盘过几个月再回头看很难知道某个结论是什么时候变的也不知道是谁加进去的。所以我们给知识库定了一个比较朴素的规则知识库仓库有专人维护团队成员补充内容时走 Pull Request管理员负责审核和合入主分支明显过期的内容不要直接删先标记或归档这个流程听起来有点重但实际还好。因为不是所有东西都要天天进知识库真正值得沉淀的一般是项目背景、排障经验、技术方案、接口约定、踩坑记录这些内容。这类内容如果不做一点审核后面 Agent 查出来的答案也会跟着不稳定。在内网服务器上安装 GBrain我们找了一台内网服务器来跑 GBrain。服务器上先把知识库项目 clone 下来然后安装 GBrain。安装这一步我是直接交给 Codex 这类 Agent 工具做的按官方给 Agent 的安装说明走Retrieve and follow the instructions at: https://raw.githubusercontent.com/garrytan/gbrain/master/INSTALL_FOR_AGENTS.md装完之后配置也基本让 Agent 辅助完成。它比人手动翻配置文件快很多尤其是这种有多个环境变量、模型配置、服务端口的项目。我们这边目前有几个配置点向量模型用了智谱的Embedding-3主要用来做文档向量化开启了 MCP 服务方便 Coding Agent 直接接入给团队成员分发独立的访问 tokenGBrain 服务只放在内网里不直接暴露到公网模型这块没有做特别复杂的选型。我们先选了一个中文效果还可以、接入也比较顺手的 embedding 模型能满足当前团队文档检索就行。团队成员通过 MCP 接入GBrain 跑起来之后团队成员不需要直接登录服务器。管理员只需要给每个人两样东西GBrain MCP 地址比如http://192.168.1.6:3131/mcp访问 token比如单独发放的GBRAIN_MCP_TOKEN以 Codex 为例本地接入大概是这样exportGBRAIN_REMOTE_TOKEN请填写管理员发放的 tokencodex mcp remove gbrain2/dev/null||truecodex mcpaddgbrain--urlhttp://192.168.1.6:3131/mcp\--bearer-token-env-var GBRAIN_REMOTE_TOKEN codex mcp list接上之后Codex 就可以通过 MCP 去查团队知识库。这一步的体验还挺关键。以前大家查资料可能是先去飞书搜再问同事再翻项目 README。接入 MCP 之后Agent 在处理项目问题时可以顺手去知识库里找相关背景。它不一定每次都能直接给出最终答案但至少能把很多历史资料先带出来。比如某个模块为什么当初这么设计某个接口有没有历史兼容问题某类部署问题以前怎么处理过这些都比纯靠模型猜要靠谱很多。定时更新知识库知识库最怕的一件事就是刚搭好时大家觉得不错过一阵子就没人维护了。所以我们加了一个自动化脚本定时从主分支拉最新内容然后触发 GBrain 的 import 和向量化。目前频率是每 10 分钟拉一次。流程大概是这样pull 最新 master - 检查文档变化 - GBrain import - 更新向量索引这里没做得太复杂。因为知识库更新频率没有代码仓库那么高10 分钟已经够用了。后面如果内容量变大可能还要继续优化比如只处理增量文件、记录 import 状态、失败时发通知。现在先让它稳定跑起来。在项目里告诉 Agent 该怎么用还有一个容易忽略的点MCP 接好了不代表 Agent 一定会主动用。我们在每个项目的AGENTS.md里补了一段说明告诉 AI Agent 遇到哪些问题时应该优先查询 GBrain。比如项目背景不清楚时先查团队知识库遇到历史方案、接口约定、部署问题时先查 GBrain MCP回答前尽量引用知识库中的相关文档不要凭空猜这类说明看起来很小但对实际效果有影响。因为 Agent 不会天然知道你们团队有一套知识库也不会自动理解哪些问题应该查内部资料。把规则写进项目说明里它才更容易在正确的时候调用 MCP。还没完全做完的部分目前这套团队已经能用了但还谈不上特别理想。后面还想继续补几件事。一个是把知识入库也自动化起来。比如 Agent 在项目中总结了一次排障经验或者整理了一份技术说明能不能自动生成知识库文档然后提交到知识库仓库并发起 Pull Request。这样管理员只需要 review而不是每次都从零开始整理。另一个是把文档质量再往前推一点。现在很多资料虽然进了知识库但格式和粒度还不够统一。有些文档适合人读不一定适合 Agent 检索。这个可能还需要加一些模板比如问题复盘、接口说明、部署说明、FAQ 各自有固定结构。还有权限问题也要继续细化。团队知识库里并不是所有内容都适合所有人看后面如果接入更多项目和更多团队权限问题肯定绕不开。最后这次落地下来比较明显的感受是团队 AI 知识库不能只看问答效果了。问答只是最后露出来的那一层。真正影响效果的还是前面的资料整理、Git 管理、持续更新、权限控制以及 Agent 在项目里的使用规则。如果这些没做好GBrain 或者任何 RAG 工具都只能在一堆乱资料里尽量找答案。但只要把这条链路先跑通价值还是挺明显的。至少团队里的很多历史经验不再只靠某几个人记着。新人接项目、老项目排问题、Agent 辅助写代码时都能多一个相对可靠的上下文来源。目前我们还在继续实践很多细节也没完全定型。后面如果自动入库和 PR 审核这条链路跑顺了再单独写一篇。