CubeSandbox cho AI Agent là gì? Giải thích về cách ly

Nếu tác nhân AI của bạn có thể viết mã, nó có thể viết mã tồi. Nếu nó có thể gọi các công cụ, nó có thể gọi sai công cụ với sai đối số. Cách khắc phục không phải là một lời nhắc thông minh hơn. Đó là một ranh giới cách ly giữa đầu ra của mô hình và máy chạy nó. CubeSandbox là một trong những hệ thống được xây dựng chính xác cho ranh giới đó, và đáng để tìm hiểu nó làm gì, nó so sánh với các phương pháp khác như thế nào, và nó phù hợp ở đâu khi các tác nhân của bạn bắt đầu chạm vào các API và dữ liệu thực.

TL;DR

CubeSandbox là một dịch vụ sandbox mã nguồn mở, cách ly phần cứng từ Tencent Cloud để chạy mã tác nhân AI. Mỗi sandbox có nhân hệ điều hành khách (guest OS kernel) riêng thông qua KVM, khởi động trong khoảng 60ms và sử dụng dưới 5MB bộ nhớ phụ. Nó được cấp phép theo Apache 2.0 và tương thích hoàn toàn với E2B SDK.

Giới thiệu

Các hệ thống tác nhân hiện đang viết và thực thi mã trong môi trường sản xuất. Một tác nhân viết mã tạo ra một tập lệnh Python và chạy nó. Một tác nhân nghiên cứu cào một trang web, phân tích nó và chuyển kết quả sang bước tiếp theo. Một tác nhân dữ liệu tải một tệp CSV và thực hiện các chuyển đổi mà mô hình đã quyết định trong thời gian chạy. Không có mã nào trong số đó được con người xem xét trước khi nó chạy. Đó là vấn đề cốt lõi mà việc sandboxing tác nhân giải quyết: bạn cần thực thi các hướng dẫn không đáng tin cậy, do mô hình tạo ra mà không cấp cho chúng quyền truy cập vào máy chủ của bạn, hệ thống tệp của bạn, thông tin xác thực của bạn hoặc mạng của bạn.

Điều này càng quan trọng hơn khi các tác nhân có quyền tự chủ. Một mô hình sai về một truy vấn SQL thì gây khó chịu. Một mô hình sai về rm -rf hoặc tuân theo một hướng dẫn đã được chèn vào bên trong một trang web đã cào là một sự cố bảo mật. Sandboxing vạch ra một ranh giới rõ ràng: tác nhân có thể làm bất cứ điều gì nó muốn bên trong một môi trường cách ly, có thể hủy bỏ, và không có gì nó làm rò rỉ ra ngoài.

Có một vấn đề thứ hai, ít ồn ào hơn. Các tác nhân không chỉ chạy mã; chúng còn gọi các API và công cụ. Trước khi bạn tin tưởng một tác nhân để truy cập API thanh toán hoặc các dịch vụ nội bộ của bạn từ bên trong một sandbox, bạn cần biết các API đó hoạt động chính xác và tác nhân gọi chúng theo cách bạn mong đợi. Đó là nơi các công cụ API chứng tỏ giá trị của mình bên cạnh việc cách ly thời gian chạy. Một nền tảng như Apidog cho phép bạn mô phỏng và kiểm tra các điểm cuối mà tác nhân sẽ gọi, để bạn xác thực hợp đồng trước khi một hệ thống tự động bắt đầu điều khiển nó trong một lần chạy được sandboxing. Nếu bạn đã suy nghĩ về kiến trúc tác nhân, hướng dẫn của chúng tôi về kiến trúc AI tác nhân sẽ đề cập đến cách các lớp thực thi và công cụ này kết hợp với nhau.

Phần còn lại của bài viết này giải thích CubeSandbox là gì, tại sao các tác nhân cần một sandbox, các mô hình cách ly khác nhau như thế nào, và cách điều này liên quan đến việc kiểm tra các API mà các tác nhân của bạn phụ thuộc vào.

CubeSandbox là gì?

CubeSandbox là một hệ thống sandbox bảo mật để chạy mã tác nhân AI, được Tencent Cloud mở nguồn theo giấy phép Apache 2.0 vào tháng 4 năm 2026. Slogan trên GitHub của nó mô tả rõ ràng: “Sandbox tức thì, đồng thời, bảo mật & nhẹ cho tác nhân AI.” Nó không chỉ là một SDK. Nó là một ngăn xếp sandbox-as-a-service hoàn chỉnh, chủ yếu được viết bằng Rust, mà bạn có thể tự triển khai.

