Thử nghiệm Meta Muse đến giới hạn: Khi control plane của AI agent bắt đầu quá tải

Meta Muse là AI agent cá nhân của Meta, ra mắt ngày 8/9/2026. Không chỉ trả lời câu hỏi, nó được thiết kế để thực thi tác vụ thay người dùng: có trình duyệt riêng, tiếp tục làm việc sau khi ứng dụng đóng, và chạy trong máy ảo Muse Secure chuyên dụng. Một kỹ sư đã tiến hành thử nghiệm black-box để kiểm tra điều gì xảy ra với runtime của Muse khi bị đẩy đến giới hạn.

Kết quả cho thấy một bức tranh đáng suy ngẫm về kiến trúc của các hệ thống AI agent đa tác vụ — nơi control plane có thể trở thành điểm nghẽn chết người.

Thí nghiệm: Tạo hàng loạt subagent cùng lúc

Tỷ lệ thất bại theo cấu hình

Lúc 06:45:32 UTC, kỹ sư này yêu cầu một phiên chat tạo 120 subagent cùng một lúc. Mỗi agent có nhiệm vụ cực kỳ đơn giản: chạy lệnh sleep 30 trong shell và báo cáo lại một dòng.

Kết quả:

• 33 lệnh thành công — tạo được agent, tất cả đều là con trực tiếp của root agent
• 87 lệnh thất bại — tất cả với cùng một lỗi database
• Câu trả lời tổng hợp không bao giờ đến — giao diện cuối cùng hiển thị trạng thái Error

Điều đáng chú ý: trong trace bền vững (durable trace), cả 33 agent được tạo đều đạt trạng thái completed. 32 trong số đó xác nhận hoàn thành workload, một agent vẫn chưa rõ kết quả. Nhưng bản ghi của agent cha vẫn hiển thị running — và người dùng không bao giờ nhận được câu trả lời tổng hợp.

Bằng chứng từ PostgreSQL

Các thí nghiệm được thực hiện chỉ với những giao diện mà phiên chat được phép truy cập: subagent.spawn, shell trong môi trường được cấp, và giao diện đọc read-only tới dữ liệu chẩn đoán. Runtime ghi lại toàn bộ hoạt động vào PostgreSQL với các bảng như agent.agents, agent.subagent_spawns và agent.subagent_progress_tool_events.

Sáu lỗi thất bại đã được phục hồi từ tool trace, tất cả đều trả về cùng một payload:

{"error_code":"spawn_failed","error_message":"database error: sqlx error: error returned from database: canceling statement due to lock timeout"}

Cả sáu đều không tạo ra child-agent row, không có spawn-ledger row. Lỗi xảy ra ở tầng database với lock timeout trước khi bất kỳ bản ghi nào được ghi.

Đường cong leo dốc: Từ 40 lên 120

Số lượng worker đồng thời theo thời gian

Tỷ lệ thất bại quan sát được qua ba lần chạy burst:

• PROBE-40: 2,5% (1/40 thất bại) — đỉnh đồng thời 39
• BURST-80: 6,25% (5/80 thất bại) — đỉnh đồng thời 72
• BURST-120: 72,5% (87/120 thất bại) — đỉnh đồng thời 33

Bước nhảy lớn nhất nằm giữa 80 và 120 lần thử. Tuy nhiên, mỗi cấu hình chỉ chạy một lần, nên đây là quan sát đơn lẻ chứ không phải đường cong mở rộng hay ngưỡng quá tải đã được đo lường.

Có một cấu hình thứ tư là STAGGERED-80 — cùng 80 lần gọi nhưng rải đều theo thời gian và dùng một coordinator agent ở depth 1 để tạo worker ở depth 2. Kết quả: 0% thất bại, đỉnh đồng thời 38. Nhưng vì thay đổi cả nhịp độ lẫn topology, nó không thể là đối chứng sạch cho các lần chạy burst.

Lỗ hổng trong việc đếm thất bại

Nhịp độ admission

Một vấn đề cấu trúc: một lần spawn thất bại không tạo ra child-agent row và không có spawn-ledger row. Bản thân lỗi không bị mất — nó tồn tại trong tool trace — nhưng phải biết tìm ở đâu.

Điều này khiến việc đếm thất bại trở thành con số khó xác định nhất. Sáu lỗi đầu tiên được phục hồi muộn từ context items, đó là lý do thí nghiệm cần có ledger riêng để đếm 87 thất bại còn lại.

Thời gian từ lúc gọi đến lúc lỗi (12 giây cho probe, khoảng 58 giây cho burst) là khoảng thời gian giữa hai sự kiện, không phải thời gian chờ lock. Giá trị timeout được cấu hình là một dữ kiện khác — và trace không ghi lại nó.

Bài học cho người xây dựng control plane

Thử nghiệm burst với 120 worker

Từ thí nghiệm này, có thể rút ra một số nguyên tắc thiết kế quan trọng:

• Durable record quan trọng hơn status flag. Giao diện hiển thị Error, agent cha hiển thị running, worker hiển thị completed. Chỉ có trace mới có thể truy vấn ngược lại sau đó.
• Giữ lại kết quả âm. Spawn thất bại không để lại dấu vết trong registry; chỉ có tool call và output của nó là bằng chứng bền vững.
• Trạng thái terminal không đồng nghĩa với thành công ngữ nghĩa. Agent C-85 có trạng thái completed nhưng kết quả workload không thể phục hồi.
• Ghi log độ trễ cho cả thất bại, không chỉ kết quả. Sáu lỗi có timestamp hai đầu; 87 lỗi còn lại thì không.
• Sự kiện progress chỉ là gợi ý, không phải nhịp tim. Ba mươi hai phút im lặng kết thúc bằng một artifact build thành công.

Những gì bằng chứng chưa thể khẳng định

Dữ liệu này ủng hộ mạnh mẽ giả thuyết tranh chấp trên đường ghi spawn vào PostgreSQL. Nhưng nó không xác định được ổ khóa, bảng, hàng, chỉ mục, truy vấn hay giao dịch cụ thể nào tham gia.

Các điểm chưa được thiết lập:

• Giá trị timeout lock được cấu hình, hoặc lý do hai độ trễ quan sát được khác nhau
• Bất kỳ giới hạn scheduler hay admission nào — các đỉnh 39, 72, 38, 33 chỉ là quan sát đơn lẻ
• Mức độ song song thực sự của inference backend — hoạt động agent chồng lấn không đồng nghĩa với các lệnh gọi model chồng lấn
• Liệu child agent có sống sót khi parent gặp lỗi — thí nghiệm này chưa từng được chạy
• Ý nghĩa của chuỗi model ipnext/avocado-5.16-v4 xuất hiện trên mọi hàng agent

Với người dùng Việt Nam đang theo dõi làn sóng AI agent, đây là lời nhắc nhở rằng đằng sau giao diện chat mượt mà là cả một hệ thống phân tán phức tạp. Khi hệ thống đó gặp sự cố, người dùng chỉ thấy một chữ "Error" — còn nguyên nhân thật sự nằm sâu trong những bảng dữ liệu mà không ai nhìn thấy.