AI TOOLS

EP02. "Claude Code 101:从 Agent 原理到 Subagents/Skills/MCP/Hooks"

首页 › AI 工具 › Claude · Claude Product Courses · EP02
约 22 分钟· #EP02#Claude#Claude Product Courses
🔒 登录后可标记已读
  • Anthropic 官方 Claude Code 101 课程,12 节课 + 1 个结业测验,官方标注约 1.5 小时,教的是 Claude Code 这个终端 agentic 编程工具本身怎么运作、怎么管理上下文、怎么扩展能力
  • 跟本站 01_Overview 那篇「Claude Code 是什么与新手上手」有重叠(安装方式、CLAUDE.md 基础、Explore→Plan→Implement→Verify 循环),这篇不重复那些内容,只补官方课程讲到、前一篇没提的细节——Agent 底层怎么循环运作、权限模式细分、上下文管理指令、代码审查两步法、CLAUDE.md 的团队/个人分层用法、Subagents/Skills/MCP/Hooks 这四个进阶功能
  • 前置知识:已装好 Claude Code、跑过至少一次基本对话(建议先看 01_Overview 那篇入门笔记)

重点内容


Agent 是什么、Agentic Loop 怎么转

官方对 Agent 的定义:「能跟环境互动、为了达成一个明确目标而采取行动的软件」,靠一个大语言模型持续实时运作,过程中可能调用工具、外部服务,甚至其他 AI Agent。

Claude Code 的核心运作是一个循环(Agentic Loop):

  1. 你发一句 prompt
  2. Claude 收集必要的上下文(模型可能直接回文字,也可能回一个「工具调用」的指令)
  3. 采取行动——改文件、跑命令
  4. 检查结果是不是达到目标
  5. 结束,或者回到第 2 步继续跑

这个循环跑的过程中,你随时能打断、补充信息、或者叫它改方向。跟一般聊天助手的关键区别:普通助手只会接文字、吐文字,Claude Code 会自己判断「这一步该不该调用工具」,靠的是语义推理,不是写死的规则。


权限模式:四种怎么选

按 Shift + Tab 循环切换,四种模式控制 Claude 能自主到什么程度:

模式行为
Manual(默认)每次要改文件、跑命令都先问你
Auto-accept改文件不用问,但跑命令还是要你批准
Plan Mode只用只读工具读代码、做研究,写出执行计划,批准之前不动任何文件
Auto Mode完全不问权限,改由背景安全分类器实时筛查每个动作,拦下有风险的操作

📌 选哪个模式没有标准答案,官方原话是「看你自己舒服的程度」——简单任务可以开 Auto-accept 求快,动到关键代码或第一次跟这个代码库打交道,建议从 Manual 或 Plan Mode 开始。


Explore → Plan → Code → Commit:补几个实操技巧

这个四阶段循环本身在 01_Overview 那篇已经讲过(对应 Explore→Plan→Implement→Verify),这里补官方在这门课额外给的具体做法:

Explore + Plan 阶段:按 Shift + Tab 切到 Plan Mode,给一句描述清楚的 prompt,例如:

I need to add WebP conversion to our image upload pipeline. Figure out
where in the pipeline it should happen, whether we need new dependencies,
and how to approach it.

(我要在图片上传流程里加 WebP 转换,帮我找出该加在流程哪个环节、需不需要新依赖、怎么下手)

Claude 会读文件、上网查资料,给出一份行动计划,你可以批准、要求改某个部分、或者继续追问,这是改方向成本最低的时机。

Code 阶段三个技巧:

  1. 写清楚成功标准:计划里明确写出「怎样算做对了」,Claude 才知道要对齐什么
  2. 给它多装工具:比如装 Claude in Chrome 扩展,让 Claude 能直接操作浏览器分页、测试 UI,减少来回沟通
  3. 给测试套件当真理来源:有现成 test suite 让 Claude 能持续跑来验证,比靠它自己判断可靠

