GitHub Copilot 实战：Agent、MCP 与工作树并行开发

从补全到自主循环：Copilot 的范式转变

2023 年中的 Copilot 还只是一个「输入提示、返回代码」的补全工具，而现在它已经能读取文件、执行命令、检查结果，并在出错时自我修正——这是一个完整的行动循环。微软 MVP、云架构师 Ashraf Ben Alaya 在一场社区分享中，用一套真实的工单系统演示了如何「塑造」这个循环。

他的定位很明确：这不是营销演示，而是每天真实使用的工作流。核心公式可以概括为——用 instruction 设定规则，用 MCP 提供工具，用 agent 编排任务。在他的语境里，MCP 被形象地称为 agent 的「眼睛和手」：Playwright MCP 让它能像真人一样操作浏览器，GitHub MCP 让它能拉取代码、开 PR、管理 issue。

Agentic 工作流（行动循环） 指的是 AI 不再只做一次性的「输入→输出」，而是把目标拆成多步：观察现状（读取文件、运行命令）、采取行动、检查结果，再根据反馈决定下一步或修正错误，直到达成目标。与传统补全的关键差别在于闭环反馈——模型能看到自己操作的后果，从而自我纠错。这也意味着权限、可观测性和安全边界变得重要：agent 能执行命令、改文件，因此需要审批机制、隔离环境和可回滚的版本控制。文章后面提到的 instruction 约束、测试即契约、逐条审阅 diff，本质上都是为这个循环设护栏，让「自主」可控。

先立规矩：Instruction 文件是团队协作的前提

在团队环境中使用 Copilot，第一件事不是写更长的提示词，而是「教会它你的团队怎么工作」。Ashraf 的做法是建立分层上下文：整个仓库一份 instruction 文件，特定匹配文件再各有一份，必要时还可以定义 agent 并共享给其他团队。这样，一句「NPM test 失败了，修一下」就足以触发完整的工作流。

他给出的几条规则很有实操价值：禁止引入新的 NPM 包（避免 agent 像系统管理员一样第一反应就是「重启或更新」）；修复前后都必须运行测试；以及他最看重的一条——完成后用三个要点总结，而不是生成二三十行解释。用他的话说，agent 应该「具体、准确、简短」，需要更多细节时再对话追问。

演示中他准备了五条测试，其中两条失败。agent 先运行测试定位问题，修复后重新运行，最终五条全绿，并按要求用三点总结了「错在哪、改了什么、测试结果如何」。

测试全绿不等于没问题：MCP 补齐 UI 盲区

单测通过后，应用里仍藏着两个 bug：搜索框对大小写敏感，导致部分工单搜不到；勾选两个高优先级工单时，顶部计数器却显示六个。这正是纯代码层测试的盲区。

Ashraf 解释了为什么需要 MCP：如果没有统一标准，Copilot 每连接一个工具（GitHub、Jira、SQL 数据库、浏览器）都要单独写一个连接器。MCP 相当于「AI 世界的 USB-C」——一个插头，多种工具。服务端暴露的是能力（比如列出工单、创建工单、导航页面），客户端一次连接即可复用。

他现场配置了两个 MCP 服务：一个是自建的 ticket-lab，暴露 list/get/create ticket 三个工具；另一个是 Playwright MCP，让 agent 拥有浏览器操作能力。值得注意的细节是，Playwright 并不是「看像素」，而是读取无障碍树（accessibility tree）的文本结构——所以它能读到页面上高亮显示了两个卡片，而段落里写着六个工单，从而精准定位这个数字不一致的 UI bug。

一个 MCP 工具由四部分组成：名称、描述（agent 靠它理解工具能力，从而在多个工具中做选择）、输入 schema，以及实际执行的函数。这套模式可以直接平移到 ServiceNow 或自有 API 上。演示中，agent 通过 MCP 成功创建了第 7 号工单：「header counter show total ticket instead of filtered count」。

MCP（Model Context Protocol） 是一个开放协议，用来把外部工具和数据源以统一方式暴露给 AI 客户端。它把「连接器」的重复工作标准化：服务端按协议声明自己提供哪些工具（名称、描述、输入 schema、执行函数），客户端只需一次接入即可发现并调用。对 agent 而言，工具描述就是「菜单」，模型据此判断何时调用哪个工具；因此描述写得准确与否，会直接影响工具选择的质量。文章把 MCP 比作「AI 世界的 USB-C」，强调的正是这种一次接入、多种复用的特性，以及它可以平移到 ServiceNow、自有 API 等任意后端服务上。

