真实开发很少是一条直线，修 bug、审 PR、追新想法同时进行。GitHub Copilot 的 My work 窗格，把 3 个内置视图和 2 种布局塞进一个面板，专治多 Agent 任务满天飞。
这不仅是 UI 的堆砌，而是开发范式的转移。当 Agent 能同时处理多个 Session，人类开发者的核心动作就从“写代码”变成了“拆任务”和“验收 PR”。谁先跑通这套调度闭环，谁的工程效能就能拉开代差。
- 3 个内置视图（Active、Review requests、Done）自动过滤 Copilot 触及的项目，一眼看清任务状态。
- 支持2 种布局（List 和 Table），Table 视图可自由拖拽列宽，掌控力更强。
- 支持从 Issue 或 PR 批量启动 Agent 会话，甚至能跨仓库指定代码库，实现任务与代码解耦。
从单点执行到全局调度的结构升级
以前用 Copilot 可能是单线程问答，现在变成多 Agent 并发。My work 窗格就是调度中心。All 视图不是全量仓库，而是基于你在 Copilot app 里触及的项目自动过滤。这个细节说明它是基于上下文的，不是简单的 GitHub 全局 Issue 列表。Active 和 Review requests 区分了“我要做的”和“我要审的”，Done 用于复盘。这种结构把开发者的注意力从“找任务”转移到“处理任务”上。
在实操中，List 视图适合快速扫描和移动端，Table 视图适合需要对比多个 Issue 优先级、或者需要批量分配 Agent 时的桌面端重度操作。如果团队规模超过 5 人，Review requests 视图的优先级会急剧上升，因为瓶颈往往不在写代码，而在等合并。明确不同视图的适用边界，能帮你省下大量切换上下文的时间。
My work 窗格的过滤与布局逻辑
除了默认视图，自定义过滤器是提升效率的关键。你可以用 angle-bracket syntax 输入过滤条件，或者直接用 UI 拖拽。比如添加 Is: Issue 和 Assignee: Me，就能建立一个专属的“我的 Issue”视图，避免被 PR 淹没。在排序策略上，将默认的 Recently updated 改为 Ascending，让 oldest items 浮到顶部，能强制你处理历史债务。
对于跨仓库协作，启动 Agent session 时手动切换 repo scope 是避坑指南。当 Issue 所在的仓库与代码仓库分离时，如果不改变作用域，Agent 很容易在错误的上下文里产生幻觉。建立这套落地清单，能让你的 Agent 调度更精准。
如何获取与起步
这是 GitHub Copilot app for Beginners 系列的第三篇内容。前两篇分别介绍了应用起步和 Session 内工作，这篇聚焦全局管理。你可以通过以下链接获取完整教程和系列视频：
系列前文回顾：
更多视频与详情：gh.io/app
GitHub 把 Copilot 从单点补全推向项目级调度，My work 窗格就是这一战略的具象化。它强制开发者在派发任务前，先理清 Issue 的上下文和 Repo 的边界。对于技术 Leader 而言，现在的当务之急不是给团队买更多 Copilot 席位，而是重新设计工作流：如何把大需求拆成独立的 Feature Request，如何让 Agent 在正确的 Repo Scope 里跑 Session，以及如何建立基于 Done 视图的验收标准。工具已经就位，拼的是拆解任务的颗粒度。
留言聊聊
多 Agent 并发时，你更看重 List 还是 Table 视图？
往期推荐
- ·Cerebras 营收爆雷，云收入涨 281% 却巨亏
- ·扎克伯格6500字宣言，AI检测证实是人类手笔
- ·Google 买航司数据，千万美元拿下七十五亿条记录
点击公众号头像 → 历史消息，可翻阅以上文章
