---
title: "Cách phối hợp Claude, Codex và Grok CLI"
description: "Cách phối hợp Codex, Claude Code và Grok Build để phát triển hệ thống. Các agents mạnh nhất sẽ debate, advise giải pháp trên nền thông tin chung được kiểm chứng."
canonical: "https://200lab.io/blog/cach-phoi-hop-claude-codex-va-grok-cli"
published: "2026-09-20T02:28:18Z"
updated: "2026-09-20T08:27:30Z"
authors: ["Việt Trần"]
tags: ["Harness", "Agent"]
reading_minutes: 11
access: "public"
---

Đây là cách mình phối hợp **Codex**, **Claude Code** và **Grok Build** để phát triển hệ thống và các đồ chơi cá nhân.

Harness chính của mình vẫn chỉ là Codex App/CLI. Tuy nhiên mình vẫn dùng thêm cả Claude và Grok cho một số việc cần thiết. Đoạn sau mình sẽ nói cách mình nối tụi này lại, cực kì dễ. Phần đáng nói hơn là cái luật để tụi nó tranh luận với nhau, vì thiếu nó thì ba model chỉ thay phiên nhau nói rất hay về thứ tụi nó vừa đoán.

## Chia vai cho ba thằng

Hiện tại mình chia vai cho ba thằng này khá rõ:

- **Codex + GPT-5.6 Sol, High**: Dùng cho những việc nặng về logic, audit, review và thiết lập các gates bằng code/script. Nếu đang build loop để tạo skill hoặc workflow thì SOL hiện là ứng cử viên Top 1 của mình. À Codex cũng có sẵn imagegen, xài GPT Image cho ra những images minh họa rất đẹp.
- **Claude Code + Fable 5** hoặc **Opus 5**, **High**: Dùng cho những bài toán cần thiết lập cấu trúc phức tạp ở cấp Enterprise hoặc Epic. Fable mạnh về research và tìm hướng đột phá cho giải pháp kỹ thuật. Opus mạnh về UX, quản lý các "góc nhìn" của từng user role trong từng tình huống cụ thể. Riêng design UI cho app thì Opus 5 vẫn là Top 1 với mình.
- **Grok Build + Grok 4.6**, **High**: System logic không mạnh bằng Fable, audit không chặt như SOL, design cũng chưa tới Opus. Nhưng quota mình đang có khá rộng, tốc độ lại rất nhanh. Nên mình dùng Grok 4.6 như một con ngựa thồ cao cấp. Các đầu việc phải spawn nhiều request như quét tài liệu, scan source code lớn, kiểm tra facts và evidence, hoặc cook thử nhiều giải pháp để so sánh, mình thường đẩy sang Grok 4.5/4.6.

Ngoài ra, Grok tạo video khá ngon và nhanh, nhưng mảng này mình ít dùng.

Gom lại thành bảng cho dễ nhìn:

| Vai | Ai giữ | Giao việc gì |
|---|---|---|
| Điều phối, quyết định cuối | Codex | Chia task, chọn chuyên gia, phân tích logic, audit, kiểm chứng claim, dựng gates, tổng hợp |
| Kiến trúc, research | Claude Fable | Cấu trúc cấp Enterprise/Epic, khả năng mở rộng dài hạn, tìm hướng đi không hiển nhiên, phản biện giả định kiến trúc |
| UX, góc nhìn người dùng | Claude Opus | UI/UX, phân quyền theo role, phân tích journey, những chỗ "đúng kỹ thuật nhưng trải nghiệm tệ" |
| Quét rộng, thử nhiều hướng | Grok Build | Scan source và tài liệu số lượng lớn, gom facts và nguồn, cook nhanh vài phương án, dò các failure case |

Có một điểm mình viết thẳng vào rules: Codex là thằng điều phối và ra quyết định cuối. Claude với Grok là chuyên gia mời ngoài, tụi nó nói gì cũng chỉ là ý kiến tham khảo. Nghe thì hiển nhiên, nhưng không viết ra thì rất dễ thành cảnh thằng nào nói tự tin hơn thì thằng đó thắng.

## Nối ba thằng lại với nhau

Cách nối ba thằng này với nhau cũng không có gì phức tạp: Trong `AGENTS.md`, mình khai báo sẵn máy đã cài sẵn Claude Code và Grok Build CLI, kèm link tới 1 file workflow `Arena - Discuss Round Table`.

Workflow này quy định rõ:

- Mỗi CLI giữ vai trò gì
- Lưu và check claims -> evidences như thế nào
- Quy tắc tranh luận
- Giới hạn số rounds
- Cách tổng hợp kết quả cuối cùng

Trong file đó có một rule nhỏ mà mình thấy rất đáng: không được đoán cú pháp CLI theo trí nhớ. Mấy CLI này ra bản mới liên tục, flags với tên model đổi hoài. Nên lần đầu gọi một CLI trong task, hoặc sau khi upgrade, hoặc khi một lệnh vừa fail, Codex phải tự chạy `--help` trên bản đang cài rồi mới gọi. Output của `--help` mới là chuẩn, không phải ví dụ trong file rules, càng không phải trí nhớ của model.

