VS Code 的 AI Chat 现在已经这么能干了？

VS Code 的 AI Chat 现在已经这么能干了？聊聊最近这波 Agent 功能

最近重新折腾了一下 VS Code 的 AI Chat，发现它和以前印象里的 Copilot 已经不是一回事了。

以前用 Copilot，基本就是写代码的时候给我补一段：

javascript 复制代码

// 写一个 debounce
function debounce(...)

然后 AI 帮你把函数补出来。

现在的 VS Code Chat 更像是：你把一个开发任务丢进去，它自己去看项目、找代码、改文件、跑命令、看结果，再继续修改。

比如你说：

"给这个 React 项目增加一个登录页，支持表单校验，接口先按照 /api/login 来写，完成以后跑一下测试。"

这时候你不需要告诉它：

bash 复制代码

先打开 src/pages/login.tsx
然后修改 router.ts
然后增加 login.ts
然后执行 npm test

Agent 会自己决定先看什么、改什么、执行什么。

整个过程大概变成：

复制代码

需求 → 分析项目 → 制定计划 → 修改代码 → 执行命令/测试 → 根据结果继续修改 → 完成

这也是我觉得现在 VS Code AI Chat 最值得关注的地方。

它正在从"帮我写一段代码 "，慢慢变成"帮我把这个开发任务做完"。

一、先别急着研究一堆名词，先搞清楚 Chat 和 Agent 的区别

很多人第一次看到 VS Code 最近这套功能，会被一堆概念搞晕：

Chat、Agent、Plan、Subagents、MCP、Skills、Hooks、Custom Agents、Agent Plugins......

看起来像又出来了一套 AI 技术栈。

其实没那么复杂。

最开始的 AI Chat，更像是：

复制代码

你提问 → AI 回答

然后变成：

复制代码

你提需求 → AI 修改当前代码

再往后就是：

复制代码

你提需求 → AI 自己分析项目 → 调工具 → 修改代码 → 验证结果

最后这个模式，就是现在大家说的 Agent。

所以 Agent 最重要的变化，并不是"回答更聪明了"，而是它开始拥有完成任务的过程。

比如一个普通 Chat 可能告诉你：

你可以在 UserService 里面增加一个 deleteUser 方法。

Agent 则可能直接：

markdown 复制代码

搜索 UserService
    ↓
找到相关接口
    ↓
修改 Service
    ↓
检查调用方
    ↓
补测试
    ↓
运行测试
    ↓
发现类型错误
    ↓
继续修改

这两种体验完全不一样。

二、现在 VS Code 里的 Agent，到底在干什么？

如果你以前用过 Claude Code、Codex、Cursor Agent 之类的东西，其实很好理解。

VS Code 的 Agent 也是类似思路。

它手里不是只有一个聊天框，而是一套工具。

例如：

读文件
搜索代码
修改文件
创建文件
执行终端命令
查看测试结果
使用 MCP 工具
调用其他 Agent

所以它面对一个需求的时候，不需要每一步都问你。

例如：

"把项目里的 ESLint 错误解决掉。"

它可以自己开始：

复制代码

搜索 ESLint 配置 → 扫描错误 → 修改代码 → 执行 lint → 查看错误 → 继续修复

如果错误很多，还可能进一步分析哪些问题是配置导致的，哪些是真正的代码问题。

这也是为什么现在很多 AI 编程工具越来越像"开发助手"，而不是"代码补全插件"。

VS Code 官方目前已经把这套能力直接放到了 Chat/Agent 体系里。Agent 可以使用工具完成多步骤任务，也可以根据任务结果继续推进。

三、Plan Agent：我觉得这是比较实用的一个功能

Agent 最大的问题其实不是"不会写代码"。

而是：

有时候它太急着写代码。

你给它一个比较大的需求：

"把这个项目的状态管理从 Redux 改成 Zustand。"

如果直接让 Agent 开干，它可能马上开始改。

但这种事情通常不是改一个文件。

可能涉及：

复制代码

Redux Store
→ Actions
→ Selectors
→ Hooks
→ Components
→ Tests
→ Middleware
→ 类型定义

这里最容易出现的问题就是：改到一半发现原来的架构理解错了。

所以现在 VS Code 里有了 Plan 这个思路。

先不要改代码，而是让它分析：

复制代码

需求 → 阅读项目 → 找相关代码 → 分析依赖 → 给出修改计划

你看完计划觉得没问题，再进入真正的实现阶段。

这其实非常接近我们平时开发的方式：

复制代码

需求
  ↓
技术方案
  ↓
开发
  ↓
测试

而不是：

复制代码

需求 → AI 直接开改

对于小需求，Plan 可能没什么必要。

但如果是这种任务：

"把现有表单系统改成 JSON Schema 驱动，并且保持原来的 API 不变。"

