Nếu bạn từng chạy nhiều hơn một AI coding agent trên cùng một repo cùng lúc, bạn đã biết kiểu lỗi này: agent A checkout một branch, bắt đầu sửa code, agent B (cùng repo, cùng working directory) checkout branch khác giữa chừng — và thế là các thay đổi chưa commit của agent A nằm nhầm branch, hoặc tệ hơn, biến mất không dấu vết. Ngày 7 tháng 8 năm 2026, GitHub triển khai một bản fix — thực chất là một lời thừa nhận đã trễ hơn là một tính năng mới: các agent session của Copilot, Claude, và Codex trong VS Code giờ mỗi cái có một git worktree riêng biệt, cộng thêm tính năng “peer chat” forking và session song song /side không làm mất context của cuộc hội thoại chính.

Vấn Đề Của Các AI Agent Session Chạy Song Song

Mọi AI coding agent đều cần một working directory để sửa file, chạy test, xem diff. Trước bản cập nhật này, mặc định là một working directory dùng chung cho mỗi repo — ổn nếu bạn chỉ chạy một agent, nhưng thảm họa nếu không. Workflow đa agent giờ đã phổ biến đến mức không còn là trường hợp hiếm: bắt đầu một refactor với Claude, nhờ Copilot viết test song song, và để Codex điều tra một lỗi CI chập chờn — tất cả trên cùng một checkout — và bạn chỉ cách một lệnh git checkout là làm lẫn lộn ba diff không liên quan.

Các team trước đây tự khắc phục bằng tay, thường là script git worktree tự viết gắn vào shell alias. Đó chính xác là thứ GitHub đã tích hợp thẳng vào editor.

Thực Sự GitHub Đã Làm Gì

Mỗi agent session giờ có worktree riêng, được VS Code tạo và dọn dẹp tự động:

# những gì VS Code thực hiện ngầm khi bạn bắt đầu một agent session
git worktree add ../repo-agent-session-a7f3 -b agent/refactor-auth-a7f3

Agent hoạt động hoàn toàn bên trong worktree đó — working directory riêng, index riêng, nhưng vẫn dùng chung object database .git với checkout chính của bạn. Khi session kết thúc (hoặc bạn hủy bỏ), VS Code sẽ dọn worktree:

git worktree remove ../repo-agent-session-a7f3
git worktree prune

Bạn có thể kiểm tra bất cứ lúc nào theo cách bạn vẫn luôn làm:

git worktree list
# /home/dev/repo                        abc1234 [main]
# /home/dev/repo-agent-session-a7f3      def5678 [agent/refactor-auth-a7f3]
# /home/dev/repo-agent-session-b91c      9ab0cde [agent/flaky-ci-investigation]

Bên cạnh worktree isolation, GitHub thêm hai tính năng ở cấp chat: peer chat, fork một cuộc hội thoại agent đang có (giữ nguyên toàn bộ lịch sử) thành một session thứ hai để bạn thử hướng tiếp cận khác mà không mất thread gốc, và /side, một câu hỏi phụ nhẹ nhàng bạn có thể hỏi cùng agent mà không làm gián đoạn tác vụ chính — kiểu như “nhanh gọn, hàm này làm gì” mà không khiến agent mất mạch trong một refactor nhiều bước.

Vì Sao Là Worktree, Không Phải Branch

Cách sửa ngây thơ hiển nhiên là “cứ dùng branch là được.” Lý do cách đó không hoạt động là vì bản thân working directory mới là tài nguyên dùng chung, không chỉ là ref. Hai branch không thể được checkout vào một working directory cùng lúc — đó chính là vấn đề gốc. Worktree giải quyết đúng ở tầng này: cùng một repository, cùng object database (không nhân bản lịch sử .git, không phải clone lại tốn kém), nhưng working directory và index thực sự tách biệt. Đây chính là primitive mà các kỹ sư senior đã dùng nhiều năm để build hotfix mà không cần stash một feature đang dang dở — GitHub chỉ đơn giản là biến nó thành đơn vị mặc định cho việc cách ly agent, thay vì một thói quen thủ công.

