Marketplace cho agent: tiện hay rủi ro?

Grok Build có plugin marketplace, nhưng điểm đáng bàn không phải là cài nhanh. Với builder, đây là bài toán quyền chạy code, rollback và đo lỗi.

Bạn có dám cho một plugin mới quyền đọc repo, chạy shell command, chạm vào database, xem log production, rồi nhờ nó “fix giúp em lỗi này” không?

Mình hỏi hơi gắt, nhưng đây là đúng chỗ các coding agent đang đi tới. Không còn là màn chat trả lời code mẫu nữa. Grok Build vừa có plugin marketplace ngay trong terminal. Hermes Agent có Profile Builder để gom identity, model, skills và MCP servers vào một flow. Kimi Code CLI thì đẩy mạnh terminal agent với hooks, subagents, MCP config. Vercel cũng đang kéo câu chuyện AI Gateway về một endpoint, quan sát và vận hành production.

Nhìn bề mặt, đây là cuộc đua “ai có nhiều tích hợp hơn”. Nhưng với team đang build thật, luận điểm nên đổi là: plugin marketplace cho agent không phải kho tiện ích; nó là supply chain mới cho quyền hành động của AI trong hệ thống của bạn.

Nói thẳng ra thì, cài plugin cho agent giống như cho tàu cập cảng: không chỉ hỏi tàu chở gì, mà phải biết nó được phép đi vào luồng nào, dỡ hàng ở đâu, và nếu có sự cố thì kéo ra bằng cách nào.

Sơ đồ tóm tắt ý chính của bài viết.

Chuyện đang dịch chuyển: từ prompt sang quyền thao tác

Grok Build Plugin Marketplace cho phép bạn duyệt, cài và cập nhật plugin ngay trong terminal. Một plugin có thể gói nhiều thứ: skills là chỉ dẫn hoặc năng lực tác vụ, slash commands là lệnh gọi nhanh trong CLI, agents là luồng xử lý tự động hơn, hooks là điểm chèn để chạy logic trước/sau hành động, MCP servers là server theo Model Context Protocol để agent nói chuyện với công cụ ngoài, và LSPs là Language Server Protocol giúp hiểu code như IDE.

Điểm mới không nằm ở từng mảnh. Dev lâu năm đã quen cài extension, CLI, package, GitHub Action. Điểm mới là một lệnh cài có thể mở thêm nhiều kênh hành động cho agent cùng lúc.

Ví dụ cụ thể: bạn cài plugin Sentry để agent đọc stack trace và debug lỗi production. Ngon. Nhưng nếu plugin đó cũng có hook chạy command, hoặc kết nối thêm server phụ, câu hỏi vận hành sẽ đổi từ “agent trả lời đúng không?” sang “agent được phép làm gì khi nó nghĩ mình đúng?”.

Đó là ranh giới mà nhiều team dễ bỏ qua vì marketplace tạo cảm giác rất mượt. Browse, chọn, nhấn i, xong. Trong UI, mọi thứ trông như extension. Trong production, nó là một lớp quyền.

Mổ lớp plugin: đừng chỉ đọc tên đối tác

Danh sách plugin ban đầu của Grok Build có MongoDB, Vercel, Sentry, Chrome DevTools, Cloudflare, Superpowers. Toàn những workflow rất thật: tối ưu query, xem deploy, debug stack trace, inspect network request, làm việc với Workers hoặc Durable Objects.

Nhưng builder không nên đánh giá plugin bằng logo. Hãy bóc theo 5 câu hỏi:

| Lớp cần soi | Câu hỏi vận hành | Vì sao quan trọng |
|---|---|---|
| Intent | Plugin sinh ra để đọc, phân tích, hay thay đổi hệ thống? | Đọc log khác xa sửa config deploy. |
| Privilege | Nó cần token nào, quyền file nào, command nào? | Quyền quá rộng là lỗi đang ngủ. |
| Provenance | Source plugin đến từ đâu, cập nhật qua cơ chế nào? | Marketplace là index, không phải bảo chứng tuyệt đối. |
| Observability | Có trace được plugin đã gọi tool gì, lúc nào, input nào không? | Không trace thì postmortem chỉ còn đoán. |
| Rollback | Gỡ plugin có trả hệ thống về trạng thái cũ không? | Cài dễ mà tháo khó là nợ vận hành. |

