现在很多开发者已经过了“会用 AI”的阶段遇到报错知道贴给大模型写函数知道让它先给一版甚至能熟练地把一段长对话沉淀成提示词。但真正到了工程化的时候还是会觉得不对劲——同一个 AI 助手上次教它的流程这次它又忘了同事分享的一套“好用的提示词”到自己手里效果立刻打折项目组想让 AI 承担更复杂的任务却只能一遍遍把上下文塞进对话框里。这种拧巴感的根源在于提示词是“一次性”的它活在对话里离开对话就消失。而 Agent 想要真正成为团队生产力需要的是一套能被反复调用、能被版本管理、能被别人复用的“技能资产”。这正是 Agent Skills 存在的意义。这篇文章我会把 Agent Skills 从概念到落地讲透并且结合 Claude Code 和 Codex 这两款目前最主流的 Agent 编程工具带你做一个完整的日志分析 Skill。读完你会发现从“会用 AI”到“会开发 Agent”中间差的不是模型而是一套沉淀技能的方法。1. 为什么 Agent Skills 正在改变 AI 开发方式很多人对 Agent 的理解是“能自己规划步骤、调用工具的 AI”。这个理解没有错但不够完整。一个只会“临场发挥”的 Agent能力上限完全取决于模型本身而一个拥有技能库的 Agent能力边界是由你定义和扩展的。打个比方大模型像一个新入职的实习生底子很好但什么都不懂提示词像是你在工位上临时给他交代任务说完就忘而 Agent Skills 像是一本带 SOP、带脚本、带模板的岗位手册他拿到就能按标准流程干活而且这次学会的下次还会用。这个差异在真实开发中非常明显。假设你要让 AI 帮你做代码审查没有 Skill 时你每次都要把“审查哪些目录、关注哪几类问题、输出什么格式的报告”完整描述一遍模型的表现会随上下文长度、对话轮数波动同一个项目上午和下午的结果可能完全不一样。有 Skill 时你只需要说一句“用 code-review 技能审查本次改动”Agent 会自己加载 SKILL.md按里面定义的步骤逐项检查最后按约定格式输出报告。Claude Code 和 Codex 之所以值得一起学是因为它们代表了当前 Agent 编程工具的两个关键方向Claude Code 官方支持 SKILL.md 技能体系Codex 则用项目指令文件如 AGENTS.md来约束 Agent 行为。学懂这两套机制你再去看其他 Agent 框架时会非常快因为它们解决的是同一个问题怎么让 Agent 稳定地、可复用地完成复杂任务。2. 核心概念Agent、Agent Skills、Claude Code 与 Codex2.1 Agent 是什么它的运作模式发生了哪些变化Agent智能体不是一个新概念但在大模型时代它被重新定义了。传统的自动化程序是一套固定的 if-else 流程而大模型 Agent 则是在一个目标任务的驱动下自己决定“下一步做什么”——比如先查文档、再改代码、然后运行测试、最后根据测试结果决定是否继续修。这套模式的关键在于Agent 需要把一个大目标拆成若干小步骤并且在每个步骤中调用合适的工具。工具越多、越规范Agent 的能力就越强。但这同时也带来一个问题你不可能把团队的规则、项目的约束、业务的背景全部实时塞进每一轮对话里Agent 需要一套“离线知识”来支撑自己。2.2 Agent Skills让 Agent 拥有可复用的专业技能Agent Skills 本质上是一个目录化的技能包。一个典型 Skill 包含三部分SKILL.md 描述文件用 Markdown 写的技能说明包含这个技能是什么、适用于什么场景、使用步骤是什么脚本或模板文件可以被执行的 Python、Shell、JavaScript 脚本或者代码模板、配置模板参考资料需要给模型读取的知识文档、示例输出等。Skill 的动作机制是当用户请求与某个技能描述匹配时Agent 会读取对应的 SKILL.md按照里面的步骤执行。如果 SKILL.md 指定了要运行某个脚本Agent 会调用命令行来执行脚本再把结果结合上下文返回给用户。从架构上看Agent Skills 位于“提示词”和“独立应用”之间提示词零成本但一次一用无法管理无法复用Agent Skills需要少量目录和文件组织成本但可复用、可版本化、可团队共享独立应用功能完整但需要完整的工程开发、部署和界面成本不适合快速沉淀。2.3 Claude Code 与 SKILL.mdClaude Code 是 Anthropic 推出的命令行编程 Agent 工具它跑在终端里可以读项目代码、改文件、执行命令、跑测试并在这个过程中不断反思和修正。它对 Agent Skills 的支持非常直接在用户级目录或项目目录中放置.claude/skills/技能名/SKILL.mdClaude Code 就会将它识别为一个 Skill。当任务相关时模型会自动加载技能说明并执行。这种设计非常适合团队沉淀研发规范比如“数据库迁移规范”“前端组件审查清单”“日志分析流程”等。2.4 Codex 与项目指令文件Codex 是 OpenAI 推出的命令行编码 Agent定位和 Claude Code 类似可以自主完成代码阅读、修改、运行和提交等操作。Codex 目前主要用项目内的AGENTS.md或类似指令文件来定义项目级规则让 Agent 在进入项目时自动获取上下文团队也能把操作规范固定下来。从实践角度看Claude Code 的 Skill 机制偏向“技能库”适合沉淀相对独立的技能Codex 的指令文件偏向“项目规范”适合描述该项目特有的约定和流程。两者不是替代关系而是互补。这也是这篇文章把两者放在一起讲的原因——一个合格的 Agent 开发者最好两套机制都掌握。3. 环境准备与前置条件在开始写 Skill 之前先要把 Claude Code 和 Codex 运行起来。本节内容以最常用的 npm 安装方式为例版本请以实际安装时的官方最新版本为准不写死版本号是为了避免文章过期。3.1 前置环境检查两个工具都依赖 Node.js 运行环境。建议先确认本机的 Node.js 和 npm 版本node -v npm -v如果还没有 Node.js需要先去 Node.js 官网下载 LTS 版本安装。这一步不复杂但直接影响后面所有命令建议先确认能正常输出版本号再继续。3.2 安装 Claude Code在终端中执行全局安装npm install -g anthropic-ai/claude-code安装完成后检查命令是否可用claude --version首次运行claude时按提示登录或配置 API Key。如果你使用 API 方式通常只需要设置环境变量export ANTHROPIC_API_KEY你的API Key不同操作系统的环境变量配置方式不同Windows 下可以用setx或系统环境变量面板macOS/Linux 下可以写入~/.bashrc或~/.zshrc中。3.3 安装 Codex CLI同样使用 npm 全局安装npm install -g openai/codex验证安装codex --versionCodex 同样需要配置 API 凭据常见做法是设置OPENAI_API_KEY环境变量export OPENAI_API_KEY你的API Key有些团队会把 Codex 接到内部统一的模型网关或兼容接口上这种情况下你需要修改 Codex 的配置文件指定模型名和接口地址。模型名、接口地址都以你所在团队的接入文档为准不要照抄网上的任何一条命令。3.4 验证安装是否成功安装完成后在最简单的测试目录里分别运行claudecodex进入交互界面后随便问一句“请介绍一下当前目录”如果 Agent 能正常响应说明环境就绪。这一步做的过程中最常见的两个现象是命令找不到或者模型名不识别。前者通常是 npm 全局目录没加到 PATH后者通常是配置的模型名与当前 CLI 版本不匹配。第 7 章会详细讲这两类问题的解法。4. 核心流程如何设计一个可复用的 Agent Skill环境就绪后真正需要思考的是什么样的任务应该沉淀成 Skill设计 Skill 时要考虑哪些因素。这一节讲清思路下一节再给完整代码。4.1 判断一个任务是否值得做成 Skill不是所有任务都应做 Skill。如果一个任务“一次问一次答”就能完成做成 Skill 反而增加成本。建议用下面这个检查清单来判断这个任务是否包含 3 个以上固定步骤是否每次执行都需要相同的命令、脚本或模板输出格式是否要求稳定比如必须输出 Markdown 报告这个任务是否会被团队多个人反复使用是否有一些只有团队才知道的规则需要强约束。如果命中 3 条以上就值得做成 Skill。如果只命中一两条先用普通提示词解决即可。过早抽象和过度设计同样是工程问题“够用就好”在 Agent 技能体系里同样成立。4.2 Skill 设计的三要素一个高质量 Skill至少要包含触发层、执行层、输出层三层设计触发层解决“Agent 什么时候该用这个技能”。这要求 SKILL.md 里的 description 写得足够精确把核心场景词和同义词都覆盖到。比如一个日志分析技能如果 description 只写“分析日志”那么当用户说“帮我看看 error.log 里报了什么错”时模型可能不会立刻联想到这个技能但如果 description 写成“分析应用日志、排查报错、统计异常分布当用户要求分析日志、查看报错、整理日志报告时使用”触发概率会显著提高。执行层解决“Agent 具体要做什么”。这里要给出明确步骤比如先找日志文件再运行脚本再读取输出。步骤要足够细但又不能把模型当成没有推理能力的机器要给一定的判断空间。输出层解决“结果如何交付”。建议在 SKILL.md 中约定输出格式例如统一输出 Markdown 报告、包含错误统计表格和高频异常列表。固定格式的好处是报告可以直接贴进文档、发给同事也能被后续流程继续解析。4.3 Skill 的存放位置Claude Code 支持两类 Skill 存放位置用户级~/.claude/skills/技能名/所有项目都能用项目级项目根目录/.claude/skills/技能名/只对当前项目生效。推荐原则是团队通用规范放用户级或独立共享目录项目特有逻辑放项目级。比如“日志分析方法论”可以放用户级“某订单系统的日志字段说明”应该放项目级。这样可以避免“无关技能打扰相关任务”的噪音。对于 Codex项目规则通常通过AGENTS.md文件表达。你可以把 Skill 的核心步骤写成 Codex 能读取的指令片段也可以在后续示例中看到两套机制的共同逻辑。5. 完整示例打造一个日志分析 Agent Skill这一节的例子是一个日志分析技能log-analyzer。选择日志分析是因为它足够常见、逻辑清晰而且脚本完全使用 Python 标准库不需要额外安装第三方依赖任何开发环境都可以跑通。5.1 创建目录结构在用户级 skills 目录下创建mkdir -p ~/.claude/skills/log-analyzer cd ~/.claude/skills/log-analyzer如果只想对单个项目生效就把目录放在项目的.claude/skills/下。下面所有内容均以用户级目录为例。5.2 编写 SKILL.md 描述文件--- name: log-analyzer description: 分析应用日志文件统计 ERROR / WARN / INFO 级别分布定位高频错误并生成 Markdown 报告。当用户要求分析日志、排查报错、统计异常、整理日志报告、查看 error 信息时使用。 --- # Log Analyzer ## 适用场景 - 分析单个或多个日志文件 - 统计日志级别分布 - 定位高频异常和错误信息 - 生成可分享的 Markdown 报告 ## 执行步骤 1. 确认日志文件路径如果用户未指定则先查找当前项目中常见的 logs/、*.log 文件。 2. 运行 python3 log_analyzer.py 日志文件路径。 3. 读取脚本输出的 Markdown 报告并转述给用户。 4. 如果脚本报错先确认日志文件是否存在、是否有读取权限。 ## 输出格式 - 报告中必须包含总日志条数、各级别数量、Top 5 错误信息、最近 10 条 ERROR 时间点。 - 报告使用 Markdown 表格展示统计结果。这段文件有两个作用给模型看的是描述和步骤给 Agent 执行的是“运行这个脚本”的指令。这里有个设计细节不要把所有逻辑都写进 SKILL.md而是让脚本负责计算模型负责解读。这样既减少模型误算也方便你在脚本里写更复杂的逻辑。5.3 编写 Python 分析脚本在同一个目录下新建log_analyzer.py#!/usr/bin/env python3 日志分析脚本统计日志级别分布定位高频错误并输出 Markdown 报告。 import re import sys import collections from pathlib import Path LEVEL_PATTERN re.compile(r\b(ERROR|WARN|INFO|DEBUG|FATAL)\b) TIME_PATTERN re.compile( r(\d{4}-\d{2}-\d{2}[ T]\d{2}:\d{2}:\d{2}) ) def parse_log(file_path: Path) - list: records [] with open(file_path, r, encodingutf-8, errorsignore) as f: for line in f: level_match LEVEL_PATTERN.search(line) time_match TIME_PATTERN.search(line) records.append({ level: level_match.group(1) if level_match else UNKNOWN, time: time_match.group(1) if time_match else , message: line.strip(), }) return records def build_report(records: list) - str: total len(records) level_counter collections.Counter(r[level] for r in records) errors [r for r in records if r[level] in (ERROR, FATAL)] error_count collections.Counter( re.sub(r\s, , r[message][:120]) for r in errors ) recent_errors [ r for r in errors if r[time] ][-10:] lines [] lines.append(## 日志分析报告) lines.append() lines.append(f- 总日志条数{total}) lines.append() lines.append(### 日志级别分布) lines.append() lines.append(| 级别 | 数量 |) lines.append(| --- | --- |) for level in sorted(level_counter, keylambda x: -level_counter[x]): lines.append(f| {level} | {level_counter[level]} |) lines.append() lines.append(### Top 5 错误信息) lines.append() for msg, cnt in error_count.most_common(5): clean_msg msg if len(msg) 80 else msg[:80] ... lines.append(f- {clean_msg}{cnt} 次) lines.append() lines.append(### 最近 10 条 ERROR 记录时间点) lines.append() for r in recent_errors: lines.append(f- {r[time]} {r[message][:100]}) return \n.join(lines) def main() - None: if len(sys.argv) 2: print(用法: python3 log_analyzer.py 日志文件路径) sys.exit(1) file_path Path(sys.argv[1]) if not file_path.exists(): print(f错误: 文件不存在 {file_path}, filesys.stderr) sys.exit(1) records parse_log(file_path) report build_report(records) print(report) if __name__ __main__: main()这个脚本的逻辑分为三块解析日志、统计信息、生成报告。LEVEL_PATTERN和TIME_PATTERN是正则表达式分别用于从日志行中提取日志级别和时间戳build_report函数负责把统计数据组装成 Markdown 报告。这里要特别说明一个设计选择脚本只做“读日志 统计 输出 Markdown”不尝试判断错误原因、不给出修复建议。因为“判断错误原因”是模型该做的事脚本只需要提供准确的统计数据。这样分工脚本更容易测试模型也能基于可靠的数据做推理。5.4 在 Claude Code 中使用这个 Skill回到终端进入任意包含日志文件的项目目录运行claude然后输入用 log-analyzer 分析一下 error.log看看最近有哪些高频报错如果一切正常Claude Code 会读取~/.claude/skills/log-analyzer/SKILL.md识别出这是一个日志分析技能然后定位到error.log文件调用python3 log_analyzer.py error.log最后把 Markdown 报告呈现给你。判断 Skill 是否被正确触发最简单的办法是看 Claude 是否执行了“运行脚本”这个动作而不是直接对着日志文件“硬读”。如果它还在用模型能力逐行读日志说明 SKILL.md 的 description 可能没有覆盖到你的指令需要调整触发描述。5.5 把同一套思路应用到 Codex在 Codex 中更常见的做法是把项目约定写进AGENTS.md。这个文件的定位类似一个“轻量级项目 Skill”当 Agent 进入项目时会自动读取。假设你要让 Codex 在做代码提交前执行固定的检查流程可以创建一个AGENTS.md# 项目级 Agent 指令 ## 代码提交前检查 在提交代码前必须完成以下步骤 1. 运行 python3 -m pytest tests/确保所有测试通过。 2. 运行 python3 -m flake8 src/确保代码风格符合规范。 3. 检查 git status确认没有误提交的临时文件。 ## 日志处理约定 - 日志使用 logging 模块输出格式为 时间 级别 消息。 - 排查线上问题时优先使用 log-analyzer 脚本生成报告。Codex 读取该文件后会在涉及代码提交、日志排查等任务时自动遵循这些规则。这里想强调一个观点Claude Code 的 SKILL.md 和 Codex 的 AGENTS.md 形式不同但底层逻辑一致——都是通过项目内或用户目录内的静态文件把“可复用的操作规范”注入到 Agent 的每次任务中。理解这一点后你在任何一个新工具里都能快速迁移这套方法论。6. 运行结果与效果验证Skill 做出来不是终点能稳定复现才是。下面给出验证流程和预期结果。6.1 准备测试日志先创建一个简单的测试日志文件。这里不要实际生成一堆无意义日志而是模拟一个真实片段方便观察统计结果cat sample.log EOF 2025-06-01 10:00:01 INFO 用户登录成功 user_id1001 2025-06-01 10:00:05 ERROR 数据库连接超时 hostdb-01 2025-06-01 10:00:07 WARN 缓存命中率下降 cache_hit0.82 2025-06-01 10:00:09 ERROR 数据库连接超时 hostdb-02 2025-06-01 10:00:12 INFO 订单创建成功 order_id90001 2025-06-01 10:00:15 ERROR 第三方接口返回 500 apipay 2025-06-01 10:00:20 FATAL 未捕获异常 NullPointerException 2025-06-01 10:00:22 WARN 队列积压消息数120 EOF6.2 直接运行脚本验证不经过 Agent先直接验证脚本本身python3 log_analyzer.py sample.log预期输出类似## 日志分析报告 - 总日志条数8 ### 日志级别分布 | 级别 | 数量 | | --- | --- | | ERROR | 3 | | INFO | 2 | | WARN | 2 | | FATAL | 1 | ### Top 5 错误信息 - 2025-06-01 10:00:05 ERROR 数据库连接超时 hostdb-011 次 - 2025-06-01 10:00:09 ERROR 数据库连接超时 hostdb-021 次 - 2025-06-01 10:00:15 ERROR 第三方接口返回 500 apipay1 次 - 2025-06-01 10:00:20 FATAL 未捕获异常 NullPointerException1 次 ### 最近 10 条 ERROR 记录时间点 - 2025-06-01 10:00:05 2025-06-01 10:00:05 ERROR 数据库连接超时 hostdb-01 ...如果脚本能直接输出这个报告说明统计逻辑正确如果输出不对先回到脚本本身排查不要急着怀疑 Agent。6.3 通过 Claude Code 验证 Skill 触发脚本验证通过后再进入 Claude Code 验证整体链路。启动后输入同样的指令重点观察两个信号第一Claude 是否真的执行了python3 log_analyzer.py sample.log这条命令。你可以从 Claude Code 的执行日志中看到它调用了哪些工具。如果它没有运行脚本而是在“假装分析”或自己脑补日志内容说明 Skill 没有被正确加载。第二输出报告是否和直接运行脚本的结果一致。如果中间出现了脚本里不存在的数据优先怀疑 Claude 在“自由发挥”。这时候应该回到 SKILL.md把“必须运行脚本获取统计结果”写得更强硬一些比如明确写“禁止自行统计必须以脚本输出为准”。6.4 失败时的第一排查顺序如果整个过程没有按预期跑通不要先翻配置文件按下面顺序排查脚本本身能不能跑直接执行python3 log_analyzer.py sample.log看输出Skill 目录位置对不对确认路径是~/.claude/skills/log-analyzer/SKILL.md模型能不能读到 SKILL.md在 Claude Code 里问“当前有哪些 skill”或检查调试日志是否触发了正确的工具观察 Claude 是否执行了脚本命令。7. 常见问题与排查思路在安装和使用 Claude Code、Codex 的过程中有一些错误非常高频。下面整理成一张排查表遇到问题时可以直接对照。问题现象可能原因排查方式解决方案运行claude提示命令找不到npm 全局安装目录不在 PATH 中执行which claude或npm config get prefix将 npm 全局目录加入 PATH 后重开终端IDE 插件提示 unable to locate the codex cli binary插件找不到 codex 可执行文件执行which codex确认安装位置在插件设置中指定 codex 路径或确保 codex 已加入 PATH提示模型名不被当前 CLI 版本识别配置的模型名错误或 CLI 版本过旧执行claude --version/codex --version检查配置文件模型名修正为账号实际可用的模型名或升级 CLI 到最新版本Skill 始终没有被模型触发SKILL.md 的 description 写得过于宽泛查看调试日志确认模型是否读取了 SKILL.md在 description 中补充更明确的触发词和同义场景执行python3脚本时报文件不存在工作目录与日志文件路径不一致执行pwd查看当前目录确认日志路径在 SKILL.md 中写明“先定位日志文件再执行脚本”或要求用户提供绝对路径网络请求失败Agent 无法调用远程接口本地网络配置异常或请求被转发到错误地址查看 CLI 详细日志确认请求目标和响应错误检查本机网络配置确认接口地址正确确保使用的是合法、已授权的服务Codex 执行任务时不断重复同一操作项目指令文件中的步骤描述不清晰检查 AGENTS.md 是否给出了充分的终止条件为每个步骤写清“完成后继续/完成后停止”的判定条件这里重点说两个最容易让新人卡住、又最容易被忽略的问题。第一个是“模型名不识别”。很多用户在网上看到别人配置了某个模型名就随手复制到自己配置里但不同账号、不同地区、不同授权范围能用的模型不一定相同。遇到这类错误先看 CLI 版本再看账号实际可用模型列表不要盲目套用网上命令。第二个是“Skill 没触发但又不报错”。这是最隐蔽的问题Claude Code 启动正常命令也能执行但它就是不用你的 Skill而是自己硬读日志、硬编报告。这种情况几乎都是 SKILL.md 的 description 没有和用户指令匹配上。解决办法是在 description 里多写几个“用户可能怎么说”覆盖口语化和缩写场景。8. 最佳实践与工程建议到这里你已经能跑通一个完整的 Agent Skill。但要在真实项目和团队协作中稳定使用还需要注意下面几个工程层面的问题。8.1 skill 描述的写法决定触发率SKILL.md 的 description 是整个技能的门面。写得越具体模型越容易在需要的时候找到它。建议采用“场景 行为 同义词”的结构先说明这个技能覆盖哪些场景再说明它会做什么最后补充用户的几种典型说法。这样的描述看起来啰嗦但触发率会明显提升。8.2 从“提示词”渐进演化为 Skill不要一开始就追求完美设计。更稳妥的做法是先在对话里把流程跑通把每一步的输入输出记录下来确认流程稳定后再固化成 SKILL.md 和脚本最后在团队里试用并迭代。一次只改一个变量避免“流程变了但说不清是哪个环节出了问题”。8.3 脚本要做到幂等、无副作用、可重复执行Skill 里带的脚本应该尽量是“只读型”或“幂等型”的同样的输入执行两次结果一致不偷偷修改源文件不依赖未声明的外部状态。比如日志分析脚本只读取日志、输出报告就是一个好的范例。如果脚本有副作用比如会更新数据库、删除临时文件必须在 SKILL.md 里显式声明并让用户确认后再执行。8.4 安全边界与权限控制这是所有 Agent 工具都绕不开的问题。Agent 拥有执行命令的能力这既是它强大的原因也是它危险的原因。请务必遵守几条底线最小权限原则以普通用户身份运行不要用 root 或管理员权限启动 Agent危险操作确认涉及删除、覆盖、批量修改、线上变更等操作时先让 Agent 输出具体命令确认后再执行测试先行任何新的 Skill 先在测试目录、测试环境跑通再放到生产环境使用审计留痕记录 Agent 执行过的命令和输出便于回溯问题敏感信息保护不要把密钥、Token、数据库密码写在 SKILL.md 或 AGENTS.md 中必要时应通过环境变量注入。8.5 团队共享与版本管理Skill 本质上是代码资产应该像代码一样被管理。推荐把一个共享的 skills 目录放进独立的 Git 仓库团队成员通过 clone 或子模块挂载到本地。每次修改都要走 review 流程重点看描述是否准确、脚本是否安全、输出格式是否兼容。这样团队里每个人的 Agent 行为会越来越一致长期看能显著降低协作成本。8.6 定期清理和审查时间一长每个开发者本地都会积累大量 Skill。有些技能可能已经被模型能力覆盖有些脚本可能依赖了已废弃的工具。建议每季度做一次技能审查删除长期未使用的技能合并功能重复的技能更新脚本依赖。技能库和代码库一样需要持续维护否则会变成新的技术债。9. 总结与后续方向这篇文章的核心内容是把 Agent 从“能用”变成“会用”关键不是囤更多提示词而是学会用 Agent Skills 的方式沉淀能力。我们从概念上解释了 Agent 和 Skill 的关系动手做了一个日志分析 Skill并在 Claude Code 和 Codex 两套工具中分别演示了技能落地的思路。你如果完整走了一遍现在应该具备自己设计 Skill、排错和团队推广的能力。下一步可以往三个方向深入第一把日志分析这个例子替换成你们团队真正的痛点场景比如代码规范检查、发布前检查、数据质量审查第二研究 Agent 如何接入更多外部工具比如通过 MCP 连接内部系统让 Skill 不只是脚本而是能操作真实业务系统的能力第三建立一套团队级的技能治理机制让 Skill 的命名、描述、脚本规范都变成团队共识。最后提醒一句Skill 是手段不是目的。别为了让 Agent “看起来会很多东西”而堆砌技能而要从真实任务的重复频率和稳定需求出发。先把一两个高频任务做成高质量 Skill跑顺之后再逐步扩展。这个节奏比你一次性铺开二十个半成品技能要稳妥得多。 Agent Skills 实战：用 Claude Code 和 Codex 构建可复用技能资产
现在很多开发者已经过了“会用 AI”的阶段遇到报错知道贴给大模型写函数知道让它先给一版甚至能熟练地把一段长对话沉淀成提示词。但真正到了工程化的时候还是会觉得不对劲——同一个 AI 助手上次教它的流程这次它又忘了同事分享的一套“好用的提示词”到自己手里效果立刻打折项目组想让 AI 承担更复杂的任务却只能一遍遍把上下文塞进对话框里。这种拧巴感的根源在于提示词是“一次性”的它活在对话里离开对话就消失。而 Agent 想要真正成为团队生产力需要的是一套能被反复调用、能被版本管理、能被别人复用的“技能资产”。这正是 Agent Skills 存在的意义。这篇文章我会把 Agent Skills 从概念到落地讲透并且结合 Claude Code 和 Codex 这两款目前最主流的 Agent 编程工具带你做一个完整的日志分析 Skill。读完你会发现从“会用 AI”到“会开发 Agent”中间差的不是模型而是一套沉淀技能的方法。1. 为什么 Agent Skills 正在改变 AI 开发方式很多人对 Agent 的理解是“能自己规划步骤、调用工具的 AI”。这个理解没有错但不够完整。一个只会“临场发挥”的 Agent能力上限完全取决于模型本身而一个拥有技能库的 Agent能力边界是由你定义和扩展的。打个比方大模型像一个新入职的实习生底子很好但什么都不懂提示词像是你在工位上临时给他交代任务说完就忘而 Agent Skills 像是一本带 SOP、带脚本、带模板的岗位手册他拿到就能按标准流程干活而且这次学会的下次还会用。这个差异在真实开发中非常明显。假设你要让 AI 帮你做代码审查没有 Skill 时你每次都要把“审查哪些目录、关注哪几类问题、输出什么格式的报告”完整描述一遍模型的表现会随上下文长度、对话轮数波动同一个项目上午和下午的结果可能完全不一样。有 Skill 时你只需要说一句“用 code-review 技能审查本次改动”Agent 会自己加载 SKILL.md按里面定义的步骤逐项检查最后按约定格式输出报告。Claude Code 和 Codex 之所以值得一起学是因为它们代表了当前 Agent 编程工具的两个关键方向Claude Code 官方支持 SKILL.md 技能体系Codex 则用项目指令文件如 AGENTS.md来约束 Agent 行为。学懂这两套机制你再去看其他 Agent 框架时会非常快因为它们解决的是同一个问题怎么让 Agent 稳定地、可复用地完成复杂任务。2. 核心概念Agent、Agent Skills、Claude Code 与 Codex2.1 Agent 是什么它的运作模式发生了哪些变化Agent智能体不是一个新概念但在大模型时代它被重新定义了。传统的自动化程序是一套固定的 if-else 流程而大模型 Agent 则是在一个目标任务的驱动下自己决定“下一步做什么”——比如先查文档、再改代码、然后运行测试、最后根据测试结果决定是否继续修。这套模式的关键在于Agent 需要把一个大目标拆成若干小步骤并且在每个步骤中调用合适的工具。工具越多、越规范Agent 的能力就越强。但这同时也带来一个问题你不可能把团队的规则、项目的约束、业务的背景全部实时塞进每一轮对话里Agent 需要一套“离线知识”来支撑自己。2.2 Agent Skills让 Agent 拥有可复用的专业技能Agent Skills 本质上是一个目录化的技能包。一个典型 Skill 包含三部分SKILL.md 描述文件用 Markdown 写的技能说明包含这个技能是什么、适用于什么场景、使用步骤是什么脚本或模板文件可以被执行的 Python、Shell、JavaScript 脚本或者代码模板、配置模板参考资料需要给模型读取的知识文档、示例输出等。Skill 的动作机制是当用户请求与某个技能描述匹配时Agent 会读取对应的 SKILL.md按照里面的步骤执行。如果 SKILL.md 指定了要运行某个脚本Agent 会调用命令行来执行脚本再把结果结合上下文返回给用户。从架构上看Agent Skills 位于“提示词”和“独立应用”之间提示词零成本但一次一用无法管理无法复用Agent Skills需要少量目录和文件组织成本但可复用、可版本化、可团队共享独立应用功能完整但需要完整的工程开发、部署和界面成本不适合快速沉淀。2.3 Claude Code 与 SKILL.mdClaude Code 是 Anthropic 推出的命令行编程 Agent 工具它跑在终端里可以读项目代码、改文件、执行命令、跑测试并在这个过程中不断反思和修正。它对 Agent Skills 的支持非常直接在用户级目录或项目目录中放置.claude/skills/技能名/SKILL.mdClaude Code 就会将它识别为一个 Skill。当任务相关时模型会自动加载技能说明并执行。这种设计非常适合团队沉淀研发规范比如“数据库迁移规范”“前端组件审查清单”“日志分析流程”等。2.4 Codex 与项目指令文件Codex 是 OpenAI 推出的命令行编码 Agent定位和 Claude Code 类似可以自主完成代码阅读、修改、运行和提交等操作。Codex 目前主要用项目内的AGENTS.md或类似指令文件来定义项目级规则让 Agent 在进入项目时自动获取上下文团队也能把操作规范固定下来。从实践角度看Claude Code 的 Skill 机制偏向“技能库”适合沉淀相对独立的技能Codex 的指令文件偏向“项目规范”适合描述该项目特有的约定和流程。两者不是替代关系而是互补。这也是这篇文章把两者放在一起讲的原因——一个合格的 Agent 开发者最好两套机制都掌握。3. 环境准备与前置条件在开始写 Skill 之前先要把 Claude Code 和 Codex 运行起来。本节内容以最常用的 npm 安装方式为例版本请以实际安装时的官方最新版本为准不写死版本号是为了避免文章过期。3.1 前置环境检查两个工具都依赖 Node.js 运行环境。建议先确认本机的 Node.js 和 npm 版本node -v npm -v如果还没有 Node.js需要先去 Node.js 官网下载 LTS 版本安装。这一步不复杂但直接影响后面所有命令建议先确认能正常输出版本号再继续。3.2 安装 Claude Code在终端中执行全局安装npm install -g anthropic-ai/claude-code安装完成后检查命令是否可用claude --version首次运行claude时按提示登录或配置 API Key。如果你使用 API 方式通常只需要设置环境变量export ANTHROPIC_API_KEY你的API Key不同操作系统的环境变量配置方式不同Windows 下可以用setx或系统环境变量面板macOS/Linux 下可以写入~/.bashrc或~/.zshrc中。3.3 安装 Codex CLI同样使用 npm 全局安装npm install -g openai/codex验证安装codex --versionCodex 同样需要配置 API 凭据常见做法是设置OPENAI_API_KEY环境变量export OPENAI_API_KEY你的API Key有些团队会把 Codex 接到内部统一的模型网关或兼容接口上这种情况下你需要修改 Codex 的配置文件指定模型名和接口地址。模型名、接口地址都以你所在团队的接入文档为准不要照抄网上的任何一条命令。3.4 验证安装是否成功安装完成后在最简单的测试目录里分别运行claudecodex进入交互界面后随便问一句“请介绍一下当前目录”如果 Agent 能正常响应说明环境就绪。这一步做的过程中最常见的两个现象是命令找不到或者模型名不识别。前者通常是 npm 全局目录没加到 PATH后者通常是配置的模型名与当前 CLI 版本不匹配。第 7 章会详细讲这两类问题的解法。4. 核心流程如何设计一个可复用的 Agent Skill环境就绪后真正需要思考的是什么样的任务应该沉淀成 Skill设计 Skill 时要考虑哪些因素。这一节讲清思路下一节再给完整代码。4.1 判断一个任务是否值得做成 Skill不是所有任务都应做 Skill。如果一个任务“一次问一次答”就能完成做成 Skill 反而增加成本。建议用下面这个检查清单来判断这个任务是否包含 3 个以上固定步骤是否每次执行都需要相同的命令、脚本或模板输出格式是否要求稳定比如必须输出 Markdown 报告这个任务是否会被团队多个人反复使用是否有一些只有团队才知道的规则需要强约束。如果命中 3 条以上就值得做成 Skill。如果只命中一两条先用普通提示词解决即可。过早抽象和过度设计同样是工程问题“够用就好”在 Agent 技能体系里同样成立。4.2 Skill 设计的三要素一个高质量 Skill至少要包含触发层、执行层、输出层三层设计触发层解决“Agent 什么时候该用这个技能”。这要求 SKILL.md 里的 description 写得足够精确把核心场景词和同义词都覆盖到。比如一个日志分析技能如果 description 只写“分析日志”那么当用户说“帮我看看 error.log 里报了什么错”时模型可能不会立刻联想到这个技能但如果 description 写成“分析应用日志、排查报错、统计异常分布当用户要求分析日志、查看报错、整理日志报告时使用”触发概率会显著提高。执行层解决“Agent 具体要做什么”。这里要给出明确步骤比如先找日志文件再运行脚本再读取输出。步骤要足够细但又不能把模型当成没有推理能力的机器要给一定的判断空间。输出层解决“结果如何交付”。建议在 SKILL.md 中约定输出格式例如统一输出 Markdown 报告、包含错误统计表格和高频异常列表。固定格式的好处是报告可以直接贴进文档、发给同事也能被后续流程继续解析。4.3 Skill 的存放位置Claude Code 支持两类 Skill 存放位置用户级~/.claude/skills/技能名/所有项目都能用项目级项目根目录/.claude/skills/技能名/只对当前项目生效。推荐原则是团队通用规范放用户级或独立共享目录项目特有逻辑放项目级。比如“日志分析方法论”可以放用户级“某订单系统的日志字段说明”应该放项目级。这样可以避免“无关技能打扰相关任务”的噪音。对于 Codex项目规则通常通过AGENTS.md文件表达。你可以把 Skill 的核心步骤写成 Codex 能读取的指令片段也可以在后续示例中看到两套机制的共同逻辑。5. 完整示例打造一个日志分析 Agent Skill这一节的例子是一个日志分析技能log-analyzer。选择日志分析是因为它足够常见、逻辑清晰而且脚本完全使用 Python 标准库不需要额外安装第三方依赖任何开发环境都可以跑通。5.1 创建目录结构在用户级 skills 目录下创建mkdir -p ~/.claude/skills/log-analyzer cd ~/.claude/skills/log-analyzer如果只想对单个项目生效就把目录放在项目的.claude/skills/下。下面所有内容均以用户级目录为例。5.2 编写 SKILL.md 描述文件--- name: log-analyzer description: 分析应用日志文件统计 ERROR / WARN / INFO 级别分布定位高频错误并生成 Markdown 报告。当用户要求分析日志、排查报错、统计异常、整理日志报告、查看 error 信息时使用。 --- # Log Analyzer ## 适用场景 - 分析单个或多个日志文件 - 统计日志级别分布 - 定位高频异常和错误信息 - 生成可分享的 Markdown 报告 ## 执行步骤 1. 确认日志文件路径如果用户未指定则先查找当前项目中常见的 logs/、*.log 文件。 2. 运行 python3 log_analyzer.py 日志文件路径。 3. 读取脚本输出的 Markdown 报告并转述给用户。 4. 如果脚本报错先确认日志文件是否存在、是否有读取权限。 ## 输出格式 - 报告中必须包含总日志条数、各级别数量、Top 5 错误信息、最近 10 条 ERROR 时间点。 - 报告使用 Markdown 表格展示统计结果。这段文件有两个作用给模型看的是描述和步骤给 Agent 执行的是“运行这个脚本”的指令。这里有个设计细节不要把所有逻辑都写进 SKILL.md而是让脚本负责计算模型负责解读。这样既减少模型误算也方便你在脚本里写更复杂的逻辑。5.3 编写 Python 分析脚本在同一个目录下新建log_analyzer.py#!/usr/bin/env python3 日志分析脚本统计日志级别分布定位高频错误并输出 Markdown 报告。 import re import sys import collections from pathlib import Path LEVEL_PATTERN re.compile(r\b(ERROR|WARN|INFO|DEBUG|FATAL)\b) TIME_PATTERN re.compile( r(\d{4}-\d{2}-\d{2}[ T]\d{2}:\d{2}:\d{2}) ) def parse_log(file_path: Path) - list: records [] with open(file_path, r, encodingutf-8, errorsignore) as f: for line in f: level_match LEVEL_PATTERN.search(line) time_match TIME_PATTERN.search(line) records.append({ level: level_match.group(1) if level_match else UNKNOWN, time: time_match.group(1) if time_match else , message: line.strip(), }) return records def build_report(records: list) - str: total len(records) level_counter collections.Counter(r[level] for r in records) errors [r for r in records if r[level] in (ERROR, FATAL)] error_count collections.Counter( re.sub(r\s, , r[message][:120]) for r in errors ) recent_errors [ r for r in errors if r[time] ][-10:] lines [] lines.append(## 日志分析报告) lines.append() lines.append(f- 总日志条数{total}) lines.append() lines.append(### 日志级别分布) lines.append() lines.append(| 级别 | 数量 |) lines.append(| --- | --- |) for level in sorted(level_counter, keylambda x: -level_counter[x]): lines.append(f| {level} | {level_counter[level]} |) lines.append() lines.append(### Top 5 错误信息) lines.append() for msg, cnt in error_count.most_common(5): clean_msg msg if len(msg) 80 else msg[:80] ... lines.append(f- {clean_msg}{cnt} 次) lines.append() lines.append(### 最近 10 条 ERROR 记录时间点) lines.append() for r in recent_errors: lines.append(f- {r[time]} {r[message][:100]}) return \n.join(lines) def main() - None: if len(sys.argv) 2: print(用法: python3 log_analyzer.py 日志文件路径) sys.exit(1) file_path Path(sys.argv[1]) if not file_path.exists(): print(f错误: 文件不存在 {file_path}, filesys.stderr) sys.exit(1) records parse_log(file_path) report build_report(records) print(report) if __name__ __main__: main()这个脚本的逻辑分为三块解析日志、统计信息、生成报告。LEVEL_PATTERN和TIME_PATTERN是正则表达式分别用于从日志行中提取日志级别和时间戳build_report函数负责把统计数据组装成 Markdown 报告。这里要特别说明一个设计选择脚本只做“读日志 统计 输出 Markdown”不尝试判断错误原因、不给出修复建议。因为“判断错误原因”是模型该做的事脚本只需要提供准确的统计数据。这样分工脚本更容易测试模型也能基于可靠的数据做推理。5.4 在 Claude Code 中使用这个 Skill回到终端进入任意包含日志文件的项目目录运行claude然后输入用 log-analyzer 分析一下 error.log看看最近有哪些高频报错如果一切正常Claude Code 会读取~/.claude/skills/log-analyzer/SKILL.md识别出这是一个日志分析技能然后定位到error.log文件调用python3 log_analyzer.py error.log最后把 Markdown 报告呈现给你。判断 Skill 是否被正确触发最简单的办法是看 Claude 是否执行了“运行脚本”这个动作而不是直接对着日志文件“硬读”。如果它还在用模型能力逐行读日志说明 SKILL.md 的 description 可能没有覆盖到你的指令需要调整触发描述。5.5 把同一套思路应用到 Codex在 Codex 中更常见的做法是把项目约定写进AGENTS.md。这个文件的定位类似一个“轻量级项目 Skill”当 Agent 进入项目时会自动读取。假设你要让 Codex 在做代码提交前执行固定的检查流程可以创建一个AGENTS.md# 项目级 Agent 指令 ## 代码提交前检查 在提交代码前必须完成以下步骤 1. 运行 python3 -m pytest tests/确保所有测试通过。 2. 运行 python3 -m flake8 src/确保代码风格符合规范。 3. 检查 git status确认没有误提交的临时文件。 ## 日志处理约定 - 日志使用 logging 模块输出格式为 时间 级别 消息。 - 排查线上问题时优先使用 log-analyzer 脚本生成报告。Codex 读取该文件后会在涉及代码提交、日志排查等任务时自动遵循这些规则。这里想强调一个观点Claude Code 的 SKILL.md 和 Codex 的 AGENTS.md 形式不同但底层逻辑一致——都是通过项目内或用户目录内的静态文件把“可复用的操作规范”注入到 Agent 的每次任务中。理解这一点后你在任何一个新工具里都能快速迁移这套方法论。6. 运行结果与效果验证Skill 做出来不是终点能稳定复现才是。下面给出验证流程和预期结果。6.1 准备测试日志先创建一个简单的测试日志文件。这里不要实际生成一堆无意义日志而是模拟一个真实片段方便观察统计结果cat sample.log EOF 2025-06-01 10:00:01 INFO 用户登录成功 user_id1001 2025-06-01 10:00:05 ERROR 数据库连接超时 hostdb-01 2025-06-01 10:00:07 WARN 缓存命中率下降 cache_hit0.82 2025-06-01 10:00:09 ERROR 数据库连接超时 hostdb-02 2025-06-01 10:00:12 INFO 订单创建成功 order_id90001 2025-06-01 10:00:15 ERROR 第三方接口返回 500 apipay 2025-06-01 10:00:20 FATAL 未捕获异常 NullPointerException 2025-06-01 10:00:22 WARN 队列积压消息数120 EOF6.2 直接运行脚本验证不经过 Agent先直接验证脚本本身python3 log_analyzer.py sample.log预期输出类似## 日志分析报告 - 总日志条数8 ### 日志级别分布 | 级别 | 数量 | | --- | --- | | ERROR | 3 | | INFO | 2 | | WARN | 2 | | FATAL | 1 | ### Top 5 错误信息 - 2025-06-01 10:00:05 ERROR 数据库连接超时 hostdb-011 次 - 2025-06-01 10:00:09 ERROR 数据库连接超时 hostdb-021 次 - 2025-06-01 10:00:15 ERROR 第三方接口返回 500 apipay1 次 - 2025-06-01 10:00:20 FATAL 未捕获异常 NullPointerException1 次 ### 最近 10 条 ERROR 记录时间点 - 2025-06-01 10:00:05 2025-06-01 10:00:05 ERROR 数据库连接超时 hostdb-01 ...如果脚本能直接输出这个报告说明统计逻辑正确如果输出不对先回到脚本本身排查不要急着怀疑 Agent。6.3 通过 Claude Code 验证 Skill 触发脚本验证通过后再进入 Claude Code 验证整体链路。启动后输入同样的指令重点观察两个信号第一Claude 是否真的执行了python3 log_analyzer.py sample.log这条命令。你可以从 Claude Code 的执行日志中看到它调用了哪些工具。如果它没有运行脚本而是在“假装分析”或自己脑补日志内容说明 Skill 没有被正确加载。第二输出报告是否和直接运行脚本的结果一致。如果中间出现了脚本里不存在的数据优先怀疑 Claude 在“自由发挥”。这时候应该回到 SKILL.md把“必须运行脚本获取统计结果”写得更强硬一些比如明确写“禁止自行统计必须以脚本输出为准”。6.4 失败时的第一排查顺序如果整个过程没有按预期跑通不要先翻配置文件按下面顺序排查脚本本身能不能跑直接执行python3 log_analyzer.py sample.log看输出Skill 目录位置对不对确认路径是~/.claude/skills/log-analyzer/SKILL.md模型能不能读到 SKILL.md在 Claude Code 里问“当前有哪些 skill”或检查调试日志是否触发了正确的工具观察 Claude 是否执行了脚本命令。7. 常见问题与排查思路在安装和使用 Claude Code、Codex 的过程中有一些错误非常高频。下面整理成一张排查表遇到问题时可以直接对照。问题现象可能原因排查方式解决方案运行claude提示命令找不到npm 全局安装目录不在 PATH 中执行which claude或npm config get prefix将 npm 全局目录加入 PATH 后重开终端IDE 插件提示 unable to locate the codex cli binary插件找不到 codex 可执行文件执行which codex确认安装位置在插件设置中指定 codex 路径或确保 codex 已加入 PATH提示模型名不被当前 CLI 版本识别配置的模型名错误或 CLI 版本过旧执行claude --version/codex --version检查配置文件模型名修正为账号实际可用的模型名或升级 CLI 到最新版本Skill 始终没有被模型触发SKILL.md 的 description 写得过于宽泛查看调试日志确认模型是否读取了 SKILL.md在 description 中补充更明确的触发词和同义场景执行python3脚本时报文件不存在工作目录与日志文件路径不一致执行pwd查看当前目录确认日志路径在 SKILL.md 中写明“先定位日志文件再执行脚本”或要求用户提供绝对路径网络请求失败Agent 无法调用远程接口本地网络配置异常或请求被转发到错误地址查看 CLI 详细日志确认请求目标和响应错误检查本机网络配置确认接口地址正确确保使用的是合法、已授权的服务Codex 执行任务时不断重复同一操作项目指令文件中的步骤描述不清晰检查 AGENTS.md 是否给出了充分的终止条件为每个步骤写清“完成后继续/完成后停止”的判定条件这里重点说两个最容易让新人卡住、又最容易被忽略的问题。第一个是“模型名不识别”。很多用户在网上看到别人配置了某个模型名就随手复制到自己配置里但不同账号、不同地区、不同授权范围能用的模型不一定相同。遇到这类错误先看 CLI 版本再看账号实际可用模型列表不要盲目套用网上命令。第二个是“Skill 没触发但又不报错”。这是最隐蔽的问题Claude Code 启动正常命令也能执行但它就是不用你的 Skill而是自己硬读日志、硬编报告。这种情况几乎都是 SKILL.md 的 description 没有和用户指令匹配上。解决办法是在 description 里多写几个“用户可能怎么说”覆盖口语化和缩写场景。8. 最佳实践与工程建议到这里你已经能跑通一个完整的 Agent Skill。但要在真实项目和团队协作中稳定使用还需要注意下面几个工程层面的问题。8.1 skill 描述的写法决定触发率SKILL.md 的 description 是整个技能的门面。写得越具体模型越容易在需要的时候找到它。建议采用“场景 行为 同义词”的结构先说明这个技能覆盖哪些场景再说明它会做什么最后补充用户的几种典型说法。这样的描述看起来啰嗦但触发率会明显提升。8.2 从“提示词”渐进演化为 Skill不要一开始就追求完美设计。更稳妥的做法是先在对话里把流程跑通把每一步的输入输出记录下来确认流程稳定后再固化成 SKILL.md 和脚本最后在团队里试用并迭代。一次只改一个变量避免“流程变了但说不清是哪个环节出了问题”。8.3 脚本要做到幂等、无副作用、可重复执行Skill 里带的脚本应该尽量是“只读型”或“幂等型”的同样的输入执行两次结果一致不偷偷修改源文件不依赖未声明的外部状态。比如日志分析脚本只读取日志、输出报告就是一个好的范例。如果脚本有副作用比如会更新数据库、删除临时文件必须在 SKILL.md 里显式声明并让用户确认后再执行。8.4 安全边界与权限控制这是所有 Agent 工具都绕不开的问题。Agent 拥有执行命令的能力这既是它强大的原因也是它危险的原因。请务必遵守几条底线最小权限原则以普通用户身份运行不要用 root 或管理员权限启动 Agent危险操作确认涉及删除、覆盖、批量修改、线上变更等操作时先让 Agent 输出具体命令确认后再执行测试先行任何新的 Skill 先在测试目录、测试环境跑通再放到生产环境使用审计留痕记录 Agent 执行过的命令和输出便于回溯问题敏感信息保护不要把密钥、Token、数据库密码写在 SKILL.md 或 AGENTS.md 中必要时应通过环境变量注入。8.5 团队共享与版本管理Skill 本质上是代码资产应该像代码一样被管理。推荐把一个共享的 skills 目录放进独立的 Git 仓库团队成员通过 clone 或子模块挂载到本地。每次修改都要走 review 流程重点看描述是否准确、脚本是否安全、输出格式是否兼容。这样团队里每个人的 Agent 行为会越来越一致长期看能显著降低协作成本。8.6 定期清理和审查时间一长每个开发者本地都会积累大量 Skill。有些技能可能已经被模型能力覆盖有些脚本可能依赖了已废弃的工具。建议每季度做一次技能审查删除长期未使用的技能合并功能重复的技能更新脚本依赖。技能库和代码库一样需要持续维护否则会变成新的技术债。9. 总结与后续方向这篇文章的核心内容是把 Agent 从“能用”变成“会用”关键不是囤更多提示词而是学会用 Agent Skills 的方式沉淀能力。我们从概念上解释了 Agent 和 Skill 的关系动手做了一个日志分析 Skill并在 Claude Code 和 Codex 两套工具中分别演示了技能落地的思路。你如果完整走了一遍现在应该具备自己设计 Skill、排错和团队推广的能力。下一步可以往三个方向深入第一把日志分析这个例子替换成你们团队真正的痛点场景比如代码规范检查、发布前检查、数据质量审查第二研究 Agent 如何接入更多外部工具比如通过 MCP 连接内部系统让 Skill 不只是脚本而是能操作真实业务系统的能力第三建立一套团队级的技能治理机制让 Skill 的命名、描述、脚本规范都变成团队共识。最后提醒一句Skill 是手段不是目的。别为了让 Agent “看起来会很多东西”而堆砌技能而要从真实任务的重复频率和稳定需求出发。先把一两个高频任务做成高质量 Skill跑顺之后再逐步扩展。这个节奏比你一次性铺开二十个半成品技能要稳妥得多。