今天选择两篇 2026 年 10 月 28 日发布的 GitHub 一手技术说明，分别回答 AI-native 软件生产中的两个问题：Agent 怎样持续获得准确的组织知识，以及多模型审查怎样在交付前提供可复核的反馈？ 它们都是近期产品能力与方法设计的公开说明，而非第三方独立的对照实验。
1. GitHub intelligence puts your code, context, and history to work
- 作者/来源： GitHub / GitHub Changelog
- 发布日期： 2026-10-28
- 原文： https://github.blog/changelog/2026-10-28-github-intelligence-puts-your-code-context-and-history-to-work/
- 补充文档： https://docs.github.com/en/copilot/concepts/prompting-and-context/copilot-memory
- Dreaming 文档： https://docs.github.com/en/copilot/concepts/prompting-and-context/copilot-dreaming
推荐理由： Agent 的长期 Context 经常被简化成“每次会话前读取一份 AGENTS.md”。GitHub 这次把个人偏好、带代码出处的仓库事实、定期更新的技能/指令和跨仓搜索区分为不同机制，并定义了自动维护与需要 PR 审核的边界。值得关注的不是它能记住多少，而是记忆从何而来、如何更新，以及什么不能依赖记忆来强制执行。
3 条核心要点：
- 把“人怎么工作”和“仓库是什么样”分开保存。 Copilot Memory 在付费 Copilot 计划上正式可用：用户级偏好可跨仓库与客户端复用，仓库级事实仅属于对应仓库，可记录测试命令、架构约定及其代码出处。CLI、Cloud Agent、Code Review 等体验可以复用同类知识。仓库事实会在使用时对照当前分支的引用检查，但 GitHub 明确说明这只是模型的判断，不是强制保证；需要可靠遵守的规则仍应放在明确的 Custom Instructions 中。
- Dreaming 是上下文维护，不是模型在线训练。 公开预览的 Copilot Dreaming 从历史会话和已合并 PR 的审查反馈中整理个人偏好、仓库知识和 Code Review 指导；它能自动添加、更新、删除 Memory，但对版本库中的
AGENTS.md、Skills、Custom Instructions 等文件只提出 PR，不会直接覆盖已提交的文件。功能需选择启用，受订阅、模型、会话同步和组织策略约束，且每次运行消耗 AI Credits。 - 跨仓搜索把代码事实按需加入 Context。 GitHub intelligence 支持精确符号/正则查找与语义检索；
/research可追踪相关服务、共享库及调用点，无需事先克隆所有仓库。GitHub 报告，在预览期间被审阅且使用 Memory 的 CLI 会话中，93% 表现出更好的偏好遵循、42% 表现出更高流程效率；这是厂商筛选样本的观察性结果，不能解读为 Memory 对所有开发任务的因果改善。
核心启示：
Interaction → Scoped Memory → Source Recheck / Dreaming → Reviewed Instruction PR → Cross-repo Retrieval。长期 Context 需要来源、适用范围、更新机制及人工可审查的变更；Memory 不是策略执行器，也不能代替测试。
2. Copilot code review: Merge with confidence with Max and approvals
- 作者/来源： GitHub / GitHub Changelog
- 发布日期： 2026-10-28
- 原文： https://github.blog/changelog/2026-10-28-copilot-code-review-merge-with-confidence-with-max-and-approvals/
推荐理由： 随着 Agent 起草 PR 的比例上升，审查不能只依赖同一个 Agent 对自己的输出做一次复述。GitHub 新增 Max 审查强度：让不同提供商的模型分别检查 PR，由汇总 Agent 处理分歧；同时把机器审查与可计入分支保护的批准分开配置。它给出了多模型审查、审批权限与成本之间的具体产品边界。
3 条核心要点：
- 多模型独立审查，再统一校验。 Max 是公开预览的第三级审查强度，与 Lite、Balanced 并列。它运行多个来自不同模型提供商的独立审查 Agent，再由 Aggregation Agent 对发现的问题进行合并、解决分歧和二次核实。GitHub 声称可扩大高风险 PR 的覆盖面，但公开公告没有给出误报率、漏报率或盲测对照数据，不能将这种架构直接等同于更高正确率。
- 机器批准可以进入分支保护，但必须显式授权。 Copilot Approvals 已正式可用，默认关闭；管理员可按企业、组织或仓库启用，并限制 Copilot 可批准的文件路径。启用后，批准可计入仓库所要求的 Approval 数；PR 在获得批准后又有新提交时，该批准会被撤销，需重新审查。这里的批准是工作流策略的一部分，不是代码行为正确性的形式化证明。
- 审查深度必须有独立的成本与治理边界。 Max 相比 Lite、Balanced 会消耗更多 AI Credits、运行更久，可针对单个 PR 选择，也能设置默认级别及管理员允许的最大级别。高风险共享库或鉴权变更适合更充分的审查，但最终仍应保留 CI、静态检查、领域所有者评审及必要的人工合并门禁；多个模型可能共享盲区。
核心启示：
PR Diff → Independent Model Reviews → Aggregation / Recheck → Configured Approval → CI & Merge Gate。Reviewer 的独立性、审批权限与可执行验证是三件不同的事，不应因为“多模型已批准”就跳过后两者。
今日思考
这两篇说明，Software Factory 的可控性需要同时解决输入侧的信息可信度与输出侧的审查可信度。
Memory、Dreaming 和跨仓检索帮助 Agent 形成持续更新的工程上下文；多模型 Code Review 则尝试在变更进入主线前补上独立视角。但会过期的记忆不是权威规范，模型投票也不是可执行测试。更完整的闭环是：Source-backed Context → Agent Change → Independent Review → Executable Verification → Human / Policy Gate。
两篇都来自 GitHub 2026 年 10 月 28 日的产品发布，功能可用性取决于计划和策略设置；文中提及的效率提升与审查效果尚不能视为独立验证。