TL;DR: Routing là việc quyết định xem coding agent nào sẽ xử lý một task cụ thể. Hãy route dựa trên đặc tính của task, chứ không phải bảng xếp hạng của tuần trước: task đó thay đổi những gì, có thể đảo ngược hay không, có trùng file với agent khác đang xử lý không, chạy không giám sát trong bao lâu, và gói subscription nào chi trả cho nó. Ghép những yếu tố đó với agent có hành vi phù hợp trên codebase của bạn. Với một hoặc hai agent, bạn có thể tính toán trong đầu. Nhưng từ ba agent trở lên, quyết định routing cần một nơi chung để tồn tại. Bài hướng dẫn này cung cấp cho bạn các quy tắc và một checklist.
Bạn có Claude Code trong một terminal, Codex trong một terminal khác, có thể Gemini CLI trong terminal thứ ba. Một task xuất hiện: sửa một test flaky, thêm một endpoint, refactor một module mà ba file khác đang import. Agent nào sẽ nhận nó? Hầu hết chúng ta trả lời theo thói quen, hoặc theo cửa sổ nào đang được focus sẵn. Cách đó ổn cho đến khi bạn không còn nhớ mình đã giao migration cho agent nào, hoặc hai agent cùng sửa một file.
Chọn agent "tốt nhất" là quyết định một lần rồi lỗi thời ngay ngày có model mới ra mắt. Còn quyết định agent nào nhận task này là quyết định bạn đưa ra hàng chục lần mỗi tuần, và nó phụ thuộc vào task nhiều hơn là vào bảng xếp hạng. Khi bạn đã có nhiều hơn một agent, routing chính là nơi thời gian của bạn chảy vào.
Sharkly được xây dựng xoay quanh chính quyết định đó. Sharkly là nền tảng command và quản lý Agent tất-cả-trong-một: bạn kết nối Computer của riêng mình, định nghĩa một Agent một lần dưới dạng role gắn với một runtime, rồi giao một Task cho nó. Nó nằm phía trên các coding agent bạn đang chạy, chứ không đứng cạnh chúng. Bài viết này đi qua cách route một task sao cho tốt, trước tiên là các quy tắc bạn tự áp dụng thủ công, sau đó là đến điểm mà quyết định routing cần một nơi chung để tồn tại.
Routing là một quyết định, không phải sở thích
Bắt đầu bằng một định nghĩa rõ ràng. Routing là ghép một task với agent nên thực thi nó. Nó không giống với việc chọn agent yêu thích của bạn, và cũng không giống với việc chọn model. Chọn model nào cho coding task nào là một câu hỏi riêng, hẹp hơn, nằm ở một tầng bên dưới; ở đây chúng ta đang quyết định agent nào (Claude Code, Codex, Gemini CLI, OpenCode và những cái còn lại) sẽ nhận công việc.
Một task mang theo các đặc tính quyết định route của nó trước cả khi năng lực được đưa vào bàn:
- Nó thay đổi những gì. Sửa một file, refactor cắt ngang nhiều phần, feature hoàn toàn mới, test, docs. Mỗi loại có bán kính ảnh hưởng khác nhau.
- Mức độ đảo ngược. Sửa lỗi typo và migration database đều tạo ra diff. Nhưng chỉ một cái có thể hủy hoại cả buổi chiều của bạn nếu agent làm sai.
- Trùng file. Task có chạm vào những file mà agent khác đang sửa ngay lúc này không?
- Chân trời tự chủ. Một chỉnh sửa tương tác nhanh, hay một lần chạy dài không giám sát phải tự lập kế hoạch, thực thi và tự kiểm tra?
- Trần chi phí. Gói subscription hay ngân sách API nào nên gánh nó?
Đọc một task qua năm đặc tính đó và route thường tự chọn chính nó. Sai lầm là nhảy thẳng đến câu hỏi "agent nào tốt nhất" — một câu hỏi không có đáp án cố định và thay đổi mỗi khi có lab ra mắt sản phẩm mới.
Route theo hình dạng task trước khi route theo năng lực
Các coding agent thực sự khác nhau. Một cái có thể lập kế hoạch tốt cho các task nhiều bước dài; cái khác có thể sắc sảo hơn ở những chỉnh sửa mang tính phẫu thuật hoặc nhanh hơn ở những vòng lặp ngắn. Nhưng phiên bản trung thực là: chúng khác nhau trên codebase của bạn, và cách duy nhất để biết là quan sát chúng làm việc trên đó. Các benchmark đo một tập vấn đề cố định tại một thời điểm cố định — đó không phải repository của bạn, cũng không phải tháng sau. Hãy so sánh các agent trên chính codebase của bạn trước khi tin vào một bảng xếp hạng.
Vậy nên hãy route theo hình dạng trước. Một cặp quyết định để neo lại: dùng một agent nhanh, tương tác tốt khi task nhỏ, phạm vi rõ ràng và bạn sẽ ngồi xem; chuyển sang agent tự chủ hơn khi task đủ lớn đến mức bạn thà mô tả một lần rồi review kết quả còn hơn là túc trực từng bước.
| Hình dạng task | Route đến | Lý do |
|---|---|---|
| Nhỏ, phạm vi rõ, bạn đang xem | Agent tương tác nhanh nhất của bạn | Ít overhead, vòng lặp chặt |
| Lớn, nhiều bước, mô tả một lần | Agent tự chủ đáng tin cậy nhất của bạn | Nó tự lập kế hoạch và tự kiểm tra không giám sát |
| Chạm vào file mà agent khác đang mở | Bất kỳ agent nào, trong một worktree tách biệt | Tránh va chạm merge |
| Rủi ro cao hoặc không thể đảo ngược | Agent mà bạn review kỹ nhất, quyền hạn chặt | Bán kính ảnh hưởng, chứ không phải tốc độ, chiếm ưu thế |
| Rẻ và lặp đi lặp lại | Bất cứ cái nào ngân sách của bạn ưu tiên | Trần chi phí quyết định |
Không có mục nào nêu tên một người thắng, vì không có người thắng. Chỉ có sự phù hợp giữa một task và hành vi đã quan sát được của một agent, và sự phù hợp đó chính là thứ bạn route dựa trên.
Những ràng buộc quyết định routing trước cả năng lực
Có hai ràng buộc luôn lấn át năng lực, và cả hai đều xoay quanh việc phối hợp, chứ không phải kỹ năng.
Thứ nhất là trùng file. Năm agent cùng sửa một repository nghe có vẻ hiệu quả cho đến khi hai agent chạm vào cùng những file và bạn phải giải quyết một merge conflict do chính mình cố ý tạo ra. Cách khắc phục là tách biệt: cho mỗi task một checkout riêng để các agent không thể va chạm. Worktree cho coding agent, một checkout cho mỗi task giải thích cơ chế, còn chạy nhiều agent trong một repository nói về những gì hỏng khi thiếu nó. Khi hai task có nguy cơ chạm vào cùng file, route không phải là "agent tốt hơn", mà là "agent nào cũng được, miễn trong một worktree riêng".
Thứ hai là rủi ro. Một task migrate dữ liệu, thay đổi auth, hoặc viết lại một hot path nên được route đến nơi mà việc review của bạn là chặt nhất và quyền của agent là hẹp nhất, bất kể agent nào mạnh nhất về mặt kỹ thuật. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, cấp quyền và chấp nhận kết quả. Route một task rủi ro cho agent nhanh nhất là tối ưu sai biến số.
Nơi mà routing trong đầu bạn ngừng mở rộng được
Với một agent, không có vấn đề routing nào cả. Với hai agent, bạn giữ bảng đó trong đầu và mọi thứ vẫn ổn. Rắc rối bắt đầu quanh mức ba agent và vài task đang mở: quyết định routing không có nơi nào để tồn tại ngoài trí nhớ ngắn hạn của bạn.
Bạn không thể nhớ agent nào đã nhận migration. Một lần chạy đã xong sẽ trôi khỏi đầu terminal trước khi bạn đọc kịp. Bạn quyết định lại cùng một route ba lần vì không có ghi chép nào cho thấy bạn đã quyết định nó một lần. Hai agent sửa cùng một file vì không có gì nói với cả hai rằng cái kia đang ở đó. Không cái nào trong số này là lỗi của agent. Chúng là cái giá của việc giữ một bảng routing trong đầu khi số terminal nhân lên. Quá nhiều terminal là một chi phí thật, và routing là nơi nó lộ diện đầu tiên.
Đây là lúc một task board khẳng định được vị trí của nó, vì nó đưa quyết định routing ra khỏi đầu bạn và vào một bản ghi chung. Sharkly làm điều này bằng ba danh từ. Một Task là đơn vị công việc chung. Một Agent là một role gắn với một runtime, được định nghĩa một lần để quyết định routing trở nên tái sử dụng được thay vì phải tạo lại trong mỗi terminal. Bạn giao một Task cho một Agent, và quá trình thực thi, các điểm chặn, và kết quả đều quay về Task đó thay vì trôi đi mất. Bạn thấy được agent nào đang làm gì mà không cần chuyển cửa sổ, và diff cùng output test chờ bạn review ở một nơi duy nhất. Giao việc, theo dõi và review công việc của agent là thứ thay thế trò chơi ghi nhớ này.
Bạn không cần bất kỳ thứ nào trong số này để chạy tốt một agent. Bạn cũng có thể tự tay chạy Claude Code và Codex cùng nhau trên một codebase, và với hai agent thì điều đó hợp lý. Phương trình thay đổi khi số quyết định routing vượt quá những gì bạn có thể giữ trong đầu: nhiều agent, nhiều task, nhiều repository, một team cần nhìn thấy cùng một bảng.
Một checklist routing bạn có thể dùng ngay hôm nay
Trước khi giao một task cho agent, hãy cho nó chạy qua những bước này:
- Gọi tên hình dạng của task. Sửa một file, refactor, greenfield, test, hay docs? Điều này xác lập bán kính ảnh hưởng.
- Kiểm tra mức độ đảo ngược. Khó hoàn tác? Route đến nơi review chặt nhất và quyền hạn chế nhất, không phải agent nhanh nhất.
- Kiểm tra trùng file. Có agent khác đang ở trong những file này không? Nếu có, hãy tách task này vào worktree riêng trước.
- Khớp chân trời tự chủ. Ngắn và có người xem, hay dài và không giám sát? Route đến agent có hành vi phù hợp trên repo của bạn.
- Đặt trần chi phí. Quyết định gói subscription hay ngân sách nào sẽ gánh lần chạy này.
- Ghi lại route ở một nơi chung. Từ hai agent trở lên, hãy viết nó ở nơi bạn và team có thể thấy: một Task, chứ không phải một terminal mà bạn sẽ đóng lại.
- Gửi kết quả về một nơi. Diff, output test, và review nên quay về bản ghi task, chứ không rải rác khắp các cửa sổ.
Route theo task, không theo bảng xếp hạng. Agent tốt nhất cho một task là cái có hình dạng phù hợp với công việc trước mắt bạn, và quyết định routing chỉ giữ được chi phí thấp nếu nó sống ở một nơi bạn có thể nhìn thấy.
Nếu bạn đã đang chạy vài coding agent, Sharkly cho bạn một nơi để route task của chúng và đọc kết quả. Bạn có thể tải Sharkly và kết nối những agent bạn đang dùng.
FAQ
Routing có giống với việc chọn coding agent tốt nhất không? Không. Chọn agent tốt nhất là một phán đoán một lần rồi nhanh chóng lỗi thời. Routing là quyết định agent nào xử lý mỗi task, dựa trên hình dạng, rủi ro, trùng file và chân trời tự chủ của nó. Bạn route hàng chục lần cho mỗi một lần bạn "chọn".
Điều này khác gì với việc chọn model? Chọn model diễn ra ở một tầng bên dưới, bên trong agent. Routing quyết định agent nào nhận task; câu hỏi model quyết định cái gì chạy bên trong session của agent đó. Xem chọn model nào cho coding task nào để biết về quyết định hẹp hơn này.
Khi nào thì tôi thực sự cần một công cụ cho việc này? Khi các quyết định routing vượt quá những gì bạn có thể theo dõi trong đầu, thường là quanh mức ba agent và vài task đang mở, hoặc khi một team cần nhìn thấy cùng những quyết định đó. Với một hoặc hai agent, một bảng trong đầu và các terminal riêng biệt là đủ.
Sharkly có thay thế Claude Code hay Codex không? Không. Sharkly không phải là sự thay thế cho Claude Code, Codex, hay các công cụ thực thi khác. Nó bổ sung tầng task chung, Computer, context và review xung quanh những coding agent mà team bạn đã dùng.
