Vì sao Muse Code giữ agent sống suốt cả phiên làm việc
Quyết định kiến trúc thầm lặng đứng sau tốc độ của Muse Code: các background agent tồn tại xuyên suốt phiên, thay vì sinh ra cho từng task rồi vứt đi.
Vấn đề của kiểu “sinh ra rồi vứt”
Phần lớn công cụ coding đa agent đều theo cùng một công thức: task đến, dựng một agent phụ, giao cho nó một mẩu việc, thu kết quả, rồi dẹp bỏ. Một abstraction gọn gàng với cái giá xấu xí. Mỗi agent mới sinh đều bắt đầu từ con số không — phải đọc lại cấu trúc repository, khám phá lại build system, học lại các quy ước mà codebase của bạn đang theo. Trong một phiên có mười task, khoản “thuế” thu thập ngữ cảnh đó bị trả mười lần.
Thuế ở đây không chỉ là token. Đó còn là độ trễ — mỗi lần khởi động lạnh đều trì hoãn công việc thật — và là công sức lèo lái của bạn, vì một agent đã quên sạch những gì nó học được một giờ trước sẽ hỏi bạn cùng một câu đến hai lần.
Câu trả lời của Muse Code: sự bền bỉ
Muse Code được xây dựng như một vòng lặp agent chính đơn giản cộng với một tập các background agent bất đồng bộ — và những background agent này hoạt động xuyên suốt phiên. Chúng không được tạo ra cho từng task riêng lẻ. Mỗi agent có chuyên môn riêng, liên tục tích lũy ngữ cảnh khi phiên tiến triển, và tự quyết định khi nào một điều gì đó đáng để báo cáo về agent chính.
Chi tiết cuối cùng đó quan trọng hơn vẻ ngoài của nó. Các background agent không chặn vòng lặp chính để chờ chỉ thị, cũng không dội bom nó bằng các cập nhật trạng thái. Chúng tự triển khai bước tiếp theo một cách độc lập và chỉ lên tiếng khi có chuyện đáng nói. Lý do Meta đưa ra chính xác là hai khoản chi phí kể trên: sự bền bỉ giảm độ trễ, và giảm nhu cầu con người phải lèo lái trong những task khó, nhiều bước.
Worker chạy song song, reviewer soi trong nền
Trên thực tế, trải nghiệm của bạn giống một đội ngũ với các vai trò cố định hơn là một hàng dài nhân viên thời vụ. Worker thực thi thay đổi song song; reviewer liên tục phản biện kết quả trong nền trước khi nó đến tay bạn. Cách định vị lúc ra mắt — “multi-agent by default” — là chính xác đến từng chữ: sự phối hợp không phải một chế độ bạn bật lên, mà là cách mọi task vận hành. Bạn ship nhanh hơn không phải vì một agent đơn lẻ nào đó nhanh hơn, mà vì khâu kiểm soát chất lượng diễn ra đồng thời thay vì được nghĩ đến sau cùng.
Được huấn luyện vào model, không phải gắn thêm bên ngoài
Có lý do khiến thiết kế harness này chạy với Muse Spark 1.2 tốt hơn hẳn một lớp wrapper quanh model đại trà. Model được đồng huấn luyện cùng harness của Muse Code — công thức training của nó tối ưu tường minh cho hành vi subagent, bên cạnh mục tiêu (goal) và nén ngữ cảnh. Sự phân công giữa một vòng lặp chính và các chuyên gia bền bỉ không phải mẹo prompt engineering phủ lên trên; model đã nhìn thấy nó ngay trong quá trình training. Đó là nguồn gốc của những tuyên bố “ít phải thử lại hơn, dùng tool tốt hơn”, và chúng tôi phân tích sâu trong bài viết về cách Muse Spark 1.2 được huấn luyện.
Điều mà sự bền bỉ không giải quyết được
Những agent sống lâu cùng sửa một repository đồng thời sẽ là công thức cho thảm họa merge — nếu chúng dùng chung một bản làm việc. Nhưng chúng không dùng chung. Khi công việc fan out, mỗi agent con có quyền ghi nhận một git worktree cách ly riêng, nên công việc song song không bao giờ va chạm trên file. Cơ chế cách ly đó xứng đáng có bài giải thích riêng: agent fan-out và git worktree. Còn khi bạn muốn biết bất kỳ agent nào trong số này thực sự đã làm gì lúc bạn không nhìn, event log dạng append-only có câu trả lời trọn vẹn.