我会比较建议先 Plan。

四、一个很重要的变化：Agent 干活的时候，你可以插话

以前 AI Coding 很容易出现一个问题。

你让它：

"重构这个模块。"

然后它开始疯狂修改。

结果你看了半天发现：

"等等，我不是这个意思。"

只能停止，再重新说一遍。

现在 Agent 的交互越来越接近一个真正的开发助手。

它执行任务的过程中，你可以继续给它补充要求：

"这里不要改 API。"
"这个组件需要兼容旧数据。"
"测试先不要动。"
"刚才那个方案不要了，换成 Context。"

也就是说，Agent 不再是"一次性生成"。

而是一个持续运行的任务。

可以把它理解成：

复制代码

你
↕
Agent
↕
代码 / 文件 / Terminal / Tools

你不是只负责"发 prompt"。

而是在整个任务过程中不断纠偏。

这一点其实挺重要。

因为真实开发本来就不是：

一句话需求 → 完美实现

而是：

需求 → 实现 → 发现问题 → 调整 → 再实现

AI Coding 开始越来越接近这个过程。

五、Subagents：一个 Agent 搞不定，就拆人

这个功能我觉得比较容易理解。

比如现在有一个需求：

"分析一下这个项目为什么首屏这么慢。"

这件事情其实可以拆成好几个方向：

复制代码

主 Agent
→ Bundle 分析
→ Network 分析
→ React 渲染分析
→ 图片/静态资源分析
→ 汇总结果

每个子任务交给一个 Subagent。

最后主 Agent 再把结果汇总起来。

例如：

markdown 复制代码

主 Agent
├─ Bundle Agent：分析 JS 包
├─ React Agent：分析组件渲染
├─ Network Agent：分析请求
└─ Performance Agent：分析性能指标
             ↓
          汇总结论

当然，真正使用的时候不一定非得搞这么复杂。

Subagent 更适合那些可以独立分析、互相影响比较小的任务。

例如：

分析测试失败原因
分析某个模块
检查安全问题
查找重复代码
分析 API 使用情况

官方现在已经支持让 Agent 调用其他 Agent 来处理子任务。自定义 Agent 也可以作为 Subagent 使用。

所以它和普通"多开几个聊天窗口"还是有区别的。

重点在于：

主 Agent 可以把任务交出去，再拿结果回来继续工作。

六、MCP：终于不只是"看代码"了

如果你之前折腾过 MCP，应该比较容易理解这个功能。

没有 MCP 的时候，Agent 主要能操作：

复制代码

项目代码
文件
Terminal
Git

有了 MCP 以后，可以把更多外部能力接进来。

例如：

css 复制代码

VS Code Agent
      ↓
     MCP
 ┌────┼─────┐
 ↓    ↓     ↓
数据库 GitHub Jira

于是你可以让 Agent：

"帮我看一下这个 Issue，然后找到对应代码并修复。"

或者：

"查一下数据库里这个用户的数据，看看为什么前端显示异常。"

当然，实际能不能做到取决于你接入了什么 MCP Server。

所以 MCP 本身并不是某一个具体功能。

它更像是一个给 Agent 接外部工具的接口。

这也是现在 AI Agent 很重要的一层：

复制代码

Agent
  ↓
Tools
  ↓
外部世界

VS Code 的 Chat/Agent 目前支持 MCP 工具，因此 Agent 的能力不再局限于当前编辑器里的代码。

七、Custom Agents：可以自己定义一个"开发角色"

这个功能对于经常重复做某类工作的开发者比较有意思。

VS Code 支持通过 .agent.md 定义自己的 Agent。

例如你可以定义：

复制代码

frontend-reviewer.agent.md

告诉它：

markdown 复制代码

你是一个前端 Code Reviewer。

重点检查：

1. React Hooks 使用
2. TypeScript 类型安全
3. 状态管理
4. 性能问题
5. 可维护性
6. 安全问题

不要直接修改代码。
只输出问题和修改建议。

以后遇到代码 Review，就可以直接使用这个 Agent。

再比如：

复制代码

test-engineer.agent.md

专门负责测试。

或者：

复制代码

security-reviewer.agent.md

专门检查：

复制代码

XSS
CSRF
敏感信息泄露
依赖漏洞
权限问题

这样以后你的 AI Coding 就不再只有一个"大而全"的 Agent。

而是可以变成：

复制代码

通用 Agent
├─ Frontend Reviewer
├─ Test Engineer
├─ Security Reviewer
└─ Performance Analyst

官方的 Custom Agents 本质上就是通过配置文件定义 Agent 的行为、工具、模型以及协作方式等。默认可以放在 .github/agents 等目录中。

八、Skills：把"会做某件事情"单独抽出来

