TL;DR
Cursor vừa giới thiệu lệnh /multitask trong giao diện Cursor 3 mới, cho phép agent chạy async subagents song song thay vì xếp hàng chờ nhau. Cùng lúc, Cursor cũng đẩy thêm worktrees tốt hơn cho task nền theo từng branch riêng và multi-root workspace để một agent session xử lý nhiều repo/folder trong cùng workspace. Thông điệp lớn ở đây không còn là “AI viết code nhanh hơn”, mà là IDE đang biến thành bề mặt điều phối công việc giữa nhiều agent.
Thread này nên đọc đúng theo thứ tự 1 → 2 → 3
Điểm hay của thread này là Cursor không tung ba feature rời rạc. Họ đang kể một workflow hoàn chỉnh theo đúng thứ tự: đầu tiên cho agent chạy song song, sau đó cô lập từng nhánh công việc bằng worktree, và cuối cùng mở phạm vi làm việc ra nhiều repo/folder cùng lúc. Nếu đọc lệch thứ tự, bài dễ thành một mớ feature list. Đọc đúng mạch thì nhìn ra ngay đây là câu chuyện về orchestration.
1. /multitask
Mở nhiều subagent chạy song song thay vì bị kẹt trong một hàng đợi tuần tự.
2. Worktrees
Tách từng task sang branch riêng để agent nền không giẫm thẳng lên workspace chính.
3. Multi-root
Cho một session chạm nhiều folder/repo, hợp với các thay đổi cross-repo ngoài đời thật.
1) /multitask: Cursor đang đập vào nút thắt lớn nhất của coding agents
Video từ tweet đầu tiên: /multitask cho phép mở nhiều async subagent chạy song song thay vì dồn tất cả vào một queue.
Điểm khó chịu nhất khi dùng coding agent trong IDE thời gian qua là mọi thứ thường bị kéo về mô hình một hàng đợi dài: gửi task, chờ agent chạy xong, rồi mới đến task tiếp theo. Điều đó ổn với việc nhỏ, nhưng rất bí khi dev muốn vừa sửa bug, vừa nghiên cứu codebase, vừa chuẩn bị refactor ở một nhánh khác.
/multitask là câu trả lời trực diện cho đúng chỗ nghẽn đó. Thay vì thêm request mới vào queue, Cursor cho agent spawn async subagents để chạy nhiều nhánh công việc cùng lúc. Với các message đã xếp hàng từ trước, user cũng có thể chuyển chúng sang multitask thay vì ngồi chờ run hiện tại kết thúc.
Nói gọn: tweet đầu tiên giải quyết chuyện throughput. Nó không làm agent thông minh hơn, nhưng nó làm hệ thống bớt kiểu “một nhân viên nhận việc từng tờ phiếu một”.
💡 Giải thích nhanh
Async subagents có thể hiểu là các agent con được tách ra để xử lý từng việc nhỏ song song. Ví dụ: một agent dò bug, một agent đọc docs nội bộ, một agent chuẩn bị patch. Ý tưởng nghe rất đã, vì bottleneck lớn nhất của agent UX lâu nay chính là phải chờ từng việc nối đuôi nhau.
2) Worktrees: phần chống tự đấm nhau khi đã cho agent chạy song song
Video từ tweet thứ hai: worktrees mới trong agents window để chạy isolated task trên branch riêng, rồi kéo branch cần test về foreground.
Đây là đoạn nhiều người dễ lướt qua, nhưng thật ra nó mới là phần làm cho tweet 1 bớt mùi demo. Khi đã cho nhiều agent chạy song song, câu hỏi ngay lập tức là: chúng nó sửa vào đâu?
Nếu nhiều agent cùng đụng một workspace và cùng sửa một component, bạn gần như đang tự mời merge conflict vào nhà. Worktrees là lớp cách ly để mỗi task nền có branch riêng, chạy độc lập, và khi muốn test hoặc đem một nhánh về local foreground thì làm ngay trong agents window.
Nói cách khác, nếu tweet 1 là cho phép song song hóa công việc, thì tweet 2 là dựng lan can để song song hóa đó đỡ biến thành đống hỗn loạn. Đây là phần rất “đời thực”, vì làm agent thật không khó ở demo — khó ở khâu tránh cho chúng nó đạp lên nhau.
⚠️ Vì sao cái này quan trọng?
Parallelism mà không có branch isolation thì khá nguy hiểm. Worktree không giải quyết hết conflict, nhưng ít nhất nó chặn được kiểu tai nạn ngớ ngẩn nhất: nhiều agent cùng sửa trực tiếp vào một cây code đang mở.
3) Multi-root workspace: đẩy agent ra khỏi khuôn một repo
Video từ tweet thứ ba: multi-root workspace cho phép một agent session xử lý nhiều folder/repo trong cùng workspace.
Tweet 3 kéo câu chuyện đi xa hơn. Agent không chỉ sửa trong một repo đơn lẻ nữa, mà có thể chạm nhiều folder hoặc repo trong cùng workspace. Đây là loại feature nghe nhỏ nhưng lại rất hợp với công việc thật: sửa API ở backend rồi cập nhật luôn client ở frontend, hoặc chạm cả package shared lẫn app chính trong cùng một lần chạy.
Multi-root workspace vì thế không chỉ là tiện. Nó là dấu hiệu cho thấy Cursor đang cố đưa agent từ mô hình “giúp tôi viết đoạn code này” sang mô hình “giúp tôi xử lý một thay đổi hệ thống có nhiều bề mặt liên quan”.
Nếu xếp ba tweet lại với nhau, logic rất rõ:
- /multitask tăng số luồng công việc,
- worktrees cô lập từng luồng để đỡ đâm nhau,
- multi-root workspace mở rộng phạm vi để mỗi luồng đụng được nhiều repo/folder khi cần.
💡 Ý chính của thread
Nếu trước đây “coding session” nghĩa là ngồi trong một luồng hội thoại với một agent, thì thread mới của Cursor đang cố biến “coding session” thành một mặt phẳng điều phối công việc, nơi delegation, branch isolation và cross-repo execution cùng diễn ra ngay trong IDE.
Cộng đồng đang phản ứng ra sao?
Phản ứng dưới thread khá chia làm hai phe rõ rệt.
Phe hưng phấn: cuối cùng queue model cũng bị đập vỡ
- Nhiều người xem async subagents là “unlock” thật sự, vì bottleneck lớn nhất của agent UX lâu nay là phải chờ từng việc nối đuôi nhau.
- Một số reply khen Cursor đang đi trước ở chỗ biến delegation và coding thành cùng một động tác, thay vì bắt người dùng chuyển qua lại giữa “viết code” và “quản task”.
- Nhóm làm cross-repo hoặc fullstack thích phần multi-root/worktrees vì nó hợp với cách dự án thật vận hành hơn là mô hình một repo, một agent, một nhánh.
Phe dè chừng: song song không tự động đồng nghĩa ít đau đầu hơn
- Nhiều người hỏi thẳng chuyện conflict giữa các agent: nếu hai subagent chọn hai hướng kiến trúc khác nhau, ai sẽ tổng hợp và chặn xung đột trước khi code land?
- Có người lo async subagents sẽ chỉ biến codegen nhanh hơn nhưng verification debt và chi phí debug lại phình to về sau.
- Một số feedback còn chạm vào UX cũ hơn: giao diện mới còn thiếu file explorer hoặc đôi lúc treo khi khởi động agent, tức là bề mặt orchestration hay thật nhưng runtime stability vẫn là bài toán sống còn.
Đây là phản ứng khá hợp lý. Bài toán của agent song song không phải chỉ là “làm nhiều hơn cùng lúc”, mà là hợp nhất đầu ra thế nào để con người không phải trả lại hóa đơn debug còn đắt hơn lúc tự viết.
Điều Cursor đang bán thực ra là một agent operating surface
Thread này có một điểm rất giống xu hướng lớn hơn của thị trường devtools AI: editor đang lùi dần về vai trò nền, còn phần quan trọng hơn là bề mặt điều phối workflow.
Khi user có thể:
- tách việc cho nhiều subagent,
- cô lập mỗi task trong branch riêng,
- và cho một session đụng nhiều repo cùng lúc,
thì IDE bắt đầu giống một hệ orchestration có giao diện, hơn là một editor cài thêm model.
⚠️ Điều nên nhìn tỉnh
Parallelism là thứ rất dễ demo đẹp. Nhưng cái quyết định giá trị thật sẽ là ba thứ: branch isolation có đủ tốt không, conflict synthesis pass có tồn tại không, và chi phí review/debug sau khi song song hóa có giảm thật không. Nếu ba thứ này không được xử lý, /multitask rất dễ biến thành một cách mới để tạo thêm việc cho senior dev.
Chốt lại
Cursor đang làm một bước đi khá thông minh: không chỉ khoe model hay prompt mới, mà khoe cách tổ chức công việc giữa nhiều agent. Đó là hướng đi đúng, vì khi model bắt đầu na ná nhau hơn, phần khác biệt lớn sẽ nằm ở UX orchestration, branch control, review loop và cách đưa nhiều luồng công việc về một chỗ con người còn kiểm soát nổi.
🚨 Chốt một câu
Cursor không chỉ thêm /multitask để chạy nhiều agent cùng lúc — họ đang thử biến IDE thành hạ tầng workflow cho coding agents. Câu hỏi còn lại không phải là “có song song được không”, mà là “song song xong thì có merge lại thành một hệ thống còn sống nổi không”.