Cách giám sát các tác nhân mã hóa AI mà không mất trí

Chạy một tác nhân mã hóa AI trong một tác vụ hoạt động rất tốt. Bạn đưa ra một vấn đề trọng tâm, nó viết mã, bạn xem lại nó. Đơn giản.

Bây giờ hãy thử chạy song song ba bộ lưu trữ trên cùng một kho lưu trữ.

Điều gì xảy ra

Tôi đã chạy Claude Code, Codex và Aider trong các dự án thực tế trong nhiều tháng. Khi bạn mở rộng quy mô từ một nhân viên lên nhiều nhân viên, có ba điều sẽ xảy ra ngay lập tức:

1. Xung đột tệp. Hai nhân viên cùng lúc chỉnh sửa cùng một tệp. Một người ghi đè lên công việc của người khác. Cả hai đều không biết chuyện đó đã xảy ra. Bạn phát hiện ra khi không có gì được biên dịch.

2. Không có cổng chất lượng. Nhân viên tuyên bố nhiệm vụ là "hoàn thành" khi họ đã tạo mã — chứ không phải khi mã đó thực sự hoạt động. Nếu không có sự can thiệp, bạn sẽ có một đống mã trông có vẻ hợp lý nhưng lại không đạt yêu cầu trong bộ thử nghiệm.

3. Bạn trở thành người điều phối toàn thời gian. Thay vì viết mã, bạn sẽ lập bảng giữa các thiết bị đầu cuối, kiểm tra xem ai đang làm việc gì, giải quyết xung đột và chạy thử nghiệm theo cách thủ công. Các đại lý đang làm việc. Bạn thì không.

Mỗi sự cố trong số này đều có cách khắc phục cụ thể. Không có mô hình nào trong số đó yêu cầu khả năng AI mới — chúng là các mẫu giám sát mà bạn có thể triển khai bằng các công cụ hiện có.

Cách khắc phục 1: Cô lập công việc với Git Worktrees

Vấn đề xung đột tệp sẽ biến mất khi mỗi tác nhân làm việc trong bản sao kho lưu trữ riêng của mình. Cây công việc Git cung cấp cho bạn chính xác điều này:

# Tạo không gian làm việc biệt lập cho mỗi nhân viên
git Worktree thêm .worktrees/agent-1 -b Agent-1/task-1
git Worktree thêm .worktrees/agent-2 -b Agent-2/task-2
git Worktree thêm .worktrees/agent-3 -b Agent-3/task-3

Mỗi tác nhân có thư mục riêng, nhánh riêng, cây làm việc riêng. Họ không thể ghi đè lên tệp của nhau vì họ thực sự đang làm việc trong các thư mục khác nhau trên các nhánh khác nhau.

Khi một tác nhân kết thúc, bạn hợp nhất nhánh của nó trở lại chính. Nếu có xung đột, bạn giải quyết một lần — không phải liên tục trong khi tổng đài viên đang làm việc.

Giới hạn thực tế là 3-5 tác nhân song song. Ngoài ra, bản thân cơ sở mã sẽ trở thành nút thắt cổ chai — có quá nhiều thay đổi đồng thời để bước hợp nhất có thể tiếp thu một cách rõ ràng.

Cách khắc phục 2: Cổng mọi thứ vào bài kiểm tra

Đây là thay đổi có tác động mạnh mẽ nhất. Trước khi chấp nhận kết quả đầu ra của bất kỳ tác nhân nào, hãy chạy bộ thử nghiệm:

cd .worktrees/agent-1
hàng hóa kiểm tra # hoặc kiểm tra npm, pytest, v.v.
echo $? # 0 = hợp nhất nó, khác 0 = gửi lại

Nếu kiểm tra thất bại thì nhiệm vụ chưa hoàn thành. Gửi đầu ra lỗi trở lại đại lý và để nó tự sửa công việc của mình. Điều này tạo ra một vòng phản hồi giúp cải thiện đáng kể chất lượng đầu ra.

Điều này giúp loại bỏ những gì:

• Mã biên dịch nhưng không hoạt động
• Hồi quy trong chức năng hiện có
• Cái bẫy "nhìn qua là thấy ngay"

Thông tin chi tiết quan trọng: bạn không cần khung đánh giá phức tạp. Bộ thử nghiệm hiện có của bạn — bộ thử nghiệm bạn đã duy trì — là cổng chất lượng. thoát 0 nghĩa là xong. Mọi thứ khác có nghĩa là hãy thử lại.