如果说 Custom Agent 是"一个角色"，那么 Skill 更像是"一个能力"。

比如你经常需要让 AI 做：

复制代码

生成 API 文档
分析数据库 Schema
写 Playwright 测试
处理 OpenAPI
检查前端性能

每次都重新解释一遍，其实挺烦。

于是可以把这些操作整理成 Skill。

比如：

复制代码

Playwright Testing Skill

里面放：

复制代码

测试规范
项目测试目录
命名规则
常用命令
测试工具
注意事项

以后 Agent 遇到测试任务，需要的时候加载这个 Skill。

这里有一个比较重要的思想：

不是把所有上下文一次性塞给 Agent，而是需要什么再加载什么。

这其实和我们最近讨论的 Context Engineering 很接近。

不要：

diff 复制代码

所有规则
+
所有项目文档
+
所有工具
+
所有历史信息
→
全部塞进 Context

而是：

复制代码

当前任务
→
判断需要什么能力
→
加载对应 Skill
→
完成任务

这对大型项目尤其重要。

九、Hooks：让 Agent 干完活以后自动检查

Hooks 可以理解成 Agent 工作流程里的"钩子"。

比如你希望：

AI 每次修改完代码，都自动执行 ESLint。

那么可以做成：

arduino 复制代码

Agent 修改代码
→ Hook
→ npm run lint
→ 检查结果
→ 有问题 → Agent 继续修

再比如：

复制代码

Agent 修改代码
→ TypeScript 检查
→ 单元测试
→ 安全扫描
→ 通过

这样以后 Agent 就不是：

"我觉得代码应该没问题。"

而是：

"我改完了，并且检查通过了。"

这个区别还是挺大的。

因为 AI Coding 最大的问题之一，就是它特别容易"自信地认为自己完成了"。

自动验证可以把这个问题压下去。

十、Agent Sessions：开始管理"任务"了

如果你只是让 AI 改一个 Button，Chat 就够用了。

但如果你同时有：

复制代码

修复登录问题
重构用户模块
增加单元测试
处理 ESLint
分析线上 Bug

这时候就会发现：

聊天记录已经不太适合作为任务管理方式了。

所以 VS Code 现在也在强化 Agent Sessions 这种体验。

你可以把一次 Agent 工作看成一个独立任务。

例如：

bash 复制代码

Session #1：修复登录 Bug
Session #2：重构 UserService
Session #3：增加 Playwright 测试
Session #4：分析 Bundle 体积

每个任务都有自己的执行过程和上下文。

这就比较像一个轻量级的 AI 任务中心。

VS Code 也在逐步把不同 Agent、不同会话以及任务委派统一到一个工作流里。

十一、那 Copilot、Claude、Codex 又是什么关系？

这部分其实很容易搞混。

现在 VS Code 更像一个"Agent 工作台"。

你可以把它理解成：

css 复制代码

VS Code
  ↓
Agent / Chat
  ↓
选择不同模型 / Agent Harness
  ↓
执行任务

也就是说：

VS Code 不一定等于某一个模型。

你可以根据任务选择不同的模型或者 Agent。

现在 VS Code 也在支持包括 Copilot、Claude、Codex，以及 BYOK 等不同模型使用方式。BYOK 还可以接入包括 OpenAI、Anthropic、Gemini、OpenRouter，以及部分本地模型方案。

所以以后可能出现这种使用方式：

css 复制代码

写普通业务代码 → 模型 A

复杂重构 → 模型 B

代码 Review → 模型 C

本地敏感项目 → 本地模型

模型本身只是底层能力。

真正决定 Agent 好不好用的，还有：

diff 复制代码

Context
+
Tools
+
Rules
+
Memory
+
Workflow
+
Model

这也是为什么最近大家讨论 AI Coding 的时候，越来越少只讨论"哪个模型写代码最好"。

十二、Agent Plugins 又是干什么的？

如果前面的东西你觉得有点零散，Agent Plugins 可以理解成：

把一套 Agent 能力打包起来。

例如一个团队可以做一个：

复制代码

Company Frontend Agent Plugin

里面放：

diff 复制代码

Skills
+
MCP
+
Custom Agents
+
其他配置

然后团队成员装上以后，大家用的是同一套能力。

这对于公司内部其实挺有用。

比如公司规定：

复制代码

React 开发规范
API 调用规范
安全检查规范
测试规范
代码 Review 规则

不需要每个人自己配置。

直接把这套 Agent 能力打包。

官方现在也在推动 Agent Plugins 作为一种标准化的扩展方式，让 Agent 的 Skills、MCP 等能力可以更方便地组合和复用。

十三、把这些东西放在一起，就比较容易理解了

如果把现在 VS Code 的 Agent 能力压缩成一张图，我觉得可以这么看：

