# 技能挖掘：从 3,500 个候选项到 466 项能力

Canonical source: https://maguyva.ai/zh-hans/blog/skill-mining-3500-and-counting

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-01-27 · Author: Maguyva Team

> 我们筛选了 3,500 个技能候选项，最终采纳了 466 个。这是一套系统化的挖掘与吸纳循环，用于大规模构建一套连贯一致的 AI 智能体技能库。

> *本文中的数字反映的是发布时（2026 年 1 月）的系统状态。如需查看最新数据，请参阅我们的 [团队页面](/zh-hans/team)。*

## 3,500 个技能的难题

当我们开始搭建一套智能体编排系统时，面对的是一个有意思的挑战：整个 AI 生态里，散落着成千上万个潜在的技能。GitHub 代码仓库、供应商文档、社区项目、内部模式——技能无处不在。但哪些才真正重要？哪些真正管用？你又该如何维护一套智能体真正能用得上的、连贯一致的技能库？

我们的答案是：一套系统化的挖掘与吸纳循环。

## 今天的数字

距 Anthropic 于 2025 年 10 月 16 日推出 Agent Skills 刚过三个多月，以下是本文发布时（2026 年 1 月 27 日）我们所处的状态：

| 指标 | 数量 |
|--------|-------|
| 已识别的候选项 | 3,500+ |
| 已采纳的技能 | 466 |
| 供应商技能 | 373 |
| 内部技能 | 93 |
| 活跃供应商 | 25+ |
| 每项技能平均 Token 数 | 2,834 |
| 引用的工具数 | 89 |
| 唯一标签数 | 635 |

我们审查了超过 3,500 个技能候选项，最终采纳了 466 个。采纳率是 13%——而这种挑剔，是有意为之的设计。

## 知识分层体系

并非所有技能都生而平等。我们把它们组织成五个知识层级（K0 到 K4），每一层代表一种不同的适用范围：

### K0：基础（通用）

每个智能体都应该具备的技能。这些代表着放之四海皆准的“优秀思考者”能力。

```
foundations/
├── test-first-discipline       # TDD: Red-Green-Refactor
├── evidence-based-completion   # Verify before claiming done
├── systematic-debugging        # Root cause methodology
├── structured-planning         # Break work into tasks
└── context-budget-awareness    # Manage token consumption
```

K0 技能可以移植到任何项目、任何领域、任何技术栈，它们编码的是通用的认知模式。

### K1：身份（学科）

在某个学科内、跨项目通用的“优秀工程师”或“优秀研究者”技能。

```
identities/
├── research-workflows          # Multi-source research
├── web-extraction-playbook     # Content extraction
├── code-review                 # PR review patterns
└── cli-interface-standards     # CLI design patterns
```

### K2：领域（专业知识）

在某个领域内可移植的“优秀数据库专家”或“优秀安全工程师”技能。

```
domains/
├── schema-migration-workflow   # Safe migration patterns
├── rpc-validation-checklist    # RPC health checks
├── auth-validation-checklist   # JWT/OAuth patterns
└── secrets-audit-checklist     # Credential scanning
```

### K3：技术栈（技术）

针对特定技术栈的“优秀 Supabase 用户”或“优秀 Cloudflare 开发者”技能。

```
stacks/
├── maguyva-quickstart          # Our semantic search patterns
├── cloudflare-deployment       # Workers/Pages deployment
└── mcp-tool-best-practices     # MCP tool selection
```

### K4：项目（组织）

特定于我们自己组织和工作流的技能。

```
project/
├── agent-creation-workflow     # How we build agents
├── skill-authoring-workflow    # How we write skills
├── mining-session-workflow     # This very process
└── vendor-skill-evaluation     # Evaluation rubrics
```

## 挖掘循环

### 第一阶段：发现

技能来自四面八方：

**供应商代码仓库**:AWS、Anthropic、Cloudflare、Supabase，以及社区贡献者，都会发布技能合集。我们追踪着 25 个以上的供应商源。

**社区项目**:GitHub 上到处都是 Claude Code 模板、智能体模式和工作流定义。

