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 与 Codex

2.1 Agent 是什么，它的运作模式发生了哪些变化

Agent（智能体）不是一个新概念，但在大模型时代，它被重新定义了。传统的自动化程序是一套固定的 if-else 流程，而大模型 Agent 则是在一个目标任务的驱动下，自己决定“下一步做什么”——比如先查文档、再改代码、然后运行测试、最后根据测试结果决定是否继续修。

这套模式的关键在于：Agent 需要把一个大目标拆成若干小步骤，并且在每个步骤中调用合适的工具。工具越多、越规范，Agent 的能力就越强。但这同时也带来一个问题：你不可能把团队的规则、项目的约束、业务的背景全部实时塞进每一轮对话里，Agent 需要一套“离线知识”来支撑自己。

2.2 Agent Skills：让 Agent 拥有可复用的专业技能

Agent Skills 本质上是一个目录化的技能包。一个典型 Skill 包含三部分：

1. SKILL.md 描述文件：用 Markdown 写的技能说明，包含这个技能是什么、适用于什么场景、使用步骤是什么；
2. 脚本或模板文件：可以被执行的 Python、Shell、JavaScript 脚本，或者代码模板、配置模板；
3. 参考资料：需要给模型读取的知识文档、示例输出等。

Skill 的动作机制是：当用户请求与某个技能描述匹配时，Agent 会读取对应的 SKILL.md，按照里面的步骤执行。如果 SKILL.md 指定了要运行某个脚本，Agent 会调用命令行来执行脚本，再把结果结合上下文返回给用户。

从架构上看，Agent Skills 位于“提示词”和“独立应用”之间：

• 提示词：零成本，但一次一用，无法管理，无法复用；
• Agent Skills：需要少量目录和文件组织成本，但可复用、可版本化、可团队共享；
• 独立应用：功能完整，但需要完整的工程开发、部署和界面成本，不适合快速沉淀。

2.3 Claude Code 与 SKILL.md

Claude Code 是 Anthropic 推出的命令行编程 Agent 工具，它跑在终端里，可以读项目代码、改文件、执行命令、跑测试，并在这个过程中不断反思和修正。

它对 Agent Skills 的支持非常直接：在用户级目录或项目目录中放置.claude/skills/<技能名>/SKILL.md，Claude 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 --version

Codex 同样需要配置 API 凭据，常见做法是设置OPENAI_API_KEY环境变量：

export OPENAI_API_KEY="你的API Key"

有些团队会把 Codex 接到内部统一的模型网关或兼容接口上，这种情况下你需要修改 Codex 的配置文件，指定模型名和接口地址。模型名、接口地址都以你所在团队的接入文档为准，不要照抄网上的任何一条命令。

3.4 验证安装是否成功

安装完成后，在最简单的测试目录里分别运行：

claude

codex

进入交互界面后，随便问一句“请介绍一下当前目录”，如果 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", encoding="utf-8", errors="ignore") 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, key=lambda 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}", file=sys.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_id=1001 2025-06-01 10:00:05 ERROR 数据库连接超时 host=db-01 2025-06-01 10:00:07 WARN 缓存命中率下降 cache_hit=0.82 2025-06-01 10:00:09 ERROR 数据库连接超时 host=db-02 2025-06-01 10:00:12 INFO 订单创建成功 order_id=90001 2025-06-01 10:00:15 ERROR 第三方接口返回 500 api=pay 2025-06-01 10:00:20 FATAL 未捕获异常 NullPointerException 2025-06-01 10:00:22 WARN 队列积压消息数=120 EOF

6.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 数据库连接超时 host=db-01`（1 次） - `2025-06-01 10:00:09 ERROR 数据库连接超时 host=db-02`（1 次） - `2025-06-01 10:00:15 ERROR 第三方接口返回 500 api=pay`（1 次） - `2025-06-01 10:00:20 FATAL 未捕获异常 NullPointerException`（1 次） ### 最近 10 条 ERROR 记录时间点 - 2025-06-01 10:00:05 2025-06-01 10:00:05 ERROR 数据库连接超时 host=db-01 ...

如果脚本能直接输出这个报告，说明统计逻辑正确；如果输出不对，先回到脚本本身排查，不要急着怀疑 Agent。

6.3 通过 Claude Code 验证 Skill 触发

脚本验证通过后，再进入 Claude Code 验证整体链路。启动后输入同样的指令，重点观察两个信号：

第一，Claude 是否真的执行了python3 log_analyzer.py sample.log这条命令。你可以从 Claude Code 的执行日志中看到它调用了哪些工具。如果它没有运行脚本，而是在“假装分析”或自己脑补日志内容，说明 Skill 没有被正确加载。

第二，输出报告是否和直接运行脚本的结果一致。如果中间出现了脚本里不存在的数据，优先怀疑 Claude 在“自由发挥”。这时候应该回到 SKILL.md，把“必须运行脚本获取统计结果”写得更强硬一些，比如明确写“禁止自行统计，必须以脚本输出为准”。

6.4 失败时的第一排查顺序

如果整个过程没有按预期跑通，不要先翻配置文件，按下面顺序排查：

1. 脚本本身能不能跑？直接执行python3 log_analyzer.py sample.log看输出；
2. Skill 目录位置对不对？确认路径是~/.claude/skills/log-analyzer/SKILL.md；
3. 模型能不能读到 SKILL.md？在 Claude Code 里问“当前有哪些 skill”，或检查调试日志；
4. 是否触发了正确的工具？观察 Claude 是否执行了脚本命令。

7. 常见问题与排查思路

在安装和使用 Claude Code、Codex 的过程中，有一些错误非常高频。下面整理成一张排查表，遇到问题时可以直接对照。

这里重点说两个最容易让新人卡住、又最容易被忽略的问题。

第一个是“模型名不识别”。很多用户在网上看到别人配置了某个模型名，就随手复制到自己配置里；但不同账号、不同地区、不同授权范围能用的模型不一定相同。遇到这类错误，先看 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，跑顺之后，再逐步扩展。这个节奏，比你一次性铺开二十个半成品技能要稳妥得多。