Copilot 不再只是补全：GitHub 把多 Agent 编排做进了 Projects

10 月 28 日的 GitHub Universe 上，GitHub 干了一件比发新模型更值得注意的事：它把 Copilot 从一个”帮你写代码的聊天框”，改造成了一个”帮你管一群 Agent 干活的工作台”。核心就是新上线的 Copilot Projects，目前处于公开预览阶段。

Projects 到底是什么

按 GitHub 官方 changelog 的说法，Projects 的逻辑很直白：很多真实工作本来就不 fit 一个仓库、一次会话。一个功能要改前端、改后端、改共享库；一个上线计划要拉上需求文档、设计稿和各种素材，却可能一行仓库代码都不碰。

Projects 给这种工作一个统一的家：你先描述目标，再把上下文交进去——仓库、设计稿、Slack 讨论串、设计会议纪要都可以算上下文；然后选模型和工具。Copilot 会按需跑起多个 Agent 并行干活，最后把结果（比如 pull request）交回来给你评审。重复性的活还能做成 project automations，比如”每次有功能上线就自动生成一段宣传视频”。当然，只想专注做一个仓库里的小任务时，仍然可以直接从该仓库开一个会话，不必非走 Projects。

同一批上线的还有两样东西，理解 Projects 时不能漏掉它们：一个是 Copilot Fusion 正式可用——不再让你手动挑模型，而是由一套路由编排系统决定每次用哪些模型、怎么配合；另一个是桌面端的 computer use 公开预览（macOS 和 Windows），Copilot 可以读应用界面、点控件、输文字，操作那些没有 API、没有 CLI、也没有 MCP 的应用。GitHub 强调，控制应用前会先征求你的批准，组织也可以通过管理设置关掉它。

为什么这一步比”补全更准了”重要

我看 Copilot 这几年的演进，有一条线一直没变：上下文的边界在哪里，Agent 的能力边界就在哪里。补全时代，上下文就是光标周围几百行代码；聊天时代，上下文是一个会话；而 Projects 把上下文扩到了”目标 + 跨仓代码 + 聊天记录 + 设计稿 + 会议纪要”这个级别。

这恰恰是过去 Agent 最弱的一环。真实需求很少完整地写在 issue 里，它散落在 Slack 的一句”先别动那个接口”、设计稿角落的一行标注、会议纪要里被划掉的方案中。以前你得自己把这些翻译成一段段提示词，再一个仓库一个仓库地开会话；现在 GitHub 想让你把”人开会时看到的材料”直接交过去，让 Agent 自己去对齐。

换句话说，GitHub 赌的是：下一阶段的编程 Agent 竞争，不在单次生成的质量，而在”能不能像一个小组一样被组织起来”。一个人给目标、一群 Agent 分头干、最后人来拍板——这个分工模型一旦跑通，开发者的主业就从写代码变成定目标、给上下文、审结果。

但并行不是免费的：三个新账单

我对 Projects 的态度是乐观但不轻信。多 Agent 并行听起来很爽，可它同时把三个成本摆到了台面上：

第一，评审账单。 十个 Agent 并行跑，可能交回来十个 PR。每个都要过测试、过 CI、等人看 diff、处理合并冲突。InfoWorld 的报道里引述分析师提醒的正是这一点：并行能清掉积压的杂活（依赖升级、API 弃用替换、SDK 替换、Java 或 .NET 版本升级），但协调跨仓库改动的难度也会同步上升。报道还提到一项 2026 年的 CooperBench 研究：Agent 协作完成任务的成功率比各自单干低约三成。数字本身不必迷信，但方向值得警惕——Agent 越多，接口处的误解越多。

第二，Token 账单。 以前一个会话花一份钱，现在一个目标可能同时烧掉好几个会话的量。GitHub 的产品页按套餐给了月度额度（比如 Pro、Pro+、Max 各档），但 changelog 并没有讲清 Projects 的用量具体怎么计量。在没摸清计量规则之前，大项目先用小目标试水，别一上来就把整个季度重构扔进去。

第三，权限账单。 这是最容易被忽略的一条。Agent 的上下文一旦包含 Slack 对话和会议纪要，它接触的数据面就不再只是代码了。哪些频道能进、哪些记录能读、Agent 的操作留不留审计日志、上下文保留多久——这些原来属于安全合规的题目，现在变成了每个用 Projects 的团队必须先回答的题目。Computer use 也一样：能点鼠标的 Agent，审批链必须比能写代码的 Agent 更严。

如果让我上手，我会先这样用

Projects 还在公开预览，我不建议一上来就拿核心链路赌它。下面是我会先试的三条路，都是低风险、收益可验证的：

先拿跨仓杂活练手。 依赖升级、废弃 API 替换、多仓同步改 SDK 版本——这类活目标清晰、改动机械、验证标准明确（测试过、CI 绿），最适合检验”并行 Agent + 人工评审”这套流程到底省不省时间。
给 Project 立三条规矩。 目标写成一句话可验收的标准（”三个仓库的 X 接口全部迁移到 Y，测试全绿”）；上下文只给必要的频道和文档，别把整个 Slack 工作区倒进去；每个 Agent 的产出单独成 PR、单独跑 CI，不许把几个仓库的改动打包成一个巨型 PR 让我”一并看看”。
先算评审时间，再算生成时间。 试跑两周后复盘一个指标就够了：Agent 省下的写代码时间，有没有被多出来的评审、返工和冲突解决吃掉。如果评审时间涨得比生成时间省得多，说明目标拆得太粗，或者上下文给得太滥——调这两处，比换模型管用。

结论：编排权比生成权更值钱

Copilot Projects 真正的信号不是”又一个新功能”，而是 GitHub 对开发者角色的判断：以后值钱的不再是谁敲代码更快，而是谁能把目标定清楚、把上下文给干净、把一群 Agent 的产出审明白。模型会继续变便宜、变聪明，但”定义问题”和”为结果负责”这两件事，短期内还迁不走。

所以我的建议很简单：去开一个公开预览的 Project，但只给它一件低风险的跨仓杂活；跑完一轮，先看评审花了多久，再决定要不要把更大的目标交过去。工作台已经搭好了，接下来要练的，是当好那个发号施令又亲自验收的人。

来源

GitHub Changelog：GitHub Copilot app, Universe releases（2026-10-28）：https://github.blog/changelog/2026-10-28-github-copilot-app-universe-releases/
InfoWorld：GitHub bets on multi-agent software development with Copilot overhaul：https://www.infoworld.com/article/4242710/github-bets-on-multi-agent-software-development-with-copilot-overhaul.html