💡 如果同一个问题反复出现、每次都要纠正 Claude,官方建议直接叫它把解法写进 CLAUDE.md(跟 01_Overview 提到的「同步更新」是一个意思)。

Commit 阶段:自己测一遍 → 跑一个 subagent 代码审查员拿「新鲜视角」审一遍(细节见下面「代码审查」小节)→ 让 Claude 照你平常的风格生成 commit message → 下一个功能重复这套流程。subagent 审查之所以有用,是因为它没有背着这次会话的上下文包袱,不会被「我知道这段代码是为什么这样写」的偏见影响判断。


上下文管理:三个指令

上下文窗口就是 Claude 的「工作记忆」——每次你发 prompt、Claude 读一个文件、跑一次工具调用、拿到一次工具结果,都在往这个窗口里加东西,快满的时候系统会自动压缩(保留重要细节、删掉不重要的工具调用结果),但压缩难免会丢一些细节。三个手动指令:

指令作用什么时候用
/compact手动压缩到当前为止的对话,但保留会话记忆还在做同一个功能、快撞上上下文上限、但还要继续做
/clear清空全部上下文,从零开始要开始做下一个功能,避免被上一个话题的思路带偏
/context显示当前上下文占用情况、哪几类东西占得多、附可视化分布图想搞清楚上下文都花在哪了

省上下文的三个习惯:

  • prompt 写具体一点——太模糊 Claude 得花更多轮探索才能搞懂你要什么
  • 留意 MCP server:默认会把所有工具定义都载进上下文,不用的记得关(细节见下面 MCP 小节)
  • 探索型/研究型任务丢给 subagent 做,只把摘要带回主上下文,不要让整个探索过程占用主对话的空间

代码审查:两步法

Claude 写完代码之后,正式 commit 前建议走两步:

第一步:自己看实际的 diff。/diff 指令会打开一个交互式界面,逐文件显示改动前后对比(这个指令依赖 Git 仓库,靠读 Git 的改动记录)。重点看三类问题:

  • 没被要求却被顺手改掉的地方(配置值被改、方法被重写)
  • 被削弱的测试(测试被跳过、删掉、或者断言被放宽)
  • 新加的依赖和写死的数值(新包、写死的 URL、写死的 key)

第二步:找第二意见。/code-review 指令会开一个「干净上下文」的审查——不带这次会话任何历史,独立检查这次改动并报告发现。可以加深浅度参数:/code-review low(保守,只报高把握的问题)/ /code-review high(更广泛,可能包含不确定的发现)。

处理发现的问题分三类:

  1. 现在就修——确实是问题、后果不小
  2. 先问为什么——不确定是不是真问题,需要先搞清楚
  3. 放着不管——影响很小、无关紧要

📌 什么情况值得走完整审查流程:改动量大、碰到敏感代码区域、要交给同事接手的工作。单行小改动扫一眼 diff 就够,不用大费周章。


CLAUDE.md:团队 vs 个人两层

01_Overview 那篇已经讲过 CLAUDE.md 的基本写法(怎么写、为什么重要),这里补这门课额外提到的用法:

两层记忆文件:

  • 项目级 CLAUDE.md:放项目根目录,跟着版本控制一起进 repo,team 里每个人都读到同一份
  • 用户级 CLAUDE.md:放在你自己的配置文件夹里,跨所有项目生效,放你的个人偏好,不会影响队友

用 @ 引用其他文档,不用把内容整个复制进 CLAUDE.md:

## README.md

Please read if you need more info: @README.md

💡 不要一开始就写一份很厚的 CLAUDE.md:官方建议先不写,从实际用的过程中留意 Claude 哪里理解错了、你纠正了什么,再把这些「course-correction」补进去,保持文件精简聚焦;想要 Claude 自己先扫一遍项目生成初稿,直接跑 /init 指令。


Subagents:把探索工作外包出去

