AI Agents Cần "Bàn Làm Việc" Riêng: Giải Pháp Từ Git Worktrees

Bạn vừa khởi chạy Claude để thực hiện một nhiệm vụ refactor (tái cấu trúc) code. Bạn biết nó sẽ mất một chút thời gian, và bạn cũng biết chính xác điều gì sẽ xảy ra tiếp theo.

Hoặc là bạn ngồi đó bất động nhìn dòng chữ chạy qua trên màn hình, sợ hãi rằng việc chạm vào bất cứ thứ gì cũng sẽ làm hỏng quá trình đang chạy. Hai mươi phút của bạn trôi qua chỉ vì bạn sợ chính quy trình làm việc của mình.

Hoặc là bạn bắt đầu sửa vài lỗi nhỏ trong lúc chờ đợi. Một lỗi chính tả trong docstring, một import thừa, hay một dòng README đã làm bạn phiền lâu nay. Nhưng khi Agent hoàn thành, nó nhìn vào các thay đổi (diff) và bắt đầu tự nói: "Mình không nhớ đã thêm cái này vào, hãy xóa nó đi". Bạn bất lực nhìn nó hoàn tác công việc của bạn vì nó không nằm trong phạm vi nhiệm vụ được giao.

Cả hai lựa chọn trên đều là một lỗi với các triệu chứng khác nhau. Bạn và Agent đang chia sẻ một thư mục làm việc (working directory), và một thư mục làm việc chỉ có thể chứa một dòng tư duy tại một thời điểm.

Giải pháp không phải là một câu lệnh prompt (gợi ý) tốt hơn hay một phạm vi công việc chặt chẽ hơn. Đó chính là thư mục làm việc thứ hai. Đó chính là những gì Git worktrees mang lại, và bài viết này sẽ giải thích chúng là gì, cách hoạt động, chi phí thiết lập mà ít ai cảnh báo, và một bộ công cụ nhỏ tôi đã xây dựng để loại bỏ chi phí đó.

Nhà phát triển ngồi chờ Agent hoàn thành, sợ chạm vào code

Một thư mục, một dòng tư duy

Một thư mục làm việc chỉ chứa chính xác một dòng tư duy tại một thời điểm. Một Agent chạy trong kho chứa (repo) của bạn thì dễ dàng. Nhưng hai Agent, hoặc một Agent cộng thêm bạn, là nơi mọi thứ bắt đầu vỡ vụn, vì hai thực thể không thể chỉnh sửa cùng một tệp trên đĩa mà không va chạm nhau. Prompt, ngữ cảnh và xem xét không thể sửa chữa điều này. Đó là một ràng buộc vật lý.

Tạo nhánh (branch) cũng không giúp ích gì. Việc chuyển đổi nhánh vẫn làm thay đổi thư mục duy nhất bạn đang mở. Nếu Agent đang sửa đổi một nửa trên nhánh feature/auth và bạn chạy git checkout main để kiểm tra một chi tiết, bạn sẽ không thể chuyển đổi (Git sẽ chặn bạn vì cây đang "bẩn") hoặc bạn sẽ kéo các thay đổi chưa hoàn thành của Agent sang nhánh sai. Dù bằng cách nào, sự cô lập bạn mong muốn cũng biến mất.

Những gì bạn thực sự cần là một bản sao thứ hai của kho chứa mà Agent có thể sở hữu, lý tưởng nhất là không có chi phí của một lệnh git clone đầy đủ và một remote mới. Đó chính xác là định nghĩa của một worktree.

Worktrees trong một câu

Một worktree là một thư mục làm việc thứ hai trỏ đến cùng một kho lưu trữ Git, được khóa ở một nhánh khác.

Nói một cách đơn giản: bạn yêu cầu Git tạo một thư mục mới ở đâu đó trên đĩa của bạn, và nó sẽ lấp đầy thư mục đó bằng các tệp của kho chứa cho một nhánh bạn chọn. Một lệnh, một cờ:

# từ bên trong repo chính của bạn
git worktree add .worktrees/myrepo-auth -b feature/auth

Lệnh đó tạo một thư mục mới tại .worktrees/myrepo-auth bên trong repo của bạn, kiểm tra một nhánh hoàn toàn mới feature/auth vào đó, và để thư mục gốc của bạn hoàn toàn nguyên vẹn. Bây giờ bạn có hai bản checkout của cùng một repo, mỗi cái trên một nhánh riêng, chia sẻ một cơ sở dữ liệu .git bên dưới. Terminal, trình soạn thảo và máy chủ dev cục bộ của bạn tiếp tục chạy trên nhánh bạn đã có, như thể không có gì xảy ra.

Bạn cũng có thể để Claude Code tạo worktree cho bạn trực tiếp. Nó có một cờ gốc --worktree (-w) tạo worktree và khởi chạy phiên làm việc trong một bước:

