Câu chuyện tăng số agent lên 22 rồi giảm xuống còn 17

Khi vận hành nhiều dự án bằng Claude Code, số subagent cứ tiếp tục tăng lên.
Mỗi khi cần tôi lại tạo thêm một cái, và cuối cùng thành 22 cái.

Tháng trước tôi đã giảm xuống còn 17 cái.

Nhưng khi dẹp bớt, tôi lại không ghi lý do vì sao dẹp.
Ba tháng sau mở thư mục archive ra thì không thể biết được vì sao đã dẹp chúng.
Trong năm cái, chỉ có một cái được ghi lý do.

Dù người tạo ra chỉ có mình tôi mà vẫn như vậy.

Vì sao lại lên tới 22 cái

Khi tăng thêm, lý do lúc nào cũng rõ ràng. Vì cần nên tạo.

Vấn đề nằm ở chiều ngược lại. Khi dẹp, ý nghĩ "biết đâu sau này lại dùng" cứ vướng mãi.
Không chắc chắn rằng nó vô dụng, nên cứ để đó. Và thế là thành 22 cái.

Nhìn lại bây giờ, nguyên nhân tăng lên chỉ có một.
Không có một gate để phán đoán rằng "cái này đáng lẽ phải là công cụ, không phải agent".

Nếu đó là công việc lặp lại, quy trình cố định và không cần phán đoán theo ngữ cảnh, thì đó không phải là agent.
Chỉ cần làm thành skill hoặc script là được. Không tốn token, khả năng tái lập là 100%, và dù đổi session cũng không bị quên.

Nếu không có gate này, mọi thứ đều trở thành agent.

Năm cái đã dẹp

Lần ngược lại thì thấy cách xử lý được chia thành bốn loại. Việc phân loại này rất quan trọng.

Một cái ngay từ đầu đã không nên là agent.
Nó phụ trách viết nội dung, nhưng quy trình hoàn toàn cố định.
Tôi thay bằng hai skill rồi dẹp nó. Cái này tôi đóng đinh là cấm khôi phục.
Nếu không làm vậy, một ngày nào đó sẽ có ai đó tạo lại.

Ba cái bị trùng vai trò với cái khác.
Kiểm tra bảo mật trùng với audit code, giám sát cron trùng với health check, lập kế hoạch trùng với thực thi.
Tất cả đều cùng một phạm vi và cùng quyền hạn.

Từ đây tôi rút ra một tiêu chí.

Nếu hai agent trùng nhau trong cùng phạm vi và cùng quyền hạn,
chi phí duy trì việc tách riêng (gánh nặng quản lý, chậm trễ khi quyết định ủy quyền) sẽ vượt quá lợi ích.

Cảm giác "cả hai đều vẫn cần" đã níu chân tôi khá lâu,
nhưng điều lẽ ra phải hỏi không phải là có cần hay không, mà là có đáng để tách riêng hay không.

Một cái thì đơn giản là không ai dùng.
Traffic của chức năng đó trong 70 ngày là 0.
Cái này tôi xử lý là ngủ đông, không phải loại bỏ. Nếu dịch vụ được mở lại, sẽ khôi phục nguyên trạng.

Điều học được khi ghi con số

Khi ghi 22 → 17 vào tài liệu, tôi nhận ra một điều.

Con số này không phải là số lượng file. Mà là số agent đang vận hành.
Có một định nghĩa nằm ngoài thư mục, nên nếu chỉ đếm file thì sẽ ra 21 và 16.

Vì vậy tôi ghi ngay đầu tài liệu rằng con số này đang đếm cái gì.
Và tôi cũng đưa kèm kết quả kiểm chứng bằng git ls-tree.

Nếu không, sau này sẽ có người đếm file rồi kết thúc ở câu "không khớp mà".
Khi ghi con số, cần ghi cả định nghĩa và cách kiểm chứng.

Những điều quyết định tuân thủ khi dẹp

Từ lần vấp này, tôi có bốn quy tắc.

