Người sáng tạo MCP nói về nguồn gốc, ưu thế kiến trúc và tương lai của MCP
Tuyển chọn TechFlowTuyển chọn TechFlow
Người sáng tạo MCP nói về nguồn gốc, ưu thế kiến trúc và tương lai của MCP
Bài viết đáng đọc nhất về MCP.
Chuyên sâu báo cáo Web3Tác giả: FounderPark
MCP – giao thức được Anthropic phát hành năm ngoái, bất ngờ trở thành giao thức nóng nhất trong lĩnh vực AI năm nay nhờ làn sóng Agent và Manus. Các ông lớn như OpenAI, Microsoft, Google lần lượt tuyên bố hỗ trợ giao thức này, các công ty Trung Quốc như Alibaba Cloud BaiLian, Tencent Cloud cũng nhanh chóng theo kịp, ra mắt nền tảng xây dựng nhanh.
Tuy nhiên, tranh cãi cũng không ít. Nhiều người đặt câu hỏi liệu MCP có thực sự khác biệt so với API, kỹ sư của Anthropic có thực sự am hiểu về giao thức Internet hay không, hoặc lo ngại về vấn đề an toàn do giao thức quá đơn giản.
Không ai phù hợp hơn những người sáng tạo ra giao thức MCP để trả lời những câu hỏi này.
Trong một tập podcast gần đây của Latent Space, họ đã mời hai kỹ sư của đội ngũ Anthropic - Justin Spahr-Summers và David Soria Parra, những người trực tiếp phát minh ra giao thức MCP, để nói chi tiết về nguồn gốc của MCP cũng như chia sẻ sâu sắc quan điểm của họ: Vì sao ra đời MCP? MCP khác gì so với API hiện tại? Làm thế nào để tận dụng tốt hơn các công cụ thông qua MCP? Thông tin phong phú, khuyến nghị lưu lại để đọc kỹ.
Giới thiệu khách tham gia:
-
Alessio Fanelli (người dẫn): Đối tác kiêm CTO của Decibel
-
swyx (người dẫn): Người sáng lập Small AI
-
David Soria Parra: Kỹ sư tại Anthropic
-
Justin Spahr-Summers: Kỹ sư tại Anthropic
Tóm tắt nội dung chính (TLDR):
-
"Chớp sáng" ý tưởng MCP đến từ một dự án nội bộ LSP (Language Server Protocol) của Anthropic. Hai kỹ sư lấy cảm hứng từ LSP, tự hỏi liệu có thể xây dựng một thứ tương tự để chuẩn hóa "giao tiếp giữa ứng dụng AI và phần mở rộng".
-
Nguyên tắc thiết kế cốt lõi của MCP: khái niệm "công cụ" không chỉ nằm ở bản thân công cụ mà còn liên quan mật thiết đến ứng dụng khách và người dùng. Qua MCP, người dùng nên có quyền kiểm soát hoàn toàn. Việc mô hình điều khiển công cụ nghĩa là chỉ mô hình gọi công cụ đó, chứ không phải người dùng chủ động chỉ định dùng công cụ nào (trừ trường hợp gợi ý).
-
Open API và MCP không đối lập mà bổ trợ cho nhau. Chìa khóa là chọn công cụ phù hợp với từng nhiệm vụ cụ thể. Nếu mục tiêu là tương tác phong phú giữa các ứng dụng AI, MCP sẽ phù hợp hơn; nếu muốn mô hình dễ dàng đọc và diễn giải đặc tả API, Open API là lựa chọn tốt hơn.
-
Để xây dựng nhanh máy chủ MCP, việc sử dụng mã hóa trợ giúp bởi AI là phương pháp rất hiệu quả. Trong giai đoạn đầu phát triển, đưa các đoạn mã SDK MCP vào ngữ cảnh cửa sổ của LLM để LLM giúp xây dựng máy chủ thường mang lại kết quả tốt. Chi tiết có thể được tối ưu sau này – đây là cách nhanh để triển khai chức năng cơ bản và tiến hành lặp lại. Đồng thời, nhóm MCP của Anthropic rất chú trọng đơn giản hóa quy trình xây dựng máy chủ, tạo điều kiện thuận lợi cho LLM tham gia.
-
Hướng phát triển tương lai của ứng dụng AI, hệ sinh thái và Agent sẽ nghiêng về Statefulness (có trạng thái), đồng thời đây cũng là chủ đề gây tranh cãi nhất trong nhóm cốt lõi MCP của Anthropic. Sau nhiều lần thảo luận và lặp lại, kết luận đạt được là dù lạc quan về tương lai Statefulness nhưng không thể vì vậy mà đi lệch khỏi mô hình hiện tại – cần tìm sự cân bằng giữa lý tưởng Statefulness và độ phức tạp trong vận hành thực tế.
Founder Park đang xây dựng cộng đồng dành cho các nhà phát triển, mời các nhà phát triển, người sáng lập tích cực thử nghiệm, kiểm tra các mô hình mới, công nghệ mới tham gia. Vui lòng quét mã QR để điền đầy đủ thông tin sản phẩm/dự án của bạn, sau khi được xét duyệt, nhân viên sẽ thêm bạn vào nhóm.
Sau khi tham gia nhóm, bạn có cơ hội nhận được:
-
Giao lưu phát triển với các mô hình chính thống mật độ cao (như DeepSeek...);
-
Kết nối tài nguyên, cơ hội trao đổi, phản hồi trực tiếp với các nhà cung cấp API, nhà cung cấp điện toán đám mây, nhà cung cấp mô hình;
-
Các sản phẩm/dự án hay, thú vị sẽ được Founder Park chủ động quảng bá.
01 MCP ra đời như thế nào?
swyx (người dẫn): Trước tiên, MCP là gì?
Justin: Giao thức Ngữ cảnh Mô hình (Model Context Protocol), viết tắt là MCP, về cơ bản là thiết kế của chúng tôi nhằm hỗ trợ ứng dụng AI mở rộng khả năng hoặc tích hợp hệ sinh thái plugin. Cụ thể, MCP cung cấp một bộ giao thức truyền thông cho phép ứng dụng AI (gọi là "client") và các phần mở rộng bên ngoài khác nhau (gọi là "MCP server") phối hợp với nhau. Những "phần mở rộng" này có thể là plugin, công cụ hoặc các tài nguyên khác.
Mục đích của MCP là giúp mọi người khi xây dựng ứng dụng AI có thể dễ dàng tích hợp dịch vụ, chức năng bên ngoài hoặc truy xuất thêm dữ liệu, giúp ứng dụng có khả năng phong phú hơn. Chúng tôi sử dụng khái niệm "client-server" chủ yếu để nhấn mạnh mô hình tương tác, nhưng bản chất là tạo ra một giao diện phổ quát giúp ứng dụng AI dễ mở rộng hơn.
Tuy nhiên, cần nhấn mạnh rằng MCP tập trung vào ứng dụng AI chứ không phải mô hình – đây là một hiểu lầm phổ biến. Ngoài ra, chúng tôi đồng tình khi so sánh MCP với cổng USB-C của ứng dụng AI – nó là giao diện phổ quát kết nối toàn bộ hệ sinh thái.
swyx (người dẫn): Đặc tính client và server ngụ ý nó là hai chiều, giống như cổng USB-C, điều này thật thú vị. Nhiều người cố gắng nghiên cứu, xây dựng các dự án mã nguồn mở liên quan. Tôi cảm giác Anthropic tích cực hơn các phòng thí nghiệm khác trong việc thu hút nhà phát triển. Tò mò đằng sau điều này là ảnh hưởng bên ngoài hay do hai bạn “lóe sáng” trong một căn phòng nào đó?
David: Thực tế, phần lớn đúng là hai chúng tôi "lóe sáng" trong một căn phòng. Không phải là một phần của chiến lược lớn nào cả. Tháng 7 năm 2024, tôi vừa gia nhập Anthropic, phụ trách công cụ phát triển nội bộ. Trong quá trình làm việc, tôi suy nghĩ làm thế nào để nhiều nhân viên hơn có thể tích hợp sâu hơn với các mô hình hiện tại, vì các mô hình này rất tuyệt vời và tiềm năng còn lớn hơn nữa, dĩ nhiên mong muốn mọi người đều dùng mô hình nội bộ.
Trong công việc, dựa trên nền tảng kinh nghiệm về công cụ phát triển, tôi sớm cảm thấy hơi thất vọng, một mặt vì chức năng của Claude Desktop bị giới hạn, không thể mở rộng, trong khi IDE lại thiếu các chức năng hữu ích của Claude Desktop, khiến tôi phải sao chép nội dung qua lại giữa hai nơi rất phiền toái. Dần dần, tôi nhận ra đây là bài toán MxN – khó khăn giữa nhiều ứng dụng và nhiều loại tích hợp – và giải pháp lý tưởng nhất là một giao thức. Lúc đó tôi đang làm một dự án nội bộ liên quan đến LSP (Giao thức Máy chủ Ngôn ngữ), nhưng không tiến triển. Tổng hợp các ý tưởng này, sau vài tuần suy ngẫm, tôi nảy ra ý tưởng xây dựng một giao thức nào đó: Có thể xây dựng thứ gì đó giống LSP không? Chuẩn hóa "giao tiếp giữa ứng dụng AI và phần mở rộng".
Vì vậy, tôi tìm Justin, chia sẻ ý tưởng này, may mắn là anh ấy rất hào hứng, chúng tôi bắt tay vào xây dựng cùng nhau.
Từ lúc có ý tưởng đến hoàn thành giao thức và tích hợp lần đầu mất khoảng một tháng rưỡi. Justin đảm nhận phần lớn công việc tích hợp lần đầu tiên trên Claude Desktop, còn tôi thực hiện nhiều chứng minh khái niệm trong IDE, minh họa ứng dụng của giao thức trong IDE. Trước khi chính thức phát hành, nếu xem kho mã nguồn liên quan sẽ thấy rất nhiều chi tiết – đó là câu chuyện khởi nguyên đại khái của MCP.
Alessio (người dẫn): Thời gian biểu như thế nào? Tôi biết ngày 25 tháng 11 là ngày phát hành chính thức. Các bạn bắt đầu dự án này khi nào?
Justin: Khoảng tháng 7, sau khi David nêu ý tưởng, tôi nhanh chóng hào hứng và cùng anh ấy xây dựng MCP. Vài tháng đầu, vì xây dựng giao thức truyền thông gồm client, server và SDK có rất nhiều công việc nền tảng, nên tiến độ khá chậm. Nhưng khi các thành phần có thể truyền thông qua giao thức, mọi thứ trở nên thú vị, có thể xây dựng nhiều ứng dụng kỳ diệu.
Sau đó, chúng tôi tổ chức một cuộc thi hackathon nội bộ, một số đồng nghiệp dùng MCP xây dựng máy chủ điều khiển máy in 3D, hoặc mở rộng chức năng "bộ nhớ"... Các mẫu thử nghiệm này rất được yêu thích, khiến chúng tôi tin tưởng ý tưởng này có tiềm năng lớn.
swyx (người dẫn): Trở lại việc xây dựng MCP, những gì chúng ta thấy chỉ là thành quả cuối cùng, rõ ràng chịu ảnh hưởng từ LSP – điều cả hai bạn thừa nhận. Muốn hỏi về khối lượng công việc khi xây dựng? Là viết mã nhiều hay thiết kế nhiều? Tôi cảm giác thiết kế chiếm tỷ trọng lớn, ví dụ chọn JSON-RPC, mức độ học hỏi từ LSP, và những phần nào khó nhất?
Justin: Chúng tôi học hỏi rất nhiều từ LSP. David giàu kinh nghiệm với LSP trong lĩnh vực công cụ phát triển, còn tôi chủ yếu làm việc với sản phẩm hoặc hạ tầng, LSP là điều mới mẻ với tôi.
Xét về nguyên tắc thiết kế, LSP giải quyết bài toán M x N mà David nhắc đến. Trước đây, các IDE, trình soạn thảo và ngôn ngữ lập trình khác nhau hoạt động riêng lẻ, bạn không thể dùng hỗ trợ Java tuyệt vời của JetBrains trong Vim, hay hỗ trợ C tuyệt vời của Vim trong JetBrains. LSP tạo ra một ngôn ngữ chung để các bên "giao tiếp", thống nhất giao thức, khiến "trình soạn thảo-ngôn ngữ" chỉ cần triển khai một lần. Mục tiêu của chúng tôi tương tự, chỉ khác bối cảnh là "ứng dụng AI-phần mở rộng".
Về chi tiết cụ thể, sau khi áp dụng JSON-RPC và khái niệm truyền thông hai chiều, chúng tôi đi theo hướng khác. LSP chú trọng trình bày chức năng, suy nghĩ và cung cấp các yếu tố cơ bản khác nhau, chứ không phải nguyên tắc ngữ nghĩa, chúng tôi cũng áp dụng vào MCP. Sau đó, chúng tôi dành rất nhiều thời gian suy nghĩ về từng yếu tố cơ bản trong MCP và lý do khác biệt của chúng – đây là khối lượng công việc thiết kế lớn. Ban đầu, chúng tôi muốn hỗ trợ ba ngôn ngữ TypeScript, Python và Rust (cho tích hợp Zed), xây dựng SDK chứa client và server, tạo hệ sinh thái thử nghiệm nội bộ, và ổn định khái niệm MCP cục bộ (liên quan đến khởi động tiến trình con...).
Chúng tôi tham khảo nhiều phê bình dành cho LSP, cố gắng cải thiện trong MCP. Ví dụ, một số cách làm của LSP trên JSON-RPC quá phức tạp, chúng tôi thực hiện theo cách trực tiếp hơn. Khi xây dựng MCP, chúng tôi tập trung đổi mới trong lĩnh vực cụ thể, còn ở các khía cạnh khác thì học hỏi các mô hình trưởng thành, ví dụ chọn JSON-RPC không quan trọng, trọng tâm đặt vào đổi mới các yếu tố cơ bản – học hỏi thành quả tiền nhân rất hữu ích cho chúng tôi.
swyx (người dẫn): Tôi rất quan tâm đến thiết kế giao thức, có rất nhiều nội dung để mở rộng. Các bạn đã nhắc đến bài toán M x N, thực tế bất kỳ ai làm công cụ phát triển đều gặp phải, còn gọi là vấn đề "Hộp vạn năng (Universal Box)".
Giải pháp cơ bản cho vấn đề kỹ thuật hạ tầng là kết nối nhiều thứ với N đối tượng khác nhau, hãy tạo một "Hộp vạn năng". Uber, GraphQL, Temporal nơi tôi từng làm việc, và React đều có vấn đề này. Tò mò khi ở Facebook hai bạn đã từng giải quyết bài toán N nhân N chưa?
David: Về một mức độ nào đó thì đúng vậy. Đây là ví dụ rất hay. Tôi từng xử lý nhiều vấn đề kiểu này trong hệ thống kiểm soát phiên bản. Đó là việc tích hợp tất cả vấn đề vào một thứ mà mọi người có thể đọc/ghi, xây dựng "Hộp vạn năng" để giải quyết. Trong lĩnh vực công cụ phát triển, vấn đề này随处可见.
swyx (người dẫn): Thú vị là những người xây dựng "Hộp vạn năng" đều đối mặt vấn đề tương tự – tính kết hợp, vấn đề cục bộ và từ xa... Justin nhắc đến vấn đề trình bày chức năng, có những thứ bản chất giống nhau nhưng cần khái niệm rõ ràng để cách trình bày khác nhau.
02 Khái niệm cốt lõi của MCP: Công cụ, Tài nguyên và Gợi ý – Ba yếu tố không thể thiếu
swyx (người dẫn): Khi đọc tài liệu MCP tôi đã có câu hỏi này, tại sao hai thứ này phải khác nhau? Nhiều người coi gọi công cụ là giải pháp vạn năng, thực tế các kiểu gọi công cụ có ý nghĩa khác nhau, đôi khi là tài nguyên, đôi khi là thực hiện thao tác, đôi khi là mục đích khác. Tôi muốn biết các bạn phân loại những khái niệm nào là gần nhau? Tại sao nhấn mạnh tầm quan trọng của chúng?
Justin: Chúng tôi suy nghĩ từng khái niệm cơ bản từ góc nhìn nhà phát triển ứng dụng. Khi phát triển ứng dụng, dù là IDE, Claude Desktop hay giao diện Agent, từ góc nhìn người dùng muốn nhận được chức năng gì từ tích hợp, mọi thứ sẽ rõ ràng hơn, đồng thời, gọi công cụ là cần thiết, nhưng cần phân biệt các chức năng khác nhau.
Vì vậy, các khái niệm cơ bản cốt lõi ban đầu của MCP, sau này có bổ sung thêm:
-
Công cụ (Tool): Là cốt lõi. Tức là trực tiếp thêm công cụ cho mô hình, để mô hình tự quyết định khi nào gọi. Với nhà phát triển ứng dụng, điều này giống "gọi hàm", chỉ khác là do mô hình khởi xướng.
-
Tài nguyên (Resource): Về cơ bản chỉ dữ liệu hoặc thông tin nền có thể thêm vào ngữ cảnh mô hình, do ứng dụng kiểm soát. Ví dụ: có thể muốn mô hình tự động tìm kiếm và xác định tài nguyên liên quan, sau đó đưa chúng vào ngữ cảnh; hoặc có thể muốn thiết lập một chức năng giao diện người dùng rõ ràng trong ứng dụng, để người dùng thông qua menu thả xuống, menu ghim kẹp... đưa nó thành một phần thông tin gửi đến LLM – đây là các kịch bản ứng dụng của tài nguyên.
-
Gợi ý (Prompt): Được thiết kế cố ý là văn bản hoặc tin nhắn do người dùng khởi xướng hoặc thay thế. Ví dụ, nếu trong môi trường trình soạn thảo, giống lệnh gạch chéo (/), hoặc chức năng tự động hoàn thành, như có một macro muốn chèn trực tiếp để sử dụng.
Thông qua MCP, chúng tôi có quan điểm riêng về cách trình bày khác nhau của các nội dung này, nhưng cuối cùng vẫn do nhà phát triển ứng dụng quyết định. Với nhà phát triển ứng dụng, việc nhận được các khái niệm được biểu đạt theo cách khác nhau là rất hữu ích, có thể dựa vào đó xác định trải nghiệm phù hợp, tạo sự khác biệt. Từ góc nhìn nhà phát triển ứng dụng, họ không muốn ứng dụng mình giống hệt người khác, khi kết nối hệ sinh thái tích hợp mở, cần cách làm độc đáo để tạo trải nghiệm tốt nhất.
Tôi thấy có hai khía cạnh: Thứ nhất, hiện tại gọi công cụ chiếm hơn 95% trong tích hợp, tôi hy vọng nhiều client hơn sử dụng gọi tài nguyên, gọi gợi ý. Gọi gợi ý được triển khai đầu tiên, rất thực dụng, có thể xây dựng máy chủ MCP có thể truy xuất, đây là tương tác do người dùng điều khiển, người dùng quyết định thời điểm nhập thông tin, tốt hơn là chờ mô hình xử lý. Đồng thời hy vọng nhiều máy chủ MCP hơn dùng gợi ý để trình bày cách dùng công cụ.
Khía cạnh khác, phần tài nguyên cũng tiềm năng lớn, hình dung một máy chủ MCP công khai tài liệu, cơ sở dữ liệu... làm tài nguyên, client xây dựng chỉ mục hoàn chỉnh xung quanh chúng. Vì tài nguyên phong phú, không do mô hình công khai, bạn có thể sở hữu nhiều nội dung tài nguyên hơn nhiều so với những gì thực tế có sẵn trong cửa sổ ngữ cảnh. Mong đợi trong vài tháng tới, ứng dụng có thể tận dụng tốt hơn các khái niệm cơ bản này, tạo trải nghiệm phong phú hơn.
Alessio (người dẫn): Cầm cái búa thì muốn coi mọi thứ là đinh, dùng gọi công cụ giải quyết mọi vấn đề. Ví dụ nhiều người dùng nó để truy vấn cơ sở dữ liệu thay vì gọi tài nguyên. Tôi tò mò trong trường hợp có API (như cơ sở dữ liệu), dùng công cụ và tài nguyên có ưu nhược điểm gì? Khi nào nên dùng công cụ để truy vấn SQL? Khi nào nên dùng tài nguyên xử lý dữ liệu?
Justin: Cách chúng tôi phân biệt công cụ và tài nguyên là: công cụ do mô hình khởi xướng gọi, mô hình tự đánh giá tìm công cụ phù hợp và áp dụng. Nếu muốn LLM chạy truy vấn SQL, đặt nó làm công cụ là hợp lý.
Tài nguyên linh hoạt hơn, tuy nhiên hiện tại vì nhiều client không hỗ trợ nên tình hình phức tạp. Trong trạng thái lý tưởng, với cấu trúc bảng cơ sở dữ liệu... có thể thông qua gọi tài nguyên. Người dùng có thể dùng điều này để thông báo thông tin liên quan cho ứng dụng khi bắt đầu hội thoại, hoặc để ứng dụng AI tự động tìm tài nguyên. Chỉ cần có nhu cầu liệt kê thực thể và đọc, đặt mô hình hóa thành tài nguyên là hợp lý. Tài nguyên được định danh duy nhất bằng URI, có thể coi là bộ chuyển đổi phổ quát, ví dụ dùng máy chủ MCP diễn giải URI người dùng nhập. Lấy trình soạn thảo Zed làm ví dụ, nó có thư viện gợi ý và máy chủ MCP tương tác điền gợi ý, cả hai bên cần thống nhất về URI và định dạng dữ liệu – đây là ví dụ giao thoa rất thú vị của tài nguyên.
Quay lại góc nhìn nhà phát triển ứng dụng, suy nghĩ nhu cầu, áp dụng tư duy này vào thực tế, ví dụ, xem các chức năng ứng dụng hiện tại, nếu áp dụng cách này, chức năng nào có thể tách ra, do máy chủ MCP thực hiện. Về cơ bản, bất kỳ IDE nào có menu đính kèm đều có thể mô hình hóa tự nhiên thành tài nguyên. Chỉ là các cách triển khai này đã tồn tại.
swyx (người dẫn): Đúng vậy, khi tôi thấy ký hiệu @ trong Claude Desktop, tôi lập tức nghĩ đến chức năng giống Cursor, giờ người dùng khác cũng có thể dùng chức năng này. Mục tiêu thiết kế này rất tuyệt, vì chức năng vốn đã tồn tại, mọi người có thể dễ dàng hiểu và sử dụng. Tôi đã trình bày biểu đồ đó, các bạn chắc chắn đồng ý với giá trị của nó, tôi cho rằng nó rất hữu ích, nên đặt lên trang đầu tài liệu, đây là đề xuất rất hay.
Justin: Bạn có muốn gửi một PR (Pull Request) cho điều này không? Chúng tôi rất thích đề xuất này.
swyx (người dẫn): Được, tôi sẽ gửi.
Là một người làm quan hệ nhà phát triển, tôi luôn cố gắng cung cấp hướng dẫn rõ ràng cho mọi người, ví dụ trước tiên liệt kê các điểm then chốt, sau đó dành hai giờ giải thích chi tiết. Vì vậy, dùng một hình ảnh để bao quát nội dung cốt lõi rất hữu ích. Tôi rất trân trọng sự coi trọng của các bạn đối với gợi ý (Prompt). Trong giai đoạn đầu phát triển ChatGPT và Claude, nhiều người cố gắng tạo thư viện gợi ý, thư viện quản lý gợi ý trên GitHub, nhưng cuối cùng đều không thực sự phổ biến.
Thực tế, lĩnh vực này cần đổi mới nhiều hơn. Mọi người mong đợi gợi ý có tính động, và các bạn đã cung cấp khả năng này. Tôi rất công nhận khái niệm "gợi ý đa bước (multi-step prompt)" các bạn nhắc đến, điều này cho thấy đôi khi để mô hình hoạt động bình thường, cần cách gợi ý đa bước hoặc phá vỡ một số giới hạn. Gợi ý không chỉ là đầu vào hội thoại đơn lẻ, đôi khi là một chuỗi quá trình hội thoại.
swyx (người dẫn): Tôi nghĩ đây chính là nơi khái niệm tài nguyên và công cụ có sự giao thoa nhất định, vì bây giờ các bạn nhắc đến đôi khi cần mức độ kiểm soát của người dùng hoặc ứng dụng, trong khi thời điểm khác lại muốn mô hình kiểm soát. Vậy hiện tại chúng ta có đang chọn một tập con của công cụ không?
David: Đúng vậy, tôi cho rằng đây là mối lo hợp lý. Về bản chất, đây là nguyên tắc thiết kế cốt lõi của MCP, tức khái niệm công cụ thực tế không chỉ là bản thân công cụ, mà liên quan mật thiết đến ứng dụng client, và do đó liên quan mật thiết đến người dùng. Thông qua thao tác MCP, người dùng nên có quyền kiểm soát hoàn toàn. Khi chúng tôi nói công cụ do mô hình kiểm soát, nghĩa là chỉ mô hình gọi, chứ không phải người dùng chủ động chỉ định dùng công cụ nào (tất nhiên, ngoại trừ trường hợp mục đích gợi ý, nhưng điều này không nên là chức năng giao diện người dùng thông thường).
Nhưng tôi cho rằng, ứng dụng client hoặc người dùng quyết định lọc và tối ưu hóa nội dung do máy chủ MCP cung cấp là hoàn toàn hợp lý, ví dụ ứng dụng client có thể nhận mô tả công cụ từ máy chủ MCP và hiển thị đã được tối ưu. Trong mô hình MCP, ứng dụng client nên có quyền kiểm soát hoàn toàn. Ngoài ra, chúng tôi còn có một ý tưởng sơ khai: thêm chức năng trong giao thức, cho phép nhà phát triển máy chủ logic nhóm các yếu tố cơ bản như gợi ý, tài nguyên và công cụ. Những nhóm này có thể được coi là các máy chủ MCP khác nhau, sau đó người dùng có thể kết hợp chúng theo nhu cầu.
03 MCP và OpenAPI: Cạnh tranh hay Bổ trợ?
swyx (người dẫn): Muốn nói về so sánh MCP và Open API (API Mở),畢竟 đây rõ ràng là một trong những vấn đề được quan tâm nhất.
Justin/David: Về cơ bản, đặc tả Open API là công cụ rất mạnh mẽ, tôi thường xuyên sử dụng khi phát triển API và client của nó. Tuy nhiên, đối với kịch bản ứng dụng của mô hình ngôn ngữ lớn (LLM), đặc tả Open API quá chi tiết, nó không phản ánh đầy đủ các khái niệm cấp cao hơn, đặc thù cho AI, như các khái niệm cơ bản MCP và mô hình tư duy của nhà phát triển ứng dụng mà chúng tôi vừa nhắc đến. So với việc chỉ cung cấp một REST API để mô hình tự do xử lý, mô hình có thể hưởng lợi nhiều hơn từ các công cụ, tài nguyên, gợi ý và các khái niệm cơ bản khác được thiết kế chuyên biệt cho nó.
Mặt khác, khi thiết kế giao thức MCP, chúng tôi cố ý làm cho nó có tính trạng thái nhất định. Bởi vì bản chất của ứng dụng AI và tương tác nghiêng về Statefulness (có trạng thái). Mặc dù Stateless (vô trạng thái) luôn có chỗ đứng nhất định, nhưng khi các mô hình tương tác (như video, âm thanh...) ngày càng tăng, Statefulness sẽ ngày càng được ưa chuộng, do đó giao thức Statefulness cũng trở nên đặc biệt hữu ích.
Thực tế, Open API và MCP không đối lập mà bổ trợ lẫn nhau. Chúng đều mạnh mẽ theo cách riêng và rất bổ trợ. Tôi cho rằng chìa khóa là chọn công cụ phù hợp nhất với nhiệm vụ cụ thể. Nếu mục tiêu là đạt được tương tác phong phú giữa các ứng dụng AI, MCP sẽ phù hợp hơn; nếu muốn mô hình dễ dàng đọc và diễn giải đặc tả API, Open API sẽ là lựa chọn tốt hơn. Sớm đã có người xây cầu nối giữa hai bên, có một số công cụ có thể chuyển đổi đặc tả Open API thành dạng MCP để phát hành, ngược lại cũng vậy, điều này rất tuyệt.
Alessio (người dẫn): Tôi đồng tổ chức một cuộc thi hackathon tại AGI Studio. Là nhà phát triển Agent cá nhân, tôi thấy có người xây dựng một Agent cá nhân có thể tạo máy chủ MCP: chỉ cần nhập URL đặc tả API, nó có thể tạo máy chủ MCP tương ứng. Các bạn nhìn nhận hiện tượng này như thế nào? Có phải điều này có nghĩa là phần lớn máy chủ MCP chỉ là thêm một lớp trên API hiện tại, không có thiết kế độc đáo? Tương lai sẽ luôn như vậy, chủ yếu dựa vào AI để nối API hiện có, hay sẽ xuất hiện trải nghiệm MCP hoàn toàn mới, chưa từng có?
Justin/David: Tôi cho rằng cả hai tình huống đều sẽ tồn tại. Một mặt, nhu cầu "kết nối dữ liệu thông qua bộ kết nối vào ứng dụng" luôn có giá trị. Mặc dù hiện tại chủ yếu dùng gọi công cụ theo mặc định, nhưng tương lai các khái niệm cơ bản khác có lẽ phù hợp hơn để giải quyết loại vấn đề này. Ngay cả khi nó vẫn là một bộ kết nối hoặc lớp adapter, thông qua thích ứng các khái niệm khác nhau cũng có thể tăng giá trị.
Mặt khác, thực sự có cơ hội xuất hiện các kịch bản ứng dụng thú vị, xây dựng máy chủ MCP không chỉ đóng vai trò adapter. Ví dụ, một máy chủ MCP bộ nhớ có thể giúp LLM ghi nhớ thông tin qua các cuộc hội thoại khác nhau; một máy chủ MCP tư duy tuần tự có thể nâng cao khả năng suy luận của mô hình. Những máy chủ này không tích hợp với hệ thống bên ngoài mà cung cấp cách suy nghĩ hoàn toàn mới cho mô hình.
Dù sao, việc sử dụng AI để xây dựng máy chủ là hoàn toàn khả thi. Ngay cả khi chức năng cần triển khai không phải là thích ứng API khác mà mang tính nguyên bản, mô hình thường cũng có thể tìm ra cách thực hiện. Thực tế, nhiều máy chủ MCP sẽ là bộ bọc API, điều này vừa hợp lý vừa hiệu quả, giúp bạn tiến rất xa. Nhưng hiện tại chúng tôi vẫn đang trong giai đoạn khám phá, liên tục khám phá các khả năng có thể đạt được.
Khi client ngày càng hoàn thiện hỗ trợ các khái niệm cơ bản này, trải nghiệm phong phú sẽ bùng nổ. Ví dụ, một máy chủ MCP "tóm tắt nội dung bảng Reddit", hiện tại chưa ai xây dựng, nhưng bản thân giao thức hoàn toàn có thể thực hiện. Tôi cho rằng, khi nhu cầu của con người chuyển từ "Tôi chỉ muốn kết nối thứ tôi quan tâm vào LLM" sang "Tôi muốn một quy trình làm việc thực sự, một trải nghiệm thực sự phong phú hơn, nơi tôi muốn mô hình tương tác sâu sắc", bạn sẽ thấy các ứng dụng đổi mới này ra đời. Tuy nhiên, hiện tại thực sự tồn tại vấn đề "con gà và quả trứng" giữa khả năng hỗ trợ của client và chức năng mà nhà phát triển máy chủ muốn thực hiện.
04 Xây dựng máy chủ MCP nhanh như thế nào: Dùng lập trình AI
Alessio (người dẫn): Tôi cảm thấy có một khía cạnh của MCP mà người ta thảo luận ít hơn, đó là việc xây dựng máy chủ. Với các nhà phát triển muốn bắt đầu xây dựng máy chủ MCP, các bạn có lời khuyên gì không? Là nhà phát triển máy chủ, làm thế nào để tìm được điểm cân bằng tốt nhất giữa cung cấp mô tả chi tiết (để mô hình hiểu) và lấy dữ liệu thô trực tiếp (để mô hình xử lý tự động sau này)?
Justin/David: Tôi có một vài lời khuyên. Một ưu điểm của MCP là xây dựng các chức năng đơn giản rất dễ dàng, khoảng nửa tiếng có thể dựng xong, dù có thể chưa hoàn hảo nhưng đủ đáp ứng nhu cầu cơ bản. Cách tốt nhất để bắt đầu là: chọn ngôn ngữ lập trình bạn thích, nếu có SDK tương ứng thì dùng luôn; xây dựng một công cụ mà bạn muốn mô hình tương tác với nó; dựng máy chủ MCP; thêm công cụ này vào máy chủ; đơn giản viết mô tả công cụ; kết nối nó với ứng dụng bạn thích thông qua giao thức đầu vào/ra tiêu chuẩn; sau đó quan sát mô hình có thể sử dụng nó như thế nào.
Với nhà phát triển, khả năng nhanh chóng thấy mô hình tác động đến thứ họ quan tâm rất hấp dẫn, có thể khơi dậy nhiệt huyết, thúc đẩy họ suy nghĩ sâu hơn cần thêm những công cụ, tài nguyên, gợi ý nào, cũng như cách đánh giá hiệu quả và tối ưu gợi ý. Đây là quá trình có thể khám phá sâu liên tục, nhưng trước tiên hãy bắt đầu từ những điều đơn giản, xem mô hình tương tác với nội dung bạn quan tâm như thế nào, bản thân điều này đã rất thú vị rồi. MCP làm cho phát triển thêm thú vị, giúp mô hình nhanh chóng phát huy tác dụng.
Tôi cũng có xu hướng sử dụng lập trình trợ giúp bởi AI. Trong giai đoạn phát triển ban đầu, chúng tôi phát hiện có thể đưa các đoạn mã SDK MCP vào ngữ cảnh cửa sổ của LLM để LLM giúp xây dựng máy chủ, kết quả thường rất tốt, chi tiết có thể tối ưu sau. Đây là phương pháp tốt để nhanh chóng triển khai chức năng cơ bản và lặp lại. Ngay từ đầu, chúng tôi rất chú trọng đơn giản hóa quy trình xây dựng máy chủ, để LLM có thể tham gia. Trong vài năm qua, khởi động một máy chủ MCP có thể chỉ cần 100-200 dòng mã, thực sự rất đơn giản. Nếu không có SDK sẵn sàng, bạn cũng có thể cung cấp đặc tả liên quan hoặc SDK khác cho mô hình, để nó giúp bạn xây dựng một phần chức năng. Gọi công cụ trong ngôn ngữ bạn thích thường cũng rất trực tiếp.
Alessio (người dẫn): Tôi nhận thấy, người xây dựng máy chủ phần lớn quyết định định dạng dữ liệu và nội dung trả về cuối cùng. Ví dụ trong trường hợp gọi công cụ, như Google Maps, thuộc tính nào trả về do người xây dựng quyết định. Nếu thiếu thuộc tính nào đó, người dùng không thể ghi đè hoặc sửa đổi nó. Điều này giống với điểm tôi không hài lòng về một số SDK: khi người ta xây dựng SDK bọc API, nếu họ bỏ sót tham số mới của API, tôi không thể dùng các tính năng mới này. Các bạn nhìn nhận vấn đề này như thế nào? Người dùng nên có quyền can thiệp bao nhiêu, hay hoàn toàn do người thiết kế máy chủ quyết định?
Justin/David: Về ví dụ Google Maps, chúng tôi có thể có một phần trách nhiệm, vì nó là máy chủ tham chiếu chúng tôi phát hành. Nói chung, ít nhất hiện tại, với kết quả gọi công cụ, chúng tôi cố ý thiết kế nó không nhất thiết là dữ liệu JSON có cấu trúc, cũng không cần khớp với mô hình cụ thể, mà là dạng tin nhắn như văn bản, hình ảnh có thể đưa trực tiếp vào LLM. Nói cách khác, chúng tôi có xu hướng trả về lượng dữ liệu lớn, và tin rằng LLM có thể lọc và trích xuất thông tin nó quan tâm từ đó. Chúng tôi đã nỗ lực rất nhiều ở khía cạnh này, nhằm giúp mô hình linh hoạt lấy thông tin cần thiết, vì đây chính là điểm mạnh của nó. Chúng tôi suy nghĩ về cách phát huy tối đa tiềm năng của LLM, thay vì hạn chế hoặc chỉ định quá mức, tránh tình trạng trở nên khó mở rộng khi mô hình cải tiến. Do đó, trong máy chủ ví dụ, trạng thái lý tưởng là tất cả các loại kết quả đều có thể truyền nguyên样 từ API được gọi, dữ liệu được API tự động truyền.
Alessio (người dẫn): Xác định ranh giới ở đâu thực sự là quyết định khó.
David: Ở đây tôi có thể cần nhấn mạnh một chút vai trò của AI. Nhiều máy chủ ví dụ được Claude viết, điều này không ngạc nhiên. Hiện tại, mọi người thường quen xử lý vấn đề theo phương pháp kỹ thuật phần mềm truyền thống, nhưng thực tế chúng ta cần học lại cách xây dựng hệ thống cho LLM và tin tưởng vào khả năng của chúng. Khi LLM tiến bộ đáng kể mỗi năm, việc giao nhiệm vụ xử lý dữ liệu cho mô hình – vốn giỏi việc này – là lựa chọn sáng suốt. Điều này có nghĩa là chúng ta có thể buông bỏ kinh nghiệm thực tiễn kỹ thuật phần mềm truyền thống trong hai, ba thậm chí bốn mươi năm qua.
Nhìn MCP từ một góc độ khác, tốc độ phát triển của AI đáng kinh ngạc, vừa phấn khích vừa mang theo chút lo lắng. Điểm nghẽn lớn nhất cho bước nâng cấp tiếp theo của mô hình có thể nằm ở khả năng tương tác với thế giới bên ngoài, ví dụ đọc nguồn dữ liệu bên ngoài, thực hiện hành động Statefulness. Khi làm việc tại Anthropic, chúng tôi rất coi trọng tương tác an toàn, và thực hiện các biện pháp kiểm soát, hiệu chỉnh tương ứng. Khi AI phát triển, mọi người kỳ vọng mô hình có những khả năng này, và việc kết nối mô hình với bên ngoài là chìa khóa nâng cao năng suất AI. MCP cũng chính là cam kết của chúng tôi về định hướng và tầm quan trọng trong tương lai.
Alessio (người dẫn): Đúng vậy, tôi nghĩ bất kỳ thuộc tính API nào có chữ "định dạng" (formatted) nên được gỡ bỏ. Chúng ta nên lấy dữ liệu thô từ mọi giao diện. Tại sao cần định dạng trước? Mô hình chắc chắn đủ thông minh để tự định dạng thông tin như địa chỉ. Vì vậy phần này nên do người dùng cuối quyết định.
05 Làm thế nào để MCP gọi được nhiều công cụ hơn?
swyx (người dẫn): Tôi còn một câu hỏi, một triển khai MCP có thể hỗ trợ bao nhiêu chức năng liên quan? Điều này liên quan đến vấn đề chiều rộng và chiều sâu, cũng liên quan trực tiếp đến việc lồng ghép MCP mà chúng ta vừa thảo luận.
Tháng 4 năm 2024, khi Claude ra mắt ví dụ ngữ cảnh triệu token đầu tiên, từng nói có thể hỗ trợ 250 công cụ, nhưng trong nhiều trường hợp thực tế, mô hình không thể sử dụng hiệu quả nhiều công cụ đến vậy. Theo một nghĩa nào đó, đây là vấn đề chiều rộng, vì không có công cụ gọi công cụ, chỉ có mô hình và cấu trúc công cụ một tầng phẳng, điều này dễ dẫn đến nhầm lẫn công cụ. Khi chức năng công cụ tương tự, mô hình có thể gọi nhầm công cụ, dẫn đến kết quả không lý tưởng. Về số lượng tối đa máy chủ MCP được bật tại bất kỳ thời điểm nào, các bạn có lời khuyên gì không?
Justin: Thành thật mà nói, câu hỏi này không có câu trả lời tuyệt đối. Một mặt phụ thuộc vào mô hình bạn dùng, mặt khác phụ thuộc vào tên và mô tả công cụ có đủ rõ ràng để mô hình hiểu chính xác, tránh nhầm lẫn hay không. Trạng thái lý tưởng là cung cấp tất cả thông tin cho LLM, hoàn toàn do nó xử lý mọi thứ, đây cũng là bản đồ tương lai mà MCP hình dung. Nhưng trong ứng dụng thực tế, ứng dụng client (tức ứng dụng AI) có thể cần làm một số công việc bổ sung, ví dụ lọc tập công cụ, hoặc dùng một LLM nhỏ và nhanh để lọc ra công cụ liên quan nhất trước, sau đó truyền cho mô hình lớn. Ngoài ra, cũng có thể thiết lập một số máy chủ MCP làm proxy cho máy chủ MCP khác để lọc.
Ít nhất với Claude, hỗ trợ hàng trăm công cụ là khá ổn. Nhưng với các mô hình khác thì chưa rõ. Theo thời gian, tình hình nên ngày càng tốt hơn, vì vậy cần thận trọng với các giới hạn, tránh cản trở sự phát triển này. Số lượng công cụ có thể hỗ trợ phần lớn phụ thuộc vào mức độ trùng lặp mô tả. Nếu chức năng máy chủ khác nhau, tên và mô tả công cụ rõ ràng và độc đáo, số lượng công cụ có thể hỗ trợ có thể nhiều hơn so với trường hợp máy chủ chức năng tương tự (ví dụ kết nối đồng thời máy chủ GitLab và GitHub).
Ngoài ra, điều này cũng liên quan đến loại ứng dụng AI. Khi xây dựng ứng dụng trí tuệ cao, bạn có thể giảm việc hỏi người dùng và tính cấu hình giao diện; nhưng khi xây dựng chương trình như IDE hoặc ứng dụng trò chuyện, cho phép người dùng chọn tập chức năng họ muốn tại các thời điểm khác nhau, thay vì luôn bật tất cả, là hoàn toàn hợp lý.
swyx (người dẫn): Cuối cùng, chúng ta hãy tập trung nói về máy chủ tư duy tuần tự (Sequential Thinking MCP Server). Nó có chức năng phân nhánh, còn có khả năng "cung cấp thêm không gian viết", điều này rất thú vị. Ngoài ra, tuần trước Anthropic phát hành một blog kỹ thuật mới, giới thiệu công cụ Tư duy (Thinking Tool) của họ, cộng đồng có một số nghi ngờ liệu máy chủ tư duy tuần tự và công cụ tư duy này có trùng lặp. Thực tế, đây chỉ là các nhóm khác nhau làm việc tương tự theo cách khác nhau, dù sao cũng có nhiều cách thực hiện.
Justin/David: Theo tôi biết, máy chủ tư duy tuần tự và công cụ tư duy của Anthropic không có nguồn gốc chung trực tiếp. Nhưng điều này thực sự phản ánh một hiện tượng phổ biến: để LLM suy nghĩ toàn diện hơn, giảm ảo giác hoặc đạt các mục tiêu khác, có nhiều chiến lược khác nhau, có thể thể hiện hiệu quả toàn diện và đáng tin cậy hơn từ nhiều chiều. Chính đây là điểm mạnh của MCP – bạn có thể xây dựng máy chủ khác nhau, hoặc thiết lập sản phẩm hoặc công cụ khác nhau trong cùng một máy chủ để thực hiện chức năng đa dạng, khiến LLM áp dụng mô hình tư duy cụ thể để đạt kết quả khác nhau.
Vì vậy, không tồn tại một cách suy nghĩ LLM lý tưởng, quy định sẵn nào cả.
swyx (người dẫn): Tôi cho rằng các ứng dụng khác nhau sẽ có mục đích sử dụng khác nhau, và MCP chính là cho phép bạn thực hiện sự đa dạng này, đúng không?
Justin/David: Đúng vậy. Tôi cảm thấy một số phương pháp mà máy chủ MCP áp dụng thực tế lấp đầy khoảng trống trong khả năng của mô hình tại thời điểm đó. Việc huấn luyện mô hình, chuẩn bị và nghiên cứu cần rất nhiều thời gian để từng bước nâng cao khả năng. Lấy máy chủ tư duy tuần tự làm ví dụ, nó trông có vẻ đơn giản, nhưng thực tế không phải vậy, và có thể dựng xong trong vài ngày. Tuy nhiên, nếu muốn thực hiện chức năng tư duy phức tạp này trực tiếp trong mô hình, tuyệt đối không thể hoàn thành trong vài ngày.
Ví dụ, nếu mô hình tôi dùng không đáng tin cậy lắm, hoặc có người cảm thấy kết quả mô hình tạo ra tổng thể chưa đáng tin cậy, tôi có thể hình dung xây dựng một máy chủ MCP, để mô hình thử tạo ba kết quả cho một truy vấn, sau đó chọn ra kết quả tốt nhất. Nhờ MCP, có thể thực hiện cách tương tác LLM đệ quy và có thể kết hợp như vậy.
06 MCP phức tạp và Agent khác nhau thế nào?
Alessio (người dẫn): Tiếp theo tôi muốn hỏi về tính kết hợp. Các bạn nhìn nhận thế nào về khái niệm đưa một MCP vào MCP khác? Có kế hoạch liên quan nào không? Ví dụ, nếu tôi muốn xây dựng một MCP tóm tắt nội dung bảng Reddit, điều này có thể cần gọi một MCP tương ứng API Reddit, và một MCP cung cấp chức năng tóm tắt. Vậy tôi nên xây dựng "MCP siêu cấp" này như thế nào?
Justin/David: Đây là chủ đề rất thú vị, có thể xem xét từ hai khía cạnh.
Một mặt, xem xét xây dựng các thành phần như chức năng tóm tắt. Mặc dù nó có thể gọi LLM, nhưng chúng tôi muốn nó giữ tính độc lập với mô hình cụ thể. Điều này liên quan đến chức năng truyền thông hai chiều của MCP. Lấy Cursor làm ví dụ, nó quản lý vòng lặp tương tác với LLM. Nhà phát triển máy chủ có thể yêu cầu client (tức ứng dụng nơi người dùng) thực hiện một số nhiệm vụ thông qua Cursor, ví dụ yêu cầu client dùng mô hình hiện tại người dùng chọn để tóm tắt và trả kết quả. Như vậy, việc chọn mô hình tóm tắt do Cursor quyết định, nhà phát triển không cần đưa thêm SDK hoặc khóa API vào phía máy chủ, từ đó đạt được việc xây dựng độc lập với mô hình cụ thể.
Mặt khác, hoàn toàn có thể dùng MCP để xây dựng hệ thống phức tạp hơn. Bạn có thể hình dung một máy chủ MCP, cung cấp hỗ trợ cho các dịch vụ như Cursor hoặc Windsurf, đồng thời bản thân máy chủ này cũng là một client MCP, gọi các máy chủ MCP khác để tạo trải nghiệm phong phú hơn. Điều này thể hiện tính đệ quy, cũng thể hiện trong các khía cạnh như ủy quyền đặc tả. Bạn có thể nối các ứng dụng vừa là máy chủ vừa là client này lại với nhau, thậm chí dùng máy chủ MCP xây dựng đồ thị acyclic có hướng (DAG) để thực hiện luồng tương tác phức tạp. Máy chủ MCP thông minh thậm chí có thể tận dụng toàn bộ khả năng hệ sinh thái máy chủ MCP. Người ta đã thực hiện các thử nghiệm liên quan. Nếu thêm các chức năng như lựa chọn tự động, cài đặt... còn có nhiều khả năng có thể thực hiện.
Hiện tại, SDK của chúng tôi cần thêm nhiều chi tiết hơn để nhà phát triển dễ dàng xây dựng ứng dụng vừa là client vừa là máy chủ MCP đệ quy, hoặc thuận tiện tái sử dụng hành vi của nhiều máy chủ MCP. Đây là những nội dung cần hoàn thiện trong tương lai, nhưng chúng đã có thể minh họa một số kịch bản khả thi hiện tại dù chưa được áp dụng rộng rãi.
swyx (người dẫn): Điều này nghe thật thú vị, tôi tin nhiều người sẽ nhận được nhiều ý tưởng và cảm hứng từ đây. Vậy, một MCP vừa là máy chủ vừa là client như vậy, có thể coi là một Agent không? Về cơ bản, Agent là bạn đưa ra một yêu cầu, nó sẽ thực hiện một số thao tác nền mà bạn có thể không hoàn toàn rõ. Có một lớp trừu tượng giữa bạn và nguồn dữ liệu gốc cuối cùng. Các bạn có hiểu biết sâu sắc nào về Agent không?
Justin/David: Tôi cho rằng thực sự có thể xây dựng một Agent theo cách MCP. Ở đây cần phân biệt, chỉ một máy chủ MCP cộng client làm Agent, với một Agent thực sự, có sự khác biệt. Ví dụ, bên trong một máy chủ MCP, có thể tận dụng vòng lặp mẫu (sample loop) do client cung cấp để làm phong phú trải nghiệm, và để mô hình gọi công cụ, như vậy xây dựng một Agent thực sự là tương đối trực tiếp.
Về mối quan hệ giữa MCP và Agent, chúng tôi có một vài hướng suy nghĩ khác nhau:
Thứ nhất, MCP có thể là cách rất tốt để biểu đạt khả năng của Agent, nhưng có lẽ hiện tại còn thiếu một số đặc tính hoặc chức năng để nâng cao trải nghiệm người dùng, những điều này nên được xem xét đưa vào giao thức MCP.
Thứ hai, có thể dùng MCP làm lớp truyền thông cơ sở để xây dựng Agent, hoặc để các Agent khác nhau kết hợp với nhau. Tất nhiên, vẫn có khả năng khác, ví dụ cho rằng MCP nên tập trung hơn vào tích hợp ở cấp độ ứng dụng AI, thay vì quá chú ý đến khái niệm Agent bản thân. Đây vẫn là vấn đề đang được thảo luận, mỗi hướng đều có sự đánh đổi. Quay lại ví dụ "Hộp vạn năng" trước đó, khi thiết kế giao thức và quản lý hệ sinh thái, điểm cần đặc biệt cẩn trọng là tránh chức năng quá phong phú, không để giao thức cố gắng ôm đồm mọi thứ, nếu không có thể dẫn đến hiệu suất kém ở mọi khía cạnh. Câu hỏi then chốt là Agent có thể hòa nhập tự nhiên đến mức nào vào khuôn khổ mô hình và mô hình hiện tại, hoặc nó nên tồn tại như một thực thể độc lập đến mức nào, đây vẫn là vấn đề chưa hoàn toàn giải quyết.
swyx (người dẫn): Tôi cho rằng, khi đạt được truyền thông hai chiều, cho phép client và server hợp nhất làm một, và có thể ủy thác công việc cho các máy chủ MCP khác, nó sẽ giống Agent hơn. Tôi rất trân trọng việc các bạn luôn ghi nhớ tầm quan trọng của sự đơn giản, không cố gắng giải quyết mọi vấn đề.
07 Bước tiếp theo của MCP: Làm thế nào để giao thức đáng tin cậy hơn?
swyx (người dẫn): Gần đây việc cập nhật từ máy chủ có trạng thái sang máy chủ vô trạng thái thu hút sự quan tâm. Các bạn chọn Sự kiện Máy chủ Gửi (SSE) làm giao thức phát hành và phương thức truyền
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
