Claude Code làm orchestrator

Một công trường có nhiều đội thầu chỉ chạy tốt khi có một người giữ bản vẽ tổng. Nếu mỗi đội vừa làm phần của mình vừa tự sửa kiến trúc, tự đổi lịch, tự quyết định tiêu chuẩn hoàn thiện, công trình sẽ không sụp ngay nhưng sẽ lệch dần theo những cách khó sửa. Trong workflow AI cũng vậy: nhiều agent (tác nhân AI có thể nhận nhiệm vụ, dùng công cụ và trả kết quả) không tự động tạo ra một hệ thống tốt hơn. Cần một điểm điều phối đủ rõ.

Ở bài trước mình viết về Codex chạy ngầm trong Claude Code, câu hỏi cuối là khi hai agent có thể gọi nhau qua MCP (Model Context Protocol, giao thức mở để ứng dụng AI gọi công cụ và dịch vụ theo cùng chuẩn), ai là orchestrator và ai là worker. Bài này là câu trả lời thực dụng của mình: mình chỉ nói chuyện với Claude Code. Mình viết prompt cho Claude Code, đưa mục tiêu cho Claude Code, và để Claude Code quyết định khi nào gọi Codex hoặc agy. Mình không mở Codex để prompt tay, cũng không mở agy để viết một prompt khác. Con người delegate cho Claude; Claude delegate cho worker.

Cách đặt vai trò này nghe nhỏ, nhưng nó đổi hẳn cảm giác làm việc. Nếu mình phải prompt cả Claude, Codex và agy, mình sẽ trở thành bộ định tuyến thủ công, vừa chia việc vừa copy kết quả vừa nhớ trạng thái từng nhánh. Khi Claude Code là orchestrator (bộ điều phối giữ kế hoạch, chia việc, nhận kết quả và quyết định tích hợp), hệ thống có một nơi giữ ý định chính. Codex và agy không cần biết toàn bộ câu chuyện; chúng chỉ cần nhận một ticket đủ hẹp, làm xong, rồi trả lại patch hoặc note.

Có một chi tiết tự tham chiếu khá đúng tinh thần này: chính essay này được sản xuất theo kiểu đó. Toàn không prompt Codex trực tiếp để “viết bài”; Toàn yêu cầu Claude Code dùng Codex như worker trong workflow. Điểm quan trọng không phải là khoe multi-agent, mà là giữ một kênh giao tiếp duy nhất giữa người và hệ thống.

Mental model: tech lead và contractor

Mental model mình dùng là tech lead và contractor. Claude Code giống tech lead: đọc repo, hiểu mục tiêu, giữ plan, biết phần nào rủi ro, phần nào cần test, phần nào không nên đụng. Nó có quyền quyết định decomposition, tích hợp patch, chạy kiểm tra cuối, và nói không với kết quả worker nếu thấy chưa đủ. Codex hoặc agy giống contractor: nhận một phạm vi hẹp, làm trong sandbox (vùng thực thi giới hạn để tránh ảnh hưởng ngoài phạm vi), trả lại kết quả, rồi rời khỏi bức tranh.

Một worker không nên sở hữu repo. Nếu nhiều agent cùng giữ full context window (cửa sổ ngữ cảnh, lượng thông tin model giữ được trong một phiên làm việc) và cùng sửa một working tree, trạng thái sẽ rối nhanh. Agent A đổi abstraction, agent B vẫn dựa trên abstraction cũ, agent C viết docs theo một phiên bản trung gian. Vấn đề không chỉ là conflict Git, mà là conflict trong mô hình tinh thần. Khi chỉ Claude Code giữ toàn cảnh, worker có thể làm phần việc nhỏ mà không đẩy toàn bộ hệ thống vào một cuộc họp ngầm giữa các model.

Codex hợp với vai worker code vì codex exec chạy headless (không cần giao diện tương tác, phù hợp script, CI hoặc lệnh tự động) và có output sạch. Với --json, nó phát JSONL event như thread.started, turn.started, item.completed, turn.completed, nên Claude hoặc script có thể theo dõi trạng thái bằng máy thay vì đọc prose. Với --output-schema, output có thể bị ép theo schema (khuôn dữ liệu mô tả trường và kiểu), giảm nhu cầu parse văn bản bằng regex. Trong các việc cần patch nhỏ, review, extraction hoặc generation có cấu trúc, đây là một lợi thế vận hành rõ.

agy ở vị trí worker thứ hai

agy lại có một vị trí khác. agy là Google Antigravity CLI (binary đang ở v1.0.0, khác với Antigravity desktop app v2.x — hai sản phẩm tách rời cùng hệ sinh thái), chạy standalone, có print mode -p, hỗ trợ --add-dir, có -c để continue, và auth qua Google Sign-In OAuth. Mình xem nó như một worker dùng thận trọng cho second opinion, pass tài liệu, hoặc một góc nhìn khác khi cần. Caveat thực tế là free tier nhỏ, khoảng 20 requests mỗi ngày và chia quota với desktop app, nên không hợp để fan-out vô tư. Nếu Codex là worker code dùng thường xuyên hơn nhờ codex exec và JSONL sạch, agy giống một reviewer phụ được gọi khi lợi ích đáng với quota.

Một fan-out thực tế