Hình dung thế này: một frontend engineer cài Chrome DevTools plugin để agent mở browser, ghi performance trace và soi network request. Đây là use case tốt, vì thao tác có thể quan sát được. Nhưng nếu cùng phiên làm việc đó agent cũng có quyền sửa file, chạy test, gọi deployment plugin, thì lỗi không còn nằm ở “model hiểu sai câu hỏi”. Lỗi nằm ở chuỗi hành động nối nhau quá dài mà không có phanh.

Vì vậy, marketplace càng tiện, bạn càng cần policy rõ. Không phải để chặn đổi mới, mà để team không biến terminal thành boong tàu lúc gió ngược: ai cũng kéo dây, nhưng không ai biết dây nào đang giữ cột buồm.

Một buổi kiểm chứng: cài như dependency, không cài như extension

Nếu team bạn muốn thử Grok Build marketplace hoặc một mô hình tương tự, đừng bắt đầu bằng plugin hấp dẫn nhất. Bắt đầu bằng plugin có blast radius nhỏ nhất — phạm vi thiệt hại nếu nó làm sai.

Một buổi chiều là đủ để dựng bài test gọn:

Bước 1: Chọn một workflow có đầu ra kiểm chứng được

Đừng chọn “agent giúp dev nhanh hơn”. Mơ hồ quá.

Chọn kiểu:

• Sentry plugin: phân tích một stack trace cũ và đề xuất file cần sửa.
• MongoDB plugin: đọc một query chậm trong môi trường staging và đề xuất index, không tự apply.
• Chrome DevTools plugin: ghi lại network trace của một route staging và liệt kê request bất thường.
• Vercel plugin: đọc trạng thái build/deploy, không đổi domain hay env.

Mục tiêu là để agent đọc và đề xuất trước, chưa cho sửa.

Bước 2: Tạo sandbox quyền thấp

Dùng repo phụ, project staging, token read-only nếu có thể. Nếu bắt buộc có quyền ghi, giới hạn vào tài nguyên throwaway.

Checklist tối thiểu:

• Token riêng cho plugin, không dùng token cá nhân của lead.
• Không gắn production secret vào phiên thử.
• Log lại command agent chạy.
• Tách branch riêng cho mọi file edit.
• Chặn lệnh nguy hiểm bằng wrapper hoặc approval thủ công.

Với Kimi Code CLI, ý tưởng approval flow cho file edits và shell commands là một hướng đáng học: thao tác đọc có thể tự động, thao tác ghi cần xác nhận. Với Grok Build, cờ --trust khi install là tín hiệu rất rõ: đã trust là đã mở cửa cho code chạy và dữ liệu bị chạm tới.

Bước 3: Đo bằng tiêu chí dừng, không đo bằng cảm giác thích

Trước khi chạy, viết ra 4 tiêu chí:

1. Độ đúng của diagnosis: agent chỉ ra đúng nguyên nhân hay chỉ kể lại log?
2. Độ sạch của hành động: có chạy command ngoài phạm vi không?
3. Khả năng audit: sau phiên làm việc, bạn có tái dựng được chuỗi tool calls không?
4. Chi phí vận hành: có thêm bước xin quyền, quản token, review log quá nặng không?

Giả sử team bạn 5 người, chỉ có một tech lead review toàn bộ AI workflow. Nếu một plugin tiết kiệm vài phút debug nhưng tạo thêm nửa giờ kiểm tra quyền mỗi lần dùng, nó chưa chắc đáng scale. Đây là ví dụ minh họa, nhưng logic thì thật: tiết kiệm ở coding mà phình ở vận hành vẫn là nợ.

Bước 4: Gắn mỏ neo rollback

Trước khi cài plugin thứ hai, hãy biết cách quay lại trạng thái sạch:

# Ví dụ minh họa: ghi lại trạng thái trước khi thử
 git checkout -b ai-plugin-trial
 git status

# Sau phiên thử, xem mọi thay đổi
 git diff
 git log --oneline -5

Với config agent, lưu lại file cấu hình trước/sau. Với token, đặt expiry ngắn. Với MCP server, ghi rõ server nào chạy local, server nào gọi remote. MCP server ở đây là điểm nối để agent dùng công cụ ngoài; tradeoff chính là tiện tích hợp nhưng mở thêm bề mặt tấn công và lỗi cấu hình.

Điều đáng giữ: packaging đang giải quyết nỗi đau thật

Mình không muốn biến bài này thành lời can “đừng cài gì cả”. Thực tế, packaging kiểu marketplace giải quyết một nỗi đau rất thật.

Trước đây, để agent làm việc có ích, team phải tự nối từng mảnh: prompt riêng, script riêng, MCP config riêng, rule riêng, token riêng. Mỗi người trong team có một setup khác nhau. Debug agent đã khó, debug môi trường của agent còn mệt hơn.

Plugin bundle có thể giúp chuẩn hóa:

• Một cách cài giống nhau cho cả team.
• Một manifest mô tả plugin, metadata và path component.
• Một chỗ cập nhật thay vì copy-paste config qua Slack.
• Một workflow có thể chia sẻ giữa coding, debugging, deploy và observability.

Hermes Agent Profile Builder cũng đi cùng hướng này nhưng ở lớp khác: gom identity, model, skills, MCP servers thành profile tách biệt. Profile là “home directory” riêng cho agent, có config, env, memory, session và state riêng. Điểm hay ở đây là isolation — cô lập trạng thái. Coding agent và research agent không nên dùng chung trí nhớ, token và lịch sử hành động.

Nếu Grok Build marketplace là cách phân phối năng lực, thì profile kiểu Hermes là cách chia khoang vận hành. Hai hướng này gặp nhau ở một điểm: agent càng mạnh, unit quản trị càng phải rõ.

Điều nên bỏ qua: cuộc thi “nhiều plugin hơn”

Thứ dễ làm team lạc hướng là đếm plugin như đếm huy chương.

Nhiều plugin không đồng nghĩa hệ thống tốt hơn. Với agent, mỗi plugin mới có thể thêm:

• Một đường truy cập dữ liệu.
• Một loại command có thể chạy.
• Một nguồn lỗi versioning.
• Một policy cần review.
• Một điểm khó tái hiện khi incident xảy ra.

Vercel AI Gateway và các chỉ số production quanh model usage gợi ý một chuyện khác: khi AI vào production, người ta quan tâm routing, observability, spend và control nhiều hơn là demo lấp lánh. Với plugin marketplace cũng vậy. Câu hỏi không phải “có plugin Vercel/Sentry/Cloudflare chưa?” mà là “khi agent dùng plugin đó, mình có thấy, giới hạn và đảo ngược được hành động không?”.

Một framework gọn cho tech lead:

• Pilot nếu plugin chỉ đọc dữ liệu, chạy được trên staging, có log rõ.
• Contain nếu plugin cần quyền ghi nhưng tác động nằm trong repo/branch/project phụ.
• Reject tạm thời nếu plugin cần production secret rộng, không audit được tool calls, hoặc không có cách rollback rõ.
• Scale khi ít nhất vài phiên thử cho thấy diagnosis đúng, hành động nằm trong phạm vi, và chi phí review không nuốt mất lợi ích.

Độc giả nên nghĩ khác sau bài này ở điểm này: đừng hỏi marketplace có gì mới; hãy hỏi nó thay đổi biên giới quyền lực của agent trong hệ thống bạn ra sao.

Plugin marketplace sẽ làm coding agent hữu dụng hơn, chắc vậy. Nhưng muốn dùng được thật, team phải đối xử với plugin như dependency có quyền hành động, không phải món trang trí trong terminal. Cài nhanh là phần dễ; biết lúc nào chưa cho tàu rời bến mới là nghề.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng