Bạn khởi động bốn agent vào sáng nay. Một con refactor module auth, một con viết test, một con chạy theo một job CI chập chờn, và một con vẫn đang suy nghĩ. Đến chiều, bạn chỉ có một cảm giác mơ hồ rằng đã có gì đó xảy ra, một mớ tab terminal, ba worktree mà bạn lờ mờ nhớ là mình đã tạo, và hai pull request bạn chưa đọc. Công việc đã xong. Nhưng bạn không nhìn ra được nó là gì.
Theo dõi công việc đã hoàn thành bởi các AI coding agent là bài toán biến đống phân tán đó thành một bản ghi: mỗi agent đã thay đổi gì, thay đổi đó có vững không, và nó nằm ở đâu. Đây là một vấn đề có thật, vì agent hoàn thành nhanh hơn tốc độ bạn có thể kiểm tra, còn bằng chứng về những gì chúng làm thì nằm rải rác ở những nơi được thiết kế cho một người làm việc đơn lẻ. Hướng dẫn này đi qua cách thiết lập thủ công trước, chỉ ra chỗ nào nó đổ vỡ, rồi trình bày quy trình mà Sharkly dùng để giữ mọi kết quả gắn chặt với task đã yêu cầu nó.
Bản ngắn gọn: bạn có thể theo dõi một vài agent bằng tay với git và terminal. Vượt qua mức đó, bạn cần một nơi chung để kết quả tự quay về, vì nút thắt không còn là việc code nữa mà là khả năng review của bạn.
TL;DR
Theo dõi công việc agent đã hoàn thành nghĩa là trả lời ba câu hỏi cho mỗi lần chạy: thay đổi gì, có đúng không, và nó nằm ở đâu. Lịch sử Git và pull request trả lời được câu hỏi đầu tiên khi bạn chỉ có một hai agent. Khi nhiều agent chạy song song, bản ghi vỡ vụn khắp các worktree, terminal và hàng đợi PR, và bạn mất luôn liên kết giữa task với kết quả của nó. Một task board khắc phục điều này bằng cách để quá trình thực thi, các điểm tắc, kết quả và bước review của con người đều quay về một task, nhờ đó công việc đã hoàn thành có thể kiểm tra được thay vì phải dựng lại từ đầu.
Theo dõi công việc đã hoàn thành nghĩa là gì
Theo dõi không phải là một bản log hoạt động. Đó là khả năng trả lời ba câu hỏi về một lần chạy đã kết thúc mà không phải dựng ngược lại toàn bộ.
- Thay đổi gì. Diff, những file bị chạm tới, lý do cho từng thay đổi.
- Có đúng không. Typecheck, test, build, và bản tóm tắt những gì agent đã kiểm chứng.
- Nó nằm ở đâu. Branch, PR, task mà nó thuộc về, và ai là người nghiệm thu.
Một agent kết thúc trong im lặng thì về mặt kỹ thuật là đã hoàn thành công việc, nhưng bạn không thể làm gì với nó. Trạng thái hoàn thành mà bạn quan tâm là trạng thái mà một con người có thể kiểm tra và nghiệm thu. Đó là lý do “test đã pass” không giống với “công việc đã được theo dõi”.
Mô hình human-in-the-loop cho coding agent vạch ra ranh giới: agent nghiên cứu, thực thi, kiểm thử và báo cáo; con người định hướng và nghiệm thu kết quả. Theo dõi chính là bộ máy giúp nửa sau đó diễn ra.
Cách tự làm, từng bước, và mỗi bước đổ vỡ ở đâu
Với một agent trên một branch, các công cụ có sẵn là đủ. Đây là phiên bản trung thực, chỉ rõ kiểu thất bại ở từng bước.
Bước 1: Xem đã thay đổi gì. Sau một lần chạy, bạn đọc diff.
git log --oneline -10
git diff main...HEAD --stat
Đổ vỡ khi: hai agent dùng chung một branch, hoặc một agent không commit gì mà để thay đổi nằm trong working tree của một worktree bạn đã quên mất. Diff bạn đọc không phải là diff đã được ship.
Bước 2: Cô lập công việc của từng agent. Bạn cấp cho mỗi agent một git worktree riêng để chúng không đụng nhau.
git worktree add ../auth-refactor -b auth-refactor
git worktree list
Đổ vỡ khi: danh sách phình to vượt quá những gì bạn có thể nhớ trong đầu. git worktree list cho bạn biết đường dẫn, chứ không cho biết agent nào đang ở trong đó, nó phục vụ task nào, hay nó đã xong chưa. Xem tài liệu git-worktree chính thức để hiểu về cơ chế; chúng chỉ dừng ở mức ghi chép sổ sách.
Bước 3: Kiểm tra xem kết quả có tới được một PR không. Bạn dựa vào GitHub.
gh pr list --author "@me" --state open
gh pr view 214 --json title,statusCheckRollup
Đổ vỡ khi: PR có tồn tại nhưng không ai viết lý do, hoặc các check xanh trong khi thay đổi lại sai, hoặc PR không có liên kết nào trỏ về yêu cầu đã khởi tạo nó. Tài liệu tham chiếu gh pr list cho bạn thấy các PR đang mở, chứ không cho thấy ý định.
Bước 4: Nhớ xem bạn đã yêu cầu điều gì. Bước này không có câu lệnh nào. Yêu cầu ban đầu nằm trong một tin nhắn Slack, một ghi chú, hoặc trong trí nhớ của bạn. Khi bạn review PR ba ngày sau, bạn chỉ đang đoán mò tiêu chí nghiệm thu.
Mỗi bước đều hoạt động. Vấn đề nằm ở những mối nối giữa chúng. Diff, sự cô lập, PR và ý định nằm ở bốn hệ thống không hề biết đến nhau, và bạn là thứ duy nhất kết nối chúng.
Khi nào cách làm thủ công hết khả năng mở rộng
Điểm vỡ không phải là một khoảnh khắc. Nó là một con dốc, và bạn có thể gọi tên vị trí của mình trên đó.
| Số agent chạy song song | Chi phí theo dõi | Thứ đổ vỡ trước tiên |
|---|---|---|
| 1 | Đọc một diff, một PR | Không có gì |
| 2 đến 3 | Chuyển ngữ cảnh giữa các worktree | Bạn mất dấu agent nào đã làm việc gì |
| 4 đến 6 | Dựng lại ý định cho từng PR | Kết quả vượt xa năng lực review của bạn |
| 7 trở lên | Phối hợp toàn thời gian | Công việc đã xong nằm đó nhiều ngày không ai review |
Chi phí thực sự được đo bằng năng lực review, chứ không phải bằng tốc độ của agent. Agent tạo ra công việc hoàn thành nhanh hơn tốc độ một người có thể kiểm tra, nên khi vượt qua một vài lần chạy, thông lượng của bạn bị giới hạn bởi tốc độ bạn trả lời ba câu hỏi kia, chứ không phải bởi tốc độ agent code. Thêm agent chỉ làm bài toán theo dõi tệ hơn, chứ không làm bài toán bàn giao tốt hơn.
Task board bổ sung được gì
Cách khắc phục là ngừng coi một lần chạy đã xong như một diff, và bắt đầu coi nó như một thứ quay về với một task.
Trong Sharkly, task chính là bản ghi chung. Bạn giao một task cho một agent hoặc một Crew, và lần chạy diễn ra trong một worktree cô lập, nên các agent song song không bao giờ chạm vào cùng một file. Khi xong, quá trình thực thi, các điểm tắc, kết quả và phần theo dõi tiếp theo đều quay về dòng thời gian của task. Bản tóm tắt thay đổi, kết quả kiểm chứng và những giới hạn đã biết đều gắn vào chính task đó, chứ không gắn vào một terminal mà bạn phải còn mở.
Đó là khác biệt giữa một bản log và một bản ghi. Log cho bạn biết đã có chuyện gì đó xảy ra. Bản ghi cho bạn biết cái gì đã thay đổi, nó có đúng không, và nó nằm ở đâu — tất cả trong một chỗ, gắn với yêu cầu đã khởi tạo nó. Bạn review công việc đã xong ngay từ task, nghiệm thu hoặc trả lại, và quyết định đó có tên bạn trên đó.
Đây là lúc những mối nối của cách tự làm được khép lại. Ý định, diff, các bước kiểm tra và việc nghiệm thu cùng nằm trên một đối tượng. Bạn vẫn giữ những công cụ mà agent đang dùng; Claude Code và Codex vẫn đảm nhiệm phần thực thi, còn Sharkly thêm vào lớp task, ngữ cảnh và review xung quanh chúng. Giao việc cho một AI agent khi đó đọc lên giống như giao việc cho một đồng đội, và kết quả quay về đúng nơi bạn có thể tìm thấy.
Bạn có thể tải Sharkly và kết nối một Computer để thử điều này với một task thật duy nhất trước khi mở rộng quy mô.
Khi nào bạn không cần những thứ này
Hãy thành thật về ngưỡng cần thiết. Nếu bạn chạy một coding agent duy nhất, trong một repo duy nhất, và đọc mọi diff trước khi nó merge, thì git và terminal đã theo dõi công việc hoàn thành của bạn rồi. Một task board sẽ chỉ thêm những thủ tục rườm rà mà bạn không cần. Chế độ xem project tích hợp trong Claude Code đã bao quát được nhiều thứ đến mức đáng ngạc nhiên cho quy trình một agent.
Phương trình đổi khác khi ba thứ cộng dồn: nhiều hơn một hai agent cùng lúc, công việc bạn không thể review ngay trong ngày nó xong, và kết quả cần đến tay người khác ngoài bạn. Đó là lúc một bản ghi task chung không còn là gánh nặng, mà trở thành cách duy nhất để công việc đã hoàn thành hiển thị rõ từ lúc đưa ra yêu cầu đến lúc phát hành.
Danh sách kiểm tra bạn có thể chạy ngay hôm nay
Trước khi thêm một agent nữa, hãy xác nhận rằng bạn có thể trả lời “có” cho từng điểm dưới đây với những agent đang chạy:
- [ ] Với bất kỳ lần chạy nào đã xong, bạn có tìm được diff trong vòng chưa đầy một phút mà không cần mở terminal không?
- [ ] Mỗi lần chạy đã hoàn thành có kèm bản tóm tắt những gì agent đã kiểm chứng, chứ không chỉ là những dấu check xanh?
- [ ] Bạn có truy ngược được một PR về yêu cầu đã khởi tạo nó không?
- [ ] Có một nơi nào cho thấy agent nào đang làm gì, cái gì đã xong, và cái gì cần review không?
- [ ] Việc nghiệm thu công việc đã hoàn thành có gắn với tên một con người cụ thể không?
- [ ] Khi một agent hoàn thành, kết quả có tự tìm đến bạn, hay bạn phải đi tìm nó?
Mỗi câu “không” là một mối nối sẽ càng rộng ra khi bạn thêm agent. Sửa sớm sẽ rẻ hơn nhiều so với việc sau này phải dựng lại cả một tuần những lần chạy không được theo dõi.
FAQ
Làm sao để theo dõi những gì một AI coding agent đã thay đổi? Hãy đọc diff, chứ đừng đọc bản tóm tắt của agent về nó. Với một agent, git diff và PR là đủ. Với nhiều agent, hãy giữ mỗi lần chạy trong một worktree riêng và đưa diff cùng bản tóm tắt kiểm chứng về một task chung, để bạn không phải dựng lại nó từ lịch sử cuộn màn hình.
Tôi có thể theo dõi công việc của AI agent chỉ với GitHub không? Với một hoặc hai agent thì được. GitHub cho bạn thấy các PR đang mở và trạng thái check. Nó không cho bạn biết agent nào tạo ra một PR, PR đó phục vụ task nào, hay thay đổi có khớp với ý định ban đầu không, nên nó nhanh chóng trở nên không đủ dùng khi nhiều agent chạy song song.
Tôi có thể chạy bao nhiêu agent trước khi cần một task board? Hầu hết mọi người cảm nhận được những mối nối khi chạy khoảng ba đến bốn agent song song, lúc mà việc dựng lại ý định cho từng PR bắt đầu ngốn nhiều thời gian hơn cả việc review. Yếu tố kích hoạt là năng lực review, chứ không phải một con số cố định. Xem ghi chú của chúng tôi về quản lý các coding agent chạy song song.
Task board có làm chậm những agent chạy nhanh không? Không. Agent vẫn thực thi trong các worktree cô lập với tốc độ tối đa. Board chỉ thêm một đường quay về để công việc đã xong của chúng đáp xuống một nơi mà bạn có thể review, nhờ đó loại bỏ bước dựng lại thủ công thay vì thêm vào một bước.
