Chuyển tới nội dung
cd /blog

Khai thác Skill: Từ 3.500 ứng viên đến 466 năng lực

[Kiến trúc][Kỹ năng]

> Chúng tôi sàng lọc 3.500 skill ứng viên và tiếp nhận 466 skill. Một vòng lặp khai thác và nạp có hệ thống để xây dựng một thư viện skill AI agent mạch lạc ở quy mô lớn.

Các con số trong bài này phản ánh hệ thống tại thời điểm xuất bản (tháng 1/2026). Xem trang team của chúng tôi để biết số liệu hiện tại.

Vấn đề 3.500 Skill

Khi chúng tôi bắt đầu xây dựng một hệ thống điều phối agent, chúng tôi đối mặt với một thách thức thú vị: có hàng nghìn skill tiềm năng rải rác khắp hệ sinh thái AI. Repository GitHub, tài liệu vendor, dự án cộng đồng, các mẫu nội bộ - skill tồn tại ở khắp mọi nơi. Nhưng cái nào thực sự quan trọng? Cái nào thực sự hoạt động? Và làm sao bạn duy trì được một thư viện skill mạch lạc mà agent thực sự có thể dùng?

Câu trả lời của chúng tôi: một vòng lặp khai thác và nạp có hệ thống.

Các con số hôm nay

Chỉ hơn ba tháng sau khi Anthropic ra mắt Agent Skills vào ngày 16 tháng 10 năm 2025, đây là vị trí của chúng tôi khi bài viết này được xuất bản vào ngày 27 tháng 1 năm 2026:

Chỉ số Số lượng
Ứng viên đã xác định 3.500+
Skill đã tiếp nhận 466
Skill vendor 373
Skill nội bộ 93
Vendor đang hoạt động 25+
Token trung bình mỗi skill 2.834
Công cụ được tham chiếu 89
Tag riêng biệt 635

Chúng tôi đã rà soát hơn 3.500 skill ứng viên. Chúng tôi đã tiếp nhận 466. Đó là tỷ lệ tiếp nhận 13% - và sự chọn lọc đó là có chủ đích.

Hệ thống tầng tri thức

Không phải mọi skill đều được tạo ra ngang hàng. Chúng tôi tổ chức chúng thành năm tầng tri thức (K0-K4), mỗi tầng đại diện cho một phạm vi áp dụng khác nhau:

K0: Foundations (Phổ quát)

Skill mà mọi agent nên có. Chúng đại diện cho năng lực “người suy nghĩ giỏi” hoạt động ở bất cứ đâu.

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

Skill K0 có thể mang theo đến bất kỳ dự án nào, domain nào, stack nào. Chúng mã hóa các mẫu nhận thức phổ quát.

K1: Identities (Kỷ luật)

Skill kiểu “kỹ sư giỏi” hoặc “nhà nghiên cứu giỏi” áp dụng được xuyên suốt các dự án trong một ngành.

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

K2: Domains (Chuyên môn chủ đề)

Skill kiểu “chuyên gia database giỏi” hoặc “kỹ sư bảo mật giỏi” có thể mang theo trong một lĩnh vực.

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: Stacks (Công nghệ)

Skill kiểu “người dùng Supabase giỏi” hoặc “nhà phát triển Cloudflare giỏi” cho các stack công nghệ cụ thể.

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

K4: Project (Tổ chức)

Skill đặc thù cho tổ chức và quy trình của chúng tôi.

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

Vòng lặp khai thác

Giai đoạn 1: Khám phá

Skill đến từ khắp mọi nơi:

Repository Vendor: AWS, Anthropic, Cloudflare, Supabase, và các cộng tác viên cộng đồng phát hành các bộ sưu tập skill. Chúng tôi theo dõi 25+ vendor root.

Dự án cộng đồng: GitHub đầy ắp các template Claude Code, mẫu agent, và định nghĩa quy trình.

Mẫu nội bộ: Khi đội của chúng tôi giải quyết các vấn đề, các mẫu xuất hiện. Chúng được hình thức hóa thành skill.

Khai thác tài liệu: Tài liệu kỹ thuật thường chứa các skill ngầm định - quy trình, checklist, cây quyết định.

Việc khám phá diễn ra liên tục. Chúng tôi dùng một backlog skill để theo dõi các ứng viên trước khi đánh giá chính thức.

Giai đoạn 2: Đánh giá

Mỗi ứng viên đi qua cùng một rubric:

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

Cả năm tiêu chí sản phẩm đều phải đạt. Đây là lý do 87% ứng viên bị loại.

Sau đó mỗi ứng viên đi qua một lượt rà soát độ tin cậy riêng biệt. Chúng tôi không xem một repository vendor chính thức, một maintainer cộng đồng nổi tiếng, và một repo GitHub ngẫu nhiên là những nguồn chân lý tương đương nhau.

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