Kiến trúc được xây dựng trên RustVMM và KVM, cùng lớp ảo hóa nhân Linux được nhiều hypervisor đám mây sử dụng. Theo tài liệu dự án và thông báo chính thức, hệ thống được chia thành nhiều thành phần:

• CubeAPI: một cổng REST mô phỏng giao diện sandbox E2B.
• CubeMaster: bộ điều phối cụm (cluster orchestrator) lên lịch các sandbox trên các nút (nodes).
• CubeHypervisor và CubeShim: lớp ảo hóa KVM khởi động và quản lý từng microVM.
• Cubelet và CubeProxy: các tác nhân cấp nút (node-level agents) chạy và định tuyến đến các sandbox.
• CubeVS: một lớp mạng hỗ trợ eBPF thực thi cách ly mạng giữa các sandbox ở cấp độ nhân (kernel level).

Đặc điểm nổi bật là mỗi sandbox có nhân hệ điều hành khách chuyên dụng riêng. Đó là một mô hình cách ly khác và mạnh hơn so với container, vốn chia sẻ nhân hệ điều hành của máy chủ. Các số liệu được Tencent công bố cho biết thời gian khởi động nguội (cold start) khoảng 60ms ở mức đồng thời đơn (trung bình 67ms với P95 khoảng 90ms khi tạo 50 phiên bản đồng thời), dưới 5MB bộ nhớ phụ mỗi phiên bản, và khả năng chạy hàng nghìn sandbox trên một máy chủ lớn duy nhất. Các tài liệu báo chí trích dẫn một máy chủ 96 vCPU hỗ trợ hơn 2.000 sandbox đồng thời. Tencent cho biết CubeSandbox đã chạy ở quy mô lớn trong cơ sở hạ tầng của họ và MiniMax đã sử dụng nó để đào tạo học tăng cường tác nhân quy mô lớn trên các môi trường không đồng nhất.

Một số tính năng nâng cao, như rollback snapshot cấp sự kiện để tạo điểm kiểm tra và khôi phục trạng thái sandbox, được mô tả là vẫn đang trong quá trình phát triển. Hãy coi các mục hướng tới tương lai là lộ trình, không phải đảm bảo đã được phát hành, và kiểm tra kho lưu trữ để biết trạng thái hiện tại. Phương pháp đo điểm chuẩn công khai ngoài các số liệu của nhà cung cấp là có hạn, vì vậy hãy xác thực các tuyên bố về hiệu suất so với khối lượng công việc của riêng bạn.

Để biết thông tin chi tiết chính xác, nguồn đáng tin cậy là kho lưu trữ GitHub của CubeSandbox và trang tài liệu chính thức.

Tại sao tác nhân AI cần một sandbox

Việc cụ thể hóa các mối đe dọa sẽ giúp ích, vì “bảo mật” quá mơ hồ để thiết kế chống lại. Có ba chế độ lỗi đẩy các nhóm đến việc sử dụng sandboxing.

Mã được tạo rủi ro. Một mô hình tạo ra mã mà nó tin là đúng. Đôi khi không phải vậy. Nó xóa sai thư mục, làm cạn kiệt bộ nhớ trong một vòng lặp chặt chẽ, hoặc ghi một tệp vào nơi không nên. Không có điều nào trong số này là độc hại; nó chỉ sai, và mã sai có quyền truy cập máy chủ thì nguy hiểm. Tác nhân không có khái niệm về phạm vi thiệt hại trừ khi bạn cung cấp cho nó.

Cuộc gọi công cụ không đáng tin cậy. Các tác nhân gọi công cụ và API dựa trên những gì mô hình quyết định trong thời gian chạy. Nếu mô hình bị điều khiển bởi một kỹ thuật tấn công prompt injection ẩn trong tài liệu, trang web, hoặc phản hồi của công cụ, nó có thể gọi một công cụ phá hủy, truyền các đối số do kẻ tấn công kiểm soát, hoặc chuỗi các cuộc gọi theo cách bạn không bao giờ dự định. Mô hình không phải là một tác nhân đáng tin cậy ở đây; nó là một trình thông dịch cho bất kỳ văn bản nào đến cửa sổ ngữ cảnh của nó. Chúng tôi đi sâu hơn về vấn đề này trong bài viết của mình về tác nhân AI như những người tiêu dùng API mới, bao gồm lý do tại sao các giả định tin cậy API truyền thống bị phá vỡ với các trình gọi tự động.

