Đội agent chạy 24/7 và những cái chết đầu tiên

Nhóm chúng tôi thử một việc: để một dàn agent (một "Lead" điều phối, cộng vài "Engineer" và "Reviewer" bên dưới) tự chạy qua đêm, tự build, tự review, tự quyết, con người chỉ đọc báo cáo buổi sáng và bấm những nút không thể giao cho máy — publish, trả tiền, tạo tài khoản. Ý tưởng nghe gọn. Thực tế đêm đầu tiên đã cho thấy phần khó không nằm ở việc agent viết code sai, mà ở việc cả dàn có còn đang chạy hay không — và làm sao biết được điều đó từ xa, lúc không có ai ngồi trước máy.

Dưới đây là ba lần hỏng thật, mỗi lần kèm con số/thông báo lỗi thật và điều đội đổi ngay sau đó.

Sự cố 1: seat mất đăng nhập, chết ngay lúc khởi động

Một đêm, mọi lượt spawn agent Peer đều chết ngay khi vừa mở, in ra đúng một dòng:

Failed to authenticate: OAuth session expired and could not be refreshed

Không phải một lần ngẫu nhiên — hai lượt liên tiếp đều chết y hệt nhau. Không có Peer thì không có ai review độc lập, và không có Engineer nhánh phụ để chạy song song. Đêm đó Lead phải tự làm luôn phần build, phần lẽ ra được chia cho Engineer, rồi chờ con người accept vào sáng hôm sau.

Chuyện xảy ra vì phiên đăng nhập của seat đó hết hạn và không tự làm mới được — một vấn đề xác thực bình thường, chỉ có điều nó chặn đứng cả một vai trong dàn agent. Đội không thể tự sửa được: việc chép lại thông tin đăng nhập là việc chạm vào tài khoản cá nhân, nên phải chờ người bấm tay. Cách vá đầu tiên là tạm thời: người phụ trách phía con người chép lại thông tin đăng nhập, cộng một cơ chế tự chạy nền lặp lại mỗi 10 phút để phòng nó hết hạn lần nữa. Sau đó đội chuyển hẳn cả bốn seat sang xác thực bằng token dài hạn, và bỏ luôn cơ chế vá lặp-10-phút kia — hết cả cái gốc sinh ra lỗi lẫn cái vá tạm cho lỗi đó, thay vì giữ một lớp vá chạy mãi trên một vấn đề đã hết.

Sự cố 2: một Lead đứng im 8,5 giờ, và hai lời giải thích không khớp nhau

Một Lead làm từ đầu ca tới đúng bước tích hợp cuối cùng thì đứng khựng lại. Nhìn từ ngoài, nó vẫn ở trạng thái "đang chạy", vẫn nhận được prompt gửi vào — chỉ có điều không có gì tiến thêm. Đúng lúc đó, Engineer nó đang chờ đã hoàn tất phần việc của mình và để lại kết quả rõ ràng (một commit cụ thể). Nhật ký theo dõi ca đó ghi lại: Lead "idle 8h 30 min (since 05:00)... waiting for P1 to handoff" — tức đứng chờ đúng bằng khoảng thời gian mà quy tắc vận hành viết lại sau này gọi là "đứng 8,5 giờ". Hai chỗ này khớp nhau, không phải một con số đơn lẻ.

Nhưng đến đây tài liệu nội bộ lại không khớp về lý do, và bài này không tự phân xử thay: quy tắc vận hành viết nguyên nhân là tín hiệu báo-đã-xong không tới nơi cần tới; trong khi báo cáo chi tiết của chính ca đó lại ghi Lead này "mất xác thực" ngay tại bước đó — phiên bị mất xác thực được cho là phiên cũ, mở từ trước khi đội đổi cách cấp token cho toàn hệ thống, nên nó vẫn giữ nguyên cách xác thực lúc khởi tạo trong khi seat đã đổi. Cả hai đều là chuyện có thể xảy ra thật; repo không nói cái nào là nguyên nhân đúng của lần đứng im 8,5 giờ, và cách xử lý ở cả hai cách kể đều giống nhau: không vá được phiên đang kẹt, bỏ hẳn nó, dựng một Lead kế nhiệm, giao lại ngữ cảnh qua ghi chú và qua lịch sử commit chứ không "hỏi lại" phiên cũ.