**内部模式**：随着我们团队不断解决问题，各种模式会自然浮现，这些模式随后会被正式提炼成技能。

**文档挖掘**：技术文档中常常隐含着技能——流程、检查清单、决策树。

发现是持续不断的。我们用一个技能待办列表，在正式评估之前追踪这些候选项。

### 第二阶段：评估

每个候选项都要经过同一套评估标准：

```yaml
adoption_criteria:
  - fills_real_gap: true      # We lack this capability
  - well_structured: true     # Progressive disclosure
  - actively_maintained: true # Commits in last 6 months
  - portable: true            # Not hyper-specific
  - tested: true              # Evidence of usage
```

五项产品标准必须全部通过，这就是为什么 87% 的候选项会被淘汰。

然后，每个候选项还要经过一次独立的信任评审。我们不会把一个官方供应商代码仓库、一个知名的社区维护者，和一个随机的 GitHub 代码仓库，当作同等可信的来源来对待。

```yaml
trust_review:
  vendor_credibility:
    - ownership_verified       # Official vendor, known maintainer, or internal source
    - maintenance_signal       # Recent commits, issue response, release history
    - adoption_signal          # Evidence of real use, stars alone are not enough
    - provenance_clear         # We can trace where the skill came from
  prompt_injection_scan:
    - hidden_instruction_check # Buried "ignore previous instructions" patterns
    - exfiltration_check       # Prompts that try to leak files, secrets, or context
    - authority_check          # Claims of priority over system or developer rules
  script_audit:
    - inspect_scripts          # Read shell/python/js helpers before adoption
    - network_and_exec_review  # curl|bash, remote downloads, subprocess execution
    - file_and_secret_review   # Env vars, credential access, broad file writes
    - destructive_action_check # rm, reset, overwrite, or unsafe automation
```

可信的供应商会得到一次较轻量的溯源审查，但绝不是可以直接放行的通行证。不可信或未知的来源，会经过更深入的人工审计，而且在脚本被阅读、圈定范围、并被判定为安全之前，我们不会执行任何随附脚本。

**差距分析**：在采纳之前，我们会先搜索自己的注册表：

```bash
uv run orkestra skills search "<capability>"
```

如果我们已经有了，那就不需要它。如果我们已经有相近的东西，我们可能会选择合并，而不是采纳。

**深度与规范评分**：我们还会给候选项打分，评估它对“智能体-技能”模型的运用有多充分。一个孤零零的 `SKILL.md` 依然可能有用，但当一项技能按照 `agentskills.io` 所鼓励的方式，把指令和参考资料、脚本、素材区分开来时，它会更有价值，也更深入。

```yaml
skill_depth:
  - level_1: SKILL.md only                     # Single instruction file
  - level_2: SKILL.md + strong description     # Clear triggers and scope
  - level_3: adds references/                  # Load docs only when needed
  - level_4: adds atomic scripts/              # Small, reviewable helpers
  - level_5: adds assets/examples/templates    # Full progressive disclosure
depth_signals:
  - standards_adherence        # Structure aligns with agentskills.io conventions
  - reference_quality          # Curated references, not giant context dumps
  - script_atomicity           # Focused helpers, not opaque monoliths
  - tool_boundary_clarity      # Clear limits on what the skill can execute
  - community_signal           # Stars/forks/users help, but only as a weak boost
```

GitHub 星标数可以稍微提升一点可信度评分，但它永远无法拯救一个浅薄或不安全的技能。一个星标很多、却只有一份内容含糊的 `SKILL.md` 和不透明脚本的代码仓库，评分会低于一个规模更小、但描述精确、`references/` 经过精心整理、且配有真正用足完整技能能力的原子化辅助工具的代码仓库。

**结构分析**：我们会检查技能的质量：

```bash
wc -l vendor/<repo>/<skill>/SKILL.md  # Size check
ls vendor/<repo>/<skill>/scripts/     # Supporting files
ls vendor/<repo>/<skill>/references/  # Bundled docs
```

