Bạn giao một lỗi cho Claude Code và một tính năng nhỏ cho Codex, rời đi, rồi quay lại thấy file có gì đó sai sai. Thay đổi của một agent biến mất. Hoặc cả hai thay đổi đều còn nhưng build thất bại. Hoặc tệ hơn, mọi thứ biên dịch được nhưng một bài test lại hỏng ở chỗ mà cả hai agent đều không đụng tới. Không có gì sập trong lúc bạn đi vắng. Cả hai agent đều đã làm đúng việc bạn yêu cầu. File không thể chứa hai tác giả cùng lúc, và không ai nói cho bạn biết ai thắng.
Sự im lặng đó mới là vấn đề thật sự. Một file không phải là công cụ merge. Khi hai coding agent cùng ghi vào auth.ts trong cùng một thư mục tại những thời điểm chồng lấn, không có lock, không có hàng đợi, không có cảnh báo; chỉ có tiến trình nào lưu sau cùng thì thắng. Bài viết này sẽ đi từng bước qua cuộc đụng độ đó, gọi tên kiểu thất bại ở mỗi giai đoạn, và kết thúc bằng một checklist bạn có thể chạy trước phiên làm việc song song tiếp theo.
Bài viết cũng chỉ ra quy trình mà những cách khắc phục này dẫn tới. Sharkly là một nền tảng lệnh và quản lý Agent tất-cả-trong-một, nằm phía trên các coding agent bạn đang dùng. Nó cấp cho mỗi Task một worktree tách biệt riêng, và giữ cho ngữ cảnh, tiến độ, điểm nghẽn, kết quả và bước review của con người luôn hiển thị từ lúc đưa ra yêu cầu đến lúc phát hành. Bạn có thể tự tay xây dựng cùng kỷ luật đó bằng Git thuần, và phần lớn bài viết này sẽ chỉ bạn cách làm. Phần cuối nói về thời điểm mà việc làm thủ công bắt đầu không còn đáng công.
Không có lock: ai ghi sau cùng thì thắng
Hãy bắt đầu với trường hợp tệ nhất, vì nó phổ biến nhất và cũng khó thấy nhất. Cả hai agent chạy trong cùng một thư mục làm việc. Agent A đọc auth.ts, lên kế hoạch thay đổi, rồi bắt đầu ghi. Agent B đọc đúng file auth.ts đó một giây sau, lên kế hoạch cho một thay đổi khác dựa trên phiên bản nó vừa đọc, và cũng ghi.
Cả hai đều không đọc được thay đổi của bên kia, vì lúc chúng đọc thì thay đổi đó chưa được lưu. Ai lưu sau sẽ ghi đè file trên đĩa bằng một phiên bản chưa từng chứa công việc của agent kia. Đây là kiểu last-write-wins, và nó diễn ra âm thầm. Không có conflict marker, không có lỗi, không có exit code. Agent A báo thành công. Agent B báo thành công. Một trong hai đang nói dối bạn mà chính nó cũng không biết.
Cuộc đua lockfile cũng là kiểu thất bại tương tự nhưng ở chỗ tốn kém hơn. Agent A chạy npm install và ghi lại package-lock.json; Agent B, đang giữa chừng install, lại ghi đè nó lần nữa từ một trạng thái khởi đầu khác. Kết quả là một lockfile không khớp với cả hai cây phụ thuộc, và lỗi hỏng chỉ lộ ra trên máy của người khác vài ngày sau. Thư mục build dùng chung, một cổng dev-server duy nhất, và một cache toàn cục đều thất bại theo đúng cách đó.
Cách khắc phục không phải là một agent thông minh hơn. Mà là cho mỗi agent một không gian riêng.
Mỗi agent một bản làm việc: cú ghi đè âm thầm biến thành xung đột nhìn thấy được
Git worktree là một bản checkout thứ hai của cùng một repository, trên một branch riêng, dùng chung một kho đối tượng .git. Mỗi agent có một thư mục thật để sửa, build và test mà không nhìn thấy công việc đang dang dở của người khác.
# From the main repo
git worktree add ../repo-agent-a -b agent/auth-refactor
git worktree add ../repo-agent-b -b agent/session-timeout
Trỏ Agent A vào ../repo-agent-a và Agent B vào ../repo-agent-b. Giờ thì những thay đổi chưa lưu của A vào auth.ts trở nên vô hình với B, và không agent nào có thể ghi đè file của agent kia trên đĩa, vì chúng đang sửa hai file khác nhau trên hai branch khác nhau. Mô hình worktree được trình bày kỹ hơn trong Git worktrees for AI coding agents và coding agent worktrees: one checkout per task.
Để ý xem việc cô lập đã làm được gì ở đây. Nó không ngăn hai agent cùng sửa một file. Nó chuyển một vụ mất dữ liệu âm thầm thành một xung đột merge nhìn thấy được, ngay tại thời điểm hai branch được hợp nhất lại. Đó là một bước nâng cấp thực sự: Git dừng lại và chỉ cho bạn đúng những dòng đang mâu thuẫn, và bạn giải quyết chúng với đầy đủ thông tin về cả hai phiên bản. Một xung đột bạn nhìn thấy được là một vấn đề bạn có thể sửa. Cú ghi đè mà bạn không thấy mới là cái đã lọt ra ngoài.
Một ranh giới cần nói rõ: worktree cô lập file, không cô lập các tác dụng phụ. Một database dùng chung, một cổng duy nhất, hay một đường dẫn output bị hardcode vẫn đụng nhau giữa các worktree. Hãy cô lập cả những thứ đó, hoặc tuần tự hóa các agent cần dùng chúng.
Xung đột mà bạn không thể nhìn thấy
Đây là kiểu thất bại vẫn tồn tại sau khi đã cô lập. Agent A, làm việc trong worktree riêng, đổi tên getUser() thành fetchUser() và cập nhật mọi chỗ gọi hàm mà nó quản lý. Agent B, cũng làm việc trong worktree riêng của mình cùng lúc, viết thêm ba chỗ gọi getUser() mới, vì đó là tên hàm vào lúc B đọc file.
Cả hai branch merge với không một conflict marker nào. Git so sánh từng dòng, và theo từng dòng thì không có gì chồng lấn: A sửa file của nó, B thêm file mới. Merge sạch trơn. Rồi build hỏng vì getUser không xác định, hoặc nó biên dịch được nhưng lỗi lúc chạy ở chỗ mà trình kiểm tra kiểu không với tới. Không công cụ nào báo động, vì về mặt văn bản thì không có đụng độ. Hai thay đổi bất đồng về ý nghĩa của file, chứ không phải về văn bản của nó.
Đó là lý do vì sao “cứ cô lập các agent ra” không phải là toàn bộ câu trả lời. Cô lập biến một xung đột cùng-file thành một xung đột cùng-interface, và kiểu thứ hai ẩn kín hơn kiểu thứ nhất. Đòn bẩy ở đây là phạm vi hóa task, không phải công cụ. Một quy tắc hữu ích: nếu bạn không thể mô tả task của hai agent mà không nhắc đến cùng một file hay cùng một hàm, thì chúng là một task, không phải hai. Chia công việc theo ranh giới module chính là phần lớn những gì giữ cho việc Claude Code và Codex cùng làm việc trên một codebase không biến thành cả một buổi chiều gỡ lỗi. Khi hai task thật sự chia sẻ một interface, hãy tuần tự hóa chúng, hoặc merge và rebase giữa các bước để agent thứ hai đọc được thực tế của agent thứ nhất.
Chỗ mà thiết lập tự làm bắt đầu hết khả năng mở rộng, và một task board thêm được gì
Hai agent và một file dùng chung thì bạn còn quản lý thủ công được: hai worktree, phạm vi hóa cẩn thận, một lần merge bạn tự ngồi xem. Cách này trụ được cho đến khi việc đếm trở nên khó. Agent nào đang ở branch nào. Worktree nào ứng với task nào. Trong năm lần merge sạch, lần nào đã âm thầm thay đổi một interface dùng chung. Những branch nào đang chờ bạn review, và branch nào bạn đã xem rồi. Các lệnh Git chẳng hề khó hơn; chỉ có việc ghi sổ sách quanh chúng là khó hơn, và chính chỗ ghi sổ đó là nơi các xung đột cùng-file lọt qua, vì bạn đã duyệt một lần merge mà bạn không đọc kỹ.
Một task board thay đổi thứ bạn đang theo dõi. Thay vì một bức tường terminal và các worktree rời rạc, mỗi đơn vị công việc là một Task có người phụ trách, một branch và một trạng thái. Trong Sharkly, một Task tự động được cấp một worktree tách biệt riêng, nên việc cô lập ở mức file trở thành mặc định thay vì một lệnh bạn phải nhớ chạy. Quá trình thực thi, các điểm nghẽn và kết quả đều quay về Task, nên bạn review một thay đổi dựa trên phạm vi đã công bố của nó thay vì phải suy ngược ý đồ từ một diff. Và phân công lao động vẫn cố định: agent nghiên cứu, thực thi, test và báo cáo; con người định hướng, trao quyền và chấp nhận kết quả. Tự động hóa dừng lại ở đúng chỗ cần đến phán đoán của đội ngũ.
Điểm cuối cùng đó là thứ mà chỉ cô lập thôi không bao giờ giải quyết được. Công cụ tốt hơn làm việc cô lập và merge dễ hơn, nhưng review không mở rộng theo số lượng agent; nó mở rộng theo sự tập trung của bạn, và review của con người mới là điểm nghẽn thật sự trong công việc agent song song. Năm agent tạo ra năm branch trong khoảng thời gian bạn đọc kỹ được một cái. Một task board không đọc code thay bạn. Nó giữ cho hàng đợi trung thực để một thay đổi trông-có-vẻ-hợp-lý không bị đọc lướt rồi merge vì bạn mất dấu nó nằm ở đống nào. Phép toán xung đột tương tự cũng xuất hiện ở mức repo, được trình bày trong nhiều coding agent trong cùng một repository.
Bạn có thể xây dựng điều này bằng worktree và kỷ luật, hoặc dùng Sharkly để quản lý quy trình. Nếu bạn đã và đang chạy nhiều agent, giá trị nằm ở chỗ có một nơi để task và kết quả của chúng cùng tồn tại thay vì rải rác khắp các terminal.
Checklist cần chạy trước phiên làm việc song song tiếp theo
Hãy chạy những bước này trước khi bạn trỏ hai agent vào bất cứ thứ gì:
- Cho mỗi agent một worktree riêng. Tuyệt đối không để hai agent trong cùng một thư mục làm việc.
git worktree add ../repo-<task> -b agent/<task>cho mỗi task. Xem các agent song song trong worktree được cô lập. - Phạm vi hóa task để chúng không nhắc đến cùng một file hay hàm. Nếu buộc phải nhắc, đó là một task; hãy tuần tự hóa nó.
- Cô lập cả tác dụng phụ, không chỉ file. Tách database, cổng, đường dẫn output và cache ra riêng, hoặc tuần tự hóa các agent dùng chung chúng.
- Rebase trước khi merge khi hai branch chạy trên cùng một commit khởi đầu, để công việc của agent thứ hai nằm trên đầu công việc của agent thứ nhất.
- Chạy kiểm tra kiểu và toàn bộ bộ test sau mỗi lần merge, không phải chỉ sau lần cuối. Các xung đột ngữ nghĩa vượt qua một lần merge sạch và gục ngã ở đây.
- Review từng branch theo phạm vi task của nó, lần lượt từng cái một. Một đống dấu tick xanh chưa đọc chính là nơi xung đột vô hình lọt ra ngoài.
Hai agent cùng sửa một file không phải là một trường hợp hiếm gặp; đó chính là dáng vẻ của công việc song song ngay khi các task của bạn chồng lấn dù chỉ một chút. Hãy lường trước đụng độ, làm cho nó hiển thị rõ, và giữ cho chỉ một người quyết định việc gì được merge.