Claude 主上下文很容易被「探索代码库」「跑网页搜索做研究」这类工具调用过程塞满。Subagent 是解法:它有自己独立的上下文窗口,能跟主对话并行跑,做完全部探索工作后,只把摘要交回来——探索过程中翻了多少文件、走了多少弯路,都不会占用主对话的上下文空间。

建一个 Subagent:跑 /agents 指令,选 "Create new agent",跟着流程选作用范围、描述用途、选它能用哪些工具、挑个颜色,Claude 会自动生成名字、描述、prompt。本质上是一份带 YAML frontmatter 的 Markdown 文件。

两个进阶设置:

  • 持久记忆:让 subagent 跨对话记住东西,适合固定负责某类项目工作的场景
  • 预载 Skills:在 subagent 定义里加 skills 这个 key 列出技能名——注意跟主对话不一样,主对话只先载入 Skill 的名字和描述,subagent 会把整个 Skill 内容直接载进上下文

Skills:教一次,以后自动用

不用每次都跟 Claude 重复解释同一套编码规范、PR 审查格式、commit message 偏好——Skill 是「教 Claude 一次,之后相关场景会自动套用」的方式。一个 Skill 是一个文件夹,里面放指令、脚本、资源文件,agent 会自己判断什么时候该用。

核心文件是 SKILL.md:里面的描述(description)决定 Claude 会不会在某次请求里触发这个 Skill——靠比对请求内容跟描述是否匹配。

存放位置两种:

位置范围适合放什么
~/.claude/skills(个人目录)跟着你,所有项目通用个人习惯、偏好写法
.claude/skills(项目根目录)谁 clone 这个 repo 谁就自动有团队统一标准

跟其他自定义方式的区别:

方式什么时候载入适合场景
CLAUDE.md每次对话都载入一直都要用到的偏好
Skills匹配到相关请求才载入(一开始只载入名字+描述,省上下文)只在特定任务才用得到的专业知识
Slash Commands要手动打指令才触发你自己主动想跑的固定流程

💡 判断标准很简单:如果发现自己在反复跟 Claude 解释同一件事,那就是一个「该写成 Skill」的信号。


MCP:接外部工具和数据源

MCP(Model Context Protocol)是一套开放标准,让 Claude Code 能连上外部工具和数据源——比如接 Linear 管项目、接 Context7 这类文档服务器查依赖包的最新用法。

加一个 MCP server:用 claude mcp add 指令配置,分两种类型:

  • HTTP server:接远端服务,由服务商托管
  • Stdio server:跑在你本机的本地进程

对话内跑 /mcp 能看目前连了哪些 server、各自状态,也能在这里关掉暂时不用的。

作用范围三级:本地范围(只当前项目)、用户范围(跨所有项目)、项目范围(写进 .mcp.json 这个文件、跟着 repo 进版本控制,team 共用)。

⚠️ 上下文成本:MCP server 的工具定义就算没用到,也会先占掉一块上下文空间,用不到的记得关掉;能用 CLI 工具(比如 gh、aws)解决的,效率通常比对应的 MCP 高。Skills 是另一种选择——只有真的要用的时候才把完整内容载进上下文,比 MCP 更省。


Hooks:确定性执行,不依赖 Claude「愿不愿意」

Hooks 的核心价值是「确定性」——一定会执行,不像写在 CLAUDE.md 里的指令那样,Claude 有时候照做、有时候可能漏掉。官方原话:「有些时候它就是不会做。Hook 能让这件事每一次都发生,没有例外。」常见用途:文件改完自动格式化、记录跑过的命令做合规审计、拦下危险操作(比如改生产环境文件)、任务完成后发通知。

怎么设置:在 settings.json 里选一个事件、可选加个工具匹配条件(matcher)、写要跑的命令,也能用 /hooks 指令来配置。常用事件:

事件触发时机
PreToolUse工具调用之前
PostToolUse工具调用完成之后
UserPromptSubmit你提交 prompt 的时候
StopClaude 回复结束的时候
NotificationClaude 发通知的时候

最常见用法:设一个 PostToolUse hook,matcher 写 "Edit|MultiEdit|Write"(文件被编辑/多重编辑/新写入时触发),命令判断文件后缀,自动跑对应格式化工具(TypeScript 用 Prettier,Go 用 gofmt……)。

用 PreToolUse 拦截动作:这类 hook 能在工具真正执行前直接拦下来——收到的是工具名和输入内容(JSON,通过 stdin 传入),靠退出码(exit code)决定结果:

  • Exit code 0:正常放行
  • Exit code 2:拦截这个动作,stderr 里的内容会告诉 Claude 为什么被拦
  • 其他退出码:不算拦截,会显示错误但不中断

这是强制性规则的做法,比如「禁止写入 production 目录」「禁止跑危险的 bash 指令」,写成 hook 比写进 prompt 靠谱。

团队共享:hooks 写进 .claude/settings.json(项目级)可以跟着 repo 进版本控制,team 每个人自动拿到同一套规则;脚本路径用环境变量 CLAUDE_PROJECT_DIR 引用,不管 Claude 当前工作目录在哪都能跑对。

📌 判断原则:「如果一件事必须每次都发生、不能有例外,别写进 prompt,写成 hook。」

常见错误

  • ❌ 复杂/关键代码任务一上来就用 Auto Mode 图快——背景安全分类器能拦掉明显危险的操作,但不代表它会挑出所有「方向错了」的改动,第一次碰的代码库建议先从 Manual 或 Plan Mode 开始
  • ❌ MCP server 装了一堆常年挂着不管——工具定义占上下文空间是持续性的,不用的记得在 /mcp 里关掉,或者改用 CLI 工具/Skills
  • ❌ 只看 Claude 给的改动摘要就直接 commit,不看 /diff 的实际改动——摘要可能漏掉顺手改掉的配置值、被削弱的测试
  • ❌ 把「只想用一次」的临时指令也写进 CLAUDE.md,导致文件越堆越厚——CLAUDE.md 建议只放真正会反复用到的规则,一次性的事直接在对话里说
  • ❌ 期待 Claude 每次都自觉遵守 CLAUDE.md 里写的强制规则(比如「绝对不能碰 production 目录」)——CLAUDE.md 是建议不是强制,真正不能有例外的规则要写成 Hook,不是写进 prompt
  • 💡 同一个问题反复要纠正 Claude,与其每次重复解释,先想想该写进 CLAUDE.md(一直要用的偏好)还是该写成 Skill(特定任务才用到的专业知识)

Sources

官方文档:

  1. Claude Code 101(课程总览)— https://academy.claude.com/courses/claude-code-101
  2. What is Claude Code? — https://academy.claude.com/courses/claude-code-101/what-is-claude-code
  3. How Claude Code works — https://academy.claude.com/courses/claude-code-101/how-claude-code-works
  4. Installing Claude Code — https://academy.claude.com/courses/claude-code-101/installing-claude-code
  5. Your first prompt — https://academy.claude.com/courses/claude-code-101/your-first-prompt
  6. The explore → plan → code → commit workflow — https://academy.claude.com/courses/claude-code-101/the-explore-plan-code-commit-workflow
  7. Context management — https://academy.claude.com/courses/claude-code-101/context-management
  8. Code review — https://academy.claude.com/courses/claude-code-101/code-review
  9. The CLAUDE.md file — https://academy.claude.com/courses/claude-code-101/the-claude-md-file
  10. Subagents — https://academy.claude.com/courses/claude-code-101/subagents
  11. Skills — https://academy.claude.com/courses/claude-code-101/skills
  12. MCP — https://academy.claude.com/courses/claude-code-101/mcp
  13. Hooks — https://academy.claude.com/courses/claude-code-101/hooks