为什么 IDE 侧栏开始不够用

早期 AI 编程工具的默认形态，是编辑器里的补全和聊天框。这个形态足够轻，也最贴近开发者正在看的文件。问题是，agentic coding 的任务边界已经变了。

当一个 agent 需要先读 issue、生成计划、开分支、运行测试、提交 PR、等待 review，再根据反馈继续修改，IDE 侧栏只能承接其中一段。它很难让用户同时看见多个任务的状态，也很难成为跨设备、跨仓库、跨团队的统一控制台。

Copilot app 之所以值得写进 GitHub 趋势，不是因为 GitHub 又做了一个桌面客户端，而是它承认 agent 工作流需要自己的前台。

桌面入口解决的是状态管理，不只是 UI

一个成熟的 coding agent 产品，最难的部分往往不是生成第一版代码，而是让人知道它现在在做什么。任务卡在哪一步，终端有没有失败，PR 是否打开，部署是否还在跑，下一步该由人还是 agent 接手，这些都需要连续状态。

桌面 app 的价值在这里显现。它可以把 agent 会话、计划、文件变更、pull request、终端输出和审批动作放在同一个工作表面上。用户不必把每个 agent 当成一次聊天，而可以把它们当作一组后台工作线程。

这也是为什么 GitHub 会把 Copilot app 放在 Build 2026 的开发者叙事里。真正要争的不是又一个按钮，而是开发者每天管理 AI 工作的默认屏幕。

多 agent 会改变开发者的注意力分配

单 agent 协作时，人和模型像 pair programming。多 agent 协作时，人更像 reviewer、调度者和产品负责人。你不再盯着每一行代码生成，而是判断任务是否拆得对、验证是否足够、风险是否可接受。

这会改变工具设计。好的界面应该帮助用户快速比较多个任务，而不是把所有过程折叠成一串聊天记录。它也应该突出证据：测试结果、diff、失败日志、部署链接和待人工决定的分歧。

Copilot app 的方向，正是把这种调度视角产品化。

GitHub 的优势仍然来自工程系统本身

桌面入口本身可以被模仿，但 GitHub 的真正优势在于它握着 issue、PR、Actions、review、权限和组织账号。agent 工作一旦要进入正式工程流，最终还是要回到这些系统里。

这也是 GitHub 做桌面 app 的底气：它不是从零搭一个 AI IDE，而是把已有工程协作系统前面再加一个 agent-native 控制层。

如果这个入口跑通，Copilot 的竞争对象就不只是 Cursor、Claude Code 或 Codex，而是所有试图成为开发者 AI 工作台的产品。