MCP hay A2A? Ai sở hữu công việc sau khi agent giao việc?

Tóm tắt cốt lõi: Chọn MCP và A2A không phải chọn giao thức thắng cuộc, mà là xác định ai điều hành công việc sau mỗi lần bàn giao. MCP phù hợp để cung cấp năng lực cho agent; A2A phù hợp khi bên nhận vận hành một nhiệm vụ độc lập, nhưng cả hai đều cần hợp đồng phạm vi, kiểm soát quyền và cơ chế xử lý thất bại. Với SME, hãy bắt đầu bằng một workflow đo được, chỉ thêm ranh giới giao thức khi trách nhiệm vận hành thực sự thay đổi.

Một agent nhân sự nhận yêu cầu giải thích bảng lương. Nó đọc chính sách, truy xuất hồ sơ rồi nhờ hệ thống tính lương kiểm tra khoản truy thu. Đến đây, câu hỏi quan trọng không còn là model nào thông minh hơn. Đó là: ai chịu trách nhiệm theo dõi, thử lại và kết thúc phần việc tính lương?

Nếu agent nhân sự vẫn điều khiển toàn bộ quy trình, hệ thống tính lương có thể chỉ là một tool. Nếu bộ phận tiền lương tiếp nhận một hồ sơ, tự xử lý và trả kết quả sau, đây là một cuộc bàn giao công việc. Hai tình huống nhìn giống nhau trên giao diện chat nhưng khác hẳn về kiến trúc.

Trong bài này, quyền sở hữu công việc được hiểu là trách nhiệm vận hành task: giữ trạng thái, quản lý thời hạn, xử lý lỗi và cung cấp bằng chứng hoàn thành. Nó không tự động chuyển trách nhiệm pháp lý hay trách nhiệm kinh doanh khỏi con người.

Dự báo 40% dự án agentic AI bị hủy nói lên điều gì?

Gartner dự báo hơn 40% dự án agentic AI sẽ bị hủy trước cuối năm 2027, với các nguyên nhân được nêu gồm chi phí leo thang, giá trị kinh doanh thiếu rõ ràng và kiểm soát rủi ro chưa đầy đủ. Đây là dự báo, không phải tỷ lệ thất bại đã quan sát được.

Cũng không thể lấy dự báo đó làm bằng chứng rằng chọn sai MCP hay A2A là nguyên nhân trực tiếp. Liên hệ thực tế nằm ở tầng vận hành: trách nhiệm mơ hồ làm tăng retry, thời gian chờ, điều tra sự cố và công việc thủ công. Những khoản này cuối cùng xuất hiện trong chi phí và rủi ro.

Các số liệu thứ cấp trong hồ sơ nghiên cứu, như tỷ lệ doanh nghiệp có agent production hoặc thời gian trung vị tạo ra giá trị, sử dụng những quần thể và định nghĩa khác nhau. Không nên ghép chúng thành một bức tranh thống kê thống nhất khi chưa kiểm tra khảo sát gốc.

• Chi phí: Ai trả tiền cho task chạy quá hạn hoặc bị gọi lại?
• Giá trị: Kết quả nào được bộ phận nghiệp vụ chấp nhận?
• Rủi ro: Ai có quyền dừng tác vụ và tiếp quản bằng quy trình thủ công?

Đó là ba câu hỏi cần trả lời trước khi vẽ sơ đồ nhiều agent. Một hệ thống có ít thành phần nhưng trách nhiệm rõ thường dễ vận hành hơn hệ thống nhiều agent chỉ biết chuyển tiếp thông điệp.

Chatbot, agent và multi-agent khác nhau ở quyền quyết định nào?

Chatbot chủ yếu tạo phản hồi. Agent có thể lựa chọn hành động trong phạm vi được cấp và dùng kết quả để quyết định bước tiếp theo. Multi-agent bổ sung nhiều đơn vị thực thi, thường có ngữ cảnh, năng lực hoặc vòng đời công việc riêng. Tên sản phẩm không đủ chứng minh sự khác biệt này.

Bài kiểm tra nhanh là yêu cầu đội triển khai chỉ ra: mục tiêu, công cụ, quyền quyết định, trạng thái bền vững và điều kiện dừng. Nếu mọi nhánh đều được định sẵn, hệ thống có thể là workflow tích hợp LLM. Điều đó không làm nó kém giá trị; nhiều quy trình SME nên giữ tính xác định như vậy.