css 复制代码

                 VS Code
                    ↓
               Agent / Chat
                    ↓
        ┌───────────┼───────────┐
        ↓           ↓           ↓
      Plan       Execute      Sessions
                    ↓
             ┌──────┼──────┐
             ↓      ↓      ↓
           Files  Terminal MCP
             ↓      ↓      ↓
           Skills  Hooks  Tools
                    ↓
                 Subagents

再往下面，就是模型：

复制代码

Agent
  ↓
Model
  ↓
LLM

所以不要把这些名词理解成十几个互不相关的功能。

它们其实都在解决一个问题：

怎样让 AI 不只是回答问题，而是真正参与一次软件开发任务。

十四、对于前端开发，哪些功能最值得用？

如果你平时主要做 React / TypeScript / Next.js 这类前端项目，我个人会按照这个顺序上手。

第一阶段：先把 Agent 用起来

先别研究 MCP、Skills、Hooks。

直接拿真实项目试：

复制代码

"分析这个页面为什么渲染慢，并给出修改方案。"

然后再试：

复制代码

"把这个组件拆成三个组件，并保持现有行为不变。"

再试：

复制代码

"给这个模块补完整的单元测试，然后运行测试并修复失败项。"

先体验 Agent 到底能不能把一个任务跑通。

第二阶段：开始使用 Plan

当需求开始变复杂，就不要一上来让 Agent 修改。

先：

复制代码

需求 → Plan → Review → Implement

尤其是涉及多个模块的时候。

第三阶段：开始写 Custom Agent

当你发现自己经常重复说：

"帮我按照我们的前端规范 Review 一遍。"

这时候就可以做一个：

复制代码

frontend-reviewer.agent.md

把规则固定下来。

第四阶段：再研究 MCP

当你发现：

"我希望 Agent 能查 GitHub / Jira / 数据库 / 内部 API。"

这时候再上 MCP。

因为 MCP 真正有价值的地方，不是"多了一个 AI 名词"。

而是：

Agent 开始能够碰到代码库之外的东西。

第五阶段：最后再玩 Skills、Hooks、Plugins

这些更适合把已经验证过的工作流程固化下来。

最终可能变成：

复制代码

需求
 ↓
Plan Agent
 ↓
主 Agent
 ↓
调用 Skills
 ↓
调用 MCP / Tools
 ↓
Subagents 并行处理
 ↓
Hooks 自动检查
 ↓
测试通过
 ↓
完成

这个时候，AI 才真正开始从"代码助手"变成"开发流程的一部分"。

十五、我觉得 VS Code 这波更新真正值得关注的，不是某一个功能

如果只看功能列表，很容易变成：

VS Code 新增了 Plan。
VS Code 新增了 Subagents。
VS Code 新增了 Skills。
VS Code 新增了 Hooks。
VS Code 新增了 MCP。

看完以后可能什么都记不住。

但把它们串起来看，就比较清楚了。

以前的 AI Coding 更像：

markdown 复制代码

人写代码
  +
AI 帮忙写

现在越来越接近：

markdown 复制代码

人提出目标
      ↓
Agent 分析任务
      ↓
Agent 操作代码
      ↓
Agent 调用工具
      ↓
Agent 执行测试
      ↓
Agent 根据结果继续修改
      ↓
人负责判断和纠偏

这时候人的工作也会发生一点变化。

以前我们花很多时间在：

复制代码

找文件
看代码
写代码
改代码
跑测试
查错误

以后可能会越来越多变成：

复制代码

定义目标
拆任务
约束 Agent
检查方案
Review 结果
处理复杂决策

所以我现在反而觉得，学 AI Coding 不应该只学 Prompt。

真正值得研究的是：

diff 复制代码

Agent
+
Tool Calling
+
MCP
+
Context Engineering
+
Memory
+
Workflow
+
Evaluation

因为 Prompt 解决的只是"怎么告诉 AI"。

而 Agent 解决的是：

"告诉 AI 以后，它怎么把事情做完。"

最后

如果你最近还把 VS Code 的 Copilot 理解成：

"写代码的时候右边弹一个聊天框。"

那确实已经有点过时了。

现在的 VS Code 更像是在慢慢变成一个 Agent 工作台。

编辑器还是那个编辑器，但 AI 已经不只是坐在旁边给你代码提示，而是可以真正参与：

复制代码

分析 → 规划 → 编码 → 调工具 → 测试 → 修复

当然，这并不意味着以后开发就变成"把需求扔给 AI，然后下班"。

恰恰相反。

任务越复杂，越需要开发者知道：

什么时候让 Agent 自己做，什么时候限制它，什么时候拆任务，什么时候让它停下来给方案，什么时候必须自己 Review。

这可能才是接下来 AI Coding 真正值得学的东西。