Điều Này Thay Đổi Gì Cho Workflow Của Team

Kỷ luật dọn dẹp disk giờ quan trọng hơn. Mỗi agent session song song là một bản sao làm việc đầy đủ của repo (worktree dùng chung object storage nhưng không dùng chung file working-tree). Với monorepo lớn, năm sáu agent session sống cùng lúc có thể cộng dồn nhanh chóng. Hãy để ý các worktree mồ côi từ những session bị crash hoặc bỏ dở — git worktree list và git worktree prune định kỳ nên nằm trong quy trình bảo trì thường xuyên của team, giống như cách bạn dọn các feature branch cũ.

Merge conflict chuyển sớm hơn, chứ không biến mất. Isolation ngăn các agent giẫm chân nhau ở working directory, nhưng không ngăn chúng sửa cùng file theo cách xung đột khi bạn merge lại. Nếu bạn cho ba agent cùng đụng vào module auth, bạn vẫn sẽ gặp three-way merge — chỉ là đã dời việc va chạm từ “ghi đè âm thầm trong lúc chạy” sang “conflict lúc merge,” tốt hơn hẳn nhưng không phải là hết conflict.

Code review cần một mental model theo từng worktree. Nếu tooling review của bạn mặc định một working directory cho mỗi repo (một số tool diff/lint local vẫn vậy), bạn có thể cần trỏ thẳng vào đường dẫn worktree của agent/refactor-auth-a7f3 thay vì giả định HEAD trong checkout chính phản ánh đúng những gì agent đã tạo ra.

Những Đánh Đổi

Đây không phải miễn phí. Worktree vẫn tốn disk thật cho file working-tree, các binary lớn được checkout sẽ nhân lên theo từng session, và bất kỳ tooling pre-commit hay IDE nào hardcode một đường dẫn repo duy nhất sẽ cần nhận biết worktree. Không có gì mới ở đây — đó là chi phí tiêu chuẩn của git worktree — nhưng việc “editor tự động làm điều này cho mọi agent session” nghĩa là chi phí giờ scale theo số lượng agent bạn chạy, chứ không phải theo số worktree bạn chủ động tạo bằng tay.

Các Bước Thực Tế Cho Team

  1. Đặt ngân sách worktree. Quyết định team bạn chịu được bao nhiêu agent session song song xét về disk/CI, và coi worktree mồ côi là vấn đề linting — viết script kiểm tra dọn dẹp vào setup môi trường dev.
  2. Phân chia agent theo quyền sở hữu file, không chỉ theo task. Nếu hai agent có khả năng đụng cùng module, hoặc serialize các task đó, hoặc chấp nhận bạn sẽ mua một merge conflict về sau.
  3. Trỏ tooling local vào đúng đường dẫn worktree — đừng giả định . là nơi thay đổi của agent nằm.
  4. Dùng /side cho những câu hỏi thực sự nhanh gọn, và dành peer-chat forking cho những lúc thực sự cần “thử hướng khác” — cả hai đều rẻ, nhưng fork toàn bộ lịch sử session cũng không phải context miễn phí để mang theo.

Xu Hướng Lớn Hơn

Đây là cùng một pattern đang diễn ra trên toàn bộ AI tooling stack: những primitive từng là thói quen thủ công của các kỹ sư cẩn thận (worktree, môi trường sandbox, credential cách ly) đang trở thành hạ tầng mặc định ngay khi AI agent biến concurrency thành chuyện bình thường thay vì ngoại lệ. Câu hỏi dài hạn thú vị không phải là editor của bạn có cách ly agent session hay không — mà là quy trình review, CI, và merge của team bạn đã sẵn sàng cho việc “ba agent cùng sửa một repo ngay lúc này” là chuyện thường ngày, chứ không phải sự cố, hay chưa.

Thuận Lương là một Technical Lead với hơn 15 năm kinh nghiệm về .NET, kiến trúc cloud, và hệ thống AI. Anh viết về những bài học thực tế từ việc xây dựng hệ thống production.

Xuất nội dung

Bình luận