Ngày 12/8, GitHub công bố hướng dẫn migration cho Agent Plugins 1.0 — một spec thực ra đã ra mắt trước đó một tuần, vào 6/8, với AWS, Anysphere (Cursor), Microsoft, OpenAI và Vercel là đối tác launch, còn Google gia nhập ngay hôm đó với vai trò core maintainer. Đó là một liên minh rộng hơn hẳn đa số thông báo “open standard” thường thấy, và đáng để hiểu vì sao: nó giải quyết một vấn đề thật, gây khó chịu thật, mà bất kỳ ai từng ship agent tooling trên nhiều hơn một client đều đã gặp.

Vấn đề: mỗi agent client muốn một manifest riêng

Nếu bạn từng xây một skill hoặc một MCP server rồi cố phân phối nó cho nhiều hơn một công cụ AI coding, bạn đã biết cảm giác này. Copilot CLI muốn một kiểu directory layout. Copilot app trong VS Code muốn metadata hơi khác. Cursor có config format riêng. Claude Code cũng có format riêng. Khả năng cốt lõi — “đây là skill biết cách triage flaky test” hay “đây là MCP server nói chuyện với deploy API nội bộ của công ty” — giống hệt nhau ở mọi nơi. Nhưng bạn vẫn phải duy trì ba bốn manifest gần như trùng lặp chỉ để phân phối cùng một thứ, và mỗi lần cập nhật skill, bạn phải sửa ở ba bốn chỗ rồi hy vọng không gõ nhầm ở chỗ nào.

Agent Plugins 1.0 đóng gói skill và MCP server thành một đơn vị cài đặt duy nhất mà bất kỳ client tuân thủ spec nào cũng dùng được. Một plugin, một repo, một nguồn sự thật duy nhất, chạy được trên extension Copilot của VS Code, Copilot CLI, Copilot app, và — theo danh sách đối tác launch — một tập hợp client bên thứ ba đang mở rộng.

Gói thực tế trông như thế nào

Hướng dẫn migration mô tả rõ ràng. Một plugin có:

{
  "$schema": "https://github.com/schemas/agent-plugin-1.0.json",
  "name": "flaky-test-triage",
  "version": "1.2.0",
  "description": "Diagnoses and proposes fixes for flaky tests",
  "skills": "./skills",
  "mcp": "./mcp.json",
  "vendor_extensions": {
    "com.github.copilot": {
      "categories": ["testing", "ci"]
    }
  }
}

Bốn điều đáng chú ý cho ai chuẩn bị làm migration này:

  1. $schema không phải trang trí. Đây là cách các client validate plugin thực sự tuân thủ 1.0 chứ không phải một bản draft cũ hơn hay một dialect riêng của client nào đó. Bỏ qua nó, đừng ngạc nhiên nếu hành vi không nhất quán giữa các client thay vì báo lỗi rõ ràng — vốn là trải nghiệm debug tệ hơn nhiều.
  2. Skill nằm dưới skills/, không rải rác ở root repo. Đây là thay đổi cấu trúc lớn nhất nếu bạn đang migrate một extension Copilot-only có sẵn — chuẩn bị tinh thần di chuyển file thật, không chỉ thêm manifest.
  3. Config MCP là một mcp.json riêng, không nhúng vào manifest plugin. Đây là một tách bạch hợp lý: config MCP server của bạn có thể được version, test, và suy luận độc lập với phần đóng gói skill xung quanh nó.
  4. Hành vi riêng của từng vendor nằm trong một block có namespace (com.github.copilot/, và tương tự có thể là com.anysphere.cursor/ cho các vendor khác) mà client tuân thủ spec từ vendor khác đơn giản là bỏ qua. Đây chính là phần khiến standard này thực sự hoạt động như một standard chứ không phải một định dạng lowest-common-denominator — bạn không mất đi sự phong phú riêng của từng vendor, chỉ là rào nó lại để không phá vỡ tính tương thích.

Discovery và governance: đây là phần thú vị với một lead

Hai điều trong spec nhắm thẳng vào leadership kỹ thuật, không phải developer cá nhân.

Discovery diễn ra qua các marketplace — “Awesome Copilot” marketplace của chính GitHub là implementation tham chiếu, nhưng spec hỗ trợ extraKnownMarketplaces như một setting governance hạng nhất, nghĩa là tổ chức của bạn có thể đăng ký một marketplace nội bộ cho plugin độc quyền mà không cần public nó.