Rò rỉ dữ liệu (Data exfiltration). Đây là điều mà mọi người đánh giá thấp. Một tác nhân có quyền truy cập mạng và truy cập vào các bí mật có thể biến thành một kênh rò rỉ dữ liệu. Một hướng dẫn bị nhiễm độc sẽ yêu cầu tác nhân đọc biến môi trường chứa khóa API và gửi nó (POST) đến một điểm cuối bên ngoài. Nếu không có lọc egress và cách ly thông tin xác thực, ranh giới sandbox trở nên vô nghĩa vì dữ liệu sẽ thoát ra ngoài. Đây là lý do tại sao CubeSandbox kết hợp cách ly cấp độ nhân với lọc egress dựa trên eBPF thông qua CubeVS; cách ly tiến trình là không đủ nếu mạng mở rộng.

Điểm chung: bạn không thể giả định rằng tác nhân sẽ hoạt động đúng, bởi vì hành vi của tác nhân một phần bị kiểm soát bởi bất kỳ dữ liệu không đáng tin cậy nào mà nó đã tiếp nhận. Một sandbox cho phép bạn ngừng suy luận về việc mô hình có đáng tin cậy hay không và bắt đầu suy luận về một ranh giới vẫn được duy trì. Để có cái nhìn thực tế về việc kiểm tra các hành vi này trước khi chúng đến môi trường sản xuất, hãy xem cách kiểm tra tác nhân AI gọi API.

Cách thức hoạt động của các sandbox tác nhân: các mô hình cách ly

Không phải tất cả các sandbox đều cách ly theo cùng một cách, và sự khác biệt này quan trọng đối với cả bảo mật và hiệu suất. Có bốn phương pháp tiếp cận chính mà bạn sẽ thấy trong hệ sinh thái tác nhân.

Cách ly cấp độ tiến trình (Process-level isolation). Chạy mã như một tiến trình hệ điều hành bị hạn chế với bộ lọc seccomp, các quyền bị loại bỏ, không gian tên (namespaces) và cgroups. Đây là tùy chọn nhẹ nhất và yếu nhất. Nó chia sẻ nhân hệ điều hành của máy chủ, vì vậy một lỗ hổng khai thác nhân có nghĩa là một sự xâm nhập máy chủ. Tốt cho mã bạn phần lớn tin tưởng; yếu cho đầu ra mô hình tùy ý.

Container. Các container kiểu Docker thêm không gian tên và giới hạn tài nguyên, và quen thuộc về mặt vận hành. Nhưng các container được thiết kế để chia sẻ nhân hệ điều hành của máy chủ. Các lỗ hổng thoát container là một loại lỗi thực tế và tái diễn, và "mã không đáng tin cậy trong container dùng chung nhân" là một điểm yếu đã biết. Nhiều nhóm bắt đầu ở đây vì nó dễ dàng, sau đó gặp phải giới hạn về cách ly.

MicroVM. Một microVM khởi động một nhân hệ điều hành khách tối thiểu bên trong ảo hóa phần cứng (KVM). Mã của tác nhân chạy trên nhân của riêng nó, vì vậy một lỗ hổng khai thác cấp độ nhân sẽ được giới hạn trong một VM dùng một lần, không phải máy chủ. Firecracker đã phổ biến mô hình này cho các khối lượng công việc phi máy chủ, và CubeSandbox nằm trong danh mục này, sử dụng RustVMM và KVM với một nhân hệ điều hành khách cho mỗi sandbox. Sự đánh đổi trong quá khứ là thời gian khởi động; microVM chậm hơn trong việc khởi động so với container. Các triển khai hiện đại giải quyết vấn đề đó bằng cách chụp ảnh nhanh (snapshotting) và cấp phát tài nguyên trước, đó là cách CubeSandbox báo cáo thời gian khởi động dưới 100ms.

Nhân ứng dụng (Application kernels). gVisor đi theo một con đường khác: nó chặn các cuộc gọi hệ thống trong không gian người dùng và tự triển khai một giao diện giống Linux, vì vậy khối lượng công việc không bao giờ nói chuyện trực tiếp với nhân máy chủ. Đó là một lớp cách ly mạnh mẽ mà không cần một VM đầy đủ, với một số sự đánh đổi về khả năng tương thích syscall và hiệu suất.

