Tuần này có một đoạn config đang được lan truyền: đặt agents.max_concurrent_threads_per_session = 64 trong config.toml của Codex rồi xem một session tách ra thành hàng chục subagent. Bài đăng khởi nguồn cho nó khẳng định giá trị mặc định là 3 và OpenAI đã thử nghiệm với 64. Cấu hình này là thật. Nhưng hai con số kia không có trong tài liệu, và phần thú vị nhất không nằm ở cái giới hạn. Mà là điều gì xảy ra với công việc khi bạn nâng nó lên.
Bài viết này nói về việc cấu hình đó thực sự làm gì, theo tài liệu tham chiếu của Codex, và ba thứ lần lượt đổ vỡ khi một session chạy nhiều agent hơn mức một người có thể đọc hết.
TL;DR
agents.max_concurrent_threads_per_session giới hạn số luồng agent được sinh ra mà Codex giữ mở cùng lúc, không tính luồng chính. Tài liệu tham chiếu không công bố giá trị mặc định; nó chỉ nói rằng Codex tự chọn một giá trị khi khóa này không được đặt. Các subagent trả kết quả tóm tắt về luồng chính, luồng này chờ tất cả rồi trả lời một lần, và tài liệu khuyến nghị dùng chúng cho các công việc thiên về đọc, đồng thời cảnh báo rằng các luồng công việc ghi song song sẽ tạo ra xung đột và chi phí phối hợp. Nâng giới hạn lên 64 đánh trúng đúng hai điểm đó: file dùng chung và một phản hồi gộp duy nhất mà không ai kiểm tra được. Sharkly chạy Codex như một Runtime và đẩy mức song song lên một tầng cao hơn, nơi mỗi lần chạy là một Task có worktree riêng, log riêng và người review riêng.
Cấu hình này thực sự làm gì
Có ba khóa trong mục [agents] của config.toml đáng quan tâm ở đây. Phần diễn giải dưới đây lấy từ tài liệu tham chiếu cấu hình.
| Khóa | Tài liệu tham chiếu nói gì |
|---|---|
agents.max_concurrent_threads_per_session |
“Số lượng tối đa các luồng agent được sinh ra có thể mở đồng thời, không tính luồng chính. Khi không được đặt, Codex sẽ tự chọn giá trị mặc định.” |
agents.max_threads |
“Bí danh cũ (legacy) cho agents.max_concurrent_threads_per_session.” |
agents.enabled |
“Bật hoặc tắt các công cụ đa agent (mặc định: true).” |
Hai khóa liên quan, agents.default_subagent_model và agents.default_subagent_reasoning_effort, quy định các agent được sinh ra sẽ chạy trên nền gì, trừ khi lệnh spawn chỉ định khác.
Vậy nên đoạn snippet hoạt động đúng như đã viết:
[agents]
max_concurrent_threads_per_session = 64
Điều tài liệu tham chiếu không nói là giá trị mặc định là bao nhiêu, hay có giá trị nào từng được thử nghiệm hay không. Hãy coi “mặc định là 3” và “OpenAI đã thử nghiệm 64” là những khẳng định đến từ một bài đăng, chứ không phải từ nhà cung cấp, cho đến khi tài liệu nói khác.
Hướng dẫn về subagent bổ sung thêm hai câu quyết định việc nâng giới hạn có phải là ý hay hay không. Về kết quả: “Khi nhiều agent cùng chạy, Codex chờ cho đến khi tất cả kết quả được yêu cầu đều sẵn sàng, rồi trả về một phản hồi gộp chung.” Về mức độ phù hợp: subagent hợp với “các tác vụ thiên về đọc như khám phá, kiểm thử, phân loại và tóm tắt”, và hướng dẫn khuyên cẩn trọng với “các luồng công việc ghi song song, vì các agent cùng lúc sửa code có thể tạo ra xung đột và làm tăng chi phí phối hợp.”
Đọc hai điều đó cùng nhau và thứ tự đổ vỡ tự hiện ra.
Thứ đầu tiên đổ vỡ: thư mục làm việc dùng chung
Các subagent trong cùng một session dùng chung thư mục làm việc của session đó, trừ khi bạn sắp xếp khác đi. Điều đó không sao với 64 agent chỉ đọc. Nhưng với bốn agent cùng ghi thì đó là một vấn đề hợp nhất (merge).
Kiểu thất bại này không hề kịch tính. Hai subagent cùng sửa một file, lần ghi sau thắng, và bản tóm tắt gộp vẫn báo cả hai tác vụ đã hoàn tất. Bạn phát hiện ra khi review, nếu bạn có bước review, hoặc trên production nếu không có. Cảnh báo của tài liệu về xung đột và chi phí phối hợp đang nói về chính điều này.
Cách khắc phục là cách mà mọi thiết lập đa agent song song đều hội tụ về: một bản sao làm việc cho mỗi đơn vị công việc. Trong Sharkly, mỗi lần chạy Task có một thư mục tách biệt, và công việc gắn với repository dùng một git worktree riêng cho mỗi lần chạy — đây chính là cơ chế được trình bày trong các agent song song trong những worktree tách biệt. Mười Task trên cùng một repository, không chia sẻ trạng thái nào. Runtime đảm nhiệm việc chỉnh sửa vẫn có thể là Codex; lớp cô lập được dựng bao quanh nó.
Thứ hai đổ vỡ: phản hồi gộp chung
Codex chờ mọi subagent rồi trả về một phản hồi duy nhất. Với bốn subagent thì đó là sự tiện lợi. Với 64 subagent thì đó là một tin nhắn duy nhất tóm tắt 64 phần công việc, do chính agent đã điều phối chúng viết ra, với toàn bộ kết quả trung gian bị gấp lại.
Đó là hình dạng sai cho việc review. Người review cần biết mỗi đơn vị công việc đã đụng vào gì, đã chạy gì và dừng ở đâu, và cần có khả năng chấp nhận hay từ chối từng cái một cách độc lập. Một bản tóm tắt của các bản tóm tắt thì không thể chấp nhận từng phần.
Sharkly lưu phản hồi cuối cùng của Agent trên Task, và giữ một log thực thi cho mỗi lần chạy gồm trigger, thời điểm bắt đầu và kết thúc, các lệnh gọi công cụ, sự kiện Runtime và chi tiết lỗi. Các lần thực thi nằm ở tab riêng, tách khỏi dòng thời gian bình luận. 64 đơn vị công việc là 64 Task với 64 log, mỗi cái đều review được, mỗi cái đều trả kết quả về đúng nơi con người sẽ nhìn vào.
Thứ ba đổ vỡ: con người trong vòng lặp
Giới hạn này không nói gì về việc điều gì xảy ra khi một subagent cần đến con người. Bên trong một session, một subagent bị chặn chỉ là một luồng đã im lặng trong một lần chờ gộp. Luồng chính không thể trả lời thay bạn, và bạn không thấy được trong 64 luồng thì luồng nào đã dừng lại.
Sharkly tách biệt trạng thái của Task và trạng thái làm việc của Agent: một Task đã Started có thể hiển thị Working, Waiting for human reply, Waiting for human review hoặc Error. Các tín hiệu đang chờ và thất bại rơi vào mục Primary của Inbox dành cho người phụ trách, và một phản hồi trên Task sẽ khởi động lần chạy tiếp theo với luồng đó làm ngữ cảnh. Cái bị kẹt sẽ báo cho bạn biết, thay vì treo trong một lần chờ mà bạn không thể kiểm tra.
Subagent hay Task? Một cặp tiêu chí để quyết định
Dùng subagent của Codex trong một session khi công việc thiên về đọc và hội tụ về một câu trả lời: khám phá một codebase, phân loại một loạt lỗi, tóm tắt một tập tài liệu, chạy một bộ kiểm thử. Đó là những gì hướng dẫn khuyến nghị, và nâng giới hạn lên cao chẳng tốn kém gì khi không có ai ghi cả.
Dùng các Task riêng biệt, mỗi Task giao cho một Agent trên một Computer, khi các đơn vị công việc có ghi code, khi những người khác nhau sẽ review những phần khác nhau, hoặc khi có thể cần một người trả lời giữa chừng. Sharkly không thay thế Codex; Codex là Runtime thực thi từng Task. Khác biệt nằm ở chỗ tính song song sống ở đâu: bên trong một lần chờ gộp của một session, hay trải khắp một bảng nơi ngữ cảnh, tiến độ, điểm tắc, kết quả và việc review của con người luôn hiển thị từ lúc yêu cầu đến lúc phát hành.
Nâng giới hạn một cách an toàn
Nếu bạn thực sự nâng max_concurrent_threads_per_session, hãy làm theo cách mà chính tài liệu về concurrency của Sharkly mô tả cho Computer: chỉ tăng sau khi thiết lập hiện tại xử lý khối lượng công việc hiện có một cách ổn định, vì mức song song cao hơn sẽ ngốn nhiều CPU, bộ nhớ, dung lượng đĩa, năng lực của nhà cung cấp và băng thông repository hơn. Một Computer trong Sharkly có giới hạn song song tác vụ riêng, và các Agent dùng thư mục tạm mặc định chỉ được một nửa con số đó. Năng lực bị giới hạn bởi Computer, mức song song của Agent và tính sẵn có của thư mục, và một Agent đang online vẫn có thể còn công việc đang xếp hàng khi năng lực đó đã đầy.
Năng lực của nhà cung cấp là thứ mọi người hay quên. 64 luồng cùng đập vào một API key là 64 cách để đụng giới hạn tần suất (rate limit) cùng một lúc, và một mã 429 mang nghĩa “hết quota” thì không thể khắc phục bằng cách thử lại. Log các lần chạy thất bại của Sharkly giữ nguyên phản hồi gốc từ nhà cung cấp bên cạnh một tiêu đề dễ hiểu, nên sự khác biệt này hiển thị rõ trước khi bất kỳ ai thử lại.
Câu hỏi thường gặp
Giá trị mặc định của agents.max_concurrent_threads_per_session là gì? Tài liệu tham chiếu cấu hình không nêu giá trị nào. Nó chỉ nói Codex tự chọn giá trị mặc định khi khóa không được đặt. Những con số lan truyền trên mạng xã hội không đến từ tài liệu tham chiếu.
Nâng giới hạn có làm Codex nhanh hơn không? Với việc fan-out thiên về đọc, nhiều luồng hơn sẽ xong sớm hơn. Với công việc thiên về ghi, tài liệu cảnh báo rằng việc sửa đổi đồng thời tạo ra xung đột và chi phí phối hợp, tốn thời gian nhiều hơn mức mà tính song song tiết kiệm được.
Subagent của Codex có chạy trong các git worktree riêng không? Hướng dẫn về subagent không nói là có. Hãy lên kế hoạch như thể chúng dùng chung thư mục làm việc, trừ khi bạn tự thiết lập cô lập.
Sharkly dùng Codex như thế nào? Như một Runtime. Một Computer đang chạy Codex sẽ báo nó là khả dụng, và các Task giao cho một Agent trên Computer đó sẽ thực thi qua nó, mỗi lần chạy trong thư mục hoặc worktree tách biệt riêng.
Tôi vẫn có thể dùng subagent bên trong một Task của Sharkly không? Có. Mọi thứ Runtime có thể tự làm vẫn hoạt động bên trong lần chạy đó. Sharkly chỉ thêm Task, lớp cô lập, log và bước review bao quanh nó.
Tóm lại
Cấu hình này là thật và đoạn snippet hoạt động được. Điều nó không làm được là khiến 64 thao tác ghi đồng thời trở nên an toàn, khiến một phản hồi gộp trở nên review được, hay cho bạn biết luồng nào đang chờ bạn. Đó là ba thứ đổ vỡ, theo đúng thứ tự đó. Hãy giữ subagent cho việc fan-out thiên về đọc, và đưa công việc song song thiên về ghi lên một bảng nơi mỗi lần chạy có worktree riêng và người review riêng. Kết nối một Computer có Codex trên đó, tạo một Agent, và giao cho nó một việc nhàm chán nào đó. Tài liệu trình bày từng khái niệm kỹ hơn: docs.sharkly.ai.
