Xây dựng Session Supervisor - Hạt nhân của mọi hệ thống AI OS

Mọi thứ đang hội tụ về một loại hệ thống mà ta chưa gọi đúng tên: hệ điều hành cho đội AI. Hệ điều hành thật có kernel; hệ điều hành AI cũng cần một hạt nhân như thế - một session Claude đứng trên các session khác, giữ nhịp, giữ kênh, giữ quyền và giữ chữ "xong". Bài này dựng hạt nhân đó từng bước - supervisor là gì và vì sao nó khả thi, bảy đặc điểm nó bắt buộc phải có, mô hình logic của Jarvis Assistant bản mình build - rồi kể phần mặn nhất bằng đúng thứ tự sai trước thành sau, vì mỗi lần sai trả về một con số đo được.

Session supervisor là gì

Hình dung một đội trực ca. Trưởng ca, nhân sự, bộ đàm, sổ giao ca, và một biên bản phím quyền ghi rõ trưởng ca được quyết việc gì. Session supervisor chính là giao vai trưởng ca đó cho một AI - một session Claude Code đứng trên các session Claude khác: đọc trạng thái từng đứa, quyết việc thay bạn, giao việc mới, khép việc xong.

Điểm khác căn bản so với agent view của Claude Code nằm ở quyền ra quyết định. Agent view là màn hình cho NGƯỜI nhìn cả đội, còn supervisor là một AI trực tiếp cầm trịch - nó quyết, chứ không chỉ đứng xem. Nếu bạn từng mở năm cửa sổ terminal chạy năm session rồi nhận ra mình đang làm đúng nghề trưởng ca mà chẳng có sổ sách, bạn đã cần một session supervisor.

Vì sao một session lại điều phối được session khác? Claude Code không có tính năng đặc biệt nào cho việc này - nó khả thi nhờ ba tính chất nền của chính session, tất cả đều kiểm chứng được. Một, trí nhớ của session là file: mọi hội thoại ghi liên tục vào transcript JSONL trên đĩa - session không phải hộp đen, thứ không đọc được thì không supervise được. Hai, điểm vào ra đều có địa chỉ: ô input ghi được từ ngoài qua tmux paste-buffer, còn claude agents --json là đường chuẩn tài liệu nêu sẵn để một session khác giám sát công việc nền. Ba, session chạy được shell - gọi API, đọc log, gửi Telegram; với thế giới bên ngoài nó chỉ là một process bình thường đủ quyền đọc ghi.

Gộp lại: supervisor không phải một tính năng mới mà là một pattern. Khi một session đủ quyền, đọc đúng chỗ, ghi đúng chỗ, nó nghiễm nhiên trở thành "người trong cuộc" hợp pháp của cả đội. Không cần đợi ai cấp phép.

Bảy đặc điểm function một supervisor phải có

Pattern khả thi mới chỉ là điểm xuất phát. Đặt mình vào ghế quản ca rồi tự hỏi từng câu - mỗi câu sinh ra một yêu cầu chức năng, đúng bảy câu là trọn vẹn một supervisor.

Ai giữ nhịp khi bạn vắng mặt, và ai chọn việc để làm? Đòi toàn quyền điều phối với hai chế độ đi cặp: autopilot giữ nhịp vận hành, plan mode nhìn tổng thể mục tiêu rồi cascade kế hoạch xuống từng tầng ngày. Bạn đi vắng nửa ngày, quay lại không biết đội đã làm gì? Đòi chế độ report định kỳ - im lặng vốn là mặc định của AI, nên báo cáo phải dựng sẵn thành hạ tầng chứ không phải đức tính để kỳ vọng.

Muốn buông máy mà vẫn nắm việc từ điện thoại thì cần giao tiếp hai chiều qua Telegram. Nói chuyện với cả đội mà không loạn? Phải bind từng session với đúng một topic - nhắn vào kênh nào tin rơi trúng session đó. Việc thật đẻ ra file thật thì đòi file hai chiều: tài liệu xuống session, file kết quả đã xử lý lên để duyệt ngay trên điện thoại. Còn hệ thống lớn dần mà không thêm người canh? Đòi chế độ tự nâng cấp - phát hiện ra gap là hệ thống tự sửa chính hệ thống qua vòng kiểm chứng.

Và câu hiểm nhất: nó bảo "xong rồi" thì tin không? Bắt buộc có bộ kiểm chứng done-verify chống AI lazy - bởi AI lazy không nằm im, nó báo DONE. Chưa qua cửa kiểm tra thì continue, người chỉ vào khi AI đã chứng minh hết phần việc của AI.

Bảy đặc điểm này vẽ vào một hình thì ra thế này.