Tôi thấy điều này làm giảm tỷ lệ "nhân viên làm hỏng thứ gì đó" khoảng 80%. 20% còn lại là trường hợp các thử nghiệm không bao gồm hành vi bị ảnh hưởng — vấn đề về phạm vi thử nghiệm chứ không phải vấn đề về tác nhân.

Cách 3: Cấu trúc công văn

Khi bạn có nhiều nhân viên hỗ trợ, ai đó cần quyết định ai sẽ làm việc gì. Nếu bạn để tổng đài viên tự tổ chức, bạn sẽ nhận được công việc trùng lặp và tình trạng đảo ngược mức độ ưu tiên.

Bảng Kanban Markdown là cách tiếp cận đơn giản nhất:

## Việc cần làm
- [ ] Thêm xác thực JWT (#12)
- [ ] Viết bài kiểm tra điểm cuối API (#13)
## Đang tiến hành 
- [ ] Tái cấu trúc lớp cơ sở dữ liệu (#11) — đại lý-1
## Xong
- [x] Sửa lỗi chuyển hướng đăng nhập (#10) — Agent-2

Bảng là nguồn thông tin chính xác duy nhất. Một tổng đài viên chọn một nhiệm vụ từ Todo, chuyển nó sang Đang tiến hành, xử lý nó và chuyển nó sang Hoàn thành khi vượt qua các bài kiểm tra. Không có hai nhân viên nào làm cùng một nhiệm vụ vì hội đồng quản trị hiển thị các nhiệm vụ.

Định dạng ít quan trọng hơn ràng buộc: một nhiệm vụ cho mỗi nhân viên, trạng thái hiển thị, không có sự mơ hồ về việc ai đang làm gì.

Đặt nó lại với nhau

Mẫu giám sát đầy đủ:

1. Phân tách công việc thành các nhiệm vụ độc lập trên một bảng Kanban
2. Giao một nhiệm vụ cho mỗi nhân viên
3. Cô lập mỗi nhân viên trong cây công việc git riêng
4. Hoàn thành cổng để vượt qua các bài kiểm tra
5. Hợp nhất các nhánh đã thử nghiệm trở lại nhánh chính, mỗi lần một nhánh

Đây là những gì tôi đã xây dựng Batty để tự động hóa. Đó là Rust CLI chạy vòng lặp giám sát: khởi chạy các tác nhân trong bảng tmux, gửi nhiệm vụ từ Kanban Markdown, cô lập công việc trong cây công việc và đưa mọi thứ vào thử nghiệm. Nhưng mẫu này vẫn hoạt động ngay cả khi bạn thực hiện thủ công.

Điều quan trọng không phải là công cụ — mà là những hạn chế. Sự cô lập ngăn ngừa xung đột. Kiểm tra gating ngăn ngừa sự hợp nhất bị hỏng. Công văn có cấu trúc ngăn chặn công việc trùng lặp. Không có những thứ này, càng có nhiều đặc vụ thì càng hỗn loạn. Với họ, nhiều đại lý hơn đồng nghĩa với nhiều thông lượng hơn.

Giám sát không phải là gì

Không phải là bắn rồi quên. Bạn vẫn xem lại mã trước khi hợp nhất. Bạn vẫn theo dõi các đặc vụ đi chệch hướng. Bạn vẫn phân chia công việc thành các nhiệm vụ hợp lý.

Việc quản lý một nhóm nhà phát triển cấp dưới gần giống với việc nhấn nút và nhận mã. Ưu điểm là bạn đang giám sát năm luồng công việc song song thay vì tự mình thực hiện một nhiệm vụ. Đó thực sự là mức tăng năng suất — nhưng chỉ khi lớp giám sát giữ cho mọi thứ không bị hỏng.

Các đặc vụ sẽ không trở nên kém hơn trong việc viết mã. Họ sẽ trở nên tốt hơn. Điều sẽ không thay đổi là nhu cầu cách ly, cổng chất lượng và sự phối hợp có cấu trúc. Hãy xây dựng những thói quen đó ngay bây giờ.

Dùng thử: cargo install batty-cli — GitHub | Bản trình diễn dài 2 phút

Nếu bạn đang điều hành nhiều đại lý và nhận thấy các mô hình giám sát khác hoạt động thì tôi rất muốn hãy nghe về họ trong phần nhận xét.