本站点文档内容均翻译自code.visualstudio.com，仅供个人学习，如有差异请以官网为准。

Visual Studio Code 中的子代理

在处理复杂任务时，您可以将子任务委托给子代理。子代理是一个独立的AI代理，执行专注的工作，例如研究一个话题、分析代码或审查更改，并将结果报告给主代理。由于每个子代理都在自己的上下文Windows中运行，它不会对您的主要对话产生干扰。VS Code还可以并行运行多个子代理，以加速多部分任务。

例如，内置的计划代理使用子代理在制定实施计划之前进行研究和分析。每个子代理都是自主工作的，只返回其调查结果。计划代理将这些调查结果综合成最终计划。

默认情况下，子代理使用与主聊天会话相同的模型和工具，但以干净的上下文Windows开始。子代理不继承主代理的说明或对话历史记录。他们只接收您提供的任务提示。通过将自定义代理作为子代理运行，您可以为特定任务应用专门的行为、工具和模型。

子代理执行如何进行

下图显示了子代理如何工作。主代理接收您的任务，将子任务委托给一个或多个子代理，每个子代理都在自己的上下文中运行，然后将结果结合起来。

显示主代理将子任务委托给在隔离上下文Windows中运行的子代理并接收结果摘要的图表。

子代理是同步的：主代理在继续之前会等待子代理的结果。这种阻塞行为是故意的：子代理的发现通常会告知任务的下一步。没有子代理的结果，主代理缺乏有效推进所需的信息。

然而，VS Code 可以并行启动多个子代理。当您请求并行分析（例如，“同时分析安全性、性能和可访问性”）时，VS Code 会并行运行这些子代理，并在主代理继续之前等待所有结果。

注意

子代理与开始一个新的代理会话不同。一个新的会话创建了一个与当前任务无关的全新对话。子代理保持关系：它们进行专注的工作并向主代理报告，而主代理控制整体任务。

用户所见

当子代理运行时，它在聊天中显示为可折叠的工具调用。默认情况下，子代理是折叠的，并显示：

  • 自定义代理的名称（如果你指定一个）
  • 当前正在运行的工具（例如，“正在读取文件...”或“正在搜索代码库...”）

选择子代理工具调用来展开并查看全部详细信息，包括子代理执行的所有工具调用、传递给子代理的提示以及返回的结果。

这种可见性使您能够在不打扰主要对话的情况下控制看到的详细信息量。

为什么使用子代理？

子代理帮助您更有效地管理复杂的AI辅助工作流程：

  • 保持主要代理上下文集中：主要代理的上下文Windows会累积每个提示和响应的信息。通过将研究、分析或实现任务委托给子代理，您可以防止上下文膨胀，并帮助主要代理保持对整体任务协调的关注。

  • 通过并行执行提高性能：VS Code 可以同时运行多个子代理。例如，在实现一个功能时，您可以并行研究认证模式、分析现有代码结构和查看文档，而不是按顺序进行。

  • 隔离实验性或探索性工作：子代理非常适合那些您想探索选项而不愿承诺方向的任务。如果子代理的研究导致 dead end，只有最终总结会影响您的主要上下文 - 而不是所有的中间探索。

  • 为特定任务应用专门的行为：通过将子代理与自定义代理结合，您可以为特定子任务应用专用工具、说明和模型。例如，使用一个关注安全的自定义代理来审查代码以查找漏洞，同时文档代理生成用户指南。

  • 减少令牌的使用和成本：因为子代理有它们自己的上下文Windows，所以它们不会将完整的对话历史添加到主代理的上下文中。只返回最终结果，这可以显著减少复杂任务的整体令牌消耗。

使用场景

以下场景说明了在什么情况下子代理可以改善您的AI辅助开发工作流程。

实施前的研究

在构建新功能时，在主代理开始实施之前，使用子代理来研究最佳实践、评估库或分析代码库中的现有模式：

使用子代理为Node.js应用程序研究OAuth 2.0实现模式。
比较passport.js vs auth0 vs 自定义实现。返回优缺点的建议。

主要代理只接收最终建议，保持其上下文清洁以便实际实施工作。

并行代码分析

在重构或审查代码时，同时运行多个子代理以分析不同的方面：