工作树隔离：两个 agent 真正并行的前提

一个 agent 干活时，你只能等。但如果两个任务彼此独立——比如一个修前端的计数器 bug，另一个给 MCP 服务加一个 close ticket 工具——就可以并行。不过 Ashraf 强调了一个安全前提：必须用 git worktree，而不是普通 checkout。同一分支上的两个 agent 会互相覆盖，而工作树让每个 agent 拥有独立文件夹、独立分支、共享的 git 历史，互不干扰。

工作树的适用场景远不止 AI：紧急修生产 bug 而手头功能分支未完成、review 别人的 PR、在一个分支跑构建的同时继续写代码、甚至把新旧版本起在不同端口做对比。但他提醒，新建工作树只共享已提交的文件，node_modules 和 .env 都不会带过去。

git worktree 允许同一个仓库同时挂载多个工作目录，每个目录检出不同分支，但共享同一份 .git 历史与对象库。与 git checkout 切换分支相比，工作树的关键优势是多个工作区可以同时存在：一个目录跑构建、另一个目录继续改代码，互不打断。对并行的多个 agent 来说，这意味着各自拥有独立文件夹和分支，写文件时不会互相覆盖，提交历史又保持统一，便于合并与审查。需要注意，新工作树只包含已提交的内容，未跟踪或忽略的文件（如 node_modules、.env）不会自动出现，通常需要重新安装依赖或手动复制环境配置。

子 agent 与技能：让上下文保持干净

当项目变多，Ashraf 采用编排者（orchestrator）模式：主 agent 从 GitHub 看板领取任务，再分派给专职子 agent——UI/UX、安全、后端、前端、reviewer、tester 各司其职。每个子 agent 拿到全新的上下文，只回传简短摘要，因此主对话不会被大量中间输出淹没。他甚至给不同子 agent 指定不同模型：负责跑流水线的用轻量模型，reviewer 用推理更强的模型，以控制 token 消耗。

演示中他让主 agent 同时调用 reviewer 和 tester 两个子 agent 检查 diff，并把结论合并成一张短表。这两个子 agent 就定义在仓库的 agents 文件夹里，各自声明名称、描述、可用工具和模型。

技能（skill）则是另一层复用：一个文件夹，内含 SKILL.md 加可选脚本。Copilot 只读一行索引，匹配到任务时才打开对应技能。Ashraf 举的例子是「release check」——每次问「这个方案可以发布了吗」，agent 就会调用该技能跑检查清单并输出报告。他提到社区已有大量现成技能可复用，且「一百个技能在未被调用前几乎零成本」。

自动化与手机遥控：把 routine 交给 agent

两个被他称为「最爱」的功能：一是定时自动化，比如每次有 PR 时自动检查文档是否同步更新，或每天上班前自动拉取 main 并汇总新评论；二是远程控制，在 VS Code 设置里开启后，输入 remote on，就能在手机上查看 agent 进度、批准工具调用。通勤路上想到新功能，直接让 agent 开发并创建 issue，再交给另一个 agent 评审。

关于「如何为任务选对模型」，他的回答很实在：模型迭代太快，不存在固定的匹配表。他的策略是——简单任务用轻量模型；复杂 bug 时让两到三个模型同时调查并交叉验证，如果两个模型结论重合度约 95%，才接受结果。

五条落地建议

• MCP 工具调用必须审批，第三方服务端要审查依赖，先从只读权限开始
• 测试即契约，agent 不得修改测试
• 会话隔离后可以放开权限，但提交前必须逐条阅读 diff
• 一条 routine 重复多次，就该考虑做成技能
• 从小处起步：写一个 instruction 文件、接一个 MCP、拆一个任务给两个 agent

在他看来，节省时间才是这些能力中最核心的价值——每天重复五六次的操作，就值得被自动化。

最小权限与人工审批 是让 agent 安全落地的通用原则：先用只读权限跑通流程，确认行为可预期后再逐步放开写操作；对会改变系统状态的工具调用（创建工单、开 PR、执行命令）保留人工批准环节，相当于给自主循环加一个「断路器」。同时要审查第三方 MCP 服务端的依赖与权限范围，避免把不必要的凭据或数据暴露给它。配合版本控制，每次改动都可 diff、可回滚，出问题时能快速定位与撤销——这比事后追责更有效。