Ngược lại, ba lời gọi model nối tiếp chưa chắc tạo thành ba agent độc lập. Nếu một bộ điều phối vẫn giữ mọi quyết định và phục hồi, bạn đang phân tách bước xử lý, chưa chắc đã phân tách quyền sở hữu task.

Bài khi nào cần multi-agent và cách điều phối đúng phân tích điều kiện cần nhiều agent. Ở đây, trọng tâm hẹp hơn: khi đã phân tách, hợp đồng bàn giao phải chứa những gì?

MCP là gì và khi nào nên dùng MCP?

Trả lời nhanh: MCP là giao thức chuẩn hóa cách ứng dụng AI kết nối với công cụ, tài nguyên và prompt. Chọn MCP khi agent cần năng lực được quản trị nhưng ứng dụng gọi vẫn điều phối công việc. Kiểm tra ba điểm trước: quyền truy cập, tác động của tool và cách phục hồi khi gọi lỗi.

Theo đặc tả chính thức Model Context Protocol, MCP cung cấp những cấu trúc giao tiếp để ứng dụng tích hợp năng lực từ server. Trong thực tế, đó có thể là tìm khách hàng, đọc tài liệu, kiểm tra tồn kho hoặc tạo bản nháp đơn hàng.

Đơn vị thiết kế hữu ích là capability có hợp đồng: đầu vào nào được chấp nhận, dữ liệu nào được trả về, tác động nào xảy ra và lỗi nào có thể nhận. Đừng xuất một tool kiểu “thực hiện mọi thao tác CRM” rồi kỳ vọng model tự giữ kỷ luật.

Không đồng nhất MCP với lời gọi ngắn, đồng bộ

Một thao tác qua MCP có thể kích hoạt công việc dài. Khả năng quản lý tác vụ còn phụ thuộc phiên bản, extension và implementation. Vì vậy, không nên dùng công thức cứng “MCP không có task, A2A mới có task”. Cần kiểm tra khả năng mà cả client lẫn server thực sự hỗ trợ.

Tương tự, tính stateless của một lớp giao tiếp không làm biến mất trạng thái nghiệp vụ. Đơn hàng đang chờ duyệt vẫn phải được lưu ở đâu đó. Những tuyên bố cụ thể về phiên bản năm 2026 cần đối chiếu release và đặc tả tương ứng trước khi đưa vào hợp đồng triển khai.

• Tool quá rộng: Tách quyền đọc, tạo nháp và ghi chính thức.
• Đầu vào không đáng tin: Nội dung tài liệu không được trở thành chỉ thị nâng quyền.
• Retry gây tác động kép: Thao tác ghi cần khóa chống trùng và đối soát trạng thái.

MCP chuẩn hóa kết nối; ứng dụng vẫn phải thiết kế chính sách sử dụng kết nối đó.

A2A là gì và khi nào cần giao việc cho agent khác?

Trả lời nhanh: A2A chuẩn hóa giao tiếp giữa các agent, gồm mô tả năng lực và trao đổi task, trạng thái, kết quả. Nên dùng khi bên nhận tự quản lý thực thi, thời gian xử lý hoặc tương tác bổ sung. Nếu chỉ gọi một hàm có đầu ra cố định, API thường có thể đơn giản hơn.

Đặc tả chính thức Agent2Agent mô tả cách agent công bố thông tin qua Agent Card và trao đổi công việc bằng những cấu trúc như task, message và artifact. Giá trị nằm ở hợp đồng liên tác, không phải ở việc hai bên cùng dùng LLM.

Ví dụ, agent nhân sự gửi một yêu cầu kiểm tra chênh lệch lương. Agent tiền lương có thể yêu cầu bổ sung kỳ công, chờ người phụ trách xác nhận rồi xuất báo cáo. Bên gửi không cần biết từng bước nội bộ, nhưng cần biết trạng thái, thời hạn và đầu ra cam kết.

Khi nào A2A đáng giá hơn API thông thường?