Để ý kỹ sẽ thấy chẳng câu hỏi nào hỏi về công nghệ - tất cả xoay quanh quản trị. Khuyết một trong bảy, khâu đó lập tức đổ lên đầu bạn, và bạn vừa dựng xong cái đài trực ca mà đêm vẫn mất ngủ.

Vì sao session supervisor là hạt nhân của mọi hệ thống AI OS

Hệ điều hành thật làm bốn việc: quản lý process, cấp phát bộ nhớ, định tuyến vào ra, giữ chính sách quyền hạn. Hệ điều hành cho đội AI - AI OS - làm đúng bốn việc đó, chỉ đổi đơn vị. Đơn vị tính toán là session. Tài sản cấp phát và thu hồi là ngữ cảnh - file transcript. Cổng vào ra là kênh giao tiếp với người. Chính sách là ai được quyết việc gì.

Theo mình, session supervisor chính là kernel của bản hệ điều hành đó, vì ba lý do. Một, mọi tài nguyên của "máy AI" quy về session - nắm được session là điều phối được toàn bộ cỗ máy; skill hay tool suy cho cùng chỉ là module cắm vào, riêng lớp điều phối không thay được. Hai, chính sách quyền hạn chỉ sống ổn ở MỘT chỗ - rải quyền ra các session là mỗi đứa tự diễn giải một kiểu, gom về một node thì mọi quyết định đều truy ngược được về đúng một gốc. Ba, đây là điều kiện duy nhất để scale từ "một người × nhiều AI" thành một hệ thống - thiếu lớp điều phối, thêm mỗi AI là thêm một việc phải canh chừng; có nó rồi, thêm AI chỉ là giao thêm nhân sự cho trưởng ca sẵn có.

Mình không biết các nền tảng sẽ đặt tên cho khối này là gì. Chỉ biết từ trải nghiệm vận hành thật, mọi hướng đi nghiêm túc về một hệ điều hành AI đều phải hội tụ về một node như thế - nơi giữ nhịp, giữ kênh, giữ quyền, và giữ chữ "xong".

Mô hình logic của Jarvis Assistant

Từ bảy đặc điểm đó, mô hình logic của Jarvis Assistant - bản supervisor mình thiết kế - có năm tầng.

Đọc từ trên xuống: bạn với điện thoại, Telegram mỗi session một topic, rồi tầng điều phối gồm relay trung chuyển và Jarvis cầm charter, tầng thực thi là các worker session, đáy cùng là launchd giữ nhịp - nét đứt, dậy định kỳ, sống qua reboot. Khối cho biết hệ thống có gì; muốn thấy một dòng tin đi trọn vòng đời thì nhìn dạng sequence.

Hai mũi tên của bạn trong hình nói lên tất cả: bạn chỉ xuất hiện ở hai đầu chuỗi - nhắn chỉ thị đầu tiên, và nhận file cuối cùng. Mọi mũi tên ở giữa do hạ tầng tự chạy. Đó chính là định nghĩa của "mình ngủ được".

Bản vẽ xong. Phần còn lại là đem ra đời thật - và bản vẽ gãy ở đâu, kể từ đây.

Thử nghiệm thực tế - bốn lần gãy, bốn bài học đo được

Đêm trực ca đầu tiên của Jarvis, mình ngủ từ 1 giờ - lần đầu sau nhiều năm không thức canh hệ thống của chính mình. Đổi lấy giấc ngủ đó là bốn lần gãy, mỗi lần một con số.

Gãy thứ nhất ở chỗ giao việc. Mỗi window của session tmux vibe_working là một nhân sự, giao việc bằng cách paste chỉ thị vào window. Jarvis gửi bằng tmux send-keys, lệnh gõ từng ký tự - session đích đang bận thì ô input chỉ hứng phần đuôi, và phím Enter chốt một bản cụt. Tin gốc hơn 4096 ký tự, tới nơi còn 420. Đo từng lớp mới ra thủ phạm thật: tmux vô tội (buffer 4508/4508 nguyên vẹn), còn ô input của Claude TUI tự rớt paste lớn - đo được 2464/4508 và 358/4446 ở hai payload khác nhau.

Lưu ý quan trọng: paste vào ô input Claude Code quá khoảng 400 ký tự là đánh bạc. Nội dung dài phải đi qua file - ghi ra file dispatch, paste duy nhất thông điệp con trỏ dưới 200 ký tự kiểu "ĐỌC VÀ THỰC THI <đường-dẫn-file>". Con trỏ 157 ký tự này tới nơi nguyên vẹn qua hàng chục lần gửi. Và paste xong KHÔNG tự submit - phải Enter lần thứ hai.

