Làm Cùng Long.
← Quay lại Kho ghi chú
Automation & AI Workflow · 10 phút đọc ·

Agent Plugins là gì? Google Cloud đang đóng gói Skills + MCP thành lớp năng lực cho coding agent

Nếu đã dùng coding agent một thời gian, rất dễ rơi vào một hệ thống kiểu này:

  • một file instruction cho project;
  • vài skill tự viết;
  • một số MCP server;
  • biến môi trường cho API key;
  • script helper;
  • tài liệu tham khảo;
  • quy tắc an toàn;
  • cách cài khác nhau cho Codex, Claude Code, Antigravity hoặc một client khác.

Từng phần đều hợp lý.

Vấn đề xuất hiện khi số lượng phần tăng lên: làm sao đóng gói một năng lực hoàn chỉnh để agent có thể dùng ổn định, thay vì yêu cầu người dùng tự nối từng mảnh?

Agent Plugins là một câu trả lời cho bài toán đó.

Điểm quan trọng đầu tiên:

Agent Plugins không thay thế Agent Skills và cũng không thay thế MCP. Nó đứng ở lớp đóng gói phía trên.

Mục lục

1. Ba khái niệm dễ bị trộn lẫn

Agent Skill

Có thể hiểu một skill như một gói hướng dẫn chuyên môn và quy trình để agent biết cách thực hiện một loại công việc.

Ví dụ:

  • audit một campaign;
  • review pull request;
  • triển khai Cloud Run;
  • xử lý một loại báo cáo;
  • làm preflight trước khi publish.

Skill có thể chứa instruction, script và reference.

Nó thiên về procedure và domain knowledge.

MCP

Model Context Protocol giải quyết một lớp khác: kết nối agent/model với tool, data hoặc system bên ngoài qua một contract chuẩn.

Ví dụ:

  • đọc dữ liệu;
  • gọi API;
  • thao tác hệ thống;
  • truy xuất tài liệu;
  • gọi một service có thật.

MCP thiên về connectivity và capability access.

Agent Plugin

Theo Agent Plugins Specification 1.0.0, plugin là một package có manifest bắt buộc và có thể chứa các component như skills và MCP server configuration.

Nói ngắn:

Skill = cách làm.
MCP = đường kết nối tới năng lực/dữ liệu.
Plugin = cách đóng gói những phần liên quan để phân phối và cài đặt.

Ba lớp có thể đi cùng nhau nhưng không nên coi là một.

2. Agent Plugins giải quyết vấn đề gì?

Google Cloud mô tả vấn đề là tool coupling.

Một agent làm việc thật hiếm khi chỉ cần một skill.

Ví dụ để agent hỗ trợ onboarding Google Cloud, nó có thể phải:

  1. hiểu tài khoản/project đang ở trạng thái nào;
  2. biết nguyên tắc IAM;
  3. biết authentication phù hợp cho local development;
  4. đọc tài liệu mới nhất;
  5. chạy gcloud nếu được phép;
  6. tránh tạo key hoặc commit secret sai cách;
  7. xin xác nhận trước hành động ảnh hưởng resource.

Nếu tất cả được chia thành các thành phần rời, người dùng phải tự biết cách kết hợp.

Plugin gom các thành phần có cùng mục tiêu thành một bundle.

Điểm có giá trị không phải “cài ít lệnh hơn”.

Giá trị lớn hơn là capability có biên rõ hơn.

Thay vì nói:

“Tôi có 12 MCP server, 8 skill và 4 file instruction.”

ta có thể nói:

“Tôi cài capability Google Cloud Developer.”

Đây là bước chuyển từ quản lý component sang quản lý capability.

3. Bên trong một plugin có gì?

Agent Plugins v1.0.0 định nghĩa một plugin là một directory có file manifest plugin.json ở root.

Cấu trúc khái niệm có thể là:

my-plugin/
├── plugin.json
├── skills/
│   └── deploy/
│       └── SKILL.md
└── mcp.json

Specification còn cho phép extension namespace dành cho hành vi riêng của từng client.

Điều đáng chú ý là chuẩn này cố tình giữ phần portable core tương đối nhỏ.