如果候选项包含脚本，这项审查就会变得更加严格。一个好的技能，不仅要有用，还必须清晰可读、边界明确，并且可以放心交给智能体去用。仅这一道安全过滤，就足以淘汰掉一大批原本看起来很有意思的候选项。

### 第三阶段：吸纳

当一项技能通过评估后，就会进入注册表。但技能从来不会被原封不动地采纳，而是会被修改以适配我们的系统。

**采纳时的修改**:

1. **元数据规范化**：每项技能都会套用我们的 Frontmatter Schema
2. **K 层级分配**：把技能归入合适的知识层
3. **标签充实**：添加标签以便被发现
4. **工具声明**：明确声明允许使用的工具
5. **章节对齐**：重新组织内容，使其符合我们的模板

吸纳之后一份典型的技能 YAML:

```yaml
metadata:
  identifier: vendor-skill-evaluation
  name: vendor-skill-evaluation
  description: Systematic evaluation of vendor skills for adoption.
  type: workflow
  layer: K4
  semantic_folder: project
  source: core
  last_updated: '2026-01-17'

frontmatter:
  tags:
    - agents
    - meta
    - skill-adoption
    - vendor
  allowed_tools:
    - Bash
    - Read
    - Write
    - Edit
    - Grep
    - Glob
    - Task
```

### 第四阶段：作用域分配

技能会被分配到不同的作用域——这些类别决定了哪些智能体会加载哪些技能：

```yaml
scopes:
  database:
    primary_skills:
      - domains/schema-migration-workflow
      - domains/rpc-validation-checklist
      - vendor/supabase/supabase-database
      - vendor/supabase/supabase-auth

  research:
    primary_skills:
      - identities/research-workflows
      - identities/web-extraction-playbook
      - identities/dataset-discovery-quickstart
```

智能体声明自己的作用域，技能就会被自动分配：

```yaml
# Agent definition
scopes: [database, research]
# Gets: all database skills + all research skills + universal skills
```

### 第五阶段：物化落地

在生产环境中，技能并不是以 YAML 的形式存在的，而是被渲染成 Claude Code 可以加载的 SKILL.md 文件：

```bash
uv run orkestra sync
```

这条命令会：
1. 读取所有技能的 YAML 定义
2. 通过 Jinja 模板渲染它们
3. 把 SKILL.md 文件写入 `.claude/skills/`
4. 按 K 层级（foundations/、identities/、domains/、stacks/、project/）组织

最终的输出结构：

```
.claude/skills/
├── foundations/     # K0: Universal
├── identities/      # K1: Discipline
├── domains/         # K2: Subject
├── stacks/          # K3: Technology
├── project/         # K4: Organization
└── vendor/          # External skills
```

## 休眠作用域模式

我们最有效的模式之一，是“已采纳但不加载”的技能，我们称之为休眠作用域。

以来自 k-dense-scientific 代码仓库的科学计算技能为例。我们已经采纳了 120 多项技能，涵盖生物信息学、化学、量子计算和临床信息学。但我们的大多数智能体，并不需要分子对接或基因表达分析。

与其把全部 120 项技能都加载进每一个智能体（把上下文窗口撑爆），我们的做法是：

1. 用一个特定的作用域（例如 `bioinformatics`）来**采纳**这些技能
2. 让它们保持**休眠**状态——已注册，但不加载
3. 只有当某个智能体声明了那个作用域时，才**启用**它们

```yaml
# In scopes.yaml - dormant scope
bioinformatics:
  description: "Bioinformatics and genomics"
  primary_skills: []  # Empty - skills exist but aren't loaded

# When an agent needs bioinformatics:
# Agent YAML
scopes: [research, bioinformatics]  # Now loads bioinformatics skills
```

这种模式让我们的注册表里可以容纳 466 项技能，而典型的智能体只会加载其中 40 到 60 项真正相关的技能。

## 技能类型

技能分为三种认知模式：

### 工作流（Workflow）

有序的流程步骤：“第一步做 X，第二步做 Y，第三步做 Z”