## Cãi nhau thì ai thắng?

Đây là phần mình coi là xương sống của cả workflow.

Khi hai thằng không đồng ý với nhau thì phân xử kiểu gì? Nếu để tụi nó tự thuyết phục nhau thì thằng viết trôi chảy hơn sẽ thắng, mà trôi chảy thì chẳng liên quan gì tới đúng. Nên mình xếp hẳn một thứ bậc bằng chứng, từ mạnh tới yếu:

1. Quyết định đã được user xác nhận và **locked**
2. Kết quả đã kiểm chứng bằng test hoặc thử nghiệm
3. Source code đang chạy, trạng thái database, logs, output của tool
4. Tài liệu chính thức và nguồn gốc
5. Suy luận có lý lẽ

Nghĩa là đồng thuận không bao giờ thắng được bằng chứng mạnh hơn. Ba model cùng gật đầu về một suy luận thì vẫn thua một cái test đang đỏ. Còn suy luận nào chưa kiểm chứng thì phải ghi rõ là chưa kiểm chứng.

Đương nhiên quyết định đã locked không phải là bất khả xâm phạm. Chuyên gia vẫn được phản biện, với điều kiện nó đưa ra được bằng chứng mới, thứ mà lúc khoá quyết định mình chưa cân nhắc. Lúc đó Codex phải đưa xung đột lên cho mình thấy, chứ không được lặng lẽ đảo quyết định.

> Điều quan trọng nhất của bài này là thứ bậc bằng chứng. Bạn chỉ xài một model thôi cũng nên dán nó vào rules: từ lúc đó agent hết cãi bằng sự tự tin, muốn cãi thì phải đưa test, log hoặc source ra.

## Context pack: cho tụi nó chung một nền

Đương nhiên, muốn việc tranh luận thực sự hiệu quả thì context của dự án phải được thiết lập đủ tốt. Trước khi gọi bất kỳ chuyên gia nào, Codex phải soạn một gói context gọn cho đúng task đó:

- Câu hỏi hoặc quyết định cần ra, viết cho chính xác
- Chỉ những file và symbol liên quan
- Các quyết định đã locked, bắt buộc giữ nguyên
- Những thử nghiệm đã xác nhận điều gì đúng, điều gì sai
- Ràng buộc, invariants và các hướng bị cấm
- Tiêu chí nghiệm thu
- Những điểm còn chưa chắc

Không quăng nguyên cuộc hội thoại hay nguyên repo sang khi một phần nhỏ là đủ. Secrets, credentials với dữ liệu người dùng không liên quan thì không bao giờ được kèm theo.

Nhờ vậy, các "chuyên gia" này có chung một context foundation để tranh luận, thay vì mỗi thằng tự đoán một hướng rồi nói rất hay về cái nó vừa đoán hoặc "tự bịa".

## Khi nào mới lôi cả ba thằng ra

Không phải việc gì mình cũng mở Arena. Việc đơn giản, cục bộ, hoặc chạy test là biết đúng sai thì một chuyên gia là đủ, nhiều khi chẳng cần ai. Mình chỉ gọi nhiều thằng khi task có ít nhất một trong mấy dấu hiệu này:

- Chưa rõ hướng nào đúng, độ bất định còn cao
- Có vài kiến trúc đang cạnh tranh nhau
- Ảnh hưởng cắt ngang nhiều phần của hệ thống
- Dính tới security hoặc toàn vẹn dữ liệu
- UX phức tạp theo nhiều role
- Có khả năng cao là đang sót một kịch bản quan trọng

## Luật tranh luận: tối đa 3 vòng

Một phiên Arena có tối đa 3 vòng, và vòng sau chỉ mở khi vòng trước chưa đủ.

**Vòng 1 là vòng độc lập.** Codex soạn một context pack chung về facts, kèm chỉ dẫn vai trò riêng cho từng thằng, và Claude với Grok không được thấy câu trả lời của nhau. Lý do là anchoring: thằng sau mà đọc được bài thằng trước thì mình sẽ nhận về hai phiên bản của cùng một ý tưởng, thay vì hai hướng tiếp cận thật sự khác nhau.

Câu trả lời cũng không được viết văn xuôi tự do mà phải theo khung: khuyến nghị, lý lẽ, giả định, bằng chứng (có đường dẫn file, số dòng hoặc kết quả test), rủi ro và mức tự tin. Có khung thì Codex mới đặt hai câu trả lời cạnh nhau mà so được. Sau đó Codex đối chiếu cả hai với thứ bậc bằng chứng ở trên, và tự kiểm lại các claim quan trọng bằng file thật, test, nguồn chính thức.

**Vòng 2 chỉ mở khi cần**: còn bất đồng đáng kể, sót một kịch bản, hoặc có một claim ảnh hưởng lớn mà chưa kiểm được. Mỗi thằng nhận một bản tóm tắt gọn các claim và bằng chứng của phía bên kia, không phải nguyên transcript. Luật của vòng này chỉ có một: phản biện claim và bằng chứng, không phản biện danh tiếng của model.