Nó không cố chuẩn hóa toàn bộ trải nghiệm agent.

Nó chủ yếu tạo một “mức sàn tương thích” để:

  • client biết plugin là gì;
  • biết đọc manifest ở đâu;
  • biết skills nằm ở đâu;
  • biết MCP configuration nằm ở đâu;
  • version nào đang được target.

INTERPRETATION: Đây là một lựa chọn thiết kế hợp lý. Nếu một standard cố chuẩn hóa cả UX, permission, distribution, hooks, memory và mọi hành vi riêng của client ngay từ đầu, nó rất dễ trở nên quá lớn và khó được chấp nhận.

4. Google Cloud Developer Plugin làm gì?

Google gọi google-cloud-developer là foundational plugin.

Nó tập trung vào những việc gần như mọi developer dùng Google Cloud đều có thể gặp:

  • authentication;
  • authorization;
  • project management;
  • gcloud CLI operations;
  • guardrails;
  • tìm tài liệu chính thức.

Trong ví dụ onboarding của Google, agent không chỉ đưa một danh sách command.

Nó làm ba việc đáng chú ý.

Một: kiểm tra environment.

Agent có thể xem CLI đã có chưa và nhận biết một số prerequisite trong môi trường hiện tại.

Hai: review rủi ro trước khi hành động.

Google nêu ví dụ về IAM best practices và nguy cơ key bị lộ hoặc commit vào Git.

Ba: đưa roadmap và xin phép trước khi sửa resource.

Đây là pattern rất nên giữ khi tự xây agent:

Detect
→ Explain
→ Plan
→ Ask
→ Act
→ Verify

Thay vì:

Prompt
→ Act ngay

Khác biệt này đặc biệt quan trọng với cloud, repository, database, quảng cáo hoặc bất kỳ hệ thống production nào.

5. Vì sao Developer Knowledge MCP quan trọng?

Một khó khăn kinh điển của coding agent là kiến thức trong model có thể cũ hơn tài liệu hiện tại.

Với cloud platform, điều đó nguy hiểm vì:

  • command thay đổi;
  • API thay đổi;
  • policy thay đổi;
  • product mới xuất hiện;
  • pricing và quota thay đổi;
  • best practice bảo mật thay đổi.

Google Cloud Developer Plugin bundle cấu hình cho Developer Knowledge MCP, giúp agent grounding bằng tài liệu developer chính thức cập nhật hơn.

Điểm này liên quan trực tiếp tới Context Engineering.

Thay vì nhét hàng trăm trang docs vào system prompt, agent được trao một cơ chế retrieval đúng nguồn.

Cách nghĩ tốt hơn là:

Không tối đa hóa lượng context. Tối đa hóa xác suất agent tìm được context đúng khi nó cần.

Với hệ thống cá nhân hoặc doanh nghiệp, có thể áp logic tương tự:

  • policy nội bộ → knowledge connector;
  • schema → registry;
  • API docs → official MCP/docs;
  • SOP → skill;
  • dữ liệu live → tool;
  • secret → environment/secret manager, không nằm trong skill.

6. Plugin không đồng nghĩa với quyền vô hạn

Đây là phần cần phản biện.

Một plugin tiện hơn cũng có nghĩa người dùng có thể cài một bundle chứa nhiều năng lực hơn mà không đọc hết từng phần.

Specification giải quyết cấu trúc package.

Nó không tự động bảo đảm rằng plugin an toàn cho mọi environment.

Khi review một plugin, tôi sẽ kiểm tra ít nhất bốn lớp.

1. Knowledge surface

Skill đưa instruction gì vào agent?

Có rule nào xung đột project không?

Có hướng agent tới hành động quá rộng không?

2. Tool surface

Plugin thêm MCP server nào?

Server đó read-only hay có write action?

Có action xóa, deploy, gửi mail, đổi cấu hình không?

3. Credential surface

Plugin cần API key/token nào?

Secret được lưu ở đâu?

Có nguy cơ bị log hoặc đưa vào context không?

4. Approval surface

Action nào chạy tự động?

Action nào cần human approval?

Có rollback và audit log không?

Một plugin tốt không chỉ “làm được nhiều”.

