【学习】Copilot CLI Session：让自主 Agent 在后台持续运行的最佳方式
1. 什么是 Copilot CLI Session
Copilot CLI Session 可以理解为：在本地后台运行的 自主 Agent 会话。
它的关键特性是：
- 使用 Copilot CLI agent harness，运行方式 独立于 VS Code 主进程
- 即使你关闭 VS Code 窗口，Session 依然可以 继续运行
- 适合 范围明确、上下文完整、不需要频繁交互 的任务，例如：
- 实现一个计划中的功能
- 批量生成多个方案
- 执行明确的修复任务
2. VS Code 如何与 CLI Session 协作
VS Code 并不是把 CLI Session “塞进”编辑器里运行，而是通过 Copilot SDK 来对会话进行“控制与观测”：
- 启动 / 停止 / 监控 CLI 会话
- 在 Chat 视图中：
- 查看状态
- 输入指令
- 处理权限请求
- 支持 Slash Commands（例如
/compact、skills、hooks）
意味着：你仍在 VS Code 中管理体验，但执行单元已经变成了一个“可后台持续运行”的 CLI Agent。
3. 隔离模式（Isolation Modes）
Copilot CLI 提供两种隔离方式，决定它“在哪个环境里改代码”。
① Worktree Isolation（推荐）
核心思路：每个 Session 创建独立 Git worktree。
- 所有修改都发生在 worktree 中，不影响主工作区
- 每轮自动 commit，保持历史一致
- 适合让 Agent 更安全地自主修改代码
注意：使用 Worktree 模式，需要当前项目是 Git 仓库。
② Workspace Isolation
核心思路：直接在当前工作区修改文件。
- 适合你希望 立即看到变更 的场景
- 风险更高：因为改动会直接落到当前工作的目录里
4. Copilot CLI Session 的限制
CLI Session 很强，但也有边界：
- 无法访问 VS Code 内置工具
- 无法使用 扩展提供的工具
- 模型能力受 CLI 工具链限制
- 只能访问 无需认证的本地 MCP 服务器
- 需要认证/受保护的 MCP 服务通常不可用
因此：如果你的任务强依赖 VS Code 扩展生态（比如某些专用调试器、可视化工具、内部插件），CLI Session 可能不是最佳选择。
5. 如何创建 Copilot CLI Session
创建方式
你可以通过以下入口创建：
- Chat 视图 → Session Target 选择 Copilot CLI
- Chat 视图顶部 → New Chat → New Copilot CLI Session
- 命令面板 → Chat: New Copilot CLI Session
创建流程
这些步骤：
- 选择隔离模式（
worktree/workspace） - 输入 prompt（可附加上下文、选择模型、选择自定义 Agent）
- 在 Chat 视图中跟踪状态
- 支持同时创建多个 CLI Session 并行工作
6. 将本地 Session 交接给 Copilot CLI
一个非常实用的工作流：先澄清需求，再让后台执行。
适用场景：
- 你先用本地 Agent（如 Plan Agent）把需求问清楚、把计划做出来
- 然后把任务交给 CLI Session 在后台推进
交接方式：
- Session Target 下拉 → 选择 Copilot CLI
- Plan Agent 的 Start Implementation → Continue in Copilot CLI
交接后会发生什么？
- 完整对话历史与上下文会传递给 CLI Session
- CLI Session 继续执行，VS Code 负责“可视化跟踪”
7. 在终端中使用 Copilot CLI
VS Code 提供专用的 Copilot CLI Terminal Profile。
打开方式
- Terminal 面板 → “+” 下拉 → GitHub Copilot CLI
- 命令面板 → Chat: New Copilot CLI Session
- 命令面板 → Terminal: Create New Terminal (With Profile)
任意终端输入 copilot
特性
- 自动识别并显示 Session 到 Chat 视图
- 可以从终端恢复 Session
- 自动处理身份验证
8. 多仓库工作区（Multi-repo Workspace）
如果你的 VS Code 工作区包含多个仓库：
- 启动 CLI Session 时会出现 仓库选择器
- 选择在哪个仓库创建 worktree
- 创建出的 worktree 会显示在 Source Control 的 Worktrees 节点中
这让 CLI Session 在 mono-repo / multi-repo 场景下仍然可控、可追踪。
9. 自定义 Agent 与 Copilot CLI（实验性）
你可以在工作区中创建自定义 Agent（persona、规则、行为），并在创建 CLI Session 时选择它。
需要启用设置：
github.copilot.chat.cli.customAgents.enabled
适合团队统一“执行风格”、或者在大型项目里固化一些约束（比如代码风格、提交规范、分支策略、风险提示等）。
10. 相关资源（延伸阅读）
- Agents Overview
- Custom Agents
- GitHub Copilot CLI 文档
何时用本地 Agent、何时用 CLI、何时用 Cloud Agent？
下面是一份工程向的快速决策指南。
🖥️ 本地 Agent（Agent / Plan / Ask）
最适合：
- 需要频繁交互
例如：一步步调试、问问题、解释代码、探索 API - 需要即时反馈
例如：写一段代码、生成一个函数、解释报错 - 任务不明确，需要澄清需求
Plan Agent 特别适合“先规划再执行”
不适合：
- 长时间运行
- 大规模修改
- 需要后台执行的任务
⚙️ Copilot CLI Agent
最适合：
- 明确、可独立执行的任务
例如：- “把整个项目迁移到 TypeScript”
- “为所有 API 添加错误处理”
- “生成 5 个不同的 UI 方案”
- 长时间运行的任务
即使关闭 VS Code 也不会中断 - 需要隔离环境的任务
Worktree 模式让它安全修改代码，不影响主分支
不适合：
- 需要频繁问答
- 需要 VS Code 扩展工具（CLI 无法访问）
- 需要访问受保护的 MCP 服务
☁️ Cloud Agent（GitHub 托管）
最适合：
- PR 工作流（自动修复 PR、生成 PR 描述、自动 review）
- 团队协作（能直接访问 GitHub repo / PR / issues）
- 需要更强算力或长上下文（云端模型通常更强）
不适合：
- 本地文件未提交到 GitHub
- 需要访问本地环境（数据库、脚本、工具链）
一张“选择哪种 Agent”的快速决策图
任务是否需要频繁交互？ │ ┌──────────┴──────────┐ │ │ 是 否 │ │ ┌───────▼───────┐ 任务是否明确？ │ 本地 Agent │ │ └───────────────┘ ┌───────┴────────┐ │ │ 否 是 │ │ ┌───────▼──────┐ 任务是否与 GitHub 交互？ │ Plan Agent │ │ └───────────────┘ ┌───────┴────────┐ │ │ 否 是 │ │ ┌───────▼──────┐ ┌────▼─────┐ │ CLI Agent │ │ Cloud Agent│ └──────────────┘ └────────────┘ 结语
Copilot CLI Session 更像是一个可以托管在本地后台的工程执行者：
- 你负责定义范围与目标
- 它负责持续推进执行
- worktree 隔离让它更适合“放心交给它改”
当任务足够明确时，把工作交给 CLI Session，往往能显著提升效率。
