内容来源：Bits, Bugs, and Opinions。https://tomakl.dev/posts/claude-code-skills-agents/
原题：Skills and agents: building reusable workflows in Claude Code
原发布时间：2026-03-06
Claude Code Skills 与智能体如何把重复劳动变成可复用工作流：19 个智能体、自动加载 Skills 以及真实示例。
归档关系：本文属于 Tomasz 的 Claude Code 配置系列，并链接到此前已经归档的自定义命令入门文章。它把这个系列从手动调用的命令，扩展到可复用 Skills、子智能体和多智能体编排。
兼容性说明（核对日期：2026-07-21）：当前 Skills 使用
.claude/skills/<name>/SKILL.md；原文的扁平.claude/skills/*.md布局已经过时。自定义命令如今已经并入 Skills，既支持斜杠调用，也支持自动加载。allowed-tools表示预先授权，而不是限制工具；version也不是文档规定的 Skill 字段。按照当前子智能体文档，Task已更名为Agent（旧名称仍可作为别名）；如果Agent可用，还可以创建嵌套子智能体；示例中的maxTurns与限定作用域 Hooks 仍受支持。原文的cot、self-refine和reflexion标签，是作者定义的提示词约定，并非内置执行模式。下文完整保留原始正文。
Hooks 文章介绍了安全层，也就是那些静默运行并阻止操作的部分。本文则讨论另一个方向：当你希望 Claude 做得更多，而不是更少时，会发生什么。具体来说，就是 Skills 和智能体怎样让你构建可复用工作流，不必每次会话都重复交代。
Skills 与命令：真正重要的区别
在介绍运行机制之前，先明确 Skills 不是什么会很有帮助。我此前写过自定义命令：/deploy、/morning、/humanize。命令是你亲自输入的内容，由你主动调用。
Skills 不同。它们位于 .claude/skills/ 中，Claude 会根据触发条件自动加载。你不必召唤，只要场景匹配，它们就会激活。
项目中有六项 Skills：
.claude/skills/
devops-diagnosis.md
security-scan.md
pr-reviewer.md
lapa-azure-admin.md
code-optimizer.md
text-humanizer.md
用户级目录（~/.claude/skills/）中还有几项，其中一项名为 claudeception，用于教 Claude 如何构建更好的 Skills。我很喜欢这种自我指涉。
Skill 文件是什么样的
Skill 是带 YAML Frontmatter 和指令正文的 Markdown 文件。Frontmatter 告诉 Claude 什么时候加载，以及允许使用哪些工具；正文则是真正的工作流。
下面是 text-humanizer Skill：
---
name: text-humanizer
version: 1.0.0
description: |
从文本中去除 AI 生成写作的痕迹。只要正在审查或编辑可能包含 AI 模式的文本，
即使用户没有明确要求人性化，也要主动使用。以下情况触发：文本使用
“delve”“crucial”“landscape”“tapestry”“testament”“foster”
“enhance”“pivotal”“showcase”“underscore”“vibrant”等词；
文本滥用破折号；文本使用“Not only...but...”“serves as”“stands as”等句式；……
allowed-tools: Read, Grep, Bash
---
Claude 会读取 description 字段，以判断 Skill 是否相关。如果你提到 “delve” 这样的词，或者要求“让这段文字听起来更自然”，Skill 就会加载。如果你正在编写代码，完全没有提及文本质量，它就不会加载。
devops-diagnosis Skill 更复杂。它的描述列出了具体触发条件：错误日志、堆栈追踪、OutOfMemoryError、连接超时、“应用宕机”、Java 异常、Python Traceback。只要其中任一内容出现，Skill 就会加载完整的多智能体流水线：
1、在 Confluence 中查找现有解决方案
2、并行启动网络调研、文档查询和代码搜索
3、把全部发现交给 enterprise-app-specialist 分析根本原因
4、询问用户要把发现记录在哪里
5、生成工单摘要
这就是 Skill 的正文。每当出现上述条件，它都会运行，我不必记得主动调用。“我粘贴一条错误”与“我粘贴一条错误，Claude 自动开始结构化调查”之间的差异，就只来自这一份文件。
策略也内置在其中。devops-diagnosis 使用 cot（思维链），意味着 Claude 会依次完成每个诊断步骤并展示推理。pr-reviewer 使用 self-refine，先完成初次审查，再进行第二轮检查以捕捉遗漏。text-humanizer 则使用 reflexion：起草、批评、修正。
智能体：拥有独立上下文窗口与规则
智能体是另一种东西。Skill 会把指令加载到当前对话；智能体则是拥有自己的上下文窗口、工具权限和模型的子流程。
项目目前有 19 个：
.claude/agents/
enterprise-app-specialist.md # opus 模型，深度排障
team-lead.md # opus，编排多智能体任务
trigger-dev-task-writer.md # sonnet，设计 Trigger.dev 任务
deploy-verifier.md # sonnet，部署后健康检查
vault-secret-rotator.md # sonnet，密钥审计与轮换
confluence-searcher.md # sonnet，搜索知识库
confluence-writer.md # sonnet，创建页面
jira-operations.md # sonnet，管理工单
web-researcher.md # sonnet，基于 Tavily 的网络搜索
docs-researcher.md # sonnet，通过 Context7 查询库文档
codebase-investigator.md # sonnet，搜索源代码
server-command-advisor.md # sonnet，远程服务器命令
log-analyzer.md # sonnet，解析与关联日志
github-ops.md # sonnet，管理 GitHub Issue
azure-ops.md # sonnet，管理 Azure 资源
aws-ops.md # sonnet，AWS 健康状况与 IAM
email-writer.md # sonnet，用我的口吻起草邮件
ticket-writer.md # sonnet，记录事件
blog-writer.md # sonnet，为本网站撰写文章
模型选择很重要，而且是刻意为之。多数智能体使用 sonnet：速度快、能力足够，对于定义明确的任务也不过度。两个智能体使用 opus：enterprise-app-specialist（深入推理复杂基础设施问题）和 team-lead（编排多个智能体并综合结果）。所有任务都使用 Opus 会更慢；所有任务都使用 Sonnet，则会让困难诊断问题的结果变差。
每份智能体文件也有 Frontmatter：
---
name: enterprise-app-specialist
description: |
排查生产应用问题、规划迁移，或者诊断 RHEL、AWS 或 Azure 上的连接问题时，
使用这个智能体。
model: opus
maxTurns: 25
hooks:
PreToolUse:
- matcher: "Bash"
hooks:
- type: command
command: /home/user/.claude/hooks/pre-tool-safety.sh
---
maxTurns 上限可以防止上下文用量失控。智能体级 Hook 意味着安全检查在子流程内部同样会运行。描述与 Skill 描述一样，是 Claude 判断是否使用这个智能体的依据。
为什么隔离上下文窗口很重要
我把任务委派给智能体，首要原因不是能力，而是整洁。原始日志文件很大，搜索结果充满噪声。如果要求 Claude 在主对话中分析一个五万行日志文件，这部分上下文空间就被占满了。对话会变慢，后续回答质量也会下降。
把任务委派给 log-analyzer 后，它会在自己的上下文窗口中启动、加载日志并完成工作，再返回结构化摘要。主对话得到的是三段发现，而不是五万行文本。
web-researcher 也一样。它会运行 Tavily 搜索、过滤噪声，再返回相关内容。我的主对话不会积累搜索残渣。
codebase-investigator 智能体则会对源代码搜索进行相同处理。在大型代码库中查找某个类的全部用法，会产生大量 Grep 输出。智能体负责处理，我得到摘要。
智能体团队与编排
team-lead 智能体让事情开始变得有趣。它使用 Task 工具创建并协调其他智能体。
下面是其文件中的事件响应模式：
并行启动：
1. log-analyzer -- 分析日志，查找根本原因
2. confluence-searcher -- 查找现有运维手册
3. web-researcher -- 搜索已知问题
4. jira-operations -- 检查相关工单
随后依次执行：
5. enterprise-app-specialist -- 使用收集到的上下文深入诊断
6. ticket-writer -- 记录事件
7. jira-operations -- 创建或更新工单
第一至第四步可以并行运行，因为彼此没有依赖。第五步在它们之后运行，因为需要前四项结果。team-lead 最终会综合全部信息，不只是拼接输出，还会寻找不同智能体发现之间的关联。日志显示连接超时的时间戳，恰好与 Jira 中一次网络变更工单相同，这种组合信号与单独看到任意一项都不同。
完整系统审计模式会并行运行三个智能体（部署健康、密钥审计、文档时效），再生成统一报告。我偶尔会运行一次，这是最接近每日站会的体验，只不过这支团队不需要睡觉。
实用模式
下面是我发现值得采用的一些做法：
让 Skills 保持聚焦。 带有 20 个触发条件的 Skill 会在不该加载时加载，而且指令会与当前任务争夺注意力。text-humanizer 只有一项工作，devops-diagnosis 只有一条流水线。Skill 一旦试图涵盖太多，就会变成噪声。
让模型匹配任务，而不是满足虚荣心。 Opus 更好，很容易让人想在所有地方都使用它，但 Sonnet 已经足以胜任 email-writer，邮件不需要深度推理。生产环境 RHEL 诊断确实很困难，因此为 enterprise-app-specialist 使用 Opus 很值得，模型质量会体现出来。
混乱任务交给智能体，主对话用于决策。 我不会让 Claude 直接在聊天中分析日志，也不会在主上下文中开展网络调研。任何会产生大量原始输出的工作都交给智能体，返回内容始终是摘要。
把 Skills 当成组织记忆。 lapa-azure-admin Skill 记录了某个客户 Azure 环境特有的一切：Tenant ID、订阅结构、命名约定、哪些防火墙规则相关。没有这项 Skill，我每次会话都要重新解释环境；有了它，Claude 已经知道。
