Cách quản lý nhiều Codex Agents mà không bị rối

Chạy từ ba agent Codex trở lên nghĩa là bạn sẽ không còn theo dõi được cái nào đã xong, cái nào thất bại, cái nào cần xem xét. Đây là cách thiết lập worktree thủ công, điểm mà nó không còn mở rộng được, và một danh sách kiểm tra bạn có thể áp dụng ngay hôm nay.

Aiden Flux

Aiden Flux

4 tháng 11 2026

Cách quản lý nhiều Codex Agents mà không bị rối

Chạy một agent Codex thì đơn giản. Bạn mở terminal, mô tả một tác vụ, rồi ngồi xem nó làm việc. Rắc rối bắt đầu từ con số ba. Một agent đang refactor module auth, một agent khác đang sửa một test chập chờn, agent thứ ba đang soạn migration, và mỗi agent nằm trong một tab terminal riêng với vùng scrollback riêng. Mười phút sau, bạn không còn nhớ tab nào chứa tác vụ nào, migration đã xong chưa, hay bản sửa test đã đáp xuống nhánh nào. Các agent vẫn ổn. Thứ hỏng là khả năng theo dõi chúng của bạn.

Đây mới là vấn đề thực sự đằng sau cụm “quản lý nhiều agent Codex”. Vấn đề không nằm ở khả năng chạy đồng thời; Codex sẵn sàng chạy song song trên nhiều thư mục làm việc tách biệt. Vấn đề là trạng thái của công việc đó — mỗi agent đang làm gì, cái gì đã xong, cái gì thất bại, và cái gì cần bạn duyệt — lại nằm rải rác khắp các tab terminal, thư mục worktree và trong trí nhớ của chính bạn. Đánh mất một trong số đó là bạn mất luôn mạch công việc.

Sharkly ra đời đúng để lấp khoảng trống này. Bạn đã có các coding agent; Sharkly biến chúng thành một đội ngũ bằng cách cho mỗi lượt chạy agent một bản ghi chung. Bài viết này đi qua phần thiết lập thủ công trước, vì bạn nên hiểu rõ thứ mình đang tự động hóa, rồi sau đó chỉ ra chỗ mà một bảng tác vụ thực sự phát huy giá trị. Kết thúc bài, bạn sẽ có một checklist có thể áp dụng ngay hôm nay.

“Mất dấu” thực chất nghĩa là gì

Mất dấu không phải chuyện mơ hồ. Đó là một kiểu hỏng hóc rất cụ thể: trạng thái công việc của bạn không có một nơi lưu trú duy nhất. Khi bạn chạy nhiều phiên Codex bằng tay, sự thật về mỗi tác vụ bị chia thành bốn nơi cùng lúc. Chỉ dẫn nằm trong terminal mà bạn gõ nó, các thay đổi nằm trong thư mục làm việc Git, trạng thái nằm trong đầu bạn, còn kết quả nằm trong một pull request bạn chưa mở. Không có gì giữ bốn thứ đó đồng bộ với nhau. Đóng terminal là chỉ dẫn biến mất. Chuyển tab là trạng thái chỉ còn là phỏng đoán. Càng thêm agent, bạn càng phải duy trì nhiều bản sao của “chuyện gì đang diễn ra”, và bạn chính là điểm tích hợp duy nhất giữ chúng dính lại với nhau.

Vậy nên mục tiêu của việc quản lý nhiều agent Codex khá hẹp và đáng nói thẳng ra: giữ tác vụ, tiến độ, thay đổi và trạng thái duyệt của mọi agent ở một nơi, thay vì chia tán chúng ra khắp các phiên terminal riêng tư. Mọi thứ bên dưới đều được đánh giá dựa trên đúng một tiêu chí đó.

Bước 1: Cô lập mỗi agent bằng một worktree

Kiểu hỏng đầu tiên là xung đột. Trỏ hai agent Codex vào cùng một thư mục và chúng sẽ ghi đè lên các chỉnh sửa của nhau, stage các file của nhau, rồi tạo ra một diff không ai đọc nổi. Git worktrees khắc phục điều này gọn gàng bằng cách cho mỗi agent bản checkout riêng của cùng một repository, trên nhánh riêng của nó.

