Busabase × OpenAI Codex
Codex 知识库
给 Codex 一套能长期读取、更新和交接的项目知识，同时避免每一次 Agent 输出都被直接当成事实。
缺失的一层
编程 Agent 可以跑得很快，项目事实必须走得更稳。
Codex 已经能理解代码仓库、操作指令和眼前的文件。更难的问题出现在任务结束之后：哪些决策值得保留，哪些发现已经验证，下一位 Agent 又能把什么当成事实？
工作方式
从 Codex 输出到可信上下文，只需四步
读取已批准的上下文
Codex 直接读取与任务相关的记录、文档和文件，不必再从聊天记录里拼凑历史。
提交更新提议
新发现以 Change Request 的形式进入系统，同时带上拟修改的字段和来源上下文。
审核具体差异
由人检查具体改动，要求修改、批准或拒绝这次提议。
复用正式记录
后续 Codex 任务从已审核的知识开始，提议与合并历史也始终可以追溯。
应该沉淀什么
值得跨越一次编程任务长期保留的知识
Busabase 最适合保存会影响后续决策的上下文，也就是其他人或 Agent 之后还会据此行动的信息。
架构决策
最终决策、备选方案、证据、负责人，以及需要重新讨论的触发条件。
已验证的 Runbook
恢复步骤、环境限制，以及最近一次成功验证的结果。
发布与事故知识
发布了什么、哪里失败、回滚了什么，以及哪些证据支持当前结论。
可复用的 Agent 工作流
把团队工作方式固化下来的 Skill、审核清单、数据结构和小型应用。
选择正确的知识层
Busabase 补充代码仓库上下文，而不是取代它。
代码和编程规则应该留在仓库附近。需要跨仓库、Agent 和应用长期复用的共同事实、决策与运营上下文，再进入经过审核的知识库。
| 知识层 | 最适合保存 | 可信依据 |
|---|---|---|
| 代码仓库 + AGENTS.md | 代码、本地指令、测试、版本化配置 | Git 历史与代码审核 |
| 向量检索 | 查找语义相关的内容片段 | 取决于来源集合与检索质量 |
| 共享文档 | 人工撰写的说明与协作内容 | 编辑责任人与文档历史 |
| Busabase | Agent 编写的记录、文档、Skill、文件和应用 | Change Request、人工审核、来源与合并历史 |
连接 Codex
使用 Skill，或通过 MCP 连接
推荐使用 Busabase Skill，因为它不仅完成连接，也把审核工作流交给 Codex。根据 OpenAI 官方文档，Codex 也支持 Streamable HTTP MCP 和 OAuth。
MCP 连接命令
codex mcp add busabase --url https://busabase.com/api/mcp
codex mcp login busabase --scopes mcp
适用性判断
只在审核会改变结果的地方使用 Busabase
非常适合
- 多个人或 Agent 会复用同一批决策。
- Agent 更新需要负责人、来源或审批。
- 知识需要跨越多个仓库或业务系统。
- 你需要还原某个值为什么成为正式事实。
用更简单的工具
- 信息只是临时草稿上下文。
- 内容本就由 Git 管理，代码审核已经足够。
- 没有人会审核 Agent 提交的更新。
- 你只需要高吞吐事件存储或向量检索。
Codex 知识库常见问题
Codex 可以直接写入 Busabase 吗？
可执行的操作取决于授权范围。常规 Agent 工作建议只授予 Change Request 权限：Codex 可以提交改动，但审核和合并仍由人决定。
它会取代 AGENTS.md 吗？
不会。AGENTS.md 适合保存仓库内部的操作规则；Busabase 保存经过审核、需要跨会话、仓库、人员、Agent 或应用共享的知识。
Codex 能同时使用 Busabase Cloud 和 Desktop 吗？
可以。Cloud 适合共享工作区和基于浏览器的 OAuth；Personal Desktop 将工作区保留在你的电脑上，并提供本地 MCP 端点。
Busabase 是向量数据库吗？
不是。向量检索用于找到相关文本；Busabase 关注结构化记录、来源、改动提议、人工审核与正式历史。两者可以配合使用。
第一个 Base 应该放什么？
先选择一条真正影响结果的工作流，例如架构决策、事故复盘、发布准备或已验证的 Runbook。数据结构保持简单，并在必要时要求填写来源、负责人、状态和最近验证日期。
从一条经过审核的记录开始
给 Codex 一份团队真正敢用的上下文
连接 Codex，让它先提交一次有价值的更新，并在内容成为共享知识之前检查具体差异。