Microsoft Copilot harness lên Foundry: xây AI agent đa mô hình

Đội phát triển agent thường bắt đầu bằng một vòng lặp đơn giản: gửi yêu cầu cho mô hình, nhận lệnh gọi công cụ rồi trả kết quả. Khi hệ thống phải đổi giữa nhiều mô hình, giữ ngữ cảnh, chạy mã an toàn và theo dõi chi phí, phần bao quanh mô hình mới là nơi phát sinh nhiều lỗi. Microsoft gọi lớp đó là harness.

Microsoft đăng thông báo ngày 28/10/2026 và cùng ngày đưa Copilot harness vào Foundry Agent Service ở trạng thái public preview. Theo bài chính thức, đây là nền tảng điều phối vốn được GitHub xây dựng và hiện dùng trong nhiều sản phẩm Copilot.

Harness là gì?

Nếu mô hình là phần suy luận, harness là hệ thống cung cấp chỉ dẫn, ngữ cảnh, công cụ, môi trường thực thi và chính sách. Nó quản lý vòng lặp agent, quyết định dữ liệu nào đưa vào, khi nào gọi công cụ, cách giới hạn quyền và cách ghi lại hành trình. Một harness tốt không làm mô hình thông minh hơn theo nghĩa huấn luyện, nhưng có thể làm tác vụ ổn định và kiểm soát được hơn.

Microsoft cho biết harness hỗ trợ hơn 20 mô hình cùng khả năng dùng khóa truy cập riêng, tiêu chuẩn MCP, agent skills và plugin. Runtime được chuyển sang Rust, với mục tiêu giảm overhead phiên và thời gian tới token đầu tiên. Hãng không công bố bộ số liệu đầy đủ trong bài, vì vậy doanh nghiệp nên coi đây là mô tả sản phẩm chứ không phải benchmark độc lập.

Điều doanh nghiệp cần kiểm tra trong public preview

• Định tuyến mô hình: quy tắc nào chọn mô hình, có thể khóa phiên bản hay không và cách xử lý khi mô hình lỗi.
• Sandbox: mã do agent tạo chạy ở đâu, có mạng hay không, giới hạn CPU/RAM/thời gian và cách xóa dữ liệu.
• Quan sát: có log prompt, công cụ, token, lỗi và thời gian từng bước mà không làm lộ dữ liệu nhạy cảm hay không.
• Chi phí: định tuyến tự động có giảm tổng chi phí trên tác vụ hoàn tất hay chỉ chuyển tải sang mô hình khác.
• Khả năng rời nền tảng: dữ liệu phiên, skills và MCP server có thể mang sang harness khác ở mức nào.

Tác động đến hạ tầng inference

Agent đa mô hình tạo tải không đều: một yêu cầu có thể gọi nhiều mô hình, thực thi mã, truy xuất vector và chờ API ngoài. Máy chủ GPU cần xử lý burst, còn CPU và bộ nhớ phải giữ nhiều phiên. Vì vậy, dự báo chỉ từ số người dùng đồng thời thường thiếu; nên đo số lần gọi mô hình trên một tác vụ, độ dài ngữ cảnh sau mỗi vòng và tỷ lệ thời gian chờ công cụ.

Doanh nghiệp Việt Nam cũng cần xem vị trí xử lý dữ liệu, luồng ra Internet và hợp đồng với từng nhà cung cấp mô hình. Một harness thống nhất giao diện không tự động thống nhất điều khoản dữ liệu của mọi mô hình phía sau.

Bộ thử nghiệm nên có

1. Chọn 30–50 tác vụ đại diện, gồm cả tình huống thiếu dữ liệu, công cụ lỗi và yêu cầu vượt quyền.
2. Đặt tiêu chí hoàn thành, số bước tối đa, ngân sách token, thời gian p95 và tỷ lệ phải có người can thiệp.
3. Chạy cùng bộ tác vụ với định tuyến cố định và tự động; so chất lượng, chi phí và độ ổn định.
4. Kiểm tra prompt injection qua tài liệu, kết quả tìm kiếm và phản hồi từ công cụ.
5. Xác nhận log đủ điều tra sự cố nhưng đã che khóa truy cập và dữ liệu cá nhân.

Nên tự xây hay dùng dịch vụ quản lý?

Dịch vụ quản lý phù hợp khi đội muốn thử nhiều mô hình nhanh và không muốn duy trì vòng lặp agent, sandbox, telemetry. Tự xây phù hợp khi luồng công việc có yêu cầu kiểm soát đặc thù, cần chạy tại chỗ hoặc muốn giảm phụ thuộc. Public preview nên được dùng cho môi trường thử nghiệm; trước khi đưa vào hệ thống đang phục vụ khách hàng, cần hỏi rõ SLA, giới hạn, thay đổi API và phương án quay lui.

Nguồn tham khảo

• Microsoft, công bố ngày 28/10/2026: https://blogs.microsoft.com/blog/2026/10/28/introducing-the-microsoft-copilot-harness-unlocking-the-potential-of-truly-multi-model-agentic-work/
• Azure Blog, Foundry Agent Service public preview ngày 28/10/2026: https://azure.microsoft.com/en-us/blog/

Nếu bạn muốn thử agent trên hạ tầng riêng, hãy gửi mô hình dự kiến, số tác vụ đồng thời, độ dài ngữ cảnh, danh sách công cụ và yêu cầu cách ly tới hotro@thuemaychu.vn. Mục tiêu là xác định cấu hình CPU/GPU và bộ tiêu chí đo trước khi triển khai.