Nó cần giúp người dùng hiểu nó được phép làm tới đâu.

7. Khi nào nên đóng gói thành plugin?

Không phải workflow nào cũng cần plugin.

Nếu chỉ có một instruction nhỏ và một tool đơn giản, đóng gói thêm một lớp có thể là overbuild.

Plugin đáng cân nhắc khi có ít nhất một trong các dấu hiệu sau.

Nhiều component phải luôn đi cùng nhau

Ví dụ một workflow deploy cần:

  • skill triển khai;
  • skill rollback;
  • MCP docs;
  • MCP cloud;
  • policy approval.

Muốn phân phối cho nhiều agent client

Nếu một team có Codex, Claude Code và Antigravity, package portable có thể giảm duplicate config.

Capability có lifecycle riêng

Ví dụ “Google Ads Audit” hoặc “Data QA” có version, test, changelog và owner riêng.

Cần installation contract rõ

Người dùng cần biết cài gì, cần credential gì và dependency nào bắt buộc.

Ngược lại, nếu capability chưa ổn định, hãy để ở dạng skill/workflow nhỏ trước.

Đừng biến “plugin hóa” thành mục tiêu.

8. Một framework thiết kế plugin thực dụng

Tôi sẽ thiết kế từ job to be done, không từ tool.

Ví dụ capability:

“Review và triển khai một thay đổi Cloud Run an toàn.”

Sau đó chia thành 6 lớp.

Intent

User muốn đạt outcome gì?

Context

Agent cần biết project, environment, policy nào?

Skill

Quy trình chuẩn là gì?

Tool

Agent cần đọc/gọi hệ thống nào?

Boundary

Action nào được phép tự động?

Evidence

Agent phải trả lại bằng chứng gì sau khi xong?

Một plugin tốt có thể được mô tả bằng contract:

Input
→ Context
→ Decision
→ Tool calls
→ Approval gates
→ Verification
→ Output + log

Nếu không mô tả được contract này, có thể capability vẫn chưa đủ rõ để đóng gói.

9. Agent Plugins liên quan gì tới Context Engineering?

Tôi xem plugin như một cơ chế progressive disclosure cho capability.

Agent không cần đọc mọi skill và mọi tài liệu ngay từ đầu.

Client có thể biết plugin nào đã cài.

Khi task phù hợp, nó mới tải thêm skill hoặc gọi MCP liên quan.

Điều này giúp giảm hai kiểu lãng phí:

Context waste: nhồi quá nhiều instruction không liên quan.

Tool confusion: expose quá nhiều tool khiến agent khó chọn đúng.

Nếu thiết kế tốt, hierarchy có thể là:

Agent
→ chọn plugin/capability
→ tải skill liên quan
→ truy xuất docs cần thiết
→ gọi MCP/tool đúng scope
→ thực hiện
→ verify

Đây cũng là lý do Agent Plugins đáng quan tâm hơn một “format cài extension”.

Nó gợi ý một cách tổ chức capability để agent có thể tự khám phá dần.

10. Điều cần theo dõi tiếp

Agent Plugins Specification 1.0.0 hiện đã được publish, còn 1.1.0 đang ở dạng working draft tại thời điểm tôi kiểm tra.

Nhưng standard chỉ có giá trị khi ecosystem thực sự implement.

Ba câu hỏi tôi sẽ theo dõi:

Portability thực tế đến đâu?

Một plugin cài được ở nhiều client không có nghĩa hành vi giống hệt nhau.

Permission model có hội tụ không?

Portable package không tự động tạo portable security policy.

Plugin registry có trở thành supply-chain risk mới không?

Khi agent plugin có thể bundle skills, MCP và configuration, review nguồn, version và provenance sẽ ngày càng quan trọng.

Vì vậy, tôi chưa xem plugin như “cứ cài là xong”.

Tôi xem nó như một bước tiến trong việc đóng gói năng lực agent thành phần mềm có cấu trúc.

Và khi agent càng giống một operator, capability packaging sẽ càng quan trọng như dependency management từng quan trọng với software.

Đọc tiếp trong Series Agentic Stack 2026

Nguồn tham khảo