摘要：本文深入解析 GitHub Copilot 的 Agent 模式，它是继 Chat（对话分析）和 Edit（原地修改）之后的第三代 AI 编程助手。Agent 模式的核心是“自动执行”：你只需告诉它最终目标（如“加一个分页查询接口”），它便能自主分析项目结构、修改多个文件、运行测试并修复 Bug，完成从需求到可运行代码的全流程。文章通过三个实战案例（补全接口文档、自动修 Bug、重构老项目）和五大使用技巧，详细展示了 Agent 模式如何将开发者从重复性、跨文件的机械操作中解放出来，并与 Chat、Edit 形成互补的工作流，最终实现“Chat 讨论方案 → Edit 精准修改 → Agent 自动执行”的高效组合。

背景回顾：从补全到代理

如果你是从第一篇开始追这个专栏的，你应该记得我们聊了 Copilot 的两大核心能力：

- Copilot Chat — 侧边栏聊天窗口，适合问问题、分析代码、讨论方案

- Copilot Edit — 内联编辑器，适合选中代码原地修改、重构

这两个功能的区别很简单：Chat 是"跟你讨论"，Edit 是"直接动手改"。

但 Copilot 在 2026 年更新了一个更重要的模式——Agent 模式。

Agent 模式跟 Chat 和 Edit 最大的区别在于：它不需要你告诉它改什么，只需要你告诉它要什么结果。中间的步骤——创建文件、修改代码、运行命令、检查结果、修正 bug——都是由 Copilot 自己完成的。

一个典型的场景对比：

用 Edit：

你：选中代码 → Ctrl+I → "给我加一个分页功能"

Copilot Edit：在你的代码旁边生成 diff，你看着 Accept

用 Agent：

你：Ctrl+Shift+I → "帮我在 UserController 里加一个分页查询接口，支持按用户名模糊搜索，用 MyBatis-Plus 实现"

Copilot Agent：自己思考需要哪些步骤 → 打开 Controller 文件 → 修改代码 → 创建 Mapper 方法 → 检查有没有遗漏 → 全部改完后告诉你结果

第二个场景里的 Copilot Agent，实际上承担了一个初级开发者的角色。你给它一个需求，它从头干到底，你最后验收结果就行。

Agent 模式到底能做什么

先说清楚一个概念：VS Code 里的 Copilot Agent 跟 GitHub 上那个 Copilot Agent 是两个东西。今天聊的是VS Code 编辑器里的 Agent 模式——它在你编辑器的上下文里工作，能看到你打开的文件、项目结构、终端输出。

Agent 模式能做的事情包括：

第一类：多文件修改

这是 Agent 跟 Edit 最大的区别。Edit 一次只改一个文件的一块代码。Agent 可以同时改多个文件。

假设你要给项目加一个"用户登录日志"的功能。

用 Edit，你得：先改 Controller 加接口 → 再改 Service 加方法 → 再创建 LogMapper → 再建数据库表 → 再改配置文件。

改 5 个文件，切 5 次，做 5 次 diff。

用 Agent，你只需要说一句：

给项目加用户登录日志功能：每次登录成功记录到 login_log 表，
字段包括 user_id、login_time、ip_address、user_agent。

Agent 会自动分析项目结构，找到 Controller（加日志记录逻辑）、创建 LoginLog 实体和 Mapper、建表 SQL。一条提示词，改好了 4 个文件，你逐文件审查一次就行。

第二类：自动跑测试和修 Bug

Agent 模式下，Copilot 可以执行终端命令。你让它跑测试，它就跑。跑挂了，它就看错误日志，自己定位问题，自己改代码修复，再跑一次。

你不需要打开终端、不需要分析报错、不需要手动修改。Agent 跑完会说"测试通过，修复了 3 个问题"。

举个例子：

我在 user_service_test.py 里加了一些测试用例，帮我跑一下看看能不能通过

Agent 会：

1. 打开终端 → pytest userservicetest.py -v

2. 看到 3 个 FAILED

3. 分析每个失败的报错：AssertionError、TypeError、NameError

4. 打开对应的 user_service.py，逐个定位问题

