Một phiên Gemini CLI là một agent đơn lẻ làm việc trong một thư mục. Ngay khi bạn muốn có thêm một tác vụ chạy song song — sửa lỗi trong lúc một đợt refactor đang chạy, viết test trong lúc một tính năng đang được hoàn thiện — bạn mở thêm một terminal. Rồi cái thứ ba. Chưa đầy một tiếng, bạn đã có bốn tab, bốn thư mục làm việc, và không có câu trả lời rõ ràng cho một câu hỏi đơn giản: agent nào đang làm gì, và cái nào vừa động vào file mà bạn sắp sửa.
Chạy nhiều tác vụ Gemini song song thì không khó để bắt đầu. Cái khó là giữ mọi thứ rõ ràng. Mỗi instance tự nó chạy rất nhanh; cái giá phải trả nằm ở khâu phối hợp, và đó chính là phần mà terminal không bao giờ mang lại cho bạn.
Bài viết này đi qua từng bước thiết lập thủ công cho các agent Gemini CLI chạy song song, chỉ ra lỗi nào đang chờ ở mỗi bước, và cho thấy bảng tác vụ sẽ tiếp quản từ đâu. Bảng tác vụ đó là Sharkly, một nền tảng chỉ huy và quản lý Agent tất-cả-trong-một. Sharkly không thay thế Gemini CLI. Nó bổ sung lớp tác vụ, Computer, ngữ cảnh và review dùng chung quanh những runtime mà đội của bạn đang dùng, để các lượt chạy song song vẫn có thể giao việc và truy vết thay vì nằm rải rác khắp các tab.
“Parallel agent” nghĩa là gì với Gemini CLI
Gemini CLI chạy một agent cho mỗi tiến trình. Nó đọc thư mục hiện tại, nạp file ngữ cảnh GEMINI.md nếu có, và xử lý prompt của bạn trong đúng working tree đó. Không có sẵn bộ điều phối nào tự chia một mục tiêu cho nhiều sub-agent rồi hợp nhất kết quả lại cho bạn.
Vậy nên “parallel Gemini agent” trên thực tế chỉ có một nghĩa: nhiều tiến trình gemini chạy cùng lúc, mỗi cái trong một môi trường tách biệt, mỗi cái đảm nhiệm một tác vụ riêng. Gemini CLI là mã nguồn mở và miễn phí khi dùng với tài khoản Google cá nhân, đó chính là lý do người ta bật một lúc bốn cái. Nút thắt chưa bao giờ nằm ở việc khởi chạy chúng. Mà là giữ cho bốn lượt chạy độc lập không đụng nhau trong cùng một repository, và một tiếng sau vẫn biết mỗi cái đã tạo ra thứ gì.
Đó cũng chính là bài toán phối hợp bạn gặp với Claude Code hay Codex. Runtime thay đổi; còn sự hỗn loạn thì không.
Thiết lập thủ công, từng bước một
Đây là phiên bản chạy được tối giản nhất của Gemini CLI song song, kèm theo thứ sẽ hỏng ở mỗi bước.
Bước 1: Cho mỗi agent một working tree riêng. Đừng chạy hai agent trong cùng một thư mục. Dùng một git worktree cho mỗi tác vụ để mỗi bản checkout tách biệt hoàn toàn về mặt vật lý:
git worktree add ../repo-auth feature/auth
git worktree add ../repo-tests chore/tests
git worktree add ../repo-bugfix fix/login-redirect
Lỗi sẽ gặp nếu bỏ qua: hai agent cùng sửa một checkout sẽ ghi đè lên nhau giữa chừng. Một cái format lại file mà cái kia đang làm dở, và cả hai để lại working tree ở trạng thái mà không cái nào mong muốn. Worktree cho mỗi agent một branch sạch và một thư mục sạch. Chúng tôi đi sâu hơn về chủ đề này trong git worktrees cho AI coding agent.
Bước 2: Khởi chạy một Gemini CLI cho mỗi worktree. Mở một terminal trong mỗi thư mục và khởi chạy một phiên:
cd ../repo-auth && gemini
Với những lượt chạy không cần giám sát, hãy dùng chế độ non-interactive để agent nhận một prompt duy nhất rồi thoát:
cd ../repo-tests && gemini -p "Add unit tests for the session module. Run the suite before finishing."
Lỗi sẽ gặp: một phiên interactive sẽ dừng lại ngay ở prompt xin quyền đầu tiên và chờ. Hai mươi phút sau bạn quay lại thì thấy agent chẳng làm gì cả, chỉ vì nó cần một chữ “đồng ý”. Hãy xác định trước lượt chạy nào là interactive, lượt nào là headless, và với lượt headless thì đưa vào prompt một bước tự kiểm tra.
Bước 3: Tách biệt ngữ cảnh cho từng tác vụ. Mỗi worktree có thể mang GEMINI.md riêng với các quy tắc cho tác vụ đó: được đụng vào gì, phải để yên cái gì, chạy test thế nào.
Lỗi sẽ gặp: dùng chung một file ngữ cảnh cho mọi agent nghĩa là chỉ dẫn dành cho tác vụ auth sẽ rò rỉ sang tác vụ test. Hãy giới hạn ngữ cảnh trong đúng working tree mà nó thuộc về.
Bước 4: Để mắt đến quota. Mọi instance đang chạy đều rút từ cùng một hạn mức tài khoản. Bốn agent cùng cày một đợt refactor lớn sẽ đụng giới hạn rate limit nhanh hơn một agent, và một agent bị bóp tốc độ sẽ thất bại âm thầm trong cái tab mà bạn không nhìn tới.
Lỗi sẽ gặp: một lượt chạy đình trệ vì lỗi quota và bạn không hề hay biết cho đến khi mở đúng tab đó ra kiểm tra. Không có màn hình chung nào báo cho bạn rằng một agent đã dừng. Nếu bạn đang cân đối các tác vụ nặng với model phù hợp, bài model nào cho tác vụ coding nào sẽ bàn kỹ về sự đánh đổi đó.
Với ba hoặc bốn tác vụ thì cách này ổn. Branch thật, tách biệt thật, song song thật, không cần thêm công cụ gì.
Cách tự làm bắt đầu hết đất dụng võ từ đâu
Cách thủ công không sụp ở khâu thực thi mà ở mọi thứ xung quanh nó. Hãy xem điều gì xảy ra khi số lượng tác vụ tăng lên.
Bạn mất tấm bản đồ. Với bốn terminal thì bạn còn nhớ trong đầu được. Nhưng tám cái, trải khắp hai repository, thì chịu. Tab nào là agent auth? Lượt chạy test đã xong hay đã chết vì lỗi quota? Giám sát các coding agent chạy song song là việc mà terminal chưa bao giờ được sinh ra để làm.
Kết quả nằm rải rác. Mỗi agent để lại công việc của mình dưới dạng một diff trên branch và một đống scrollback trong cái tab mà kiểu gì bạn cũng sẽ đóng. Không có bản ghi chung về việc mỗi lượt chạy đã thay đổi gì, vì sao, hay liệu nó có vượt qua được bài test của chính nó hay không. Khi đồng nghiệp hỏi bản sửa lỗi đăng nhập đã làm gì, câu trả lời nằm trong một terminal đã không còn tồn tại.
Khâu review không có chỗ trú ngụ. Agent chạy song song thì sinh ra diff song song, và cái nào cũng vẫn cần người duyệt. Đọc bốn branch mà không có tóm tắt, không có kết quả kiểm chứng, không có ngữ cảnh thì còn chậm hơn cả tốc độ mà agent đã tiết kiệm được. Tốc độ bạn giành được ở khâu thực thi sẽ bị trả lại hết ở khâu review.
Đây là cặp lựa chọn thẳng thắn. Nếu bạn chỉ thỉnh thoảng chạy ba bốn tác vụ Gemini, cứ giữ cách thiết lập worktree ở trên; nó đơn giản và hiệu quả, còn bảng tác vụ chỉ là thứ cồng kềnh không cần thiết. Chỉ cần đến nó khi các lượt chạy song song trở thành chuyện thường ngày: nhiều agent, nhiều hơn một repository, nhiều hơn một người cần theo dõi tiến độ, và khâu review phải truy vết được chứ không thể dựa vào trí nhớ. Đến lúc đó thì việc so sánh các công cụ quản lý agent chạy song song là điều đáng làm.
Bảng tác vụ bổ sung được gì
Bảng tác vụ thay đổi đơn vị công việc từ “một tab terminal” thành “một Task”. Chính sự dịch chuyển đó là thứ mà cách tự làm còn thiếu.
Với Sharkly, bạn giao một Task cho một Agent chạy trên nền Gemini CLI. Agent sẽ nhận Task, làm việc trong một worktree tách biệt, còn quá trình thực thi, các điểm tắc, kết quả và thảo luận tiếp theo đều quay về dòng thời gian của Task thay vì biến mất trong những terminal riêng lẻ. Chạy nhiều cái cùng lúc thì mỗi cái là một dòng bạn nhìn thấy được, chứ không phải một tab bạn phải đi tìm. Gemini CLI vẫn làm phần viết code; Sharkly quản lý việc giao task, các Computer được kết nối, ngữ cảnh và khâu review xuyên suốt mọi lượt chạy.
Phân công lao động vẫn rõ ràng. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, cấp quyền và phê duyệt kết quả. Tự động hóa dừng lại ở đúng chỗ cần đến phán đoán của con người, và mỗi lượt chạy trở về kèm bản tóm tắt thay đổi cùng kết quả kiểm chứng của chính nó, nên việc chấp nhận hay từ chối một diff chỉ cần liếc mắt thay vì đào bới như khảo cổ. Ngữ cảnh, tiến độ, điểm tắc, kết quả và khâu review của con người luôn hiển thị rõ từ lúc đưa ra yêu cầu đến khi phát hành.
Bạn giữ nguyên những gì đang có. Sharkly không yêu cầu bạn rời bỏ Gemini CLI hay cam kết gắn bó với một runtime duy nhất. Vì nó trung lập về nhà cung cấp, cùng một bảng tác vụ có thể chạy agent Claude Code và Codex song song với agent Gemini của bạn, nên quy trình của bạn vẫn đứng vững dù agent xịn nhất tiếp theo có là gì đi nữa. Sự trung lập đó chính là điểm mấu chốt: bạn quản lý các agent của mình ở một nơi, chứ không phải đổi hệ sinh thái mỗi khi có công cụ mới ra đời.
Danh sách kiểm tra bạn có thể áp dụng ngay hôm nay
Hãy chạy qua danh sách này trước loạt tác vụ Gemini song song tiếp theo:
- [ ] Mỗi tác vụ một git worktree; tuyệt đối không để hai agent trong cùng một checkout.
- [ ]
GEMINI.mdđược giới hạn riêng cho từng tác vụ, không dùng chung một file cho tất cả. - [ ] Lượt chạy headless dùng
gemini -pkèm bước kiểm chứng sẵn có để không bị đình lại ở prompt. - [ ] Có mức trần rõ ràng cho số instance chạy đồng thời để quota dùng chung không bóp nghẹt một lượt chạy mà bạn không nhìn thấy.
- [ ] Một nơi duy nhất trả lời được “agent nào đang làm gì, và cái gì đã xong” mà không cần mở từng tab.
- [ ] Mỗi lượt chạy hoàn tất đều để lại bản tóm tắt thay đổi và kết quả test để con người review, chứ không chỉ là một diff trên branch.
Bốn mục đầu bạn có thể làm ngay tối nay với worktree và terminal. Hai mục cuối là chỗ cách làm thủ công hết đường. Nếu bạn đã và đang chạy nhiều agent Gemini CLI cùng lúc, Sharkly cho bạn một nơi để giao việc, theo dõi tiến độ và review kết quả của chúng. Bạn có thể tự xây lớp phối hợp này, hoặc đưa các coding agent hiện có của mình chạy qua Sharkly và đi thẳng đến phần có thể mở rộng.