API thông thường vẫn là lựa chọn tốt nếu hai bên đã thống nhất endpoint, dữ liệu và cơ chế bất đồng bộ. A2A đáng cân nhắc khi có nhiều agent từ nhiều đội hoặc nhà cung cấp, cần một mô hình tương tác chung thay vì xây từng adapter riêng.

Đổi lại, doanh nghiệp phải vận hành thêm discovery, tương thích phiên bản, theo dõi task và xử lý các trạng thái trung gian. Agent Card có mô tả năng lực không đồng nghĩa năng lực đó đã được kiểm chứng. Một lời đề nghị hủy task cũng không đảm bảo tác động bên ngoài đã được đảo ngược.

Đừng dùng A2A chỉ vì bên nhận có chữ “agent”. Hãy dùng khi hợp đồng bàn giao công việc thực sự cần vòng đời độc lập.

MCP và A2A: Ai sở hữu công việc sau khi bàn giao?

Ba câu hỏi dưới đây giúp tránh chọn giao thức theo tên gọi:

• Ai sở hữu năng lực? Bên cung cấp chỉ thực hiện thao tác, hay còn quyết định cách giải quyết yêu cầu?
• Ai giữ vòng đời task? Bên nào lưu tiến độ, xử lý timeout, xin bổ sung thông tin và công bố kết quả?
• Ranh giới tổ chức ở đâu? Hai bên có cùng đội trực vận hành, quyền truy cập và lịch phát hành không?

Ranh giới tổ chức là tín hiệu quan trọng, nhưng không tự động quyết định giao thức. Một dịch vụ trong cùng công ty vẫn có thể cần hợp đồng task độc lập. Ngược lại, dịch vụ của đối tác chỉ trả dữ liệu đơn giản có thể dùng API hoặc MCP phù hợp.

Ma trận này không xếp hạng giao thức. Một hệ thống dùng cả hai có thể đúng, nhưng cũng có thể chỉ đang nhân đôi chi phí tích hợp. Mỗi ranh giới mới phải giảm được sự phụ thuộc hoặc làm rõ trách nhiệm.

Kiến trúc hybrid MCP + A2A cho quy trình nhân sự

Xét một thiết kế tham chiếu, không phải tuyên bố về triển khai đã đo kiểm. Nhân viên hỏi vì sao lương thực nhận khác tháng trước. Agent nhân sự có quyền đọc chính sách và dữ liệu giới hạn; agent tiền lương có quy trình kiểm tra nghiệp vụ riêng.

1. Tiếp nhận: Ứng dụng xác định người yêu cầu, phạm vi dữ liệu và mã hồ sơ.
2. Tra cứu: Agent nhân sự dùng MCP đọc chính sách và bản tóm tắt được phép xem.
3. Bàn giao: Nếu cần điều tra nghiệp vụ, tạo task qua A2A với kỳ lương, câu hỏi và thời hạn.
4. Thực thi: Agent tiền lương dùng các công cụ nội bộ, yêu cầu bổ sung nếu thiếu dữ liệu.
5. Phê duyệt: Mọi điều chỉnh tiền lương đi qua người có thẩm quyền.
6. Đóng hồ sơ: Đối chiếu báo cáo, phản hồi nhân viên và lưu bằng chứng.

Scope contract một trang phải ghi gì?

Scope contract không phải prompt dài. Nó là thỏa thuận vận hành giữa bên giao và bên nhận: mục tiêu, đầu vào bắt buộc, dữ liệu cấm truy cập, đầu ra được chấp nhận, thời hạn, ngân sách và người tiếp quản khi lỗi.

Đặc biệt cần phân biệt chủ task con với chủ hồ sơ đầu cuối. Agent tiền lương chịu trách nhiệm điều tra; bộ phận nhân sự vẫn chịu trách nhiệm trả lời nhân viên. Bàn giao task con không làm biến mất trách nhiệm với người dùng cuối.

Thiết kế đường lỗi trước đường thành công

Nếu bên nhận không phản hồi, workflow không được tạo task mới vô hạn. Lưu mã yêu cầu, tra trạng thái trước khi gửi lại và chuyển sang hàng chờ thủ công khi vượt ngưỡng. Khi timeout nhưng chưa rõ tác động đã xảy ra hay chưa, ưu tiên đối soát thay vì thực hiện lại thao tác ghi.

