我们知道和 AI 对话只是“会用”让 AI 按规范自动完成一整套任务才算真正进入 Agent 开发的大门。本文围绕 Agent Skills 展开把概念、工具、实战、排错、工程建议一次讲透适合刚接触 AI 编程助手、又想往 Agent 方向进阶的开发者。在近年来的 AI 编程工具里Claude Code 和 Codex 是两条非常有代表性的技术路线一个强调 Agent 自主规划与工具调用一个强调与编辑器、CLI 的深度集成。而 Agent Skills 的出现让两者的能力边界进一步扩展——你不再只是“问”模型而是把一套可复用的“技能”交给 Agent让它按你的规范去执行。全文会从最基础的概念讲起然后带你手动创建第一个技能包最后说明如何把它接入 Claude Code 与 Codex并整理出实际开发中最容易踩的坑。文章中的代码和目录结构都按最小可运行标准编写你可以直接复制到自己的项目里调整。1. 从“会用AI”到“会开发Agent”为什么需要 Agent Skills1.1 会提问与会执行之间到底差在哪里先看一个常见的开发场景。你让 AI“帮我写一个 Python 爬虫”它能很快给你一段代码但如果你让它“扫描这个目录下所有 Python 文件找出使用不安全的eval、subprocess且没有参数校验的代码并按指定格式输出审查报告”模型往往会在中途迷失方向或者输出非常随意的结果。原因很简单模型本身擅长“理解语言”和“生成文本”但它不擅长“记住一套固定流程”也不擅长“在每次任务中保持一致行为”。如果把任务规范写在系统提示词里提示词会越来越长维护成本越来越高如果每次都在对话里手动交代一遍效率又太低。Agent 的概念正是为了解决“执行”问题而出现的。Agent 可以理解为一个能自主调用工具、多步规划、根据中间结果调整策略的 AI 程序。它不满足于“回答问题”而是真正“完成任务”。但 Agent 也面临一个新问题不同的任务需要不同的专业知识。比如审查代码需要知道规范与危险模式写文档需要知道文档结构和示例风格做数据分析需要知道统计口径与报表格式。如果把这些知识全部塞进 Agent 的系统提示词里会互相干扰、难以维护。于是 Agent Skills 应运而生。1.2 Agent Skills 是什么Agent Skills 可以理解为一组“可插拔的专业能力包”。每个 Skill 是一个独立文件夹里面包含一个SKILL.md文件用来描述这个技能的名称、作用、使用场景和详细操作步骤若干辅助资源比如脚本、模板、示例数据、规则文档。当 Agent 遇到任务时会先根据技能描述判断“我是否需要加载某个技能”需要时再读取对应的SKILL.md和资源文件。这样 Agent 不会在一开始就把所有知识加载进上下文而是在合适的时机“按需调用”。这种设计至少带来三个明显收益。第一上下文更省。模型不需要在每次对话里都保存所有领域知识只有用到某个技能时才临时加载上下文窗口的压力大大降低。第二行为更可控。技能里的操作步骤是人工编写的、固定的Agent 在执行时会严格按照步骤推进而不是自由发挥。第三复用性更好。同一个技能可以在不同项目、不同 Agent 中反复使用团队里也可以把技能包作为“数字资产”共享。1.3 Agent Skills 与 Prompt、MCP、Function Calling 的区别很多读者会把 Agent Skills 和 Prompt 工程、MCP、Function Calling 混在一起这里做一个简单区分。Prompts 是给模型的文本指令是“一次性”的。你每次都要写或者写进系统提示词。它适合简单的、不需要太多外部依赖的任务。Function Calling 是模型调用外部函数的机制解决的是“模型如何触发一个具体操作”的问题。它适合把“工具”暴露给模型比如获取天气、执行 SQL、读取文件等但模型并不关心这些操作背后的领域知识。MCPModel Context Protocol提供的是“工具与数据源的统一接入协议”解决的是“Agent 如何连接外部系统”的问题。MCP Server 可以暴露资源、工具和提示词让 Agent 能读取数据、执行操作。Agent Skills 则更偏“上层能力封装”。它关注的是“Agent 如何按照一套完整流程完成某一类专业任务”。Skill 内部可以引用脚本、模板也可以建议 Agent 调用 MCP 工具。你可以理解为MCP 是给 Agent 装“手和眼睛”Agent Skills 是给 Agent 装“工作手册”。概念核心问题典型产物Prompt怎么描述任务提示词文本Function Calling怎么触发函数函数定义MCP怎么接入工具与数据MCP ServerAgent Skills怎么按流程完成任务SKILL.md 资源包1.4 为什么是 Claude Code 与 CodexClaude Code 是 Anthropic 推出的终端编程 Agent擅长在命令行中完成读代码、改代码、运行命令、提交 Git 等一系列开发任务。它对 Agent Skills 的原生支持比较友好你只要把技能包放到约定目录Claude Code 就能自动识别并在合适时机加载。Codex 是 OpenAI 推出的 CLI 编程工具同样具备 Agent 能力。社区中围绕 Codex 的玩法也非常多比如接入不同模型网关、配置自定义指令、使用 AGENTS.md 约束行为等。虽然不同工具的 Skill 加载机制略有差异但底层思想一致把可复用的流程和知识打包让 Agent 在需要时读取执行。本文后面的实战会把同一套技能包分别接入这两个工具帮助你理解差异也能在真实项目中灵活选择。2. 环境准备Claude Code 与 Codex 的安装2.1 工具链选型写 Agent Skills 之前先把环境准备好。你需要准备的东西包括Node.js 环境Claude Code 和 Codex CLI 都依赖 Node.js 运行一个支持终端操作的命令行工具可用的模型服务账号或 API Key建议使用 Git 管理技能包方便版本回溯。版本方面不同工具的安装方式和依赖版本更新较快具体以官方 README 或--version输出为准。下面的安装命令是常见方案如果你的环境已经有 Node.js直接执行即可。2.2 安装 Claude CodeClaude Code 提供两种主流安装方式一种是通过 npm 全局安装npm install -g anthropic-ai/claude-code另一种是使用官方安装脚本curl -fsSL https://claude.ai/install.sh | bash安装完成后在终端输入claude --version如果能看到版本号说明安装成功。接下来在项目目录中执行claude会进入交互式对话界面。首次使用需要完成登录授权配置好 API Key 或账号登录后即可开始。如果你是在 VSCode 中开发也可以安装官方扩展让 Claude Code 以面板形式出现在编辑器里。社区里常见的做法是配合 VSCode 的终端集成一起使用这样既能看代码又能直接和 Agent 对话。2.3 安装 Codex CLICodex CLI 同样是 npm 包常见安装命令是npm install -g openai/codex安装后检查版本codex --version如果你遇到“unable to locate the codex cli binary”这样的报错通常是因为系统中只安装了 Codex 的 GUI 插件或编辑器扩展而命令行二进制没有正确安装或者 PATH 环境变量没有配置好。处理方法会在后续问题排查章节详细说明。Codex 也支持通过环境变量指定模型提供方因此可以接入兼容 OpenAI 接口的第三方模型服务。配置时需要注意 base URL、API Key、模型名称是否匹配否则很容易出现模型不识别或鉴权失败的问题。2.4 验证环境为了确保两个工具都能正常工作建议在空目录中做一个最小验证。先建一个测试文件# 文件路径test.py def main(): print(hello agent)然后在 Claude Code 中提问“读取 test.py 并解释”如果能正确读取文件内容说明工具调用正常。再用 Codex 执行同样的尝试确认终端工具与模型服务之间的链路是通的。这里要特别提醒不同版本的工具对模型名称的兼容性不同。比如某些 Claude Code 版本会提示xxx is not a model this version of claude code recognizes这通常不是你的配置写错了而是当前版本支持模型列表里没有该项需要升级工具版本或更换模型名。3. Agent Skills 核心原理拆解3.1 技能包的目录结构一个标准的 Agent Skill 通常是一个独立文件夹命名使用小写字母和连字符比如code-review、doc-generator。文件夹内部至少包含一个SKILL.md其余资源文件按需组织。推荐目录结构如下skills/ └── code-review/ ├── SKILL.md ├── scripts/ │ └── review.py ├── templates/ │ └── report.md └── rules/ └── security-rules.mdSKILL.md是技能的入口Agent 首先读取它。scripts用于存放可执行脚本templates用于存放输出模板rules用于存放额外的规则文档。这样的结构方便技能包在多个项目之间复制移动。3.2 SKILL.md 的 frontmatter 元数据SKILL.md顶部有一段 YAML 格式的 frontmatter用来声明技能的关键元信息。最核心的两个字段是name和description。--- name: code-review description: 对代码变更进行系统性审查检查安全漏洞、性能问题、代码规范偏差和可维护性隐患。当用户要求审查代码、code review、检查 PR 时使用。 ---name是技能唯一标识Agent 和开发者都能通过它定位技能包。description的作用非常关键它决定了 Agent 会不会在合适的时机加载这个技能。所以 description 里一定要写清楚三件事技能做什么、适合什么场景、哪些关键词会触发它。另外description 不要写得太抽象比如“帮助用户提升代码质量”就不如“检查代码中的危险函数调用、未捕获异常、硬编码密钥”具体。Agent 是根据文本语义匹配的描述越具体命中率越高。3.3 渐进式披露如何设计技能说明Agent Skills 设计里有一个重要思想叫“渐进式披露”。简单来说就是不要让技能包一开始就把所有信息暴露给 Agent而是分层提供。第一层是SKILL.md里的 brief description只说明技能用途和触发条件。第二层是技能正文说明操作步骤和输出要求。第三层是资源文件比如规则文档、脚本模板这些内容只有在真正需要时才会被读取。这样做的好处是节省上下文空间。如果 Agent 只是判断“这个任务要不要用技能”它只需要读 description真正开始执行时再读完整正文需要更细的规则时再去读规则文件。每一层都比上一层更详细但只有在需要时才会被加载。3.4 技能与 Agent 的协作流程理解技能如何与 Agent 协作可以借助下面这个流程来把握。用户提出任务Agent 先对任务做初步规划。如果任务与某个技能的 description 匹配Agent 读取对应SKILL.md。Agent 按照SKILL.md中的步骤结合资源文件开始执行。执行过程中如果发现信息不足Agent 可以向用户提问或调用其他工具。最终产物按SKILL.md中定义的格式输出。这个流程说明技能本身不等于 Agent它只是 Agent 的“能力插件”。Agent 仍然负责规划、判断、调用工具和总结输出而技能负责提供专业流程与领域知识。4. 实战从零打造一个代码审查技能4.1 需求与功能拆分下面我们实际动手做一个“代码审查技能”。它的目标是当用户让 Agent 审查代码时Agent 能够按照固定流程检查危险函数、调试残留、硬编码密钥等问题并输出一份结构化报告。按功能拆分我们需要四块内容技能元信息用来告诉 Agent 何时使用审查步骤规定检查顺序和检查项辅助脚本自动扫描常见问题输出模板保证报告格式统一。4.2 创建技能目录在项目根目录下创建如下目录结构my-agent-project/ ├── .claude/ │ └── skills/ │ └── code-review/ │ ├── SKILL.md │ ├── scripts/ │ │ └── review.py │ └── templates/ │ └── report.md其中.claude/skills是 Claude Code 约定的技能放置目录。如果你的项目还没有这个目录直接创建即可。Codex 的加载方式不完全一样后面会讲。4.3 编写 SKILL.md先写技能入口文件# 文件路径.claude/skills/code-review/SKILL.md --- name: code-review description: 对代码进行系统性审查检查危险函数调用、调试残留、硬编码密钥、异常处理缺失等问题并输出结构化报告。当用户要求 code review、审查代码、检查 PR、分析代码质量时使用。 --- # Code Review Skill ## 目标 帮助开发者快速发现代码中的安全隐患、性能问题和可维护性风险。 ## 执行步骤 ### 第一步收集代码信息 1. 读取待审查文件或目录结构。 2. 识别主要编程语言和关键依赖。 3. 如果文件数量过多优先审查变更文件和核心入口文件。 ### 第二步运行自动化扫描 1. 调用 scripts/review.py传入待审查的文件路径。 2. 记录脚本输出的问题列表。 3. 如果脚本执行失败不要跳过先分析失败原因。 ### 第三步人工分析与补充 1. 针对脚本发现的每个问题判断是否真实存在。 2. 检查脚本未覆盖但代码中明显存在的风险点。 3. 对每个问题标记严重级别高危、中危、低危。 ### 第四步输出报告 1. 按 templates/report.md 的模板生成报告。 2. 报告内容包括审查范围、问题总数、按严重级别分组的问题列表、修改建议。 3. 报告中每条问题必须包含文件路径、行号、问题描述、修复建议。 ## 注意事项 - 禁止修改用户代码只输出审查结果。 - 如果无法确定某个问题是否误报在报告中标记为“需要确认”。 - 所有建议都要具体不要写“优化代码”这类空话。这份SKILL.md的核心是把审查流程固定下来让 Agent 每次执行时都按照同样的步骤走。注意我没有在技能里写任何具体语言的检查规则因为这部分交给脚本和规则文件更合适。4.4 编写辅助脚本辅助脚本的作用是快速定位常见问题。下面用 Python 写一个简单的扫描器它能检查 Python 文件中的危险函数调用、调试输出和硬编码密钥。# 文件路径.claude/skills/code-review/scripts/review.py #!/usr/bin/env python3 import os import re import sys # 常见的危险函数调用 DANGEROUS_FUNCTIONS [ r\beval\s*\(, r\bexec\s*\(, r\bcompile\s*\(, r\bsubprocess\s*\.\s*(call|run|Popen)\s*\(, ] # 调试残留 DEBUG_PATTERNS [ rprint\s*\(, rconsole\.log\s*\(, rdebugger\s*;, ] # 疑似硬编码密钥/密码 SECRET_PATTERNS [ r(?i)(password|passwd|secret|token|api[_-]?key)\s*[:]\s*[\][^\][\], ] def scan_file(file_path): problems [] try: with open(file_path, r, encodingutf-8) as f: lines f.readlines() except Exception as e: return [{file: file_path, line: 0, problem: f文件读取失败: {e}, level: 高危}] for line_no, line in enumerate(lines, start1): for pattern in DANGEROUS_FUNCTIONS: if re.search(pattern, line): problems.append({ file: file_path, line: line_no, problem: f发现危险函数调用: {line.strip()}, level: 高危, }) for pattern in DEBUG_PATTERNS: if re.search(pattern, line): problems.append({ file: file_path, line: line_no, problem: f发现调试残留: {line.strip()}, level: 低危, }) for pattern in SECRET_PATTERNS: if re.search(pattern, line): problems.append({ file: file_path, line: line_no, problem: f疑似硬编码密钥: {line.strip()}, level: 高危, }) return problems def main(): if len(sys.argv) 2: print(用法: python review.py file_or_dir) sys.exit(1) target sys.argv[1] files [] if os.path.isfile(target): files.append(target) elif os.path.isdir(target): for root, _, names in os.walk(target): for name in names: if name.endswith(.py): files.append(os.path.join(root, name)) else: print(f路径不存在: {target}) sys.exit(1) all_problems [] for f in files: all_problems.extend(scan_file(f)) if not all_problems: print(扫描完成未发现明显问题。) return for p in all_problems: print(f[{p[level]}] {p[file]}:{p[line]} {p[problem]}) if __name__ __main__: main()这个脚本不追求覆盖所有语言和场景重点是演示“技能如何借助脚本完成自动化检查”。实际项目中你可以把扫描规则扩展成 ESLint、Bandit、Semgrep 等成熟工具的封装调用。4.5 编写报告模板为了让 Agent 的输出格式统一再写一个报告模板# 文件路径.claude/skills/code-review/templates/report.md # 代码审查报告 ## 审查范围 - 文件路径 - 审查时间 - 编程语言 ## 问题总览 - 高危问题 - 中危问题 - 低危问题 - 总计 ## 问题详情 ### 高危 1. 文件xxx - 行号 - 问题描述 - 修复建议 ### 中危 1. 文件xxx - 行号 - 问题描述 - 修复建议 ### 低危 1. 文件xxx - 行号 - 问题描述 - 修复建议 ## 总结 - 整体评价 - 优先处理建议模板的意义在于让 Agent 每次输出的报告结构一致方便后续接入流程或人工归档。4.6 在 Claude Code 中加载使用完成技能包后在项目根目录启动 Claude Codeclaude然后在对话中输入请使用 code-review 技能审查项目中的 src 目录正常情况下Claude Code 会在技能目录中搜索匹配的SKILL.md读取后按步骤执行。如果它没有自动识别技能可以指定读取路径请阅读 .claude/skills/code-review/SKILL.md然后按照技能流程审查 src 目录这样做虽然少了自动触发但能保证技能被正确加载适合排障阶段使用。4.7 在 Codex 中加载使用Codex 的 Skill 加载机制和 Claude Code 略有不同但原理一致通过项目指令文件告诉 Agent“什么时候应该读取哪个技能包”。在项目根目录创建或修改AGENTS.md# 项目指令 ## 技能使用规则 当用户要求代码审查、code review、检查 PR 时必须按以下流程执行 1. 读取 .claude/skills/code-review/SKILL.md。 2. 调用 scripts/review.py 执行自动化扫描。 3. 按 templates/report.md 输出报告。 技能文件位于 .claude/skills/code-review/ 目录。然后在 Codex CLI 中启动输入codex 审查代码变更输出审查报告Codex 读取AGENTS.md后会根据指令加载技能包。这个方式不依赖特定绑定路径所以即使项目同时使用多个 Agent 工具也能保持一套技能复用。4.8 运行与验证为了验证技能是否真正生效可以创建一个小型示例# 文件路径src/demo.py import subprocess import os password 123456 def run_command(cmd): return subprocess.run(cmd, shellTrue) run_command(ls -la) print(debug output)然后执行审查流程。预期你会看到类似下面的问题输出[高危] src/demo.py:3 疑似硬编码密钥: password 123456 [高危] src/demo.py:4 发现危险函数调用: subprocess.run(cmd, shellTrue) [低危] src/demo.py:8 发现调试残留: print(debug output)这说明脚本扫描有效。接下来 Agent 会按模板生成完整报告包含修改建议。例如对于subprocess.run(cmd, shellTrue)建议改为参数列表方式并避免 shell 拼接对于硬编码密钥建议使用环境变量或密钥管理服务。5. 进阶构建可复用、可扩展的智能体技能体系5.1 技能命名与分类当技能数量越来越多命名与分类就成了头等大事。建议按照“动词-对象”的规则命名比如code-review、doc-generator、>skills/ ├── code/ │ ├── code-review/ │ └── refactor/ ├── docs/ │ ├── doc-generator/ │ └── changelog/ └── data/ ├──>## 前置依赖 在开始本技能前如果代码尚未审查请先加载 code-review 技能完成审查。第二种是把公共逻辑抽成独立脚本供多个技能调用。比如所有技能都用到的“输出报告”逻辑可以放到一个公共模板目录各技能按需引用。这样能避免同一份规则被复制到多个技能包减少维护负担。5.3 版本管理与团队共享技能本质上也是代码应该用 Git 管理。建议每个技能包独立版本号在SKILL.md的 frontmatter 中增加version字段--- name: code-review description: ... version: 1.2.0 ---变更记录可以放在技能包内的CHANGELOG.md中。这样当 Agent 行为异常时可以快速定位是不是某个技能更新引入的问题。团队共享方面推荐建一个独立的技能仓库团队成员通过 Pull Request 提交新技能或修改现有技能。提交前至少要有两个人 review避免单点决策。技能发布后项目里通过 git submodule 或复制的方式引入并记录版本。5.4 从技能到 Agent 工作流单个技能解决的是“单点任务”但真实项目往往需要多个技能串联。比如“新功能开发”可能包括需求分析、技术方案设计、代码生成、代码审查、测试、文档生成。每个阶段都可以对应一个技能。你可以把这类跨技能流程写在AGENTS.md或CLAUDE.md里让 Agent 知道完整的流程编排。例如## 通用开发流程 1. 需求明确后先读取 docs/requirements/ 下最新文档。 2. 编码前必须调用 code-review 技能中定义的规范检查。 3. 代码完成后运行测试并输出测试报告。 4. 最后调用 doc-generator 技能生成更新日志。这样技能负责“单步执行能力”Agent 负责“流程编排”两者配合才能发挥最大价值。6. 常见问题与排查思路实际使用 Agent Skills 的过程中大家最容易遇到下面几类问题。我按“现象、原因、解决思路”整理成表格遇到问题时可以直接对照排查。问题现象常见原因解决思路Codex CLI 提示 unable to locate the codex cli binary只安装了编辑器插件或 GUI没安装命令行二进制或 PATH 未配置重新安装 CLI确认入口脚本路径必要时在配置中指定 codex_cli_pathClaude Code 提示某模型名不被当前版本识别Claude Code 版本较旧或模型名不在当前支持列表升级工具版本检查模型名拼写重点确认当前版本支持的模型范围Agent 提示 the agent execution provider did not respond in time模型服务响应超时或本地模型网关转发不稳定检查模型服务状态确认网络连通性适当加大请求超时时间本地网关转发时报 codex endpoint 相关错误本地配置的 API 转发地址有误或鉴权信息过期检查 base URL、API Key、鉴权头确认 endpoint 路径与转发服务匹配技能一直没有被自动加载description 触发词不明确或技能目录位置不对优化 description加入明确触发词检查目录是否放在约定位置同一个技能在 Claude Code 生效在 Codex 不生效两个工具的技能加载机制不同在 AGENTS.md 中显式声明技能路径和读取时机脚本执行成功但报告格式混乱技能正文没有给出明确的输出模板要求在 SKILL.md 中引用模板文件并要求 Agent 严格按模板输出排查技能问题时有一个简单有效的思路先让 Agent“显式读取”技能文件绕过自动加载机制。如果显式读取后技能仍然不生效说明问题出在技能内容如果显式读取生效但自动加载不生效说明问题出在 description 或目录位置。另外注意不要把所有问题都归咎于技能本身。有时候 Agent 已经正确加载了技能但因为模型上下文限制导致步骤执行到一半“忘了”规则。这时可以把技能正文拆得更短把详细规则移到资源文件中降低上下文占用。7. 最佳实践与工程建议7.1 技能设计的工程规范从工程角度看技能设计应该遵循“小而专”的原则。一个技能只解决一个领域的问题不要试图写一个“万能技能”。如果技能描述里出现“以及其他相关任务”说明职责边界不够清晰。description的写作也很有讲究。建议采用“功能说明 使用场景 触发词”的格式。比如对 Python 项目进行安全审查检查危险函数、硬编码密钥和依赖风险。当用户要求安全检查、审计代码、审查依赖时使用。这样的描述比“检查代码问题”清晰得多。技能内的脚本要健壮。务必处理文件不存在、编码错误、权限不足等边界情况。脚本的输出要易于被 Agent 解析尽量使用结构化格式比如每行一条问题、带严重级别标记。7.2 安全与权限边界Agent 本身就拥有执行命令、修改文件的权限给 Agent 添加技能后权限面会进一步扩大。这里必须强调几个安全原则。第一最小权限原则。技能只申请完成任务所需的最小权限。比如代码审查技能只需要读取代码和运行静态扫描就不应该包含修改代码或执行部署的指令。第二危险操作确认机制。如果技能涉及删除文件、修改生产环境、执行外部命令必须在SKILL.md中明确要求 Agent 先向用户确认不能直接执行。第三密钥管理。不要把 API Key、数据库密码写进技能包或脚本中。技能包通常要进版本库一旦密钥提交就会永久留在 Git 历史里。所有敏感信息都应通过环境变量或密钥管理服务注入。第四第三方依赖风险。如果技能包需要安装 Python 包或 Node 模块要锁定版本避免供应链攻击。团队共享的技能仓库应该做依赖检查。7.3 性能与上下文控制技能设计直接影响 Agent 的响应速度和上下文占用。建议从三个方面控制。一是控制技能正文长度。SKILL.md正文尽量控制在几百行以内超长内容放到资源文件中。Agent 只有在需要时才会读取资源文件不会一次性占用大量上下文。二是控制资源文件粒度。规则文件不要做成一个几千行的大文件可以拆成多个主题小文件。比如安全规则、代码风格、测试规范分别存放Agent 只读取与当前任务相关的部分。三是控制自动加载范围。技能目录里的技能不要太多每个技能的 description 要写清楚边界避免 Agent 在简单任务中反复尝试加载多个技能拖慢响应速度。7.4 生产环境落地建议真正把 Agent Skills 用到生产环境还需要关注可观测性和灰度发布。在可观测性方面建议在技能执行关键节点打印日志比如“开始扫描”“扫描完成发现 3 个问题”“报告已生成”。这样当 Agent 执行异常时你能知道是技能加载失败、脚本执行失败还是模型输出格式问题。在灰度发布方面新技能或技能大版本更新时不要直接在核心项目上全量替换。可以先在非关键目录验证技能输出确认无误后再让 Agent 在正式项目中自动加载。还有一点值得注意Agent 的输出并不总是稳定技能只是降低了不确定性并不能完全消除。因此对于影响生产环境的操作仍然要保留人工审批环节。8. 总结从“会用 AI 对话”到“开发 Agent 技能”跨越的不仅是代码能力更是对“AI 如何工作”的理解。Agent 负责规划与执行Agent Skills 负责提供专业流程与领域知识两者组合才能让 AI 从“会聊天”变成“会干活”。本文从概念和原理出发拆解了 Agent Skills 的目录结构、SKILL.md 设计、渐进式披露等核心内容然后通过一个完整的“代码审查技能”示例演示了如何编写技能包、接入 Claude Code 与 Codex并验证执行效果最后整理了常见问题与工程落地建议。下一步你可以从这几个方向继续深入把代码审查技能扩展成支持多语言、多规则引擎的完整方案为团队搭建统一的技能仓库和版本发布流程尝试在不同 Agent 框架中复用同一套技能包结合 MCP 工具让技能不仅能分析代码还能直接调用外部系统。动手创建一个自己的技能包哪怕只是把日常工作流程固化成一个简单的SKILL.md你也会发现自己对 Agent 开发的掌控力提升了一大截。如果本文对你有帮助建议收藏备用后续做 Agent 技能体系时可以直接对照实践。