Sau đêm đó, dù chưa ai chốt được nguyên nhân gốc, đội vẫn thêm được một lớp phòng vệ không cần biết trước lý do agent đứng im: một mốc kiểm 45 phút (agent nào rảnh quá 45 phút không có báo cáo mới sẽ được chủ động đánh thức, thay vì chờ nó tự lên tiếng), cộng một lịch đánh thức định kỳ cho toàn dàn, để độ trễ phát hiện tối đa bị chặn trên ở một con số biết trước, không còn phụ thuộc vào việc có ai tình cờ nhìn vào màn hình.

Sự cố 3: công cụ theo dõi báo "không có gì xảy ra", trong khi việc đã xong thật

Khi Lead kế nhiệm ở trên tra lại nhật ký hoạt động của hai agent đã bàn giao cho nó — một Engineer và một Reviewer, cả hai đều để lại code và nhận xét thật — công cụ theo dõi trả về đúng 0 activity cho cả hai. Nếu tin theo công cụ, coi như hai agent đó chưa từng làm gì, dù kết quả nằm sờ sờ trong lịch sử commit.

Không có cách sửa cái công cụ theo dõi ngay lúc đó. Cách xử lý là bỏ qua nó: Lead kế nhiệm dựng lại toàn bộ bàn giao từ các commit đã có SHA cụ thể và vài file tạm còn sót lại, không dựa vào bất kỳ lời kể nào của hai agent kia — vì lúc đó chẳng có lời kể nào để dựa vào cả. Không mất artifact nào theo cách làm này. Từ đó, thói quen của đội đổi hẳn: khi bàn giao, thứ đáng tin là SHA đã nằm trong lịch sử git, không phải nhật ký hoạt động hay lời agent tự kể — vì cái sau có thể trống trong khi việc đã hoàn thành thật.

Sơ đồ: đường đi của một sự cố "đứng im"

Engineer hoàn tất việc, để lại commit
        │
        ▼
   bàn giao lại  ──────► (không tới đích: tín hiệu mất, hoặc phiên nhận mất xác thực — chưa rõ)
        │
        ▼
   Lead: idle, chờ
        │
        │   [không có kiểm định kỳ]
        │
        ▼
   ...8,5 giờ trôi qua, không ai biết...
        │
        ▼
   có người phát hiện: việc đã xong từ lâu, Lead vẫn chờ
        │
        ▼
   đánh thức Lead thủ công → tích hợp tiếp

Sau khi sửa:
Engineer hoàn tất → bàn giao ──► mốc kiểm 45 phút
                                        │
                                nếu quá 45 phút không tiến
                                        ▼
                                đánh thức chủ động

Cơ chế chung đứng sau cả ba sự cố

Cả ba lần đều có cùng một dạng: agent trông như đang sống (không báo lỗi, trạng thái vẫn hiển thị bình thường) nhưng thực chất đã ngừng làm việc có ích — vì hết xác thực, vì mang xác thực cũ, hoặc vì công cụ quan sát chính nó cũng không đáng tin. "Đang chạy" và "đang có tiến độ" hoá ra là hai thứ khác nhau, và chỉ nhìn trạng thái thôi thì không phân biệt được. Nói ngắn gọn: qua một đêm, thứ sống sót được là commit đã nằm trong lịch sử git, không phải trạng thái hiển thị của agent hay lời nó tự kể lại đã làm gì.

Một câu cần nói rõ

Code sản phẩm trong hệ thống này do AI viết — lịch sử commit công khai của nó có đủ dòng ghi rõ tác giả là AI. Người review và quyết định có accept hay không là con người, đọc log và diff thật trước khi cho qua, không phải agent tự chấm điểm cho chính mình.

Chúng tôi vẫn đang chạy tiếp, và vẫn còn thấy những dạng đứng-im mới mỗi vài đêm. Nhưng ba cái chết đầu tiên này là lý do vì sao bây giờ có mốc kiểm định kỳ, có đánh thức chủ động, và có thói quen tin vào commit hơn là tin vào việc agent nói "tôi xong rồi".