Bạn khởi động một coding agent cho một công việc thực tế, gấp laptop lại rồi đi ăn trưa. Phần đó thì dễ. Phần khó là những gì bạn thấy khi quay lại: một terminal đã cuộn mất phần đầu, một diff mà bạn không hề được xem trong lúc nó được viết ra, và không có câu trả lời rõ ràng cho câu hỏi duy nhất thực sự quan trọng — liệu công việc này có đủ tốt để giữ lại không.
Chạy agent không giám sát có hai nửa, và hầu hết các thiết lập chỉ giải quyết được nửa đầu. Nửa đầu là giữ cho tiến trình sống và làm việc hiệu quả trong khi không ai theo dõi. Nửa sau là hàng đợi đánh giá: một đống các lượt chạy đã xong, xong dở và thất bại đang chờ người ra quyết định khi bạn quay lại. Bỏ qua nửa sau thì agent không giám sát chỉ chuyển nút thắt từ việc viết code sang việc dựng lại xem chuyện gì đã xảy ra.
Bài viết này đề cập cả hai nửa: cách tự thiết lập một lượt chạy không giám sát, kiểu lỗi ở từng bước, và điểm mà cách tự làm đó không còn mở rộng được nữa. Khi một terminal trở thành năm, một bảng công việc như Sharkly sẽ nằm bên trên các coding agent của bạn. Bạn vẫn để Claude Code, Codex hay Gemini CLI làm việc, còn Sharkly giữ công việc, lượt chạy và phần đánh giá ở cùng một chỗ, thay vì phân tán khắp những terminal mà bạn đã đóng từ lâu.
Chạy agent không giám sát thực chất gồm những gì
Một lượt chạy không giám sát là khi một coding agent thực thi một công việc trên một host mà bạn không trực tiếp theo dõi, với kết quả đầu ra được ghi lại để đánh giá sau. Định nghĩa đó có ba phần cốt lõi: một công việc mà agent có thể hoàn thành mà không cần bạn, một host vẫn tiếp tục chạy khi bạn ngắt kết nối, và một bản ghi mà bạn có thể đọc lại sau đó.
Bản ghi là phần bị đánh giá thấp nhất. Khi bạn theo dõi agent trực tiếp, chính bạn là cuốn log: bạn thấy nó chọn sai file, bạn ngắt nó, bạn chỉnh lại hướng đi. Còn khi không giám sát, không có gì trong số đó diễn ra. Mọi thứ agent đã làm đều phải tồn tại dưới một dạng mà bạn có thể kiểm tra từ đầu, nhiều giờ sau đó, khi đã không còn nhớ mình đã yêu cầu gì. 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ả. Giao kèo đó chỉ đứng vững nếu bản báo cáo là thật và đầy đủ vào lúc bạn quay lại xem.
Vậy nên mục tiêu không phải là “để agent chạy mà không cần tôi”. Mà là “để agent chạy mà không cần tôi và trả về một thứ tôi có thể đánh giá được”. Đây là hai bài toán khác nhau, và bài toán thứ hai chính là chỗ các quy trình không giám sát thường đổ vỡ.
Tự thiết lập một lượt chạy không giám sát
Đây là phiên bản thủ công tối giản, kèm theo kiểu lỗi cắn bạn ở từng bước.
Bước 1: cô lập công việc. Cấp cho lượt chạy một checkout riêng để nó không đụng độ với editor hay một agent khác.
git worktree add ../task-auth-refactor -b task/auth-refactor
cd ../task-auth-refactor
Kiểu lỗi: bỏ qua bước này thì hai lượt chạy trong cùng một thư mục sẽ ghi đè lên các thay đổi chưa commit của nhau. Xem mỗi task một checkout để hiểu vì sao worktree, chứ không chỉ riêng branch, mới là ranh giới cô lập.
Bước 2: tách tiến trình ra khỏi phiên làm việc. Phiên SSH hay terminal của bạn rồi sẽ đóng, và một tiến trình chạy foreground sẽ chết theo nó (SIGHUP). Giữ nó sống bằng nohup hoặc một phiên tmux:
nohup claude -p "Refactor auth to use the new token service; run the tests" \
> run.log 2>&1 &
Kiểu lỗi: chạy nó trong một shell foreground thông thường rồi gập nắp máy sẽ giết agent ngay giữa lúc đang sửa nhiều file, để lại một cây làm việc hỏng. nohup giải quyết được vòng đời nhưng không cho bạn cách quay lại; tmux cho phép bạn gắn lại vào phiên và xem chuyện gì đang diễn ra.
Bước 3: ghi lại mọi thứ. Phần > run.log 2>&1 ở trên không phải là tùy chọn. Đó chính là hàng đợi đánh giá ở dạng thô nhất.
Kiểu lỗi: không có log được ghi lại thì bạn không thể trả lời câu hỏi “vì sao nó dừng lại?”. Kiểu đình trệ âm thầm phổ biến nhất là agent chờ mãi mãi ở một prompt tương tác mà không ai trả lời, vì không giám sát nghĩa là không có ai ở đó để gõ “yes”. Hãy chạy ở chế độ không tương tác và phê duyệt trước một tập hành động hẹp mà công việc cần đến.
Bước 4: giới hạn phạm vi ảnh hưởng. Hãy quyết định trước khi rời đi: agent được tự làm gì và việc gì cần đến bạn. Giới hạn phạm vi file, cấm force-push, và tuyệt đối không để một lượt chạy không giám sát merge vào branch được bảo vệ.
Kiểu lỗi: một lượt chạy được cấp quá nhiều quyền rồi push thẳng lên main không phải là một thắng lợi về năng suất, mà là một sự cố. Các cổng phê duyệt tồn tại để agent dừng lại ở điểm an toàn cuối cùng và chờ.
Bước 5: biết khi nào nó xong, và xong thế nào. Kiểm tra exit code và tự gửi cho mình một tín hiệu để không phải liên tục mở log ra xem bằng tay:
claude -p "..." > run.log 2>&1; echo "exit $?" | mail -s "auth run done" [email protected]
Kiểu lỗi: không có tín hiệu hoàn thành thì “không giám sát” biến thành “cứ hai mươi phút tôi lại mở terminal xem một lần”, tức là vẫn giám sát nhưng thêm độ trễ.
Khi cách tự làm không còn mở rộng được
Một agent, một worktree, một file log: cách này hiệu quả, và với một lượt chạy duy nhất thì bạn chẳng cần gì nặng hơn. Nhưng thiết lập này sụp đổ ngay khi có nhiều hơn một.
Chạy ba agent cho ba task thì bạn có ba worktree, ba file log, ba exit code và ba email báo hoàn thành mà bạn sẽ đọc nhầm ngay từ cái liếc mắt đầu tiên. Việc cô lập vẫn đứng vững. Thứ sụp đổ là hàng đợi đánh giá. Không có gì cho bạn biết lượt chạy nào xong sạch sẽ, lượt nào thất bại ở bước test, và lượt nào đang âm thầm chờ ở một prompt. Bạn phải tự dựng lại bức tranh đó bằng tay, đọc từng log một — đúng cái việc mà bạn đang muốn giao đi.
Đây mới là chi phí thật, và rất dễ bị bỏ qua vì từng mảnh riêng lẻ đều có vẻ ổn. Giám sát nhiều lượt chạy song song trở thành một vấn đề thật sự khi số lượng vượt quá những gì một màn hình hiển thị được. Một file log trả lời câu hỏi “lượt chạy này in ra gì”, chứ không trả lời “trong sáu lượt chạy của tôi, ba lượt nào đang cần tôi ngay bây giờ”. Những tín hiệu trạng thái và thất bại đáng được ghi lại sẽ không tự sắp xếp thành một hàng đợi. Mà hàng đợi mới chính là toàn bộ ý nghĩa của việc làm trong lúc bạn đi vắng: bạn muốn một danh sách các quyết định đã được xếp hạng, chứ không phải một thư mục đầy kết quả thô.
Bảng công việc thay đổi điều gì
Bảng công việc là nơi nửa sau của vấn đề được giải quyết. Lượt chạy không giám sát vẫn diễn ra trên một Computer mà bạn kết nối, với Runtime hiện có của bạn đảm nhiệm phần viết code. Điều thay đổi là kết quả đáp xuống đâu.
Trong Sharkly, công việc, lượt chạy và phần đánh giá cùng nằm trên một Task. Bạn giao Task cho một Agent — một cấu hình đã lưu gồm chỉ dẫn, Runtime và các repository, chứ không phải một prompt dùng một lần mà bạn phải gõ lại. Agent nhận Task, chạy trong một worktree được cô lập, và quá trình thực thi, các điểm tắc cùng kết quả đều quay về dòng thời gian của Task. Khi quay lại, bạn không phải grep sáu file log. Bạn mở bảng ra và đọc hàng đợi: cái gì đã xong, cái gì thất bại, cái gì đang chờ bạn.
Đây là ranh giới cần nói cho rõ ràng. Sharkly không thay thế Claude Code, Codex hay các công cụ thực thi khác. Nó bổ sung lớp task chung, Computer, ngữ cảnh và đánh giá bao quanh những công cụ mà đội của bạn đã dùng. Agent vẫn viết code. Sharkly đảm bảo rằng trong lúc bạn đi vắng, code quay về ở một nơi bạn có thể nhìn thấy, kèm theo bản tóm tắt thay đổi và kết quả test, và rằng việc chấp nhận cuối cùng vẫn là quyết định của con người. Tự động hóa dừng lại ở đúng chỗ cần đến phán đoán.
Bạn có thể tự dựng toàn bộ những thứ này bằng worktree, nohup và một lệnh mail. Quy tắc quyết định thẳng thắn là: nếu bạn chỉ thỉnh thoảng chạy một agent, cách làm thủ công là ổn và Sharkly chỉ là thứ cồng kềnh bạn không cần. Phương trình thay đổi khi nhiều agent chạy trên nhiều task và repository, và hàng đợi đánh giá trở thành thứ bạn dành cả buổi sáng để xử lý. Nếu bạn muốn tiếp tục dùng nhiều coding agent thay vì gắn chặt vào một hệ sinh thái duy nhất, thì hàng đợi đó chính là bài toán mà Sharkly được thiết kế để giải quyết.
Hàng đợi đánh giá mới là nút thắt thực sự
Đây là giả định đáng để chất vấn: người ta tối ưu lượt chạy không giám sát rồi coi việc đánh giá là chuyện phụ. Điều đó hoàn toàn ngược. Chạy nhiều agent song song trong lúc bạn ngủ chỉ là một thắng lợi nếu việc đánh giá kết quả của chúng vào sáng hôm sau nhanh hơn so với việc tự tay làm. Khi năm agent xong việc qua đêm mà đọc cả năm diff còn lâu hơn viết hai trong số đó, thì việc chạy song song chẳng mang lại gì cả.
Vậy nên hãy thiết kế hàng đợi đánh giá trước tiên. Hãy quyết định “hoàn thành” phải bao gồm những gì trước khi một lượt chạy đến tay bạn: test pass, typecheck pass, một bản tóm tắt thay đổi và một ghi chú về những giới hạn đã biết. Sắp xếp hàng đợi theo mức rủi ro, không theo thời điểm hoàn thành, để lượt chạy có đụng đến phần auth được bạn chú ý trước lượt chỉ sửa một lỗi chính tả. Hãy làm cho “yêu cầu chỉnh sửa” rẻ ngang với “phê duyệt”, vì một nửa các lượt chạy không giám sát sẽ gần đúng nhưng chưa thật sự đúng. Đánh giá là nút thắt trong bất kỳ quy trình nhiều agent song song nào, và việc các agent thực sự chạy ở đâu — server của bạn, laptop của bạn, hay cả hai — ít quan trọng hơn nhiều so với việc kết quả của chúng đến dưới dạng một hàng đợi mà bạn có thể xử lý hết.
Danh sách kiểm tra bạn có thể áp dụng ngay hôm nay
Trước khi rời khỏi một agent, hãy xác nhận:
- Cô lập: lượt chạy có worktree riêng, không dùng checkout đang làm việc của bạn.
- Vòng đời: tiến trình sống sót qua việc ngắt kết nối (
nohup,tmuxhoặc một Computer được quản lý), để việc gập nắp máy không giết nó ngay giữa lúc đang sửa file. - Ghi lại: stdout và stderr được đưa vào một log bền vững hoặc dòng thời gian của Task để bạn có thể đọc lại từ đầu.
- Không tương tác: agent sẽ không bị kẹt ở một prompt không có ai trả lời.
- Phạm vi ảnh hưởng: phạm vi file được giới hạn, force-push bị tắt, và không lượt chạy không giám sát nào merge vào branch được bảo vệ.
- Tín hiệu hoàn thành: bạn được báo khi nó xong và liệu nó có pass hay không, mà không phải liên tục kiểm tra.
- Thỏa thuận đánh giá: mọi lượt chạy hoàn thành đều đến kèm test, bản tóm tắt thay đổi và các giới hạn đã biết, còn việc chấp nhận vẫn thuộc về bạn.
Sáu mục đầu giúp lượt chạy trở thành không giám sát. Mục cuối khiến nó đáng để làm. Nếu bạn đã chạy nhiều agent và thời gian buổi sáng của bạn đổ hết vào việc đánh giá, hãy cho các coding agent hiện có của bạn chạy qua Sharkly để hàng đợi đến tay bạn có tổ chức thay vì phân tán.
