Agent đáng tin bắt đầu từ nét vẽ

Agent đáng tin bắt đầu từ nét vẽ

MCP không làm agent tự nhiên giỏi hơn. Nó buộc team phải quyết định rõ: tool nào được gọi, gọi khi nào, và chặn lỗi ở đâu.

Có lần mình thấy một team WordPress demo agent sửa plugin ngay trong editor. Màn hình chạy mượt: agent đọc file, đề xuất patch, gọi tool, cập nhật code. Cả phòng im vài giây, kiểu “ừ rồi, mình sắp thất nghiệp hả?”.

Nhưng đến đoạn hỏi: “Nếu agent update nhầm option trong production database thì ai rollback?”, không khí đổi màu nhanh hơn bảng màu bị đổ nước.

Đó là chỗ mình muốn nói hôm nay: agent không đáng tin vì nó biết gọi tool; agent đáng tin khi orchestration và guardrail được vẽ rõ từ đầu. MCP đang làm việc kết nối AI với hệ thống thật dễ hơn, nhất là trong các hệ sinh thái nhiều lớp như WordPress. Nhưng dễ kết nối không đồng nghĩa với an toàn để cho chạy tự do.

Sơ đồ minh họa cho bài Agent đáng tin bắt đầu từ nét vẽ

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

MCP không phải phần màu đẹp nhất, nó là lớp phác thảo

MCP, viết tắt của Model Context Protocol, là giao thức chuẩn để AI client nói chuyện với tool, dữ liệu, file system hoặc API qua một dạng chung. Nếu trước đây mỗi app phải tự viết connector riêng, MCP giúp tool được đóng gói thành MCP server — một dịch vụ phơi bày capability — để các MCP client tương thích có thể dùng lại.

Trong WordPress, chuyện này rất hấp dẫn. Vì WordPress không chỉ là vài file PHP. Nó có database schema, plugin lifecycle, theme, block editor, REST API, GraphQL tùy site, hook/filter, quyền user, cache, hosting khác nhau. Một chatbot đứng ngoài chỉ có thể đoán. Một agent có MCP có thể đọc context thật, gọi tool thật, và hành động trong môi trường thật.

Nhưng đây cũng là điểm nguy hiểm. Trước MCP, lỗi thường dừng ở câu trả lời sai. Sau MCP, lỗi có thể thành file bị sửa, record bị cập nhật, hoặc endpoint bị gọi nhầm.

Nói thẳng ra thì: MCP không thay thế kiến trúc agent. Nó chỉ chuẩn hóa đường nối giữa model và thế giới bên ngoài. Phần bạn vẫn phải quyết định là: đường nào được mở, mở cho ai, và có lan can ở đâu.

Câu hỏi đúng không phải “có dùng MCP không?”

Với builder, câu hỏi thực tế hơn là: team mình nên cho agent quyền gì ở giai đoạn nào?

Mình hay chia thành 3 mức quyết định:

| Mức | Agent được làm gì | Phù hợp khi | Rủi ro chính |
|---|---|---|---|
| Read-only | Đọc file, query metadata, tra docs nội bộ | Team mới thử, hệ thống production nhạy cảm | Agent hiểu sai context nhưng chưa phá dữ liệu |
| Suggest-only | Tạo patch, viết SQL nháp, đề xuất config | Có reviewer kỹ thuật, có CI rõ | Người review bị “automation bias” và approve vội |
| Act-with-approval | Gọi API, update file, chạy migration sau khi được duyệt | Workflow lặp lại, có rollback và audit | Guardrail hở là lỗi đi thẳng vào hệ thống |

Điểm hay của MCP là bạn có thể tách tool khỏi agent. Ví dụ cùng một MCP server có tool get_plugin_info, search_wp_hooks, create_patch, update_option. Nhưng không nhất thiết client nào cũng được gọi tất cả.

Nếu team bạn đang build agent cho WordPress hoặc CMS nội bộ, mình sẽ không bắt đầu bằng “agent tự sửa mọi thứ”. Mình sẽ bắt đầu bằng read-only + suggest-only, rồi chỉ nâng quyền khi đã thấy pattern lỗi lặp lại và có chốt kiểm soát.

Hình dung thế này: agent đang cầm cọ, không phải chỉ ngồi bình luận tranh

Hình dung thế này: bạn có một site WordPress dùng WooCommerce, vài plugin custom, và một theme đã sống qua ba đời developer. Khách báo lỗi: trang checkout thỉnh thoảng mất field VAT.

Agent kiểu cũ có thể gợi ý: “kiểm tra hook woocommerce_checkout_fields”. Hữu ích, nhưng bạn vẫn phải tự mở code, grep file, đọc plugin, test lại.

Agent có MCP có thể đi xa hơn:

  1. Đọc danh sách plugin đang active.
  2. Tìm các file có hook liên quan checkout.
  3. Query option hoặc config liên quan field VAT.
  4. Tạo patch đề xuất.
  5. Chạy test cục bộ hoặc lệnh kiểm tra lint nếu tool cho phép.

