GitHub intelligence 公布后仓库历史怎样成为开发上下文

GitHub 在 2026 年 10 月 28 日公布了 GitHub intelligence。它不是一个单独的聊天窗口，而是一层来自 GitHub 数据图谱的上下文与学习能力：让代理记住团队怎样工作、持续整理上下文，并能搜索本地检出目录之外的相关代码。

官方地址：https://github.com/

对开发者来说，最小采用配方是：先用 Memory 固化个人偏好和仓库约定，再用 Code Search 找到跨仓库实现，最后用 /research 把实现、调用方和迁移风险整理成问题答案。Dreaming 则要单独看待，因为公告标明它仍是公开预览，并且需要主动开启。

GitHub intelligence 先拆成三项能力

公告把变化归纳为三个方向。Memory 负责把知识带到下一次会话，Dreaming 负责持续改进上下文，Code Search 则让代理触达当前检出目录之外的代码。三者都围绕“减少每次重新讲背景”的目标，但可用条件并不相同。

所以这条新闻真正改变的是上下文的组织方式，而不是把所有仓库无条件塞进每次对话。

先用 Memory 固化重复说明

Memory 适合保存不会随着某一次任务结束就失效的规则。例如个人偏好可以是“Pull Request 描述先写 TL;DR”，仓库记忆可以是“修改后按项目约定运行某个测试命令”。官方公告说明，Copilot Memory 已在付费 Copilot 计划中一般可用，并能跨 Copilot app、CLI、VS Code、云代理、代码审查、Slack、Teams 和 GitHub Mobile 等场景使用。

写入记忆时，应该把稳定规则和临时任务分开。下面这种表达适合长期复用：

• Remember to start my pull request descriptions with a TL;DR：个人写作偏好。
• 仓库约定：提交改动前执行项目已有的测试命令，并在描述中说明未覆盖的部分。

不适合写入 Memory 的内容包括一次性排障变量、短期分支名、临时密钥和未经确认的业务结论。记忆能减少重复说明，但不能替代代码审查，也不能证明代理已经理解了所有隐含规则。

Dreaming 适合持续整理，但要先看开关和成本

Dreaming 目前是公开预览，而且是 opt-in。公告列出三类梦境：个人记忆整理、仓库定制，以及把重复被接受的代码审查反馈转成审查指导。它可以增加、更新或移除个人和仓库记忆；涉及仓库内技能或自定义指令的变化，会以 Pull Request 形式提议给团队审阅。

这意味着它更像“持续维护候选上下文”的后台能力，而不是自动替团队发布规则。个人订阅者需要在 Copilot 设置中开启个人整理和仓库 dreams；组织与企业则还受管理员策略和仓库访问设置影响。公告还特别说明，dream runs 会消耗 AI credits。

采用时可以保留一个简单判断：如果团队希望把反复接受的审查意见沉淀为规则，并且愿意审阅 PR，Dreaming 有试用价值；如果规则变更必须经过严格人工编审，就应先从较小的仓库范围开始。

用 Code Search 处理跨仓库上下文

Code Search 解决的是“当前仓库没有完整答案”。官方说明它可以在相关项目和依赖中寻找代码、配置、Schema 与文档，支持精确文本和符号、正则表达式，也能按仓库、路径或语言缩小范围。语义搜索则允许用“它做什么”来找代码，例如查找失败支付的重试逻辑，而不必提前知道文件名或函数名。

公告给出的使用方向可以改写成一个可执行提问：

/research How do these components retry failed charges, and where could retries overlap?

这个问题的价值不在于命令本身，而在于它把“找实现”推进到“找实现与调用方之间的关系”。类似地，迁移旧 API 时，可以要求它列出各服务的实现位置、调用方和仍在使用旧接口的项目，再人工确认迁移顺序。

若只想查一个确定符号，用精确搜索更合适；不知道符号名但知道行为，用语义搜索更合适；需要把多个仓库的关系整理成研究结论时，再使用 /research。这比每次复制大段代码到聊天上下文更容易保持边界。

采用前记住四个边界

1. 可用范围：Memory、Dreaming 和 Code Search 的设置与可用性并不相同，不能用其中一项的计划条件推断另外两项。
2. 权限范围：跨仓库搜索仍受组织、仓库、路径、语言和访问权限限制，不是默认读取所有代码。
3. 预览风险：Dreaming 会修改或提出修改记忆与定制内容，团队需要保留审阅和回滚流程。
4. 结果责任：搜索到的实现线索可以帮助定位和规划，但最终的代码变更、测试和安全判断仍需要开发者确认。

因此，GitHub intelligence 更适合作为团队上下文的“配方层”：Memory 保存稳定偏好，Code Search 找到关联材料，Dreaming 帮助维护候选规则。把三者混成“代理自动知道整个组织”会高估公告承诺，也会忽略权限与人工审阅。

常见问题

GitHub intelligence 是一个新模型吗？

从公告表述看，它是一层来自 GitHub 数据图谱的上下文与学习能力，组合了 Memory、Dreaming 和 Code Search 三项能力；公告并没有把它描述成一个独立模型。

为什么有了 Memory 还需要 Code Search？

Memory 更适合复用偏好和仓库约定，Code Search 负责在相关项目中寻找代码和调用关系。前者保存“应该怎样工作”，后者查找“相关实现在哪里”，职责不同。