Hai bài trước nói về một điều:
agent muốn lên production thì phải có Harness, và Harness phải được lắp.
Ngày 28/10/2026, Microsoft đưa ra một lựa chọn khác.
Microsoft Copilot harness, chính lớp hạ tầng đứng sau các sản phẩm Copilot, giờ có mặt trong Foundry Agent Service dưới dạng public preview.
Câu hỏi đặt ra rất tự nhiên:
Đã có Harness để thuê, có còn cần lắp nữa không?
(Thông tin trong bài tính đến ngày 10/11/2026, khi tính năng vẫn đang preview.)
Tự xây bếp hay thuê bếp
Một người muốn mở quán ăn có hai cách.
Cách thứ nhất: tự xây bếp.
Mua lò, lắp hút mùi, đi đường gas, xin giấy phép phòng cháy.
Mất vài tháng trước khi nấu được món đầu tiên.
Cách thứ hai: thuê bếp trung tâm.
Lò, dao, tủ đông, hệ thống chữa cháy đều có sẵn.
Chỉ cần mang công thức tới và bắt đầu nấu.
Copilot harness là cách thứ hai.
Một khách hàng được Microsoft trích dẫn nói đội của họ có giải pháp chạy được trong chưa đầy một tuần.
Trong “bếp thuê” có gì
Harness tiếp quản toàn bộ vòng lặp làm việc của agent:
gọi model, gọi tool, đọc ghi file, chạy code, giao việc nhỏ cho agent phụ.
Team cung cấp Microsoft vận hành
───────────── ──────────────────
Instructions Vòng lặp agent
Skills (SKILL.md) ───▶ Sandbox an toàn
Tool, MCP server Đọc/ghi file, chạy code
Chọn model Subagent, duyệt built-in tool
Vài điểm đáng chú ý:
- Skills là các gói hướng dẫn, script, file mà agent dùng lại được qua nhiều task. Giống cuốn sổ công thức riêng của đầu bếp.
- Tool và MCP được kết nối kèm quy tắc đăng nhập và phê duyệt.
- Đổi model không cần viết lại vòng lặp. Đổi đầu bếp, bếp vẫn nguyên.
- Định nghĩa agent có thể nằm trong source control cùng code ứng dụng.
Ba cách để có bữa ăn
Foundry hiện có ba lựa chọn, và chúng giống ba cách giải quyết bữa trưa:
Prompt agent Prompt agent + harness Hosted agent
──────────── ────────────────────── ────────────
Mua cơm hộp Thuê bếp trung tâm Tự mở bếp riêng
Vài chỉ dẫn, Skills, file, code, Framework, middleware,
vài tool subagent, nhiều bước vòng lặp tự viết
Foundry chỉ lo chỗ chạy
Ít kiểm soát ─────────────────────────────────▶ Nhiều kiểm soát
Cơm hộp nhanh nhưng không chọn được món.
Bếp riêng làm được mọi thứ nhưng phải tự lo mọi thứ.
Bếp thuê nằm ở giữa.
Microsoft lo phần nào, team vẫn lo phần nào
Đây là phần quan trọng nhất của bài.
Đặt Copilot harness cạnh khung Harness ở hai bài trước sẽ thấy ngay đường ranh giới.
Microsoft đã đóng gói:
- Vòng lặp thực thi.
- Sandbox, tức là giới hạn phạm vi ảnh hưởng mà bài phần 1 gọi là Execution Sandbox.
- Cơ chế duyệt tool, một phần của bài toán Authority.
Team vẫn phải tự làm:
- Guides kiểm tra được bằng máy. Một file
SKILL.mdviết “hãy cẩn thận với dữ liệu khách hàng” vẫn chỉ là lời khuyên, dù chạy trên nền tảng nào. - Sensors. Lint, test, policy, các ngưỡng đánh giá. Harness chạy code, nhưng không biết code đó đúng nghiệp vụ hay không.
- Kiểm soát hành vi. Đơn hàng nào được hoàn tiền, khách nào được giảm giá, đó là luật của doanh nghiệp, không phải của Microsoft.
- Ngưỡng gọi con người. Khi nào agent phải dừng lại và hỏi.
Quay lại căn bếp thuê.
Chủ bếp đảm bảo lò không nổ, điện không chập, đồ ăn được giữ lạnh đúng nhiệt độ.
Nhưng chủ bếp không nếm món của từng quán.
Món mặn hay nhạt, có đúng công thức không, là việc của đầu bếp.
Thuê được nhà xưởng. Không thuê được quy trình kiểm tra chất lượng.
“Lịch sử hội thoại là chưa đủ”
Cùng ngày 28/10, khả năng chịu lỗi cho hosted agent chạy dài đã GA.
Nếu một task dài bị ngắt giữa chừng, Foundry tự phát hiện và khởi động lại agent với đầu vào ban đầu.
Nghe như vấn đề đã được giải quyết.
Nhưng chính tài liệu của Microsoft nhấn mạnh: lịch sử hội thoại là chưa đủ để khôi phục công việc đang làm dở.
Ứng dụng phải tự lưu checkpoint, và phải kiểm tra xem hành động bên ngoài đã xảy ra chưa trước khi làm lại.
Hình dung một agent xử lý hoàn tiền.
Nó đã chuyển tiền cho khách, rồi bị ngắt trước khi kịp ghi lại “đã xong”.
Foundry khởi động lại từ đầu.
Không có checkpoint, khách được hoàn tiền hai lần.
Giống bấm nút “Thanh toán” trên app ngân hàng lúc mạng chập chờn.
Bấm hai lần, nhưng một ứng dụng tử tế chỉ trừ tiền một lần.
Đó không phải may mắn. Đó là idempotency key do người viết ứng dụng thiết kế.
Nền tảng giúp chạy lại.
Nhưng chạy lại mà không gây hậu quả vẫn là việc của team.
Lớp bảo mật đi kèm
Đầu tháng 11, Microsoft Security bổ sung hai mảnh ghép đáng chú ý cho agent:
- Microsoft Execution Containers (MXC), đã GA: lớp cô lập do hệ điều hành Windows thực thi, giới hạn agent với file, mạng, tiến trình. Có thể chạy thử policy trước khi bật thật.
- Dynamic Permissions: mỗi agent nhận quyền vừa đủ cho task hiện tại, chỉ trong thời gian cần, và có thể bị yêu cầu chờ người duyệt với hành động tác động lớn.
Giống thẻ từ khách sạn.
Thẻ chỉ mở đúng phòng đã đặt, đúng số đêm đã ở.
Trả phòng xong, thẻ vô hiệu.
Không ai được cầm chìa khóa tổng chỉ vì “có thể sẽ cần”.
Vài điểm cần cẩn thận
1. Shell bật sẵn, và Microsoft giữ quyền duyệt built-in tool.
Theo phân tích của Futurum Group dựa trên hướng dẫn triển khai, agent mới được bật sẵn năm built-in tool, trong đó có shell.
Quy tắc duyệt cho các built-in tool này do dịch vụ quản lý. Cài đặt phê duyệt của team chỉ áp dụng cho MCP tool tự kết nối.
Chính tài liệu gọi shell là tool “rộng nhất”.
Tắt quyền đọc file hay truy cập web nhưng vẫn để shell bật thì không phải một ranh giới bảo mật thật.
Giống khóa cửa sổ nhưng để cửa chính mở.
Với doanh nghiệp trong ngành tài chính, y tế, đây là điểm cần quyết định trước khi tạo agent, không phải sau.
2. Chọn lúc tạo, không đổi được.
Harness phải được chọn khi tạo agent. Agent đã có không chuyển sang được, và trong preview cũng không có đường chuyển ngược ra.
Giống đổ bê tông móng nhà: đổ xong rồi thì rất khó đổi ý.
3. Mang được công thức, không mang được bếp.
SKILL.md theo định dạng mở Agent Skills, MCP server cũng là chuẩn mở. Những thứ này mang đi được.
Còn kết nối Foundry, danh tính, cài đặt phê duyệt thì phải làm lại nếu chuyển nền tảng. Vòng lặp và cơ chế khôi phục, team sẽ phải tự viết.
Đầu bếp rời bếp thuê mang theo được sổ công thức.
Nhưng không mang theo được cái lò.
4. Preview chưa dành cho production.
Không có SLA. Chưa dùng được model tự mang tới, chưa có Foundry Memory. Cấu hình CPU, bộ nhớ của sandbox do Foundry cố định.
5. Chưa có region Đông Nam Á.
Danh sách region preview gần Việt Nam nhất là Japan East và Australia East.
Với ứng dụng cần độ trễ thấp hoặc có yêu cầu dữ liệu lưu trong khu vực, đây là câu hỏi cần trả lời sớm.
6. Giá rẻ từng giờ, nhưng nhân lên thì khác.
Miễn phí sandbox đến 1/12/2026. Sau đó tính theo mức dùng: 0,0994 USD mỗi vCPU-giờ và 0,0118 USD mỗi GiB-giờ, chưa tính tiền model.
Thử một phép tính, giả định sandbox 2 vCPU và 4 GiB:
1 giờ sandbox ≈ 2 × 0,0994 + 4 × 0,0118 ≈ 0,25 USD
(khoảng giá một ly trà đá vỉa hè)
1.000 task/ngày × 10 phút ≈ 167 giờ/ngày
≈ 41 USD/ngày
≈ 1.200 USD/tháng
Một ly trà đá thì không ai để ý.
Một nghìn ly mỗi ngày thì kế toán sẽ để ý.
Hóa đơn lại đổ về chủ subscription Foundry, trong khi agent thường do từng phòng ban tạo ra. Ai trả tiền cần được thống nhất trước hóa đơn đầu tiên.
Vậy nên chọn gì?
Ba câu hỏi:
1. Cần tùy biến vòng lặp đến đâu?
Cần middleware riêng, framework riêng thì chọn hosted agent. Cần chạy nhanh các task nhiều bước thì harness phù hợp.
2. Chấp nhận phụ thuộc nền tảng tới mức nào?
Nếu khả năng chuyển nền tảng quan trọng, hãy giữ logic nằm trong skills và MCP, những phần mang đi được.
3. Đã có Sensors chưa?
Đây là câu quan trọng nhất.
Harness làm agent chạy nhanh hơn.
Không có Sensors, agent chỉ sai nhanh hơn.
Kết luận
Copilot harness là một bước tiến thật.
Nó gỡ bỏ phần nặng nhất và ít khác biệt nhất: vòng lặp, sandbox, hạ tầng chạy.
Nhưng nó cũng làm rõ một điều:
phần Harness tạo ra khác biệt chưa bao giờ là vòng lặp.
Đó là luật nghiệp vụ được viết thành phép kiểm tra.
Là thông báo lỗi chỉ đúng chỗ cần sửa.
Là ngưỡng mà ở đó agent phải dừng lại và hỏi con người.
Những thứ đó không có trong bất kỳ bản preview nào.
Microsoft có thể cho thuê bếp. Nhưng không ai nếm món thay cho đầu bếp.