Đây là cách các phương pháp tiếp cận so sánh qua các khía cạnh quan trọng đối với tác nhân:

Không có một giải pháp chiến thắng duy nhất. Lựa chọn phù hợp phụ thuộc vào mức độ bạn tin tưởng mã, bạn cần thời gian khởi động nguội nhanh đến mức nào, liệu bạn có thể chạy KVM hay không, và liệu bạn muốn tự vận hành cơ sở hạ tầng hay sử dụng nó như một dịch vụ.

CubeSandbox trong bối cảnh chung

Vị trí của CubeSandbox rất cụ thể: cách ly cấp độ phần cứng với thời gian khởi động nguội đủ nhanh để cảm giác như một container, được triển khai như một thứ bạn tự chạy hơn là một dịch vụ bạn thuê. Điều đó đặt nó vào sự so sánh trực tiếp về mặt khái niệm với ba điểm tham chiếu.

• So với container. Một container chia sẻ nhân máy chủ; CubeSandbox cung cấp nhân riêng cho mỗi sandbox. Đối với mã tác nhân được tạo tùy ý, đó là lập luận về bảo mật. Chi phí là bạn cần một máy chủ Linux x86_64 hỗ trợ KVM (một máy chủ bare-metal, một máy ảo đám mây hỗ trợ ảo hóa lồng nhau, hoặc WSL 2 cho công việc cục bộ). Nếu nền tảng của bạn không thể hiển thị KVM, cách ly dựa trên microVM không khả dụng cho bạn và một phương pháp không gian người dùng như gVisor hoặc API được lưu trữ có thể phù hợp hơn.
• So với Firecracker. Firecracker là microVM nổi tiếng cho các ứng dụng phi máy chủ và bản thân nó là một khối xây dựng, không phải là một sản phẩm sandbox tác nhân. CubeSandbox cũng dựa trên KVM/RustVMM nhưng được đóng gói ở tầng cao hơn: một bộ điều phối, một cổng API tương thích E2B, và cách ly mạng eBPF, vì vậy bạn đang triển khai một dịch vụ sandbox tác nhân chứ không phải lắp ráp một cái. Nếu bạn muốn các thành phần cơ bản, hãy dùng Firecracker. Nếu bạn muốn một dịch vụ sandbox với API định dạng tác nhân, CubeSandbox nhắm đến điều đó.
• So với E2B và các sandbox được lưu trữ. E2B cung cấp các sandbox cách ly như một dịch vụ được quản lý; bạn gọi một API và cơ sở hạ tầng là vấn đề của người khác. Lựa chọn thiết kế đáng chú ý của CubeSandbox là khả năng tương thích với E2B SDK. Tài liệu mô tả nó như một giải pháp thay thế trực tiếp: trỏ E2B_API_URL đến phiên bản Cube tự lưu trữ của bạn và mã hiện có vẫn hoạt động. Điều đó làm cho quyết định thực sự ít hơn là "sandbox nào" mà là "dịch vụ được quản lý so với cơ sở hạ tầng tự lưu trữ", với quyền cư trú dữ liệu, chi phí ở quy mô lớn, và quyền sở hữu vận hành là các yếu tố quyết định. Nó cũng hỗ trợ nguyên bản OpenAI Python SDK theo thông báo của Tencent.

Tóm tắt trung thực: CubeSandbox là một giải pháp đáng tin cậy trong không gian sandbox tác nhân với một luận điểm rõ ràng (cách ly mạnh mẽ, khởi động nhanh, tự lưu trữ, tương thích E2B). Nó cũng mới và chủ yếu được nhà cung cấp của nó tài liệu hóa, vì vậy các điểm chuẩn độc lập còn ít. Hãy tạo nguyên mẫu nó với khối lượng công việc của bạn và đo lường thời gian khởi động nguội, mật độ và hành vi cách ly trước khi cam kết.

Điều này liên quan đến việc kiểm tra các API và công cụ mà tác nhân của bạn gọi như thế nào

