Tác giả: FounderPark
Giao thức MCP được Anthropic phát hành năm ngoái bất ngờ trở thành giao thức hot nhất trong lĩnh vực AI năm nay do sự phổ biến của Manus và Agent. OpenAI, Microsoft, Google và các công ty lớn khác cũng đã hỗ trợ giao thức này. Trong nước, Alibaba Cloud Bailian và Tencent Cloud cũng nhanh chóng đi theo xu hướng này và ra mắt các nền tảng xây dựng nhanh chóng.
Nhưng cũng có nhiều tranh cãi. Nhiều người thắc mắc rằng không có nhiều khác biệt giữa MCP và API, rằng các kỹ sư của Anthropic không thành thạo về các giao thức Internet và rằng có những vấn đề bảo mật do tính đơn giản của giao thức.
Người phát minh ra giao thức MCP hẳn phải trả lời những câu hỏi này.
Trong một podcast gần đây của Latent Space, họ đã mời những người phát minh ra giao thức MCP từ đội ngũ Anthropic, Justin Spahr-Summers và David Soria Parra, để nói chi tiết về nguồn gốc của MCP và nhiều suy nghĩ của họ về MCP: lý do MCP được ra mắt, MCP khác với các API hiện có như thế nào, cách sử dụng tốt hơn các công cụ với MCP, v.v. Lượng thông tin rất lớn, tôi khuyên bạn nên lưu lại để đọc.
Giới thiệu khách mời:
Alessio Fanelli (Người điều phối): Đối tác và Giám đốc công nghệ của Decibel
swyx (chủ nhà): Người sáng lập Small AI
David Soria Parra: Kỹ sư nhân chủng học
Justin Spahr-Summers: Kỹ sư nhân chủng học
Tóm lại:
"Ý tưởng lóe sáng" cho khái niệm MCP xuất phát từ một dự án nội bộ của Anthropic, LSP (Giao thức máy chủ ngôn ngữ). Lấy cảm hứng từ LSP, hai kỹ sư tự hỏi liệu họ có thể tạo ra thứ gì đó tương tự LSP để chuẩn hóa "giao tiếp giữa các ứng dụng AI và mở rộng" hay không.
Nguyên tắc thiết kế cốt lõi của MCP là khái niệm công cụ không chỉ là bản thân công cụ mà còn liên quan chặt chẽ đến ứng dụng máy trạm và người dùng. Người dùng phải có toàn quyền kiểm soát hoạt động của MCP. Các công cụ được kiểm soát bởi mô hình, nghĩa là chúng chỉ được mô hình gọi, thay vì người dùng chủ động chỉ định cách sử dụng công cụ (trừ mục đích nhắc nhở).
API mở và MCP không loại trừ lẫn nhau mà bổ sung cho nhau. Điều quan trọng là chọn công cụ tốt nhất cho nhiệm vụ cụ thể. Nếu mục tiêu là đạt được sự tương tác phong phú giữa các ứng dụng AI, MCP sẽ phù hợp hơn; nếu bạn muốn mô hình có thể dễ dàng đọc và diễn giải các thông số kỹ thuật API, API mở sẽ là lựa chọn tốt hơn.
Để xây dựng nhanh chóng các máy chủ MCP, sử dụng mã hóa hỗ trợ AI là một cách rất tốt. Trong giai đoạn đầu phát triển, hãy đưa đoạn mã SDK MCP vào cửa sổ ngữ cảnh LLM và để LLM giúp xây dựng máy chủ. Kết quả thường rất tốt và các chi tiết có thể được tối ưu hóa thêm sau này. Đây là một phương pháp tốt để triển khai nhanh các chức năng cơ bản và lặp lại. Đồng thời, đội ngũ MCP của Anthropic rất tập trung vào việc đơ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 sự tham gia của LLM.
Hướng phát triển trong tương lai của các ứng dụng, hệ sinh thái và tác nhân AI sẽ có xu hướng là Trạng thái, đây cũng là một trong những chủ đề gây tranh cãi nhất trong đội ngũ cốt lõi MCP của Anthropic. Sau lần cuộc thảo luận và lặp lại, chúng tôi kết luận rằng mặc dù lạc quan về tương lai của Statefulness, chúng tôi không thể đi chệch khỏi mô hình hiện tại và phải tìm ra sự cân bằng giữa khái niệm Statefulness và tính phức tạp của các hoạt động thực tế.
Founder Park đang xây dựng một cộng đồng nhà phát triển, mời các nhà phát triển và doanh nhân đang tích cực thử nghiệm các mô hình và công nghệ mới tham gia. Vui lòng quét mã QR để điền thông tin chi tiết về sản phẩm/dự án của bạn. Sau khi vượt qua vòng đánh giá, nhân viên sẽ thêm bạn vào nhóm~
Sau khi tham gia nhóm, bạn sẽ có cơ hội nhận được:
Nồng độ cao về phát triển và truyền thông mô hình chính thống (như DeepSeek, v.v.);
Kết nối tài nguyên, cơ hội giao tiếp trực tiếp và phản hồi với API, nhà cung cấp đám mây và nhà cung cấp mô hình;
Nhà sáng lập Park sẽ tích cực quảng bá các sản phẩm/trường hợp hữu ích và thú vị.
01 MCP ra đời như thế nào?
swyx (chủ nhà): Trước hết, MCP là gì?
Justin: Model Context Protocol, hay viết tắt là MCP, về cơ bản là thiết kế mà chúng tôi tạo ra để giúp các ứng dụng AI tự mở rộng hoặc tích hợp hệ sinh thái plug-in in. Cụ thể, MCP cung cấp một bộ giao thức truyền thông cho phép các ứng dụng AI (mà chúng tôi gọi là "máy trạm") và nhiều mở rộng rộng bên ngoài (mà chúng tôi gọi là "máy chủ MCP") cộng tác với nhau. "Mở rộng" ở đây có thể là plug-in, công cụ hoặc tài nguyên khác.
Mục đích của MCP là cho phép mọi người dễ dàng giới thiệu các dịch vụ và chức năng bên ngoài hoặc thu thập thêm dữ liệu khi xây dựng các ứng dụng AI, để các ứng dụng có khả năng phong phú hơn. Khái niệm "máy khách-máy chủ" được đưa vào tên gọi của chúng tôi, chủ yếu là để nhấn mạnh chế độ tương tác, nhưng bản chất là tạo ra một giao diện chung "giúp các ứng dụng AI dễ mở rộng".
Tuy nhiên, điều quan trọng cần nhấn mạnh là MCP tập trung vào các ứng dụng AI hơn là bản thân các mô hình, đây là một hiểu lầm thường gặp. Hơn nữa, chúng tôi đồng ý rằng MCP giống như cổng USB-C dành cho các ứng dụng AI, là giao diện chung kết nối toàn bộ hệ sinh thái.
swyx (máy chủ): Bản chất máy trạm và máy chủ có nghĩa là nó là giao tiếp hai chiều, giống như giao diện USB-C, điều này rất thú vị. Nhiều người cố gắng thực hiện nghiên cứu liên quan và xây dựng các dự án mã nguồn mở. Tôi cảm thấy Anthropic năng động hơn các phòng thí nghiệm khác trong việc thu hút các nhà phát triển. Tôi tò mò không biết có tác động bên ngoài nào đằng sau việc này không, hay đó chỉ là một ý tưởng bất chợt nảy ra trong đầu hai bạn khi đang ngồi cùng phòng?
David : Thực ra, hầu hết chỉ có hai chúng tôi trong phòng nghĩ ra theo ý thích nhất thời. Đây không phải là một phần của chiến lược lớn. Tôi gia nhập Anthropic vào tháng 7 năm 2024 và chủ yếu chịu trách nhiệm về các công cụ phát triển nội bộ. Trong thời gian này, tôi đã suy nghĩ về cách để có thêm nhiều nhân viên tích hợp sâu vào các mô hình hiện có. Xét cho cùng, những mô hình này rất tuyệt vời và có triển vọng tốt hơn. Tất nhiên, tôi hy vọng mọi người sẽ sử dụng mô hình của chúng ta nhiều hơn.
Ở nơi làm việc, tôi nhanh chóng cảm thấy thất vọng với bối cảnh của mình về các công cụ phát triển vì Claude Desktop bị hạn chế và không thể mở rộng, còn IDE thì thiếu các tính năng hữu ích của Claude Desktop, nên tôi phải sao chép nội dung qua lại giữa hai công cụ, điều này thật bất tiện. Theo thời gian. Tôi nhận ra rằng đây là vấn đề MxN, tức là nhiều ứng dụng và nhiều tích hợp, và cách giải quyết tốt nhất là sử dụng một giao thức duy nhất. Vào thời điểm đó, tôi vẫn đang làm việc trên một dự án nội bộ liên quan đến LSP (Giao thức máy chủ ngôn ngữ) và không có nhiều tiến triển. Kết hợp những ý tưởng này và suy nghĩ về chúng trong vài tuần, tôi đã nảy ra ý tưởng xây dựng một loại giao thức nào đó: Tôi có thể tạo ra thứ gì đó tương tự như LSP không? Chuẩn hóa " giao tiếp mở rộng các ứng dụng và tiện ích mở rộng AI ".
Vì vậy, tôi đã tìm thấy Justin và chia sẻ ý tưởng này, may mắn thay, anh ấy cũng quan tâm, vì vậy chúng tôi bắt đầu cùng nhau xây dựng nó.
Từ khi ý tưởng xuất hiện, phải mất khoảng một tháng rưỡi để xây dựng giao thức và hoàn tất tích hợp đầu tiên. Justin đã bỏ lượng lớn công sức vào tích hợp Claude Desktop đầu tiên, còn tôi đã thực hiện nhiều bằng chứng về khái niệm trong IDE để chỉ ra cách giao thức có thể được sử dụng trong IDE. Trước khi phát hành chính thức, việc xem xét cơ sở mã liên quan đã tiết lộ rất nhiều chi tiết. Đây là câu chuyện về nguồn gốc của MCP.
Alessio (Người dẫn chương trình): Dòng thời gian là gì? Tôi biết ngày 25 tháng 11 là ngày phát hành chính thức. Bạn bắt đầu thực hiện dự án này khi nào?
Justin : Vào khoảng tháng 7, sau khi David đề xuất ý tưởng, tôi nhanh chóng hào hứng được hợp tác với anh ấy để xây dựng MCP. Trong vài tháng đầu, tiến độ diễn ra chậm vì có lượng lớn công việc nền tảng để xây dựng giao thức truyền thông bao gồm máy trạm , máy chủ và SDK. Nhưng một khi mọi thứ có thể giao tiếp thông qua giao thức, nó sẽ trở nên thú vị và bạn có thể xây dựng đủ loại ứng dụng tuyệt vời.
Sau đó, chúng tôi tổ chức một hacker nội bộ và một số đồng nghiệp đã sử dụng MCP để lập trình máy chủ có thể điều khiển máy in 3D cũng như triển khai mở rộng như "chức năng bộ nhớ". Các nguyên mẫu được đón nhận nồng nhiệt và giúp chúng tôi tin tưởng rằng ý tưởng này có tiềm năng rất lớn.
swyx (người điều phối): Quay lại với việc xây dựng MCP, tất cả những gì chúng ta thấy là sản phẩm cuối cùng, rõ ràng là lấy cảm hứng từ LSP, như cả hai bạn đều thừa nhận. Tôi muốn hỏi khối lượng công việc khi xây dựng như thế nào? Quá trình xây dựng chủ yếu là quá trình mã hóa chuyên lượng lớn hay lượng lớn trình thiết kế chuyên sâu? Tôi cảm thấy công việc thiết kế chiếm tỷ lệ tỷ lệ lớn. Ví dụ, khi chọn JSON-RPC, nó sử dụng LSP ở mức độ nào? Những phần nào còn khó hơn?
Justin : Chúng tôi nhận được rất nhiều cảm hứng từ LSP. David có nhiều kinh nghiệm với LSP về mặt công cụ phát triển, tôi chủ yếu làm việc trong lĩnh vực sản phẩm hoặc cơ sở hạ tầng và LSP là khái niệm mới đối với tôi.
Theo quan điểm nguyên tắc thiết kế, LSP giải quyết được vấn đề M x N mà David đã đề cập. Trước đây, các IDE, trình soạn thảo và ngôn ngữ lập trình khác nhau là những thực thể riêng biệt. Bạn không thể sử dụng khả năng hỗ trợ Java tuyệt vời của JetBrains trong Vim, cũng như khả năng hỗ trợ ngôn ngữ C tuyệt vời của Vim trong JetBrains. LSP cho phép tất cả các bên "giao tiếp" bằng cách tạo ra một ngôn ngữ chung. LSP thống nhất giao thức để "ngôn ngữ biên tập" chỉ cần được triển khai một lần. Mục tiêu của chúng tôi thì tương tự, nhưng kịch bản đã thay đổi thành mối liên hệ giữa "ứng dụng AI - mở rộng".
Về chi tiết cụ thể, chúng tôi đã áp dụng các khái niệm về JSON-RPC và giao tiếp hai chiều và đi theo một hướng khác. LSP tập trung vào trình bày chức năng, tư duy và cung cấp các yếu tố cơ bản khác nhau thay vì các nguyên tắc ngữ nghĩa, mà chúng tôi cũng áp dụng cho MCP. Sau đó, chúng tôi dành lượng lớn thời gian suy nghĩ về từng yếu tố cơ bản trong MCP và lý do tại sao chúng lại khác biệt, đây là lượng lớn. Ban đầu, chúng tôi muốn hỗ trợ TypeScript, Python và Rust để tích hợp Zed, xây dựng SDK với máy trạm và máy chủ, thúc đẩy hệ sinh thái thử nghiệm nội bộ và ổn định các khái niệm MCP gốc (bao gồm việc khởi chạy các quy trình phụ, v.v.).
Chúng tôi tham khảo nhiều lời chỉ trích về LSP và cố gắng cải thiện nó trong MCP. Ví dụ, một số cách tiếp cận của LSP trên JSON-RPC quá phức tạp, vì vậy chúng tôi đã thực hiện một số triển khai trực tiếp hơn. Bởi vì khi xây dựng MCP, chúng tôi đã lựa chọn đổi mới ở những lĩnh vực cụ thể và vay mượn những mô hình trưởng thành ở những khía cạnh khác . Ví dụ, không quan trọng khi chọn JSON-RPC mà nên tập trung vào những cải tiến như các thành phần cơ bản. Việc học hỏi từ những thành tựu của những người đi trước trong những khía cạnh này rất có ích cho chúng ta.
swyx (chủ nhà): Tôi quan tâm đến thiết kế giao thức và có rất nhiều điều để thảo luận ở đây. Bạn đã đề cập đến Bài toán M x N. Trên thực tế, bất kỳ ai làm việc trên các công cụ phát triển đều gặp phải vấn đề này, đó là sự cố "Universal Box".
Vấn đề cơ bản và giải pháp của kỹ thuật cơ sở hạ tầng là kết nối nhiều thứ với N thứ khác nhau và tạo ra một "hộp chung". Các công ty như Uber, GraphQL, Temporal nơi tôi từng làm việc và React đều gặp phải vấn đề này. Tôi tò mò, bạn đã từng giải bài toán N lần N khi bạn còn làm việc ở Facebook chưa?
David: Ở một mức độ nào đó thì đúng vậy. Đây là một ví dụ hay. Tôi đã từng xử lý rất nhiều vấn đề tương tự như thế này với các hệ thống kiểm soát phiên bản. Đó là tích hợp tất cả các vấn đề thành thứ mà mọi người đều có thể đọc và viết, và xây dựng một "hộp chung" để giải quyết chúng. Trong thế giới công cụ dành cho nhà phát triển, những vấn đề như thế này xuất hiện ở khắp mọi nơi.
swyx (chủ nhà): Điều thú vị là những người xây dựng một “hộp chung” sẽ phải đối mặt với những vấn đề giống nhau, cụ thể là khả năng cấu hình, các vấn đề từ xa và cục bộ, v.v. Justin đã đề cập đến vấn đề trình bày chức năng. Một số thứ về cơ bản là giống nhau, nhưng chúng cần được trình bày khác nhau để làm rõ các khái niệm.
02 Khái niệm cốt lõi của MCP: công cụ, tài nguyên và mẹo là không thể thiếu
swyx (chủ nhà): Tôi có câu hỏi này khi đọc tài liệu MCP, tại sao lại có sự khác biệt giữa hai điều này? Nhiều người coi việc gọi công cụ là giải pháp chung. Trên thực tế, các loại lệnh gọi công cụ khác nhau có ý nghĩa khác nhau. Đôi khi chúng là tài nguyên, đôi khi chúng là hoạt động, và đôi khi chúng phục vụ cho mục đích khác. Tôi muốn biết bạn nhóm những khái niệm nào vào các danh mục tương tự nhau? Tại sao lại nhấn mạnh tầm quan trọng của chúng?
Justin : Chúng tôi suy nghĩ về mọi khái niệm cơ bản theo góc nhìn của một nhà phát triển ứng dụng. Khi phát triển một ứng dụng, cho dù đó là IDE, Claude Desktop hay giao diện Agent, các chức năng mà người dùng muốn có được từ tích hợp sẽ rõ ràng hơn nhiều. Đồng thời, cần phải có lệnh gọi công cụ và 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 đó đã được mở rộng:
Công cụ : là cốt lõi. Nghĩa là thêm các công cụ trực tiếp vào mô hình và để mô hình quyết định thời điểm gọi chúng. Đối với các nhà phát triển ứng dụng, điều này tương tự như "lời gọi hàm", nhưng nó được khởi tạo bởi mô hình.
Tài nguyên : Về cơ bản đề cập đến dữ liệu hoặc thông tin bối cảnh có thể được thêm vào bối cảnh của mô hình và có thể được kiểm soát bởi ứng dụng. Ví dụ, bạn có thể muốn mô hình tự động tìm kiếm và tìm ra các tài nguyên có liên quan và đưa chúng vào ngữ cảnh; bạn cũng có thể muốn thiết lập chức năng giao diện người dùng rõ ràng trong ứng dụng để cho phép người dùng biến nó thành một phần thông tin được gửi đến LLM thông qua menu thả xuống, menu kẹp giấy, v.v. Đây đều là các tình huống ứng dụng cho tài nguyên.
Lời nhắc : Văn bản hoặc tin nhắn được người dùng cố ý khởi tạo hoặc thay thế. Ví dụ, nếu bạn đang ở trong hoàn cảnh biên tập, nó giống như lệnh gạch chéo hoặc chức năng tự động hoàn thành tương tự, chẳng hạn như macro mà bạn muốn chèn trực tiếp.
Thông qua MCP, chúng tôi có nhận xét riêng về những cách khác nhau để trình bày nội dung này, nhưng quyết định cuối cùng vẫn phụ thuộc vào các nhà phát triển ứng dụng. Là một nhà phát triển ứng dụng, việc diễn đạt những khái niệm này theo nhiều cách khác nhau sẽ rất hữu ích để bạn có thể xác định trải nghiệm phù hợp và tạo ra sự khác biệt dựa trên chúng. Theo quan điểm của các nhà phát triển ứng dụng, họ không muốn các ứng dụng của mình giống nhau và họ cần những phương pháp riêng để tạo ra trải nghiệm tốt nhất khi kết nối với hệ sinh thái mở và tích hợp .
Tôi nghĩ có hai khía cạnh: Khía cạnh đầu tiên là các lệnh gọi công cụ hiện chiếm tỷ lệ hơn 95% tích hợp . Tôi hy vọng rằng nhiều máy trạm sẽ sử dụng dịch vụ gọi điện thoại và gọi điện thoại nhanh hơn. Tính năng đầu tiên được triển khai là chức năng nhắc nhở, rất thiết thực và có thể xây dựng một máy chủ MCP có thể theo dõi được. Đây là tương tác do người dùng điều khiển và người dùng quyết định thời điểm nhập thông tin, điều này tốt hơn là chờ mô hình xử lý. Chúng tôi cũng hy vọng rằng nhiều máy chủ MCP sẽ sử dụng lời nhắc để hiển thị cách sử dụng công cụ.
Mặt khác, nguồn tài nguyên cũng có tiềm năng lớn. Hãy tưởng tượng một máy chủ MCP cung cấp tài liệu, cơ sở dữ liệu và các tài nguyên khác, còn máy trạm xây dựng một chỉ mục hoàn chỉnh xung quanh những tài nguyên này. Vì nội dung tài nguyên phong phú nên nó không được hiển thị theo mô hình điều khiển, vì bạn có thể có nhiều nội dung tài nguyên hơn so với nội dung thực sự có sẵn trong cửa sổ ngữ cảnh. Mong đợi các ứng dụng sẽ tận dụng tốt hơn những khái niệm cơ bản này và tạo ra trải nghiệm phong phú hơn trong những tháng tới.
Alessio (người dẫn chương trình): Khi cầm búa, bạn muốn coi mọi thứ như đinh và sử dụng công cụ để giải quyết mọi vấn đề. Ví dụ, nhiều người sử dụng nó cho các truy vấn cơ sở dữ liệu thay vì các cuộc gọi tài nguyên. Tôi tò mò về những ưu và nhược điểm của việc sử dụng các công cụ và tài nguyên khi có giao diện API (như cơ sở dữ liệu)? Khi nào bạn nên sử dụng công cụ để thực hiện truy vấn SQL? Khi nào nên sử dụng tài nguyên để xử lý dữ liệu?
Justin: Cách chúng tôi phân biệt giữa công cụ và tài nguyên là các công cụ được mô hình gọi ra và mô hình tự xác định xem có nên tìm công cụ thích hợp và áp dụng hay không. Nếu bạn muốn LLM có thể chạy các truy vấn SQL, thì việc thiết lập nó như một công cụ là hợp lý.
Việc sử dụng tài nguyên linh hoạt hơn, nhưng tình hình hiện tại khá phức tạp vì nhiều máy trạm không hỗ trợ. Trong điều kiện lý tưởng, cấu trúc bảng cơ sở dữ liệu và nội dung khác có thể được gọi thông qua tài nguyên. Người dùng có thể sử dụng điều này để cung cấp cho ứng dụng thông tin có liên quan để bắt đầu cuộc trò chuyện hoặc để ứng dụng AI tự động tìm tài nguyên. Miễn là có yêu cầu liệt kê một thực thể và đọc nó thì việc mô hình hóa nó như một tài nguyên là hợp lý. Tài nguyên được xác định duy nhất bằng URI, có thể được coi là bộ chuyển đổi chung, chẳng hạn như sử dụng máy chủ MCP để diễn giải URI do người dùng nhập. Lấy trình soạn thảo Zed làm ví dụ. Nó có một thư viện gợi ý tương tác với máy chủ MCP để đưa ra các gợi ý. Cả hai bên cần phải thống nhất về URI và định dạng dữ liệu. Đây là một ví dụ thú vị về ứng dụng tài nguyên.
Hãy quay lại góc nhìn của các nhà phát triển ứng dụng, suy nghĩ về nhu cầu và áp dụng ý tưởng này vào thực tế. Ví dụ, hãy xem các chức năng ứng dụng hiện có và xem chức năng nào có thể được tách biệt và triển khai bởi máy chủ MCP nếu áp dụng phương pháp này. Về cơ bản, bất kỳ IDE nào có menu bổ sung đều có thể được mô hình hóa như một tài nguyên. Chỉ là những triển khai này đã tồn tại rồi.
swyx (người điều hành): Vâng, khi tôi nhìn thấy biểu tượng @ trong Claude Desktop, tôi ngay lập tức nghĩ rằng đây là chức năng tương tự như Cursor và bây giờ những người dùng khác cũng có thể tận dụng chức năng này. Mục tiêu thiết kế này rất tuyệt vời vì bản thân chức năng đã có sẵn và mọi người có thể dễ dàng hiểu và sử dụng nó. Tôi đã cho các bạn xem biểu đồ đó và tôi chắc rằng các bạn đều đồng ý rằng nó rất có giá trị và tôi cho rằng nó rất hữu ích và nên được đưa lên trang đầu của tài liệu, đây là một gợi ý tuyệt vời.
Justin : Bạn có sẵn lòng gửi Yêu cầu kéo (PR) cho việc này không? Chúng tôi thực sự thích gợi ý này.
swyx (chủ nhà): Được, tôi sẽ nộp.
Là người phụ trách quan hệ nhà phát triển, tôi luôn cố gắng đưa ra chỉ dẫn rõ ràng cho mọi người, chẳng hạn như nêu ra những điểm chính trước rồi dành hai giờ để giải thích chi tiết. Vì vậy, việc có một hình ảnh thể hiện nội dung cốt lõi sẽ rất hữu ích. Tôi đánh giá cao sự nhấn mạnh của bạn vào lời nhắc. Vào những ngày đầu của ChatGPT và Claude, nhiều người đã thử tạo ra các thư viện nhắc nhở và thư viện quản lý nhắc nhở tương tự như trên GitHub, nhưng không có thư viện nào thực sự phổ biến.
Thực tế, cần có nhiều cải tiến hơn nữa trong lĩnh vực này. Mọi người mong đợi lời nhắc phải năng động và bạn cung cấp khả năng đó. Tôi hoàn toàn đồng ý với khái niệm về lời nhắc nhiều bước mà bạn đã đề cập, điều này cho thấy rằng đôi khi để mô hình chạy đúng cách, cần phải áp dụng lời nhắc nhiều bước hoặc phá vỡ một số hạn chế. Lời nhắc không chỉ là một đoạn hội thoại lần, đôi khi nó là một loạt các quy trình hội thoại.
swyx (người điều phối): Tôi nghĩ đây là nơi có sự hội tụ nhất định giữa các khái niệm về tài nguyên và công cụ, bởi vì lúc này bạn đang đề cập rằng đôi khi bạn muốn có một mức độ kiểm soát nhất định của người dùng hoặc kiểm soát ứng dụng, và những lúc khác bạn muốn mô hình kiểm soát nó. Vậy, bây giờ chúng ta chỉ đang chọn một tập hợp con các công cụ thôi phải không?
David: Vâng, tôi cho rằng đó là mối lo ngại chính đáng. Cuối cùng, đây là nguyên tắc thiết kế cốt lõi của MCP, rằng khái niệm về một công cụ thực sự không chỉ là bản thân công cụ đó, mà còn gắn chặt với ứng dụng máy trạm và người dùng. Người dùng phải có toàn quyền kiểm soát hoạt động của MCP. Khi chúng tôi nói rằng một công cụ được kiểm soát bởi mô hình, ý chúng tôi là công cụ đó chỉ được gọi bởi mô hình, thay vì người dùng chủ động chỉ định cách sử dụng công cụ (tất nhiên, ngoại trừ mục đích nhắc nhở, nhưng đây không phải là chức năng giao diện người dùng thông thường).
Nhưng tôi cho rằng việc ứng dụng máy trạm 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 máy trạm có thể lấy mô tả công cụ từ máy chủ MCP và tối ưu hóa màn hình hiển thị. Theo mô hình MCP, ứng dụng máy trạm phải có toàn quyền kiểm soát. Ngoài ra, chúng tôi có ý tưởng ban đầu là bổ sung chức năng vào giao thức để cho phép các nhà phát triển máy chủ nhóm các thành phần cơ bản như mẹo, tài nguyên và công cụ một cách hợp lý. Các nhóm này có thể được coi là các máy chủ MCP khác nhau và người dùng có thể kết hợp chúng tùy theo nhu cầu của mình.
03 MCP và OpenAPI: Cạnh tranh hay bổ sung cho nhau?
swyx (chủ nhà): Tôi muốn nói về sự so sánh giữa MCP và Open API . Xét cho cùng, đây rõ ràng là một trong những vấn đề mà mọi người đều rất quan tâm.
Justin /David: Về cơ bản, Đặc tả API mở là một công cụ rất mạnh mẽ mà tôi thường xuyên sử dụng khi phát triển API và máy trạm. Tuy nhiên, đối với kịch bản ứng dụng của các mô hình ngôn ngữ lớn (LLM), đặc tả API mở quá chi tiết và không phản ánh đầy đủ các khái niệm cụ thể về AI cấp cao hơn, chẳng hạn như khái niệm cơ bản về MCP mà chúng tôi vừa đề cập và chế độ tư duy của các nhà phát triển ứng dụng. Các mô hình sẽ được hưởng lợi nhiều hơn từ các công cụ, tài nguyên, mẹo và các khái niệm cơ bản khác được thiết kế riêng cho chúng thay vì chỉ cung cấp REST API và để chúng chạy tự do.
Mặt khác, khi thiết kế giao thức MCP, chúng tôi cố tình làm cho nó có trạng thái. Điều này là do các ứng dụng và tương tác AI vốn có trạng thái cao hơn. Mặc dù tính không trạng thái luôn có chỗ đứng ở một mức độ nào đó, nhưng khi các chế độ tương tác (như video, âm thanh, v.v.) tiếp tục tăng lên, tính trạng thái sẽ ngày càng trở nên phổ biến hơn, do đó các giao thức trạng thái sẽ trở nên đặc biệt hữu ích.
Trên thực tế, API mở và MCP không hề mâu thuẫn nhau mà còn bổ sung cho nhau. Mỗi loại đều có thế mạnh riêng và bổ sung cho nhau rất tốt. Tôi cho rằng điều quan trọng là chọn công cụ tốt nhất cho nhiệm vụ cụ thể. Nếu mục tiêu là đạt được sự tương tác phong phú giữa các ứng dụng AI thì MCP phù hợp hơn; nếu bạn muốn mô hình có thể dễ dàng đọc và diễn giải các thông số kỹ thuật API, thì API mở sẽ là lựa chọn tốt hơn. Đã có những nỗ lực ban đầu nhằm xây dựng cầu nối giữa hai bên, với các công cụ có thể chuyển đổi thông số kỹ thuật API mở sang MCP để xuất bản và ngược lại, điều này thật tuyệt vời.
Alessio (Người dẫn chương trình): Tôi đã đồng tổ chức một hacker tại AGI Studios. Là một nhà phát triển đại lý cá nhân, tôi đã thấy ai đó xây dựng một đại lý cá nhân có thể tạo máy chủ MCP: chỉ cần nhập URL của thông số kỹ thuật API và nó có thể tạo máy chủ MCP tương ứng. Bạn ứng xử hiện tượng này? Điều này có nghĩa là hầu hết các máy chủ MCP chỉ thêm một lớp vào API hiện có mà không có nhiều thiết kế độc đáo không? Liệu tương lai sẽ luôn như thế này, chủ yếu dựa vào AI để kết nối với các API hiện có hay một trải nghiệm MCP hoàn toàn mới, chưa từng có sẽ xuất hiện?
Justin /David: Tôi cho rằng là cả hai. Một mặt, các yêu cầu như "đưa dữ liệu vào ứng dụng thông qua trình kết nối" luôn có giá trị. Mặc dù các lệnh gọi công cụ hiện nay mang tính mặc định hơn, nhưng các khái niệm cơ bản khác có thể phù hợp hơn để giải quyết loại vấn đề này trong tương lai. Ngay cả khi vẫn là lớp kết nối hoặc bộ điều hợp, nó vẫn có thể tăng giá trị bằng cách áp dụng các khái niệm khác nhau.
Mặt khác, có một cơ hội thực sự cho một số trường hợp sử dụng thú vị, đó là xây dựng các máy chủ MCP hoạt động nhiều chức năng hơn là chỉ là bộ điều hợp. Ví dụ, máy chủ MCP bộ nhớ có thể cho phép LLM ghi nhớ thông tin trong nhiều cuộc hội thoại khác nhau; Máy chủ MCP tư duy tuần tự có thể cải thiện khả năng suy luận của mô hình. Thay vì tích hợp với các hệ thống bên ngoài, các máy chủ này cung cấp những cách hoàn toàn mới để suy nghĩ về các mô hình.
Dù sao đi nữa, 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à bản cải tiến của API khác mà là bản gốc, thì mô hình thường có thể tìm ra cách để triển khai chức năng đó. Trên thực tế, nhiều máy chủ MCP sẽ là trình bao bọc API, điều này vừa hợp lý vừa hiệu quả và có thể giúp bạn đạt được nhiều tiến bộ. Nhưng chúng tôi vẫn đang trong giai đoạn thăm dò và liên tục tìm hiểu những điều có thể.
Khi sự hỗ trợ máy trạm đối với những khái niệm cơ bản này hoàn thiện, trải nghiệm phong phú hơn sẽ xuất hiện. Ví dụ, máy chủ MCP có thể "tóm tắt nội dung của một mục trên Reddit" vẫn chưa được xây dựng, nhưng bản thân giao thức thì hoàn toàn khả thi. Tôi cho rằng khi nhu cầu của mọi người thay đổi từ "Tôi chỉ muốn kết nối những thứ tôi quan tâm với LLM" thành "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 có thể tương tác sâu sắc với mô hình", bạn sẽ thấy những ứng dụng sáng tạo này xuất hiện. Tuy nhiên, hiện tại có một vấn đề "con gà và quả trứng" giữa các khả năng được hỗ trợ bởi máy trạm và các chức năng mà nhà phát triển máy chủ muốn triển khai.
04 Cách xây dựng máy chủ MCP nhanh chóng: sử dụng lập trình AI
Alessio (người điều hành): Tôi nghĩ rằng có một khía cạnh khác của MCP mà mọi người ít thảo luận, đó là việc xây dựng máy chủ. Bạn có lời khuyên nào cho các nhà phát triển muốn bắt đầu xây dựng máy chủ MCP không? Là một nhà phát triển máy chủ, làm thế nào để bạn tìm được sự cân bằng tốt nhất giữa việc cung cấp các mô tả chi tiết (để mô hình hiểu) và trực tiếp thu thập dữ liệu thô (để mô hình tự động xử lý sau đó)?
Justin /David: Tôi có một số gợi ý. Một trong những điều tuyệt vời về MCP là rất dễ để xây dựng một số chức năng đơn giản có thể được thực hiện trong khoảng nửa giờ và mặc dù có thể không hoàn hảo nhưng vẫn đủ tốt để đáp ứng các nhu cầu cơ bản. Phương pháp tốt nhất để bắt đầu là chọn ngôn ngữ lập trình yêu thích của bạn và sử dụng SDK nếu có; xây dựng một công cụ mà bạn muốn mô hình của mình tương tác; thiết lập máy chủ MCP; thêm công cụ vào máy chủ; viết một mô tả ngắn gọn về công cụ; kết nối nó với ứng dụng yêu thích của bạn thông qua các giao thức đầu vào và đầu ra chuẩn; và sau đó xem mô hình có thể sử dụng nó như thế nào.
Đối với các nhà phát triển, việc có thể nhanh chóng xem mô hình hoạt động trên thứ mà họ quan tâm là rất hấp dẫn và có thể truyền cảm hứng nhiệt tình, thúc đẩy họ suy nghĩ sâu sắc về các công cụ, tài nguyên và mẹo khác cần thiết, cũng như cách đánh giá hiệu suất và tối ưu hóa các mẹo. Đây là một quá trình có thể được khám phá theo thời gian, nhưng sẽ thú vị hơn nếu bắt đầu với điều gì đó đơn giản và xem mô hình tương tác như thế nào với những thứ bạn quan tâm. MCP giúp việc phát triển trở nên thú vị và giúp các mô hình trở nên hữu ích nhanh chóng.
Tôi cũng có xu hướng tận dụng lợi thế của mã hóa hỗ trợ AI . Trong giai đoạn đầu phát triển, chúng tôi phát hiện ra rằng chúng tôi có thể đưa các đoạn mã từ MCP SDK vào cửa sổ ngữ cảnh của LLM và để LLM giúp xây dựng máy chủ. Kết quả thường rất tốt và các chi tiết có thể được tối ưu hóa thêm sau này. Đây là phương pháp tuyệt vời để nhanh chóng triển khai chức năng cơ bản và lặp lại chức năng đó. Ngay từ đầu, chúng tôi tập trung vào việc đơn giản hóa quy trình xây dựng máy chủ để các LLM có thể tham gia. Trong những năm trước, việc khởi chạy một máy chủ MCP có thể chỉ cần 100 đến 200 dòng mã, thực sự rất dễ dàng. Nếu không có SDK có sẵn, bạn cũng có thể cung cấp các thông số kỹ thuật có liên quan hoặc các SDK khác cho mô hình để giúp bạn xây dựng một số chức năng. Việc gọi công cụ bằng ngôn ngữ bạn yêu thích cũng khá đơn giản.
Alessio (người điều phối): Tôi thấy rằng trình xây dựng máy chủ quyết định phần lớn đến định dạng và nội dung dữ liệu cuối cùng được trả về. Ví dụ, trong trường hợp gọi công cụ, như Google Maps, thuộc tính nào được trả về sẽ do trình xây dựng xác định. Nếu thiếu một thuộc tính, người dùng không thể ghi đè hoặc sửa đổi thuộc tính đó. Điều này tương tự như một trong những phàn nàn của tôi về một số SDK: khi mọi người xây dựng SDK bao bọc một API , nếu họ bỏ qua các tham số mà API thêm vào, tôi không thể sử dụng những tính năng mới đó. Bạn ứng xử vấn đề này? Người dùng nên can thiệp ở mức độ nào hay điều này hoàn toàn phụ thuộc vào nhà thiết kế máy chủ?
Justin /David: Liên quan đến ví dụ về Google Maps, có lẽ chúng tôi phải chịu một phần trách nhiệm vì đây là máy chủ tham khảo mà chúng tôi đã phát hành. Nói chung, ít nhất là hiện tại, chúng tôi cố tình thiết kế kết quả của các lệnh gọi công cụ không phải là dữ liệu JSON có cấu trúc, cũng không khớp với các mẫu cụ thể. Thay vào đó, chúng được trình bày dưới dạng tin nhắn như văn bản và hình ảnh có thể nhập trực tiếp vào LLM. Nghĩa là, chúng ta có xu hướng trả về lượng lớn dữ liệu và tin tưởng LLM sẽ sàng lọc dữ liệu đó và rút thông tin mà nó quan tâm. Chúng tôi đã nỗ lực rất nhiều vào việc này để cung cấp cho mô hình sự linh hoạt để có được thông tin cần thiết, vì đó là thế mạnh của mô hình. Chúng tôi suy nghĩ về cách khai thác tối đa tiềm năng của LLM mà không quá hạn chế hoặc áp đặt, do đó tránh tình trạng khó mở rộng khi mô hình được cải thiệ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ả có thể được truyền trực tiếp từ API được gọi một cách nguyên vẹn và API sẽ tự động truyền dữ liệu.
Alessio (người dẫn chương trình): Thật sự rất khó khăn để đưa ra quyết định nên đặt ra ranh giới ở đâu.
David: Có lẽ tôi cần phải nhấn mạnh vai trò trong đó AI ở đây. Không có gì ngạc nhiên khi nhiều máy chủ mẫu được viết bởi Claude. Hiện nay, mọi người có xu hướng quen sử dụng phương pháp kỹ thuật phần mềm truyền thống để giải quyết vấn đề, nhưng thực tế là 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. Với việc LLM đạt được những tiến bộ đáng kể mỗi năm, giờ đây việc giao nhiệm vụ xử lý dữ liệu cho các mô hình giỏi thực hiện việc này là một lựa chọn sáng suốt. Điều này có nghĩa là chúng ta có thể cần phải từ bỏ các phương pháp kỹ thuật phần mềm truyền thống của hai mươi, ba mươi hoặc thậm chí bốn mươi năm qua.
Nhìn vào MCP từ một góc độ khác, tốc độ phát triển của AI thật đáng kinh ngạc, điều này vừa thú vị vừa có chút đáng lo ngại. Đối với làn sóng cải tiến khả năng mô hình tiếp theo, nút thắt lớn nhất có thể là khả năng tương tác với thế giới bên ngoài , chẳng hạn như đọc các nguồn dữ liệu bên ngoài và thực hiện các hành động trạng thái. Khi làm việc tại Anthropic, chúng tôi rất coi trọng các tương tác an toàn và có các biện pháp kiểm soát và hiệu chuẩn phù hợp. Khi AI phát triển, mọi người sẽ mong đợi các mô hình có những khả năng này và việc kết nối các mô hình với thế giới bên ngoài là chìa khóa để cải thiện năng suất AI. MCP cũng là sự đặt cược của chúng tôi vào hướng đi tương lai và tầm quan trọng của nó.
Alessio (người điều hành): Đúng vậy, tôi nghĩ bất kỳ thuộc tính API nào có chữ "đã định dạng" đều nên bị xóa. Chúng ta nên lấy dữ liệu thô từ tất cả các giao diện. Tại sao bạn cần phải định dạng trước? Mô hình này 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 sao để MCP gọi được nhiều công cụ hơn?
swyx (chủ nhà): Tôi muốn hỏi một câu hỏi khác. 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 đề về chiều rộng và độ sâu, và liên quan trực tiếp đến việc lồng MCP mà chúng ta vừa thảo luận.
Khi Claude ra mắt ví dụ ngữ cảnh triệu token đầu tiên vào tháng 4 năm 2024, công ty tuyên bố rằng nó có thể hỗ trợ 250 công cụ, nhưng trong nhiều tình huống thực tế, mô hình không thể thực sự sử dụng hiệu quả nhiều công cụ như vậy. Theo một nghĩa nào đó, đây là một vấn đề về chiều rộng vì không có công cụ nào gọi công cụ, chỉ có các mô hình và hệ thống phân cấp công cụ phẳng, khiến cho việc nhầm lẫn giữa các công cụ trở nên dễ dàng. Khi các công cụ có chức năng tương tự nhau, mô hình có thể gọi sai công cụ, dẫn đến kết quả không như mong muốn. Bạn có khuyến nghị nào về số lượng máy chủ MCP tối đa có thể được bật tại bất kỳ thời điểm nào không?
Justin: Nói thật thì không có câu trả lời tuyệt đối nào cho câu hỏi này. Một mặt, nó phụ thuộc vào mô hình bạn sử dụng và mặt khác, nó phụ thuộc vào việc tên gọi và mô tả của công cụ có đủ rõ ràng để hiểu chính xác mô hình và tránh nhầm lẫn hay không. Tình huống lý tưởng nhất là cung cấp mọi thông tin cho LLM, nơi sẽ xử lý mọi việc một cách trọn vẹn. Đây cũng chính là bản thiết kế tương lai mà MCP hình dung. Nhưng trong các ứng dụng thực tế, ứng dụng máy trạm(tức là ứng dụng AI) có thể cần thực hiện một số công việc bổ sung, chẳng hạn như lọc bộ công cụ hoặc sử dụng LLM nhỏ và nhanh để lọc ra các công cụ phù hợp nhất trước khi chuyển chúng cho mô hình lớn. Ngoài ra, bạn có thể lọc bằng cách thiết lập một số máy chủ MCP làm proxy cho các máy chủ MCP khác.
Ít nhất đối với Claude, việc hỗ trợ hàng trăm công cụ là một lựa chọn an toàn. Tuy nhiên, tình hình của các mẫu xe khác vẫn chưa rõ ràng. Mọi thứ sẽ tốt hơn theo thời gian, vì vậy cần thận trọng khi áp dụng các hạn chế để không cản trở sự tiến triển này. Số lượng công cụ có thể được hỗ trợ phụ thuộc phần lớn vào mức độ chồng chéo trong các mô tả. Nếu chức năng của các máy chủ khác biệt và tên cũng như mô tả công cụ rõ ràng và duy nhất, thì số lượng công cụ được hỗ trợ có thể nhiều hơn so với khi có các máy chủ có chức năng tương tự (chẳng hạn như kết nối với cả máy chủ GitLab và GitHub).
Ngoài ra, điều này còn phụ thuộc vào loại ứng dụng AI. Khi xây dựng các ứng dụng có tính thông minh cao, bạn có thể muốn giảm số lượng câu hỏi mà bạn hỏi người dùng và khả năng cấu hình giao diện của mình; nhưng khi xây dựng thứ gì đó như IDE hoặc ứng dụng trò chuyện, sẽ hợp lý hơn nếu cho phép người dùng chọn bộ tính năng họ muốn vào những thời điểm khác nhau, thay vì bật tất cả các tính năng mọi lúc.
swyx (máy chủ): Cuối cùng, chúng ta hãy tập trung vào Sequential Thinking MCP Server . Nó có khả năng phân nhánh và khả năng cung cấp "nhiều không gian viết hơn", điều này rất thú vị. Ngoài ra, Anthropic đã xuất bản một blog kỹ thuật mới vào tuần trước giới thiệu Công cụ tư duy của họ và có một số nhầm lẫn trong cộng đồng về việc liệu có sự chồng chéo giữa Máy chủ tư duy tuần tự và Công cụ tư duy này hay không. Trên thực tế, đây chỉ là đội ngũ khác nhau thực hiện những việc tương tự theo những cách khác nhau, xét cho cùng, có nhiều phương pháp khác nhau để thực hiện chúng.
Justin/David: Theo như tôi biết, Sequential Thought Server không có nguồn gốc chung trực tiếp với Thinking Tools của Anthropic. Nhưng nó phản ánh một hiện tượng chung: để giúp LLM suy nghĩ sâu sắc hơn, giảm ảo tưởng hoặc đạt được các mục tiêu khác, có nhiều chiến lược khác nhau có thể chứng minh đầy đủ và đáng tin cậy hơn các hiệu ứng trên nhiều chiều. Đây chính là sức mạnh của MCP - bạn có thể xây dựng nhiều máy chủ khác nhau hoặc thiết lập nhiều sản phẩm hoặc công cụ khác nhau trên cùng một máy chủ để đạt được nhiều chức năng khác nhau và để LLM áp dụng các mô hình tư duy cụ thể để đạt được những kết quả khác nhau.
Do đó, không có cách suy nghĩ lý tưởng và chuẩn mực nào về LLM.
swyx (chủ nhà): 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 cho phép bạn đạt được sự đa dạng này, đúng không?
Justin/David: Chính xác. Tôi nghĩ phương pháp tiếp cận của một số máy chủ MCP chỉ lấp đầy khoảng trống trong khả năng của mô hình tại thời điểm đó. Việc đào tạo, chuẩn bị và nghiên cứu mô hình cần lượng lớn thời gian để cải thiện dần khả năng của nó. Hãy lấy Máy chủ tư duy tuần tự làm ví dụ; trông có vẻ đơn giản nhưng thực tế không phải vậy và nó có thể được xây dựng chỉ trong vài ngày. Tuy nhiên, nếu bạn muốn triển khai trực tiếp chức năng tư duy phức tạp này vào mô hình, thì chắc chắn đây không phải là việc có thể hoàn thành trong vài ngày.
Ví dụ, nếu mô hình tôi đang sử dụng không đáng tin cậy lắm, hoặc ai đó cảm thấy rằng kết quả do mô hình hiện tại tạo ra nhìn chung không đáng tin cậy, tôi có thể tưởng tượng việc xây dựng một máy chủ MCP có mô hình thử tạo ra ba kết quả cho một truy vấn và sau đó chọn kết quả tốt nhất. Với MCP, tương tác LLM đệ quy và có thể cấu thành này có thể đạt được.
06 Sự khác biệt giữa MCP phức tạp và Agent là gì?
Alessio (người dẫn chương trình): Tiếp theo tôi muốn hỏi một câu hỏi về khả năng kết hợp. Bạn ứng xử khái niệm giới thiệu một MCP này vào một MCP khác? Có kế hoạch nào cho việc này không? Ví dụ, nếu tôi muốn xây dựng một MCP tóm tắt nội dung của một chủ đề Reddit, điều này có thể yêu cầu gọi một MCP phản hồi với Reddit API và một MCP cung cấp chức năng tóm tắt. Vậy, làm sao tôi có thể xây dựng được một "siêu MCP" như vậy?
Justin /David: Đây là một chủ đề rất thú vị và có thể được xem xét từ hai khía cạnh.
Một mặt, hãy xem xét việc xây dựng một thành phần như hàm tóm tắt . Mặc dù nó có thể viện dẫn LLM, chúng tôi muốn nó không phụ thuộc vào mô hình cụ thể. Điều này liên quan đến chức năng giao tiếp 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. Các nhà phát triển máy chủ có thể sử dụng Cursor để yêu cầu máy trạm(ứng dụng có người dùng) thực hiện một số nhiệm vụ nhất định, chẳng hạn như yêu cầu máy trạm tóm tắt bằng mô hình hiện do người dùng chọn và trả về kết quả. Theo cách này, việc lựa chọn mô hình tóm tắt phụ thuộc vào Cursor và các nhà phát triển không cần phải giới thiệu thêm SDK hoặc khóa API ở phía máy chủ, do đó đạt được cấu trúc độc lập với mô hình cụ thể.
Mặt khác, hoàn toàn có thể xây dựng các hệ thống phức tạp hơn bằng cách sử dụng MCP . Bạn có thể tưởng tượng 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 hoạt động như một máy trạm MCP, gọi các máy chủ MCP khác để tạo ra trải nghiệm phong phú hơn. Điều này phản ánh bản chất đệ quy và mô hình này cũng được phản ánh trong các khía cạnh như việc ủy quyền các thông số kỹ thuật. Bạn có thể kết nối các ứng dụng này, vừa là máy chủ vừa là máy khách, và thậm chí sử dụng máy chủ MCP để xây dựng DAG (Đồ thị không có chu trình có hướng) nhằm triển khai các quy trình tương tác phức tạp. Một máy chủ MCP thông minh thậm chí có thể tận dụng khả năng của toàn bộ hệ sinh thái máy chủ MCP. Người ta đã thực hiện những thí nghiệm có liên quan về vấn đề này. Nếu chúng ta xem xét các chức năng như lựa chọn và cài đặt tự động, có rất nhiều khả năng có thể thực hiện được.
Hiện tại, SDK của chúng tôi vẫn cần thêm nhiều chi tiết hơn để giúp các nhà phát triển dễ dàng xây dựng các ứng dụng vừa là máy trạm vừa là máy chủ MCP đệ quy hoặc thuận tiện hơn khi sử dụng lại hành vi của nhiều máy chủ MCP. Đây là những điều cần được hoàn thiện trong tương lai, nhưng chúng có thể chứng minh một số tình huống ứng dụng hiện khả thi nhưng chưa được áp dụng rộng rãi.
swyx (người dẫn chương trình): Nghe có vẻ rất thú vị và tôi tin rằng nhiều người sẽ nhận được rất nhiều ý tưởng và cảm hứng từ nó. Vậy, MCP này, vừa là máy chủ vừa là máy khách, có thể được coi là một tác nhân không? Theo một nghĩa nào đó, một tác nhân là khi bạn gửi một yêu cầu và nó thực hiện một số hoạt động cấp thấp mà bạn có thể không nhận thức đầy đủ. Có một lớp trừu tượng giữa bạn và nguồn dữ liệu thô cuối cùng. Bạn có nhận xé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 thông qua phương pháp MCP. Điều cần phân biệt ở đây là sự khác biệt giữa máy chủ MCP cộng với máy trạm chỉ là Đại lý và một Đại lý thực sự. Ví dụ, trong máy chủ MCP, bạn có thể sử dụng vòng lặp mẫu do máy trạm cung cấp để làm phong phú thêm trải nghiệm và để mô hình gọi công cụ để xây dựng một Đại lý thực sự. Phương pháp xây dựng này tương đối đơn giản.
Về mối quan hệ giữa MCP và Agent, chúng ta có một số cách suy nghĩ khác nhau:
Đầu tiên, MCP có thể là một cách tốt để thể hiện khả năng của một tác nhân, nhưng có lẽ hiện tại nó còn thiếu một số tính năng hoặc chức năng có thể nâng cao trải nghiệm tương tác của người dùng, điều này cần được xem xét để đưa vào giao thức MCP.
Thứ hai, MCP có thể được sử dụng như một lớp giao tiếp cơ bản để xây dựng các tác nhân hoặc cho phép các tác nhân khác nhau kết hợp với nhau. Tất nhiên, vẫn còn những khả năng khác, chẳng hạn như cho rằng MCP nên tập trung nhiều hơn vào tích hợp các ứng dụng AI thay vì tập trung quá nhiều vào khái niệm về Agent. Đây vẫn là một cuộc thảo luận đang diễn ra và mỗi hướng đi đều có những đánh đổi riêng. Quay trở lại phép loại suy về “hộp chung”, khi thiết kế các giao thức và quản lý hệ sinh thái, chúng ta cần đặc biệt cẩn thận để tránh làm phức tạp quá mức và không để giao thức cố gắng bao gồm tất cả, điều này có thể khiến giao thức hoạt động kém ở mọi khía cạnh. Câu hỏi chính là ở mức độ nào tác nhân có thể được tích hợp tự nhiên vào mô hình và khuôn khổ mô hình hiện có, hoặc ở mức độ nào nó nên tồn tại như một thực thể độc lập, đây vẫn là một vấn đề chưa được giải quyết.
swyx (người điều hành): Tôi cho rằng rằng khi đạt được giao tiếp hai chiều, máy trạm và máy chủ có thể được kết hợp thành một và công việc có thể được chuyển giao cho các máy chủ MCP khác, nó trở nên giống một tác nhân hơn. Tôi đánh giá cao việc các bạn luôn nghĩ đơn giản và không cố gắng giải quyết mọi vấn đề.
07 Bước tiếp theo cho MCP : Làm thế nào để giao thức đáng tin cậy hơn?
swyx (máy chủ): Bản cập nhật gần đây từ máy chủ có trạng thái sang máy chủ không trạng thái đã thu hút sự quan tâm của mọi người. Lý do nào khiến bạn chọn Server-Sent Events (SSE) làm giao thức xuất bản và vận chuyển, cũng như hỗ trợ lớp vận chuyển có thể cắm thêm? Liệu nó có bị ảnh hưởng bởi dòng tweet của Jared Palmer hay nó đã được thực hiện rồi?
Justin /David: Không hẳn vậy. Chúng tôi đã thảo luận công khai về tình huống tiến thoái lưỡng nan giữa Statefulness và Stateless trên GitHub cách đây vài tháng và đã cân nhắc những ưu và nhược điểm. Chúng tôi cho rằng hướng phát triển trong tương lai của các ứng dụng, hệ sinh thái và tác nhân AI có xu hướng là Trạng thái . Đây là một trong những chủ đề gây tranh cãi nhất trong đội ngũ cốt cán MCP và đã trải qua lần cuộc thảo luận và lặp lại. Kết luận cuối cùng là mặc dù chúng ta lạc quan về tương lai của Statefulness, chúng ta không thể đi chệch khỏi mô hình hiện tại và phải tìm ra sự cân bằng giữa khái niệm Statefulness và tính phức tạp của các hoạt động thực tế. Bởi vì nếu máy chủ MCP được yêu cầu duy trì kết nối liên tục trong thời gian dài thì việc triển khai và vận hành sẽ rất khó khăn. Thiết kế vận chuyển SSE ban đầu dựa trên ý tưởng rằng bạn triển khai một máy chủ MCP và máy trạm có thể kết nối với máy chủ đó và duy trì kết nối gần như vô thời hạn, đây là yêu cầu cao đối với bất kỳ ai cần hoạt động ở quy mô lớn và không phải là mô hình triển khai hoặc vận hành lý tưởng.
Do đó, chúng tôi nghĩ về cách cân bằng tầm quan trọng của trạng thái với tính dễ vận hành và bảo trì. Việc giới thiệu phương thức truyền tải HTTP trực tuyến, bao gồm SSE, của chúng tôi được thiết kế theo hướng gia tăng. Máy chủ có thể là máy chủ HTTP thông thường và kết quả được lấy thông qua yêu cầu HTTP POST. Chức năng này sau đó có thể được nâng cao dần dần để hỗ trợ truyền phát kết quả hoặc thậm chí cho phép máy chủ chủ động đưa ra yêu cầu cho máy trạm. Miễn là máy chủ và máy trạm hỗ trợ Tiếp tục phiên (tức là kết nối lại và tiếp tục truyền sau khi ngắt kết nối), có thể đạt được mở rộng thuận tiện trong khi vẫn tính đến tương tác Trạng thái và xử lý tốt hơn tình trạng mất ổn định của mạng và các điều kiện khác.
Alessio (chủ nhà): Có, và cũng bao gồm ID phiên. Bạn có kế hoạch gì cho tương lai của việc xác minh danh tính? Hiện tại, đối với một số MCP, tôi chỉ cần dán khóa API vào dòng lệnh . Bạn cho rằng hướng phát triển trong tương lai là gì? Liệu có thứ gì đó giống như tệp cấu hình dành riêng cho MCP để quản lý thông tin xác thực không?
Justin /David: Chúng tôi đã đưa các thông số kỹ thuật xác thực vào bản dự thảo sửa đổi tiếp theo của giao thức. Hiện tại, trọng tâm chính là xác thực từ người dùng đến máy chủ, sử dụng OAuth 2.1 hoặc các phiên bản hiện đại của nó. Cách tiếp cận này có hiệu quả và mọi người đang phát triển theo hướng đó. Điều này có thể giải quyết được rất nhiều vấn đề, vì bạn chắc chắn không muốn người dùng dán khóa API tùy ý, đặc biệt khi hầu hết các máy chủ trong tương lai sẽ là máy chủ từ xa và cần có xác thực an toàn giữa chúng.
Trong hoàn cảnh cục bộ, vì thông tin ủy quyền được xác định ở lớp vận chuyển, điều này có nghĩa là cần phải đóng gói khung dữ liệu(thiết lập tiêu đề yêu cầu) và không thể triển khai trực tiếp đầu vào và đầu ra chuẩn (stdin/stdout). Tuy nhiên, khi chạy một chương trình cục bộ sử dụng đầu vào và đầu ra chuẩn, nó rất linh hoạt và thậm chí có thể mở trình duyệt để xử lý quy trình cấp phép. Chúng tôi vẫn chưa xác định rõ ràng liệu có nên sử dụng HTTP để xác thực cục bộ hay không. Justin có xu hướng ủng hộ điều này, nhưng cá nhân tôi không đồng ý và điều này gây ra một số tranh cãi.
Về thiết kế ủy quyền, tôi cho rằng rằng giống như các nội dung khác của thỏa thuận, chúng tôi cố gắng súc tích, giải quyết các điểm khó khăn thực tế, đơn giản hóa các chức năng càng nhiều càng tốt, sau đó mở rộng dần theo nhu cầu thực tế và các điểm khó khăn để tránh thiết kế quá mức. Việc thiết kế giao thức đòi hỏi sự cẩn thận cao vì một khi đã mắc lỗi, về cơ bản là không thể khắc phục được và sẽ phá vỡ khả năng tương thích ngược. Do đó, sẽ dễ dàng và chắc chắn hơn khi chỉ chấp nhận hoặc thêm những tính năng đã được cân nhắc và xác thực kỹ lưỡng, và để cộng đồng dùng thử tạm thời thông qua cơ chế mở rộng cho đến khi có sự đồng thuận rộng rãi hơn rằng một số tính năng nhất định thực sự cần được thêm vào giao thức cốt lõi và chúng tôi có thể cung cấp hỗ trợ liên tục trong tương lai.
Lấy quyền hạn và khóa API làm ví dụ, chúng tôi đã phải mất lượng lớn thời gian để đưa ra ý tưởng. Phương pháp ủy quyền hiện tại (tập hợp OAuth 2.1) có thể đáp ứng được các tình huống sử dụng khóa API. Máy chủ MCP có thể hoạt động như một máy chủ ủy quyền OAuth và thêm chức năng liên quan, nhưng nếu bạn truy cập trang "/authorize" của máy chủ này, máy chủ có thể chỉ cung cấp một hộp văn bản để bạn nhập khóa API. Mặc dù đây có thể không phải là cách tiếp cận lý tưởng nhất, nhưng nó phù hợp với mô hình hiện tại và khả thi ở thời điểm hiện tại. Chúng tôi lo ngại rằng nếu thêm quá nhiều tùy chọn bổ sung, cả máy trạm và máy chủ sẽ phải xem xét và triển khai nhiều trường hợp hơn, điều này sẽ làm tăng thêm tính phức tạp.
Alessio (người điều phối): Bạn đã bao giờ nghĩ đến khái niệm phạm vi chưa? Hôm qua chúng tôi đã thực hiện một tập với Dharmesh Shah, người sáng lập Agent.ai . Ông đưa ra một ví dụ về email: ông sở hữu tất cả email của mình và muốn kiểm soát phạm vi chi tiết hơn, chẳng hạn như "bạn chỉ có thể truy cập
