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

本文中的数字反映的是发布时(2026 年 1 月)的系统状态。如需查看最新数据,请参阅我们的 团队页面。

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 模板、智能体模式和工作流定义。

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

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

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

第二阶段:评估

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

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 代码仓库,当作同等可信的来源来对待。

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

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

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

uv run orkestra skills search "<capability>"

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

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

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/ 经过精心整理、并且真正用足了完整技能能力的原子化辅助工具的代码仓库。

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

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:

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

第四阶段:作用域分配

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

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

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

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

第五阶段:物化落地

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

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. 只有当某个智能体声明了那个作用域时,才启用它们

# 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”

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

准则(Discipline)

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

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

检查清单(Checklist)

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

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

质量门禁

每项技能在发布前,都必须通过校验:

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 才知道什么时候该建议使用它们。

我们会持续进行校验:

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 中声明:

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,探索我们当前的注册表。