• Ghi lý do vào file tại thời điểm loại bỏ. Nếu không ghi, ba tháng sau phải lần ngược lại. Tôi đã thực sự phải làm vậy.

• Không xóa, mà di chuyển bằng rename. Nội dung được bảo toàn 100%, nên có thể khôi phục đúng nguyên bản.

• Ghi rõ các mục cấm khôi phục. Nếu không ghi, một ngày nào đó ai đó sẽ hồi sinh chúng.

• Thêm "loại bỏ vai trò trùng lặp ở nơi hấp thụ" vào quy trình khôi phục. Nếu bỏ bước này, khi hồi sinh thì hai bên sẽ làm cùng một việc.

Những thứ đã整理 lý cùng lúc

Nhân dịp này tôi gom các quy tắc trong 4 năm lại và công khai. Xin ghi ra vài cái.

Cấm âm thầm đi đường vòng

Đây là quy tắc buộc agent phải báo cáo thay vì phá qua khi gặp ràng buộc.
Nếu là chặn hợp lệ, chỉ giữ lại bước đó và tiếp tục phần còn lại.
Ngay cả khi việc chặn có vẻ là phán đoán sai, agent cũng không tự ý đi đường vòng. Nó tổng hợp căn cứ, gửi lên và nhận xác nhận.

Và nếu việc chặn làm lộ ra khiếm khuyết của chính quy tắc, thì việc sửa khiếm khuyết đó cũng là một phần của phản ứng.

Thực ra chính quy tắc này cũng được tạo ra như vậy. Tôi đã tạo nó sau khi trải qua một lần bị chặn.

Không dùng FAIL như PASS

Ngay cả với việc kết thúc bằng chỉ thị, vẫn ghi nguyên trạng thái đo được và để lại điều kiện reopen.
Báo cáo bằng số liệu đo thực tế Before/After, và viết phần còn lại cùng rủi ro trước thành quả.

Agent về cơ bản chịu áp lực muốn báo cáo thành công. Nếu không chặn bằng quy tắc, nó sẽ cứ tiếp tục như vậy.

Định nghĩa quyền tự chủ bằng ngưỡng định lượng

Thay vì chia đôi "được phép sửa/không được phép sửa", tôi định nghĩa bằng con số phạm vi mà agent phân tích có thể tự sửa.

• Chỉ 1 file

• Dưới 5 dòng

• Không phải file cấp cao

• Dưới ngưỡng điểm impact

Là thỏa mãn tất cả (AND), và nếu vướng dù chỉ một điều kiện thì phải trình lên.
Và điều khoản cuối cùng là cốt lõi — nếu mơ hồ thì yêu cầu ủy quyền. Giá trị mặc định phải thận trọng thì quy tắc mới không sụp đổ.

Tách phán định và thực thi

Xác minh và điều tra được fan-out song song bằng subagent chỉ đọc,
còn thực thi trên file và DB được orchestrator xử lý tuần tự ở trung tâm.

Vì nếu nhiều agent đồng thời sửa file dùng chung thì chắc chắn sẽ hỏng.

Có cái giá phải trả. Với công việc quy mô lớn, xử lý tuần tự ở trung tâm là nút thắt.
Đây là kết quả của việc chấp nhận chậm hơn vì cho rằng vẫn tốt hơn xung đột.

Repository

https://github.com/YoungChulMoon/claude-agent-harness

Chỉ là vài file Markdown. Không có gì cần cài đặt.
Bạn chỉ cần đặt template dưới .claude/agents/ và điền những phần cần thiết.

Đây không hẳn là một đáp án đúng duy nhất, mà là cách đã hoạt động trong môi trường này suốt 4 năm.
Có thể không phù hợp tùy theo quy mô đội ngũ hoặc tính chất dự án.

Có nhiều câu chuyện về việc tăng thêm, nhưng không mấy ai nói về việc giảm bớt.
Hy vọng nó sẽ hữu ích cho những ai cũng đang thấy số agent của mình phình to theo cách tương tự.