Sáng nay bạn bật ba coding agent. Một con đang refactor module auth, một con đang viết test, còn một con đang xử lý một CI job chập chờn. Một giờ sau, trước mắt bạn là năm terminal đang mở, hai pane tmux đã detach, cùng một linh cảm chẳng lành rằng ít nhất một con đã dừng từ lâu và nằm bất động trong lúc bạn không để ý. Bạn Alt-Tab qua lại, cuộn log, rồi đoán mò.
Chính việc phải đoán mò đó mới là cái giá thực sự khi chạy agent song song. Việc khởi chạy nhiều coding agent cùng lúc giờ đây quá dễ dàng. Nhưng biết được con nào đang cần bạn can thiệp, con nào đang bị kẹt, và con nào đã âm thầm hoàn thành mới là thứ ngốn sạch cả buổi chiều của bạn. Giám sát các coding agent chạy song song đồng nghĩa với việc trả lời được bốn câu hỏi theo thời gian thực mà không cần phải mở năm cửa sổ: từng agent đang làm gì, tiến độ đến đâu, điều gì đang cản trở nó, và kết quả nào trả về đang cần bạn review.
Bài hướng dẫn này trước tiên sẽ điểm qua cách tự thiết lập hệ thống giám sát thủ công (DIY), chỉ rõ các điểm gãy ở từng bước, sau đó phân tích vì sao cách làm này không còn mở rộng được nữa và một tầng tác vụ dùng chung sẽ mang lại giá trị gì. Tầng dùng chung đó chính là Sharkly: bạn đã có sẵn các coding agent, và Sharkly sẽ biến chúng thành một đội ngũ thực sự bằng cách tập trung tiến độ, các điểm nghẽn và kết quả của từng agent vào một nơi duy nhất thay vì nằm rải rác khắp các terminal. Bạn hoàn toàn có thể tự dựng hầu hết quy trình giám sát này. Mục đích của việc xem xét cả hai cách là để bạn biết chính xác thời điểm mà hệ thống tự dựng bắt đầu gây tốn kém công sức hơn là tiết kiệm thời gian.
Bốn tín hiệu đáng theo dõi
Giám sát không chỉ đơn giản là một thao tác duy nhất. Khi mọi người nói một lượt chạy của agent "trông có vẻ ổn", họ thường ám chỉ một trong bốn tín hiệu riêng biệt, và mỗi tín hiệu lại có một cách gặp sự cố khác nhau.
- Trạng thái (State). Tiến trình đang chạy, đang chờ dữ liệu đầu vào, đã hoàn tất hay đã chết? Một agent chạy xong và một agent bị treo đều không xuất thêm output nào mới, vì thế sự im lặng tự nó chẳng nói lên điều gì.
- Tiến độ (Progress). Tác vụ đã hoàn thành được bao nhiêu phần? Các mục trong kế hoạch đã được đánh dấu, các file đã được chỉnh sửa, các bài test đã pass. Tiến độ là yếu tố cho bạn biết một agent đang chạy có thực sự tiến triển hay chỉ đang lặp vô tận.
- Điểm nghẽn (Blockers). Agent đang phải chờ đợi điều gì? Một yêu cầu cấp quyền, một biến môi trường bị thiếu, một xung đột khi merge, hay một câu hỏi nó đưa ra mà chưa ai trả lời.
- Kết quả cần review (Output needing review). Agent đã tạo ra những gì mà con người cần phải duyệt hoặc từ chối? Một bản diff, một PR, hay một bản tóm tắt các thay đổi.
Nếu chỉ theo dõi trạng thái, bạn sẽ bỏ sót agent vẫn đang chạy nhưng lại mắc kẹt trong vòng lặp thử lại. Nếu chỉ theo dõi tiến độ, bạn sẽ bỏ lỡ con đã hoàn thành từ hai mươi phút trước. Một hệ thống giám sát chuẩn mực phải làm nổi bật cả bốn tín hiệu này cho từng agent, chỉ qua một cái nhìn lướt qua.
Bước 1: Giám sát theo cách thủ công và lỗ hổng ở từng bước
Cách thiết lập thủ công tận dụng các công cụ bạn đã có sẵn. Dưới đây là bức tranh thực tế, cùng những thiếu sót mà mỗi bước để lại.
Xem những gì đang chạy. Nếu mỗi agent chạy trong một git worktree riêng, hãy liệt kê chúng cùng các nhánh tương ứng:
git worktree list
tmux ls # if each agent runs in a tmux session
Điểm gãy: cách này chỉ cho bạn biết một session đang tồn tại, chứ không cho biết agent bên trong đang làm việc hay đang chờ. Một pane tmux bị nghẽn ở dấu nhắc Continue? (y/n) trông chẳng khác gì một pane đang xử lý dở tác vụ. Bạn chỉ phát hiện ra khi attach vào session đó.
Theo dõi tiến độ. Dùng tail để xem output của từng agent và thăm dò worktree của nó để phát hiện thay đổi:
tail -f /path/to/agent-1.log
watch -n 5 'git -C ../wt-auth status --short'
Điểm gãy: cách này tăng độ phức tạp tỷ lệ thuận với số lượng agent. Ba file log thì còn đọc được. Sáu luồng tail log đan xen vào nhau thì không thể, và vòng lặp watch chỉ cho bạn thấy sự biến động của file chứ không mang lại ý nghĩa thực tế. Bạn thấy các file liên tục thay đổi mà không hề biết liệu thay đổi đó có đúng hay không, hoặc liệu agent có đang lặp đi lặp lại cùng một việc hay không.
Bắt sự kiện hoàn thành. Bọc lệnh của từng agent để nó gửi thông báo cho bạn khi tiến trình thoát:
your-agent-command "$TASK"; \
curl -s -X POST "$WEBHOOK_URL" -d "agent-1 exited $?"
Điểm gãy: exit code 0 chỉ có nghĩa là tiến trình đã kết thúc, chứ không đồng nghĩa với việc công việc đạt chất lượng hay thậm chí đã hoàn thành. Rất nhiều agent thoát một cách êm đẹp sau khi đưa ra một câu hỏi mà bạn chưa từng nhìn thấy. Một thông báo "đã xong" khiến bạn tin vào một tín hiệu thực chất không hề có nghĩa là đã xong.
Phát hiện xung đột. Khi nhiều agent dùng chung một repository, worktree giúp tách biệt các thư mục làm việc, nhưng việc hai agent cùng sửa một file trên hai nhánh khác nhau vẫn sẽ dẫn đến xung đột khi merge.
git worktree list --porcelain | grep branch
Điểm gãy: bạn chỉ phát hiện ra sự chồng chéo khi tiến hành merge, mà đây lại là thời điểm tốn kém chi phí nhất để xử lý nó.
Những cách làm trên không hề sai. Với hai hoặc ba agent làm các tác vụ không liên quan, vài pane tmux cùng một vòng lặp watch là một giải pháp giám sát hợp lý, và bạn chưa cần đến thứ gì phức tạp hơn. Cứ giữ cho hệ thống tinh gọn nhất có thể cho đến khi bạn chạm phải giới hạn.
Nơi cách giám sát thủ công không còn mở rộng được nữa
Giới hạn xuất hiện khi bạn chạy nhiều agent đến mức không một màn hình nào có thể chứa hết. Ba vấn đề sau sẽ cộng dồn lại:
Thăm dò chỉ báo trạng thái, không nêu nguyên nhân. git status và lệnh tail log cho bạn thấy có gì đó đã thay đổi hoặc output đã dừng lại. Chúng không thể cho bạn biết agent đang bị kẹt ở một prompt, hay thiếu dependency, hay đã hoàn tất. Rốt cuộc, bạn phải attach vào từng session để chẩn đoán, điều này đi ngược lại hoàn toàn với mục tiêu ban đầu của việc chạy song song là loại bỏ việc nhảy qua nhảy lại giữa các terminal.
Không có trạng thái dùng chung. Việc giám sát nằm cục bộ trên laptop của bạn, trong tmux server, trong lịch sử shell. Đồng nghiệp không thể thấy agent nào đang phụ trách tác vụ nào, và chính bạn cũng chẳng thấy được gì sau khi gập máy lại. Khi một agent chạy trên máy chủ từ xa, cách tiếp cận tail log cục bộ sẽ hoàn toàn vô dụng.
Khâu review trở thành điểm nghẽn cổ chai. Đây là điều mà mọi người thường đánh giá thấp. Việc chạy song song các agent sẽ chẳng còn ích lợi gì nếu khâu review kết quả của chúng lại bị dồn ứ tuần tự thành một hàng đợi chỉ có một người xử lý. Năm bản diff đã hoàn thành nhưng không có một nơi chung để theo dõi "reviewed / changes requested / merged" đồng nghĩa với việc bạn phải mở năm tab trình duyệt và tự ghi nhớ trong đầu. Agent làm nhanh hơn, nhưng con người thì chậm đi.
Tại thời điểm đó, thứ bạn thiếu không phải là thêm nhiều cửa sổ terminal. Thứ bạn thiếu là một bản ghi dùng chung.
Giá trị của bảng tác vụ: kết quả quy về một mối
Một tầng tác vụ thay đổi đơn vị giám sát từ "một tiến trình trong một pane" thành "một Task có trạng thái". Đây chính là bước chuyển dịch cốt lõi của Sharkly, và nó ánh xạ trực tiếp vào bốn tín hiệu kể trên.
Mỗi lượt chạy của agent được gắn với một Task. Trạng thái, tiến độ, điểm nghẽn và kết quả đều quay về dòng thời gian của Task đó thay vì nằm trong một file log mà chỉ mình bạn xem được. Thay vì phải liên tục thăm dò, bạn theo dõi trên một bảng điều khiển: Task nào đang thực hiện, Task nào đang bị nghẽn, Task nào đã xong và đang chờ bạn. Hộp thư Inbox của Sharkly là nơi hiển thị những lượt chạy cần sự can thiệp của con người, nhờ đó câu hỏi không còn là "đã có con nào chạy xong chưa?" mà trở thành "đây là những việc đang cần mình đưa ra quyết định". Agent nghiên cứu, thực thi, viết test và báo cáo; con người định hướng, cấp quyền và nghiệm thu kết quả. Tự động hóa sẽ dừng lại ở nơi cần đến sự phán đoán.
Ranh giới ở đây rất quan trọng, vì rất dễ hiểu lầm: Sharkly không trực tiếp chạy agent hay viết code. Claude Code, Codex và các runtime khác mà bạn đang dùng vẫn đảm nhiệm phần thực thi. Sharkly bổ sung tầng tác vụ dùng chung, máy tính, ngữ cảnh và lớp review bao quanh chúng, để tiến độ của một lượt chạy cùng bản diff của nó được đưa về một nơi mà cả nhóm có thể theo dõi xuyên suốt từ lúc yêu cầu đến khi phát hành. Nền tảng này cũng giữ mỗi lượt chạy trong một worktree cô lập riêng, nhờ đó tình trạng xung đột trên cùng một file mà bình thường bạn chỉ phát hiện ra khi merge sẽ được kiểm soát độc lập theo từng Task.
Quy tắc đưa ra quyết định thực tế: nếu bạn chỉ chạy một hoặc hai agent cho các tác vụ độc lập và không bao giờ bàn giao công việc cho ai khác, việc tự giám sát thủ công là đủ và Sharkly sẽ là dư thừa. Nhưng bài toán sẽ thay đổi khi số lượng agent vượt quá số màn hình bạn có, khi tác vụ chạy trên các máy tính mà bạn không ngồi trực tiếp, hoặc khi những người khác cần xem chung một bảng theo dõi. Nếu bạn muốn tiếp tục sử dụng nhiều coding agent khác nhau thay vì bị bó buộc vào một hệ sinh thái duy nhất, thì góc nhìn dùng chung đó chính là bài toán mà Sharkly được thiết kế để giải quyết. Để có cái nhìn toàn diện hơn về những gì cần hiển thị trên bảng điều khiển đó, hãy xem dashboard của AI coding agent thực sự cần hiển thị những gì.
Checklist giám sát bạn có thể áp dụng ngay hôm nay
Dù bạn tiếp tục tự dựng hay chuyển sang dùng một tầng dùng chung, một hệ thống giám sát agent chạy song song cần phải trả lời được các câu hỏi sau mà không đòi hỏi bạn phải attach vào bất kỳ session nào:
- Mỗi agent gắn liền với một tác vụ có tên rõ ràng. Không còn những cái tên vô danh như “agent-3”. Bạn phải có thể nói rõ từng con đang làm gì.
- Trạng thái hiển thị rõ ràng chỉ qua một cái nhìn. Đang chạy, chờ dữ liệu, hoàn tất hay thất bại được phân biệt rành mạch, không phải suy đoán từ sự im lặng.
- Agent bị nghẽn phải biết "giơ tay" báo hiệu. Một prompt đang chờ nhập
y/n, một secret bị thiếu, hay một câu hỏi chưa có lời đáp phải nổi lên cho bạn thấy thay vì âm thầm đình trệ. - Hoàn thành đồng nghĩa với việc sẵn sàng để review, không chỉ là đã thoát tiến trình. Một lượt chạy hoàn tất phải trỏ đến một bản diff hoặc PR cụ thể, chứ không chỉ đưa ra một mã exit code.
- Khâu review có trạng thái riêng. Các trạng thái đã review, yêu cầu sửa đổi và đã merge được theo dõi rõ ràng, để luồng công việc song song không bị tắc nghẽn thành một hàng đợi review xử lý từng cái một.
- Khả năng theo dõi không bị mất khi gập laptop và có thể chia sẻ được. Trạng thái được lưu trữ ở một nơi khác ngoài lịch sử shell của bạn.
- Các tác vụ trên cùng repo được cô lập. Mỗi agent có một worktree riêng, và sự trùng lặp file phải được phát hiện trước khi merge chứ không phải trong khi merge.
Hãy đối chiếu danh sách trên với thiết lập hiện tại của bạn. Những mục bạn chưa thể đánh dấu kiểm hôm nay chính là những thứ sẽ làm bạn mất trắng cả buổi chiều sau này. Nếu bạn đang chạy nhiều agent cùng lúc, Sharkly mang đến cho bạn một nơi duy nhất để quản lý các tác vụ và kết quả của chúng. Bạn cũng có thể chạy các coding agent hiện có qua Sharkly mà vẫn giữ nguyên các runtime bạn đang sử dụng.