Với n8n, có thể dùng workflow làm lớp tiếp nhận, webhook, approval và điều phối. Tuy nhiên, trạng thái nghiệp vụ quan trọng nên nằm trong kho dữ liệu bền vững có khả năng truy vấn, không chỉ trong lịch sử execution. Cần kiểm tra riêng khả năng tích hợp giao thức của phiên bản và node được triển khai.

Vì sao đúng giao thức vẫn chưa đủ an toàn?

MCP và A2A không tự tạo thành ranh giới bảo mật. Tuân thủ schema chỉ cho biết thông điệp có hình dạng hợp lệ. Nó không chứng minh người gọi được phép đọc hồ sơ đó, hay nội dung trả về không chứa chỉ dẫn độc hại.

• Danh tính xuyên chuỗi: Ghi nhận người khởi tạo, dịch vụ thực thi và phạm vi được ủy quyền; không chuyển tiếp tùy tiện token quyền cao.
• Allowlist: Giới hạn server, agent, công cụ và đích mạng được phép sử dụng.
• Approval gate: Đặt ở điểm gây tác động kinh doanh, không chỉ trước bước sinh văn bản.
• Audit log: Liên kết yêu cầu, task con, lần gọi tool, quyết định duyệt và kết quả bằng mã truy vết.

Ngân sách cũng là một phần của phạm vi: task được phép tiêu bao nhiêu lượt gọi, kéo dài bao lâu và giao tiếp sâu đến mấy tầng. Nếu mỗi agent đều tự gọi thêm agent mà không có giới hạn, hệ thống có thể đúng giao thức nhưng không còn kiểm soát được chi phí.

Ủy quyền tốt không chỉ nói bên nhận được làm gì. Nó phải nói bên nhận không được làm gì, khi nào phải dừng và ai nhận lại công việc.

Chi phí: Khi nào tự host model rẻ hơn API?

Trả lời nhanh: Không có ngưỡng token hòa vốn dùng chung cho mọi hệ thống. SME nên so tổng chi phí GPU, vận hành, dự phòng và chất lượng với API trên cùng tập tác vụ. Chỉ tự host khi tải đủ ổn định, đáp ứng độ trễ và có người chịu trách nhiệm vận hành.

Quyết định giao thức và quyết định triển khai model là hai trục khác nhau. Agent dùng A2A vẫn có thể gọi model qua API; MCP server có thể phục vụ ứng dụng chạy model nội bộ. Không nên đóng gói chúng thành một lựa chọn duy nhất.

Công thức lập ngân sách đơn giản là: chi phí tự host tháng = GPU + hạ tầng phụ trợ + nhân sự vận hành + dự phòng + chi phí lỗi. Phía API gồm token đầu vào, đầu ra, phí công cụ và những khoản cố định thực sự phát sinh theo nhà cung cấp.

Ví dụ giả định: tổng chi phí tự host là 2.400 USD/tháng, còn chi phí API hỗn hợp là 1 USD/triệu token. Điểm bằng nhau thuần số học là 2,4 tỷ token/tháng. Đây không phải khuyến nghị giá thị trường: kết quả chỉ có ý nghĩa nếu hai phương án đạt chất lượng, độ trễ và năng lực phục vụ tương đương.

Utilisation cao chưa đủ nếu hàng đợi làm trễ công việc. Cũng không thể lấy benchmark token/giây của một cấu hình rồi áp nguyên cho workload khác. Độ dài ngữ cảnh, tỷ lệ đầu vào/đầu ra, batching và yêu cầu chất lượng đều làm thay đổi công suất hữu dụng.

Router lai chỉ hợp lý khi đã có tải nền ổn định: model nội bộ xử lý phần phù hợp, API nhận tải đỉnh hoặc tác vụ khó. Cần kiểm tra chính sách dữ liệu trước khi fallback; “hết GPU thì gửi ra ngoài” không phải chính sách hợp lệ cho mọi hồ sơ.

Lộ trình 90 ngày: Đo trước, chọn giao thức sau

Ngày 1–15: Đóng phạm vi và đo baseline

Chọn một quy trình có đầu ra kiểm chứng được. Đo thời gian xử lý, tỷ lệ phải sửa, thời gian con người tham gia và số hồ sơ tồn. Viết scope contract trước khi làm demo. Nếu chưa biết kết quả nào được chấp nhận, chưa nên xây agent tự hành.