Gãy thứ hai mang hình một con số: 409. HTTP 409 Conflict nghĩa là có hơn một consumer cùng poll một bot token - hai máy nhà mình dùng chung token, lỗi lúc sống lúc chết, đúng kiểu khó phát hiện nhất. Truy đến cùng ra một listener cũ trên Mac Mini tự sống lại theo lịch do một binary tự cài lại launch agent; bootout không đủ, phải disable. Chung cuộc: bot riêng cho Jarvis. Bài học phụ đáng giá ngang bài chính: health check grep chuỗi "409" báo động giả liên tục - vì user-id Telegram của mình có chứa "409". Match message lỗi đầy đủ, đừng match con số trần.

Sạch sóng rồi, hai đặc điểm bộ đàm mới thành hình. Bind từng session một topic theo bảng map topics.json - cao điểm sáu session sáu topic, nhìn cả đội từ điện thoại như sáu kênh trực tiếp. Và file hai chiều: bản relay đầu chỉ biết text, zip gửi tới bị drop im lặng - giờ tải về inbox kèm nhãn [TG FILE], chiều ngược lại gửi file kết quả lên đúng topic.

Gãy thứ ba chia ba đợt học phí. Thứ nhất, nhịp đều 5 phút kể cả đêm yên tĩnh - launchd dậy com.vccc.jarvis-autopilot đúng 300 giây dù cả đội đang nghỉ, nên bản vá adaptive cadence nhân đôi nhịp khi yên tĩnh (5→10→20→30 phút, công thức 300 × 2^số-vòng-yên-tĩnh, cap 1800 giây). Thứ hai, im lặng: user phàn nàn cả hệ thống im lìm và user đúng - heartbeat treo cứng 2.5 giờ, vì bản vá timeout dùng lệnh timeout vốn không tồn tại trên macOS (script tự gãy exit 127 ngay dòng đầu); bản vá cho bản vá là signal.alarm thuần Python. Từ đó report định kỳ thành hạ tầng hai nhịp: heartbeat 4 phút, digest 30 phút. Thứ ba, định dạng: Telegram từ chối digest MarkdownV2 ba lần liên tiếp bằng HTTP 400 - truy ra double-escape trong entity; giải pháp là hàm _normalize() idempotent, chạy lại không hỏng.

Chạy ổn rồi mới dám nói chuyện quyền hạn - phần mà ban đầu mình gần bỏ qua. Charter ghi ba nhóm: mục tiêu chuyến trực ca map về key result nào, những việc Jarvis được TOÀN QUYỀN quyết, và những việc PHẢI HỎI - mặc định mọi thứ bất khả đảo ngược. Nguyên tắc chốt: autopilot là TÔI QUYẾT với mọi việc còn đảo ngược được; việc không đảo ngược được thì hỏi; hỏi 10 phút không ai trả lời thì park rồi đi tiếp.

Plan mode theo đúng luật ấy - quét sáu nguồn thật (strategy, OKR, tracking, task treo, lịch, note cơ hội) rồi cascade bốn tầng Year/Month/Week/Day, tối đa năm việc một tầng, lên Telegram chờ duyệt rồi mới sync.

Gãy thứ tư là cú sốc đẹp nhất: chữ "xong". Một deck showcase được builder session tự chấm 9.3/10 - re-grade độc lập bởi model khác nhìn artifact thật: 3.8/10, hai lỗi critical. Gốc rễ là circular grading kèm điểm ngoại suy "≈" sau khi fix mà không chấm lại. Ba rule vá thành luật cứng của vibe-done-verify: cấm điểm ngoại suy, juror bắt buộc xem artifact thật thay vì vote trên bảng tóm tắt, tách nhãn "tồn tại đúng nguồn gốc" khỏi nhãn "chất lượng đạt". Chưa đạt là LAZY-CONTINUE - giao lại kèm gap, làm tiếp. Tin DONE thật rồi mới close: đủ bốn điều kiện (completion gate, harvest ba dòng logbook, không artifact chờ duyệt mắt, pane không bận) - vì đóng window không mất gì (resume bằng session-id), nhưng giết session giữa tool call là mất việc đang chạy.

Và đặc điểm đẹp nhất: tự nâng cấp. Chọn một gap bất kỳ trong bài này - bản vá heartbeat, hàm _normalize(), cơ chế bind topic - rồi truy xem ai viết: phần lớn do chính các worker session xây, qua pipeline improve bắt buộc qua engine kiểm chứng đối chiếu mọi claim "đã improved" trên diff thật trước-sau, claim nào diff không chứng minh được thì verdict bị veto. Ông trưởng ca được nuôi bằng chính sản phẩm của nhân sự nó canh.