# One isolated working directory per task, each on its own branch
git worktree add ../repo-auth      -b agent/auth-refactor
git worktree add ../repo-flaky     -b agent/flaky-test
git worktree add ../repo-migration -b agent/db-migration

Giờ hãy khởi động một phiên Codex trong mỗi thư mục. Mỗi agent chỉ thấy các file của riêng nó, commit lên nhánh riêng, và không thể giẫm chân lên các agent khác.

cd ../repo-auth && codex     # agent 1, auth refactor
cd ../repo-flaky && codex    # agent 2, flaky test

Kiểu hỏng cần gọi tên ở đây: worktree giải quyết xung đột file, chứ không giải quyết việc theo dõi. Giờ bạn có ba thư mục với những cái tên gần như giống hệt nhau và không một bản ghi nào cho biết mỗi thư mục chứa tác vụ gì. Hãy đặt một quy ước đặt tên mã hóa tác vụ (agent/<task>), vì một tuần nữa repo-2 và repo-3 sẽ chẳng còn nghĩa lý gì. Nếu muốn đi sâu vào cơ chế, xem Git worktree cho các agent lập trình AI và mô hình rộng hơn trong chạy nhiều tác vụ Codex cùng lúc.

Bước 2: Giữ các phiên trong tầm mắt

Ba agent trong ba tab nghĩa là chỉ cần một lần lỡ tay bấm Cmd+W là bạn đã giết một tác vụ đang chạy và mất luôn vùng scrollback của nó. Một trình quản lý nhiều phiên terminal như tmux giữ mọi phiên sống trong những cửa sổ có tên, để bạn có thể detach rồi attach lại sau.

tmux new-session -d -s codex -n auth      'cd ../repo-auth && codex'
tmux new-window        -t codex   -n flaky 'cd ../repo-flaky && codex'
tmux new-window        -t codex   -n migration 'cd ../repo-migration && codex'
tmux attach -t codex

Các cửa sổ có tên (auth, flaky, migration) khôi phục lại cái nhãn mà một tab thô đã ném đi. Detach bằng Ctrl-b d, gấp laptop lại, sáng hôm sau attach lại, và các phiên vẫn còn nguyên đó.

Kiểu hỏng cần gọi tên ở đây: tmux giữ các phiên tiếp tục chạy; nó không nói cho bạn biết phiên nào đang cần bạn. Một agent đã xong từ hai mươi phút trước và một agent vừa gặp lỗi trông giống hệt nhau từ bên ngoài: một khung pane im lìm. Bạn vẫn phải ghé thăm từng cửa sổ và đọc trăm dòng cuối để biết trạng thái của nó. Chi phí thăm dò đó tăng lên theo từng agent bạn thêm vào, và chính nó là khoản thuế khiến bộ thiết lập thủ công ngày càng nặng nề.

Bước 3: Ghi lại trạng thái và việc duyệt ở một nơi bền vững

Phần thủ công cuối cùng là phần mọi người hay bỏ qua: ghi lại mỗi agent đã tạo ra gì và bạn có chấp nhận nó hay không. Scrollback không phải là bản ghi. Nó biến mất, không thể tìm kiếm xuyên các tác vụ, và đồng nghiệp không đọc được. Phiên bản nhẹ nhàng nhất là một checklist đơn giản bạn tự tay cập nhật.

TASK          BRANCH                 STATUS       REVIEW
auth refactor agent/auth-refactor    done         needs review
flaky test    agent/flaky-test       running      -
db migration  agent/db-migration     failed: perm not reviewed

Đây chính là toàn bộ công việc thu nhỏ lại: một nơi bền vững để tiến độ, điểm tắc, kết quả và việc duyệt của con người luôn hiển thị từ lúc đưa ra yêu cầu đến lúc phát hành. Giữ nó trung thực và bạn có thể quản lý nhiều agent từ terminal trong một thời gian dài. Vấn đề là chính bạn là cỗ máy đồng bộ, phải cập nhật nó bằng tay mỗi khi có bất cứ thay đổi nào. Để hiểu thêm về cách khiến kết quả của agent có thể kiểm toán được, xem cách theo dõi công việc do các agent lập trình AI hoàn thành.