Governance được xử lý qua managed-settings.json, do admin doanh nghiệp kiểm soát, không phải từng developer:

{
  "enabledPlugins": {
    "flaky-test-triage": "auto-install",
    "experimental-refactor-agent": "blocked"
  },
  "extraKnownMarketplaces": ["https://plugins.internal.acme.com"],
  "strictKnownMarketplaces": true
}

strictKnownMarketplaces: true là setting mà tôi nghĩ đa số tổ chức bị regulate chặt sẽ bật ngay lập tức — nó giới hạn việc cài đặt chỉ trong những marketplace bạn đã phê duyệt rõ ràng, đóng lại rủi ro “developer cài một plugin ngẫu nhiên từ một repo GitHub ngẫu nhiên” — vốn là câu hỏi mở trong agent tooling từ khi MCP server bắt đầu nở rộ. Kết hợp với allowlist ở tầng MCP, bạn có hai lớp kiểm soát: plugin nào được phép cài, và những plugin đó được phép nói chuyện với MCP server nào.

Nếu tổ chức bạn vẫn đang trì hoãn một chính sách “engineer được phép cài skill và MCP server nào,” đây là lần đầu tiên có một cơ chế chuẩn để thực sự thực thi chính sách đó, thay vì dựa vào tribal knowledge và sự cẩn trọng khi review code.

Liên hệ với MCP

Đáng nói rõ về sự phân tầng ở đây, vì rất dễ nhầm lẫn hai thứ này. MCP chuẩn hóa cách một agent nói chuyện với một tool hay data source tại runtime — protocol cho tool call, resource access, v.v. Agent Plugins 1.0 chuẩn hóa cách bạn đóng gói và phân phối một bó skill cùng config MCP server sao cho việc cài đặt là một hành động duy nhất trên mọi client. MCP là wire protocol; Agent Plugins là lớp đóng gói và phân phối nằm cao hơn một tầng. Bạn vẫn viết MCP server theo đúng cách hiện tại — Agent Plugins chỉ cho bạn một manifest để ship chúng cùng skill, thay vì lặp lại logic ship đó cho từng client.

Lời cảnh báo thành thật: đây là bản 1.0

Một launch với sáu vendor là tín hiệu mạnh về ý định, nhưng một spec 1.0 với nhiều implementer độc lập như vậy cũng là nơi bạn nên lường trước sự phân kỳ ở các edge case. Để ý:

  • Cách diễn giải vendor_extensions khác nhau giữa các client. Quy ước namespace ngăn được lỗi vỡ hoàn toàn, nhưng không đảm bảo mọi client xử lý field không xác định ở top-level giống hệt nhau — hãy test trên mọi client bạn thực sự hỗ trợ, đừng giả định tuân thủ spec đồng nghĩa với hành vi giống nhau.
  • Niềm tin marketplace vẫn đang trong giai đoạn khởi động. strictKnownMarketplaces chỉ tốt bằng kỷ luật của tổ chức bạn trong việc curate allowlist. Một standard mới sáng bóng không loại bỏ nhu cầu có người thực sự vet những gì nằm trong đó.
  • Chi phí migration không bằng không. Di chuyển skill của một extension có sẵn vào skills/ và tách mcp.json là việc cơ học nhưng không miễn phí công sức — hãy tính nó như một task migration thật, không phải một chỉnh sửa config nhỏ, nếu bạn đang duy trì plugin hiện tại.

Việc nên làm ngay tuần này

Nếu team bạn đang publish bất kỳ Copilot extension, skill, hay MCP server nội bộ nào: đọc hướng dẫn migration, và nếu bạn hỗ trợ nhiều hơn một AI coding client trong tổ chức engineering, việc này đáng được ưu tiên hơn phần lớn backlog agent-tooling khác — đó là khác biệt giữa việc duy trì N manifest mãi mãi và duy trì một manifest duy nhất. Nếu bạn chỉ là người tiêu thụ plugin chứ không publish, việc cần làm ngay là dựng managed-settings.json với strictKnownMarketplaces: true trước khi engineer của bạn bắt đầu cài thứ gì đó từ những marketplace bạn chưa review.

Nguồn: GitHub Changelog — Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app

Xuất nội dung

Bình luận