```yaml
type: workflow
# Examples: schema-migration-workflow, mining-session-workflow
```

### 准则（Discipline）

行为护栏：“始终 X”“绝不 Y”“优先 Z”

```yaml
type: discipline
# Examples: test-first-discipline, evidence-based-completion
```

### 检查清单（Checklist）

验证标准：“确认 X”“核实 Y”“检查 Z”

```yaml
type: checklist
# Examples: auth-validation-checklist, secrets-audit-checklist
```

## 质量门禁

每项技能在发布前，都必须通过校验：

```yaml
validation:
  file_exists: true           # Skill file at declared path
  frontmatter_valid: true     # Frontmatter parses correctly
  sections_complete: true     # Expected sections present
  tools_registered: true      # Declared tools exist in registry
```

描述必须在 50 到 400 个字符之间，并带有触发短语（“Use when...”“When you need...”），这样 Claude Code 才知道什么时候该建议使用它们。

我们会持续进行校验：

```bash
uv run orkestra validate --show-warnings
```

## 供应商生态

我们的 373 项供应商技能来自：

| 供应商 | 技能数 | 领域 |
|----------|--------|--------|
| AWS Agent | 19 | 云服务 |
| Anthropic | 12 | 文档生成 |
| Cloudflare | 8 | 边缘计算 |
| Supabase | 5 | 数据库 |
| k-dense | 100+ | 科学计算 |
| silvainfm | 4 | 数据科学 |
| Java Developer Kit | 45+ | Spring/Java |
| Vercel | 1 | 浏览器自动化 |

每个供应商源都在 metadata.yaml 中声明：

```yaml
vendor_roots:
  - path: vendor/aws-agent-skills
    provider: aws
  - path: vendor/k-dense-scientific/scientific-skills
    provider: k-dense
  - path: vendor/supabase-skills
    provider: supabase
```

当 `orkestra sync` 运行时，供应商技能会以各自的供应商命名空间，被符号链接进 `.claude/skills/vendor/`。

## 我们学到了什么

**挑剔是值得的。** 采纳一切看起来有用的东西，诱惑力很大。但每一项技能都要消耗 Token。每项技能平均消耗 2,834 个 Token，一旦臃肿起来，伤害来得很快。我们 13% 的采纳率，让智能体保持精简。

**结构成就可发现性。** K 层级体系不只是一种组织方式，更关乎可移植性。K0 技能可以在任何地方复用；K4 技能则是有意设计成特定于项目的。这种清晰度，能帮助人类和智能体都找到自己需要的东西。

**休眠作用域能带来规模。** 你可以采纳数百项技能，而不必把它们全部加载进来。作用域让你能构建一份全面的注册表，同时让每个智能体的上下文窗口保持在可控范围内。

**采纳时的修改必不可少。** 原始的供应商技能，很少能直接契合你的系统。吸纳流程——添加元数据、分配层级、充实标签——让外部技能能够在内部真正发挥作用。

**挖掘是持续不断的。** 3,500 这个数字还在不断增长。新的供应商代码仓库不断出现，社区模式不断涌现，内部工作流不断沉淀固化。这个循环永不停止。

## 接下来的计划

我们正在推进几项改进：

1. **自动化差距检测**：当某个常见的智能体失败，原本可以被一项尚未采纳的技能解决时，发出提醒
2. **技能弃用工作流**：为退役那些已被取代或不再使用的技能，建立正式流程
3. **跨技能依赖**：明确声明技能之间的前置依赖关系
4. **使用情况分析**：追踪智能体究竟真正调用了哪些技能，而不只是加载了哪些

技能挖掘循环是一种基础设施，它并不光鲜亮丽，但正是它，让 41 个智能体能够在遵守上下文限制的同时，连贯一致地驾驭 466 项能力。

这就是 3,500 如何变成 466 的故事。不是靠忽略掉 3,000 个，而是靠系统性地评估它们，只采纳真正管用的那些。

---

*想看看这套技能系统的实际运作？查看 `uv run orkestra skills list`，探索我们当前的注册表。*