- Việc kết nối các tác nhân AI với toàn bộ bề mặt API là thách thức lớn do giới hạn cửa sổ ngữ cảnh của LLM khi phải tải quá nhiều định nghĩa công cụ.
- Giải pháp hiệu quả nhất là để các tác nhân AI tự viết mã dựa trên các SDK được định kiểu (typed SDKs) được tạo ra từ đặc tả API, mang lại sự linh hoạt và khả năng bao quát cao.
- Để chạy an toàn mã không đáng tin cậy do AI tạo ra, cần sử dụng các môi trường cô lập bảo mật cao (như Cloudflare Worker isolates) với các hàng rào bảo vệ có thể lập trình được.
MCP = Mega Context Problem - Matt Carey
- Vấn đề cửa sổ ngữ cảnh: Các hệ thống tool calling truyền thống không thể mở rộng để bao phủ toàn bộ bề mặt API (hàng ngàn điểm cuối) vì sẽ làm quá tải cửa sổ ngữ cảnh của LLM.
- Các phương pháp khám phá công cụ:
- CLI cho tác nhân: Cho phép tác nhân tương tác qua giao diện dòng lệnh, nhưng yêu cầu quyền truy cập shell, gây ra rủi ro bảo mật.
- Tìm kiếm công cụ: Tải động các công cụ liên quan vào ngữ cảnh, giảm tải nhưng vẫn giữ một phần định nghĩa công cụ trong ngữ cảnh.
- Mô hình Code Mode: Cách tiếp cận tối ưu là để tác nhân AI tự động tạo mã (ví dụ: TypeScript) chống lại SDK được định kiểu (tạo từ OpenAPI spec) để gọi API, tận dụng khả năng của mô hình.
- Thách thức về mã không đáng tin cậy: Chạy mã do AI tạo ra tiềm ẩn rủi ro bảo mật nghiêm trọng như truy cập trái phép vào hệ thống tệp, rò rỉ bí mật, vòng lặp vô hạn, hoặc chạy các tác vụ độc hại.
- Giải pháp môi trường cô lập: Sử dụng các môi trường biệt lập (isolates) hiệu suất cao và an toàn (ví dụ: Cloudflare Workers) để thực thi mã không đáng tin cậy, cung cấp sandbox có thể lập trình và các hàng rào bảo vệ tùy chỉnh.
- Tương lai của tương tác AI-API: Xu hướng là chuyển dịch sang việc các tác nhân AI tạo và thực thi mã trong các môi trường cô lập an toàn, yêu cầu phát triển nhiều nguyên tắc hạ tầng hơn để hỗ trợ điều này trên web.
- Actionable: Khi thiết kế tương tác API cho tác nhân AI, ưu tiên các giải pháp cho phép khám phá công cụ dần dần và xem xét việc sử dụng mã được tạo bởi tác nhân trong một môi trường thực thi được kiểm soát và an toàn.
agent— tác nhânAPI— API (Giao diện lập trình ứng dụng)tool— công cụtool calling / function calling— gọi công cụ / gọi hàmLarge Language Model (LLM)— Mô hình ngôn ngữ lớn (LLM)context window— cửa sổ ngữ cảnhtoken— mã thông báoAPI endpoint— điểm cuối APIprogressive discovery— khám phá dần dầnCLI (Command Line Interface)— Giao diện dòng lệnh (CLI)shell access— quyền truy cập shelltyped SDK— SDK được định kiểuuntrusted code— mã không đáng tin cậyisolate / isolated environment— vùng cô lập / môi trường cô lậpguardrails— hàng rào bảo vệ
Giới thiệu về Tác nhân AI và Tương tác API
Chào mừng tất cả mọi người. Xin cảm ơn. Tôi là Matt và tôi làm việc với MCP và các tác nhân tại Cloudflare. Bài nói chuyện của tôi hôm nay sẽ tập trung vào cách chúng ta có thể biến mọi API thành một công cụ cho các tác nhân AI. Các API tồn tại rộng rãi, vậy làm thế nào để chúng ta kết nối chúng với các tác nhân và khiến chúng thực hiện các tác vụ?
Tôi thực sự yêu thích công việc của mình vì mỗi ngày, tôi được quyết định xem liệu một tác nhân có thể làm điều này hay không, và liệu nó có thể làm điều kia không. Thật thú vị khi chúng ta thường xuyên dao động giữa hai thái cực này. Ai đó làm điều gì đó mà bạn nghĩ là hơi buồn cười, và sáu tháng sau, tất cả chúng ta đều làm theo và coi đó là điều tuyệt vời nhất trên thế giới.
Tuy nhiên, phần chính trong vai trò của tôi, và những gì tôi làm hằng ngày, là làm thế nào để "trao tay" cho các tác nhân? Làm thế nào để chúng có thể tương tác với thế giới bên ngoài? Chắc hẳn các bạn đã quen thuộc với khái niệm này: đó là tool calling (gọi công cụ) hay function calling (gọi hàm). Nó đã xuất hiện được một thời gian rồi. Mô hình ngôn ngữ lớn (LLM) sẽ viết một hàm, bạn thực thi hàm đó. Ví dụ, hỏi về thời tiết ở London là 18 độ C. (Hiện tại thì không phải, trời chỉ khoảng 8 độ và đang đóng băng. Thật buồn.)
Sự Phát triển của Công cụ: Từ Công cụ Đóng gói đến Công cụ Chia sẻ (MCP)
Từ đó, chúng ta chuyển từ các công cụ đóng gói (bundled tools) sang các công cụ chia sẻ (shared tools). Mọi người đã tạo công cụ trong các tác nhân của họ. Chắc hẳn đây là lịch sử gần đây, nên mọi người đều biết. Nhưng trước khi có MCP, chúng tôi có những người đóng gói tất cả công cụ của họ vào các tác nhân của mình, và sau đó chúng sẽ được giữ nguyên như vậy. Nếu tôi muốn tương tác với Gmail hoặc thứ gì đó, tôi sẽ tạo hàng loạt công cụ cho Gmail, đóng gói chúng với tác nhân của tôi và thế là xong. Người tiếp theo sẽ phải làm chính xác điều tương tự.
Sau đó, khoảng tháng 4 năm ngoái, chúng ta chứng kiến sự bùng nổ của MCP và MCP từ xa. Các nhà cung cấp dịch vụ đã nói: "Chúng tôi có thể cung cấp cho mọi người các công cụ MCP. Sau đó, mọi người có thể sử dụng cùng một công cụ được tiêu chuẩn hóa. Chúng tôi chỉ cần tạo ra nó một lần và cung cấp nó như một kênh khác để mọi người sử dụng API của chúng tôi." Có thể có một CLI, một API, hoặc một API GraphQL. Và giờ đây, MCP là một kênh khác.
Thách thức về Cửa sổ Ngữ cảnh và Số lượng API
Nhưng mọi chuyện trở nên phức tạp một chút. Mọi thứ vẫn ổn với tám công cụ. Nhưng điều gì sẽ xảy ra nếu bạn thêm một vài công cụ nữa? Hay thêm vài cái nữa? Và giờ đây, bạn muốn cấp cho một tác nhân quyền truy cập vào toàn bộ bề mặt API của chúng tôi. Chà, điều đó sẽ không xảy ra. Tại sao? Bạn đã làm nổ tung cửa sổ ngữ cảnh (context window) của tác nhân rồi. Bạn đã hủy diệt nó hoàn toàn. Đây là một con số khổng lồ, hàng triệu mã thông báo (tokens).
Đây chính là vấn đề mà chúng tôi gặp phải cách đây khoảng một năm. Chúng tôi đang cố gắng cấp quyền truy cập vào toàn bộ API CLI cho các tác nhân. Bạn cố gắng tạo các công cụ đơn giản cho mỗi điểm cuối API (API endpoint), và bạn sẽ làm nổ tung cửa sổ ngữ cảnh. Đặc tả OpenAPI là 2,3 triệu mã thông báo. Nếu biến thành công cụ, đó là khoảng 1,1 triệu mã thông báo. Con số này sẽ không bao giờ khả thi ngay cả với các mô hình ngôn ngữ lớn nền tảng lớn nhất.
Giải pháp Tạm thời: Máy chủ MCP dựa trên Sản phẩm
Vào thời điểm đó, chúng tôi nhận ra rằng đây không nhất thiết là vấn đề của MCP, nhưng đó là cách mọi người khác đang làm. Vì vậy, chúng tôi quyết định thích nghi, cải tiến và chia API của mình thành nhiều máy chủ MCP dựa trên sản phẩm khác nhau. Chắc hẳn bạn đã thấy điều này, một công ty có thể xuất bản tới 16 máy chủ MCP. Và sau đó, người dùng phải tương tác với máy chủ mà họ muốn sử dụng khi cần.
Giải pháp này có ít ngữ cảnh hơn, nhưng người dùng phải tự chọn. Và hầu hết thời gian, phạm vi bao phủ là không đầy đủ. Ví dụ, một trong các bộ sản phẩm của chúng tôi có thể có sáu công cụ trong máy chủ MCP của chúng tôi, nhưng tổng API có thể có 30 điểm cuối. Bạn đã bỏ lỡ một phần đáng kể phạm vi bao phủ ở đó. Và điều này không đạt được mục tiêu "làm thế nào để biến mọi API thành một công cụ cho các tác nhân." Thực tế, nó khá khó chịu.
Tôi nghĩ tất cả chúng ta đều mắc sai lầm một chút. Tại Cloudflare, chúng tôi nhanh chóng có 16 máy chủ. Chúng tôi đang dao động quanh 1.000 điểm cuối, và tôi nghĩ hiện tại chúng tôi có 2.600 điểm cuối API. Nhưng về cơ bản, chúng tôi không thể chia tất cả các điểm cuối này thành hai máy chủ của mình. Và người dùng phải chọn những máy chủ mà chúng tôi muốn. Điều chúng tôi thực sự cần là progressive discovery (khám phá dần dần) các công cụ. Ai đã từng nghe về progressive discovery? Vâng, rất tốt.
Khám phá Công cụ Tiên tiến và Vấn đề Context
Điều đó đưa chúng ta đến điểm cốt yếu của các cuộc tranh luận trên mạng: làm thế nào để chúng ta thực hiện progressive discovery? Và liệu MCP đã chết? Liệu MCP có phải là một ý tưởng tồi? Tôi sẽ nói rằng tôi không nghĩ vậy. MCP là một giao thức. Tất cả những điều này đều có thể được phơi bày qua MCP. Chúng ta chỉ không nên đổ hàng loạt công cụ vào ngữ cảnh. Đó là điều chính. Chúng ta không nên đổ công cụ và tất cả các khả năng vào ngữ cảnh. Trong tương lai, chúng ta có thể có nhiều lời nhắc và tài nguyên hơn, các kỹ năng về cơ bản là tài nguyên. Và chúng ta không nên tải tất cả những thứ đó cùng một lúc.
Có ba cách để giải quyết vấn đề đó:
CLI(Giao diện dòng lệnh) - được nhiều người ưa thích.Tool search(Tìm kiếm công cụ).- Cách thứ ba mà chúng ta sẽ đề cập sau.
1. CLI cho Tác nhân
Vậy, CLI sẽ hoạt động như thế nào đối với các tác nhân? Đây là một sandbox ở phía sau. Nếu tôi sử dụng CLI của chúng tôi và thực hiện một lệnh như Wrangler, chúng tôi sẽ nhận được một loạt các lệnh. Tác nhân có thể đọc các lệnh này, phân tích chúng và nhận ra: "Ồ, tôi muốn tương tác với cơ sở dữ liệu." Vì vậy, nó sẽ chạy Wrangler D1. Và có thể chúng ta muốn liệt kê các cơ sở dữ liệu của mình. Sau một khoảng thời gian và một quá trình tương tác, chúng ta sẽ nhận được các cơ sở dữ liệu đó.
Một tác nhân có thể làm điều này hầu hết các trường hợp. Nó có thể gọi --help để tự kiểm tra các tham số cần thiết. Điều này hoạt động khá tốt và rất phổ biến với các công cụ như OpenCore. Mọi người nói chung rất thích CLI. Nhưng bạn cần quyền truy cập shell (shell access). Đây là điểm mấu chốt. Bạn phải có quyền truy cập shell, và điều đó hơi bất tiện.
2. Tìm kiếm Công cụ (Tool Search)
Đối với các hệ thống như Claude Code, họ muốn một cách cấu trúc hơn để thực hiện mọi việc. Vì vậy, họ có tool search. Họ có một công cụ tìm kiếm để tải các công cụ cần thiết vào ngữ cảnh khi cần. Ví dụ, Sarah muốn tạo một worker. Hệ thống sẽ lấy câu hỏi của người dùng, thực hiện một số loại khớp từ khóa, và sau đó thêm một số lượng công cụ nhất định (ví dụ: tám công cụ) vào ngữ cảnh. Sau đó, LLM sẽ tìm kiếm và nhận ra: "À, workers create - đây là cái chúng ta cần." Và chúng ta sẽ sử dụng cái đó. Nhưng phần còn lại của các công cụ vẫn nằm trong ngữ cảnh. Có thể không phải tám, có thể là sáu, con số này có thể thay đổi.
Dù sao, bạn vẫn sẽ có khoảng 2.100 mã thông báo, và chỉ 500 trong số đó được sử dụng. Nhưng nó hoạt động. Nó hoạt động khá tốt. Bạn chỉ tải các công cụ có liên quan.
3. Chế độ Mã hóa (Code Mode) và Tác nhân Viết mã
Điều cuối cùng là một bài đăng trên blog mà chúng tôi đã xuất bản vào mùa hè năm ngoái. Nó nói về việc, thay vì sử dụng một công cụ tìm kiếm tĩnh hoặc buộc tác nhân phải cần một CLI, làm thế nào chúng ta có thể làm điều gì đó mà chúng ta chỉ cần để tác nhân viết mã và để tác nhân viết mã chống lại API của chúng tôi?
Hóa ra TypeScript, cụ thể là các kiểu (types), là một cách rất súc tích để biểu diễn đầu vào và đầu ra theo cách mà một tác nhân có thể suy luận được. Vì vậy, giả sử bạn có tất cả các điểm cuối này, như get worker scripts hoặc create a worker hoặc những thứ tương tự. Chúng tôi tạo ra các kiểu này. Và sau đó, chúng tôi để mô hình (với các kiểu đã cho) viết một số mã chống lại các kiểu này.
Ở đây, chúng ta đang thực hiện code mode list workers. Tôi hy vọng các bạn có thể thấy điều đó. Và chúng ta sẽ cố gắng liệt kê một số worker. Đây có thể là một yêu cầu của người dùng để liệt kê các worker. Mô hình tạo ra mã này chống lại một SDK được định kiểu (typed SDK) mà chúng tôi tạo ra từ API của mình. Bạn có thể tạo chúng từ đặc tả OpenAPI. Và sau đó chúng ta có thể chạy nó và liệt kê các worker mà chúng ta có trong tài khoản của mình.
Chúng ta có thể triển khai một worker. Thật thú vị. "Hello world." Và chúng ta có thể đặt nó đằng sau một trong những điều khó khăn nhất để làm tại Cloudflare, điều này thật kỳ lạ vì đó là một sản phẩm rất mạnh mẽ. Nhưng chúng ta có thể thêm Access, đó là Nhà cung cấp danh tính (IDP) được quản lý của chúng tôi. Và giờ đây, worker này được bảo mật đằng sau Access. Thật tuyệt. Chúng ta có thể muốn chính sách Access chỉ cho phép tôi truy cập vào nó và tất cả những thứ này. Cực kỳ dễ dàng. Và một tác nhân có thể tạo ra tất cả mã này với các kiểu của chúng tôi.
Vì vậy, điều này có vẻ là một bước đi đúng hướng. Chỉ cần để mô hình viết mã, chúng ta sẽ được hưởng lợi từ việc mô hình trở nên tốt hơn. Chúng ta sẽ được hưởng lợi từ việc cải thiện đặc tả OpenAPI của chúng ta. Nó giống như đó nên là nguồn chân lý.
Thách thức: Chạy Mã Không đáng tin cậy
Nhưng chúng tôi đã gặp một điều hơi kỳ lạ khi chúng tôi nghĩ rằng điều này thật tuyệt vời và chúng tôi khá tự hào về nó. Nhưng các client đã không triển khai nó. Và khi tôi nói client, tôi đang nói theo thuật ngữ MCP, vậy client chính là tác nhân. Vì vậy, từ bây giờ, chúng ta sẽ gọi tác nhân là client.
Vậy các client đã không thực sự triển khai nó. Và chúng tôi hơi bối rối về lý do tại sao lại như vậy. Điều này xảy ra khoảng tám, chín tháng trước. Đây là một cách tốt hơn để tương tác với API – chỉ cần để mô hình viết mã chống lại API. Nhưng họ không triển khai nó. Và tại sao không? Bởi vì chạy mã không đáng tin cậy (untrusted code) là vô cùng, vô cùng đáng sợ.
Nếu vài năm trước tôi nói với bạn: "Ồ, chúng ta sẽ chỉ để một mô hình ngôn ngữ viết một số mã mà chúng ta sẽ thực thi cho người dùng mà không cần xem xét, không cần đọc, không cần biết nó làm gì, có thể có quyền truy cập bí mật (secret access) tiềm ẩn," bạn sẽ nói: "Điều đó thật điên rồ! Đó là một CVE (Lỗ hổng và Phơi nhiễm Chung), phải không? Đó là một CVE! Đó là một lỗ hổng. Đó là một vấn đề." Và bây giờ chúng ta đang đề xuất bạn làm điều này. Vì vậy, nó khá đáng sợ.
Rất nhiều điều có thể xảy ra sai sót. Chúng ta có thể đọc hệ thống tập tin (file system), đọc một số bí mật (secrets) mà bạn không muốn đọc. Nó có thể trích xuất các bí mật đó vào một yêu cầu mạng, chạy các vòng lặp vô hạn (infinite loops), tiêu thụ tất cả tài nguyên của bạn, làm những việc thực sự đáng sợ, chạy một trình đào tiền mã hóa (crypto miner). Điều đó sẽ rất tệ.
Trong quá khứ, mọi người đã thử rất nhiều cách để cho phép chạy các giải pháp giống như mã. Vì vậy, nếu ai đó đã từng viết một DSL (Ngôn ngữ đặc tả miền), một loại đặc tả JSON về cách nội suy nó thành mã, thì đó về cơ bản là cách này. Nếu bạn đã từng sử dụng một trong các phần mềm tích hợp đó, nơi bạn phải làm điều đó, thì đó là cách này. Họ chỉ không tin tưởng bạn viết mã trên máy chủ của họ.
Các máy ảo (VMs) cũng vậy, mọi người đang tạo ra các sandbox để chạy mã. Các sandbox lớn, các VM lớn, đó cũng là cách này. Và cả kiểm tra mã (code review).
Giải pháp An toàn: Vùng cô lập Worker
Nhưng chúng ta khá may mắn, bởi vì chúng ta có một công cụ khá thú vị giải quyết vấn đề này. Và sẽ có những công cụ khác giải quyết vấn đề này. Tôi chỉ nghĩ đây là cái đầu tiên và vì vậy đáng để nói về nó. Và đó là: làm thế nào để bạn chạy mã không đáng tin cậy một cách siêu an toàn cho bạn và cơ sở hạ tầng của bạn?
Nó hoạt động như thế này. Chúng ta có thể thực thi một worker từ một chuỗi. Và một worker chỉ giống như một vùng cô lập (isolate) nhỏ trong V8. Có nhiều blog về cách hoạt động của nó. Tôi sẽ không đi sâu quá chi tiết vào đó. Tôi chỉ sẽ cho bạn thấy nó có thể làm gì.
Ví dụ, chúng ta có đoạn mã được tạo ra này. Và chúng ta sẽ chạy đoạn mã được tạo ra này. Và điều này đã chạy trên backend. Nó không chạy trong trình duyệt của tôi. Nó chạy trong một worker động được cô lập hoàn toàn. Và làm thế nào tôi có thể chứng minh điều đó cho bạn? Nếu chúng ta thực hiện worker này, chúng ta đang cố gắng lấy một số bí mật ở đây, process.env. Và nếu chúng ta in chúng ra, không có bí mật nào cả. Và chúng ta cũng có biến toàn cục Cloudflare kỳ lạ này. Ồ, thú vị.
Nếu chúng ta tắt khả năng tương thích với Node, chúng ta thậm chí không có process.env ở đó. Và tất cả đều lỗi. Vì vậy, chúng ta có một sandbox có thể lập trình được. Nó không hẳn là một sandbox. Nó giống như một thứ rất nhẹ. Bạn có thể đặt mã vào đó và sau đó chạy nó. Và tôi sẽ trình bày một số tùy chọn khác sau.
Môi trường biệt lập có thể lập trình và Hàng rào bảo vệ
Không chỉ riêng chúng tôi có điều này, nhưng chúng tôi có một dịch vụ mà chúng tôi host cho bạn và nó có thể mở rộng đến quy mô của Cloudflare. Nếu bạn muốn thực hiện hàng tỷ yêu cầu, cứ thoải mái. Và bây giờ, đây là một ví dụ mà các tác nhân nằm trong một đoạn mã truy cập Giao diện lập trình ứng dụng bên ngoài. Nếu chúng ta chạy cái này, worker này không được phép truy cập internet thông qua các hàm toàn cục. Chà, có lẽ chúng ta muốn nó truy cập internet. Và bây giờ chúng ta có thể cấp quyền truy cập cho nó. Vì vậy, đó là một sandbox có thể lập trình với hàng rào bảo vệ có thể lập trình. Và tất cả những gì chúng ta đang làm ở đây là bật một giá trị Boolean trên máy chủ. Đó là tất cả những gì đang xảy ra ở đây. Nhưng bạn có thể cung cấp một hàm chuyên sâu hơn để giới hạn việc chỉ truy cập vào các domain nhất định. Và đó là những gì chúng tôi làm trên Cloudflare MCP. Nếu chúng ta chuyển sang phần tiếp theo.
Demo Cloudflare MCP
Ồ, nói về Cloudflare MCP, đây là nơi tôi thực sự hy vọng demo hoạt động. Đây là một MCP client trong slide. Và nếu chúng ta hỏi nó một câu hỏi, chúng ta sẽ nhận được một pop-up toàn màn hình. Và sau đó, hy vọng tất cả những điều này sẽ hoạt động một cách đáng kinh ngạc. Vì vậy, bây giờ chúng tôi đã cấp quyền truy cập toàn bộ Cloudflare API. Tất cả cơ sở hạ tầng Cloudflare của tôi đều có quyền truy cập. Điều đó khá tuyệt. Đừng lo lắng về các ID tài khoản này, chúng không phải là bí mật trong thế giới Cloudflare. Tuyệt vời. Vì vậy, chúng tôi vừa liệt kê một worker.
Nhưng bạn có thể làm nhiều điều hơn thế ở đây. Bạn có thể triển khai worker từ giao diện dòng lệnh của mình. Bạn có thể làm những gì chúng tôi đã làm trước đó và thêm quyền truy cập vào một thứ gì đó. Bạn có thể xem xét DNS của mình. Bạn có thể gửi email sớm. Bạn có thể làm rất nhiều thứ khác. Những gì bạn có thể làm ở đây thực sự rất tuyệt vời. Bởi vì bạn có quyền truy cập vào toàn bộ Cloudflare API, tất cả hơn 2.000 endpoint.
Tương lai của tác nhân và Công cụ bên ngoài: Phát triển mã
Và tôi đoán điều này đặt ra câu hỏi: chúng ta sẽ đi đến đâu khi cho phép các tác nhân truy cập công cụ bên ngoài? Điều này sẽ trông như thế nào? Bạn có những người cài đặt CLI cho mọi thứ. Họ đang chạy nó trên máy của riêng họ, hoặc có thể trên một VM. Điều đó khá hay. Chúng ta lại có những người nói rằng, "Ồ, bạn có thể chạy mã không tin cậy ở một nơi khác thực sự cô lập." Bạn có những người thực hiện tìm kiếm công cụ. Bạn có những người render UI JSON. Tôi không biết.
Và tôi đoán suy nghĩ chính của tôi là chúng ta sẽ có rất nhiều môi trường cô lập trên web. Và sẽ có rất nhiều nguyên tắc hạ tầng cho phép bạn chạy loại mã không tin cậy này trên web. Bởi vì mã thực sự là một kế hoạch rất gọn nhẹ. Thay vì thực hiện các lời gọi công cụ, bạn có thể có một công cụ được gọi là mã, trong đó mô hình tạo ra mã theo lựa chọn của bạn, và sau đó bạn chạy nó. Và mã đó có nhiều mức độ tự do hơn một lời gọi công cụ riêng lẻ. Vì vậy, đối với tôi, điều đó hợp lý khi các mô hình trở nên thông minh hơn, đây là những gì chúng ta sẽ làm. Và mọi người sẽ điều chỉnh các nguyên tắc hạ tầng của họ để làm điều này. Vì vậy, sẽ có nhiều điều như thế này hơn nữa. Và bạn thấy điều này bắt đầu với Pydantic Monte, Dino cũng vậy, và chúng tôi cũng có nó với Workadie, các worker động mà tôi đã trình bày trước đó. Nhiều người hơn sẽ xây dựng các nguyên tắc này bởi vì chúng sẽ ngày càng trở nên hữu ích hơn.
Chuyển đổi sang Chạy mã không đáng tin cậy
Vì vậy, chỉ là một lời giải thích nhỏ. Đây là Workadie, khởi tạo một worker động trong sandbox này và chạy một đoạn mã để lấy một chuỗi fibonacci. Bạn có thể làm điều tương tự với Dino, với Dino run, với một số kiểm tra đáng ngờ. Tôi không biết nó làm gì. Và sau đó bạn cũng có thể làm điều tương tự với Pydantic Monte, sau đó bạn code interpreter để chạy Python không đáng tin cậy. Vì nó là Python, chúng ta phải tải xuống Python. Khó khăn. Điều này có thể không bao giờ hoạt động. Tôi không biết. Ồ, đây rồi. Tuyệt vời.
Vì vậy, có lẽ bạn có thể thấy hướng chúng ta đang đi. Đã có một thời gian trước đây không ai dám chạy mã không đáng tin cậy. Đó là một lỗ hổng CV. Bạn sẽ ngay lập tức phải ngăn chặn điều đó. Và sau đó, dường như đối với các Mô hình ngôn ngữ lớn, việc chúng tạo ra mã mà bạn có thể chạy thực sự rất tốt. Và vì vậy bây giờ chúng ta đang xây dựng các nguyên tắc để thực sự cho phép chúng ta làm điều đó. Và có vẻ như chúng ta đã bỏ lỡ toàn bộ phần này của lĩnh vực công nghệ mà chúng ta chưa từng thử trước đây. Vào những năm 1950, khi bạn muốn chạy một cái gì đó trên máy tính ở thị trấn của mình, bạn in ra một số thẻ đục lỗ, và bạn đóng dấu chúng, và bạn đưa chúng cho người điều khiển. Và đó cũng giống như chạy mã không đáng tin cậy, phải không? Đó là như vậy. Và sau đó khi chúng ta chuyển sang điện toán đám mây, chúng ta đã rời xa điều đó. Và bây giờ tôi nghĩ chúng ta sẽ quay trở lại điều đó nhiều hơn, nơi người dùng của bạn có thể viết mã, bởi vì người dùng của bạn là AI. Và AI rất giỏi trong việc viết mã. Và đó là cách họ sẽ tương tác với nền tảng của bạn, dù thông qua MCP, dù thông qua bash và CLI, tôi không bận tâm. Tôi nghĩ họ sẽ chỉ viết mã chống lại các dịch vụ của bạn. Và các dịch vụ của bạn phải sẵn sàng cho điều này. Các Giao diện lập trình ứng dụng của bạn phải sẵn sàng chịu đựng, bởi vì chúng phải có giới hạn tốc độ tốt. Bởi vì tôi có thể chạy điều này trong một vòng lặp đầy đủ trên nhiều sandbox cùng một lúc, và chỉ tấn công Giao diện lập trình ứng dụng của bạn. Bạn phải có cách nào đó để bảo vệ điều đó. Đây là thế giới mới mà chúng ta sẽ sống.
Đổi mới phía máy khách
Và đó là về phía máy chủ, về phía các dịch vụ. Vậy điều gì sẽ xảy ra ở phía máy khách? Vì vậy, tôi nghĩ điều đó thậm chí còn thú vị hơn, bởi vì đó là phía đối diện người dùng. Nhưng người dùng sẽ không nhìn thấy máy chủ. Người dùng không quan tâm. Người dùng chỉ quan tâm tại sao tác nhân của tôi không nhận được email Gmail của tôi? Hoặc tại sao nó lại xóa toàn bộ hộp thư đến của tôi? Họ sẽ không thấy điều đó. Nhưng ở phía máy khách, sẽ có rất nhiều đổi mới. Và tôi nghĩ chúng ta đã chững lại một chút gần đây, bởi vì việc xây dựng một MCP client nói riêng trở nên thực sự rất khó để xây dựng một client hiệu suất và hoạt động tốt. Bạn cần quản lý các kết nối có trạng thái. Bạn cần quản lý khả năng tiếp tục giữa các kết nối đó. Có rất nhiều lý do khác khiến việc xây dựng MCP client trở nên khó khăn, nhưng đó là một nỗi đau, một nỗi đau tuyệt đối.
Và vì vậy, mọi người có các client được lược bỏ nhiều nhất có thể. Họ chủ yếu offload sang các SDK MCP, khá tối thiểu. Và không ai xây dựng những trải nghiệm UI độc đáo hơn trên đó. Và tôi nghĩ điều đó sẽ đến rất, rất sớm. Vì vậy, điều hiển nhiên nhất là chúng ta sẽ có lời gọi công cụ có thể lập trình trong các client. Slide trước chúng ta vừa thực hiện cho thấy những sandbox đó với Workadie, Dino và Pynantic. Đó chỉ là chạy mã không đáng tin cậy trong một client. Mọi người sẽ làm điều đó. Nếu client của bạn là remote, bạn sẽ làm điều đó theo cách đó. Nếu client của bạn là local, thì cứ yo-lo nó, dù sao đi nữa. Chỉ cần eval nó. Sẽ ổn thôi. Nhưng nhiều người hơn sẽ thực hiện lời gọi công cụ có thể lập trình này. Nó sẽ xảy ra.
Và bởi vì bạn đang tạo mã, mọi người sẽ lưu mã này. Và họ sẽ lưu nó trong các mini script này. Và người dùng có thể quyết định, hành động tôi vừa thực hiện, mà Mô hình ngôn ngữ lớn đã tạo ra cho tôi, tôi muốn giữ nó lại để sử dụng sau. Và sau đó nó sẽ nhanh hơn nhiều. Vì vậy, bạn có thể thấy những thứ như Chrome jobs, một người dùng có thể thiết lập một web scraping job, mà không cần bất kỳ kiến thức nào về cách web scraping hoạt động. Và sau đó nó tạo ra một script. Và script đó được chạy hàng ngày, hai ngày một lần. Và bất cứ khi nào nó bị hỏng, bởi vì web scraping khá dễ vỡ, tác nhân sẽ sửa nó và lưu lại script. Điều này sẽ xảy ra. Và tôi nghĩ những mini script đã lưu này. Chúng chỉ hoạt động khi bạn áp dụng lời gọi công cụ có thể lập trình, nhưng chúng thực sự hiệu quả.
Và điều cuối cùng là chúng ta có lẽ sẽ có nhiều client hơn nữa, bởi vì cho đến nay chúng rất khó tạo, và nó sẽ trở nên dễ dàng hơn. Thực tế chỉ có, không có một lượng lớn MCP client được sử dụng rộng rãi. Điều đó sẽ thay đổi. Và với sự thay đổi đó, nhiều người hơn sẽ có thể tạo, nhiều người hơn sẽ triển khai tác nhân lên đám mây mà cuối cùng trở thành MCP client. Và tôi nghĩ nhiều người hơn sẽ cố gắng thực hiện điều vòng lặp tác nhân không trạng thái này. Sẽ ổn thôi khi có sandbox cho mỗi tác nhân chạy mã cục bộ, nếu có một triệu tác nhân trên thế giới này. Tôi nghĩ khi có 100 tác nhân cho mỗi người, ồ, xin chào. Đừng làm vậy. Điều đó sẽ bắt đầu trở nên thực sự khó khăn. Và bạn sẽ phải áp dụng một cách tiếp cận đám mây bản địa để thực hiện mọi thứ, điều đó có nghĩa là trạng thái phải là thứ bạn có thể bật hoặc tắt.
Sự phát triển của MCP và SDK
Và đây, tôi nghĩ, chúng ta đang gần kết thúc. Nhưng đây là điều cuối cùng của tôi. Giống như, tôi làm việc rất nhiều trên máy chủ MCP và trên SDK. Và đây là nơi tôi nghĩ phần đó sẽ đi đến đâu. Tôi nghĩ chúng ta sẽ thấy MCP như một middleware trong một máy chủ MCP khi bạn xây dựng một dịch vụ API. Nó sẽ là một flag mà bạn có thể bật trong framework yêu thích của mình. SDK bản thân nó đang trở nên siêu nhẹ. Và tôi nghĩ vào cuối năm nay, nó sẽ được tích hợp gốc trong mọi framework full-stack lớn, ít nhất là TypeScript. Nó sẽ có mặt một cách tự nhiên. Bởi vì nó sẽ rất nhỏ, nó sẽ chỉ đơn thuần thể hiện giao thức trong chính nó. Và sẽ thật ngớ ngẩn nếu họ không có nó. Họ sẽ chỉ có một tích hợp gốc. Và họ sẽ có thể làm cho MCP là true trên tất cả các Giao diện lập trình ứng dụng của bạn. Và bởi vì tất cả các client sẽ thực hiện lời gọi công cụ có thể lập trình, bạn có thể thể hiện 1000 Giao diện lập trình ứng dụng của mình từ một ứng dụng Next.js và chỉ cần đặt MCP là true và hiển thị nhiều công cụ hơn thông qua MCP nữa. Và tôi nghĩ điều đó sẽ xảy ra. Ý tôi là, tôi nghĩ điều đó sẽ xảy ra trong một thời gian, nhưng tôi nghĩ chúng ta đã thực sự gần rồi. Và rào cản cuối cùng là thực sự sửa SDK để nó có khả năng làm điều đó. Nó có khả năng phù hợp với mọi bundle, thực sự. Và đó là kế hoạch.
Tài nguyên và Lời cảm ơn
Bạn có thể tìm hiểu thêm. Chúng tôi có một bài đăng trên blog Code Mode vừa ra mắt gần đây. Đó là cách chúng tôi cung cấp cho các tác nhân toàn bộ API trong 1000 mã thông báo. Nếu bạn có một API lớn, bạn nên làm điều này. Và các nhà cung cấp khả năng tiếp cận làm ơn hãy làm điều này. Bởi vì việc mọi người truy cập dữ liệu của bạn thực sự rất tốt. Và xin cảm ơn. Hãy dùng thử. NPMI agents. Cảm ơn rất nhiều.
TL;DR
- Việc kết nối các tác nhân AI với toàn bộ bề mặt API là thách thức lớn do giới hạn cửa sổ ngữ cảnh của LLM khi phải tải quá nhiều định nghĩa công cụ.
- Giải pháp hiệu quả nhất là để các tác nhân AI tự viết mã dựa trên các SDK được định kiểu (typed SDKs) được tạo ra từ đặc tả API, mang lại sự linh hoạt và khả năng bao quát cao.
- Để chạy an toàn mã không đáng tin cậy do AI tạo ra, cần sử dụng các môi trường cô lập bảo mật cao (như Cloudflare Worker isolates) với các hàng rào bảo vệ có thể lập trình được.
Điểm chính
- Vấn đề cửa sổ ngữ cảnh: Các hệ thống tool calling truyền thống không thể mở rộng để bao phủ toàn bộ bề mặt API (hàng ngàn điểm cuối) vì sẽ làm quá tải cửa sổ ngữ cảnh của LLM.
- Các phương pháp khám phá công cụ:
- CLI cho tác nhân: Cho phép tác nhân tương tác qua giao diện dòng lệnh, nhưng yêu cầu quyền truy cập shell, gây ra rủi ro bảo mật.
- Tìm kiếm công cụ: Tải động các công cụ liên quan vào ngữ cảnh, giảm tải nhưng vẫn giữ một phần định nghĩa công cụ trong ngữ cảnh.
- Mô hình Code Mode: Cách tiếp cận tối ưu là để tác nhân AI tự động tạo mã (ví dụ: TypeScript) chống lại SDK được định kiểu (tạo từ OpenAPI spec) để gọi API, tận dụng khả năng của mô hình.
- Thách thức về mã không đáng tin cậy: Chạy mã do AI tạo ra tiềm ẩn rủi ro bảo mật nghiêm trọng như truy cập trái phép vào hệ thống tệp, rò rỉ bí mật, vòng lặp vô hạn, hoặc chạy các tác vụ độc hại.
- Giải pháp môi trường cô lập: Sử dụng các môi trường biệt lập (isolates) hiệu suất cao và an toàn (ví dụ: Cloudflare Workers) để thực thi mã không đáng tin cậy, cung cấp sandbox có thể lập trình và các hàng rào bảo vệ tùy chỉnh.
- Tương lai của tương tác AI-API: Xu hướng là chuyển dịch sang việc các tác nhân AI tạo và thực thi mã trong các môi trường cô lập an toàn, yêu cầu phát triển nhiều nguyên tắc hạ tầng hơn để hỗ trợ điều này trên web.
- Actionable: Khi thiết kế tương tác API cho tác nhân AI, ưu tiên các giải pháp cho phép khám phá công cụ dần dần và xem xét việc sử dụng mã được tạo bởi tác nhân trong một môi trường thực thi được kiểm soát và an toàn.
Từ vựng
agent— tác nhânAPI— API (Giao diện lập trình ứng dụng)tool— công cụtool calling / function calling— gọi công cụ / gọi hàmLarge Language Model (LLM)— Mô hình ngôn ngữ lớn (LLM)context window— cửa sổ ngữ cảnhtoken— mã thông báoAPI endpoint— điểm cuối APIprogressive discovery— khám phá dần dầnCLI (Command Line Interface)— Giao diện dòng lệnh (CLI)shell access— quyền truy cập shelltyped SDK— SDK được định kiểuuntrusted code— mã không đáng tin cậyisolate / isolated environment— vùng cô lập / môi trường cô lậpguardrails— hàng rào bảo vệ
Nội dung chi tiết
Giới thiệu về Tác nhân AI và Tương tác API
Chào mừng tất cả mọi người. Xin cảm ơn. Tôi là Matt và tôi làm việc với MCP và các tác nhân tại Cloudflare. Bài nói chuyện của tôi hôm nay sẽ tập trung vào cách chúng ta có thể biến mọi API thành một công cụ cho các tác nhân AI. Các API tồn tại rộng rãi, vậy làm thế nào để chúng ta kết nối chúng với các tác nhân và khiến chúng thực hiện các tác vụ?
Tôi thực sự yêu thích công việc của mình vì mỗi ngày, tôi được quyết định xem liệu một tác nhân có thể làm điều này hay không, và liệu nó có thể làm điều kia không. Thật thú vị khi chúng ta thường xuyên dao động giữa hai thái cực này. Ai đó làm điều gì đó mà bạn nghĩ là hơi buồn cười, và sáu tháng sau, tất cả chúng ta đều làm theo và coi đó là điều tuyệt vời nhất trên thế giới.
Tuy nhiên, phần chính trong vai trò của tôi, và những gì tôi làm hằng ngày, là làm thế nào để "trao tay" cho các tác nhân? Làm thế nào để chúng có thể tương tác với thế giới bên ngoài? Chắc hẳn các bạn đã quen thuộc với khái niệm này: đó là tool calling (gọi công cụ) hay function calling (gọi hàm). Nó đã xuất hiện được một thời gian rồi. Mô hình ngôn ngữ lớn (LLM) sẽ viết một hàm, bạn thực thi hàm đó. Ví dụ, hỏi về thời tiết ở London là 18 độ C. (Hiện tại thì không phải, trời chỉ khoảng 8 độ và đang đóng băng. Thật buồn.)
Sự Phát triển của Công cụ: Từ Công cụ Đóng gói đến Công cụ Chia sẻ (MCP)
Từ đó, chúng ta chuyển từ các công cụ đóng gói (bundled tools) sang các công cụ chia sẻ (shared tools). Mọi người đã tạo công cụ trong các tác nhân của họ. Chắc hẳn đây là lịch sử gần đây, nên mọi người đều biết. Nhưng trước khi có MCP, chúng tôi có những người đóng gói tất cả công cụ của họ vào các tác nhân của mình, và sau đó chúng sẽ được giữ nguyên như vậy. Nếu tôi muốn tương tác với Gmail hoặc thứ gì đó, tôi sẽ tạo hàng loạt công cụ cho Gmail, đóng gói chúng với tác nhân của tôi và thế là xong. Người tiếp theo sẽ phải làm chính xác điều tương tự.
Sau đó, khoảng tháng 4 năm ngoái, chúng ta chứng kiến sự bùng nổ của MCP và MCP từ xa. Các nhà cung cấp dịch vụ đã nói: "Chúng tôi có thể cung cấp cho mọi người các công cụ MCP. Sau đó, mọi người có thể sử dụng cùng một công cụ được tiêu chuẩn hóa. Chúng tôi chỉ cần tạo ra nó một lần và cung cấp nó như một kênh khác để mọi người sử dụng API của chúng tôi." Có thể có một CLI, một API, hoặc một API GraphQL. Và giờ đây, MCP là một kênh khác.
Thách thức về Cửa sổ Ngữ cảnh và Số lượng API
Nhưng mọi chuyện trở nên phức tạp một chút. Mọi thứ vẫn ổn với tám công cụ. Nhưng điều gì sẽ xảy ra nếu bạn thêm một vài công cụ nữa? Hay thêm vài cái nữa? Và giờ đây, bạn muốn cấp cho một tác nhân quyền truy cập vào toàn bộ bề mặt API của chúng tôi. Chà, điều đó sẽ không xảy ra. Tại sao? Bạn đã làm nổ tung cửa sổ ngữ cảnh (context window) của tác nhân rồi. Bạn đã hủy diệt nó hoàn toàn. Đây là một con số khổng lồ, hàng triệu mã thông báo (tokens).
Đây chính là vấn đề mà chúng tôi gặp phải cách đây khoảng một năm. Chúng tôi đang cố gắng cấp quyền truy cập vào toàn bộ API CLI cho các tác nhân. Bạn cố gắng tạo các công cụ đơn giản cho mỗi điểm cuối API (API endpoint), và bạn sẽ làm nổ tung cửa sổ ngữ cảnh. Đặc tả OpenAPI là 2,3 triệu mã thông báo. Nếu biến thành công cụ, đó là khoảng 1,1 triệu mã thông báo. Con số này sẽ không bao giờ khả thi ngay cả với các mô hình ngôn ngữ lớn nền tảng lớn nhất.
Giải pháp Tạm thời: Máy chủ MCP dựa trên Sản phẩm
Vào thời điểm đó, chúng tôi nhận ra rằng đây không nhất thiết là vấn đề của MCP, nhưng đó là cách mọi người khác đang làm. Vì vậy, chúng tôi quyết định thích nghi, cải tiến và chia API của mình thành nhiều máy chủ MCP dựa trên sản phẩm khác nhau. Chắc hẳn bạn đã thấy điều này, một công ty có thể xuất bản tới 16 máy chủ MCP. Và sau đó, người dùng phải tương tác với máy chủ mà họ muốn sử dụng khi cần.
Giải pháp này có ít ngữ cảnh hơn, nhưng người dùng phải tự chọn. Và hầu hết thời gian, phạm vi bao phủ là không đầy đủ. Ví dụ, một trong các bộ sản phẩm của chúng tôi có thể có sáu công cụ trong máy chủ MCP của chúng tôi, nhưng tổng API có thể có 30 điểm cuối. Bạn đã bỏ lỡ một phần đáng kể phạm vi bao phủ ở đó. Và điều này không đạt được mục tiêu "làm thế nào để biến mọi API thành một công cụ cho các tác nhân." Thực tế, nó khá khó chịu.
Tôi nghĩ tất cả chúng ta đều mắc sai lầm một chút. Tại Cloudflare, chúng tôi nhanh chóng có 16 máy chủ. Chúng tôi đang dao động quanh 1.000 điểm cuối, và tôi nghĩ hiện tại chúng tôi có 2.600 điểm cuối API. Nhưng về cơ bản, chúng tôi không thể chia tất cả các điểm cuối này thành hai máy chủ của mình. Và người dùng phải chọn những máy chủ mà chúng tôi muốn. Điều chúng tôi thực sự cần là progressive discovery (khám phá dần dần) các công cụ. Ai đã từng nghe về progressive discovery? Vâng, rất tốt.
Khám phá Công cụ Tiên tiến và Vấn đề Context
Điều đó đưa chúng ta đến điểm cốt yếu của các cuộc tranh luận trên mạng: làm thế nào để chúng ta thực hiện progressive discovery? Và liệu MCP đã chết? Liệu MCP có phải là một ý tưởng tồi? Tôi sẽ nói rằng tôi không nghĩ vậy. MCP là một giao thức. Tất cả những điều này đều có thể được phơi bày qua MCP. Chúng ta chỉ không nên đổ hàng loạt công cụ vào ngữ cảnh. Đó là điều chính. Chúng ta không nên đổ công cụ và tất cả các khả năng vào ngữ cảnh. Trong tương lai, chúng ta có thể có nhiều lời nhắc và tài nguyên hơn, các kỹ năng về cơ bản là tài nguyên. Và chúng ta không nên tải tất cả những thứ đó cùng một lúc.
Có ba cách để giải quyết vấn đề đó:
CLI(Giao diện dòng lệnh) - được nhiều người ưa thích.Tool search(Tìm kiếm công cụ).- Cách thứ ba mà chúng ta sẽ đề cập sau.
1. CLI cho Tác nhân
Vậy, CLI sẽ hoạt động như thế nào đối với các tác nhân? Đây là một sandbox ở phía sau. Nếu tôi sử dụng CLI của chúng tôi và thực hiện một lệnh như Wrangler, chúng tôi sẽ nhận được một loạt các lệnh. Tác nhân có thể đọc các lệnh này, phân tích chúng và nhận ra: "Ồ, tôi muốn tương tác với cơ sở dữ liệu." Vì vậy, nó sẽ chạy Wrangler D1. Và có thể chúng ta muốn liệt kê các cơ sở dữ liệu của mình. Sau một khoảng thời gian và một quá trình tương tác, chúng ta sẽ nhận được các cơ sở dữ liệu đó.
Một tác nhân có thể làm điều này hầu hết các trường hợp. Nó có thể gọi --help để tự kiểm tra các tham số cần thiết. Điều này hoạt động khá tốt và rất phổ biến với các công cụ như OpenCore. Mọi người nói chung rất thích CLI. Nhưng bạn cần quyền truy cập shell (shell access). Đây là điểm mấu chốt. Bạn phải có quyền truy cập shell, và điều đó hơi bất tiện.
2. Tìm kiếm Công cụ (Tool Search)
Đối với các hệ thống như Claude Code, họ muốn một cách cấu trúc hơn để thực hiện mọi việc. Vì vậy, họ có tool search. Họ có một công cụ tìm kiếm để tải các công cụ cần thiết vào ngữ cảnh khi cần. Ví dụ, Sarah muốn tạo một worker. Hệ thống sẽ lấy câu hỏi của người dùng, thực hiện một số loại khớp từ khóa, và sau đó thêm một số lượng công cụ nhất định (ví dụ: tám công cụ) vào ngữ cảnh. Sau đó, LLM sẽ tìm kiếm và nhận ra: "À, workers create - đây là cái chúng ta cần." Và chúng ta sẽ sử dụng cái đó. Nhưng phần còn lại của các công cụ vẫn nằm trong ngữ cảnh. Có thể không phải tám, có thể là sáu, con số này có thể thay đổi.
Dù sao, bạn vẫn sẽ có khoảng 2.100 mã thông báo, và chỉ 500 trong số đó được sử dụng. Nhưng nó hoạt động. Nó hoạt động khá tốt. Bạn chỉ tải các công cụ có liên quan.
3. Chế độ Mã hóa (Code Mode) và Tác nhân Viết mã
Điều cuối cùng là một bài đăng trên blog mà chúng tôi đã xuất bản vào mùa hè năm ngoái. Nó nói về việc, thay vì sử dụng một công cụ tìm kiếm tĩnh hoặc buộc tác nhân phải cần một CLI, làm thế nào chúng ta có thể làm điều gì đó mà chúng ta chỉ cần để tác nhân viết mã và để tác nhân viết mã chống lại API của chúng tôi?
Hóa ra TypeScript, cụ thể là các kiểu (types), là một cách rất súc tích để biểu diễn đầu vào và đầu ra theo cách mà một tác nhân có thể suy luận được. Vì vậy, giả sử bạn có tất cả các điểm cuối này, như get worker scripts hoặc create a worker hoặc những thứ tương tự. Chúng tôi tạo ra các kiểu này. Và sau đó, chúng tôi để mô hình (với các kiểu đã cho) viết một số mã chống lại các kiểu này.
Ở đây, chúng ta đang thực hiện code mode list workers. Tôi hy vọng các bạn có thể thấy điều đó. Và chúng ta sẽ cố gắng liệt kê một số worker. Đây có thể là một yêu cầu của người dùng để liệt kê các worker. Mô hình tạo ra mã này chống lại một SDK được định kiểu (typed SDK) mà chúng tôi tạo ra từ API của mình. Bạn có thể tạo chúng từ đặc tả OpenAPI. Và sau đó chúng ta có thể chạy nó và liệt kê các worker mà chúng ta có trong tài khoản của mình.
Chúng ta có thể triển khai một worker. Thật thú vị. "Hello world." Và chúng ta có thể đặt nó đằng sau một trong những điều khó khăn nhất để làm tại Cloudflare, điều này thật kỳ lạ vì đó là một sản phẩm rất mạnh mẽ. Nhưng chúng ta có thể thêm Access, đó là Nhà cung cấp danh tính (IDP) được quản lý của chúng tôi. Và giờ đây, worker này được bảo mật đằng sau Access. Thật tuyệt. Chúng ta có thể muốn chính sách Access chỉ cho phép tôi truy cập vào nó và tất cả những thứ này. Cực kỳ dễ dàng. Và một tác nhân có thể tạo ra tất cả mã này với các kiểu của chúng tôi.
Vì vậy, điều này có vẻ là một bước đi đúng hướng. Chỉ cần để mô hình viết mã, chúng ta sẽ được hưởng lợi từ việc mô hình trở nên tốt hơn. Chúng ta sẽ được hưởng lợi từ việc cải thiện đặc tả OpenAPI của chúng ta. Nó giống như đó nên là nguồn chân lý.
Thách thức: Chạy Mã Không đáng tin cậy
Nhưng chúng tôi đã gặp một điều hơi kỳ lạ khi chúng tôi nghĩ rằng điều này thật tuyệt vời và chúng tôi khá tự hào về nó. Nhưng các client đã không triển khai nó. Và khi tôi nói client, tôi đang nói theo thuật ngữ MCP, vậy client chính là tác nhân. Vì vậy, từ bây giờ, chúng ta sẽ gọi tác nhân là client.
Vậy các client đã không thực sự triển khai nó. Và chúng tôi hơi bối rối về lý do tại sao lại như vậy. Điều này xảy ra khoảng tám, chín tháng trước. Đây là một cách tốt hơn để tương tác với API – chỉ cần để mô hình viết mã chống lại API. Nhưng họ không triển khai nó. Và tại sao không? Bởi vì chạy mã không đáng tin cậy (untrusted code) là vô cùng, vô cùng đáng sợ.
Nếu vài năm trước tôi nói với bạn: "Ồ, chúng ta sẽ chỉ để một mô hình ngôn ngữ viết một số mã mà chúng ta sẽ thực thi cho người dùng mà không cần xem xét, không cần đọc, không cần biết nó làm gì, có thể có quyền truy cập bí mật (secret access) tiềm ẩn," bạn sẽ nói: "Điều đó thật điên rồ! Đó là một CVE (Lỗ hổng và Phơi nhiễm Chung), phải không? Đó là một CVE! Đó là một lỗ hổng. Đó là một vấn đề." Và bây giờ chúng ta đang đề xuất bạn làm điều này. Vì vậy, nó khá đáng sợ.
Rất nhiều điều có thể xảy ra sai sót. Chúng ta có thể đọc hệ thống tập tin (file system), đọc một số bí mật (secrets) mà bạn không muốn đọc. Nó có thể trích xuất các bí mật đó vào một yêu cầu mạng, chạy các vòng lặp vô hạn (infinite loops), tiêu thụ tất cả tài nguyên của bạn, làm những việc thực sự đáng sợ, chạy một trình đào tiền mã hóa (crypto miner). Điều đó sẽ rất tệ.
Trong quá khứ, mọi người đã thử rất nhiều cách để cho phép chạy các giải pháp giống như mã. Vì vậy, nếu ai đó đã từng viết một DSL (Ngôn ngữ đặc tả miền), một loại đặc tả JSON về cách nội suy nó thành mã, thì đó về cơ bản là cách này. Nếu bạn đã từng sử dụng một trong các phần mềm tích hợp đó, nơi bạn phải làm điều đó, thì đó là cách này. Họ chỉ không tin tưởng bạn viết mã trên máy chủ của họ.
Các máy ảo (VMs) cũng vậy, mọi người đang tạo ra các sandbox để chạy mã. Các sandbox lớn, các VM lớn, đó cũng là cách này. Và cả kiểm tra mã (code review).
Giải pháp An toàn: Vùng cô lập Worker
Nhưng chúng ta khá may mắn, bởi vì chúng ta có một công cụ khá thú vị giải quyết vấn đề này. Và sẽ có những công cụ khác giải quyết vấn đề này. Tôi chỉ nghĩ đây là cái đầu tiên và vì vậy đáng để nói về nó. Và đó là: làm thế nào để bạn chạy mã không đáng tin cậy một cách siêu an toàn cho bạn và cơ sở hạ tầng của bạn?
Nó hoạt động như thế này. Chúng ta có thể thực thi một worker từ một chuỗi. Và một worker chỉ giống như một vùng cô lập (isolate) nhỏ trong V8. Có nhiều blog về cách hoạt động của nó. Tôi sẽ không đi sâu quá chi tiết vào đó. Tôi chỉ sẽ cho bạn thấy nó có thể làm gì.
Ví dụ, chúng ta có đoạn mã được tạo ra này. Và chúng ta sẽ chạy đoạn mã được tạo ra này. Và điều này đã chạy trên backend. Nó không chạy trong trình duyệt của tôi. Nó chạy trong một worker động được cô lập hoàn toàn. Và làm thế nào tôi có thể chứng minh điều đó cho bạn? Nếu chúng ta thực hiện worker này, chúng ta đang cố gắng lấy một số bí mật ở đây, process.env. Và nếu chúng ta in chúng ra, không có bí mật nào cả. Và chúng ta cũng có biến toàn cục Cloudflare kỳ lạ này. Ồ, thú vị.
Nếu chúng ta tắt khả năng tương thích với Node, chúng ta thậm chí không có process.env ở đó. Và tất cả đều lỗi. Vì vậy, chúng ta có một sandbox có thể lập trình được. Nó không hẳn là một sandbox. Nó giống như một thứ rất nhẹ. Bạn có thể đặt mã vào đó và sau đó chạy nó. Và tôi sẽ trình bày một số tùy chọn khác sau.
Môi trường biệt lập có thể lập trình và Hàng rào bảo vệ
Không chỉ riêng chúng tôi có điều này, nhưng chúng tôi có một dịch vụ mà chúng tôi host cho bạn và nó có thể mở rộng đến quy mô của Cloudflare. Nếu bạn muốn thực hiện hàng tỷ yêu cầu, cứ thoải mái. Và bây giờ, đây là một ví dụ mà các tác nhân nằm trong một đoạn mã truy cập Giao diện lập trình ứng dụng bên ngoài. Nếu chúng ta chạy cái này, worker này không được phép truy cập internet thông qua các hàm toàn cục. Chà, có lẽ chúng ta muốn nó truy cập internet. Và bây giờ chúng ta có thể cấp quyền truy cập cho nó. Vì vậy, đó là một sandbox có thể lập trình với hàng rào bảo vệ có thể lập trình. Và tất cả những gì chúng ta đang làm ở đây là bật một giá trị Boolean trên máy chủ. Đó là tất cả những gì đang xảy ra ở đây. Nhưng bạn có thể cung cấp một hàm chuyên sâu hơn để giới hạn việc chỉ truy cập vào các domain nhất định. Và đó là những gì chúng tôi làm trên Cloudflare MCP. Nếu chúng ta chuyển sang phần tiếp theo.
Demo Cloudflare MCP
Ồ, nói về Cloudflare MCP, đây là nơi tôi thực sự hy vọng demo hoạt động. Đây là một MCP client trong slide. Và nếu chúng ta hỏi nó một câu hỏi, chúng ta sẽ nhận được một pop-up toàn màn hình. Và sau đó, hy vọng tất cả những điều này sẽ hoạt động một cách đáng kinh ngạc. Vì vậy, bây giờ chúng tôi đã cấp quyền truy cập toàn bộ Cloudflare API. Tất cả cơ sở hạ tầng Cloudflare của tôi đều có quyền truy cập. Điều đó khá tuyệt. Đừng lo lắng về các ID tài khoản này, chúng không phải là bí mật trong thế giới Cloudflare. Tuyệt vời. Vì vậy, chúng tôi vừa liệt kê một worker.
Nhưng bạn có thể làm nhiều điều hơn thế ở đây. Bạn có thể triển khai worker từ giao diện dòng lệnh của mình. Bạn có thể làm những gì chúng tôi đã làm trước đó và thêm quyền truy cập vào một thứ gì đó. Bạn có thể xem xét DNS của mình. Bạn có thể gửi email sớm. Bạn có thể làm rất nhiều thứ khác. Những gì bạn có thể làm ở đây thực sự rất tuyệt vời. Bởi vì bạn có quyền truy cập vào toàn bộ Cloudflare API, tất cả hơn 2.000 endpoint.
Tương lai của tác nhân và Công cụ bên ngoài: Phát triển mã
Và tôi đoán điều này đặt ra câu hỏi: chúng ta sẽ đi đến đâu khi cho phép các tác nhân truy cập công cụ bên ngoài? Điều này sẽ trông như thế nào? Bạn có những người cài đặt CLI cho mọi thứ. Họ đang chạy nó trên máy của riêng họ, hoặc có thể trên một VM. Điều đó khá hay. Chúng ta lại có những người nói rằng, "Ồ, bạn có thể chạy mã không tin cậy ở một nơi khác thực sự cô lập." Bạn có những người thực hiện tìm kiếm công cụ. Bạn có những người render UI JSON. Tôi không biết.
Và tôi đoán suy nghĩ chính của tôi là chúng ta sẽ có rất nhiều môi trường cô lập trên web. Và sẽ có rất nhiều nguyên tắc hạ tầng cho phép bạn chạy loại mã không tin cậy này trên web. Bởi vì mã thực sự là một kế hoạch rất gọn nhẹ. Thay vì thực hiện các lời gọi công cụ, bạn có thể có một công cụ được gọi là mã, trong đó mô hình tạo ra mã theo lựa chọn của bạn, và sau đó bạn chạy nó. Và mã đó có nhiều mức độ tự do hơn một lời gọi công cụ riêng lẻ. Vì vậy, đối với tôi, điều đó hợp lý khi các mô hình trở nên thông minh hơn, đây là những gì chúng ta sẽ làm. Và mọi người sẽ điều chỉnh các nguyên tắc hạ tầng của họ để làm điều này. Vì vậy, sẽ có nhiều điều như thế này hơn nữa. Và bạn thấy điều này bắt đầu với Pydantic Monte, Dino cũng vậy, và chúng tôi cũng có nó với Workadie, các worker động mà tôi đã trình bày trước đó. Nhiều người hơn sẽ xây dựng các nguyên tắc này bởi vì chúng sẽ ngày càng trở nên hữu ích hơn.
Chuyển đổi sang Chạy mã không đáng tin cậy
Vì vậy, chỉ là một lời giải thích nhỏ. Đây là Workadie, khởi tạo một worker động trong sandbox này và chạy một đoạn mã để lấy một chuỗi fibonacci. Bạn có thể làm điều tương tự với Dino, với Dino run, với một số kiểm tra đáng ngờ. Tôi không biết nó làm gì. Và sau đó bạn cũng có thể làm điều tương tự với Pydantic Monte, sau đó bạn code interpreter để chạy Python không đáng tin cậy. Vì nó là Python, chúng ta phải tải xuống Python. Khó khăn. Điều này có thể không bao giờ hoạt động. Tôi không biết. Ồ, đây rồi. Tuyệt vời.
Vì vậy, có lẽ bạn có thể thấy hướng chúng ta đang đi. Đã có một thời gian trước đây không ai dám chạy mã không đáng tin cậy. Đó là một lỗ hổng CV. Bạn sẽ ngay lập tức phải ngăn chặn điều đó. Và sau đó, dường như đối với các Mô hình ngôn ngữ lớn, việc chúng tạo ra mã mà bạn có thể chạy thực sự rất tốt. Và vì vậy bây giờ chúng ta đang xây dựng các nguyên tắc để thực sự cho phép chúng ta làm điều đó. Và có vẻ như chúng ta đã bỏ lỡ toàn bộ phần này của lĩnh vực công nghệ mà chúng ta chưa từng thử trước đây. Vào những năm 1950, khi bạn muốn chạy một cái gì đó trên máy tính ở thị trấn của mình, bạn in ra một số thẻ đục lỗ, và bạn đóng dấu chúng, và bạn đưa chúng cho người điều khiển. Và đó cũng giống như chạy mã không đáng tin cậy, phải không? Đó là như vậy. Và sau đó khi chúng ta chuyển sang điện toán đám mây, chúng ta đã rời xa điều đó. Và bây giờ tôi nghĩ chúng ta sẽ quay trở lại điều đó nhiều hơn, nơi người dùng của bạn có thể viết mã, bởi vì người dùng của bạn là AI. Và AI rất giỏi trong việc viết mã. Và đó là cách họ sẽ tương tác với nền tảng của bạn, dù thông qua MCP, dù thông qua bash và CLI, tôi không bận tâm. Tôi nghĩ họ sẽ chỉ viết mã chống lại các dịch vụ của bạn. Và các dịch vụ của bạn phải sẵn sàng cho điều này. Các Giao diện lập trình ứng dụng của bạn phải sẵn sàng chịu đựng, bởi vì chúng phải có giới hạn tốc độ tốt. Bởi vì tôi có thể chạy điều này trong một vòng lặp đầy đủ trên nhiều sandbox cùng một lúc, và chỉ tấn công Giao diện lập trình ứng dụng của bạn. Bạn phải có cách nào đó để bảo vệ điều đó. Đây là thế giới mới mà chúng ta sẽ sống.
Đổi mới phía máy khách
Và đó là về phía máy chủ, về phía các dịch vụ. Vậy điều gì sẽ xảy ra ở phía máy khách? Vì vậy, tôi nghĩ điều đó thậm chí còn thú vị hơn, bởi vì đó là phía đối diện người dùng. Nhưng người dùng sẽ không nhìn thấy máy chủ. Người dùng không quan tâm. Người dùng chỉ quan tâm tại sao tác nhân của tôi không nhận được email Gmail của tôi? Hoặc tại sao nó lại xóa toàn bộ hộp thư đến của tôi? Họ sẽ không thấy điều đó. Nhưng ở phía máy khách, sẽ có rất nhiều đổi mới. Và tôi nghĩ chúng ta đã chững lại một chút gần đây, bởi vì việc xây dựng một MCP client nói riêng trở nên thực sự rất khó để xây dựng một client hiệu suất và hoạt động tốt. Bạn cần quản lý các kết nối có trạng thái. Bạn cần quản lý khả năng tiếp tục giữa các kết nối đó. Có rất nhiều lý do khác khiến việc xây dựng MCP client trở nên khó khăn, nhưng đó là một nỗi đau, một nỗi đau tuyệt đối.
Và vì vậy, mọi người có các client được lược bỏ nhiều nhất có thể. Họ chủ yếu offload sang các SDK MCP, khá tối thiểu. Và không ai xây dựng những trải nghiệm UI độc đáo hơn trên đó. Và tôi nghĩ điều đó sẽ đến rất, rất sớm. Vì vậy, điều hiển nhiên nhất là chúng ta sẽ có lời gọi công cụ có thể lập trình trong các client. Slide trước chúng ta vừa thực hiện cho thấy những sandbox đó với Workadie, Dino và Pynantic. Đó chỉ là chạy mã không đáng tin cậy trong một client. Mọi người sẽ làm điều đó. Nếu client của bạn là remote, bạn sẽ làm điều đó theo cách đó. Nếu client của bạn là local, thì cứ yo-lo nó, dù sao đi nữa. Chỉ cần eval nó. Sẽ ổn thôi. Nhưng nhiều người hơn sẽ thực hiện lời gọi công cụ có thể lập trình này. Nó sẽ xảy ra.
Và bởi vì bạn đang tạo mã, mọi người sẽ lưu mã này. Và họ sẽ lưu nó trong các mini script này. Và người dùng có thể quyết định, hành động tôi vừa thực hiện, mà Mô hình ngôn ngữ lớn đã tạo ra cho tôi, tôi muốn giữ nó lại để sử dụng sau. Và sau đó nó sẽ nhanh hơn nhiều. Vì vậy, bạn có thể thấy những thứ như Chrome jobs, một người dùng có thể thiết lập một web scraping job, mà không cần bất kỳ kiến thức nào về cách web scraping hoạt động. Và sau đó nó tạo ra một script. Và script đó được chạy hàng ngày, hai ngày một lần. Và bất cứ khi nào nó bị hỏng, bởi vì web scraping khá dễ vỡ, tác nhân sẽ sửa nó và lưu lại script. Điều này sẽ xảy ra. Và tôi nghĩ những mini script đã lưu này. Chúng chỉ hoạt động khi bạn áp dụng lời gọi công cụ có thể lập trình, nhưng chúng thực sự hiệu quả.
Và điều cuối cùng là chúng ta có lẽ sẽ có nhiều client hơn nữa, bởi vì cho đến nay chúng rất khó tạo, và nó sẽ trở nên dễ dàng hơn. Thực tế chỉ có, không có một lượng lớn MCP client được sử dụng rộng rãi. Điều đó sẽ thay đổi. Và với sự thay đổi đó, nhiều người hơn sẽ có thể tạo, nhiều người hơn sẽ triển khai tác nhân lên đám mây mà cuối cùng trở thành MCP client. Và tôi nghĩ nhiều người hơn sẽ cố gắng thực hiện điều vòng lặp tác nhân không trạng thái này. Sẽ ổn thôi khi có sandbox cho mỗi tác nhân chạy mã cục bộ, nếu có một triệu tác nhân trên thế giới này. Tôi nghĩ khi có 100 tác nhân cho mỗi người, ồ, xin chào. Đừng làm vậy. Điều đó sẽ bắt đầu trở nên thực sự khó khăn. Và bạn sẽ phải áp dụng một cách tiếp cận đám mây bản địa để thực hiện mọi thứ, điều đó có nghĩa là trạng thái phải là thứ bạn có thể bật hoặc tắt.
Sự phát triển của MCP và SDK
Và đây, tôi nghĩ, chúng ta đang gần kết thúc. Nhưng đây là điều cuối cùng của tôi. Giống như, tôi làm việc rất nhiều trên máy chủ MCP và trên SDK. Và đây là nơi tôi nghĩ phần đó sẽ đi đến đâu. Tôi nghĩ chúng ta sẽ thấy MCP như một middleware trong một máy chủ MCP khi bạn xây dựng một dịch vụ API. Nó sẽ là một flag mà bạn có thể bật trong framework yêu thích của mình. SDK bản thân nó đang trở nên siêu nhẹ. Và tôi nghĩ vào cuối năm nay, nó sẽ được tích hợp gốc trong mọi framework full-stack lớn, ít nhất là TypeScript. Nó sẽ có mặt một cách tự nhiên. Bởi vì nó sẽ rất nhỏ, nó sẽ chỉ đơn thuần thể hiện giao thức trong chính nó. Và sẽ thật ngớ ngẩn nếu họ không có nó. Họ sẽ chỉ có một tích hợp gốc. Và họ sẽ có thể làm cho MCP là true trên tất cả các Giao diện lập trình ứng dụng của bạn. Và bởi vì tất cả các client sẽ thực hiện lời gọi công cụ có thể lập trình, bạn có thể thể hiện 1000 Giao diện lập trình ứng dụng của mình từ một ứng dụng Next.js và chỉ cần đặt MCP là true và hiển thị nhiều công cụ hơn thông qua MCP nữa. Và tôi nghĩ điều đó sẽ xảy ra. Ý tôi là, tôi nghĩ điều đó sẽ xảy ra trong một thời gian, nhưng tôi nghĩ chúng ta đã thực sự gần rồi. Và rào cản cuối cùng là thực sự sửa SDK để nó có khả năng làm điều đó. Nó có khả năng phù hợp với mọi bundle, thực sự. Và đó là kế hoạch.
Tài nguyên và Lời cảm ơn
Bạn có thể tìm hiểu thêm. Chúng tôi có một bài đăng trên blog Code Mode vừa ra mắt gần đây. Đó là cách chúng tôi cung cấp cho các tác nhân toàn bộ API trong 1000 mã thông báo. Nếu bạn có một API lớn, bạn nên làm điều này. Và các nhà cung cấp khả năng tiếp cận làm ơn hãy làm điều này. Bởi vì việc mọi người truy cập dữ liệu của bạn thực sự rất tốt. Và xin cảm ơn. Hãy dùng thử. NPMI agents. Cảm ơn rất nhiều.