Busabase × GitHub CopilotGitHub Copilot 知识库
GitHub 已经很擅长记录代码变化。Busabase 补上经过审核的交接层，让决策和运营事实安全穿过 IDE Agent、云端 Agent、Pull Request 以及 GitHub 之外的系统。
一个产品，多个执行面
同一项任务可以从本地开始，在云端继续，最后进入审核队列。
GitHub 明确区分 IDE agent mode 和 Copilot cloud agent。云端 Agent 在 GitHub Actions 提供的临时环境中工作，可以创建分支和 Pull Request；IDE Agent 直接修改开发者本地环境。Copilot code review 又是另一个仓库上下文使用者。可信交接必须标明每项主张来自哪个执行面。
本地工作区
在开发者电脑上修改代码并运行测试。
GitHub 托管任务
研究、规划、创建分支、提交代码和 Pull Request。
Pull Request
根据仓库上下文和规则检查拟议代码。
仓库上下文已有明确主人
不要在第二个数据库里复制 GitHub 指令、Commit 和 Pull Request。
GitHub 支持仓库级指令、路径级指令、AGENTS.md 和 Copilot Memory。仓库级 memory 只在同一仓库使用，并会根据引用的代码验证后再生效。它们很适合代码上下文；Busabase 负责那些不能只由一个仓库拥有的事实。
| 产物 | 职责 | 正式归属 |
|---|---|---|
| .github/copilot-instructions.md | 告诉 Copilot 怎样构建、测试和验证当前仓库。 | Git |
| AGENTS.md / 路径指令 | 随目录或文件范围变化的操作要求。 | Git |
| Commit 与 Pull Request | 具体代码变化及其审核讨论。 | GitHub |
| 客户、发布、客服或运营决策 | 需要由仓库外的人和 Agent 复用的事实。 | Busabase |
交接链
Pull Request 合并只是一个事件，不是完整交付记录。
一项任务可能从 Issue 开始，进入 Agent session，产生 Pull Request，通过 CI，完成部署，最后改变发布状态或客户状态。每次转换都有不同证据，也有不同的结果负责人。
发布证据契约
让每项跨系统事实拥有足够结构，可以活过一次 Pull Request。
记录应该链接回 GitHub，而不是复制 GitHub。一套精简字段能说明：即使代码已合并，发布、文档、客服准备或客户影响是否仍在等待审核。
| 字段 | 含义 |
|---|---|
| work_item | 授权这项工作的 Issue 或任务 |
| pull_request | 已审核的代码变更 |
| commit_sha | 实际评估的精确版本 |
| environment | 预发布、生产、区域或租户 |
| verification | 测试、健康检查或观测结果 |
| operational_state | 提议、就绪、已发布、已回滚或阻塞 |
| owner | 对当前状态负责的人 |
| effective_at | 下游从何时可以依赖它 |
Pull Request 之外的审核
代码批准和业务接受可以发生在不同时间。
Copilot 读取已合并 Pull Request 与部署证据后，可以提出发布状态变化。Busabase 展示将要改变的精确字段，由产品、客服或运营审核影响，再决定是否合并新状态。
事件让台账保持更新
用自动化提出后续动作，不要让它抹掉审核者。
部署 Webhook 或定时 Agent 可以发现新事件并打开 Change Request。交付日志说明事件是否到达；记录审核仍负责判断它的含义能否成为正式事实。
deploy.succeeded提议发布状态与验证链接deploy.failed提议阻塞状态与事故负责人rollback.completed提议已恢复版本和影响范围
不同执行面的 MCP 并不相同
在 VS Code 中能连接，不代表 Copilot 云端 Agent 也能原样使用。
Busabase 连接页针对 VS Code 的 Copilot Agent mode，可以通过 Streamable HTTP 完成 OAuth。GitHub 当前云端 Agent 文档则说明：其 MCP 只支持 tools，不支持 resources 或 prompts，也不支持使用 OAuth 的远程 MCP 服务器。必须把它们当成两套部署选择。
| VS Code Agent mode | Streamable HTTP + OAuth | 使用现有连接指南，并通过 auth_verify 验证。 |
|---|---|---|
| Copilot cloud agent | 仓库 MCP 配置 | 只开放必要 tools；注意当前远程 OAuth 限制。 |
| Copilot code review | 共享仓库 MCP 设置 | 工具可能自主执行，因此必须审核访问范围。 |
Copilot CLI 也使用同一份审定知识
终端调查、IDE 工作和云端任务可以把结论交给同一条共享记录。知识保留一个正式归属，各执行面分别配置连接。Copilot CLI 不使用 VS Code 的 .vscode/mcp.json。
- 在终端运行 copilot mcp add --transport http busabase https://busabase.com/api/mcp。Copilot CLI 使用独立配置，包括 ~/.copilot/mcp-config.json；组织的 MCP 白名单和 CLI 使用策略仍然生效。
- 服务需要认证时，在 CLI 会话中运行 /mcp auth busabase 并完成浏览器授权。需要先审后写时，选择有限有效期的 changeRequest 授权。write 授权拥有更广的审核和合并能力，提示词里的“先问我”不会缩小凭据权限。
- 先调用 auth_verify，核对目标 Space 和 Base，再读取已有记录。把调查结论、准确的代码提交、来源链接和验收方法一起提议；经授权审核并合并后，回读正式记录。下一项目或会话使用时，再核对适用条件。
例如一次发布失败调查，Copilot CLI 可以在已有发布记录中提议确认原因和修复提交链接。终端命令的执行许可、代码审核、发布状态的业务接受是三个不同决定。代码继续由 GitHub 管理，审定后的运营结论链接到这里；终端对话不会自动变成团队知识。
关于 Copilot 交接的问题
GitHub Copilot 知识库常见问题
Busabase 会取代 GitHub Issues 或 Pull Request 吗？
不会。代码任务、Commit、分支、Pull Request 和代码审核继续由 GitHub 管理。跨仓库、并进入产品、客服、发布和运营工作流的已审核事实由 Busabase 承接。
它会取代 Copilot Memory 吗？
不会。Copilot Memory 为支持的 Copilot 功能保存仓库事实和个人偏好。当记录需要明确字段、外部负责人、审核决定和跨仓库复用时，再使用 Busabase。
云端 Agent 能和 VS Code Agent mode 用同一种连接方式吗？
不一定。GitHub 对云端 Agent 记录了不同的 MCP 能力与认证限制。每个执行面都要单独配置和验证。
部署事件应该直接写正式记录吗？
确定性事件可以触发提议，但交付成功不总等于业务已就绪。影响客户、客服、合规或协同发布的状态仍应审核。
第一张 Base 应该跟踪什么？
从团队最容易产生分歧的一次交接开始，例如发布准备、迁移状态、安全修复、事故跟进或客户影响变化。
Copilot CLI 和 VS Code 要各建一套知识库吗？
不需要。两者可以读取并提议更新同一组 Busabase 记录，分别配置连接与权限即可。结论和来源保存在共享记录中，具体接入按各自指南操作；每个执行面可以使用哪些工具，仍受 GitHub 和组织策略约束。
从 Pull Request 之后开始
把一次已合并改动，变成所有团队都能使用的已审核事实。
在实际使用的执行环境中连接 Copilot，定义一条发布状态记录，完成第一次从 GitHub 证据到运营事实的交接审核。