扩展 Claude Code:hooks(确定性)vs CLAUDE.md(建议性)、skills、subagents、plugins、接 MCP server、CLI 工具优先
CLAUDE.md 只是建议,hooks 才是门禁。学会用 hooks 把「每次都要做」的事变成确定的,用 skill 装可复用流程,用 subagent 把查资料的活派出去,再接上 MCP 与 CLI 工具。
今日目标
- 能说清 hooks 为什么比 CLAUDE.md 里的规则可靠,并写出一条阻止危险操作的 hook
- 能写一个 SKILL.md,并说清 skill、CLAUDE.md、subagent 三者各装什么
- 能给 Claude Code 接上一个 MCP server,并说出 CLI 工具优先的理由
昨天你给搭档写了入职手册。今天要回答手册解决不了的问题:哪些规矩必须一定被执行、哪些流程值得做成说明书、哪些活该派给别人。读完做完实验,回到顶部勾掉三条目标。
小白版讲解
建议与门禁:CLAUDE.md 说「请这样做」,hooks 保证「一定这样做」
入职手册上写着「进机房要刷卡」。大多数同事会照做,但总有人赶时间从后门溜进去。真正保证「一定刷卡」的不是手册,是门禁——不刷卡门就不开,跟人自觉不自觉没关系。
CLAUDE.md 是手册,hooks 是门禁。这不是修辞,而是两者在系统里的位置决定的:CLAUDE.md 的内容是作为一段文字送进模型的上下文,模型读了之后决定怎么做——它是建议性的(advisory),遵守率很高但不是百分之百,文件越长遵守率越低,这是昨天讲过的。钩子(hook)则是 Claude Code 这个程序在特定时刻无条件执行的脚本:工具调用之前、之后,一轮结束之前,会话开始时——脚本跑不跑、拦不拦,由退出码决定,模型说什么都不影响。它是确定性的(deterministic)。
所以判据只有一句:「每次都必须发生、一次例外都不能有」的事,做成 hook;「通常应该这样」的事,写进 CLAUDE.md。 官方 best practices 页把这条列成了独立的一节,还给了一个反向的建议:如果 CLAUDE.md 里某条规则 Claude 已经默认会遵守,删掉它;如果某条规则必须百分之百遵守,把它换成 hook。两头一削,CLAUDE.md 就短了。
典型的「必须发生」清单:改完文件自动跑格式化;碰 migrations/ 目录一律拦下;测试不过不许结束这一轮;每条命令记进审计日志。典型的「通常应该」清单:优先用具名导出;提交信息用中文;需求有歧义先问。前者交给门禁,后者留在手册。
写第一条 hook:事件、匹配器、脚本、退出码
一条 hook 由四件事组成:在哪个时刻触发(事件)、对哪些工具触发(匹配器)、跑什么(命令)、结果怎么表达(退出码或 JSON)。配置写在项目的 .claude/settings.json(跟 git 走、全组共享)或 ~/.claude/settings.json(只对你)里,用 /hooks 可以浏览当前生效的配置。
常用的事件有这几个:PreToolUse(工具调用前,能拦)、PostToolUse(调用后,能跟着做点事)、Stop(模型准备结束这一轮时,能不让它结束)、UserPromptSubmit(你提交提示词时)、SessionStart(会话开始)。示例任务里我们要拦住对迁移目录的写入,用 PreToolUse;匹配器写工具名,Edit|Write 匹配两个编辑工具:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "node ${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-migrations.mjs"
}
]
}
],
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/require-green.sh",
"timeout": 120
}
]
}
]
}
}脚本从标准输入读到一个 JSON:里面有 hook_event_name、tool_name、tool_input(对 Edit 来说就是 file_path 等字段)、cwd、session_id。它用退出码表达决定:0 是放行(如果 stdout 打了一个 JSON,Claude Code 会解析里面的结构化决定);2 是阻止,stderr 的内容会作为「为什么被拦」送回给模型,让它换个做法;其他非零码是「脚本自己出错了,但不阻止」。守门脚本用两种语言写出来是这样:
// PreToolUse hook:拦住对 migrations/ 的任何写入。
// 从 stdin 读 JSON,退出码 2 = 阻止,stderr 会作为理由送回给模型。
import { readFileSync } from 'node:fs'
const input = JSON.parse(readFileSync(0, 'utf8')) // 0 = stdin
const filePath = input.tool_input?.file_path ?? ''
if (/(^|\/)migrations\//.test(filePath)) {
process.stderr.write(
`拒绝:${filePath} 在 migrations/ 下。迁移文件只能由 pnpm db:generate 生成,不能手改。`
)
process.exit(2) // 2 = 阻止这次工具调用
}
process.exit(0) // 0 = 放行,走正常权限流程# PreToolUse hook:拦住对 migrations/ 的任何写入。
# 从 stdin 读 JSON,退出码 2 = 阻止,stderr 会作为理由送回给模型。
import json
import re
import sys
payload = json.load(sys.stdin)
file_path = payload.get("tool_input", {}).get("file_path", "")
if re.search(r"(^|/)migrations/", file_path):
print(
f"拒绝:{file_path} 在 migrations/ 下。迁移文件只能由 pnpm db:generate 生成,不能手改。",
file=sys.stderr,
)
sys.exit(2) # 2 = 阻止这次工具调用
sys.exit(0) # 0 = 放行,走正常权限流程Stop 那条 hook 的脚本更短:跑一遍测试,失败就 exit 2 并把失败摘要写到 stderr——模型会收到「测试没过,不能结束」,继续修,直到通过。这就是昨天说的「把检查做硬」的第三档。有一个安全阀要知道:连续 8 次被 Stop hook 拦下后,Claude Code 会放行结束这一轮,避免死循环。
skills:把重复流程装成可按需加载的说明书
有些活你每周都要交代搭档一遍:「修一个 issue 的流程是先看 issue、再搜代码、写测试、改、跑 lint、提 PR」。写进 CLAUDE.md?可以,但它每次会话都加载,而你一周只修两次 issue——其余时间这几十行都在白占窗口。更好的做法是把它写成一本说明书放在抽屉里,需要时才拿出来。
这就是技能(skill):.claude/skills/<name>/SKILL.md,一份带 frontmatter 的 Markdown。它的关键性质是渐进式加载——会话开始时只有 frontmatter 里那一行 description 常驻上下文,Claude 判断当前任务相关(或你输入 /name)时才把正文读进来。所以 skill 的正文可以很长、可以带步骤和示例,几乎不影响日常成本。示例任务的 skill:
---
name: add-validation
description: 给一个 Express 路由补 zod 输入校验并写对应的 vitest 用例。用户提到「加校验」「补测试」「校验请求体」时使用。
argument-hint: [路由路径,如 POST /todos]
---
给 $ARGUMENTS 补输入校验与测试,按下面顺序做,每步完成再进下一步:
1. 读路由文件与现有测试,列出请求体里每个字段现在的处理方式
2. 先写失败的测试:空值、超长、类型错误、多余字段各一个
3. 用 zod 定义 schema(一律 .strict()),校验失败返回 400 与 { error, issues }
4. 只跑这一个测试文件:pnpm vitest run test/<文件>
5. 全绿后把测试输出贴在回复里,再停下等确认description 是触发器,写法有讲究:说清「做什么」和「用户会怎么说」,控制在一百来字,太泛会被误触发,太窄永远触发不到。$ARGUMENTS 接住你在 /add-validation POST /todos 后面传的参数。两个可选字段值得记:disable-model-invocation: true 表示只允许你手动 /name 触发,适合部署、发消息这类有副作用的流程;allowed-tools 可以给这个 skill 预授权几条命令。
现在三样东西的分工清楚了:CLAUDE.md 装每次都成立的短事实,skill 装偶尔才用的多步流程,而下一节的 subagent 装的是「需要独立上下文的活」。判断一段内容该去哪,问两个问题:它每次会话都用得上吗?它是一句规则还是一套步骤?
subagents:派出去查资料的同事,回来只带结论
你让搭档「查一下我们的鉴权是怎么处理 token 刷新的」。他去翻了三十个文件——如果这三十个文件全都摊在你们共用的那张桌子上,桌子就满了,接下来真正要做的实现反而没地方放。更好的办法是让他去隔壁办公室翻,翻完只回来告诉你一句结论。
子代理(subagent)就是那间隔壁办公室:一个拥有自己独立上下文窗口的 Claude,接到一个任务,读它需要读的一切,最后只把一段总结带回主会话。D2、D3 反复强调上下文是最稀缺的资源,subagent 是最直接的保护手段——把「读很多、留很少」的活隔离出去。Claude Code 内置了几个:Explore 只读、专门用来找文件和理解代码;Plan 在计划模式下做调研;general-purpose 什么都能干。你也可以在 .claude/agents/<name>.md 里定义自己的:
---
name: security-reviewer
description: 审查代码的安全问题:注入、鉴权缺陷、密钥泄露。用户要求安全审查时使用。
tools: Read, Grep, Glob, Bash
model: sonnet
---
你是一名资深安全工程师。只审查、不修改。对每个问题给出文件与行号、风险说明、修复建议。tools 限定它能用什么(一个审查者不该有 Edit),model 可以给它配更便宜或更强的模型。用法很直接:「用 subagent 调查一下鉴权模块的 token 刷新逻辑」或「用 security-reviewer 审一下这次的 diff」。它看不到你主会话的历史,只看到你派它去做的那句任务和 CLAUDE.md——这既是限制也是优点:一个没有被「刚写完这段代码」的记忆污染的审查者,更容易挑出毛病。D5 的对抗式审查就建在这个性质上。
什么时候不该用?需要来回多轮讨论的活、几个阶段要共享大量上下文的活、一句话就能改完的活。派出去的成本是一次完整的任务交代加一次总结,太小的活不划算。
plugins 与 MCP:别人做好的能力怎么接进来
到这里你会的都是「自己写」:写手册、写门禁、写说明书、写子代理。但很多能力别人已经做好了,接进来比自己写快。两条路。
**插件(plugin)**是打包好的一组 skill、hook、subagent 和 MCP 配置,一条命令装上。用 /plugin 打开市场浏览,比如用强类型语言的项目可以装一个代码智能插件,让 Claude 拿到精确的符号跳转和改动后的自动报错。
MCP(Model Context Protocol)server 则是把外部系统变成 Claude 可以调用的工具:issue 跟踪器、数据库、监控平台、设计工具。接一个 server 只要:
# 远程 server(HTTP)
claude mcp add --transport http notion https://mcp.notion.com/mcp
# 本地 server(stdio,一个可执行命令)
claude mcp add my-db -- npx -y @some/postgres-mcp postgres://localhost:5432/app接上之后 Claude 就多了一组工具,能「从 issue #123 读需求然后实现」、能「查一下这张表最近的慢查询」。MCP 本身是一门七天的课(mcp-7days,即将上线),今天只要会接、会用。
一个提醒:每接一个 MCP server,它的全部工具定义都会进入上下文——接十个 server 可能就是几万 token 的固定开销。接你真会用的,用完的可以卸。
CLI 工具优先:为什么 gh 比调 GitHub API 更省上下文
最后一条看起来最土,却是官方 best practices 里单独成节的建议:能用命令行工具的,别让 Claude 直接调 API。
原因还是上下文。让 Claude 通过 GitHub 的 REST API 创建一个 issue,它要构造请求、处理鉴权、解析一大坨 JSON 响应——每一步的输入输出都进窗口。换成 gh issue create --title ... --body ...,一行命令、一行输出,而且 gh 已经处理好了登录和分页。aws、gcloud、sentry-cli、docker、kubectl 都是同理:CLI 是人类花了多年打磨出来的、信息密度最高的接口,Claude 对它们也最熟。
它甚至能自学它不认识的 CLI:「先用 foo --help 了解 foo 工具,然后用它完成 A、B、C」——一条 --help 的输出通常就够它学会。所以在「自己写 MCP server」之前,先问一句:这个系统有没有现成的 CLI?有,装上就行。
把今天六节合起来看,扩展 Claude Code 的手段按「确定性」排一条线:hook 最硬(一定执行),CLI 与 MCP 是能力(有就能用),skill 是按需的流程,subagent 是隔离的上下文,CLAUDE.md 最软(建议)。给搭档配装备的顺序也是这个:先把必须的门禁装好,再谈怎么让它更能干。
源码导读
动手实验
实验的 starter 与 solution 目录本身就是一个几十行的演示项目(Express + zod + vitest),.claude/ 下放 hooks 与 skill。starter/ 的 hook 脚本和 SKILL.md 挖了空,solution/ 是完整版;两边都带一个事件模拟器——它不需要 Claude Code,直接把假的事件 JSON 喂给 hook 脚本、打印退出码,让你在写脚本时能快速迭代。前三步不需要 Claude Code,后两步需要。
- 在 starter 目录 pnpm install 后跑 pnpm start,看到模拟器把三个事件都跑成了「放行」——因为 hook 还是空的,这就是你要补的地方。
- 完成练习 1:在 guard-migrations.mjs 里读 stdin 的 JSON,路径命中 migrations/ 时向 stderr 写理由并 exit 2;重跑模拟器确认第一个事件变成「阻止」。
- 完成练习 2:在 require-green.sh 里跑演示项目的单文件测试,失败则把最后几行输出写到 stderr 并 exit 2;故意改坏一个断言重跑模拟器看效果,再改回来。
- 完成练习 3:补全 SKILL.md 的 description 与五步流程,确保 description 写了「用户会怎么说」。
- 用真实的 Claude Code 打开 solution 目录,先 /hooks 看配置,再让它「把 migrations/0001_init.sql 里的表名改一下」观察被拦;最后 /add-validation POST /todos 走完整个流程。
面试题
今天 3 道题在下方题库区,侧重 hooks 与 CLAUDE.md 的可靠性差异、skill 的渐进式加载、subagent 的上下文隔离。展开后先看「分析过程」再看要点——照着推导练,比背要点管用。标注「国内高频 / 海外高频」方便按目标市场取舍。
检查清单与明日预告
- 能说清 hooks 为什么比 CLAUDE.md 里的规则可靠,并写出一条阻止危险操作的 hook
- 能写一个 SKILL.md,并说清 skill、CLAUDE.md、subagent 三者各装什么
- 能给 Claude Code 接上一个 MCP server,并说出 CLI 工具优先的理由
- 能背出 hook 三种退出码的含义,以及 Stop hook 的 8 次安全阀
- 实验的 5 条验收标准全部通过
- 3 道面试题不看要点也能答出至少 2 道
明天(D5)是最后一天,我们把 Claude Code 从终端里的搭档变成流水线里的一环:用 claude -p 无头模式跑进 CI、解析 JSON 结果判断成败、用 worktree 并行开会话、用 Writer / Reviewer 双会话做对抗式审查,最后用 Agent SDK 写一个 20 行的最小 agent。今天装好的门禁在无人值守的场景里才真正发挥价值——没有人盯着的时候,hook 是唯一还在工作的规则。
面试题库
为什么 hooks 比 CLAUDE.md 里的规则更可靠?各适合放什么?举一个你会从 CLAUDE.md 挪到 hook 的例子。Why are hooks more reliable than rules in CLAUDE.md? What belongs in each? Give one rule you would move from CLAUDE.md to a hook.
国内高频海外高频基础#hooks#claude-md分析过程 · 先想清楚再作答
- 这题考的是「建议 vs 确定性」的系统位置,不是背功能名。答「hooks 是自动执行的脚本」只是描述,要说清为什么模型的遵守率不等于程序的执行率。
- 拆法:CLAUDE.md 的内容作为文字进入模型上下文,由模型读后决定怎么做——遵守率高但不是百分之百,文件越长越低,压缩后还可能丢失。hook 是 Claude Code 程序在固定生命周期点(PreToolUse / PostToolUse / Stop 等)无条件运行的脚本,由退出码决定拦不拦,与模型的判断无关。
- 判据一句话:一次例外都不能有的动作做成 hook;通常应该这样的偏好写进 CLAUDE.md。反向操作也成立:CLAUDE.md 里模型已经默认遵守的删掉,必须百分之百的换成 hook,文件就短了。
- 例子要具体:「提交前跑 lint 与测试」——作为文字它偶尔会被跳过;做成 Stop hook,测试不过 exit 2,模型收到失败摘要继续修,直到通过;「不许改 migrations/」做成 PreToolUse hook 匹配 Edit|Write,路径命中就 exit 2。
- 可预期的追问:hook 有没有风险?有——它是代码,跑在你机器上,clone 陌生仓库时别人的 hook 会执行,无头模式没有信任对话框;Stop hook 连续 8 次阻止后会被放行防死循环。
How to reason about it · think before answering
- This tests the systemic position of advisory versus deterministic, not feature recall. 'Hooks are scripts that run automatically' is a description; explain why model adherence is not program execution.
- Breakdown: CLAUDE.md enters the model's context as text and the model decides after reading — adherence is high but not total, drops as the file grows, and can be lost after compaction. A hook is a script Claude Code itself runs unconditionally at fixed lifecycle points (PreToolUse, PostToolUse, Stop), with the exit code deciding whether to block, independent of the model's judgment.
- One-line rule: actions that allow zero exceptions become hooks; preferences that usually apply stay in CLAUDE.md. The inverse also holds — delete rules the model follows by default, convert must-always rules into hooks, and the file shrinks.
- Make the example concrete: 'run lint and tests before committing' is occasionally skipped as text; as a Stop hook, failing tests exit 2 and the model receives the summary and keeps fixing. 'Never edit migrations/' becomes a PreToolUse hook matching Edit|Write that exits 2 on a path hit.
- Follow-ups: risks? Hooks are code running on your machine — a cloned repo's hooks execute, and headless mode shows no trust dialog; a Stop hook is overridden after 8 consecutive blocks to prevent loops.
答题要点
- CLAUDE.md 是送进上下文的文字,由模型读后决定,遵守率高但不是百分之百
- hook 是程序在固定生命周期点无条件跑的脚本,退出码决定拦不拦,与模型判断无关
- 一次例外都不能有的做 hook;通常应该这样的写 CLAUDE.md
- 例:提交前测试改成 Stop hook;禁改 migrations 改成 PreToolUse hook
Key points
- CLAUDE.md is text the model reads and then decides on — high but not total adherence
- A hook is a script the program runs unconditionally at lifecycle points; the exit code decides, not the model
- Zero-exception actions become hooks; usual preferences stay in CLAUDE.md
- Examples: pre-commit tests as a Stop hook; a migrations deny as a PreToolUse hook
skill 的渐进式加载是怎么回事?为什么能省上下文?description 应该怎么写?What is progressive loading for skills, why does it save context, and how should the description be written?
国内高频海外高频进阶#skills#context分析过程 · 先想清楚再作答
- 这题考的是「按需加载」这个设计思想,以及你有没有真写过 skill。第三问是区分度:description 写不好,skill 就形同虚设。
- 机制:会话开始时只有每个 skill 的 frontmatter 里那一行 description 常驻上下文;当模型判断当前任务相关、或用户输入 /name 时,正文才被读进来。所以正文长短几乎不影响日常成本,可以放几十步的流程、示例、注意事项。
- 对比 CLAUDE.md:它整份每次加载,是固定成本;一周只用两次的流程放进去等于其余时间白占窗口。把这类内容挪到 skill,是「删到不能再删」之后 CLAUDE.md 还能继续变短的主要手段。
- description 的写法:说清做什么 + 用户会怎么说(触发词),一百来字;太泛会被无关任务误触发,太窄永远触发不到。有副作用的流程(部署、发消息)加 disable-model-invocation: true 只允许手动 /name 触发。$ARGUMENTS 接参数,allowed-tools 预授权命令。
- 可预期的追问:怎么测 skill 有没有被触发?用几个自然语言说法试,看模型是否读了正文;再追问「skill 与 subagent 的区别」——skill 是在当前上下文里加载一份说明书,subagent 是另起一个上下文去做事,两者可以组合。
How to reason about it · think before answering
- This tests the on-demand loading idea and whether you have actually written a skill. The third part separates candidates: a poorly written description makes the skill dead weight.
- Mechanism: at session start only each skill's one-line description from the frontmatter is resident; the body loads when the model judges the task relevant or the user types /name. Body length therefore barely affects daily cost, so it can hold long procedures, examples, and caveats.
- Contrast with CLAUDE.md: loaded in full every session, a fixed cost; a procedure used twice a week wastes the window the rest of the time. Moving such content into skills is how CLAUDE.md keeps shrinking after pruning.
- Writing the description: state what it does plus the phrases a user would say, about a hundred words; too broad triggers on unrelated tasks, too narrow never triggers. Add disable-model-invocation: true for side-effecting workflows so only /name invokes them; $ARGUMENTS takes parameters; allowed-tools pre-approves commands.
- Follow-ups: how do you test triggering? Try several natural phrasings and check whether the body loaded. Skill versus subagent: a skill loads a manual into the current context; a subagent opens a separate context to do work; they compose.
答题要点
- 只有 description 常驻,正文在被触发时才加载;正文长短几乎不影响日常成本
- CLAUDE.md 整份每次加载;偶尔用的流程挪进 skill 是让它继续变短的手段
- description 写「做什么 + 用户会怎么说」,一百来字,不泛不窄
- 副作用流程加 disable-model-invocation;$ARGUMENTS 接参数
Key points
- Only the description is resident; the body loads on invocation, so body length barely costs
- CLAUDE.md loads in full each time; moving occasional procedures to skills keeps it short
- Write the description as what it does plus how users phrase it, about a hundred words
- Side-effecting workflows get disable-model-invocation; $ARGUMENTS carries parameters
subagent 解决了什么问题?它看得到主会话的历史吗?什么时候不该用?What problem do subagents solve? Do they see the main conversation's history? When should you not use one?
国内高频海外高频进阶#subagents#context分析过程 · 先想清楚再作答
- 题眼是「解决了什么问题」——答案是保护主会话的上下文窗口,而不是「并行」或「专业化」这些附带好处。第二问是常见误区,第三问考边界感。
- 推导:查资料、审代码这类任务的特征是「读很多、留很少」——读三十个文件只为一段结论。放在主会话里做,三十个文件全进窗口,真正的实现反而没地方放。subagent 拥有独立的上下文窗口,读完只把总结带回来,主会话只付总结的成本。
- 第二问:看不到。subagent 起步时只有系统提示、你派给它的任务描述、CLAUDE.md、git 状态快照;主会话的历史、你之前读过的文件、之前加载的 skill 都不在。这是限制也是优点:一个没有「刚写完这段代码」记忆的审查者更容易挑出毛病,D5 的对抗式审查就靠这个性质。
- 配置:.claude/agents/<name>.md,frontmatter 的 tools 限定它能用什么(审查者不给 Edit)、model 可以配更便宜或更强的模型;内置的 Explore 只读、Plan 用于计划模式、general-purpose 全能。
- 不该用的场景:需要多轮来回讨论的活(每次派出去都要重新交代)、几个阶段要共享大量上下文的活、一句话就能改完的活(交代 + 总结的开销大于任务本身)。可预期的追问:subagent 与 /compact 的关系——一个是不让东西进窗口,一个是进了以后压缩,前者更省。
How to reason about it · think before answering
- The key is the problem solved: protecting the main conversation's context window, not the side benefits of parallelism or specialization. The second part is a common misconception; the third tests judgment.
- Chain: research and review tasks read a lot and keep little — thirty files for one conclusion. Done in the main session, all thirty land in the window and crowd out the actual implementation. A subagent has its own context window, reads everything, and returns only a summary; the main session pays only for the summary.
- Second part: no. A subagent starts with the system prompt, the task you delegated, CLAUDE.md, and a git status snapshot — not the main history, your earlier file reads, or previously loaded skills. That is both a limit and a strength: a reviewer without the memory of having just written the code finds more faults, which is what adversarial review in D5 relies on.
- Configuration: .claude/agents/<name>.md with tools restricting what it may use (no Edit for a reviewer) and model to pick a cheaper or stronger model; built-ins are Explore (read-only), Plan (plan mode research), and general-purpose.
- When not to: tasks needing multi-turn back-and-forth (every dispatch re-explains), phases that share heavy context, and one-line fixes where dispatch plus summary costs more than the work. Follow-up: subagent versus /compact — one keeps content out of the window, the other compresses it afterward; the former is cheaper.
答题要点
- 解决的是主会话上下文被「读很多留很少」的任务撑满;subagent 独立窗口,只带回总结
- 看不到主会话历史,只有任务描述、CLAUDE.md、git 快照;因此审查更客观
- tools 限定权限、model 选模型;内置 Explore / Plan / general-purpose
- 不该用:多轮讨论、多阶段共享上下文、一句话能改完的小活
Key points
- Solves the main window being flooded by read-heavy, keep-little tasks; a subagent has its own window and returns a summary
- It does not see the main history — only the task, CLAUDE.md, and a git snapshot — which makes its review more objective
- tools restricts permissions, model picks the model; built-ins are Explore, Plan, general-purpose
- Avoid for multi-turn discussion, heavy shared context across phases, and one-line fixes
评论
登录后即可参与讨论
还没有评论,来说第一句。