Bạn bắt đầu với một terminal và Claude Code. Rồi một task thứ hai ập đến, bạn mở thêm một terminal nữa và khởi động Codex trên đó. Một bản sửa frontend lại được đẩy sang terminal thứ ba. Giờ bạn cứ alt-tab qua lại giữa ba cửa sổ, cố nhớ xem cửa sổ nào đang chờ mình, cửa sổ nào đã hỏi một câu từ mười phút trước, và cửa sổ nào đã lặng lẽ xong việc rồi ngồi không trong khi bạn đốt sự chú ý vào hai cửa sổ còn lại. Chẳng có gì đang cháy cả. Nhưng bạn đã trở thành thứ định tuyến công việc giữa các agent, và công việc đó mở rộng tệ hơn bất kỳ agent nào.
Terminal không phải là cái tốn kém. Bạn mới là. Khi agent chạy thủ công, mọi quyết định về việc tiếp theo sẽ làm gì đều nằm ở một nơi duy nhất: trong đầu bạn. Agent nào nhận task tiếp theo, diff vừa rồi có an toàn không, cái gì đã hỏng trong lúc bạn đang đọc một cửa sổ khác. Việc điều phối đó là công việc thật, không được trả công, và nó tăng nhanh hơn số agent bạn thêm vào.
Bài viết này phân tích xem chạy coding agent thủ công thực sự tốn những gì, hóa đơn ấy nấp ở đâu cho đến khi nó chồng chất, và quy trình giúp loại bỏ phần lớn chi phí đó. Sharkly là lớp quản lý nằm phía trên các agent của bạn: bạn vẫn giữ Claude Code, Codex hay bất kỳ runtime nào bạn đang dùng, còn Sharkly giữ task, sự cô lập và việc review trong một nơi chung thay vì trải khắp một bức tường terminal.
TL;DR
Chạy coding agent thủ công trông như miễn phí vì chẳng công cụ nào tính tiền cho việc đó. Chi phí thực sự là sự chú ý của bạn: bạn trở thành bộ định tuyến giữa các agent, bộ nhớ lưu việc từng con đang làm, và người review duy nhất phải cập nhật mọi cửa sổ. Chi phí đó còn nhỏ khi có hai, ba agent và chồng chất khi vượt qua năm. Bạn có thể tiếp tục làm thủ công, hoặc định tuyến các agent hiện có qua một lớp task như Sharkly — nơi giao việc, cô lập từng lượt chạy và trả mọi kết quả về một Task để review.
Vấn đề không nằm ở terminal, mà ở chính bạn
Đây là định nghĩa đáng ghi nhớ: terminal là nơi agent chạy; task là công việc mà nó chạy trên đó. Khi bạn quản lý agent thủ công, chẳng có gì kết nối hai thứ đó ngoài chính bạn. Terminal hiển thị output. Nó không biết task là gì, đã xong chưa, hay ai quyết định bước tiếp theo. Bạn phải cung cấp tất cả những thứ đó từ trí nhớ, từng cửa sổ một.
Đó là lý do “quá nhiều terminal” chỉ là triệu chứng, không phải căn bệnh. Chia một agent ra năm pane bằng tmux không làm giảm việc điều phối; nó chỉ sắp xếp lại mà thôi. Bạn vẫn phải giữ tấm bản đồ: pane nào phụ trách task nào, cái nào đang chạy dở, cái nào đã xong và cần người xem qua. Tấm bản đồ ấy không nằm ở đâu chia sẻ được, nên vừa rời đi là nó lỗi thời, và đến lúc đồng đội cần thì nó không tồn tại.
Chạy agent thủ công thực sự tốn những gì
Hóa đơn được trả bằng sự chú ý, và sự chú ý có một cái giá đo đếm được. Khi chuyển đổi giữa những task không liên quan, bạn không thể quay lại ngay lập tức. Nghiên cứu về công việc tri thức bị ngắt quãng của Gloria Mark và các cộng sự, công bố tại CHI 2008, cho thấy trung bình một người mất hơn hai mươi phút để quay lại task đang làm sau khi bị kéo sang việc khác. Bản tóm tắt của Hiệp hội Tâm lý học Hoa Kỳ về nghiên cứu chuyển đổi task ước tính mức mất năng suất do chuyển qua lại giữa các task lên tới 40 phần trăm. Mỗi lần một agent chạy xong và bạn xoay sang cửa sổ khác, bạn lại trả một phiên bản nào đó của thứ thuế ấy.
Chạy agent thủ công biến việc chuyển đổi đó thành vòng lặp chính của bạn. Đây là những nơi chi phí tích tụ:
| Chi phí ẩn | Biểu hiện khi làm thủ công | Vì sao nó chồng chất |
|---|---|---|
| Định tuyến | Bạn tự quyết định agent nào nhận mỗi task mới, dựa vào trí nhớ | Càng nhiều agent thì càng nhiều cặp ghép phải ghi nhớ trong đầu |
| Nạp lại ngữ cảnh | Bạn đọc lại từng terminal để nhớ nó đang làm gì | Mỗi lần chuyển đổi, đồng hồ lại đếm lại từ đầu để bạn quay về đúng task đó |
| Trạng thái lệch pha | Mỗi terminal mang branch, env và những chỉnh sửa dang dở riêng | Hai task trong cùng một thư mục âm thầm phá hỏng lẫn nhau |
| Tồn đọng review | Bạn là người duy nhất chứng kiến mỗi lượt chạy diễn ra | Công việc đã xong phải chờ đúng một người có thể review nó |
| Không có bản ghi chung | Trạng thái chỉ nằm trong phiên làm việc của bạn, không nơi nào đồng đội xem được | Bạn rời đi là tiến độ biến mất; không ai có thể tiếp tục |
Không có cái nào trong số này biểu hiện thành một cú crash. Chúng biểu hiện thành một ngày có vẻ bận rộn nhưng chỉ tạo ra ba PR được merge thay vì tám, mà bạn không thể chỉ ra bất kỳ khoảnh khắc cụ thể nào là nguyên nhân.
Các kiểu lỗi chỉ lộ ra khi chúng chồng chất
Với hai agent, bạn có thể giữ toàn bộ tấm bản đồ trong trí nhớ làm việc và chi phí gần như bằng không. Điều này cần nói thẳng, vì đây là chỗ hầu hết lời khuyên phóng đại vấn đề: nếu bạn chạy một hoặc hai agent trên một máy và review từng cái trước khi bắt đầu cái tiếp theo, bạn chưa cần lớp quản lý. Hãy giữ số thành phần chuyển động ở mức không.
Phương trình thay đổi khi công việc chồng lấn về thời gian hoặc về trạng thái. Chạy ba agent trong cùng một checkout và bạn gặp vấn đề cô lập đã bàn trong nhiều coding agent trong cùng một repository: hai agent chạm vào cùng những file, và một con âm thầm ghi đè lên con kia. Khắc phục bằng một worktree cho mỗi task — nguyên tắc trong coding agent worktrees — thì bạn đổi vấn đề merge lấy vấn đề ghi chép: thư mục nào ứng với task nào, cái nào xoá được an toàn, cái nào con người đang review dở. Giải quyết bằng cách thêm terminal thì bạn lại quay về vạch xuất phát, chỉ khác là có nhiều cửa sổ hơn.
Chi phí cuối cùng là cái âm thầm. Khi mọi lượt chạy đều diễn ra trong một terminal riêng, công việc đã xong không có nơi nào để đi ngoài sự chú ý của bạn. Review trở thành nút thắt, vì bạn là người duy nhất xem agent làm việc và là người duy nhất có thể nói diff có tốt hay không. Chạy agent song song chẳng ích gì nếu việc review output của chúng bị dồn hết vào một người. Đó chính là cái bẫy được mô tả trong vì sao coding agent tốt nhất quan trọng ít hơn cách bạn quản lý chúng: model nhanh hơn, còn hàng đợi review của bạn thì không.
Lớp quản lý giúp loại bỏ những gì
Một task board loại bỏ đúng phần bạn đang làm thủ công: vai trò mô liên kết giữa agent và công việc. Trong Sharkly, Task là đơn vị sở hữu lượt chạy. Bạn giao một Task cho một Agent, Sharkly chuẩn bị một worktree cô lập cho nó trên một Computer đã kết nối, chạy phiên agent ở đó, rồi trả diff, log và mọi điểm tắc nghẽn về Task đó. Việc định tuyến, sự cô lập và bản ghi mà bạn từng giữ trong đầu giờ trở thành thuộc tính của Task.
Điều đó giữ cho sự phân công lao động rõ ràng. Agent nghiên cứu, thực thi, kiểm thử và báo cáo; con người định hướng, trao quyền và nghiệm thu kết quả. Sharkly không thay thế Claude Code, Codex hay runtime bạn đang dùng; những công cụ đó thực hiện phần thực thi. Nó bổ sung lớp task chung, Computer đã kết nối và lớp review bao quanh chúng, để ngữ cảnh, tiến độ, điểm tắc nghẽn, kết quả và việc review của con người luôn hiển thị từ lúc đưa yêu cầu đến lúc phát hành, thay vì nằm rải rác trong năm phiên chỉ mình bạn thấy được. Khi bạn cần theo dõi nhiều lượt chạy cùng lúc, đó mới là mục đích thực sự của một agent dashboard, và đó cũng là lý do các đội ngũ cuối cùng muốn có lớp nằm trên Claude Code và Codex thay vì thêm một terminal nữa.
Nếu bạn đang chạy nhiều agent, đó chính là quy trình mà Sharkly được xây dựng xoay quanh. Bạn có thể tiếp tục định tuyến thủ công qua các terminal, hoặc chạy các coding agent hiện có qua Sharkly và để task board giữ tấm bản đồ.
Khi nào chạy thủ công là ổn, và khi nào thì không
Quy tắc quyết định trung thực rất ngắn gọn:
- Chạy agent thủ công khi bạn chỉ có một hoặc hai con, trên một máy, và bạn review từng cái trước khi bắt đầu cái tiếp theo. Chi phí phụ trội của bất kỳ công cụ nào lúc này vẫn chưa đáng.
- Chuyển sang một lớp task khi agent thứ ba xuất hiện, công việc trải trên nhiều repository, hoặc có ai đó ngoài bạn cần thấy cái gì đang chạy. Đó là điểm mà chi phí điều phối không còn vừa với đầu của một người nữa.
Dấu hiệu không phải là số lượng terminal. Mà là khoảnh khắc bạn thấy mình tự hỏi “khoan đã, cái đó ở cửa sổ nào nhỉ?”. Câu hỏi đó chính là thứ thuế điều phối hiện lên thành lời, và cũng là tình trạng hỗn loạn agent mà một task board ra đời để chấm dứt.
Câu hỏi thường gặp
Tmux hay một terminal multiplexer là không đủ sao? Nó sắp xếp các cửa sổ; nó không loại bỏ việc điều phối. Bạn vẫn phải giữ pane nào phụ trách task nào, cái gì đã xong và ai review nó. Multiplexer giải quyết diện tích màn hình. Còn chi phí chạy agent thủ công là sự chú ý, không phải số pixel.
Tôi có thể chạy thủ công bao nhiêu agent trước khi thấy đuối? Hầu hết mọi người vẫn ổn với một hoặc hai, và bắt đầu thấy mệt khi lên ba đến năm, đặc biệt là khi làm trên nhiều repository. Con số chính xác phụ thuộc vào mỗi task chạy bao lâu và cần review bao nhiêu. Dấu hiệu nhận biết là khi việc định tuyến và đọc lại các cửa sổ chiếm nhiều thời gian trong ngày hơn cả việc review thực sự.
Task board có làm agent của tôi nhanh hơn không? Không, và Sharkly cũng không tuyên bố như vậy. Các agent chạy với tốc độ y hệt. Cái thay đổi là chi phí phụ trội của bạn: định tuyến, cô lập và review không còn nằm trong đầu bạn nữa mà bắt đầu quay về một Task, nơi công việc hiển thị rõ ràng và có thể review.
Còn việc giữ ngữ cảnh xuyên các phiên thì sao? Terminal riêng tư mất ngữ cảnh ngay khi bạn đóng chúng. Gắn một lượt chạy với một Task giữ mục tiêu, diff và thảo luận lại với nhau — đó là bài toán giữ ngữ cảnh xuyên phiên được giải ở tầng bản ghi thay vì bằng trí nhớ.
Tôi vẫn có thể dùng Claude Code và Codex cùng nhau theo cách này chứ? Có. Sharkly quản lý công việc xoay quanh các công cụ; nó không thay thế chúng. Xem cách chạy Claude Code và Codex cùng nhau để biết mô hình này.
