- MCP (Microservice Communication Protocol) là một giao thức độc đáo cho phép máy chủ tự vận chuyển giao diện và công cụ của ứng dụng, không cần plugin hay SDK, giúp cả con người và AI model dễ dàng tương tác trên nhiều nền tảng.
- Trong 18 tháng qua, MCP đã phát triển mạnh mẽ thành một tiêu chuẩn chung cho giao tiếp tác nhân, đạt 110 triệu lượt tải xuống hàng tháng và tích hợp sâu rộng vào các hệ thống doanh nghiệp và ứng dụng AI.
- Tầm nhìn đến năm 2026 tập trung vào các "tác nhân tổng quát" có khả năng thực hiện công việc tri thức phức tạp, đòi hỏi khả năng kết nối đa dạng, thiết kế API hướng tác nhân và các kỹ thuật tối ưu hóa như khám phá tiến bộ và gọi công cụ có lập trình.
The Future of MCP — David Soria Parra, Anthropic
- MCP là Giao thức Giao diện & Công cụ Tập trung vào Tác nhân: Nó cung cấp một cách để ứng dụng vận chuyển giao diện và công cụ của mình trực tiếp từ máy chủ, cho phép tương tác liền mạch bởi cả con người (qua UI) và AI model (qua công cụ) mà không phụ thuộc vào plugin hoặc SDK phía client.
- Ba Trụ cột Khả năng Kết nối cho Tác nhân: Xây dựng tác nhân hiệu quả vào năm 2026 sẽ dựa trên ba yếu tố: Kỹ năng (kiến thức chuyên môn), CLI (cho tác nhân cục bộ, môi trường cô lập, các công cụ đã được huấn luyện trước), và MCP (cho ngữ nghĩa phong phú, UI, tác vụ chạy dài, quản trị doanh nghiệp và tính độc lập nền tảng).
- Thực hiện Khám phá Tiến bộ: Phía client (agent harness) nên sử dụng mô hình "khám phá tiến bộ" để trì hoãn việc tải công cụ, chỉ tải chúng khi model cần, giảm đáng kể kích thước cửa sổ ngữ cảnh và cải thiện hiệu quả.
- Áp dụng Gọi Công cụ có Lập trình (Code Mode): Thay vì gọi công cụ tuần tự, cung cấp cho model một môi trường thực thi (ví dụ: REPL, V8, Lua interpreter) để model viết và thực thi mã nhằm điều phối các công cụ, giảm độ trễ, tiết kiệm mã thông báo và tăng tính linh hoạt.
- Thiết kế API hướng Tác nhân: Ngừng chuyển đổi 1:1 các REST API truyền thống sang máy chủ MCP. Thay vào đó, thiết kế API từ đầu với tư duy về cách cả con người và tác nhân sẽ tương tác và điều phối công việc, tận dụng các tính năng ngữ nghĩa phong phú của MCP.
- Khai thác Ngữ nghĩa Phong phú của MCP: Tận dụng các tính năng độc đáo của MCP như ứng dụng MCP, kỹ năng qua MCP, các nguyên thủy như tác vụ (tasks) và elicitations để xây dựng các tương tác tác nhân mạnh mẽ và phức tạp hơn.
- Cải tiến Lõi Giao thức: MCP đang được nâng cấp với giao thức vận chuyển không trạng thái (stateless transport) để mở rộng quy mô dễ dàng hơn cho các hyper-scaler, cải thiện giao tiếp tác nhân-tác nhân bất đồng bộ và SDK phiên bản 2 tốt hơn cho TypeScript và Python.
- Tích hợp và Khám phá Rộng rãi: Các tính năng mới như "truy cập đa ứng dụng" (cross-app access) thông qua IDP và "khám phá máy chủ" (server discovery) để tự động nhận diện máy chủ MCP trên URL sẽ giúp tăng cường tích hợp và đơn giản hóa việc triển khai.
- ứng dụng MCP — MCP application
- tác nhân — agent
- giao thức — protocol
- máy chủ — server
- công cụ — tool
- khả năng kết nối — connectivity
- khám phá tiến bộ — progressive discovery
- gọi công cụ có lập trình — programmatic tool calling
- API — API
- SDK — SDK
Giới thiệu về Ứng dụng MCP
Chào mừng quý vị. Hãy bắt đầu. Đây là một ứng dụng MCP. Nó là một tác nhân tự vận chuyển giao diện của mình, không thông qua một plugin, không qua một SDK, không được mô hình hiển thị động trên phía client, hay mã hóa cứng vào sản phẩm. Đây là một thứ được phục vụ qua máy chủ MCP, và bạn có thể lấy máy chủ, đặt nó vào đám mây, bạn có thể đặt nó vào ChatGPT, bạn có thể đặt nó vào VS Code, Cursor, và nó sẽ hoạt động.
Và điều đó, tôi nghĩ, khá hay, bởi vì để làm được điều đó, bạn cần một thứ mà nhiều điều chúng ta muốn trong hệ sinh thái không cung cấp. Bạn cần một số phân tích. Bạn cần cả hai phía — client và server — để hiểu những gì mỗi phía đang nói, để hiểu kết xuất của bạn như thế nào, để hiểu rằng có một UI sắp tới. Và vì điều đó, bạn cần một giao thức.
Và điều tuyệt vời nhất về điều này, một máy chủ MCP không chỉ vận chuyển một ứng dụng, hoặc có thể vận chuyển một ứng dụng, nó còn có thể vận chuyển các công cụ cùng với nó. Vì vậy, bạn có thể tương tác với ứng dụng đó như một con người, và bạn có thể để mô hình tương tác với nó thông qua các công cụ, điều mà tôi nghĩ là một điều rất độc đáo mà chúng ta chưa khám phá nhiều cho đến nay.
Hành trình phát triển MCP: Từ ý tưởng đến 110 triệu lượt tải
Được rồi, nhưng hãy cùng tua lại một chút từ đây — điều mà tôi nghĩ là một cái nhìn thoáng qua thực sự thú vị về tương lai của MCP. Hơn một năm trước, 18 tháng — một sự vĩnh cửu trong vòng đời AI — tất cả những điều này không hề tồn tại. Chỉ có một tài liệu đặc tả nhỏ, một vài SDK, chủ yếu do Klott viết, chỉ hoạt động cục bộ, với rất ít hơn là các công cụ.
Trong 18 hoặc 12 tháng qua, các bạn đã điên cuồng xây dựng mọi thứ, xây dựng các máy chủ, và một hệ sinh thái điên rồ xung quanh điều này. Và chúng tôi, về phía mình, đã bận rộn biến điều chỉ hoạt động cục bộ này, thêm khả năng từ xa, thêm ủy quyền tập trung, thêm các nguyên thủy mới như elicitation và tác vụ, và cuối cùng nhưng không kém phần quan trọng, thêm các tính năng thử nghiệm mới vào giao thức, giống như các ứng dụng MCP mà bạn vừa thấy.
Và trong thời gian đó, chúng ta đã đạt được, tôi nghĩ, một cột mốc thực sự thú vị, bởi vì, một lần nữa, tất cả các bạn đã điên cuồng xây dựng, và xây dựng, và xây dựng — tất nhiên, may mắn là với sự giúp đỡ của rất nhiều tác nhân. Chúng ta hiện có 110 triệu lượt tải xuống hàng tháng, và đó tất nhiên không phải chỉ là chúng tôi sử dụng nó trong các client và máy chủ của mình. Đó là tác nhân SDK của OpenAI, đó là ADC của Google, đó là Langshane, hàng nghìn khung làm việc và công cụ mà bạn có thể chưa bao giờ nghe nói đến, kéo nó như một phụ thuộc, điều đó có nghĩa là có một tiêu chuẩn chung mà tất cả chúng ta có thể sử dụng để giao tiếp với nhau.
Chỉ một chút ngữ cảnh, React, một trong những dự án mã nguồn mở thành công nhất có lẽ trong những thập kỷ qua, đã mất khoảng gấp đôi thời gian để đạt được khối lượng tải xuống đó. Và trong thời gian đó, tất nhiên, tất cả các bạn đã xây dựng những máy chủ thực sự, thực sự tuyệt vời — từ những dự án nhỏ như máy chủ WhatsApp và máy chủ Blender cho đến việc xây dựng các tích hợp SaaS như Linear, Slack và Notions, những thứ thực sự thúc đẩy những gì mọi người làm hàng ngày khi họ sử dụng MCPs. Nhưng quan trọng nhất, phần lớn các máy chủ MCP mà hầu hết chúng ta đã xây dựng đều ở "phía sau cánh cửa đóng kín", kết nối hệ thống công ty với các tác nhân trong ứng dụng AI.
Tầm nhìn 2026: Tác nhân tổng quát và Khả năng kết nối
Nhưng tôi vẫn nghĩ đây chỉ là sự khởi đầu tuyệt đối của chúng ta, bởi vì tôi nghĩ năm 2025 là tất cả về khám phá, và năm 2026 là tất cả về việc đưa các tác nhân này vào sản xuất. Bởi vì nếu bạn thực sự nghĩ về nó, trong tâm trí tôi, năm 2024, chúng ta chỉ xây dựng một loạt các bản demo và trình diễn những thứ thú vị cho mọi người, và có một chút sự chú ý ở đó. Năm 2025 thực sự là tất cả về coding tác nhân, nhưng coding tác nhân, nếu bạn thực sự nghĩ về nó, là kịch bản lý tưởng nhất cho một tác nhân. Nó cục bộ, nó rất khả thi, bạn có thể gọi một trình biên dịch. Giống như, bạn có một nhà phát triển có thể khắc phục mọi thứ nếu có lỗi xảy ra trước máy tính, và bạn có thể hiển thị một giao diện công cụ, và người dùng khá hài lòng.
Nhưng tôi nghĩ bây giờ với khả năng của mô hình ngày càng tăng, chúng ta đang bước vào một kỷ nguyên mới, mà tôi nghĩ năm nay sẽ bắt đầu. Chúng ta sẽ không chỉ thực hiện coding tác nhân nữa, mà sẽ có các tác nhân tổng quát sẽ thực hiện công việc tri thức thực sự, như những việc phân tích tài chính mà các nhà phân tích tài chính muốn làm, hoặc một người làm marketing muốn làm, và họ cần một điều đặc biệt. Họ không cần một tác nhân cục bộ gọi một trình biên dịch, mà thứ họ cần là một thứ có thể kết nối với khoảng năm ứng dụng SaaS và một ổ đĩa chia sẻ, bởi vì phần quan trọng nhất đối với họ cho một tác nhân là khả năng kết nối.
Và trong tâm trí tôi, khả năng kết nối không phải là một điều duy nhất. Nếu ai đó nói với bạn rằng có một giải pháp cho tất cả các vấn đề kết nối của bạn, cho dù đó là sử dụng máy tính, CLI, hay MCP, họ có lẽ đã sai. Bởi vì điều đúng đắn, tất nhiên, là nó luôn có nghĩa "còn tùy", và có một ngăn xếp khả năng kết nối rất lớn, và có một công cụ phù hợp cho công việc phù hợp.
Ba trụ cột cho Tác nhân năm 2026: Kỹ năng, MCP và CLI
Và trong tâm trí tôi, có ba điều chính bạn muốn xem xét khi xây dựng một tác nhân vào năm 2026: kỹ năng, MCP, và tất nhiên là CLI (hoặc sử dụng máy tính), tùy thuộc vào trường hợp sử dụng. Và chúng có ba điều rất khác biệt mà chúng có thể làm, và ba điều khác nhau bạn muốn xem xét khi bạn xây dựng tác nhân của mình.
Thứ nhất, kỹ năng, tất nhiên, giống như kiến thức chuyên môn. Nó giống như việc nắm bắt các khả năng cụ thể được đưa vào một tệp rất đơn giản, và nó hầu hết là không thể rút gọn. Có một số khác biệt nhỏ giữa các nền tảng khác nhau.
Tất nhiên, CLI rất phổ biến khi sử dụng coding tác nhân cục bộ. Nó là một công cụ tuyệt vời để bắt đầu một cách đơn giản, để có một thứ mà bạn có thể đóng trong một bash, mà mô hình có thể tự động khám phá những gì CLI có khả năng. Và quan trọng nhất, nếu bạn có những thứ giống như CLIs, như GitHub, Git, và những thứ khác đã có trong pre-training, CLI là một giải pháp tuyệt vời cho phần khả năng kết nối của bạn. Và chúng đặc biệt tốt khi bạn có một tác nhân cục bộ, nơi bạn có thể giả định một môi trường biệt lập, nơi bạn có thể giả định một môi trường thực thi mã.
Nhưng nếu bạn không có điều này, nếu bạn cần ngữ nghĩa phong phú, khi bạn cần một UI có thể hiển thị các tác vụ chạy dài, khi bạn cần những thứ như tài nguyên, khi bạn cần xây dựng một thứ gì đó hoàn toàn tách rời và cần độc lập nền tảng, hoặc bạn không có một môi trường biệt lập, khi bạn cần những thứ như ủy quyền, quản trị, chính sách — hoặc nói ngắn gọn là những thứ doanh nghiệp nhàm chán nhưng quan trọng — hoặc nếu bạn muốn có những thử nghiệm như ứng dụng MCP, hoặc điều gì sắp tới là kỹ năng qua MCP, thì tôi nghĩ MCP chỉ giống như một mô liên kết bổ sung, chỉ là một công cụ khác trong hộp công cụ của bạn để xây dựng một tác nhân tuyệt vời.
Và vì vậy, tất cả những điều này muốn nói rằng tôi nghĩ vào năm 2026, chúng ta sẽ bắt đầu xây dựng các tác nhân sử dụng tất cả những điều này. Chúng không chỉ sử dụng một thứ; chúng sử dụng tất cả, và chúng sử dụng chúng một cách khá liền mạch cùng nhau.
Cải thiện Tác nhân với Khám phá Tiến bộ và Gọi công cụ có lập trình
Nhưng tôi không nghĩ chúng ta đã hoàn toàn đạt được điều đó, bởi vì chúng ta cần xây dựng rất nhiều thứ — một phần vì các tác nhân của chúng ta vẫn còn "hơi tệ", và một phần vì tôi nghĩ chúng ta chưa nói đủ về một số kỹ thuật mà bạn có thể thực hiện để thực sự kết nối mô liên kết này lại với nhau.
Điều số một mà chúng ta cần thực hiện và bắt đầu xây dựng là ở phía client, ở phía agent harness — về những thứ cung cấp năng lượng cho các phần kết nối, dù đó là Claude Code, Py, hay bất kỳ ứng dụng nào bạn sắp xây dựng. Và điều số một chúng ta sẽ làm ở đó, và điều tất cả chúng ta phải làm, và điều tôi thực sự muốn truyền đạt hôm nay, là chúng ta cần bắt đầu xây dựng một thứ gọi là khám phá tiến bộ.
Hầu hết mọi người khi nghĩ về "Ồ, MCP," họ không thể nghĩ về phình to ngữ cảnh. Nhưng nếu bạn thực sự xem xét giao thức làm gì, giao thức chỉ truyền thông tin qua đường dây, nhưng client có trách nhiệm xử lý thông tin đó. Và điều mà mọi người đã làm cho đến nay, bởi vì chúng ta đang ở trong giai đoạn thử nghiệm ban đầu này, là chỉ đơn giản đặt tất cả các công cụ vào cửa sổ ngữ cảnh, và sau đó khá ngạc nhiên khi cửa sổ ngữ cảnh có thể trở nên lớn.
Nhưng điều bạn có thể làm thay thế, và điều bạn nên làm thay thế, là bạn nên bắt đầu sử dụng mô hình khám phá tiến bộ này, tức là, sử dụng một thứ gì đó như tìm kiếm công cụ để trì hoãn việc tải các công cụ, và bắt đầu tải các công cụ khi mô hình cần. Và chúng tôi có điều này trong sản phẩm Anthropic và API, và mọi người cũng có thể sử dụng điều này trên các API của các đối thủ cạnh tranh. Nhưng bạn cũng có thể tự xây dựng điều này, nơi bạn không trực tiếp tải công cụ. Ngay khi bạn cung cấp cho mô hình một công cụ tải công cụ về cơ bản, và mô hình sẽ nói, "À, có lẽ mình cần một công cụ bây giờ. Hãy để mình tìm kiếm những công cụ mình cần," và sau đó bạn tải chúng theo yêu cầu. Và trong ví dụ này, những gì bạn đang thấy ở phía bên trái là Claude Code, trước khi chúng tôi thêm điều này vào Claude Code, và sau đó là sau khi thêm vào Claude Code. Vì vậy, bạn thấy một sự giảm đáng kể trong việc sử dụng ngữ cảnh công cụ.
Phần thứ hai của điều đó là một thứ gọi là gọi công cụ có lập trình, hoặc điều mà những người khác thường gọi là chế độ mã. Đây là ý tưởng rằng một điều bạn thực sự muốn làm là tổng hợp mọi thứ lại với nhau. Bạn không muốn mô hình gọi một công cụ, lấy kết quả, sau đó gọi một công cụ khác, lấy kết quả, rồi lại gọi một công cụ khác. Bởi vì những gì bạn thực sự đang làm là bạn đang để mô hình điều phối mọi thứ lại với nhau, và trong điều phối đó, bạn đang sử dụng suy luận, nó nhạy cảm với độ trễ, và tất cả những thứ đó có thể được thực hiện hiệu quả hơn nhiều nếu bạn thay vào đó viết một tập lệnh. Và trên thực tế, đó thực sự là điều bạn liên tục làm và điều bạn liên tục thấy, như Claude Code làm khi nó viết lệnh bash.
Nhưng tất nhiên bạn có thể làm điều này với mọi thứ, và bạn có thể làm điều này với MCP, và bạn nên làm điều này với MCP. Vậy điều này có nghĩa là gì? Thay vì có hết công cụ này đến công cụ khác, bạn muốn cung cấp cho mô hình một công cụ REPL, cung cấp một môi trường thực thi như V8, Isolate, hoặc Monty, hoặc một trình thông dịch Lua, và chỉ cần để mô hình viết mã cho bạn, và mô hình chỉ cần thực thi mã đó, và sau đó tổng hợp chúng lại với nhau.
Và có một tính năng gọn gàng, một đầu ra có cấu trúc MCP-code, cho bạn biết giá trị trả về của mã MCP, của đầu ra sẽ là gì. Và mô hình có thể sử dụng thông tin này để tìm ra thông tin kiểu, điều đó có nghĩa là nó có thể tổng hợp những thứ này lại với nhau một cách rất tốt. Và trong ví dụ này, thay vì thực hiện các cuộc gọi công cụ khác nhau, bạn thực hiện một cuộc gọi duy nhất, và bạn có thể lọc. Mô hình sẽ tự động xóa mọi thứ khỏi JSON và tiếp tục.
Tất nhiên, nếu bạn không có một đầu ra có cấu trúc, bạn luôn có thể yêu cầu mô hình cung cấp cho bạn một đầu ra có cấu trúc, bằng cách chỉ cần trích xuất nó và nói, "Này, gọi cho chúng ta mô hình giá rẻ, và nói, tôi muốn kiểu mong muốn này, hãy trả lại cho tôi," và bùm, bạn có một kiểu, mô hình có thể tổng hợp mọi thứ lại với nhau. Và tôi nghĩ đây là điều chúng ta vẫn chưa làm đủ, và đây là điều chúng ta có thể cải thiện agent harnesses của mình.
Và cuối cùng nhưng không kém phần quan trọng, tất nhiên bạn có thể tổng hợp những thứ này lại với nhau bằng các tệp thực thi, như với CLIs, với các thành phần khác, với cả APIs.
Thiết kế API cho Tác nhân thay vì REST truyền thống
Tiếp theo, điều chúng ta cần làm, bên cạnh công việc client — bao gồm khám phá tiến bộ và gọi công cụ có lập trình — là chúng ta cần bắt đầu xây dựng một cách đúng đắn cho các tác nhân. Và điều đó có nghĩa là tất cả chúng ta cần ngừng lấy các REST API và đặt chúng một đối một vào một máy chủ MCP. Mỗi lần tôi thấy ai đó xây dựng một công cụ chuyển đổi REST sang MCP server khác, nó hơi cringed (khiến khó chịu) vì tôi nghĩ nó chỉ dẫn đến những điều khủng khiếp.
Và thay vào đó, bạn nên thiết kế cho một tác nhân. Về cơ bản, bạn có thể bắt đầu thiết kế cho bạn với tư cách là một con người, cách bạn muốn tương tác với điều này, bởi vì đó thực sự là một khởi đầu rất, rất tốt cho một tác nhân. Nếu bạn muốn điều phối mọi thứ lại với nhau, bạn nên chọn, tất nhiên, gọi công cụ có lập trình. Và bạn có thể làm điều này ở phía client, như tôi đã nói trước đó, nhưng bạn cũng có thể làm điều này ở phía server.
Cải thiện sử dụng MCP và Điều phối Tác nhân
Máy chủ MCP của CloudFlem và các hệ thống tương tự là những ví dụ tuyệt vời về cách bạn có thể cung cấp một môi trường thực thi cho mô hình, thay vì chỉ cung cấp các công cụ. Sau đó, mô hình có thể orchestration mọi thứ với nhau. Điều này giúp giảm mức sử dụng mã thông báo, giảm độ trễ và mạnh mẽ hơn rất nhiều trong khả năng kết hợp của nó.
Cuối cùng, nhưng không kém phần quan trọng, chúng ta, với tư cách là các tác giả máy chủ, nên bắt đầu sử dụng ngữ nghĩa phong phú mà MCP cung cấp so với các lựa chọn thay thế. Điều này có nghĩa là phát hành các ứng dụng MCP, phát hành kỹ năng thông qua MCP, và sử dụng các yếu tố như tasks và các khía cạnh khác mà giao thức cung cấp hiện đang bị sử dụng chưa triệt để, hoặc những thứ như elicitations. Đó là những điều chỉ MCP mới có thể làm được cho bạn.
Cải tiến Lõi MCP
Tất nhiên, đó là tất cả công việc mà các bạn cần làm, và có thể một số nhân sự sản phẩm của chúng tôi cũng cần thực hiện. Chúng tôi cũng cần thực hiện rất nhiều công việc trên chính MCP. Có một vài điều sắp tới mà chúng ta sẽ phải giải quyết. Điều quan trọng nhất là chúng ta cần cải thiện lõi. Có một số điều mà, khi chúng tôi đã phát triển giao thức trong năm qua, hiện không ở trong tình trạng tốt.
Đầu tiên là HTTP truyền tải theo luồng hiện tại rất khó mở rộng quy mô nếu bạn là một nhà cung cấp dịch vụ siêu lớn (hyper-scaler). Vì vậy, chúng tôi có một đề xuất từ những người bạn tại Google, những người đang làm việc với một giao thức vận chuyển không trạng thái (stateless transport protocol), điều này làm cho việc xử lý các máy chủ MCP như một máy chủ REST không trạng thái khác trở nên dễ dàng hơn đáng kể. Giống như những gì chúng ta đã quen thuộc khi triển khai lên Cloud Run hoặc Kubernetes, v.v. Điều này sẽ ra mắt vào tháng 6 và hy vọng sẽ sớm được tích hợp vào các SDK.
Cải thiện Giao tiếp Tác nhân và SDK
Ngoài ra, chúng ta cần cải thiện tính năng nguyên thủy cho tác vụ bất đồng bộ của mình, về cơ bản là một cách hoa mỹ để nói rằng chúng ta chỉ muốn có giao tiếp tác nhân với tác nhân. Chúng tôi có một phiên bản thử nghiệm của giao thức mà rất ít client hỗ trợ. Vì vậy, chúng tôi sẽ bắt đầu xây dựng nhiều client hơn cho tính năng này.
Quan trọng nhất, chúng tôi đang cải thiện một số ngữ nghĩa nhỏ cần thiết. Chúng tôi sẽ phát hành SDK phiên bản 2 cho TypeScript và SDK phiên bản 2 cho Python, dựa trên nhiều bài học kinh nghiệm trong năm qua. Có một SDK tên là FastMCP. Ai đang sử dụng FastMCP? Đúng vậy, nó tốt hơn rất nhiều so với SDK Python mà chúng tôi đang phát hành, phải không? Và đó là lỗi của tôi vì tôi đã viết SDK Python. Vì vậy, tôi có một nhóm những người giỏi hơn tôi nhiều trong việc phát triển Python để giúp tôi viết nó tốt hơn.
Tích hợp Rộng rãi và Khám phá Máy chủ MCP
Phần thứ hai là chúng ta cần bắt đầu tích hợp ở mọi nơi. Chúng tôi sẽ phát hành, đặc biệt cho các doanh nghiệp, một thứ gọi là cross app access (truy cập đa ứng dụng). Đây là một tính năng mới mà chúng tôi đang hợp tác chặt chẽ với các Nhà cung cấp danh tính (IDP), chỉ đơn giản là cho phép bạn (một cách hoa mỹ để nói) sau khi bạn đăng nhập một lần bằng Nhà cung cấp danh tính của công ty bạn, dù là Google hay một actor, bạn sẽ có thể sử dụng các máy chủ MCP mà không cần phải đăng nhập lại. Điều này mang lại sự mượt mà hơn.
Ngoài ra, chúng tôi sẽ thêm một tính năng gọi là server discovery (khám phá máy chủ) bằng cách chỉ định cách bạn có thể tự động khám phá các máy chủ trên các URL đã biết. Vì vậy, các crawler, trình duyệt và tác nhân có thể truy cập một trang web và nói, "À, thay vì chỉ phân tích cú pháp trang web, có máy chủ MCP nào tôi có thể sử dụng không?". Và chúng tôi sẽ có thể tự động khám phá điều này. Đây là một tính năng thực sự thú vị sẽ ra mắt vào tháng 6 khi chúng tôi ra mắt một ex-specification và sẽ được hỗ trợ tại đó.
Mở rộng MCP thông qua Cơ chế Tiện ích
Và cuối cùng nhưng không kém phần quan trọng, chúng tôi đang bắt đầu sử dụng các cơ chế mở rộng của mình trong MCP, điều này có nghĩa là một số client sẽ hỗ trợ điều này, ví dụ như các ứng dụng MCP, sẽ chỉ được hỗ trợ bởi các giao diện dựa trên web. Bởi vì nếu bạn là một giao diện dòng lệnh (CLI), bạn sẽ gặp khó khăn khi hiển thị HTML. Và chúng tôi sẽ thực hiện nhiều tiện ích mở rộng như vậy hơn nữa.
Một trong những tiện ích mở rộng thú vị nhất mà tôi nghĩ là hay là chúng ta sẽ phát hành các kỹ năng thông qua MCP. Bởi vì rõ ràng là nếu bạn có một máy chủ MCP lớn với vô số công cụ, bạn chỉ muốn gửi kèm theo kiến thức chính và nói, "Đây là cách bạn nên sử dụng cái này, đây là cách bạn nên sử dụng cái kia." Và với tư cách là tác giả máy chủ, bạn có thể liên tục phát hành các kỹ năng được cập nhật mà không cần phải dựa vào các cơ chế plug-in và registry hay những thứ khác. Điều đó sắp ra mắt. Đã có rất nhiều thử nghiệm từ mọi người trong không gian đó. Bạn đã có thể làm một phần trong số đó ngay hôm nay nếu bạn chỉ cung cấp các kỹ năng tải mô hình cho một ngày. Bạn có thể xây dựng các phiên bản nguyên thủy của điều này ngay hôm nay mà không cần phải dựa vào ngữ nghĩa, nhưng tất nhiên, chúng tôi sẽ định nghĩa ngữ nghĩa đó.
Tầm nhìn MCP cho Tương lai Giao tiếp Tác nhân
Được rồi, đó là cách dài dòng của tôi để nói rằng tôi nghĩ MCP thực sự đang ở trong một tình trạng rất tốt. Và tôi nghĩ trong năm nay, chúng ta sẽ thúc đẩy các tác nhân đến khả năng kết nối hoàn chỉnh. MCP sẽ tiếp tục đóng một vai trò cực kỳ quan trọng. Và tất nhiên chúng tôi muốn nhận được phản hồi từ các bạn. Chúng tôi là một cộng đồng rất cởi mở. Chúng tôi vừa tạo ra một tổ chức nơi hầu hết các hoạt động được điều hành như một cộng đồng mã nguồn mở với Discord và các vấn đề. Hãy đến với chúng tôi và cho chúng tôi biết chúng tôi sai ở đâu? Chúng tôi làm đúng ở đâu? Để chúng tôi có thể cải thiện điều này một cách liên tục.
Vì vậy, tôi nghĩ năm 2026 sẽ là tất cả về kết nối. Và các tác nhân tốt nhất sẽ sử dụng mọi phương pháp có sẵn. Họ sẽ sử dụng sử dụng máy tính, họ sẽ sử dụng giao diện dòng lệnh (CLI), họ sẽ sử dụng MCP, và họ sẽ sử dụng kỹ năng. Bởi vì họ muốn có một sự đa dạng đúng đắn về những điều họ có thể làm. Và sau đó họ có thể tạo ra những thứ hay ho như thế này. Đây là một trong những tính năng sản phẩm chúng tôi vừa phát hành gần đây. Về cơ bản, đó không gì khác ngoài một ứng dụng MCP hiển thị nội dung. Tuyệt vời. Vậy bây giờ chúng ta có thể xem xét các biểu đồ viết mô hình. Dù sao đi nữa, xin cảm ơn.
TL;DR
- MCP (Microservice Communication Protocol) là một giao thức độc đáo cho phép máy chủ tự vận chuyển giao diện và công cụ của ứng dụng, không cần plugin hay SDK, giúp cả con người và AI model dễ dàng tương tác trên nhiều nền tảng.
- Trong 18 tháng qua, MCP đã phát triển mạnh mẽ thành một tiêu chuẩn chung cho giao tiếp tác nhân, đạt 110 triệu lượt tải xuống hàng tháng và tích hợp sâu rộng vào các hệ thống doanh nghiệp và ứng dụng AI.
- Tầm nhìn đến năm 2026 tập trung vào các "tác nhân tổng quát" có khả năng thực hiện công việc tri thức phức tạp, đòi hỏi khả năng kết nối đa dạng, thiết kế API hướng tác nhân và các kỹ thuật tối ưu hóa như khám phá tiến bộ và gọi công cụ có lập trình.
Điểm chính
- MCP là Giao thức Giao diện & Công cụ Tập trung vào Tác nhân: Nó cung cấp một cách để ứng dụng vận chuyển giao diện và công cụ của mình trực tiếp từ máy chủ, cho phép tương tác liền mạch bởi cả con người (qua UI) và AI model (qua công cụ) mà không phụ thuộc vào plugin hoặc SDK phía client.
- Ba Trụ cột Khả năng Kết nối cho Tác nhân: Xây dựng tác nhân hiệu quả vào năm 2026 sẽ dựa trên ba yếu tố: Kỹ năng (kiến thức chuyên môn), CLI (cho tác nhân cục bộ, môi trường cô lập, các công cụ đã được huấn luyện trước), và MCP (cho ngữ nghĩa phong phú, UI, tác vụ chạy dài, quản trị doanh nghiệp và tính độc lập nền tảng).
- Thực hiện Khám phá Tiến bộ: Phía client (agent harness) nên sử dụng mô hình "khám phá tiến bộ" để trì hoãn việc tải công cụ, chỉ tải chúng khi model cần, giảm đáng kể kích thước cửa sổ ngữ cảnh và cải thiện hiệu quả.
- Áp dụng Gọi Công cụ có Lập trình (Code Mode): Thay vì gọi công cụ tuần tự, cung cấp cho model một môi trường thực thi (ví dụ: REPL, V8, Lua interpreter) để model viết và thực thi mã nhằm điều phối các công cụ, giảm độ trễ, tiết kiệm mã thông báo và tăng tính linh hoạt.
- Thiết kế API hướng Tác nhân: Ngừng chuyển đổi 1:1 các REST API truyền thống sang máy chủ MCP. Thay vào đó, thiết kế API từ đầu với tư duy về cách cả con người và tác nhân sẽ tương tác và điều phối công việc, tận dụng các tính năng ngữ nghĩa phong phú của MCP.
- Khai thác Ngữ nghĩa Phong phú của MCP: Tận dụng các tính năng độc đáo của MCP như ứng dụng MCP, kỹ năng qua MCP, các nguyên thủy như tác vụ (tasks) và elicitations để xây dựng các tương tác tác nhân mạnh mẽ và phức tạp hơn.
- Cải tiến Lõi Giao thức: MCP đang được nâng cấp với giao thức vận chuyển không trạng thái (stateless transport) để mở rộng quy mô dễ dàng hơn cho các hyper-scaler, cải thiện giao tiếp tác nhân-tác nhân bất đồng bộ và SDK phiên bản 2 tốt hơn cho TypeScript và Python.
- Tích hợp và Khám phá Rộng rãi: Các tính năng mới như "truy cập đa ứng dụng" (cross-app access) thông qua IDP và "khám phá máy chủ" (server discovery) để tự động nhận diện máy chủ MCP trên URL sẽ giúp tăng cường tích hợp và đơn giản hóa việc triển khai.
Từ vựng
- ứng dụng MCP — MCP application
- tác nhân — agent
- giao thức — protocol
- máy chủ — server
- công cụ — tool
- khả năng kết nối — connectivity
- khám phá tiến bộ — progressive discovery
- gọi công cụ có lập trình — programmatic tool calling
- API — API
- SDK — SDK
Nội dung chi tiết
Giới thiệu về Ứng dụng MCP
Chào mừng quý vị. Hãy bắt đầu. Đây là một ứng dụng MCP. Nó là một tác nhân tự vận chuyển giao diện của mình, không thông qua một plugin, không qua một SDK, không được mô hình hiển thị động trên phía client, hay mã hóa cứng vào sản phẩm. Đây là một thứ được phục vụ qua máy chủ MCP, và bạn có thể lấy máy chủ, đặt nó vào đám mây, bạn có thể đặt nó vào ChatGPT, bạn có thể đặt nó vào VS Code, Cursor, và nó sẽ hoạt động.
Và điều đó, tôi nghĩ, khá hay, bởi vì để làm được điều đó, bạn cần một thứ mà nhiều điều chúng ta muốn trong hệ sinh thái không cung cấp. Bạn cần một số phân tích. Bạn cần cả hai phía — client và server — để hiểu những gì mỗi phía đang nói, để hiểu kết xuất của bạn như thế nào, để hiểu rằng có một UI sắp tới. Và vì điều đó, bạn cần một giao thức.
Và điều tuyệt vời nhất về điều này, một máy chủ MCP không chỉ vận chuyển một ứng dụng, hoặc có thể vận chuyển một ứng dụng, nó còn có thể vận chuyển các công cụ cùng với nó. Vì vậy, bạn có thể tương tác với ứng dụng đó như một con người, và bạn có thể để mô hình tương tác với nó thông qua các công cụ, điều mà tôi nghĩ là một điều rất độc đáo mà chúng ta chưa khám phá nhiều cho đến nay.
Hành trình phát triển MCP: Từ ý tưởng đến 110 triệu lượt tải
Được rồi, nhưng hãy cùng tua lại một chút từ đây — điều mà tôi nghĩ là một cái nhìn thoáng qua thực sự thú vị về tương lai của MCP. Hơn một năm trước, 18 tháng — một sự vĩnh cửu trong vòng đời AI — tất cả những điều này không hề tồn tại. Chỉ có một tài liệu đặc tả nhỏ, một vài SDK, chủ yếu do Klott viết, chỉ hoạt động cục bộ, với rất ít hơn là các công cụ.
Trong 18 hoặc 12 tháng qua, các bạn đã điên cuồng xây dựng mọi thứ, xây dựng các máy chủ, và một hệ sinh thái điên rồ xung quanh điều này. Và chúng tôi, về phía mình, đã bận rộn biến điều chỉ hoạt động cục bộ này, thêm khả năng từ xa, thêm ủy quyền tập trung, thêm các nguyên thủy mới như elicitation và tác vụ, và cuối cùng nhưng không kém phần quan trọng, thêm các tính năng thử nghiệm mới vào giao thức, giống như các ứng dụng MCP mà bạn vừa thấy.
Và trong thời gian đó, chúng ta đã đạt được, tôi nghĩ, một cột mốc thực sự thú vị, bởi vì, một lần nữa, tất cả các bạn đã điên cuồng xây dựng, và xây dựng, và xây dựng — tất nhiên, may mắn là với sự giúp đỡ của rất nhiều tác nhân. Chúng ta hiện có 110 triệu lượt tải xuống hàng tháng, và đó tất nhiên không phải chỉ là chúng tôi sử dụng nó trong các client và máy chủ của mình. Đó là tác nhân SDK của OpenAI, đó là ADC của Google, đó là Langshane, hàng nghìn khung làm việc và công cụ mà bạn có thể chưa bao giờ nghe nói đến, kéo nó như một phụ thuộc, điều đó có nghĩa là có một tiêu chuẩn chung mà tất cả chúng ta có thể sử dụng để giao tiếp với nhau.
Chỉ một chút ngữ cảnh, React, một trong những dự án mã nguồn mở thành công nhất có lẽ trong những thập kỷ qua, đã mất khoảng gấp đôi thời gian để đạt được khối lượng tải xuống đó. Và trong thời gian đó, tất nhiên, tất cả các bạn đã xây dựng những máy chủ thực sự, thực sự tuyệt vời — từ những dự án nhỏ như máy chủ WhatsApp và máy chủ Blender cho đến việc xây dựng các tích hợp SaaS như Linear, Slack và Notions, những thứ thực sự thúc đẩy những gì mọi người làm hàng ngày khi họ sử dụng MCPs. Nhưng quan trọng nhất, phần lớn các máy chủ MCP mà hầu hết chúng ta đã xây dựng đều ở "phía sau cánh cửa đóng kín", kết nối hệ thống công ty với các tác nhân trong ứng dụng AI.
Tầm nhìn 2026: Tác nhân tổng quát và Khả năng kết nối
Nhưng tôi vẫn nghĩ đây chỉ là sự khởi đầu tuyệt đối của chúng ta, bởi vì tôi nghĩ năm 2025 là tất cả về khám phá, và năm 2026 là tất cả về việc đưa các tác nhân này vào sản xuất. Bởi vì nếu bạn thực sự nghĩ về nó, trong tâm trí tôi, năm 2024, chúng ta chỉ xây dựng một loạt các bản demo và trình diễn những thứ thú vị cho mọi người, và có một chút sự chú ý ở đó. Năm 2025 thực sự là tất cả về coding tác nhân, nhưng coding tác nhân, nếu bạn thực sự nghĩ về nó, là kịch bản lý tưởng nhất cho một tác nhân. Nó cục bộ, nó rất khả thi, bạn có thể gọi một trình biên dịch. Giống như, bạn có một nhà phát triển có thể khắc phục mọi thứ nếu có lỗi xảy ra trước máy tính, và bạn có thể hiển thị một giao diện công cụ, và người dùng khá hài lòng.
Nhưng tôi nghĩ bây giờ với khả năng của mô hình ngày càng tăng, chúng ta đang bước vào một kỷ nguyên mới, mà tôi nghĩ năm nay sẽ bắt đầu. Chúng ta sẽ không chỉ thực hiện coding tác nhân nữa, mà sẽ có các tác nhân tổng quát sẽ thực hiện công việc tri thức thực sự, như những việc phân tích tài chính mà các nhà phân tích tài chính muốn làm, hoặc một người làm marketing muốn làm, và họ cần một điều đặc biệt. Họ không cần một tác nhân cục bộ gọi một trình biên dịch, mà thứ họ cần là một thứ có thể kết nối với khoảng năm ứng dụng SaaS và một ổ đĩa chia sẻ, bởi vì phần quan trọng nhất đối với họ cho một tác nhân là khả năng kết nối.
Và trong tâm trí tôi, khả năng kết nối không phải là một điều duy nhất. Nếu ai đó nói với bạn rằng có một giải pháp cho tất cả các vấn đề kết nối của bạn, cho dù đó là sử dụng máy tính, CLI, hay MCP, họ có lẽ đã sai. Bởi vì điều đúng đắn, tất nhiên, là nó luôn có nghĩa "còn tùy", và có một ngăn xếp khả năng kết nối rất lớn, và có một công cụ phù hợp cho công việc phù hợp.
Ba trụ cột cho Tác nhân năm 2026: Kỹ năng, MCP và CLI
Và trong tâm trí tôi, có ba điều chính bạn muốn xem xét khi xây dựng một tác nhân vào năm 2026: kỹ năng, MCP, và tất nhiên là CLI (hoặc sử dụng máy tính), tùy thuộc vào trường hợp sử dụng. Và chúng có ba điều rất khác biệt mà chúng có thể làm, và ba điều khác nhau bạn muốn xem xét khi bạn xây dựng tác nhân của mình.
Thứ nhất, kỹ năng, tất nhiên, giống như kiến thức chuyên môn. Nó giống như việc nắm bắt các khả năng cụ thể được đưa vào một tệp rất đơn giản, và nó hầu hết là không thể rút gọn. Có một số khác biệt nhỏ giữa các nền tảng khác nhau.
Tất nhiên, CLI rất phổ biến khi sử dụng coding tác nhân cục bộ. Nó là một công cụ tuyệt vời để bắt đầu một cách đơn giản, để có một thứ mà bạn có thể đóng trong một bash, mà mô hình có thể tự động khám phá những gì CLI có khả năng. Và quan trọng nhất, nếu bạn có những thứ giống như CLIs, như GitHub, Git, và những thứ khác đã có trong pre-training, CLI là một giải pháp tuyệt vời cho phần khả năng kết nối của bạn. Và chúng đặc biệt tốt khi bạn có một tác nhân cục bộ, nơi bạn có thể giả định một môi trường biệt lập, nơi bạn có thể giả định một môi trường thực thi mã.
Nhưng nếu bạn không có điều này, nếu bạn cần ngữ nghĩa phong phú, khi bạn cần một UI có thể hiển thị các tác vụ chạy dài, khi bạn cần những thứ như tài nguyên, khi bạn cần xây dựng một thứ gì đó hoàn toàn tách rời và cần độc lập nền tảng, hoặc bạn không có một môi trường biệt lập, khi bạn cần những thứ như ủy quyền, quản trị, chính sách — hoặc nói ngắn gọn là những thứ doanh nghiệp nhàm chán nhưng quan trọng — hoặc nếu bạn muốn có những thử nghiệm như ứng dụng MCP, hoặc điều gì sắp tới là kỹ năng qua MCP, thì tôi nghĩ MCP chỉ giống như một mô liên kết bổ sung, chỉ là một công cụ khác trong hộp công cụ của bạn để xây dựng một tác nhân tuyệt vời.
Và vì vậy, tất cả những điều này muốn nói rằng tôi nghĩ vào năm 2026, chúng ta sẽ bắt đầu xây dựng các tác nhân sử dụng tất cả những điều này. Chúng không chỉ sử dụng một thứ; chúng sử dụng tất cả, và chúng sử dụng chúng một cách khá liền mạch cùng nhau.
Cải thiện Tác nhân với Khám phá Tiến bộ và Gọi công cụ có lập trình
Nhưng tôi không nghĩ chúng ta đã hoàn toàn đạt được điều đó, bởi vì chúng ta cần xây dựng rất nhiều thứ — một phần vì các tác nhân của chúng ta vẫn còn "hơi tệ", và một phần vì tôi nghĩ chúng ta chưa nói đủ về một số kỹ thuật mà bạn có thể thực hiện để thực sự kết nối mô liên kết này lại với nhau.
Điều số một mà chúng ta cần thực hiện và bắt đầu xây dựng là ở phía client, ở phía agent harness — về những thứ cung cấp năng lượng cho các phần kết nối, dù đó là Claude Code, Py, hay bất kỳ ứng dụng nào bạn sắp xây dựng. Và điều số một chúng ta sẽ làm ở đó, và điều tất cả chúng ta phải làm, và điều tôi thực sự muốn truyền đạt hôm nay, là chúng ta cần bắt đầu xây dựng một thứ gọi là khám phá tiến bộ.
Hầu hết mọi người khi nghĩ về "Ồ, MCP," họ không thể nghĩ về phình to ngữ cảnh. Nhưng nếu bạn thực sự xem xét giao thức làm gì, giao thức chỉ truyền thông tin qua đường dây, nhưng client có trách nhiệm xử lý thông tin đó. Và điều mà mọi người đã làm cho đến nay, bởi vì chúng ta đang ở trong giai đoạn thử nghiệm ban đầu này, là chỉ đơn giản đặt tất cả các công cụ vào cửa sổ ngữ cảnh, và sau đó khá ngạc nhiên khi cửa sổ ngữ cảnh có thể trở nên lớn.
Nhưng điều bạn có thể làm thay thế, và điều bạn nên làm thay thế, là bạn nên bắt đầu sử dụng mô hình khám phá tiến bộ này, tức là, sử dụng một thứ gì đó như tìm kiếm công cụ để trì hoãn việc tải các công cụ, và bắt đầu tải các công cụ khi mô hình cần. Và chúng tôi có điều này trong sản phẩm Anthropic và API, và mọi người cũng có thể sử dụng điều này trên các API của các đối thủ cạnh tranh. Nhưng bạn cũng có thể tự xây dựng điều này, nơi bạn không trực tiếp tải công cụ. Ngay khi bạn cung cấp cho mô hình một công cụ tải công cụ về cơ bản, và mô hình sẽ nói, "À, có lẽ mình cần một công cụ bây giờ. Hãy để mình tìm kiếm những công cụ mình cần," và sau đó bạn tải chúng theo yêu cầu. Và trong ví dụ này, những gì bạn đang thấy ở phía bên trái là Claude Code, trước khi chúng tôi thêm điều này vào Claude Code, và sau đó là sau khi thêm vào Claude Code. Vì vậy, bạn thấy một sự giảm đáng kể trong việc sử dụng ngữ cảnh công cụ.
Phần thứ hai của điều đó là một thứ gọi là gọi công cụ có lập trình, hoặc điều mà những người khác thường gọi là chế độ mã. Đây là ý tưởng rằng một điều bạn thực sự muốn làm là tổng hợp mọi thứ lại với nhau. Bạn không muốn mô hình gọi một công cụ, lấy kết quả, sau đó gọi một công cụ khác, lấy kết quả, rồi lại gọi một công cụ khác. Bởi vì những gì bạn thực sự đang làm là bạn đang để mô hình điều phối mọi thứ lại với nhau, và trong điều phối đó, bạn đang sử dụng suy luận, nó nhạy cảm với độ trễ, và tất cả những thứ đó có thể được thực hiện hiệu quả hơn nhiều nếu bạn thay vào đó viết một tập lệnh. Và trên thực tế, đó thực sự là điều bạn liên tục làm và điều bạn liên tục thấy, như Claude Code làm khi nó viết lệnh bash.
Nhưng tất nhiên bạn có thể làm điều này với mọi thứ, và bạn có thể làm điều này với MCP, và bạn nên làm điều này với MCP. Vậy điều này có nghĩa là gì? Thay vì có hết công cụ này đến công cụ khác, bạn muốn cung cấp cho mô hình một công cụ REPL, cung cấp một môi trường thực thi như V8, Isolate, hoặc Monty, hoặc một trình thông dịch Lua, và chỉ cần để mô hình viết mã cho bạn, và mô hình chỉ cần thực thi mã đó, và sau đó tổng hợp chúng lại với nhau.
Và có một tính năng gọn gàng, một đầu ra có cấu trúc MCP-code, cho bạn biết giá trị trả về của mã MCP, của đầu ra sẽ là gì. Và mô hình có thể sử dụng thông tin này để tìm ra thông tin kiểu, điều đó có nghĩa là nó có thể tổng hợp những thứ này lại với nhau một cách rất tốt. Và trong ví dụ này, thay vì thực hiện các cuộc gọi công cụ khác nhau, bạn thực hiện một cuộc gọi duy nhất, và bạn có thể lọc. Mô hình sẽ tự động xóa mọi thứ khỏi JSON và tiếp tục.
Tất nhiên, nếu bạn không có một đầu ra có cấu trúc, bạn luôn có thể yêu cầu mô hình cung cấp cho bạn một đầu ra có cấu trúc, bằng cách chỉ cần trích xuất nó và nói, "Này, gọi cho chúng ta mô hình giá rẻ, và nói, tôi muốn kiểu mong muốn này, hãy trả lại cho tôi," và bùm, bạn có một kiểu, mô hình có thể tổng hợp mọi thứ lại với nhau. Và tôi nghĩ đây là điều chúng ta vẫn chưa làm đủ, và đây là điều chúng ta có thể cải thiện agent harnesses của mình.
Và cuối cùng nhưng không kém phần quan trọng, tất nhiên bạn có thể tổng hợp những thứ này lại với nhau bằng các tệp thực thi, như với CLIs, với các thành phần khác, với cả APIs.
Thiết kế API cho Tác nhân thay vì REST truyền thống
Tiếp theo, điều chúng ta cần làm, bên cạnh công việc client — bao gồm khám phá tiến bộ và gọi công cụ có lập trình — là chúng ta cần bắt đầu xây dựng một cách đúng đắn cho các tác nhân. Và điều đó có nghĩa là tất cả chúng ta cần ngừng lấy các REST API và đặt chúng một đối một vào một máy chủ MCP. Mỗi lần tôi thấy ai đó xây dựng một công cụ chuyển đổi REST sang MCP server khác, nó hơi cringed (khiến khó chịu) vì tôi nghĩ nó chỉ dẫn đến những điều khủng khiếp.
Và thay vào đó, bạn nên thiết kế cho một tác nhân. Về cơ bản, bạn có thể bắt đầu thiết kế cho bạn với tư cách là một con người, cách bạn muốn tương tác với điều này, bởi vì đó thực sự là một khởi đầu rất, rất tốt cho một tác nhân. Nếu bạn muốn điều phối mọi thứ lại với nhau, bạn nên chọn, tất nhiên, gọi công cụ có lập trình. Và bạn có thể làm điều này ở phía client, như tôi đã nói trước đó, nhưng bạn cũng có thể làm điều này ở phía server.
Cải thiện sử dụng MCP và Điều phối Tác nhân
Máy chủ MCP của CloudFlem và các hệ thống tương tự là những ví dụ tuyệt vời về cách bạn có thể cung cấp một môi trường thực thi cho mô hình, thay vì chỉ cung cấp các công cụ. Sau đó, mô hình có thể orchestration mọi thứ với nhau. Điều này giúp giảm mức sử dụng mã thông báo, giảm độ trễ và mạnh mẽ hơn rất nhiều trong khả năng kết hợp của nó.
Cuối cùng, nhưng không kém phần quan trọng, chúng ta, với tư cách là các tác giả máy chủ, nên bắt đầu sử dụng ngữ nghĩa phong phú mà MCP cung cấp so với các lựa chọn thay thế. Điều này có nghĩa là phát hành các ứng dụng MCP, phát hành kỹ năng thông qua MCP, và sử dụng các yếu tố như tasks và các khía cạnh khác mà giao thức cung cấp hiện đang bị sử dụng chưa triệt để, hoặc những thứ như elicitations. Đó là những điều chỉ MCP mới có thể làm được cho bạn.
Cải tiến Lõi MCP
Tất nhiên, đó là tất cả công việc mà các bạn cần làm, và có thể một số nhân sự sản phẩm của chúng tôi cũng cần thực hiện. Chúng tôi cũng cần thực hiện rất nhiều công việc trên chính MCP. Có một vài điều sắp tới mà chúng ta sẽ phải giải quyết. Điều quan trọng nhất là chúng ta cần cải thiện lõi. Có một số điều mà, khi chúng tôi đã phát triển giao thức trong năm qua, hiện không ở trong tình trạng tốt.
Đầu tiên là HTTP truyền tải theo luồng hiện tại rất khó mở rộng quy mô nếu bạn là một nhà cung cấp dịch vụ siêu lớn (hyper-scaler). Vì vậy, chúng tôi có một đề xuất từ những người bạn tại Google, những người đang làm việc với một giao thức vận chuyển không trạng thái (stateless transport protocol), điều này làm cho việc xử lý các máy chủ MCP như một máy chủ REST không trạng thái khác trở nên dễ dàng hơn đáng kể. Giống như những gì chúng ta đã quen thuộc khi triển khai lên Cloud Run hoặc Kubernetes, v.v. Điều này sẽ ra mắt vào tháng 6 và hy vọng sẽ sớm được tích hợp vào các SDK.
Cải thiện Giao tiếp Tác nhân và SDK
Ngoài ra, chúng ta cần cải thiện tính năng nguyên thủy cho tác vụ bất đồng bộ của mình, về cơ bản là một cách hoa mỹ để nói rằng chúng ta chỉ muốn có giao tiếp tác nhân với tác nhân. Chúng tôi có một phiên bản thử nghiệm của giao thức mà rất ít client hỗ trợ. Vì vậy, chúng tôi sẽ bắt đầu xây dựng nhiều client hơn cho tính năng này.
Quan trọng nhất, chúng tôi đang cải thiện một số ngữ nghĩa nhỏ cần thiết. Chúng tôi sẽ phát hành SDK phiên bản 2 cho TypeScript và SDK phiên bản 2 cho Python, dựa trên nhiều bài học kinh nghiệm trong năm qua. Có một SDK tên là FastMCP. Ai đang sử dụng FastMCP? Đúng vậy, nó tốt hơn rất nhiều so với SDK Python mà chúng tôi đang phát hành, phải không? Và đó là lỗi của tôi vì tôi đã viết SDK Python. Vì vậy, tôi có một nhóm những người giỏi hơn tôi nhiều trong việc phát triển Python để giúp tôi viết nó tốt hơn.
Tích hợp Rộng rãi và Khám phá Máy chủ MCP
Phần thứ hai là chúng ta cần bắt đầu tích hợp ở mọi nơi. Chúng tôi sẽ phát hành, đặc biệt cho các doanh nghiệp, một thứ gọi là cross app access (truy cập đa ứng dụng). Đây là một tính năng mới mà chúng tôi đang hợp tác chặt chẽ với các Nhà cung cấp danh tính (IDP), chỉ đơn giản là cho phép bạn (một cách hoa mỹ để nói) sau khi bạn đăng nhập một lần bằng Nhà cung cấp danh tính của công ty bạn, dù là Google hay một actor, bạn sẽ có thể sử dụng các máy chủ MCP mà không cần phải đăng nhập lại. Điều này mang lại sự mượt mà hơn.
Ngoài ra, chúng tôi sẽ thêm một tính năng gọi là server discovery (khám phá máy chủ) bằng cách chỉ định cách bạn có thể tự động khám phá các máy chủ trên các URL đã biết. Vì vậy, các crawler, trình duyệt và tác nhân có thể truy cập một trang web và nói, "À, thay vì chỉ phân tích cú pháp trang web, có máy chủ MCP nào tôi có thể sử dụng không?". Và chúng tôi sẽ có thể tự động khám phá điều này. Đây là một tính năng thực sự thú vị sẽ ra mắt vào tháng 6 khi chúng tôi ra mắt một ex-specification và sẽ được hỗ trợ tại đó.
Mở rộng MCP thông qua Cơ chế Tiện ích
Và cuối cùng nhưng không kém phần quan trọng, chúng tôi đang bắt đầu sử dụng các cơ chế mở rộng của mình trong MCP, điều này có nghĩa là một số client sẽ hỗ trợ điều này, ví dụ như các ứng dụng MCP, sẽ chỉ được hỗ trợ bởi các giao diện dựa trên web. Bởi vì nếu bạn là một giao diện dòng lệnh (CLI), bạn sẽ gặp khó khăn khi hiển thị HTML. Và chúng tôi sẽ thực hiện nhiều tiện ích mở rộng như vậy hơn nữa.
Một trong những tiện ích mở rộng thú vị nhất mà tôi nghĩ là hay là chúng ta sẽ phát hành các kỹ năng thông qua MCP. Bởi vì rõ ràng là nếu bạn có một máy chủ MCP lớn với vô số công cụ, bạn chỉ muốn gửi kèm theo kiến thức chính và nói, "Đây là cách bạn nên sử dụng cái này, đây là cách bạn nên sử dụng cái kia." Và với tư cách là tác giả máy chủ, bạn có thể liên tục phát hành các kỹ năng được cập nhật mà không cần phải dựa vào các cơ chế plug-in và registry hay những thứ khác. Điều đó sắp ra mắt. Đã có rất nhiều thử nghiệm từ mọi người trong không gian đó. Bạn đã có thể làm một phần trong số đó ngay hôm nay nếu bạn chỉ cung cấp các kỹ năng tải mô hình cho một ngày. Bạn có thể xây dựng các phiên bản nguyên thủy của điều này ngay hôm nay mà không cần phải dựa vào ngữ nghĩa, nhưng tất nhiên, chúng tôi sẽ định nghĩa ngữ nghĩa đó.
Tầm nhìn MCP cho Tương lai Giao tiếp Tác nhân
Được rồi, đó là cách dài dòng của tôi để nói rằng tôi nghĩ MCP thực sự đang ở trong một tình trạng rất tốt. Và tôi nghĩ trong năm nay, chúng ta sẽ thúc đẩy các tác nhân đến khả năng kết nối hoàn chỉnh. MCP sẽ tiếp tục đóng một vai trò cực kỳ quan trọng. Và tất nhiên chúng tôi muốn nhận được phản hồi từ các bạn. Chúng tôi là một cộng đồng rất cởi mở. Chúng tôi vừa tạo ra một tổ chức nơi hầu hết các hoạt động được điều hành như một cộng đồng mã nguồn mở với Discord và các vấn đề. Hãy đến với chúng tôi và cho chúng tôi biết chúng tôi sai ở đâu? Chúng tôi làm đúng ở đâu? Để chúng tôi có thể cải thiện điều này một cách liên tục.
Vì vậy, tôi nghĩ năm 2026 sẽ là tất cả về kết nối. Và các tác nhân tốt nhất sẽ sử dụng mọi phương pháp có sẵn. Họ sẽ sử dụng sử dụng máy tính, họ sẽ sử dụng giao diện dòng lệnh (CLI), họ sẽ sử dụng MCP, và họ sẽ sử dụng kỹ năng. Bởi vì họ muốn có một sự đa dạng đúng đắn về những điều họ có thể làm. Và sau đó họ có thể tạo ra những thứ hay ho như thế này. Đây là một trong những tính năng sản phẩm chúng tôi vừa phát hành gần đây. Về cơ bản, đó không gì khác ngoài một ứng dụng MCP hiển thị nội dung. Tuyệt vời. Vậy bây giờ chúng ta có thể xem xét các biểu đồ viết mô hình. Dù sao đi nữa, xin cảm ơn.