Các vendor đáng tin cậy được rà soát nguồn gốc nhẹ hơn, nhưng không phải là một vé miễn phí. Các nguồn không đáng tin cậy hoặc không rõ danh tính phải trải qua một lượt kiểm toán thủ công sâu hơn, và chúng tôi không thực thi các script đi kèm cho đến khi chúng đã được đọc, xác định phạm vi, và phân loại là an toàn.

Phân tích khoảng trống: Trước khi tiếp nhận, chúng tôi tìm kiếm trong registry của mình:

uv run orkestra skills search "<capability>"

Nếu chúng tôi đã có nó rồi, chúng tôi không cần nó nữa. Nếu chúng tôi có thứ gì đó gần giống, chúng tôi có thể hợp nhất thay vì tiếp nhận.

Chấm điểm độ sâu và tiêu chuẩn: Chúng tôi cũng chấm điểm mức độ ứng viên sử dụng đầy đủ mô hình agent-skill. Một SKILL.md đơn lẻ vẫn có thể hữu ích, nhưng các skill sâu hơn có giá trị hơn khi chúng tách biệt các chỉ dẫn khỏi tham chiếu, script, và tài sản theo cách mà agentskills.io khuyến khích.

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

Sao GitHub có thể nâng điểm tín nhiệm lên một chút, nhưng chúng không bao giờ cứu được một skill hời hợt hoặc không an toàn. Một repo nhiều sao với một SKILL.md mơ hồ và các script mờ đục chấm điểm thấp hơn một repo nhỏ hơn với mô tả chính xác, references/ được tuyển chọn, và các helper nguyên tử thực sự tận dụng đầy đủ năng lực skill.

Phân tích cấu trúc: Chúng tôi kiểm tra chất lượng skill:

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

Nếu một ứng viên bao gồm script, lượt rà soát đó trở nên nghiêm ngặt hơn. Một skill tốt không chỉ hữu ích; nó phải dễ hiểu, có giới hạn, và an toàn để giao cho một agent. Riêng bộ lọc an toàn đó đã loại một phần đáng kể các ứng viên khác thì thú vị.

Giai đoạn 3: Nạp (Ingestion)

Khi một skill vượt qua đánh giá, nó bước vào registry. Nhưng skill không bao giờ được tiếp nhận nguyên trạng. Chúng được chỉnh sửa để phù hợp với hệ thống của chúng tôi.

Các chỉnh sửa khi tiếp nhận:

  1. Chuẩn hóa Metadata: Mọi skill nhận được schema frontmatter của chúng tôi
  2. Gán tầng K: Skill được đặt vào tầng tri thức phù hợp
  3. Làm giàu Tag: Tag được thêm vào để hỗ trợ khám phá
  4. Khai báo công cụ: Các công cụ được phép được khai báo tường minh
  5. Căn chỉnh phần: Nội dung được tái cấu trúc để khớp với template của chúng tôi

Một skill YAML điển hình sau khi nạp:

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

Giai đoạn 4: Gán phạm vi

Skill được gán vào các scope - các danh mục xác định agent nào nạp skill nào:

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 khai báo scope của chúng, và skill được tự động gán:

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

Giai đoạn 5: Hiện thực hóa

Skill không tồn tại dưới dạng YAML trong production. Chúng được render thành các file SKILL.md mà Claude Code có thể nạp:

uv run orkestra sync

Lệnh này:

  1. Đọc tất cả định nghĩa skill YAML
  2. Render chúng qua các template Jinja
  3. Ghi các file SKILL.md vào .claude/skills/
  4. Tổ chức theo tầng K (foundations/, identities/, domains/, stacks/, project/)

Cấu trúc đầu ra cuối cùng:

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

Mẫu phạm vi ngủ đông (Dormant Scope)

Một trong những mẫu mạnh mẽ nhất của chúng tôi là các skill “đã tiếp nhận nhưng chưa nạp.” Chúng tôi gọi chúng là các scope ngủ đông.

Hãy xem xét các skill điện toán khoa học từ repository k-dense-scientific. Chúng tôi đã tiếp nhận hơn 120 skill bao phủ tin sinh học, hóa học, điện toán lượng tử, và tin học lâm sàng. Nhưng hầu hết các agent của chúng tôi không cần docking phân tử hay phân tích biểu hiện gen.

Thay vì nạp cả 120 skill vào mọi agent (làm phình to cửa sổ ngữ cảnh), chúng tôi:

  1. Tiếp nhận các skill với một scope cụ thể (ví dụ: bioinformatics)
  2. Giữ chúng ở trạng thái ngủ đông - đã đăng ký nhưng chưa nạp
  3. Kích hoạt chúng chỉ khi một agent khai báo scope đó
# 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

Mẫu này cho phép chúng tôi có 466 skill trong registry trong khi các agent điển hình chỉ nạp 40-60 skill liên quan.

Các loại Skill

Skill xuất hiện dưới ba mẫu nhận thức:

Workflow

Các bước quy trình có thứ tự: “1. Làm X, 2. Sau đó Y, 3. Cuối cùng Z”

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

Discipline

