Skills、Hooks 与子智能体：在 Claude Code 中组装你的第一个 Agent Loop

核验日期：2026-07-24

内容来源：BrainGrid Blog。本文来自 Claude Code 中文译文归档，先作为 Claude Code 专区后台草稿入库；发布前需由内容人员复核原文链接、图片、版本时效、是否包含厂商宣传，以及是否需要补充本站实践说明。来源：https://www.braingrid.ai/blog/skills-hooks-subagents-first-agent-loop
原题：Skills, Hooks, and Subagents: Assembling Your First Agent Loop in Claude Code
原发布时间：2026-07-16

了解 Claude Code Hooks、Skills 与子智能体分别能做什么、如何将它们组装成 Agent Loop，以及三者都无法为循环提供的一样东西：完成定义。

作者：BrainGrid Team
发布于：2026-07-16
修改于：2026-07-16
阅读时间：12 分钟
来源：https://www.braingrid.ai/blog/skills-hooks-subagents-first-agent-loop
来源 Markdown：https://www.braingrid.ai/blog/skills-hooks-subagents-first-agent-loop.md

准确性说明（核对于 2026-07-22）：文章将 Hooks 描述为保证，这种说法最直接适用于 Command 与 HTTP Hooks；基于 Prompt 和 Agent 的 Hooks 会使用模型判断，而且 Hooks 可能失败或超时。默认情况下，如果 Stop Hook 连续阻止八次且没有进展，阻止行为会被覆盖。Skill 名称与描述在调用前会消耗少量上下文；除非配置工作树隔离，否则子智能体会共享工作检出目录。文章声称循环无法生成计划或验收标准，这是一种推广性的夸大：模型可以起草这些内容，但为了避免自己评价自己，仍然需要外部标准或经过用户验证的标准。请参阅 Hooks、Skills与子智能体参考资料。

来源立场说明：文章后半部分明确把 BrainGrid 宣传为规划与验收标准缺口的解决方案。相关定位与行动号召均按原文保留。

Skills、Hooks 与子智能体：在 Claude Code 中组装你的第一个 Agent Loop

Claude Code 中最强大的功能，恰恰是大多数人从未启用的三项功能。Hooks、Skills 和子智能体已经在文档中存在数月；把它们连接起来的构建者，正在运行能够交付真实工作的 Agent Loops，而我们其他人仍在逐条输入提示词。

这种差距正是“循环工程”（Loop Engineering）的故事。今年夏天，这个词主导了 AI 构建领域的讨论；此前，Anthropic Claude Code 负责人 Boris Cherny 告诉听众，他已经不再亲自提示 Claude：“我运行着一些循环，它们会提示 Claude，并判断应该做什么。”这个观点之所以引起共鸣，是因为它符合事实。要让编程智能体发挥更多价值，关键不是更好的提示词，而是更好的循环。如果你使用 Claude Code，构建这套循环的原材料，恰好就是这三种基础机制。本文的假设很简单：Hooks、Skills 与子智能体，是组装可靠 Agent Loop 的零部件；了解各自用途，是摆脱全程看管智能体的最快方法。但三者都只控制循环如何运行，没有任何一项能够定义怎样才算完成；而这恰恰是循环无法自行生成的唯一输入。

Hooks：无论智能体是否记得，都会触发的规则

先从 Hooks 开始，因为它们最容易被忽视，也最容易遭到误解。

Hook 是 Claude Code 在生命周期的特定节点自动运行的 Shell 命令、HTTP 端点或提示词：编辑文件前、任务完成后、执行 Shell 命令之前。只需配置一次，每次到达相应节点都会触发，无论智能体正在“思考”什么。最后一点正是关键。如果你在指令中写“每次编辑后运行格式化工具”，智能体大多数时候会执行，偶尔也会忘记，因为指令只是模型结合上下文中其他内容权衡的一项建议。Hook 不是建议，而是保证。

社区很快理解了这一点。相关主题中传播最广的解读之一，将 Hooks 称为“AI 智能体的权限系统”，这种定位非常准确。选择 Hook 而不是在 CLAUDE.md 中添加一行的原因，就在于确定性。你希望 Linter 每次都运行，密钥扫描器每次都能阻止提交，测试套件每次都在智能体宣布胜利前执行。模型行为具有概率性，Hook 则不然。

