别写 Prompt 了!Agent Skills 正在杀死 Prompt Engineering
Agent Skills 完全指南:从 Prompt Engineering 到 Skill Engineering 的范式革命
当所有人还在卷 Prompt 的时候,一批开发者已经悄悄把 AI Agent 装上了"技能包"。
2025年12月,Anthropic 将 Agent Skills 正式发布为开放标准——继 MCP 之后,AI 原生应用的"能力层"拼图彻底补齐。Claude、Cursor、OpenCode、Letta 等头部工具已率先支持。本文将从概念解析、标准拆解到硬核实战,带你完成从"指挥 AI"到"配置 AI"的认知跃迁。
一、为什么 Agent Skills 是 2026 年最值得学的 AI 技术?
1.1 一个让你"沉默"的对比
| 维度 | Prompt Engineering | Skill Engineering |
|---|---|---|
| 持久性 | 一次性的,跨会话不保留 | 永久安装,全项目生效 |
| 复用性 | 每次重新粘贴 | 写一次,到处运行 |
| 精确性 | 靠人力微调措辞 | 结构化Schema驱动 |
| 协作性 | 只能人→AI | AI→AI、Agent→Agent |
| 工程化 | 文档散落在聊天记录 | 版本控制、代码审查、CI/CD |
一句话总结:Prompt 是"临时工",Skill 是"正式员工"。
1.2 行业正在发生的三个信号
信号一:三大 AI 巨头默契统一
OpenAI、Anthropic、Google DeepMind——三家没有联合声明、没有标准委员会,却不约而同采用了几乎相同的 Skill 定义格式(基于 JSON Schema)。这不是巧合,是技术收敛的必然。
信号二:开发工具集体入局
Claude Code、Cursor、Qoder、OpenCode、VS Code、Letta……一线 AI 编程工具在 2025 年末至 2026 年初密集上线 Skills 支持。一套 Skill,多平台运行。
信号三:从单 Agent 到多 Agent 架构
当 Agent 需要协作时,"你擅长什么"比"你能回答什么"重要一万倍。Skills 是 Agent 间能力发现的唯一标准化方案。
二、什么是 Agent Skills?核心概念全解析
2.1 一句话定义
Agent Skill 是一个可移植的"能力包"——它让 AI Agent 知道自己能做什么、何时做、怎么做。
物理形态上,它就是一个文件夹:
my-skill/
├── SKILL.md # 必须:元数据 + 指令(入口文件)
├── scripts/ # 可选:可执行脚本
│ └── validate.sh
├── references/ # 可选:参考文档
│ └── REFERENCE.md
├── assets/ # 可选:模板、资源文件
│ └── template.md
└── examples/ # 可选:示例输出
└── sample.md
2.2 SKILL.md 的完整结构
每个 Skill 的核心是 SKILL.md,由两部分组成:YAML Frontmatter(元数据)+ Markdown Body(指令)。
---
name: code-review # 必须:技能名称(小写+连字符)
description: 按 OWASP Top 10 标准审查代码,检查安全漏洞和最佳实践违规。 # 必须:描述做什么+何时用
license: Apache-2.0 # 可选:许可证
compatibility: Requires git, jq # 可选:环境依赖
metadata: # 可选:扩展元数据
author: dev-team
version: "1.0"
allowed-tools: Bash(git:*) Read # 可选:预授权工具列表
---
# 代码审查指令
## 步骤
1. 使用 `git diff` 获取待审查的代码变更
2. 逐文件检查以下维度:
- SQL 注入风险
- 硬编码密钥/凭证
- 缺失的错误处理
- 不安全的反序列化
3. 按 严重/警告/建议 三级分类输出
4. 生成修复建议和具体代码修改
## 输出格式
| 级别 | 文件 | 行号 | 问题描述 | 修复建议 |
|------|------|------|---------|---------|
## 注意事项
- 忽略 auto-generated 文件
- 对 test 文件降低严格度
2.3 命名规则(踩坑必看)
name 字段必须严格遵守:
| 规则 | 合法示例 | 非法示例 | 原因 |
|---|---|---|---|
| 仅小写字母+数字+连字符 | code-review |
Code-Review |
大写不允许 |
| 不能以连字符开头/结尾 | pdf-process |
-pdf |
开头不能是 - |
| 不能连续连字符 | data-analysis |
data--analysis |
-- 不允许 |
| 必须与目录名一致 | 目录 code-review/ |
name 写成 cr |
名不匹配 |
| 最长 64 字符 | a-valid-name |
超过 64 字符 | 长度超限 |
2.4 渐进式披露:为什么 1000 个 Skill 也不卡?
Agent Skills 的杀手级设计——Progressive Disclosure(渐进式披露):
第一阶段:Metadata(~100 tokens)
→ 系统启动时,只加载 name + description
→ Agent 知道"我有什么技能",但还没加载具体指令
第二阶段:Instructions(<5000 tokens)
→ 当 Agent 决定使用某个 Skill 时,才加载 SKILL.md 全文
→ 只占上下文一小部分
第三阶段:Resources(按需)
→ scripts/、references/、assets/ 中的文件
→ 仅在指令中引用到时才加载
实际效果:给 Agent 装备 1000 个 Skill,日常仅占用约 10 万 tokens 的元数据空间。只有真正"干活"时,才按需加载详细指令。这完美解决了 Token 浪费和上下文干扰问题。
三、Skills vs Tools vs MCP vs A2A:一张图厘清生态定位
3.1 四层架构全景
┌─────────────────────────────────────────────────┐
│ A2A 协议层 │
│ Agent 间协作的"社交网络" │
│ "你能做什么?我需要你的帮助!" │
├─────────────────────────────────────────────────┤
│ Skills 能力层 │
│ Agent 的"技能包"与"岗位SOP" │
│ "我知道怎么做,这是我的操作手册" │
├─────────────────────────────────────────────────┤
│ MCP 连接层 │
│ 工具调用的"通用插座" │
│ "我能连接到数据库、文件系统、API" │
├─────────────────────────────────────────────────┤
│ Agent 执行主体 │
│ 感知 → 规划 → 行动 → 记忆 → 反思 │
└─────────────────────────────────────────────────┘
3.2 核心区别对比
| 维度 | Tools | Skills | MCP | A2A |
|---|---|---|---|---|
| 本质 | 可执行函数/API | 知识+行为模式 | 连接协议 | 协作协议 |
| 粒度 | 原子操作 | 复合能力 | 传输通道 | 通信框架 |
| 解决的问题 | “能做什么” | “做得对不对” | “能不能访问” | “怎么分工” |
| 类比 | 螺丝刀 | 维修手册 | USB 接口 | 团队协作流程 |
3.3 一次看懂:商务邮件场景
Tool: send_email(to, subject, body) ← 一个函数调用
Skill: 商务邮件写作规范 ← 包含模板、礼仪、语气指南
MCP: 连接到 Gmail/企业邮箱 ← 建立通信管道
A2A: 邮件Agent ← 接收任务 ← 主Agent ← Agent间委托
最佳实践:用 MCP 建立连接,用 Skill 定义流程,用 A2A 分工协作。
四、开放标准:三大 AI 巨头的"默契统一"
4.1 没有标准委员会的收敛
2023 年中,OpenAI 率先推出 Function Calling,定义了第一个事实标准:
{
"name": "get_weather",
"description": "Get the current weather for a location",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City and state, e.g. Austin, TX"
}
},
"required": ["location"]
}
}
随后,Anthropic 的 Tool Use、Google 的 FunctionDeclaration,都采用了几乎相同的 JSON Schema 格式。差异仅在表层:参数包装方式、调用信号格式、API 传参位置。
4.2 为什么是 JSON Schema?
| 优势 | 说明 |
|---|---|
| 已有生态 | API 文档和数据验证已广泛使用 |
| 双重可读 | 人类可读 + 机器可解析 |
| 类型完备 | 支持 string/number/enum/array/nested object |
| 零成本迁移 | 无需新规范,直接复用现有工具链 |
4.3 三家实现的差异一览
| 平台 | 定义方式 | 调用信号 | 特色 |
|---|---|---|---|
| OpenAI | tools[] → type: "function" |
返回 tool_calls 数组 |
Agents SDK 支持 Handoff |
| Anthropic | tools[] → input_schema |
返回 tool_use 内容块 |
description 对准确率影响最大 |
FunctionDeclaration |
返回 functionCall 部分 |
原生多模态支持 |
关键洞察:一个 Skill 定义,三家平台只需改"包装层",核心 Schema 完全通用。跨平台 Skill 适配器完全可行。
4.4 MCP vs Skills:不要混淆
这是开发者最容易混淆的一对概念:
| 维度 | MCP | Skills |
|---|---|---|
| 解决问题 | 一个 Agent 如何访问外部工具和数据 | 多个 Agent 间如何描述和共享能力 |
| 方向 | Agent → 工具(1对多) | Agent ↔ Agent(多对多) |
| 类比 | USB 接口 | 通用驱动程序 |
| 关系 | 基础设施层 | 能力互操作层 |
一句话:MCP 是"硬件连接",Skills 是"软件驱动"。两者互补而非竞争。
五、实战一:5 分钟创建你的第一个 Agent Skill
5.1 场景:Git 变更摘要 Skill
每当想看自己改了什么、有没有风险操作,一个 Skill 搞定。
Step 1:创建目录
# 个人 Skill(所有项目可用)
mkdir -p ~/.claude/skills/summarize-changes
# 或项目级 Skill(仅当前项目)
mkdir -p .claude/skills/summarize-changes
Step 2:编写 SKILL.md
---
name: summarize-changes
description: >
Summarizes uncommitted changes and flags anything risky.
Use when the user asks what changed, wants a commit message,
or asks to review their diff.
---
## Current changes
!`git diff HEAD`
## Instructions
Summarize the changes above in two or three bullet points,
then list any risks you notice such as:
- Missing error handling
- Hardcoded secrets or API keys
- Tests that need updating
- Breaking changes to public APIs
If the diff is empty, say there are no uncommitted changes.
## Output Format
**Summary:**
- <bullet 1>
- <bullet 2>
**Risks:**
- ⚠️ <risk description> or "No significant risks detected"
关键技巧:
!`git diff HEAD`是动态上下文注入——Claude Code 会在加载 Skill 前先执行该命令,将输出内联替换到 Skill 内容中。这样 Agent 看到的就是实时 diff 数据,而非静态文本。
Step 3:测试
在任意 Git 项目中启动 Claude Code:
# 方式一:自然语言触发(Claude 根据 description 自动判断)
> 我改了什么?
# 方式二:直接调用
> /summarize-changes
5.2 Skill 的三种存放位置
| 位置 | 路径 | 生效范围 |
|---|---|---|
| 个人 | ~/.claude/skills/<name>/SKILL.md |
你的所有项目 |
| 项目 | .claude/skills/<name>/SKILL.md |
仅当前项目 |
| 插件 | <plugin>/skills/<name>/SKILL.md |
启用插件的位置 |
优先级:企业 > 个人 > 项目。插件 Skill 使用 plugin-name:skill-name 命名空间,不会冲突。
六、实战二:企业级代码审查 Skill(含脚本+参考文档)
6.1 场景说明
构建一个完整的 Go 项目 Code Review Skill,包含:主指令、Lint 脚本、安全检查参考文档。
6.2 目录结构
code-review/
├── SKILL.md # 主指令
├── scripts/
│ ├── go-lint.sh # Go Lint 检查脚本
│ └── go-vuln.sh # 漏洞扫描脚本
├── references/
│ ├── SECURITY-CHECKLIST.md # 安全审查清单
│ └── GO-BEST-PRACTICES.md # Go 最佳实践参考
└── assets/
└── review-template.md # 审查报告模板
6.3 SKILL.md 主文件
---
name: code-review
description: >
Analyze Go code changes based on OWASP Top 10 and Go best practices.
Use when reviewing pull requests, checking code quality, or when
the user asks for a code review.
license: Apache-2.0
compatibility: Requires go, git, jq
metadata:
author: devops-team
version: "2.0"
allowed-tools: Bash(git:*) Bash(go:*) Read Write
---
# Go Code Review Skill
## Overview
This skill performs comprehensive code review for Go projects, covering
security, performance, readability, and correctness.
## Step-by-step Instructions
### Phase 1: Collect Changes
1. Run `git diff --name-only origin/main...HEAD` to identify changed files
2. Filter for `.go` files only
3. Skip auto-generated files (e.g., `*_test.go` in vendor/)
### Phase 2: Static Analysis
Run the linting script to catch common issues:
```bash
bash scripts/go-lint.sh
Review the output and categorize findings.
Phase 3: Security Review
Consult SECURITY-CHECKLIST.md for
the complete security review checklist. Focus on:
- SQL injection (string concatenation in queries)
- Hardcoded credentials or API keys
- Unsafe use of
interface{}without type assertion - Missing input validation on HTTP handlers
Also run vulnerability scanning:
bash scripts/go-vuln.sh
Phase 4: Best Practices Check
Reference GO-BEST-PRACTICES.md for
detailed guidelines. Key areas:
- Error handling: Are errors properly wrapped with context?
- Concurrency: Are goroutines properly managed with context cancellation?
- Resource management: Are
deferstatements used for cleanup? - API design: Do exported functions follow Go naming conventions?
Phase 5: Generate Report
Use the template in review-template.md
to format your findings. Classify each issue as:
- 🔴 Critical: Security vulnerability, data loss risk
- 🟡 Warning: Performance issue, missing error handling
- 🟢 Suggestion: Code style, readability improvement
Edge Cases
- If no Go files are changed, report “No Go code changes to review”
- For test files, reduce severity level by one notch
- For generated code (//go:generate), skip entirely
- If
go vetfails to run, note the environment issue and proceed with manual review
### 6.4 Lint 脚本
```bash
#!/bin/bash
# scripts/go-lint.sh - Go 静态分析检查
set -euo pipefail
echo "=== Go Vet ==="
go vet ./... 2>&1 || true
echo ""
echo "=== Go Lint (golangci-lint) ==="
if command -v golangci-lint &>/dev/null; then
golangci-lint run --timeout=5m ./... 2>&1 || true
else
echo "golangci-lint not installed, skipping"
fi
echo ""
echo "=== Go Format Check ==="
unformatted=$(gofmt -l .)
if [ -n "$unformatted" ]; then
echo "Files needing formatting:"
echo "$unformatted"
else
echo "All files properly formatted"
fi
6.5 安全审查清单
<!-- references/SECURITY-CHECKLIST.md -->
# Go Security Review Checklist
## Input Validation
- [ ] All HTTP handler inputs are validated
- [ ] File paths are sanitized (no path traversal)
- [ ] SQL queries use parameterized statements
- [ ] User input is not directly interpolated into templates
## Authentication & Authorization
- [ ] Sensitive endpoints require authentication
- [ ] Role-based access control is properly enforced
- [ ] JWT tokens are validated (signature, expiry, issuer)
- [ ] Password hashing uses bcrypt/argon2 (not MD5/SHA)
## Data Protection
- [ ] No hardcoded secrets or API keys
- [ ] Sensitive data is encrypted at rest
- [ ] TLS is used for all network communication
- [ ] Logs do not contain PII or credentials
## Error Handling
- [ ] Internal errors are not exposed to clients
- [ ] Stack traces are not returned in production
- [ ] Panic recovery middleware is in place
- [ ] Context cancellation is properly handled
6.6 审查报告模板
<!-- assets/review-template.md -->
# Code Review Report
**Date**: {date}
**Reviewer**: Agent Skill
**Branch**: {branch}
## Summary
{2-3 sentence summary of changes}
## Findings
| # | Level | File | Line | Issue | Fix |
|---|-------|------|------|-------|-----|
| 1 | 🔴/🟡/🟢 | | | | |
## Metrics
- Files reviewed: {n}
- Critical issues: {n}
- Warnings: {n}
- Suggestions: {n}
## Verdict
- [ ] ✅ Approved - No critical issues
- [ ] ⚠️ Conditional - Fix warnings before merge
- [ ] ❌ Rejected - Critical issues must be resolved
6.7 使用方式
# 自动触发(Claude 根据 description 判断)
> 请审查这个 PR 的代码变更
# 手动调用
> /code-review
# 指定范围
> 审查 src/api/ 目录下最近的变更
七、实战三:多 Skill 协作——构建智能研发工作流
7.1 场景:三个 Skill 联合完成"提交前全流程检查"
用户: "我要提交代码了,帮我做一次完整检查"
┌──────────────────────────────────────────────┐
│ 主 Agent (Claude) │
│ │
│ 1. 自动加载 /summarize-changes │
│ → 获取变更概览和风险标记 │
│ │
│ 2. 自动加载 /code-review │
│ → 执行安全审查 + Lint 检查 │
│ │
│ 3. 自动加载 /commit-helper │
│ → 生成规范的 commit message │
│ │
└──────────────────────────────────────────────┘
7.2 第三个 Skill:Commit Message 生成器
---
name: commit-helper
description: >
Generate conventional commit messages from staged changes.
Use when the user wants to commit, needs a commit message,
or asks about commit conventions.
---
## Current staged changes
!`git diff --cached --stat`
## Instructions
Generate a commit message following Conventional Commits format:
():
Type Selection Guide
feat: New featurefix: Bug fixrefactor: Code restructuring without behavior changedocs: Documentation onlytest: Adding or updating testschore: Build process, dependencies, toolingperf: Performance improvementci: CI/CD configuration
Rules
- Subject line: max 72 characters, imperative mood
- Body: explain WHY, not WHAT (diff already shows what)
- Reference issue numbers in footer if applicable
- Breaking changes: use
!after type and explain in footer
Example
feat(api): add rate limiting to user endpoints
Implement token bucket rate limiter for /api/users/* endpoints
to prevent abuse. Default: 100 requests/minute per IP.
Closes #142
### 7.3 工作流编排
将三个 Skill 放入项目后,只需一句话触发:
```text
> 我要提交代码了
Claude 会自动:
1. 加载 summarize-changes → 输出变更摘要
2. 加载 code-review → 输出审查报告
3. 加载 commit-helper → 生成 commit message
如果审查有 Critical 问题,Claude 会建议先修复再提交。
如果一切正常,Claude 会直接帮你执行 git commit。
八、主流平台 Skills 支持一览
| 平台 | Skills 支持 | 存放路径 | 特色功能 |
|---|---|---|---|
| Claude Code | ✅ 完整支持 | ~/.claude/skills/ / .claude/skills/ |
动态上下文注入、子 Agent 执行、自动发现 |
| Cursor | ✅ 已支持 | 项目配置 | 与 Cursor Rules 集成 |
| Qoder | ✅ 内置 create-skill | .qoder/skills/ |
交互式 Skill 创建向导(/create-skill) |
| VS Code | ✅ 通过插件 | 工作区配置 | 微软官方集成 Agent Skills 标准 |
| OpenCode | ✅ 已支持 | 项目配置 | 开源 AI 编程工具 |
| Letta | ✅ 已支持 | Agent 配置 | 记忆增强型 Agent 框架 |
8.1 Qoder 的交互式创建方式
Qoder 内置了 /create-skill 命令,通过对话引导你逐步创建 SKILL.md:
> /create-skill
Qoder: 好的,让我们创建一个新的 Skill。
1. 请输入技能名称(小写+连字符): api-doc-generator
2. 请描述这个技能的功能和适用场景: 自动根据代码注释生成 OpenAPI 文档...
3. 这个技能需要哪些工具权限? Read, Write, Bash(swagger:*)
4. 请提供主要指令内容: ...
✅ Skill 已创建: .qoder/skills/api-doc-generator/SKILL.md
8.2 验证你的 Skill
使用官方验证工具:
# 安装验证工具
pip install skills-ref
# 验证 Skill 格式
skills-ref validate ./my-skill
# 输出示例
✅ name: valid
✅ description: valid
✅ frontmatter: valid
✅ directory name matches skill name
✅ SKILL.md found
九、编写高质量 Skill 的 10 条黄金法则
法则 1:Description 是 Skill 的"搜索引擎优化"
# ❌ 差:太模糊
description: Helps with PDFs.
# ✅ 好:包含做什么 + 何时用 + 关键词
description: >
Extracts text and tables from PDF files, fills PDF forms,
and merges multiple PDFs. Use when working with PDF documents
or when the user mentions PDFs, forms, or document extraction.
Agent 根据 description 决定是否激活 Skill。写得越精准,自动触发越准确。
法则 2:SKILL.md 控制在 500 行以内
超过 500 行的指令,Agent 容易"走神"。把详细参考资料拆到 references/ 目录,主文件只保留核心步骤。
法则 3:用动态上下文注入替代静态假设
# ❌ 差:让 Agent 自己猜
请检查当前项目的代码变更
# ✅ 好:用 !`command` 注入实时数据
!`git diff HEAD`
法则 4:明确输出格式
# ❌ 差
分析代码并给出建议
# ✅ 好
按以下格式输出:
| 级别 | 文件 | 行号 | 问题 | 修复建议 |
|------|------|------|------|---------|
级别分为:🔴 Critical / 🟡 Warning / 🟢 Suggestion
法则 5:处理边界情况
## Edge Cases
- 如果没有 Go 文件变更,报告 "No Go code changes to review"
- 如果 diff 为空,报告 "No uncommitted changes"
- 如果 lint 工具未安装,跳过该步骤并注明
法则 6:合理使用 allowed-tools
# 仅预授权必要的工具,避免过度权限
allowed-tools: Bash(git:*) Read
# 而不是
allowed-tools: Bash(*) # 危险:允许执行任意命令
法则 7:区分"参考型"和"任务型"Skill
# 参考型:知识注入,Claude 自动使用
---
name: api-conventions
description: API design patterns for this codebase
---
# 任务型:分步操作,通常手动调用
---
name: deploy
description: Deploy the application to production
disable-model-invocation: true # ← 禁止自动触发
---
法则 8:善用 Monorepo 的嵌套发现
my-monorepo/
├── .claude/skills/ # 全局 Skill
│ └── code-review/
├── packages/
│ ├── frontend/
│ │ └── .claude/skills/ # 前端专用 Skill
│ │ └── react-review/
│ └── backend/
│ └── .claude/skills/ # 后端专用 Skill
│ └── api-review/
当你在 packages/frontend/ 中工作时,Claude 会自动发现上下两级目录的 Skill。
法则 9:版本化你的 Skill
metadata:
version: "2.1"
changelog: |
v2.1: Added OWASP API Security Top 10 checks
v2.0: Restructured to separate references
v1.0: Initial release
法则 10:为 Skill 编写测试
# 在项目中创建 Skill 测试脚本
test/test-skills.sh
#!/bin/bash
# 验证 Skill 基本功能
echo "Testing summarize-changes..."
echo "test" >> test-file.txt
# 在 Claude Code 中运行 /summarize-changes
# 预期:检测到变更,输出摘要
rm test-file.txt
十、Agent Skills 的未来:从"能做"到"会做"
10.1 技术趋势
| 趋势 | 说明 | 预期时间 |
|---|---|---|
| Skill 市场成熟 | 类似 VS Code 插件市场的一站式 Skill 分发 | 2026 下半年 |
| 跨平台互操作 | 一套 Skill 在 Claude/Cursor/Qoder/VS Code 通用 | 已实现(基础) |
| Skill 链式编排 | Skill A 的输出自动成为 Skill B 的输入 | 2026 Q3 |
| 企业 Skill 仓库 | 私有 Skill Registry,内部知识沉淀 | 2026 Q2 |
| Skill 自动生成 | AI 根据你的操作记录自动提炼 Skill | 2026 Q4 |
10.2 对开发者的意义
从 Prompt Engineer 到 Skill Engineer:
Prompt Engineer(过去)
→ 写提示词
→ 调措辞、换格式
→ 聊天记录就是文档
→ 经验无法复用
Skill Engineer(未来)
→ 设计能力架构
→ 编写结构化指令
→ 版本控制、代码审查
→ 企业知识可沉淀、可复用、可迁移
未来的高价值开发者,不再是那些会写漂亮提示词的人,而是能将企业隐性知识封装成标准化、可移植 Agent Skills 的人。
10.3 行动建议
第一步:安装 Claude Code 或 Qoder → 创建你的第一个 Skill
↓
第二步:把重复性指令迁移为 Skill(commit message、代码审查、部署流程)
↓
第三步:为团队项目建立共享 Skill 库(编码规范、安全检查、CI/CD)
↓
第四步:探索多 Agent + 多 Skill 协作架构
↓
第五步:发布你的 Skill 到社区,成为 Skill Engineer 先行者
附录:关键资源
| 资源 | 链接 |
|---|---|
| Agent Skills 开放标准规范 | https://agentskills.io/specification |
| Claude Code Skills 文档 | https://code.claude.com/docs/zh-CN/skills |
| Anthropic Skills GitHub | https://github.com/anthropics/skills |
| Qoder Skills 文档 | https://docs.qoder.com/zh/extensions/skills |
| skills-ref 验证工具 | https://github.com/agentskills/agentskills/tree/main/skills-ref |
| Google A2A 协议 | https://github.com/google/A2A |
| Anthropic MCP 协议 | https://modelcontextprotocol.io |
| OpenAI Agents SDK | https://github.com/openai/openai-agents-python |
| Datawhale Agent Skills 教程 | https://github.com/datawholechina/agent-skills-with-anthropic |
Agent Skills 不是又一个转瞬即逝的"热词",它是 AI Agent 从"玩具"到"工具"的关键基础设施。就像 npm 之于 Node.js、Docker 之于容器化——当生态的标准层出现,才是技术真正爆发的起点。
而现在,这个标准层刚刚铺好。早一步掌握 Skill Engineering,就早一步拿到 AI 2.0 时代的入场券。
如果这篇文章对你有帮助,点赞+收藏+关注三连,下期我们将深入实战——用 Agent Skills 构建完整的 CI/CD 自动化流水线。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐



所有评论(0)