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 交接的问题
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 应该跟踪什么？
从团队最容易产生分歧的一次交接开始，例如发布准备、迁移状态、安全修复、事故跟进或客户影响变化。
从 Pull Request 之后开始
把一次已合并改动，变成所有团队都能使用的已审核事实。
在实际使用的执行环境中连接 Copilot，定义一条发布状态记录，完成第一次从 GitHub 证据到运营事实的交接审核。