Sau 24 giờ đối chiếu: khoảng 300 vòng autopilot, 12 mục goal re-audit qua jury đa model, 7 giờ sáng một bản handshake cho khách nằm sẵn trong topic. Bảy đặc điểm - đủ.

Một lời công cho analogy đội trực ca: nó giúp thiết kế rất nhiều, cho đến khi bắt đầu nói dối. Trưởng ca người nhìn là biết ai làm ai chơi, Jarvis phải poll và vẫn có khi đọc sai. Trưởng ca thật không quên giao ca, session AI quên mặc định - nên mọi thứ "phải nhớ" đều xuống hạ tầng. Còn ngược lại với nhân sự thật: nhân sự số idle không tốn lương, chỉ tốn RAM - nên quy tắc close tồn tại, thứ đội người thật không cần.

Tái lập một phần thí nghiệm trong 5 phút

Không cần cả hệ thống - chỉ lớp dưới cùng cũng đủ tự tay sai một lần.

tmux new -s demo -d
tmux new-window -t demo -n viec_1          # một window = một "nhân sự"
tmux send-keys -t demo:viec_1 "claude" Enter
tmux set-buffer -b chi_so "chỉ thị ngắn của bạn"
tmux paste-buffer -t demo:viec_1 -b chi_so # paste KHÔNG tự submit
tmux send-keys -t demo:viec_1 Enter        # Enter lần hai mới chạy

Thử set-buffer vài nghìn ký tự rồi paste - bạn sẽ tận mắt thấy TUI nhận về bao nhiêu phần trăm. Đó là gãy thứ nhất của bài, thu nhỏ vừa tay.

Ba câu tự kiểm tra

Một. Chỉ thị 4000 ký tự phải tới một session đang bận. Paste thẳng hay ghi file rồi gửi con trỏ - cách nào sống sót, và lớp nào rớt?

Hai. Hai máy dùng chung một bot token poll getUpdates. Hiện tượng gì xuất hiện, và vì sao không chết hẳn?

Ba. Session báo DONE. Bốn điều kiện nào phải thoả trước khi close window, và vì sao "không đang bận" dễ bị bỏ qua nhất?

Mang về

1. Viết biên bản phím quyền trước khi viết code - tự chạy mà không rõ ai được quyết gì là tai nạn, không phải tự động hóa
2. Paste dài qua file, ô input chỉ nhận con trỏ
3. Một hệ thống một bot token, đừng share consumer
4. Im lặng là mặc định - báo cáo phải là hạ tầng
5. Không tin chữ "xong" không kèm evidence
6. Đóng session như giao ca - đủ hồ sơ, đúng thời điểm
7. Việc đảo ngược được thì quyết thay, việc không thì hỏi

Và một câu bản thể, dùng được ngoài cả Claude Code: ủy thác thật sự bắt đầu ở biên bản phím quyền, không ở dòng code đầu tiên. Giao việc cho AI cũng như giao việc cho người - điều nguy hiểm nhất không phải máy làm sai, mà là không ai biết rõ ai đang có quyền quyết điều gì.

Tham khảo

• Docs sessions Claude Code - code.claude.com/docs/en/sessions.md - transcript JSONL, resume bằng session-id (truy cập 08/11/2026)
• Docs agent view Claude Code - code.claude.com/docs/en/agent-view.md - claude agents --json, giám sát từ session khác (truy cập 08/11/2026)
• Telegram Bot API - core.telegram.org/bots/api - getUpdates và hành vi 409 Conflict (truy cập 08/11/2026)
• tmux manual - paste-buffer, send-keys, buffer handling (truy cập 08/11/2026)
• claude-telegram-multi-relay - github.com/hailoc12/claude-telegram-multi-relay - relay nhiều session nhiều topic (repo của người viết)
• vibe-jarvis SKILL.md + kb/autopilot-mode.md, kb/planning-mode.md, kb/session-topic-binding.md - charter, plan mode, bind topic, close rule (máy người viết)
• vibe-done-verify SKILL.md - luật chống lazy, jury đa model, evidence grading (máy người viết)
• Logbook trực ca 08/11/2026 - ~/Projects/jarvis/logbook/2026-11-08.md - mỗi vòng một dòng, ghi trực tiếp (máy người viết)
• Bài trước trong chuỗi - Quản lý session trên Claude Code, tất tần tật từ A đến Z (blog người viết)

Lộc Đặng viết về vibe coding và cách giao việc cho AI như quản lý nhân sự. Nếu bạn đang muốn đưa AI vào quy trình làm việc của mình, xem thêm tại facebook.com/locdang.ai hoặc nhắn tin trực tiếp.