Chỗ mà cách tự làm bắt đầu hết khả năng mở rộng

Hãy trung thực về thời điểm cách làm thủ công là đủ. Với một hoặc hai agent Codex trên những tác vụ được khoanh vùng rõ ràng, worktree cộng với quy ước đặt tên cộng với một file trạng thái tự tay cập nhật thực sự là ổn. Đừng thêm công cụ mà bạn không cần; số thành phần chuyển động gần như bằng không và toàn bộ hệ thống vừa vặn trong đầu bạn.

Phương trình thay đổi ở một điểm có thể dự đoán được. Bạn cảm nhận được điều đó khi:

  • Bạn đang chạy từ ba agent trở lên và chi phí thăm dò (ghé từng pane, đọc phần đuôi, ghi nhớ trạng thái) ngốn nhiều thời gian hơn mức mà các agent tiết kiệm được.
  • Công việc trải rộng trên nhiều hơn một repository, nên chỉ riêng worktree không còn cho bạn một bức tranh gọn gàng.
  • Người khác hỏi “mấy con agent đang làm gì vậy?” và câu trả lời trung thực duy nhất chỉ nằm trong terminal và trí nhớ của bạn.

Mỗi trường hợp trong số này đều cùng một nguyên nhân gốc như đã nói ở đầu bài: trạng thái công việc không có nơi lưu trú chung. Cách thiết lập thủ công giữ nó ở đúng một nơi không thể mở rộng, chính là bạn. Các đội nhóm va vào bức tường này nhanh nhất, đó là lý do những công cụ tốt nhất để quản lý các agent lập trình AI song song đều hội tụ về cùng một nước đi: cho công việc một nơi lưu trú bên ngoài terminal.

Một bảng tác vụ thêm được gì

Bảng tác vụ thay đổi đơn vị quản lý từ “một phiên terminal” sang “một Task”. Trong Sharkly, bạn kết nối Computer mà mình vốn đã chạy Codex, rồi giao một Task cho một Codex Agent thay vì gõ lệnh vào một pane. Agent chạy trong worktree cô lập của riêng nó, và việc thực thi, tiến độ, điểm tắc cùng kết quả đều quay về Task. Bạn thôi thăm dò; bảng đã biết cái gì xong và cái gì thất bại.

Sự phân chia công việc là có chủ đích, và đáng nói rõ như một ranh giới: Sharkly không thay thế Codex. Codex đảm nhiệm việc thực thi. Sharkly bổ sung lớp tác vụ chung, Computer, ngữ cảnh và duyệt xung quanh nó. Agent nghiên cứu, thực thi, kiểm thử và báo cáo; con người định hướng, cấp quyền và chấp nhận kết quả. Tự động hóa dừng lại ở nơi cần đến phán đoán của bạn, tức là cổng duyệt, chứ không phải phần code.

Đó chính là điều mà file trạng thái thủ công đang cố vươn tới, nay được làm cho bền vững và chia sẻ. Có ba thứ terminal không thể mang lại cho bạn:

  • Trạng thái mà không cần thăm dò. Mỗi Task hiển thị đang chạy, đã xong, bị tắc hoặc cần duyệt mà bạn không phải ghé vào pane nào.
  • Một bức tranh xuyên repository. Các Task từ nhiều repo và nhiều Agent cùng nằm trong một Space, nên thêm agent không có nghĩa là thêm terminal phải trông coi. Đây cũng là lý do các đội nhóm chạy Claude Code và Codex cùng nhau từ một nơi.
  • Một bước duyệt vững chắc. Kết quả chờ tại cổng human-in-the-loop kèm theo bản tóm tắt thay đổi và bằng chứng, nên không có gì bị merge chỉ vì bạn quên mất nó đang chờ.

