Copilot 不再只帮你写代码了：一个目标横跨多个仓库，人才是最后签字的人

GitHub 在 Universe 大会上把 Copilot 从“聊天框”改成了“工作区”，核心是 Copilot Projects：给 agent 一个目标，它能同时在多个仓库里并行干活，进度集中在一个地方看，产出是等你审的拉取请求，而不是直接合进去的代码。配套的还有 Slack 对话、设计稿、会议纪要这类代码之外的上下文——agent 拿到的材料，开始像一个真人团队手里的材料。InfoWorld 转述的 GitHub 口径和 10 月 30 日多家报道交叉了这一点：Projects 处于公开预览，目标可以跨仓库，多个 agent 并行跑不同部分。

对个人开发者和独立开发者来说，这件事的落点不在“更快”，而在“任务怎么写”。以前你给 agent 的是一段代码需求，现在你给的是一次跨仓库的目标：要改哪些仓库、验收标准是什么、最后以什么形式的 PR 交回来。目标写得含糊，并行 agent 交回来的就是几份各改各的 PR，合并冲突和评审负担全落回你一个人身上。GitHub 自己给的模型也是“人定目标、人审结果”，agent 只负责起草、测试和迭代。把这层关系想反了——以为下了目标就能撒手——多 agent 反而比单 agent 更费人。

怎么用起来，给三条可直接照做的建议。第一，从低风险仓库起手：依赖升级、SDK 替换、Java 或 .NET 版本升级这类跨仓库重复活，最适合先试 Projects，业务核心仓库先别放进去。第二，一个目标只配一套验收标准，写进 PR 描述里：改动范围、测试怎么跑、什么算通过，agent 交 PR 时对照着自查，你审的时候也按同一张表过。第三，把代码之外的上下文当成权限来管：Slack 对话和会议纪要一旦喂给 agent，就等于进了它的工作材料，敏感频道、含客户信息的纪要先排除在外，别为了图全把什么都接上。

什么情况下这个结论不成立：如果你只有一个仓库、一次只改一处，Projects 的多仓库编排就是多余成本，普通 Copilot 对话就够了；如果你团队没有“审 PR”这个环节（比如个人项目直接合进主分支），多 agent 并行交回来的改动会直接变成主分支的风险；还有一点要留口子，公开预览阶段的并行冲突处理、token 账单和评审瓶颈，InfoWorld 引用的分析师已经点名是下一道坎，别按正式版的稳定性去排生产计划。