Rào chắn hành vi: “Luôn X”, “Không bao giờ Y”, “Ưu tiên Z”

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

Checklist

Tiêu chí xác minh: “Xác nhận X”, “Kiểm chứng Y”, “Kiểm tra Z”

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

Cổng chất lượng

Mọi skill phải vượt qua xác thực trước khi lên sóng:

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

Mô tả phải có 50-400 ký tự với các cụm từ kích hoạt (“Dùng khi…”, “Khi bạn cần…”) để Claude Code biết khi nào nên gợi ý chúng.

Chúng tôi xác thực liên tục:

uv run orkestra validate --show-warnings

Hệ sinh thái Vendor

373 skill vendor của chúng tôi đến từ:

Provider Skill Domain
AWS Agent 19 Dịch vụ đám mây
Anthropic 12 Sinh tài liệu
Cloudflare 8 Điện toán biên
Supabase 5 Database
k-dense 100+ Điện toán khoa học
silvainfm 4 Khoa học dữ liệu
Java Developer Kit 45+ Spring/Java
Vercel 1 Tự động hóa trình duyệt

Mỗi vendor root được khai báo trong 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

Khi orkestra sync chạy, các skill vendor được symlink vào .claude/skills/vendor/ kèm namespace nhà cung cấp của chúng.

Những gì chúng tôi đã học được

Sự chọn lọc mang lại kết quả. Thật hấp dẫn khi muốn tiếp nhận mọi thứ trông có vẻ hữu ích. Nhưng mỗi skill đều tốn token. Với trung bình 2.834 token mỗi skill, sự phình to gây tổn hại nhanh chóng. Tỷ lệ tiếp nhận 13% của chúng tôi giữ cho các agent gọn nhẹ.

Cấu trúc cho phép khám phá. Hệ thống tầng K không chỉ là tổ chức - đó là về khả năng mang theo. Skill K0 có thể tái sử dụng ở bất cứ đâu. Skill K4 có chủ đích đặc thù cho dự án. Sự rõ ràng này giúp cả con người lẫn agent tìm thấy những gì họ cần.

Scope ngủ đông mở rộng quy mô. Bạn có thể tiếp nhận hàng trăm skill mà không cần nạp tất cả. Scope cho phép bạn xây dựng một registry toàn diện trong khi vẫn giữ cửa sổ ngữ cảnh của từng agent ở mức quản lý được.

Chỉnh sửa khi tiếp nhận là thiết yếu. Skill vendor thô hiếm khi phù hợp với hệ thống của bạn. Quy trình nạp - thêm metadata, gán tầng, làm giàu tag - khiến các skill bên ngoài hoạt động được ở nội bộ.

Khai thác diễn ra liên tục. Con số 3.500 vẫn tiếp tục tăng. Các repo vendor mới xuất hiện. Các mẫu cộng đồng nổi lên. Các quy trình nội bộ được củng cố. Vòng lặp không bao giờ dừng lại.

Điều gì tiếp theo

Chúng tôi đang làm việc trên một số cải tiến:

  1. Phát hiện khoảng trống tự động: Cảnh báo khi các lỗi agent phổ biến có thể được giải quyết bởi một skill chưa được tiếp nhận
  2. Quy trình khai tử skill: Quy trình chính thức để loại bỏ các skill đã bị thay thế hoặc không được dùng
  3. Phụ thuộc liên-skill: Khai báo tường minh các điều kiện tiên quyết của skill
  4. Phân tích sử dụng: Theo dõi skill nào agent thực sự gọi so với chỉ nạp

Vòng lặp khai thác skill là hạ tầng. Nó không hào nhoáng. Nhưng đó là thứ khiến 41 agent hoạt động mạch lạc với 466 năng lực trong khi vẫn nằm trong giới hạn ngữ cảnh.

Đó là câu chuyện về việc 3.500 trở thành 466 như thế nào. Không phải bằng cách bỏ qua 3.000 - mà bằng cách đánh giá chúng có hệ thống và chỉ tiếp nhận những gì thực sự hoạt động.


Muốn xem hệ thống skill hoạt động trong thực tế? Hãy xem uv run orkestra skills list để khám phá registry hiện tại của chúng tôi.

Đọc thêm liên quan

Thêm từ nhật ký xây dựng Maguyva

Tự cải thiện đệ quy theo ngôn ngữ: Mài giũa trí tuệ mã nguồn trên khoảng 280 ngôn ngữ_

Chúng tôi hỗ trợ trí tuệ mã nguồn cho khoảng 280 ngôn ngữ. Không con người nào có thể tự tay rà soát hết được. Vì vậy chúng tôi xây dựng một vòng lặp tự cải thiện đệ quy theo ngôn ngữ — kiểm tra ngẫu nhiên, dùng LLM làm giám khảo, sửa từng thứ một, xác thực lại — và chạy nó với một đội quân agent cách ly cho đến khi việc trích xuất thực sự đúng, chứ không chỉ xanh (green).

[Kiến trúc][Ngôn ngữ][Tác nhân]