Bạn có thể tự tay dựng toàn bộ những thứ này bằng worktree và tính kỷ luật, hoặc dùng Sharkly để quản lý quy trình khi số lượng agent tăng lên. Codex vẫn giữ nguyên như cũ; gánh nặng quản lý được chuyển khỏi vai bạn. Nếu bạn đã chạy nhiều agent Codex, đó chính là bài toán mà Sharkly được thiết kế để giải.

Checklist bạn có thể áp dụng ngay hôm nay

Dù bạn giữ cách làm thủ công hay chuyển sang dùng bảng, đây là mức tối thiểu giúp bạn không mất dấu:

  • [ ] Mỗi agent một worktree cô lập, trên nhánh đặt tên theo tác vụ, tuyệt đối không để hai agent trong cùng một thư mục.
  • [ ] Một quy ước đặt tên mã hóa tác vụ, để agent/auth-refactor hơn hẳn repo-3.
  • [ ] Các phiên sống lâu (tmux hoặc một bảng) mà bạn có thể detach rồi attach lại mà không giết công việc đang chạy.
  • [ ] Một bản ghi trạng thái bền vững nằm ngoài vùng scrollback của terminal: tác vụ, nhánh, trạng thái, tình trạng duyệt.
  • [ ] Một cổng duyệt rõ ràng; không nhánh nào được merge cho đến khi con người chấp nhận.
  • [ ] Một phép kiểm tra số lượng: khi có từ ba agent trở lên, hoặc từ hai repo trở lên, hãy đưa trạng thái ra khỏi đầu bạn.

Hãy chạy phiên bản thủ công cho đến khi khoản thuế thăm dò bắt đầu đau. Khi đó, hãy đưa các coding agent hiện có của bạn chạy qua Sharkly để việc theo dõi là việc của bảng, không phải của bạn.

Câu hỏi thường gặp

Thực tế tôi có thể chạy bao nhiêu agent Codex cùng lúc? Nhiều đến mức máy và giới hạn rate limit cho phép; trần mà bạn chạm tới trước thường là con người, chứ không phải kỹ thuật. Theo dõi từ ba agent trở lên bằng tay là lúc hầu hết mọi người mất mạch. Xem luồng chạy đồng thời và subagent của Codex để biết giới hạn phía thực thi.

Bảng tác vụ có thay thế Codex không? Không. Codex thực thi; bảng quản lý việc giao việc, cô lập, ngữ cảnh và duyệt xung quanh nó. Hai thứ bổ trợ cho nhau.

Khám phá thêm

GPT-6 Cyber có ý nghĩa gì đối với các đội ngũ vận hành AI Agent

GPT-6 Cyber có ý nghĩa gì đối với các đội ngũ vận hành AI Agent

GPT-6 Cyber yêu cầu Daybreak Red cùng với sự phê duyệt mô hình và có mức giá 20 USD cho mỗi một triệu token đầu vào. Dưới đây là cách các đội ngũ phát triển AI agent nên phân luồng quy trình rà soát bảo mật và phân loại xử lý.

6 tháng 11 2026

Bảng giá Gemini Omni 1.2 Flash: Mức giá 0,07 USD/giây tốn bao nhiêu ở quy mô đội ngũ

Bảng giá Gemini Omni 1.2 Flash: Mức giá 0,07 USD/giây tốn bao nhiêu ở quy mô đội ngũ

Giá của Gemini Omni 1.2 Flash khởi điểm từ 0,07 USD/giây cho độ phân giải 720p, nhưng các nhóm sẽ trả phí theo từng lượt xử lý. Hãy xem chi tiết biểu phí cho từng mức độ phân giải cùng kế hoạch ngân sách hàng tháng mà bạn có thể tái sử dụng.

6 tháng 11 2026

Gemini Omni 1.2 Flash có miễn phí không?

Gemini Omni 1.2 Flash có miễn phí không?

Gemini Omni 1.2 Flash không có gói miễn phí trên Gemini API, và khoản tín dụng 300 USD của Google Cloud cũng không áp dụng cho Gemini API. Những nơi vẫn hỗ trợ tạo video với giá 0 USD (Google Vids và Flow), hạn mức của từng công cụ, chi phí cho mỗi clip, và ý nghĩa thực sự khi các agent tự mình...

6 tháng 11 2026