claude --worktree feature-auth

Các lệnh Worktrees cần nhớ

Năm lệnh sau đây bao gồm vòng đời worktree hàng ngày:

# tạo worktree trên nhánh mới
git worktree add .worktrees/myrepo-auth -b feature/auth

# tạo worktree trên nhánh đã tồn tại
git worktree add .worktrees/myrepo-hotfix hotfix/login

# liệt kê tất cả worktrees
git worktree list

# xóa worktree khi hoàn thành (--force nếu có thay đổi chưa commit)
git worktree remove [--force] .worktrees/myrepo-auth

# dọn dẹp metadata cũ sau khi xóa thủ công bằng rm -rf
git worktree prune

Bên trong một worktree, bạn commit, push, pull, rebase và mở PR y hệt như bạn vẫn luôn làm. Không có phương ngữ Git riêng cho worktree.

Nhánh và Worktree sống trên các trục khác nhau

Mô hình tư duy chính: một nhánh là một dòng cam kết được đặt tên trong lịch sử của repo, không gì hơn. Nó không có vị trí vật lý. Một worktree là một thư mục trên hệ thống tệp của bạn. Đó là nơi bạn có thể xem và chỉnh sửa các tệp cho một nhánh cụ thể.

Một repo, nhiều bàn làm việc

Có hai điều quan trọng cần lưu ý:

1. Xóa worktree không xóa nhánh. Lệnh git worktree remove xóa thư mục vật lý, nhưng nhánh và tất cả các commit của nó vẫn còn trong repo. Thư mục chỉ là một cửa sổ xem. Đóng nó không ảnh hưởng đến lịch sử.
2. Commit hiển thị ngay lập tức trên mọi worktree. Tất cả worktree của bạn chia sẻ một cơ sở dữ liệu .git, vì vậy một commit được tạo ở cái này sẽ hiển thị trong git log của cái khác mà không cần push, pull hay sync.

Worktree dùng để làm gì và không dùng để làm gì

Sự phân chia trục này có một hệ quả thực tế khiến nhiều người vấp phải khi lần đầu cố gắng chạy song song các tác nhân: worktree song song hóa các nhánh, không phải các tác nhân. Git thực thi điều này trực tiếp. Bạn không thể checkout cùng một nhánh ở hai worktree cùng lúc.

Dùng để làm gì: Công việc song song trên các nhánh khác nhau. Kịch bản điển hình: Bạn có một Agent đang lặp lại trên feat/auth với nhiệm vụ mất mười phút. Bạn không muốn ngồi chờ và cũng không muốn chuyển nhánh. Vì vậy, bạn mở một worktree cho feat/billing và bắt đầu công việc tiếp theo ở đó. Khi Agent feat/auth hoàn thành, bạn đổi terminal, không phải đổi nhánh.

Không dùng để làm gì: Nhiều Agent trên cùng một nhánh. Git sẽ từ chối, và ngay cả khi không từ chối, các Agent sẽ đạp lên nhau trong lịch sử chia sẻ. Giải pháp là ở thượng nguồn: phân chia nhiệm vụ thành các nhánh con.

Tại sao vấn đề này trở nên lớn khi Agents xuất hiện?

Worktree đã tồn tại trong Git kể từ năm 2015. Trong phần lớn thập kỷ qua, đó là một tính năng ngách cho người dùng chuyên nghiệp mà không nhiều người cần hay biết đến, vì con người hiếm khi muốn làm việc trên ba nhánh cùng một lúc.

Nhưng AI Agents thì muốn.

Một khi bạn có một công cụ có thể thực hiện đáng tin cậy một nhiệm vụ code trong hai mươi phút ở nền, câu hỏi "tôi có thể chạy bao nhiêu cái như vậy cùng lúc?" trở nên thực tế. Hai? Ba? Năm? Và ngay khi bạn cố chạy hai cái, bạn sẽ gặp vấn đề thư mục làm việc, và worktree bỗng nhiên trở thành câu trả lời rõ ràng.

Sự thay đổi lớn hơn là những gì xảy ra với chính bạn. Khi ba Agent chạy song song, công việc của bạn ngừng là "viết code" và bắt đầu là "phân chia công việc, giao việc, xem xét kết quả". Bạn không còn ở trong bong bóng code nữa, bạn ở trong bong bóng điều phối.

Chi phí thiết lập mà không ai cảnh báo

Trước khi bạn gặp giới hạn tốc độ hay quá tải khi xem xét, bạn sẽ gặp một trần thấp hơn: mọi worktree mới đều cần được khởi tạo từ đầu. Đây là phần mà các bài viết hào hứng thường bỏ qua. Một worktree là một thư mục mới chỉ chứa các tệp mà Git theo dõi. Mọi thứ được đề cập trong .gitignore đều không có ở đó.

Những thứ không có trong một worktree mới:

• node_modules/, .venv/, hoặc bất cứ thứ gì trình quản lý gói của bạn xây dựng. Bạn phải cài đặt lại.
• Các tạo phẩm build như dist/, .next/, target/, hoặc __pycache__/. Lần build đầu tiên luôn lạnh.
• .env và bất cứ thứ gì bạn đã khôn ngoan giữ ra khỏi kiểm soát phiên bản. Ứng dụng của bạn sẽ không khởi động được nếu thiếu chúng.
• Cổng (Ports). Hai worktree đều chạy npm run dev sẽ tranh giành cổng :3000.

Chi phí thiết lập cho một worktree trống

Đối với một repo Python nhỏ, đó là 30 giây phiền toái. Nhưng đối với một monorepo hiện đại với cây node_modules 400 MB, bộ nhớ đệm build Next.js và một .env chứa 12 bí mật, đây là 5 đến 10 phút thiết lập cho mỗi worktree bạn tạo ra.

Giảm chi phí bằng cách để Agent trả tiền

Chi phí thiết lập chính xác là loại công việc dán ghép lặp đi lặp lại, cơ khí, dễ sai mà phần mềm rất giỏi. Cách hiển nhiên là tự động hóa nó: bọc git worktree add, sao chép các tệp .env, chạy lệnh cài đặt.

Thông qua shell script? Câu trả lời đơn giản nhất là bash script. Nó hoạt động tốt cho một repo duy nhất với một stack duy nhất. Nhưng nó cũng nhanh chóng gặp giới hạn. Một script không thể dễ dàng đặt tên nhánh cho bạn khi bạn mô tả một thay đổi bằng một câu. Nó không thể quyết định xem một sửa chữa nhỏ nên đi qua PR hay gộp cục bộ.

Vậy là qua Claude Code Skill? Nếu script quá cứng nhắc, bản năng ngược lại là giao toàn bộ việc đó cho một Agent. Tuy nhiên, các thao tác tệp cơ học, tính toán bù cổng, và các lệnh cài đặt idempotent lại là loại công việc xác định mà Agent lại làm tệ. Nó chậm hơn, có thể trôi dạt giữa các lần chạy.

Kết hợp cả hai là tốt nhất Câu trả lời là sử dụng từng công cụ cho việc nó giỏi:

• Một bash script cho những gì Agent không thể thấy và không nên làm anyway: tạo worktree, sao chép tệp .env, chạy lệnh cài đặt.
• Một tập hợp Claude Code skills cho những gì Agent thực sự giỏi: đặt tên nhánh từ mô tả, chọn chiến lược hợp nhất, viết mô tả PR.

Một công cụ quản lý Worktree cụ thể bạn có thể mượn

Để tiết kiệm giờ kết nối hai lớp này cho bạn, tôi đã viết một bộ công cụ worktree nhỏ và đặt lên GitHub là ThinkVelta/claude-worktree-tools. Nếu bạn muốn dùng nguyên trạng, bạn có thể thả các kỹ năng code Claude và script thiết lập vào bất kỳ repo git nào thông qua một lệnh:

npx @thinkvelta/claude-worktree-tools

Bộ cài đặt sẽ tạo ra scripts/wt-setup.sh và một tập hợp các kỹ năng Claude Code như /wt-open (tạo hoặc mở lại worktree), /wt-merge (hợp nhất cục bộ), /wt-close (dọn dẹp worktree), và /wt-adopt (đọc stack của bạn để điền vào các phần cụ thể của repo trong script thiết lập).

Kết luận

Bạn và AI Agent của bạn không thể chia sẻ một bàn làm việc. Bạn đã cảm thấy điều này mỗi khi ngồi bất động chờ một lệnh chạy xong, hoặc nhìn Agent hoàn tác lặng lẽ một thay đổi bạn thực hiện trong khi nó đang suy nghĩ. Worktrees mang lại cho Agent bàn làm việc của riêng nó, và nó làm điều đó mà không cần clone repo, chiến đấu với remote, hay phát minh ra một quy trình làm việc mới.

Chi phí thực sự duy nhất là chi phí thiết lập, và chi phí thiết lập chính xác là vấn đề mà Agent của bạn được xây dựng để giải quyết. Hãy cho nó một worktree. Sau đó hãy cho nó kỹ năng để thiết lập cái tiếp theo. Đây là một mô hình đáng để nội hóa hóa: bất kỳ công cụ nào tuyệt vời về lý thuyết nhưng quá phiền để thiết lập trong thực tế đều là một kỹ năng đang chờ được viết ra.

Chi tiết chính: Bất cứ khi nào một công cụ tuyệt vời về lý thuyết nhưng việc thiết lập quá phiền phức để sử dụng nhất quán, ma sát đó là một kỹ năng đang chờ được viết. Hãy sử dụng Agent bạn đang chạy để xây dựng công cụ giúp onboard Agent tiếp theo.