Varick Agents CTO Eyad Khrais 吃到上一篇 Claude Code 入门文章:The complete claude code tutorial 的红利后(在 X 上大受欢迎,总阅读量接近 500 万),又迅速写了第二篇 Claude Code 进阶的文章:The claude code tutorial level 2。这篇文章的核心在于介绍 Skills(技能)、Subagents(子智能体)和 MCP connectors(MCP 连接器)这三大高级功能。
关键细节
Skills(技能):教导 Claude 特定工作流
- 定义与结构:Skill 是一个 Markdown 文件,包含 YAML 头信息(名称、描述)和具体的指令正文。
- 创建方式:在
~/.claude/skills/目录下创建文件夹和SKILL.md文件。 - 工作原理:采用“渐进式披露”原则。Claude 启动时仅加载 Skill 的名称和描述(约 100 tokens),只有在判定相关时才加载完整指令。这允许用户拥有数十个技能而不占用过多上下文。
- 应用场景:代码审查标准、Git 提交信息规范(如 Conventional Commits)、数据库查询模式、API 文档格式等。
Subagents(子智能体):隔离上下文与任务分发
- 核心优势:解决上下文退化问题。主对话将复杂任务委托给子智能体,子智能体在独立的 200K 窗口中运行,仅返回摘要给主对话,从而防止主上下文被污染。
- 内置类型:
- Explore:快速、只读的代码库搜索与分析。
- Plan:用于规划模式下的研究和架构决策。
- General-purpose:处理需要多步操作的复杂任务。
- 自定义智能体:用户可在
~/.claude/agents/中定义自定义智能体(如安全审查员),设定特定的系统提示词和工具权限(如只读或读写)。 - 通信模式:主智能体委托任务 -> 子智能体执行 -> 子智能体返回摘要。注意:子智能体不能再生成子智能体。
MCP Connectors(模型上下文协议):连接外部世界
- 功能:一种标准化的接口,允许 AI 模型直接调用外部工具和数据源,无需为每个工具单独集成。
- 操作命令:使用
claude mcp add --transport http <name> <url>添加连接。 - 推荐集成:
- GitHub:管理代码库、PR 和 Issue。
- Slack:读取频道历史和摘要。
- PostgreSQL:直接查询数据库。
- Linear/Jira:集成任务跟踪。
- 实际效果:将原本需要切换 5 个标签页(查看 Issue、设计图、Slack 讨论、写代码、更新工单)的工作流,整合为一个连续的会话。
原文:The claude code tutorial level 2
这是官方 Claude Code 教程的第二部分,我将涵盖更高级的概念,帮助你更充分地利用 Claude Code。如果你还没读过第一部分,我强烈建议你在读这篇文章之前先读一下。这篇文章直接建立在那些基础之上。
我已经做了 7 年的软件工程师(SWE),曾在 Amazon、Disney 和 Capital One 工作。我交付的代码触及数百万用户。第一部分涵盖了大多数人容易弄错的基础知识,但这篇文章将深入探讨 Claude Code 底层的系统,这些系统区分了合格的使用和卓越的使用。
大多数人仍然不知道如何有效使用的主要功能有 3 个,即:技能 (skills)、子代理 (subagents) 和 MCP 连接器 (MCP connectors)。所有这些功能都在文档中,唯一的问题是文档没有告诉你这些部分在实践中如何组合在一起,或者哪些配置对实际工作真正重要。
以下是我在通过日常构建生产级软件使用这些系统后所学到的一切。其中一些花了我几周时间才弄明白,而另一些是通过反复试错得出的。希望能为你节省一些时间。
在我们进入高级功能之前,有一些影响其他一切的基础性内容。如果你正在使用多个 AI 编程工具,你可能假设它们处理上下文的方式都是一样的(剧透预警:并不是)。根据 Qodo 工程团队的详细比较,Claude Code 提供了“更可靠且明确的 200K token 上下文窗口”,而 Cursor 的“实际使用量通常低于理论上的 200K 上限”,这是由于“为了性能或成本管理而进行的内部截断”。该系统应用了静默减少你有效上下文的内部保障措施。我在第一部分中涵盖了为什么上下文如此重要。
虽然你可能会因为 Cursor 有这些限制而生气,但你必须明白不同的工具是针对不同的工作流进行优化的。如果你正在处理大型、相互关联的代码库,你需要模型理解你的认证系统如何连接到 API 路由,以及它如何连接到数据库模式,那么上下文就很重要。因此,对于较大的项目,我会建议直接使用 Claude Code。Claude Code 能够持续提供完整的 200K 上下文。
这也是为什么我即将介绍的功能在 Claude Code 中特别有效的原因。技能、子代理和 MCP 连接都受益于拥有可预测的上下文来工作。
技能 (Skills)
技能是一个 Markdown 文件,用于教导 Claude 如何执行特定于你工作的操作。当你问 Claude 一些符合技能用途的问题时,它会自动应用该技能。结构非常简单。
- 创建一个包含
SKILL.md文件的文件夹:~/.claude/skills/your-skill-name/ - 或者对于你想与团队共享的项目特定技能:
.claude/skills/your-skill-name/SKILL.md
每个 SKILL.md 都以 YAML 头信息(name 和 description)开头:
name: 代码审查标准
description: 在审查 PR 或建议改进时,应用我们团队的代码审查标准。用于审查代码、讨论最佳实践,或当用户请求对实现提供反馈时。
描述 (description) 是至关重要的。Claude 使用它来决定何时应用该技能。对触发条件要具体。你也可以明确告诉 Claude “利用 x 技能 (utilize x skill)”,它会照做。但目标是让 Claude 根据自己的判断识别出何时需要利用该技能。
在 yaml 头信息下方,用 Markdown 编写实际指令。这是一个最小示例:
---
name: commit-messages
description: 生成符合我们要团队规范的提交信息。在创建提交或当用户询问有关提交信息的帮助时使用。
---
# 提交信息格式
所有提交均遵循约定式提交(conventional commits):
* feat: 新功能
* fix: bug 修复
* refactor: 既不修复错误也不增加功能的代码更改
* docs: 仅文档
* test: 添加或更新测试
格式:`type(scope): description`
示例:`feat(auth): add password reset flow`
保持描述在 50 个字符以内。如果需要更多上下文,加一个空行然后写正文。起初以这种格式写作会很别扭(因为写听起来自然的英语句子是你通常的做法),但质量的差异是显而易见的。
关键的架构原则是渐进式披露。Claude 在启动时只预加载每个已安装技能的名称和描述(每个大约 100 tokens)。完整的指令只有在 Claude 确定该技能相关时才会加载,这意味着你可以拥有几十个技能而不会通过膨胀你的上下文。
你可以将支持文件添加到你的技能文件夹中。如果你有大量的参考资料,把它放在一个单独的文件中,并在 SKILL.md 中引用它。Claude 只会在需要时读取它。
同样重要的是要注意,技能不仅仅局限于代码。我见过工程师为以下内容构建技能:
- 特定于其架构的数据库查询模式
- 他们公司使用的 API 文档格式
- 会议记录模板
- 甚至是像膳食计划或旅行预订这样的个人工作流
这种模式适用于任何你发现自己反复向 Claude 解释相同上下文或偏好的情况。
要查看当前加载了哪些技能,直接问 Claude:“What skills do you have available?(你有哪些可用技能?)” 它会列出它们(或者去 设置 -> 功能 -> 向下滚动,你会看到技能)。
子代理 (Subagents)
子代理是一个独立的 Claude 实例,拥有自己的上下文窗口、系统提示词和工具权限。这正是 Claude Code 架构真正与众不同的地方。当 Claude 委托给子代理时,该子代理独立运行并将摘要返回给主对话。
记住上下文退化发生在上下文窗口的 45% 左右,这一点很重要。子代理让你能够将复杂的研究或实施任务卸载到一个全新的上下文中,然后只带回相关的结果,这意味着你的主对话保持干净。
Claude Code 包含三个内置子代理:
Explore(探索):一个快速、只读的代理,用于搜索和分析代码库。当 Claude 需要在不进行更改的情况下理解你的代码时,它会委托给这里。当正确使用时,Claude 会指定彻底程度:快速、中等或非常彻底。
Plan(计划):在计划模式下使用的研究代理,用于在提出计划之前收集上下文。它调查你的代码库并返回发现结果,以便 Claude 做出明智的架构决策。
General-purpose(通用):一个能力强的代理,用于执行需要探索和行动的复杂、多步骤任务。当任务需要多个依赖步骤或复杂推理时,Claude 会委托给这里。
创建自定义子代理
就像你需要自定义技能一样,我强烈建议创建你自己的自定义子代理。在 Claude Code 中运行 /agents 可以查看所有可用的子代理并创建新的。
要手动创建一个,添加一个 Markdown 文件到 ~/.claude/agents/(用户级,在所有项目中可用)或 .claude/agents/(项目级,与团队共享)。
一个示例结构:
---
name: security-reviewer
description: 审查代码中的安全漏洞。在检查认证问题、注入风险或数据泄露时调用。
tools: Read, Grep, Glob
---
你是一名专注于安全的代码审查员。在分析代码时:
1. 检查认证和授权方面的缺口
2. 寻找注入漏洞(SQL、命令、XSS)
3. 识别敏感数据泄露风险
4. 标记不安全的依赖项
为每个发现提供具体的文件和行号引用。按严重程度分类:严重、高、中、低。
tools 字段控制子代理可以做什么。对于只读审查者,限制为 read, grep 和 glob 命令。对于实施代理,包括 write, edit 和 bash 命令。
子代理如何通信
这是大多数人忽略的部分。子代理不会直接相互共享上下文,因为它们是隔离运行的。通信通过委托和返回模式发生:
- 主代理识别适合委托的任务
- 主代理使用描述任务的特定提示词调用子代理
- 子代理在其自己的上下文窗口中执行
- 子代理将发现/操作的摘要返回给主代理
- 主代理整合摘要并继续
摘要是关键。设计良好的子代理不会将其整个上下文倾倒回去。这就是为什么子代理描述和系统提示词需要对输出格式非常明确。
对于复杂的工作流,你可以链接子代理。主代理进行编排:
|── Delegates research to Explore subagent
│ └── Returns: "Found 3 relevant files: file1.ts, file2.ts, file3.ts"
|── Delegates implementation to custom implementer subagent
│ └── Returns: "Added password reset endpoint, updated 2 files"
└── Delegates testing to custom test-runner subagent
└── Returns: "All 12 tests passing, coverage at 94%"
每个子代理都为其特定任务获得新鲜的上下文。主代理只持有摘要,而不是完整的探索历史。这防止了导致长时间编码会话崩溃的上下文污染。
一个重要的约束:子代理不能生成其他子代理。这防止了无限嵌套并保持架构的可预测性。
实用的子代理模式
大型重构:让主代理识别所有需要更改的文件,然后为每个逻辑组启动一个子代理。每个子代理处理其范围并返回摘要。主代理永远不需要同时持有每个文件的完整上下文。
代码审查管道:创建三个子代理:样式检查器、安全扫描器、测试覆盖率,并针对 PR 并行运行它们。每个都以一致的格式返回发现结果 -> 主代理将其合成为单个审查。
研究任务:当你需要理解代码库中不熟悉的部分时,带着具体问题委托给 Explore。它返回相关文件和模式的提炼地图,使你的主上下文专注于实际的实施工作。
MCP (Model Context Protocol)
MCP 是一种标准化方式,让 AI 模型通过统一接口调用外部工具和数据源,而不是为每个工具进行自定义集成。你不必进入 github,不必进入 slack、gmail、drive 等等。你可以通过 MCP 服务器让 AI 在 Claude 界面中与所有这些“对话”。
添加连接器的命令:
# HTTP transport (recommended for remote servers)
claude mcp add --transport http <name> <url>
# Example: Connect to Notion
claude mcp add --transport http notion https://mcp.notion.com
# 使用身份验证连接到 GitHub
claude mcp add --transport http github https://mcp.github.com \
--header "Authorization: Bearer your-token"
或者如果你想在 Web 应用程序中使用超级简单的途径,去 设置 -> 连接器 -> 找到你的服务器 -> 配置 -> 给予权限,你就搞定了。
过去 6 个月里 MCP 服务器为我做的一些示例:
- 从问题跟踪器实现功能:“添加 JIRA 问题 ENG-4521 中描述的功能”
- 查询数据库:“从我们的 PostgreSQL 数据库中查找上周注册的用户”
- 集成设计:“根据新的 Figma 设计更新我们的邮件模板”
- 自动化工作流:“创建 Gmail 草稿,邀请这些用户参加反馈会议”
- 总结 Slack 线程:“团队在 API 重构频道中决定了什么?”
力量不在于任何单一的集成。
过去需要五次上下文切换的工作流(检查问题跟踪器、查看设计、审查 Slack 讨论、实施代码、更新工单),现在发生在一个连续的会话中。你全天候处于心流状态。
我建议连接以下 MCP 服务器:
- GitHub:仓库管理、Issues、PRs、代码搜索
- Slack:频道历史、线程摘要、消息搜索
- Google Drive:在实施过程中访问文档以供参考
- PostgreSQL/databases:直接查询而不离开 Claude
- Linear/Jira:问题跟踪集成
要查看当前的 MCP 连接,在 Claude Code 中运行 /mcp。
第三方 MCP 服务器未经 Anthropic 验证,所以要小心。对于敏感集成,请审查服务器的源代码或使用服务提供商的官方连接器。
这就是所有内容结合的地方。一个知道你代码库模式的技能 + 一个处理测试的子代理 + 连接到你问题跟踪器的 MCP 连接 = 一个无与伦比的系统。
技能编码了你团队的惯例。你不需要担心上下文。子代理保持你的主对话干净,同时处理复杂的子任务。MCP 连接消除了分散你注意力的上下文切换。
我观察到的从 Claude Code 获得最大收益的工程师,并没有将其用于一次性任务,而是将其视为一个倍增其工作能力的系统。他们投入时间配置技能、定义子代理、连接服务。这种投资随后在每一个后续任务中都获得了理所应当的回报。
如果你害怕不知道从哪里开始,就从一个针对你反复解释的事情的技能开始。或者只创建一个单一的代理。然后测试并从那里开始。不需要让自己一次性尝试所有东西而不知所措。
总结一下
上下文窗口是不平等的。 Claude Code 提供一致的 200K tokens。由于内部保障措施,Cursor 在实践中通常截断到 70-120K。这对大型代码库很重要。
技能教导 Claude 你特定的工作流。 创建 ~/.claude/skills/skill-name/SKILL.md,带有 YAML frontmatter(名称、描述)和 Markdown 指令。Claude 在相关时会自动应用它们。
子代理为复杂任务提供隔离的上下文。 每个都获得自己的 200K 窗口。内置:Explore, Plan, general-purpose。在 ~/.claude/agents/ 中创建自定义代理。它们通过委托和摘要进行通信,而不是共享上下文。
MCP 连接器消除上下文切换。 连接到 GitHub, Slack, 数据库, 问题跟踪器。将通常需要五个标签页的工作流链接到一个连续的会话中。命令:claude mcp add --transport http <name> <url>
这些会产生复利。 技能编码模式,子代理处理子任务,MCP 连接服务。它们共同构建了一个随使用而改进的系统。