Ngày 16–35: Một agent, quyền hạn hẹp

Bắt đầu bằng quyền đọc hoặc tạo nháp. Chạy bộ tình huống đại diện, gồm dữ liệu thiếu, sai quyền và yêu cầu ngoài phạm vi. Chỉ thêm MCP khi lợi ích chuẩn hóa capability rõ ràng; một API sẵn có không cần bị bọc lại chỉ để hợp xu hướng.

Ngày 36–60: Thử ranh giới bàn giao

Nếu có bên nhận độc lập, thử hợp đồng task và cân nhắc A2A. Kiểm thử mất kết nối sau khi nhận việc, gửi trùng, hủy muộn, đầu ra không đạt và thay đổi phiên bản. Đo công sức đối soát, không chỉ tỷ lệ lời gọi thành công.

Ngày 61–90: Vận hành giới hạn và quyết định tiếp tục

Đặt ngưỡng dừng trước khi mở rộng: chi phí vượt trần, chất lượng thấp hơn baseline, tồn đọng tăng hoặc không truy được nguyên nhân lỗi. Mọi ngưỡng cần gắn với đặc thù nghiệp vụ, không lấy một tỷ lệ chung cho mọi SME.

Đội chưa có kỹ sư có thể bắt đầu từ các workflow ứng dụng agent có kiểm soát và đo chất lượng. Mục tiêu đầu tiên là một quy trình hữu ích với đường lui rõ ràng, không phải sơ đồ kiến trúc nhiều logo.

Câu hỏi thường gặp

MCP có thay thế được A2A không?

Không có câu trả lời tuyệt đối. Hai giao thức có thể chồng lấn một phần về khả năng thực hiện công việc, đặc biệt khi có extension. Tuy nhiên, chuẩn hóa capability và chuẩn hóa tương tác giữa các agent độc lập là hai mục tiêu khác nhau. Hãy so hợp đồng cần có với khả năng thực tế của client, server và phiên bản triển khai.

SME chưa có đội kỹ sư nên bắt đầu từ đâu?

Bắt đầu bằng một workflow giới hạn, người phụ trách nghiệp vụ và cơ chế duyệt thủ công. Yêu cầu nhà cung cấp bàn giao sơ đồ dữ liệu, danh sách quyền, cách xuất log và quy trình xử lý lỗi. Chưa cần tự vận hành cả MCP lẫn A2A nếu một tích hợp đơn giản đã giải quyết được công việc.

Vì sao protocol compliance không đồng nghĩa với an toàn?

Tuân thủ giao thức kiểm tra cách trao đổi, không thay thế quyết định cấp quyền. Một task hợp lệ vẫn có thể yêu cầu thao tác vượt phạm vi; một kết quả đúng schema vẫn có thể chứa dữ liệu nhạy cảm. Kiểm soát phải tồn tại tại ứng dụng, dịch vụ và hệ thống dữ liệu, không chỉ trong prompt của agent.

Khi nào nên tự host model 27B thay vì API?

Chỉ khi model cụ thể vượt bộ kiểm thử nghiệp vụ, cấu hình phục vụ đáp ứng tải và tổng chi phí có lợi trong điều kiện thực tế. 27B chỉ là quy mô tham số, không xác định sẵn lượng VRAM hay chất lượng. Còn phải xét độ chính xác số, lượng tử hóa, KV cache, ngữ cảnh, đồng thời và chi phí người trực vận hành.

Kết luận: Chọn theo trách nhiệm, không theo độ phổ biến

MCP hữu ích khi agent cần năng lực có quản trị. A2A hữu ích khi công việc đi sang một đơn vị thực thi độc lập. Kết hợp cả hai chỉ đáng làm khi hệ thống thực sự có cả hai loại ranh giới.

Trước khi chọn giao thức, hãy viết một trang trả lời: ai giữ trạng thái, ai được tạo tác động, ai xác nhận kết quả và ai tiếp quản khi thất bại. Nếu chưa trả lời được, thiếu sót nằm ở hợp đồng vận hành — không phải ở thư viện SDK.

Tác giả: Cường Nguyễn — Founder AI Ops Solutions | Verified n8n Creator. Kết nối: Facebook · LinkedIn · YouTube · TikTok