分析此代码库以寻找重构机会。使用子代理来：
1. 查找重复的代码模式
2. 识别未使用的导出和僵尸代码
3. 检查错误处理的一致性
4. 检查安全漏洞

将调查结果编译成优先级行动计划。
探索多种解决方案

当你不确定最佳方法时，使用子代理来探索不同的选项，而不会污染你的主要上下文：

我需要为这个API实现缓存。并行运行三个子代理来：
1. 设计一个基于Redis的缓存解决方案
2. 设计一个带有LRU淘汰策略的内存缓存解决方案
3. 设计一种带有分层缓存的混合方法

比较结果并推荐最适合我们用例的方法。
代码审查，专注于特定领域

使用自定义代理作为子代理以应用不同的审查视角：

使用子代理审查此PR的更改：
- 运行安全审查代理以检查漏洞
- 运行性能审查代理以识别瓶颈
- 运行无障碍审查代理以验证无障碍合规性

将发现结果合并到一个综合审查总结中。

调用子代理

代理发起 vs. 用户调用

子代理通常是由代理发起的，而不是用户在聊天中直接调用的。为了允许主代理调用子代理，请确保运行子代理工具已启用。

主要代理决定何时进行上下文隔离。你不需要为每个任务手动输入“运行子代理”。模式的工作方式如下：

  1. 您（或您的定制Agents的说明）描述了一个复杂的任务。
  2. 主要代理识别出任务中受益于独立上下文的部分。
  3. 代理启动子代理，仅传递相关的子任务。
  4. 子代理自主工作并返回总结。
  5. 主要代理整合结果并继续。

你可以通过措辞来暗示你希望子代理进行委托，从而表明独立研究或并行分析。主代理将启动子代理，将任务传递给它，并仅接收最终结果。

小贴士

为了确保子代理的一致行为，请在自定义代理的说明中定义何时使用子代理，而不是每次手动提示。

为了优化子代理性能，请明确定义任务和预期输出。这有助于子代理专注于具体目标，而不是将不必要的上下文传递回主代理。

请参阅使用场景部分，了解如何构建调用子代理的提示示例。

在提示文件中调用子代理

要在一个提示文件中调用子代理，请确保运行子代理或Agent工具包含在工具前言属性:

---
名称：文档特性
工具：['代理', '阅读', '搜索', '编辑'
]
---运行一个子代理来研究新的特性实现细节，并仅返回与用户文档相关的信息。
然后更新docs/文件夹中的新文档。

在提示说明中，你可以通过建议独立研究或并行分析来提示代理使用子代理，以完成特定子任务。

运行自定义代理作为子代理（实验性）

默认情况下，子代理继承主聊天会话中的代理，并使用相同的模型和工具。要为子代理定义特定行为，请使用自定义代理。自定义代理可以指定自己的模型、工具和说明。当用作子代理时，这些设置会覆盖从主会话继承的默认设置。

控制子代理调用

您可以通过使用两个 frontmatter 属性来控制自定义代理的调用方式：

  • 用户可调用: 控制是否在聊天的代理下拉菜单中显示代理（默认是真)。设置为假创建只能作为子代理访问的代理。
  • 禁用模型调用防止该代理被其他代理作为子代理调用（默认是）假)。设置为真当智能体仅应由用户明确触发。

例如，要创建只能作为子代理使用的代理（在下拉菜单中不可见）：

---
名称: 内部助手
用户可调用: 否
---

此代理只能作为子代理调用。
注意

该推断属性已弃用。使用用户可调用和禁用模型调用而是为了更精细的控制。

要将自定义代理作为子代理运行，请提示AI使用自定义或内置的代理来执行子代理。例如：

  • 将研究代理作为一个子代理来研究这个项目中最佳的认证方法。
  • 使用子代理中的计划代理为myfeature创建实施计划。然后将计划保存在plans/myfeature.plan.md中。

限制可以使用的子代理（实验性）

默认情况下，所有没有的自定义代理禁用模型调用：真可以作为子代理使用。如果两个或多个代理具有相似的名称或描述，AI 可能会选择意外的代理。

您可以通过指定来限制哪些自定义代理可以作为子代理使用Agent主代理的前导部分中的属性，并提供允许的自定义代理列表。