来看一个具体区别。如果只用文字告诉智能体“结束前始终运行 pnpm test”，那么在漫长、混乱的任务中，它有时会跳过这一步，宣布功能完成，再把损坏的构建交给你。如果接入一个运行测试并在失败时阻止完成的 Stop Hook，它就无法跳过，因为此时跳过与否已不再由模型决定。智能体相同，模型相同，唯一变量是这项检查究竟是一项请求，还是一条规则。

Skills：只在需要时加载的专业知识

Skills 解决的是相反问题。Hooks 是始终启用的保证，Skills 是按需加载的知识。

Skill 是一个包含 Markdown 文件的文件夹，用来教智能体如何完成一项具体工作：团队如何编写迁移、如何生成 PDF 发票、如何依据设计系统审查组件。它会保持休眠，直到智能体遇到 Skill 所描述的情境，只有这时才载入上下文。这正是我们在上下文腐化一文中讨论的失败模式之解法：提前塞进智能体上下文的内容越多，它处理眼前任务时的表现就越差。Skills 让你可以随时提供深度专业知识，却不必在每一轮都为其付出成本。工作需要时知识就在场，不需要时则不会碍事。

这种机制确实存在取舍，而且值得明确说出来。只有智能体识别出相应时机，Skill 才会触发；因此，描述含糊的 Skill 会一直闲置，智能体则在旁边胡乱发挥。Skill 的质量取决于它的触发条件。编写描述时，应当像告诉一名新员工究竟何时查阅这份操作手册一样精确，否则它只能积灰。

子智能体：用全新上下文保持主线程干净

第三种基础机制可以让循环扩展到更大规模。

子智能体是智能体的独立实例，拥有自己的上下文窗口，由主会话启动以处理一项委派工作。主会话把任务交给它，子智能体在自己的窗口内完成探索、文件读取和所有走弯路的推理，只有结果会返回。中间的混乱过程完全不会进入主线程。这一点很重要，因为单个长时间运行的智能体会话，会随着上下文被过去所有尝试的残留填满而逐渐退化。子智能体让你可以执行大型工作，又不会让第三步的探索污染智能体在第七步中的判断。

在实践中，正是这一点让循环能够处理真正有规模的工作。“审查者”子智能体检查“构建者”子智能体生成的成果，二者各自拥有干净窗口，就像真实团队会把制作与检查分开。主循环负责编排；子智能体执行隔离工作并汇报。这种分离解释了为什么构建者会把子智能体称为一项关键功能：它让 Claude Code 配置从一名聪明助手，变成一套能在多步骤任务中真正保持完整的系统。

组装循环

把三者组合起来，循环就不再是一种比喻，而会变成一台可以指向某个目标的机器。

flowchart LR
    A[来自工作队列的<br/>任务] --> B[Skill 加载<br/>正确操作手册]
    B --> C[子智能体在干净<br/>上下文中构建]
    C --> D[Hook 触发：<br/>测试 + Lint]
    D -->|失败| C
    D -->|通过| E[审查子智能体<br/>检查结果]
    E --> F[结果返回<br/>主循环]
    F --> A

Skills 在需要的时刻提供操作知识。子智能体在隔离环境中完成工作，不会堵塞主线程。Hooks 则触发模型无权跳过的硬性检查。再用一个循环包住这套机制，让它取出下一项任务并不断重复，你就得到了 Cherny 描述的系统：由系统替你提示智能体。这就是今天的实际构建者能够实现的循环工程，而不是研究演示。

这确实是一项提升。定时、自检式智能体任务已经成为现实，也已经存在于当前 Claude Code 中；把这些基础机制组装起来，比再投入任何时间调优提示词都能让你走得更远。如果你使用 Claude Code，实际含义很直接：接下来一小时，与其继续润色另一条提示词，不如接入一个 Hook 和一个子智能体，因为提示词只带来一次性收益，循环则会复利增长。

重新理解：循环负责运行工作，却无法决定怎样才算“完成”

这是关于循环的社交媒体帖子往往略过、却最重要的部分。

这三种基础机制全都在控制循环如何运行。Hook 决定检查在何时触发，Skill 决定任务如何执行，子智能体决定工作在哪里发生。它们都不会决定你正在构建什么，也不会决定你如何判断结果正确。Stop Hook 可以在每轮都运行测试套件，但必须有人编写测试，也必须有人判断“测试通过”确实意味着功能符合你的意图。这个“某人”不是 Hook、Skill 或子智能体，而是一份带有验收标准的计划；循环无法自行生成它。

