Một kỹ sư trong đội ngũ Grok Bot đã chuyển từ việc chạy 15 cloud agent cùng lúc lên hơn 200 agent đồng thời.
Không phải bằng 200 bot. Mà chỉ với sáu.
Năm bot kỹ sư, mỗi con phụ trách một mảng, và một bot vận hành không viết dù chỉ một dòng code. Cũng trong team đó, Lauren Tan đã merge hơn 2.000 PR chỉ trong một tháng.
Đó là điều mà hầu hết mọi người bỏ lỡ. Con bot đầu tiên hoạt động tốt, nên họ thêm con thứ hai, rồi thứ năm, thứ mười. Kết quả là họ có mười cửa sổ chat và một công việc full-time mới: ngồi đọc chúng.
Một đống bot chỉ là số lượng nhân sự. Một team thực thụ cần có cấu trúc. Hướng dẫn này chính là cấu trúc đó, được đúc kết từ cách chính những người ở xAI đang vận hành team của họ.
Bản tóm tắt 30 giây
- Một bot là một nhân sự. Một team cần năm yếu tố: một cửa ngõ, các chuyên gia, một bảng việc, một chiếc đồng hồ và một chốt chặn.
- Bạn chỉ nói chuyện với một bot duy nhất. Nó sẽ phân phối việc cho những con còn lại.
- Mỗi chuyên gia phụ trách một mảng và tự quản lý bộ nhớ riêng.
- Công việc nằm trên bảng, không nằm trong khung chat.
- Các routine (tác vụ định kỳ) tự đẩy tiến độ khi bạn ngủ. Các bước duyệt quyết định thứ gì được phép đưa ra ngoài.
- Chính các team nội bộ của xAI cũng chỉ chạy mô hình này với khoảng sáu bot. Không phải sáu mươi.
Phần 1. Khi nào nên tuyển bot thứ hai
Không phải khi con đầu tiên "đang bận". Bot không biết bận như bạn đâu.
Kevin Niparko đang vận hành cả một team bot với vai trò PM tại SpaceXAI, và hướng dẫn của anh ấy đưa ra ba lý do để chia việc cho nhiều bot: khả năng quy chiếu ("Bạn biết rõ ai làm gì"), tính song song, và bộ nhớ được khoanh vùng.
Lý do thứ ba mới là câu trả lời thực sự. Theo lời anh ấy:
Chief of Staff không nên đi debug mấy bài eval computer-use.
Hãy tuyển bot thứ hai khi bộ nhớ của một bot bắt đầu phải gánh hai việc.
Bạn sẽ nhận ra điều đó trước khi kịp gọi tên nó. Con bot quản lý inbox bắt đầu trả lời bằng giọng văn của con bot review code. Sở thích về lịch trình bị rò rỉ vào các bản tóm tắt nghiên cứu. Mỗi lần mở tin nhắn, bạn lại phải nhắc bot xem hôm nay nó đang đóng vai gì.
Lingxi Li, người dùng chính Grok Bot để xây dựng Grok Bot, cũng nói điều tương tự từ góc độ kỹ thuật: bot "hoạt động tốt nhất khi chỉ tập trung vào một lĩnh vực duy nhất".
Bài test: Đây là skill hay là bot?
Tài liệu định nghĩa skill là "một tập hợp hướng dẫn có thể tái sử dụng về cách thực hiện một tác vụ", và các private skill của bạn là một thư viện dùng chung cho tất cả bot.
Vậy nên, một tác vụ mới là một skill. Còn một lĩnh vực mới với bộ nhớ riêng mới là một bot. Nếu bạn không thể gọi tên lĩnh vực đó trong ba từ, bạn chưa cần thêm bot đâu.
Phần 2. Năm mảnh ghép của một team
1. Cửa ngõ (The front door)
Con bot duy nhất mà bạn thực sự nói chuyện. Hướng dẫn của Josh Kim gọi nó là Bot Boss, "cửa ngõ duy nhất". Niparko gọi nó là Chief of Staff và mô tả trong hai câu: "Kẻ đa năng duy nhất. Im lặng nếu không có gì thay đổi."
Cửa ngõ chỉ phân phối. Nó không trực tiếp làm. Câu prompt của Kim nói rất thẳng: "bạn là EA hoạt động theo mô hình hub and spoke, không phải thợ xây cũng chẳng phải kiểm toán viên".
Một câu prompt bạn có thể copy luôn:
Bạn là Chief of Staff của tôi và là con bot duy nhất tôi nói chuyện. Hãy chuyển mọi yêu cầu đến đúng chuyên gia phụ trách, thu thập kết quả, đối chiếu với những gì tôi đã yêu cầu, và báo cáo lại trong năm dòng. Giữ im lặng nếu không có gì thay đổi.
2. Các chuyên gia (The specialists)
Đội hình của Niparko: một Chief of Staff, một quản lý kỹ thuật tên Emily, năm bot kỹ sư, một chuyên viên phân tích dữ liệu, một bot PM và một nhà tuyển dụng. Đội hình của Li: năm bot kỹ sư chia theo nền tảng (iOS, desktop, infrastructure, Android, harness) cộng thêm Jenny, trưởng bộ phận vận hành.
Hãy nhìn điểm chung của cả hai team. Một người quản lý không trực tiếp làm việc. Emily chia nhỏ task, giao việc và đối chiếu output với mục tiêu. Jenny onboard bot mới và chạy postmortem. Cả hai đều không viết dòng code nào.
Với team đầu tiên, ba chuyên gia là đủ. Eric Zakariasson giới hạn mỗi kênh dự án tối đa sáu bot và gọi con số đó là "chỉ mang tính ước lệ". Ước lệ, nhưng chuẩn xác.
3. Bảng việc (The board)
Tin nhắn chat rồi sẽ trôi. Một team cần một nơi duy nhất lưu giữ trạng thái công việc.
Team của Li dùng một tracker chung trên Notion. Cứ 30 phút, các bot lại kiểm tra từng PR xem có lỗi CI, comment review hay conflict khi merge không. Vấn đề nào có lỗi sẽ bị đẩy về trạng thái Working. Cái nào sạch thì chuyển sang Ready for Review.
Zakariasson chạy hai database là Projects và Tasks, mỗi dự án một kênh. Bot nào bị kẹt sẽ đánh dấu task của mình là Blocked và ping người dùng. Thời gian còn lại, con người chỉ việc ngồi nhìn các thẻ di chuyển.
Câu hay nhất trong tất cả các bản hướng dẫn nằm ở đây:
Điều thú vị là càng xây dựng thêm trên nền tảng này, nó càng giống với một hệ thống ban đầu được tạo ra dành cho con người.
4. Đồng hồ (The clock)
Theo tài liệu, một routine "báo cho một Bot biết khi nào cần chạy workflow". Mỗi bot có thể chứa tối đa 50 routine, có thể kích hoạt thường xuyên tới mức mỗi 5 phút một lần, và chúng vẫn chạy ngay cả khi bạn gập laptop lại.
Chiếc đồng hồ của Li hoạt động thế này. 3 giờ sáng, các đợt audit hàng đêm chạy: dead code, thời gian tải, dung lượng bundle. 5 giờ sáng, Jenny họp 1:1 với từng bot trong team, rà soát playbook và lôi các điểm nghẽn ra ánh sáng. Kết quả ghi nhận được: các bot "hiếm khi quên những workflow phức tạp của tôi, kể cả sau nhiều tuần".
Buổi standup lúc 5 giờ sáng đó là ý tưởng bị đánh giá thấp nhất trong toàn bộ hệ thống này. Context của một bot có giới hạn. Sự lặp lại chính là cách một team duy trì tiêu chuẩn, và ở đây, một con bot sẽ làm việc lặp lại đó thay bạn.
5. Chốt chặn (The gate)
Niparko nói về những việc vẫn cần con người:
Tôi vẫn tự tay duyệt cuối cùng với mọi email gửi ra ngoài, mọi giao dịch mua sắm, hoặc các hành động phá hủy như xóa dữ liệu.
Kim còn làm gắt hơn. Con bot quản lý inbox chỉ có quyền đọc và tuyệt đối không gửi gì đi cho đến khi chữ "send" được gõ vào ngay lúc đó.
Hai sự thật từ tài liệu sẽ thay đổi cách bạn thiết kế chốt chặn:
- Các yêu cầu duyệt dưới nền sẽ hết hạn. Khi một routine hoặc bot khác kích hoạt hành động cần bạn gật đầu, yêu cầu đó sẽ hết hiệu lực sau khoảng 10 phút và hành động sẽ không được thực thi. Một job lúc 3 giờ sáng chờ bạn duyệt sẽ chết trong lúc chờ. Hãy quyết định trước: hoặc viết sẵn một allow rule cho nó, hoặc cài đặt để routine dừng lại ở bản nháp.
- Tất cả bot của bạn dùng chung một máy tính đám mây. File, phiên trình duyệt và thông tin đăng nhập được chia sẻ xuyên suốt cả đội hình. Tài liệu nói thẳng: đừng coi các bot riêng lẻ là một ranh giới bảo mật.
Bạn chia bot để tối ưu sự tập trung và bộ nhớ. Còn sự an toàn đến từ chốt chặn.
Phần 3. Xây dựng trong năm ngày
Ngày 1. Cửa ngõ. Thăng cấp con bot đầu tiên của bạn lên Chief of Staff bằng câu prompt ở trên. Từ giờ trở đi, đó là khung chat duy nhất bạn mở.
Ngày 2. Chia theo bộ nhớ. Liệt kê mọi thứ con bot số một đang làm hôm nay và nhóm danh sách đó theo lĩnh vực. Hai nhóm lớn nhất sẽ trở thành hai chuyên gia đầu tiên. Cài đặt của một bot gồm ba trường: Name, Title, Description. Hãy điền chúng như thể bạn đang viết một tin tuyển dụng.
Ngày 3. Bảng việc. Một bảng với Task, Owner và Status: Todo, Working, Blocked, Ready for Review, Done. Sau đó dặn tất cả bot cùng một câu: không có gì được coi là xong cho đến khi bảng việc nói vậy, và nếu bị kẹt, hãy chuyển sang Blocked rồi ping tôi.
Ngày 4. Đồng hồ. Ba routine để bắt đầu: một bản tin buổi sáng từ Chief of Staff, một lượt quét bảng việc mỗi 30 phút, và một đợt audit ban đêm. Hãy chạy thử từng cái với input an toàn trước. Tài liệu cảnh báo rằng một lần chạy thử "vẫn thực hiện công việc thật".
Ngày 5. Chốt chặn. Viết các luật "hỏi trước khi làm": gửi tin, mua sắm, xóa, xuất bản, bất cứ thứ gì liên quan đến production. Thêm một allow rule cho hành động mà bạn đã duyệt thủ công năm lần liên tiếp.
Sau đó, hãy để yên một tuần trước khi tuyển con bot thứ tư.
Năm sai lầm giết chết một team bot
Đội quân nhân bản. Năm bản sao của cùng một con bot đa năng. Không có bộ nhớ khoanh vùng, không lĩnh vực, không lợi ích. Bạn chỉ nhân bản chi phí và giữ nguyên sự lộn xộn.
Group chat không có bảng việc. Các bot có thể nhắn tin và kích hoạt lẫn nhau. Không có trạng thái dùng chung, đó là một cuộc họp, không phải công việc.
Sếp thích xắn tay áo. Một cửa ngõ bắt đầu tự nhảy vào làm việc. Khoảnh khắc Chief of Staff của bạn đi viết code, sẽ không còn ai phân phối và không ai kiểm tra nữa.
Bộ lắng nghe quá rộng. Một trigger gắn vào mọi tin nhắn mới. Tài liệu cảnh báo chính xác điều này vì nó tạo ra nhiễu và đốt sạch quota sử dụng. Hãy match thật hẹp.
Ảo tưởng bảo mật. Tin rằng bot tài chính không thể thấy những gì bot nghiên cứu đã đăng nhập. Cùng một máy tính, cùng các phiên làm việc.
Sơ đồ tổ chức chính là sản phẩm
Những người xây dựng Grok Bot không phát minh ra kiến trúc mới nào cho team của họ. Họ chỉ dựng lại kiến trúc cổ xưa nhất: một người quản lý, các chuyên gia, một bảng việc, một buổi standup và một bước ký duyệt.
Khác biệt duy nhất là team này họp standup lúc 5 giờ sáng và không ai phàn nàn.
Hãy bắt đầu từ cửa ngõ. Thêm một chuyên gia. Đừng thêm người thứ ba cho đến khi bảng việc tồn tại.
P.S. Nếu bạn chưa tuyển con bot đầu tiên, hãy bắt đầu với hướng dẫn trước đó của tôi, "Grok Bot: How to Hire Your First AI Employee". Mọi trích dẫn trong bài đều lấy từ các hướng dẫn và tài liệu công khai về Grok Bot của xAI.