**Vòng 3 thì hiếm**, chỉ dành cho đúng một vấn đề ảnh hưởng lớn mà vẫn chưa ngã ngũ. Bằng chứng rõ rồi thì dừng sớm.

Có một chỗ dễ hiểu nhầm: con số 3 giới hạn số vòng phối hợp, không giới hạn số lượt suy nghĩ hay gọi tool bên trong mỗi thằng. Mình cố ý không đặt trần token, trần chi phí hay trần số turn cho Claude và Grok trong một vòng. Cắt ngang một thằng đang làm dở thì mình nhận về nửa câu trả lời, mà giọng điệu thì vẫn tự tin như cả câu. Im lặng chưa ra output cũng chưa chắc là nó bị treo.

Cuối cùng Codex viết bản tổng hợp: quyết định được chọn, bằng chứng quyết định, các phương án bị loại kèm lý do, và phần còn chưa chắc.

> Có những quyết định mà bằng chứng không trả lời thay được: chuyện business, sản phẩm, compliance, hay UX nên đi hướng nào. Tới đó thì cho tụi nó dừng lại và hỏi mình. Ba model biểu quyết kiểu gì cũng ra một đáp án, nhưng đáp án đúng thì chỉ có bạn biết.

## Cho ghi file thì phải chặt

Mặc định Claude và Grok chỉ chạy ở chế độ read-only hoặc plan, từ thư mục gốc của repo, và không bao giờ dùng flag bỏ qua kiểm tra quyền. Tụi nó chỉ được ghi khi Codex giao việc implement một cách tường minh.

Kể cả lúc đó mình vẫn giữ hai nguyên tắc: không để hai thằng sửa chồng lên cùng một chỗ, và Codex phải review diff, chạy đủ gates rồi mới nhận thay đổi.

## Có tốn kém không?

Mình thường dùng chúng phối hợp để giải các bài toán có độ phức tạp cao, ảnh hưởng sâu rộng. Hoặc giả lập đủ các tình huống và góc nhìn để xem thiết kế còn sót chỗ nào không, hoặc tìm các rủi ro chưa được cân nhắc.

Các bạn có thể nghĩ rằng cách này của mình tốn kém nhưng thực ra sự phối hợp của chúng chỉ nằm ở các phase pre-implement (brainstorm, report, research, consult, plan, simulate,...).

Những phần này thực sự không tốn nhiều tokens so với các implement phases. Chuẩn phần chuẩn bị thì đoạn sau rất nhẹ và đỡ tốn kém vì phải quay lại, break contracts,... Với lại có mấy con ngựa thồ xịn và rẻ như **Grok**, **DeepSeek v4** rồi cũng "nhẹ thận".

## Tự viết hay lấy file có sẵn

Tới đây thì bạn đủ đồ để tự viết một bản rules cho mình rồi: chia vai, thứ bậc bằng chứng, context pack, luật ba vòng và nguyên tắc read-only. Gói gọn lại thì nó là:

> Đúng model cho đúng vai, chung một context, cãi nhau bằng bằng chứng, và chốt lại bằng gates chạy được.

Còn nếu lười ngồi viết với tinh chỉnh thì file bên dưới là bản mình đang xài thật, viết bằng tiếng Anh để thả thẳng vào `AGENTS.md`. Ngoài những gì bài này đã kể, nó có thêm mấy phần mình cố ý không chép ra đây:

- Lệnh gọi mẫu đầy đủ flags cho Claude Fable, Claude Opus và Grok Build ở chế độ plan, output JSON
- Khung 8 mục bắt buộc cho câu trả lời của mỗi chuyên gia
- Format phản biện của vòng 2 và template bản tổng hợp cuối của Codex
- Danh sách điều kiện Codex được phép ngắt một chuyên gia
- Checklist 5 mục phải định nghĩa trước khi cấp quyền ghi

**Claude Codex Grok CLI Arena rules**

Rules và các thiết lập để đấu nối 3 agent cli để tạo môi trường thảo luận, debate các vấn đề khó trên cùng 1 ngữ cảnh nền

- Định dạng: ZIP · 1 tệp · 4,0 KB
- Giá: 9.000 ₫ · giá gốc 39.000 ₫ · mua một lần
- Truy cập: tải về sau khi mua, cần đăng nhập
- Mua: https://200lab.io/blog/cach-phoi-hop-claude-codex-va-grok-cli#artifact-01a0ba0b-d102-7750-ad4e-57964b0712b8

## Đọc thêm

- [Phân biệt Agent & Harness và tư duy giải cấu trúc](https://200lab.io/blog/phan-biet-agent-va-harness.md): Agent chọn làm gì tiếp theo, Harness điều phối và kiểm soát. Tách được hai phần này là bước đầu của tư duy giải cấu trúc khi làm hệ thống.
- [Mọi bài viết chủ đề Harness](https://200lab.io/blog/tags/harness.md)

Toàn bộ nội dung: https://200lab.io/llms.txt