工业AI质检：智能时代的质量革命
2026-06-13 3353136
2026-06-13 0
VS Code Copilot 的本地 Agent 有三种模式：Agent、Plan、Ask。很多开发者打开聊天窗口后，默认就用 Agent 模式，但其实选错模式会直接影响效率和输出质量。
Agent 负责干活，Plan 负责规划，Ask 负责答疑。三种模式各司其职，用对了事半功倍。
这篇文章拆解三种模式的核心差异、适用场景和切换时机，帮你建立正确的使用直觉。
使用本地 Agent 需要：
chat.agent.enabled 设置已开启（组织级别可能禁用，需联系管理员）在 VS Code 的 Agent 体系中，本地 Agent 是唯一在编辑器内部运行的智能体。它直接访问你的工作区、文件、终端、扩展工具和 MCP 服务器。
适合本地 Agent 的场景：
不适合的场景：
本地 Agent 的核心优势是全工具访问。它能调用 VS Code 中所有可用的工具——内置工具、扩展工具、MCP 服务器工具。Copilot CLI 和云端 Agent 在这方面都有不同程度的限制。
Agent 模式是日常开发的主力。它针对基于高层需求的复杂编码任务进行优化，能自主确定相关上下文、规划工作步骤、调用多个工具，并在出错时迭代修复。
核心能力：
典型用法：
Implement a user authentication system with OAuth2 and JWT.
Set up a CI/CD pipeline for this project.
Agent 拿到这种高层需求后，会自己拆解步骤、找到相关文件、生成代码、运行测试。你只需要审查结果，用 Keep/Undo 决定接受或拒绝。
关键技巧：Agent 工作时可以发送后续提示词。把消息加入队列引导 Agent 调整方向，或者立即停止当前任务重新开始。不需要等它完成才能纠正。
Plan 模式是容易被低估的模式。很多开发者跳过规划直接让 Agent 开干，结果发现方向跑偏了，浪费大量时间。
Plan Agent 专门为创建结构化实施计划而优化。它会把复杂功能拆解成更小、更易管理的步骤，并提出澄清性问题确保全面理解任务。
核心能力：
典型用法：
创建一个为应用添加深色/浅色主题切换的计划。切换应能在主题之间切换，并持久保存用户的偏好设置。
Plan Agent 可能会追问：
回答这些问题后，Plan Agent 生成详细计划。然后点击 开始实施，将计划移交给 Agent 或 Copilot CLI 执行。
什么时候必须用 Plan：
Ask 模式最适合回答关于代码库、编码和通用技术概念的问题。它使用 Agent 能力研究代码库并收集相关上下文，但不会主动修改代码。
核心能力：
#codebase 上下文变量）典型用法：
Provide 3 ways to implement a search feature in React.
Where is the db connection configured in this project? #codebase
Ask 的响应可能包含代码块。将鼠标悬停在代码块上，点击 在编辑器中应用 按钮，就能把建议的代码插入到文件中。这比 Agent 直接修改更可控——你决定哪些代码块要应用。
什么时候用 Ask 而不是 Agent：
| 特性 | Agent | Plan | Ask |
|---|---|---|---|
| 核心功能 | 自主编码实施 | 创建结构化计划 | 回答问题、提供方案 |
| 修改代码 | 是，直接编辑文件 | 否，只生成计划 | 否，代码块可选应用 |
| 调用工具 | 终端、文件、扩展工具 | 研究工具 | 研究工具 |
| 交互方式 | 实时反馈、可中途纠正 | 提问澄清、完善计划 | 一问一答、追问深入 |
| 输出产物 | 代码变更 | 实施计划 | 文字回答 + 可选代码块 |
| 典型耗时 | 几分钟到几十分钟 | 几十秒到几分钟 | 几秒到几十秒 |
很多开发者第一次接触 Subagent 时，会以为它是 Agent、Plan、Ask 之外的"第四种模式"。这是一个常见的误解。
Subagent 不是聊天模式，而是一种任务委派机制。
| 维度 | Agent / Plan / Ask | Subagent |
|---|---|---|
| 本质 | 聊天会话的模式 | Agent 内部的任务委派工具 |
| 谁发起 | 你手动选择 | 主 Agent 自动决定 |
| 是否可见 | 你直接对话 | 主 Agent 内部调用，折叠显示 |
| 上下文 | 整个对话历史 | 隔离的干净上下文 |
| 并行能力 | 不支持（一次一个模式） | 支持多个 Subagent 并行执行 |
一句话总结：Agent、Plan、Ask 是你和 AI 之间的对话模式；Subagent 是 AI 在内部把复杂任务拆分、委派给"分身"执行的机制。你不需要手动说"启动一个 Subagent"，主 Agent 会在需要时自动判断。
你用 Agent 模式工作时，以下场景主 Agent 可能会自动调用 Subagent：
并行分析：同时研究多个模块，互不干扰
分析 auth、payment、notification 三个模块的安全漏洞。
Agent 可能启动 3 个 Subagent 并行分析，各自拿到干净上下文，最后汇总。
独立探索：需要不受主对话历史影响的全新视角
先探索几种不同的数据库迁移方案，然后推荐最优的。
Agent 可能启动多个 Subagent 分别研究不同方案，避免彼此"锚定"。
专注审查：用特定角色审查代码
审查这次 PR 的所有变更，重点关注安全、性能和可读性。
Agent 可能并行启动安全审查、性能审查、代码质量审查三个 Subagent。
Subagent 本身不替代 Agent/Plan/Ask，而是增强了 Agent 模式的能力：
你可以创建专用的自定义 Agent，只在 Subagent 中被调用（不在聊天下拉菜单中显示）：
---
name: security-reviewer
user-invocable: false
tools: ['read', 'search']
---你是安全审查专家。审查代码时关注：
- 输入验证和注入风险
- 认证和授权漏洞
- 敏感数据暴露
设置 user-invocable: false 后，这个 Agent 只作为 Subagent 被主 Agent 调用，不会出现在聊天界面的下拉菜单里。每个自定义 Subagent 可以指定专用的工具集和模型，实现"专人专事"。
大部分情况下你不需要手动操作 Subagent——主 Agent 自动处理。但在以下场景，理解 Subagent 能帮你更好地使用 Agent：
三种模式不是互斥的，同一个任务中可以灵活切换。
推荐工作流：
Ask 起步：先用 Ask 了解代码库现状、探索可行方案
How is authentication currently handled in this project? #codebase
Plan 规划：切换到 Plan，生成实施计划
Create a plan to refactor the auth system to use OAuth2.
Agent 执行：审查计划后，切换 Agent 开始实施
Implement the plan for OAuth2 refactoring.
Ask 验证：完成后用 Ask 检查结果
Review the changes and identify any potential issues.
切换方式：在聊天视图的 Agent 选择器中随时切换模式。切换后，之前的对话上下文保留，新模式的响应会基于已有讨论继续。
误区一：所有任务都用 Agent
Agent 会主动修改代码。如果只是想了解方案，用 Ask 更合适。Agent 的"自主性"在探索阶段反而是负担——它可能在你还没想清楚的时候就改了文件。
误区二：跳过 Plan 直接执行
复杂任务跳过 Plan 是效率杀手。Agent 没有充分规划就开始改代码，容易走偏方向。花 30 秒让 Plan 生成计划，能省下后面 10 分钟的回滚时间。
误区三：以为模型跑在本地
"本地 Agent"指的是 Agent 编排逻辑在本地 VS Code 中运行，不是语言模型在本地运行。模型的位置取决于你选择的模型提供商——GitHub Copilot 的模型在远程，BYOK 模型可以在本地或私有基础设施上。