Đây là khác biệt thật: model không chỉ “biết về WordPress”, nó có cửa để nhìn vào site cụ thể của bạn.

Nhưng nét cọ càng gần canvas thật, lỗi càng đắt. Nếu tool update_option nhận input quá rộng, agent có thể sửa nhầm option. Nếu tool run_sql không giới hạn câu lệnh, bạn vừa đưa cho model một cây cọ nhúng thẳng vào database.

Vì vậy, thiết kế tool nên nhỏ và có chủ đích:

# Ví dụ minh họa: tool hẹp, có validate rõ
@tool
def update_checkout_vat_label(site_id: str, new_label: str) -> str:
    """Chỉ cập nhật label VAT ở checkout, không sửa option khác."""
    if len(new_label) > 80:
        raise ValueError("Label quá dài")
    return wp_update_option(site_id, "checkout_vat_label", new_label)

Tool này kém “đa năng” hơn update_any_option, nhưng an toàn hơn nhiều. Trong production, tool hẹp thường đáng tin hơn tool quyền lực.

Orchestration mới là nơi agent thắng hoặc thua

Orchestration là cách điều phối các bước, tool và trạng thái để hoàn thành việc. Trong demo, orchestration thường bị giấu sau vài dòng code. Ngoài đời, nó là phần quyết định agent có chạy như một quy trình hay như người cầm bút vẽ lung tung lên lớp nền.

Một flow tối thiểu cho agent sửa lỗi WordPress nên có dạng:

1. Diagnose
   - đọc file liên quan
   - lấy config/plugin active
   - tóm tắt giả thuyết

2. Plan
   - liệt kê file/tool định dùng
   - nêu rủi ro
   - chờ duyệt nếu có hành động ghi

3. Execute
   - tạo patch hoặc gọi tool hẹp
   - không gọi tool ngoài plan

4. Verify
   - chạy test/lint
   - đọc diff
   - ghi audit log

5. Rollback path
   - nêu cách hoàn tác
   - lưu trạng thái trước khi sửa

Ở đây có vài thuật ngữ cần neo nhanh:

Một lỗi nhiều team mắc: nghĩ memory là đủ để truy vết. Không. Memory giúp hội thoại liền mạch; audit log giúp vận hành và điều tra sự cố. Hai thứ này khác nhau như phác thảo ý tưởng và hồ sơ bàn giao bản vẽ.

Ai nên dùng, ai nên bỏ qua lúc này?

MCP đáng thử nếu team bạn có ít nhất một trong các điều kiện sau:

Còn nên khoan nếu:

Điều kiện đổi quyết định cũng khá rõ: khi một workflow đã lặp đủ nhiều, lỗi do thao tác tay xuất hiện thường xuyên, và bạn có thể mô tả nó thành các tool hẹp, lúc đó MCP bắt đầu đáng giá. Không phải vì nó làm agent thông minh hơn, mà vì nó làm đường giao tiếp giữa agent và hệ thống có hình dạng kiểm soát được.

Một buổi chiều để kiểm tra độ chín của team

Không cần dựng full agent ngay. Trong một buổi chiều, bạn có thể làm bài kiểm tra nhỏ này:

  1. Chọn một workflow thật, ví dụ “tìm nguyên nhân lỗi plugin sau khi update”.
  2. Viết ra 5 tool agent cần, nhưng đánh dấu tool nào chỉ đọc, tool nào có ghi.
  3. Với mỗi tool ghi, thêm 3 cột: input schema, quyền cần có, rollback.
  4. Chạy thử bằng local agent hoặc MCP server nhỏ trên staging, không đụng production.
  5. Xem log sau buổi thử: có bước nào agent gọi tool ngoài mong đợi không?

Nếu đến bước 3 mà team không mô tả được rollback, đừng vội nâng quyền. Nếu bước 5 log mù mờ, cũng đừng cho agent chạy thật. Agent production không cần trông hào nhoáng; nó cần để lại dấu vết đủ rõ khi có chuyện.

Chốt lại: đừng mua sự tự động hóa bằng niềm tin mơ hồ

Sau bài này, mình muốn bạn đổi một cách nghĩ: MCP không phải quyết định “có agent hay không”, mà là quyết định “agent được chạm vào phần nào của hệ thống, dưới luật nào”.

Với WordPress hay bất kỳ stack nào nhiều plugin, nhiều dữ liệu, nhiều môi trường, phần khó không nằm ở việc model biết gọi tool. Phần khó là vẽ ranh giới: đọc ở đâu, đề xuất ở đâu, ghi ở đâu, dừng ở đâu.

Nếu là mình, mình sẽ dùng MCP như lớp phác thảo cho automation: nét nào chắc thì tô đậm, nét nào còn run thì để reviewer cầm cọ. Agent giỏi không phải agent tự làm tất cả; agent giỏi là agent biết đứng đúng ô trên canvas.

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

Nguồn tham khảo