5. 修改代码

6. 重新跑测试

7. 全部通过后告诉你：测试通过，修复了 mock 参数不匹配、类型转换遗漏、变量名拼写错误三个问题

整个过程你只需要看结果，什么都不用操作。

第三类：项目创建、代码迁移、重构

中小型项目可以从头让 Agent 帮你创建。

用 Express + TypeScript 创建一个 TODO API 项目。
数据库用 SQLite，ORM 用 Prisma。
需要有完整的 CRUD 接口、数据校验、错误处理。
启动后输出到 terminal：Server running on port 3000

Agent 会自己走安装流程：

✅ 初始化项目 package.json
✅ 安装 express, prisma, typescript 等依赖
✅ 配置 tsconfig.json
✅ 创建 Prisma schema
✅ 生成数据库迁移
✅ 写路由文件、控制器、中间件
✅ 启动项目验证接口可用
→ 全部完成用时 3 分 12 秒

很接近 Claude Code 的操作方式——但 Claude Code 是在终端里，你的 IDE 体验是零。Agent 模式在 VS Code 里运行，你可以实时看到文件的变化和 diff。

打开 Agent 模式的方法

Copilot Agent 的入口在 VS Code 里很显眼——Chat 面板左上角有一个切换按钮。

默认是 Chat 模式（聊天气泡图标），点一下切换到 Agent 模式（小机器人图标），再点一下切换回 Chat。

用快捷键触发的话：

- Ctrl+Shift+I 打开 Chat 面板 → 默认是 Chat 模式

- Ctrl+I 在弹出的 Edit 输入框 → 输入框右下角也有一个「切换到 Agent」按钮

- 最直接的：直接在 Chat 面板打 /agent 后面跟你的需求

切换完成后，你会看到输入框下面多了一行提示：

Agent 模式 | Copilot 将读取你的工作区文件并执行操作

同时出现两个选项：

- 编辑文件（默认开启）— Agent 可以修改你的代码文件

- 运行命令（默认关闭）— Agent 可以执行终端命令（首次需要你确认）

如果打开"运行命令"，Agent 的威力才能完全释放——它可以在终端里跑测试、安装依赖、编译代码。

但注意：建议第一次使用 Agent 模式的时候，先把运行命令关闭。等你有把握了再打开。不然 Agent 自动给你装了一堆依赖，你可能都不知道发生了什么。

实战一：用 Agent 补全接口文档

场景：你有一个 Spring Boot 项目，控制器写完了，但没写 Swagger 注解。

之前的做法：手动在每个 Controller 方法上加 @Operation、@ApiResponse。20 个接口，一个一个加，枯燥且容易漏。

用 Agent：

在 Chat 面板切换到 Agent 模式，输入：

给 controller 包下所有 REST 接口加上 Swagger 注解。
每个接口的描述从方法名和参数名推断。
响应错误码统一加：400（参数错误）、500（服务器错误）、200（成功）。

Agent 会：

1. 扫描 controller 目录，找到 20 个文件

2. 分析每个方法签名和参数名

3. 推断接口描述：「根据用户名和邮箱查询用户」→ @Operation(summary = "查询用户", description = "根据用户名和邮箱模糊查询")

4. 给每个方法加上 @ApiResponses

5. 所有文件改完后逐个展示 diff

结果：20 个文件，全部加上了 Swagger 注解，耗时大约 40 秒。

你逐个文件翻一遍，看到不合适的描述手动改一下，就搞定了。

实战二：用 Agent 自动修 Bug

比改代码更爽的是让 Agent 帮你 Debug。

你有一个 Node.js 项目，用户反馈了一个 Bug：上传文件超过 10MB 时，服务器直接挂了，连错误提示都没有。

你在 Agent 模式下输入：

用户上传文件超过 10MB 时服务器崩溃，帮我找到问题并修复。
重点关注文件上传相关的中间件和路由。

Agent 会：

1. 打开项目结构，找到 multer 配置文件和文件上传路由

2. 分析代码：发现 multer 的 limits.fileSize 没设，Nginx 也没有限制

3. 检查后端有没有错误处理中间件——发现没有全局错误拦截

4. 于是它做了三件事：

- 给 multer 加上 limits: { fileSize: 10 1024 1024 }

- 加了一个全局错误处理中间件，捕获 MulterError 返回友好提示

- 在 nginx.conf 加入 clientmaxbody_size 10m

然后它报告结果：

✅ 修复完成，改动 3 个文件：
1. src/middleware/upload.js — 添加 fileSize 限制（10MB）
2. src/middleware/errorHandler.js — 新增全局错误处理
3. nginx.conf — 添加 client_max_body_size 10m
已生成超过10MB文件的测试用例，需要我跑测试验证吗？

Agent 的 Debug 能力强在其理解整个系统的上下文——它知道瓶颈可能在前端、后端、Nginx、数据库等不同层面。给它一个 Bug 描述，它自己就能顺藤摸瓜找到根因。

实战三：用 Agent 重构老项目

假设你要接手一个同事留下的老项目——Java 8、Spring Boot 2.x、JSP 页面混杂、手写 JDBC。

你的任务是把它升级到 Spring Boot 3.x + MyBatis-Plus。

大部分程序员看到这种任务脑子已经开始疼了。但用 Agent，你可以拆成几个小任务：

第一步：让 Agent 分析项目结构

分析这个项目的依赖和架构，列出迁移到 Spring Boot 3.x + MyBatis-Plus 需要改动的地方。
按改动量从大到小排列。

Agent 读完项目后会输出一份详细的迁移计划，包括哪些文件需要改动、涉及那些依赖升级、有哪些已知的兼容性问题。

第二步：让 Agent 逐个执行

开始迁移：先把 pom.xml 里的 Spring Boot 版本从 2.x 升级到 3.x，
同时检查所有依赖的兼容性，列出需要升级的第三方库。

Agent 会逐条处理，每改完一个文件就展示 diff，你确认后执行下一步。

第三步：替换 DAO 层

把所有手写 JDBC 的 DAO 类改成 MyBatis-Plus 的 BaseMapper 继承方式。
Mapper XML 文件保留不动。

Agent 会扫描所有 DAO 类，逐个替换。

这种大型重构一口气让 Agent 做完不现实，会有遗漏。但拆成清晰的子任务，每个任务做一次验证，经过 3-5 轮对话，就能逐步替你把整个项目翻新一遍。

什么时候该用 Agent，什么时候不该用

Agent 模式很强大，但不是所有场景都适合。

适合 Agent 的场景

1. 重复性修改

批量加注释、批量加日志、批量改命名、批量改参数——任何需要"在所有类里做同样的事"的场景，Agent 比人高效 10 倍。

2. 跨文件修改

一个需求改动涉及 3 个以上的文件，用 Edit 要切来切去，用 Agent 一站式搞定。

3. 需要跑命令验证

"写完代码后跑测试验证"——Agent 可以自动执行测试命令、分析结果、修完继续跑。

4. 你心里有底但你懒的操作

你知道怎么写，你完全能做，但你觉得"这种事情让 AI 做吧"——这是 Agent 最舒服的场景。你给明确的指令，它一模一样的执行。

不适合 Agent 的场景

1. 需要精确控制修改范围的

Agent 有时候会改多——它觉得改 A 的时候顺便改一下 B 的命名更统一。但对于需要严格控制的代码（比如支付模块、安全模块），多改一点都不行。

2. 第一次写的代码

你不确定怎么写的时候，你甚至没法判断 Agent 写得好不好。这种情况下，用 Chat 问清楚方案，再用 Edit 逐步写，更适合。

3. 涉及外部系统变更的

Agent 只能改你项目目录里的代码。它不能帮你配置 AWS、不能帮你改线上数据库、不能帮你发 PR。它的边界是你的工作区。

Agent 模式的使用技巧

用了一段时间 Agent 模式之后，我总结了几个实用技巧：

技巧一：第一步先分析，不要一上来就改

Agent 模式最容易翻车的地方是——它没理解透你的项目就开始改。

解决办法是，任何复杂操作前先加一句：

先分析，不要改。列一下需要改哪些文件、改什么内容。

Agent 会输出一份计划，你审完说"好，按这个执行"，它再动手。

技巧二：复杂操作分批进行

把一个大需求拆成 3-5 个明确的小步骤，每一步做完你确认一次。

第一步：给 UserController 加分页查询接口 ✅ 确认
第二步：创建对应的 Service 方法 ✅ 确认
第三步：加 Mapper 查询方法 ✅ 确认
第四步：跑测试看能不能用 ✅ 确认

如果你一次把四个步骤都扔给 Agent，它可能会全部做完但是其中某一步跑偏了，你还要回退。

技巧三：给 Agent 看例子

Agent 执行多文件修改时，它理解项目风格的能力没有你想象中那么强。

如果你想让 Agent 参考项目中已有的某个写法，直接把那个文件拖到 Chat 里给它看看：

参考这个 UserController 的写法风格，给 OrderController 也加上类似的日志和异常处理。

有了参考文件，Agent 生成的代码风格贴合度会提升很多。

技巧四：修改前先备份

Agent 会直接修改你的代码文件。如果出错了，虽然有 Undo 可以回退，但批量修改后 Undo 可能覆盖不了所有改变。

建议：在让 Agent 做大范围修改前，先 git stash 或创建新分支。

git checkout -b agent-refactor-xxxx

Agent 改完你觉得 ok，再合并到主分支。有问题直接删分支重来，零成本。

技巧五：第一次用先关闭"运行命令"

Agent 的"运行命令"能力是双刃剑。它能自动安装依赖、跑测试、编译代码，非常强。但你得看住它别让它乱装东西。

建议第一次使用时关闭"运行命令"。等理解 Agent 的行为模式后，再对有把握的操作打开。

Agent vs Edit vs Chat：怎么组合

Copilot 三个模式不是互相替代的，是三种不同层级的助手：

模式	能力	你做什么	AI 做什么	适合场景
Chat	对话	问	答	分析代码、设计方案、学习
Edit	原地修改	选中范围、说需求	原地改代码	精准修改、小范围重构
Agent	自动执行	说需求，审结果	分析、改代码、跑命令	多文件修改、Debug、自动测试

一个典型的一天工作流：

1. 早上打开一个 PR，不知道它在改什么 → Chat："这个 PR 的改动范围是什么？"

2. 讨论方案 → Chat："这段代码用状态模式合适吗？"

3. 确定要改了 → Edit：选中方法，说需求，Accept

4. 涉及多个文件 → Agent："在这个模块加缓存，参考 user 模块的缓存写法"

5. 跑测试 → Agent："跑测试看有没有问题"

6. 最终 Review → Chat：把改完的代码贴过去，让它做性能分析

总结

Copilot Agent 模式是 VS Code 里 AI 编程能力的一次跃升。它不是简单改代码，而是理解上下文、分析需求、多步执行、验证结果——更接近一个初级开发者的角色。

从使用频率上看，我自己的实际体验：

- Chat：每天都在用（问问题、讨论方案）

- Edit：写代码时高频使用（80%的代码修改）

- Agent：每天用 2-3 次，用于：批量修改、自动测试、项目初始搭建

Agent 不会完全取代 Chat 和 Edit。但它是三个人里面最能让你"少干活"的那个。它适合你做但不想做的重复劳动——批量加注释、改命名、跑测试。

你跟 Agent 配合的默契度越高，你花在机械操作上的时间就越少。

如果你还没有试过 Agent 模式，今天就可以试：打开 VS Code，按 Ctrl+Shift+I，在输入框的下面找到模式切换按钮，切换到小机器人图标，然后输入：

帮我分析这个项目，列出所有的设计模式使用情况。

Agent 会开始扫描你的代码，逐个文件分析，最后给你一份惊喜的清单。看明白 Agent 在干什么之后，你再给它提下一步需求，你会发现——原来之前需要自己动手的那么多步骤，现在说一句话就够了。

---

下一篇预告：Windsurf vs Cursor vs Copilot——2026年AI IDE 横评。这三个神仙打架的 AI 编辑器，到底哪个更适合你？