该Agent属性接受：

  • Agents的名字列表（例如，[‘编辑’, ‘搜索’]) 仅允许特定代理
  • 输入：*允许所有可用的代理（默认行为）
  • 一个空数组[]防止任何子代理使用
注意

明确列出Agents在Agent数组覆盖禁用模型调用：真这意味着您可以创建受保护的智能体，这些智能体不能被一般子智能体使用，但可以被明确允许的特定协调智能体访问。

例如，一个测试驱动开发（TDD）代理应该只使用红色，绿色，和重构将代理视为子代理。如果不加以限制，TDD代理可能会选择更通用的编码代理来实现测试，而不是专门的TDD代理。

---
名称: TDD
工具: ['代理']
Agent: ['红色', '绿色', '重构']
---
使用测试驱动开发实现以下功能。使用子代理引导以下步骤：
1. 使用红色代理编写失败的测试
2. 使用绿色代理实现通过测试的代码
3. 使用重构代理改进代码质量

编排模式

子代理实现编排模式，其中协调代理将工作委托给专门的工人代理。这种方法帮助你在保持每个代理专注于其最擅长的工作的同时，构建复杂的流程。

协调者和工作者模式

协调代理管理总体任务并将子任务委托给专业的小代理。每个工作代理可以拥有一套定制的工具。例如，计划和审查代理只需要只读访问权限，而实施者则需要编辑权限。

---
name: Feature Builder
tools: ['agent', 'edit', 'search', 'read']
agents: ['Planner', 'Plan Architect', 'Implementer', 'Reviewer']
---
You are a feature development coordinator. For each feature request:

1. 使用Planner代理将功能分解成任务。
2. 使用Plan Architect代理将计划与代码库模式进行验证。
3. 如果架构师识别出可重用的模式或库，请向Planner发送反馈以更新计划。
4. 使用Implementer代理为每个任务编写代码。
5. 使用Reviewer代理检查实现。
6. 如果 Reviewer 识别出问题，请再次使用 Implementer 代理应用修复。

在规划与架构之间，以及审查与实施之间迭代，直到每个阶段收敛。

工人代理各自定义其工具访问，并且可以选择更快或更具有成本效益的模型，因为他们专注于更窄的领域：

---
name: Planner
user-invokable: false
tools: ['read', 'search']
---
Break down feature requests into implementation tasks. Incorporate feedback from the Plan Architect.

---
name: Plan Architect
user-invokable: false
tools: ['read', 'search']
---
Validate plans against the codebase. Identify existing patterns, utilities, and libraries that should be reused. Flag any plan steps that duplicate existing functionality.

---
名称: 实现者
用户可调用: 否
模型: ['Claude Haiku 4.5 ( copilot )', 'Gemini 3 Flash ( 预览 ) ( copilot )']
---
编写代码以完成分配的任务。

该模式使协调器的上下文专注于高级工作流程，同时每个工作代理都有一个干净的上下文和其特定任务的适当权限。

多视角代码审查

代码审查可以从多个角度受益。一次扫描通常会错过在通过不同视角查看时显而易见的问题。使用子代理并行运行每个审查视角，然后综合结果。

---
name: Thorough Reviewer
tools: ['agent', 'read', 'search']
---
You review code through multiple perspectives simultaneously. Run each perspective as a parallel subagent so findings are independent and unbiased.

When asked to review code, run these subagents in parallel:
- Correctness reviewer: logic errors, edge cases, type issues.
- Code quality reviewer: readability, naming, duplication.
- Security reviewer: input validation, injection risks, data exposure.
- Architecture reviewer: codebase patterns, design consistency, structural alignment.

所有子代理完成后，将发现结果综合成一个优先级最高的总结。注意哪些问题是关键的，哪些是可有可无的。认可代码的优点。

这个模式之所以有效，是因为每个子代理都是从头开始处理代码，不受其他观点的限制。在这个例子中，指挥者通过其提示来塑造每个子代理的关注点。这是一种轻量级的方法，不需要额外的代理文件。

小贴士

为了获得更多的控制权，每个审查视角都可以是一个具有专用工具访问的自定义代理。例如，安全审查员可能会使用一个专注于安全的MCP服务器，而代码质量审查员可能会有访问代码检查CLI工具的权限。这种方法使每个视角能够使用最适合其特定关注点的工具。

相关资源