教程 搜索 / 原生 Mac IDE / 编写子代理
📝 文字 ● 中级 更新于 2026-05-13

如何为 LingCode 编写子代理?

TL;DR:.claude/agents/<your-agent>.md 中创建一个 Markdown 文件,添加 frontmatter(namedescription,可选 tools)以及下方的系统提示。主代理可通过 Agent 工具将任务委派给它——非常适合需要隔离上下文的场景。

子代理是主代理可以委派任务的专家——拥有独立的系统提示、独立的工具集和独立的上下文窗口。当任务边界清晰、工作假设与当前对话不同,或者你不希望其污染主上下文时,子代理是最佳选择。

与代理协作的默认方式是一段持续增长的对话。每一条提示、每一次工具调用结果、代理读取的每一个文件——全都积累在同一个上下文窗口中。对于短任务来说这没什么问题,但对于长任务来说却很糟糕,因为两种失败模式会同时出现。第一种是稀释:对话越长,模型需要平衡的指令越多,重要内容越容易漂移。第二种是泄漏:一个本应只读的调研任务,最终代理却开始建议代码修改——因为主上下文已处于"写"模式,而它还没到该写的时候。

子代理可以同时解决这两个问题。它是一个全新的代理实例,拥有独立的系统提示和工具集,由主代理像调用工具一样调用。子代理在隔离环境中完成任务,返回一个结构化结果后消失——它产生的两万个 token 的中间过程永远不会进入父对话。只有摘要会被返回。

使用子代理的艺术在于判断哪些任务值得用它。错误答案是"所有任务"——把琐碎的工作委派给子代理只会增加延迟和混乱。正确答案是"边界清晰且需要不同思维模式的任务":代码审查、测试生成、代码库探索——任何工作量大但结果紧凑的事情。

你将学到

第一步:文件格式

1

每个子代理对应一个 Markdown 文件

子代理文件存放在 .claude/agents/<name>.md(项目级)或 ~/.claude/agents/<name>.md(用户级)。每个文件是带有 YAML frontmatter 的 Markdown:

---
name: code-reviewer
description: Use this for in-depth code review of staged or unstaged changes. Invoke when the user says "review this," "look over this diff," or before they push.
tools: [Read, Grep, Glob, Bash]
---

# Code reviewer

You are a senior code reviewer. Read the staged diff with `git diff --staged`,
and the unstaged diff with `git diff`. For each meaningful change:

- Note what was changed and whether it accomplishes the stated goal.
- Flag bugs, race conditions, and security issues.
- Flag missing tests for non-trivial logic.
- Flag style violations only if egregious.

Do NOT propose fixes — that's the main agent's job. Report findings only.

frontmatter 包含三个有意义的字段:name(调用时使用)、description(用于路由决策),以及可选的 tools(限定工具白名单)。

第二步:描述引导委派

2

描述即路由逻辑

当主代理决定是否要委派时,它会读取所有可用子代理的描述,并选择描述与当前情境最匹配的那个。描述模糊("帮助处理代码")的会被忽略;描述具体("用于对已暂存或未暂存的变更进行代码审查")的会被选中。

描述应采用"在 [任务] 时使用"或"当用户 [说/想/需要] [某事] 时调用"的形式。想象未来的你冷读这段描述——你能知道什么时候该派发吗?

描述是给模型看的,不是给人看的。要具体说明触发条件,而非花哨地描述能力。"当用户要求写测试时使用"远比"擅长编写全面测试套件、深谙测试模式的专家"更有效。

第三步:限制工具

3

子代理应只做它该做的事

默认情况下,子代理可以使用主代理能用的任何工具。通过 frontmatter 中的 tools 字段将其限制为完成任务所需的最小工具集:

  • 代码审查子代理需要 ReadGrepGlob,以及用于 git 命令的 Bash——但不应拥有 EditWrite 或任何破坏性工具。它只审查,不修复。
  • 调研子代理需要读取类工具和 WebFetch。明确不应拥有 EditWrite
  • 测试编写子代理需要 ReadGrepEditWriteBash。完整的编辑工具集,但通过系统提示将其范围限定在测试文件内。

工具列表是策略,不是偏好。缺少 Edit 的子代理就真的无法编辑,无论模型"想"做什么。这正是代码审查子代理所需要的:即便模型想"顺手修一下这个小问题",它也做不到。

第四步:调用方式——隐式与显式

4

主代理委派的两种方式

子代理有两种调用方式:

  • 隐式:主代理判断当前情境,发现匹配的子代理描述,无需指示便自行委派。这是描述清晰的子代理最常见的触发方式。你会看到它以名为"Agent"的工具调用形式出现,参数中包含子代理的名称。
  • 显式:你说"用 code-reviewer 子代理审查这个 diff"。主代理按指示派发。当你知道该用哪个子代理且不想把路由交给模型自行判断时,这种方式很有用。

无论哪种方式,子代理都会获得全新的上下文窗口,完成任务,返回摘要,然后消失。主对话继续,只有摘要进入其上下文。

第五步:不该用子代理的情况

5

三个警示信号

  • 任务是对话性的。来回互动的对话不适合子代理——它们只返回一次摘要,而不是持续聊天。如果需要迭代,让主代理处理。
  • 结果就是全部过程产物。子代理只返回摘要;详细的中间工作会丢失。如果你需要看代理实际的 diff 探索过程,子代理会把它藏起来。改在主上下文中运行。
  • 任务只需一行操作。"格式化这个文件"不需要子代理。启动子代理的开销比任务本身还大。子代理应留给真正需要独立上下文窗口的工作。

第六步:子代理 vs. 技能 vs. 斜线命令

6

三种定制工具,三种不同用途

  • 技能(Skill)——教代理如何做某件事。主代理读取技能并在当前上下文中应用。没有隔离。
  • 子代理(Subagent)——将任务委派给拥有独立上下文的全新代理。有隔离。只返回摘要。
  • 斜线命令(Slash command)——用户手动输入的快捷方式,触发已知的提示模板。提供便利,但没有隔离。

经验法则:想要隔离,写子代理。想要在同一上下文中改变行为,写技能。想要快速触发,写斜线命令。

子代理只能以摘要形式看到主对话内容。主代理派发时,会传递一份简报——"审查已暂存的 diff 并报告发现"。子代理看不到完整的聊天历史。编写子代理的提示时,要假设它从冷上下文开始工作。

下一步