Một fan-out thực tế có thể bắt đầu từ một task gồm refactor, docs và tests. Claude Code đọc repo trước, xác định đường biên, và quyết định phần code nào có thể giao cho Codex. Nó viết prompt worker đủ cụ thể: file nào được đọc, file nào được sửa, tiêu chí test là gì, output cần gồm patch và rủi ro nào. Phần docs có thể giao cho agy để rà lại wording, phát hiện chỗ thiếu giải thích, hoặc đề xuất cấu trúc. Sau đó Claude nhận cả hai kết quả, không merge mù, mà tự đọc lại diff, chỉnh những chỗ chưa khớp, chạy test, và cập nhật plan.

Cái lợi không nên được mô tả đơn giản là “nhanh gấp ba”. Đôi khi overhead điều phối còn làm chậm hơn nếu task nhỏ. Lợi ích thật là Claude Code không phải nhét mọi side analysis vào context chính. Worker trả lại kết quả đã nén: patch, note, risk, assumption. Claude vẫn là nơi ra quyết định cuối, nhưng context chính không bị lấp bởi toàn bộ quá trình suy nghĩ phụ. Với những task dài, điều này giúp phiên làm việc bền hơn.

Git worktree là xương sống

Để parallel work không đè lên nhau, git worktree gần như là xương sống. Mỗi worker nên có một branch hoặc worktree riêng, để patch của nó không clobber phần của người khác. tmux giúp giữ nhiều phiên terminal, theo dõi lệnh dài, và quay lại từng worker khi cần. Đây là pattern cũ nhưng vẫn chắc: tách không gian file bằng Git, tách không gian chạy bằng terminal session, rồi để orchestrator tích hợp.

OMX, hay oh-my-codex, và cmux là những nỗ lực productize pattern đó. Chúng làm việc với nhiều agent và nhiều terminal dễ nhìn hơn, giảm phần cơ khí của worktree, split, session, và notification. Tuy vậy, mình không nghĩ ai cũng cần kéo ngay một lớp UI mới vào workflow. Nếu scale hiện tại chỉ là Claude gọi Codex thỉnh thoảng, setup đơn giản vẫn đủ. Khi bắt đầu có nhiều worker chạy song song, lúc đó câu hỏi “mình nhìn chúng bằng gì” mới trở nên rõ.

Cost discipline mới là phần dễ quên

Cost discipline là phần ít hào nhoáng nhưng quyết định workflow có sống được không. Mình giữ Claude Code subscription như orchestrator always-on, vì đó là nơi mình làm việc chính. Codex và agy là worker calls có chi phí hoặc quota, nên nên được dùng như tài nguyên có chủ đích. Nếu một agent cứ gọi worker trong loop để “xem thêm một chút”, workflow sẽ trở thành máy đốt token. Fan-out chỉ đáng khi task có biên rõ, output có thể kiểm, và context chính thật sự được giảm tải.

Khi nào không nên orchestrate

Có một dạng lạm dụng multi-agent khá dễ gặp: chia việc chỉ vì có thể chia. Một bug nhỏ trong một file có thể được Claude Code sửa trực tiếp nhanh hơn việc viết prompt cho worker, chờ worker chạy, đọc patch, rồi merge. Một quyết định kiến trúc đang mơ hồ cũng không nên ném cho worker, vì worker thiếu toàn cảnh sẽ tạo ra câu trả lời nghe hợp lý nhưng lệch ưu tiên. Việc cần orchestrator giữ trong đầu là việc có coupling cao, nhiều trade-off, hoặc phụ thuộc vào lịch sử quyết định của repo.

Ngược lại, việc hợp để giao đi thường có boundary rõ. Ví dụ: “đọc module này và đề xuất test cases còn thiếu”, “tạo migration theo schema đã cho”, “rà docs để tìm chỗ lệch với API hiện tại”, “trích xuất action items từ 20 note theo JSON Schema”. Những việc này có input, output và tiêu chí đánh giá tương đối cụ thể. Worker không cần hiểu linh hồn của cả codebase để làm tốt.

Kỹ năng thật sự là decomposition

Kỹ năng thật vì vậy không nằm ở việc biết gọi bao nhiêu agent. Nó nằm ở decomposition: biết phần nào cần toàn cảnh, phần nào là ticket hẹp, phần nào nên chạy song song, phần nào không đáng orchestrate. Claude Code làm orchestrator chỉ hiệu quả nếu mình cung cấp mục tiêu đủ rõ và để nó giữ quyền tích hợp. Codex và agy chỉ hiệu quả nếu prompt worker đủ cụ thể để không cần tự phát minh bối cảnh.

Mình đang nghiêng về một workflow khá khiêm tốn: một orchestrator chính, vài worker headless, worktree khi cần song song, và kỷ luật không fan-out nếu chưa có lý do. Nó không làm quá trình phát triển biến thành dàn nhạc tự động hoàn hảo, nhưng nó giảm việc mình phải tự làm người chuyển tiếp giữa các cửa sổ chat. Khi nhiều agent xuất hiện, câu hỏi mình thấy đáng hỏi không phải là agent nào giỏi nhất, mà là việc nào xứng đáng được tách khỏi đầu của orchestrator. Bạn đang chia việc giữa các agent theo tiêu chí nào?