最近一个 Reddit 讨论中的氛围编程者，在不了解任何这些术语的情况下，从头重建了这套理念，而且比大多数文档表达得更好：“你必须为应用定义‘完成’，规划到达那里所需的全部工作……需求、验收测试、代码。如果想要确定性结果，就需要确定性验证。” 这就是整个游戏。只有存在一项固定标准，让循环每次都能据此检查，循环才能在规模扩大后仍保持完整。缺少标准时，审查子智能体没有审查依据，Stop Hook 只能检查代码能否运行，而不是代码是否正确；循环的每一轮都可能悄悄偏离你的真实目标。循环运行得很漂亮，却交付了错误的东西。

这正是 BrainGrid 试图填补的缺口。BrainGrid 是一个计划优先的应用构建平台，运行同样的“计划 → 构建 → 验证 → 重复”循环，但它负责 Claude Code 基础机制无法生成的两个部分：计划与标准。你描述功能，Planning Agent 会将其转化为一项带有明确验收标准的需求，也就是循环检查所衡量的完成定义。随后，Builder Agent 会在 BrainGrid Cloud 沙箱中构建，也可以通过 MCP 使用 Claude Code、Cursor 或 Codex，在你自己的 GitHub 仓库中完成构建；这样，你的 Hooks 与子智能体继续发挥各自所长，循环也终于拥有了目标。验证阶段会根据每条标准检查构建结果；只有证据表明成果符合意图，功能才算完成。基础机制让循环运行，计划则让循环值得运行。

常见问题

什么是 Claude Code Hooks？

Claude Code Hooks 是在智能体生命周期的特定节点自动运行的 Shell 命令、HTTP 端点或提示词，例如编辑文件前、运行 Shell 命令前或任务完成时。由于它们会确定性触发，而不是依赖模型记住指令，因此被用来落实保证：每次编辑后运行格式化工具、阻止危险命令，或在智能体宣布任务完成前运行测试套件。它们是 Claude Code 中最接近权限与自动化系统的机制；只需在设置中配置一次，不必在每条提示词中重复要求。

Claude Code 中 Hooks、Skills 与子智能体有什么区别？

三者解决不同问题。Hooks 是始终启用的规则，会在设定节点自动触发，模型无法跳过，因此适合保证测试与 Lint 等操作执行。Skills 是按需加载的知识，也就是由指令组成的文件夹；只有当智能体识别出相关情境时才会加载，因此适合存放不希望始终占用上下文的专业知识。子智能体是拥有独立上下文窗口的智能体实例，负责委派任务，只返回最终结果，因此适合隔离混乱工作并保持主会话干净。Hooks 控制检查何时运行，Skills 控制任务如何执行，子智能体控制工作在哪里发生。

使用 Claude Code 构建产品，必须使用 Hooks、Skills 与子智能体吗？

不必。只用普通提示词也能高效使用 Claude Code，很多人正是这样做。这三项功能在你希望从逐步提示，升级到更自主、只需较少看管就能交付多步骤工作的循环时变得重要。Hooks 提供确定性检查，Skills 提供可复用的专业知识，子智能体则让大型工作能够运行，又不会让主上下文退化。如果智能体总是跳过你要求的步骤、忘记约定，或在长任务中丢失脉络，这些就是值得组装上述基础机制的信号。

什么是循环工程？

循环工程是一种系统设计实践：让系统自动提示并编排 AI 编程智能体，而不是由人每次手动提示一个步骤。Anthropic Claude Code 负责人 Boris Cherny 表示，他已经不再直接提示 Claude，而是编写循环来替他提示 Claude；之后，这个术语开始广泛传播。在 Claude Code 中，构建这种循环的基础模块是 Hooks、Skills 与子智能体。需要注意的是，只有拥有一项固定标准，让循环每轮都能据此检查，循环才能产生可靠结果；这意味着循环必须根据需求与验收标准验证工作，而不能只有维持运行的自动化。

Claude Code 循环能验证功能是否真正正确吗？

只能验证一部分，这正是关键限制。Hooks 可以运行测试，子智能体也可以审查工作，但它们只能验证测试与审查者被要求检查的内容。仍然需要有人定义功能怎样才算“完成”、编写验收标准，并判断通过检查是否真的等同于实现了你的意图。这项定义就是计划，而循环的基础机制无法自行生成它。因此，构建者会把 Agent Loop 与明确需求和验收标准配对：循环负责运行工作，计划则告诉循环和你本人，结果确实正确。

BrainGrid 是一个计划优先的应用构建平台，可以把你的创意转化为带有验收标准的需求，让 Claude Code 循环终于拥有可供构建与验证的完成定义。前往 braingrid.ai 试用。