Cách ly thời gian chạy trả lời cho câu hỏi “điều gì sẽ xảy ra nếu mã tồi.” Nó không trả lời “điều gì sẽ xảy ra nếu API mà tác nhân gọi là tồi, hoặc tác nhân gọi sai.” Đó là những vấn đề khác nhau, và bạn cần giải quyết cả hai.

Hãy hình dung một tác nhân được sandboxing đặt chuyến du lịch. Mã chạy an toàn bên trong CubeSandbox. Nhưng tác nhân vẫn gọi API chuyến bay, API thanh toán và dịch vụ lịch trình nội bộ. Nếu bất kỳ API nào trả về một phản hồi bị định dạng sai, tác nhân có thể lặp, tạo ra một giải pháp phục hồi ảo, hoặc truyền dữ liệu xấu xuống dòng. Nếu nó gọi API thanh toán với khóa idempotency sai, việc cách ly sẽ không cứu bạn; tiền vẫn được chuyển. Sandbox bảo vệ máy chủ khỏi tác nhân. Nó không bảo vệ hệ thống của bạn khỏi một tác nhân bối rối thực hiện các cuộc gọi thực tế đến các dịch vụ thực.

Vì vậy, quy trình làm việc thực sự hiệu quả có hai lớp hoạt động cùng nhau:

1. Cách ly thực thi để mã do mô hình tạo ra và các lệnh gọi công cụ không thể gây hại cho máy chủ hoặc làm rò rỉ dữ liệu. Đó là lớp CubeSandbox.
2. Xác thực hợp đồng của mọi API và công cụ mà tác nhân có thể truy cập, trước và trong các lần chạy được sandboxing. Đó là lớp công cụ API.

Đối với lớp thứ hai, hãy mô phỏng các phụ thuộc để tác nhân nói chuyện với một đối tượng thay thế được kiểm soát khi bạn đang kiểm tra hành vi, sau đó kiểm tra các điểm cuối thực tế về sự phù hợp lược đồ, xử lý lỗi, xác thực và các trường hợp biên. Với Apidog, bạn có thể xây dựng một máy chủ giả lập trả về các phản hồi xác định, chính xác theo lược đồ, trỏ tác nhân được sandboxing vào đó và xem cách tác nhân phản ứng với cả đường dẫn thành công và thất bại mà không ảnh hưởng đến môi trường sản xuất. Khi bạn đã sẵn sàng, hãy chạy các kịch bản tương tự đối với API thực để xác nhận hợp đồng được duy trì. Hướng dẫn của chúng tôi về kiểm thử sandbox bao gồm thực hành chung về kiểm thử trong môi trường cách ly, được kiểm soát, điều này áp dụng trực tiếp ở đây.

Sự kết hợp này quan trọng vì các tác nhân làm khuếch đại sự sai lệch hợp đồng. Một con người sẽ nhận thấy khi một phản hồi API có vẻ không đúng. Một tác nhân thường thì không; nó tiếp nhận phản hồi và hành động theo nó. Các hợp đồng API chặt chẽ, được thực hiện với các mock và kiểm thử, ngăn chặn một trình gọi tự động biến một phản hồi tồi thành một chuỗi lỗi liên hoàn. Nếu các tác nhân của bạn nói Model Context Protocol, kiểm thử máy chủ MCP với Apidog sẽ mở rộng nguyên tắc tương tự cho lớp công cụ. Và nếu bạn đang thiết kế API cho người tiêu dùng tác nhân, thiết kế API cho tác nhân AI bao gồm các mẫu hợp đồng giúp các cuộc gọi tự động trở nên dễ đoán.

Các trường hợp sử dụng trong thế giới thực

Một vài mẫu nơi phương pháp tiếp cận cách ly cộng với hợp đồng thể hiện giá trị của nó:

• Các tác nhân viết mã và trình thông dịch mã. Một mô hình viết và chạy mã để trả lời câu hỏi, chuyển đổi dữ liệu hoặc tạo biểu đồ. Đây là trường hợp sử dụng sandbox điển hình và là mục tiêu trực tiếp của các API tương thích E2B. Nhân riêng cho mỗi sandbox của CubeSandbox quan trọng ở đây vì mã hoàn toàn tùy ý và thay đổi theo mỗi lần chạy.
• Các nền tảng tác nhân đa người thuê (multi-tenant). Nếu tác nhân của nhiều khách hàng thực thi mã trên cơ sở hạ tầng dùng chung, việc cách ly cấp độ container giữa các người thuê là rủi ro. Cách ly phần cứng cho mỗi sandbox mang lại cho bạn một ranh giới người thuê vẫn được duy trì ngay cả khi tác nhân của một người thuê là độc hại. Mật độ được báo cáo (hàng nghìn sandbox trên mỗi máy chủ) là điều làm cho điều đó khả thi thay vì một VM cho mỗi người thuê.
• RL tác nhân và các vòng lặp đào tạo. Đào tạo các tác nhân bằng học tăng cường (reinforcement learning) có nghĩa là chạy số lượng lớn các lần triển khai (rollouts) ngắn hạn, không đáng tin cậy. Tencent trích dẫn MiniMax sử dụng CubeSandbox cho chính điều này trên các môi trường không đồng nhất. Thời gian khởi động nguội nhanh và chi phí phụ mỗi phiên bản thấp là sự khác biệt giữa một lần đào tạo khả thi và một lần không khả thi.
• Các tác nhân nghiên cứu và dữ liệu sử dụng công cụ. Một tác nhân lấy nội dung bên ngoài, phân tích nó và gọi các API hạ nguồn. Nội dung được lấy là không đáng tin cậy (nguy cơ tấn công prompt injection), vì vậy việc phân tích và mã được tạo phải nằm trong một sandbox, trong khi các API hạ nguồn nên được kiểm tra bằng mock trước tiên. Đây là nơi việc kết hợp cách ly với kiểm thử hợp đồng API mang lại hiệu quả cao nhất.
• Thực thi plugin hoặc tiện ích mở rộng không đáng tin cậy. Nếu người dùng có thể cung cấp công cụ hoặc mã mà tác nhân của bạn chạy, theo định nghĩa, bạn đang thực thi mã bên thứ ba không đáng tin cậy. Một ranh giới microVM cho mỗi lần thực thi là tư thế phù hợp, cùng lý do mà các nền tảng phi máy chủ đã sử dụng khi áp dụng Firecracker.

Kết luận

Việc sandboxing tác nhân không còn là tùy chọn kể từ khi các tác nhân bắt đầu thực thi mã và gọi công cụ mà không có sự xem xét của con người. CubeSandbox là một câu trả lời cụ thể, mở cho một nửa vấn đề về cách ly đó.

• CubeSandbox là có thật và cụ thể: Sandbox mã nguồn mở Apache 2.0 của Tencent Cloud dành cho tác nhân AI, được xây dựng trên RustVMM và KVM, với nhân khách riêng cho mỗi sandbox.
• Mô hình cách ly là trọng tâm: một nhân chuyên dụng cho mỗi sandbox mạnh hơn cách ly container đối với mã do mô hình tạo tùy ý, với thời gian khởi động nguội được báo cáo dưới 100ms và chi phí phụ dưới 5MB.
• Khả năng tương thích E2B giảm chi phí chuyển đổi: nếu bạn đang sử dụng E2B, đường dẫn thay thế trực tiếp được ghi trong tài liệu định hình lại lựa chọn là dịch vụ được quản lý so với tự lưu trữ, chứ không phải viết lại mã.
• Hãy coi số liệu của nhà cung cấp là điểm khởi đầu: các tuyên bố về hiệu suất và mật độ phần lớn đến từ Tencent; hãy đo điểm chuẩn với khối lượng công việc của riêng bạn, và kiểm tra kho lưu trữ để biết các tính năng nào đã được phát hành so với đang trong quá trình phát triển.
• Cách ly là cần thiết nhưng chưa đủ: một sandbox bảo vệ máy chủ của bạn khỏi tác nhân; nó không bảo vệ các API của bạn khỏi một tác nhân bối rối gọi chúng.
• Kết hợp cách ly thời gian chạy với kiểm thử hợp đồng API: mô phỏng và kiểm tra mọi điểm cuối mà tác nhân có thể truy cập để một phản hồi tồi không gây ra lỗi liên hoàn.

Nếu các tác nhân của bạn gọi các API mà bạn sở hữu hoặc phụ thuộc vào, hãy thiết lập lớp hợp đồng cùng với lớp cách ly. Tải xuống Apidog để mô phỏng các dịch vụ mà các tác nhân được sandboxing của bạn truy cập và kiểm tra chúng về lược đồ, xác thực và hành vi lỗi trước khi một hệ thống tự động điều khiển chúng trong môi trường sản xuất.