Agent Teams - Điều phối nhóm phiên Claude Code

 (code.claude.com)
29 điểm bởi GN⁺ 2026-02-06 | 2 bình luận | Chia sẻ qua WhatsApp
  • Một tính năng thử nghiệm cho phép tổ chức nhiều phiên Claude Code thành một nhóm để phân chia và điều phối công việc song song, trong đó phiên lead tạo thành viên, giao việc và tổng hợp kết quả
  • Khác với sub-agent hiện có, các thành viên trong nhóm có thể nhắn tin trực tiếp cho nhau, và người dùng cũng có thể giao tiếp trực tiếp với từng thành viên mà không cần đi qua lead
  • Hiệu quả cho review mã, khám phá song song các giả thuyết debug, và các công việc xuyên nhiều lớp như frontend, backend, test; với công việc tuần tự hoặc chỉnh sửa cùng một file thì một phiên đơn phù hợp hơn
  • Mỗi thành viên có cửa sổ ngữ cảnh độc lập nên mức sử dụng token tăng đáng kể, và chi phí có thể tăng tỷ lệ thuận với số lượng thành viên
  • Hỗ trợ chế độ chia màn hình qua tmux hoặc iTerm2, đồng thời hỗ trợ nâng cao năng suất và chất lượng của các tác vụ phát triển phức tạp thông qua khám phá song song và tự động hóa cộng tác

Tổng quan về Agent Teams

  • Điều phối nhiều phiên Claude Code theo đơn vị nhóm để thực hiện công việc song song
    • Team lead sẽ phân chia công việc và tổng hợp kết quả
    • Mỗi thành viên chạy riêng trong một cửa sổ ngữ cảnh độc lập
  • Khác với Subagent, các thành viên có thể nhắn tin trực tiếp cho nhau
  • Đây là tính năng thử nghiệm và bị tắt theo mặc định; có thể bật bằng cách thiết lập biến môi trường CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS

Khi nào nên dùng Agent Teams

  • Nghiên cứu và review: nhiều thành viên cùng lúc điều tra các khía cạnh khác nhau của vấn đề, sau đó chia sẻ kết quả và đối chiếu chéo
  • Phát triển module hoặc tính năng mới: mỗi thành viên phụ trách file/module riêng để làm việc song song mà không xung đột
  • Debug dựa trên các giả thuyết cạnh tranh: kiểm thử đồng thời các giả thuyết khác nhau để tìm nguyên nhân nhanh hơn
  • Điều phối xuyên nhiều lớp: bố trí thành viên theo từng lớp như frontend, backend, test để thay đổi đồng thời
  • Với công việc tuần tự, chỉnh sửa cùng một file, hoặc tác vụ có nhiều phụ thuộc, một phiên đơn hoặc sub-agent sẽ hiệu quả hơn

Subagent vs. Agent Team

  • Sub-agent: có cửa sổ ngữ cảnh riêng nhưng chỉ trả kết quả về cho bên gọi; agent chính quản lý toàn bộ công việc; chi phí token tương đối thấp
  • Agent team: có cửa sổ ngữ cảnh hoàn toàn độc lập, cho phép nhắn tin trực tiếp giữa các thành viên, tự điều phối bằng danh sách tác vụ dùng chung; vì mỗi thành viên là một instance Claude riêng nên chi phí token cao hơn
  • Với công việc tập trung chỉ cần kết quả, sub-agent phù hợp hơn; với công việc phức tạp cần thảo luận và cộng tác giữa các thành viên, agent team là lựa chọn thích hợp

Bắt đầu đội agent đầu tiên

  • Mặc định tính năng bị tắt; có thể bật bằng cách đặt biến môi trường CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS thành 1 hoặc thêm biến môi trường tương ứng vào settings.json
  • Sau khi bật, chỉ cần mô tả cấu trúc nhóm và công việc bằng ngôn ngữ tự nhiên, Claude sẽ tạo nhóm và spawn thành viên rồi điều phối công việc

    • I'm designing a CLI tool that helps developers track TODO comments across their codebase. Create an agent team to explore this from different angles: one teammate on UX, one on technical architecture, one playing devil's advocate.

    • Tôi đang thiết kế một công cụ CLI giúp developer theo dõi các comment TODO trên toàn bộ codebase. Hãy tạo một agent team để khám phá vấn đề này từ nhiều góc độ khác nhau: một thành viên phụ trách UX, một phụ trách kiến trúc kỹ thuật, và một đóng vai người phản biện.
    • Khi đó Claude sẽ cố gắng tạo danh sách tác vụ dùng chung, tạo từng thành viên, để họ khám phá từng vấn đề, tổng hợp kết quả, và dọn dẹp nhóm khi công việc hoàn tất
  • Ở terminal của lead sẽ hiển thị toàn bộ danh sách thành viên và trạng thái công việc; có thể chọn thành viên bằng Shift+Up/Down để gửi tin nhắn trực tiếp

Điều khiển agent team

  • Chọn chế độ hiển thị

    • Chế độ in-process: tất cả thành viên chạy trong terminal chính, có thể chọn thành viên và gửi tin nhắn bằng Shift+Up/Down, không cần cấu hình bổ sung
    • Chế độ split panes: mỗi thành viên hiển thị trong một pane riêng, có thể xem đầu ra cùng lúc, yêu cầu tmux hoặc iTerm2
    • Giá trị mặc định "auto" sẽ dùng split pane nếu đang chạy trong một phiên tmux, nếu không thì dùng in-process
    • Khi đặt "tmux", chế độ split-pane được bật và sẽ tự động phát hiện tmux cùng iTerm2
    • Có thể ghi đè bằng teammateMode trong settings.json, hoặc dùng cờ claude --teammate-mode in-process để ép về một phiên đơn

  • Chỉ định thành viên và model

    • Claude sẽ tự quyết định số lượng thành viên theo công việc, nhưng bạn cũng có thể chỉ định chính xác số lượng và model (ví dụ: Sonnet) bằng lệnh như "Create a team with 4 teammates"

  • Yêu cầu phê duyệt kế hoạch

    • Với tác vụ phức tạp hoặc có rủi ro, có thể áp dụng chế độ plan chỉ đọc cho thành viên để chặn việc triển khai cho tới khi lead phê duyệt
    • Khi thành viên hoàn thành kế hoạch, họ sẽ gửi yêu cầu phê duyệt cho lead; nếu lead chấp thuận thì bắt đầu triển khai, nếu từ chối thì chỉnh sửa theo phản hồi và nộp lại
    • Tiêu chí đánh giá của lead cũng có thể được tác động qua prompt, ví dụ: "chỉ phê duyệt kế hoạch có bao gồm test coverage"

  • Chế độ delegate

    • Thay vì tự triển khai, lead sẽ bị giới hạn chỉ dùng các công cụ chuyên điều phối như spawn thành viên, nhắn tin, kết thúc, quản lý tác vụ
    • Sau khi khởi động nhóm, nhấn Shift+Tab để chuyển sang chế độ delegate

  • Trò chuyện trực tiếp với thành viên

    • Mỗi thành viên là một phiên Claude Code hoàn toàn độc lập, nên có thể trực tiếp gửi thêm chỉ thị, câu hỏi tiếp theo hoặc thay đổi cách tiếp cận
    • Trong chế độ in-process, dùng Shift+Up/Down để chọn rồi gửi tin nhắn, Enter để xem phiên, Escape để dừng lượt hiện tại, và Ctrl+T để bật/tắt danh sách tác vụ
    • Trong chế độ split-pane, chỉ cần nhấp vào pane tương ứng để tương tác trực tiếp

  • Giao và claim tác vụ

    • Cả nhóm điều phối công việc qua danh sách tác vụ dùng chung, với ba trạng thái: pending, in progress, completed
    • Có thể thiết lập phụ thuộc giữa các tác vụ; tác vụ còn phụ thuộc chưa được giải quyết thì không thể claim
    • Lead có thể gán tác vụ một cách rõ ràng, hoặc thành viên sau khi hoàn thành sẽ tự động claim tác vụ tiếp theo chưa được gán và không bị chặn
    • Dùng file lock để ngăn nhiều thành viên cùng lúc claim một tác vụ

  • Kết thúc thành viên và dọn dẹp nhóm

    • Khi yêu cầu lead kết thúc một thành viên cụ thể, thành viên đó có thể chấp thuận hoặc từ chối kèm lý do
    • Khi dọn dẹp nhóm, lead sẽ xóa các tài nguyên dùng chung; nếu vẫn còn thành viên đang hoạt động thì việc dọn dẹp sẽ thất bại, nên cần kết thúc họ trước

Cách agent team vận hành bên trong

  • Luồng khởi động nhóm

    • Người dùng yêu cầu nhóm: mô tả tác vụ phù hợp để làm song song và yêu cầu rõ ràng việc tạo agent team
    • Claude đề xuất nhóm: nếu Claude nhận thấy đặc tính công việc phù hợp cho xử lý song song, nó sẽ đề xuất tạo nhóm và chỉ thực hiện sau khi người dùng xác nhận
    • Trong cả hai trường hợp, nhóm sẽ không được tạo nếu không có sự chấp thuận của người dùng

  • Thành phần kiến trúc

    • Team lead: phiên Claude Code chính, chịu trách nhiệm tạo nhóm, spawn thành viên và điều phối công việc
    • Teammates: các instance Claude Code riêng biệt, mỗi thành viên thực hiện tác vụ được giao
    • Task list: danh sách hạng mục công việc dùng chung để thành viên claim và hoàn thành
    • Mailbox: hệ thống nhắn tin để giao tiếp giữa các agent
    • Phụ thuộc giữa các tác vụ được quản lý tự động; khi một thành viên hoàn thành tác vụ, các tác vụ bị chặn sẽ được mở khóa mà không cần can thiệp thủ công
    • Cấu hình nhóm được lưu cục bộ tại ~/.claude/teams/{team-name}/config.json, danh sách tác vụ tại ~/.claude/tasks/{team-name}/
    • Trong config có mảng members để ghi lại tên, ID agent và loại agent của từng thành viên

  • Quyền hạn

    • Thành viên sẽ khởi động với thiết lập quyền hạn được kế thừa từ lead; nếu lead chạy với --dangerously-skip-permissions thì tất cả thành viên cũng sẽ áp dụng như vậy
    • Có thể thay đổi chế độ của từng thành viên sau khi spawn, nhưng không thể đặt quyền riêng cho từng thành viên ngay lúc spawn

  • Ngữ cảnh và giao tiếp

    • Mỗi thành viên có cửa sổ ngữ cảnh độc lập, và khi spawn sẽ tải cùng ngữ cảnh dự án như một phiên thông thường, bao gồm CLAUDE.md, MCP server, skill, v.v.
    • Lịch sử hội thoại của lead không được truyền cho thành viên, chỉ có prompt dùng để spawn được chuyển đi
    • Chuyển tiếp tin nhắn tự động: tin nhắn do thành viên gửi sẽ được chuyển thẳng cho người nhận, lead không cần polling
    • Thông báo idle: khi thành viên hoàn thành công việc và dừng lại, lead sẽ tự động được thông báo
    • Danh sách tác vụ dùng chung: mọi agent đều có thể kiểm tra trạng thái tác vụ và claim công việc khả dụng
    • Hệ thống nhắn tin có hai kiểu: message (gửi cho một thành viên cụ thể) và broadcast (gửi cho toàn bộ nhóm; vì chi phí tăng theo quy mô nhóm nên cần dùng tiết chế)

  • Mức sử dụng token

    • So với một phiên đơn, agent team làm tăng đáng kể mức sử dụng token, và mức tăng tỷ lệ thuận với số thành viên đang hoạt động
    • Với nghiên cứu, review và phát triển tính năng mới, chi phí token bổ sung thường là hợp lý; nhưng với tác vụ thường nhật thì một phiên đơn tiết kiệm chi phí hơn

Trường hợp sử dụng

  • Review code song song

    • Một reviewer đơn lẻ thường chỉ tập trung vào một loại vấn đề tại một thời điểm, nên có thể chia tiêu chí review thành các miền độc lập như bảo mật, hiệu năng, độ bao phủ test
    • Mỗi reviewer áp dụng một bộ lọc khác nhau trên cùng một PR, sau đó lead tổng hợp toàn bộ kết quả

  • Điều tra dựa trên các giả thuyết cạnh tranh

    • Một agent đơn lẻ thường dừng khám phá khi đã tìm được một lời giải thích, vì vậy nên cấu trúc nhóm thành các thành viên mang tính đối kháng một cách rõ ràng
    • Mỗi thành viên điều tra giả thuyết của mình đồng thời cố gắng bác bỏ lý thuyết của các thành viên khác theo kiểu tranh luận khoa học
    • Điều này giúp tránh thiên kiến neo bám thường gặp trong điều tra tuần tự, và tăng khả năng giả thuyết sống sót cuối cùng chính là nguyên nhân gốc rễ thực sự

Thực tiễn tốt nhất

  • Cung cấp đủ ngữ cảnh cho thành viên: ngữ cảnh dự án được tải tự động nhưng lịch sử hội thoại của lead không được truyền đi, nên prompt spawn cần bao gồm chi tiết liên quan tới công việc
  • Điều chỉnh kích thước tác vụ hợp lý: nếu quá nhỏ thì chi phí điều phối sẽ lớn hơn lợi ích; nếu quá lớn thì dễ làm lâu mà không check-in và tăng rủi ro lãng phí; đơn vị công việc tự khép kín tạo ra đầu ra rõ ràng như hàm, file test, review là phù hợp
  • Nếu lead bắt đầu tự triển khai thay cho thành viên, hãy chỉ thị "Wait for your teammates to complete their tasks before proceeding"
  • Khi mới dùng lần đầu, nên bắt đầu từ các tác vụ nghiên cứu và review có ranh giới rõ ràng, không cần viết code, như review PR, khảo sát thư viện, điều tra bug
  • Tránh xung đột file: nếu hai thành viên chỉnh sửa cùng một file có thể xảy ra ghi đè, nên chia công việc để mỗi người phụ trách một tập file khác nhau
  • Theo dõi tiến độ của thành viên định kỳ, đổi hướng những cách tiếp cận không hiệu quả, và tổng hợp kết quả ngay khi có

Khắc phục sự cố

  • Khi thành viên không xuất hiện: trong chế độ in-process, dùng Shift+Down để chuyển qua các thành viên đang hoạt động; kiểm tra xem công việc có đủ phức tạp để cần một nhóm hay không; nếu yêu cầu split pane thì kiểm tra tmux đã có trong PATH chưa; với iTerm2, kiểm tra it2 CLI đã được cài và Python API đã bật chưa
  • Prompt xin quyền quá nhiều: yêu cầu quyền của thành viên sẽ được đẩy lên lead, nên trước khi spawn thành viên hãy phê duyệt trước các tác vụ phổ biến trong thiết lập quyền hạn
  • Thành viên dừng sau lỗi: kiểm tra đầu ra của thành viên đó rồi trực tiếp đưa thêm chỉ thị, hoặc spawn một thành viên thay thế để tiếp tục công việc
  • Lead thoát trước khi hoàn thành công việc: hướng dẫn lead tiếp tục chạy, hoặc thiết lập để đợi thành viên hoàn thành trước khi delegate
  • Phiên tmux mồ côi: nếu sau khi kết thúc nhóm mà vẫn còn phiên tmux, hãy kiểm tra bằng tmux ls rồi xóa bằng tmux kill-session -t <session-name>

Giới hạn

  • Không thể khôi phục phiên thành viên in-process: /resume và /rewind không khôi phục thành viên in-process; sau khi khôi phục, lead có thể gửi tin nhắn tới thành viên không còn tồn tại, nên cần spawn thành viên mới
  • Độ trễ trạng thái tác vụ: thành viên có thể không đánh dấu hoàn thành tác vụ khiến tác vụ phụ thuộc vẫn bị chặn; cần cập nhật trạng thái thủ công hoặc yêu cầu lead nhắc thành viên
  • Độ trễ khi kết thúc: thành viên chỉ kết thúc sau khi hoàn tất request hoặc lời gọi công cụ hiện tại
  • Mỗi phiên chỉ có một nhóm: muốn bắt đầu nhóm mới thì phải dọn dẹp nhóm hiện tại trước
  • Không hỗ trợ nhóm lồng nhau: thành viên không thể spawn nhóm hoặc thành viên riêng; chỉ lead mới có thể quản lý nhóm
  • Lead cố định: phiên tạo nhóm sẽ là lead vĩnh viễn của nhóm đó; không thể nâng một thành viên thành lead hoặc chuyển quyền lãnh đạo
  • Thiết lập quyền đồng loạt khi spawn: mọi thành viên đều bắt đầu với chế độ quyền của lead; không thể đặt quyền khác nhau cho từng thành viên tại thời điểm spawn
  • Split pane yêu cầu tmux hoặc iTerm2: terminal tích hợp của VS Code, Windows Terminal và Ghostty không hỗ trợ chế độ split-pane

Bài viết liên quan

2 bình luận

 
kuthia 2026-02-06

Có vẻ như trong điều phối đa tác tử, điều quan trọng sẽ là làm thế nào để bảo toàn các kết quả mang tính ngữ nghĩa trong quá trình nén ngữ cảnh. Nghe giống khoa học nhận thức nhỉ.
 
GN⁺ 2026-02-06
Ý kiến trên Hacker News

  • Thật thú vị khi phần lớn đổi mới trong 1 năm qua chủ yếu đi theo hướng lấy kỹ thuật làm trung tâm
    MCP, agent, skill và nhiều khái niệm mới liên tục xuất hiện, nhưng các vấn đề cốt lõi như ảo giác, thiếu chính xác, sụp đổ ngữ cảnh vẫn chưa được giải quyết
    Có vẻ những vấn đề này không thể giải bằng kỹ thuật đơn thuần mà chỉ có thể xử lý bằng nghiên cứu nền tảng
    Những cải tiến và công bố hiện tại tạo cảm giác như là một phần của chu kỳ hype nhằm duy trì kỳ vọng của nhà đầu tư
    Thành thật mà nói, tôi đã mệt với câu chuyện AI này và chỉ muốn nhanh chóng bước sang giai đoạn mà công nghệ này thực sự hữu ích ở đâu được làm rõ

  • Tính năng này đúng là ngầu, nhưng tôi vẫn tự hỏi có bao nhiêu người thực sự có thể chạy agent cả ngày
    Dùng Cursor thấy mức tiêu thụ token quá lớn nên tôi đã nâng lên Ultra, nhưng cảm giác mức sử dụng không tỷ lệ với giá trị nhận được
    May là phe LLM mã nguồn mở đang bắt kịp rất nhanh nên vẫn còn hy vọng

    • Tôi còn chẳng dùng hết hạn mức 200 lượt/tháng của Claude Max. Dù ngày nào cũng code và làm việc khá nặng thì vẫn vậy
    • Thực ra mấy thứ này vẫn đang ở giai đoạn thử nghiệm, nên có thể thất bại như Gas Town
    • Nhiều công ty có thể thuê kỹ sư junior lương 150.000 USD/năm. Nếu phí thuê bao AI còn đắt hơn thì đó là vấn đề
      Với lại, ở đây đang nói về Claude Code chứ không phải Cursor. Tôi thà khuyên dùng Claude Max hơn
    • Có lẽ chỉ những startup 2 người được VC rót vốn mới đủ sức chạy thứ này cả ngày
    • Claude Code Max mang lại giá trị gấp 30 lần so với đơn giá token, nên nếu không dùng hết thì là do bản thân thôi. Có khi còn rẻ hơn tiền điện

  • Trước đây Steve Yegge từng đề xuất ý tưởng agent orchestrator cho các công ty như Anthropic
    (Welcome to Gas Town)
    Giờ nhìn Anthropic ra mắt Agent Teams thì có vẻ hoặc là họ đã chuẩn bị từ khi đó, hoặc đã đi đến cùng một kết luận
    Dù sao thì cũng thú vị khi tầm nhìn của Steve coi như đã được kiểm chứng. Có lẽ sắp đến mùa “thuần hóa polecat” rồi

    • Tôi cũng không biết GasTown hay Beeds, nhưng đã tự làm thứ gì đó tương tự. Đây là bước tiếp theo quá tự nhiên
      claude-code-orchestrator
    • Tôi cũng từng làm thử một cấu trúc team agent đơn giản trước cả làn sóng GasTown. Tôi chạy nhiều instance Claude trong các session tmux và đồng bộ bằng .claude.lock
      Nó hoạt động khá ổn, nhưng vẫn chưa hiệu quả lắm. Tốc độ viết spec và chất lượng QA mới là nút thắt cổ chai
    • Thực ra kiểu cấu trúc này là khái niệm đã tồn tại trong framework actor từ lâu. So với các hệ thống như Akka thì chẳng có gì mới
      Việc các nhà cung cấp LLM đến giờ mới học những thứ này khiến tôi cảm thấy họ đang trưởng thành theo thời gian thực
      Gọi đây là Kubernetes for agents cũng không hề cường điệu. Tôi cũng đang nối theo kiểu đó ở local
    • Tôi không nghĩ các kỹ sư Anthropic có thể không biết những ý tưởng này. Những câu chuyện như vậy đã có từ thời kỳ đầu của ChatGPT
    • Thực ra các hệ thống multi-agent như vậy đã đầy trên arxiv và GitHub từ năm 2023
      Khi đó chỉ là model kém thông minh hơn và context window nhỏ hơn, còn bây giờ thì đơn giản là đã đủ khả thi

  • Tôi đã dùng workflow cho nhiều instance Claude Code cộng tác như các CLI agent dựa trên tmux
    Tính năng orchestration lần này hữu ích hơn nhiều vì nó chia sẻ task list chung và để agent chính điều phối
    Có thể tự động hóa cộng tác giữa các agent bằng công cụ tmux-cli

  • Tôi không học cái này cho tới giờ vì rõ ràng sớm muộn nó cũng sẽ được tích hợp mặc định, nhưng có vẻ giờ đã đến lúc nên thử

  • Tôi lo là gói thuê bao 20 USD/tháng của mình còn không trụ nổi 10 phút

    • Nếu cá nhân tự trả tiền thì dùng Kimi hay GLM có vẻ hợp lý hơn
    • Tôi cũng nghĩ vậy. Tôi vẫn nghi ngờ liệu cấu trúc này có thực sự tạo ra giá trị hay không
    • Với một số tác vụ nhất định thì Haiku cho kết quả khá tốt

  • Cái này trông khá giống Gas Town

    • Nếu một dự án đi quá xa theo hướng kỳ quặc hoặc đùa cợt, cuối cùng rất có thể một bản clone bớt lố hơn sẽ xuất hiện và thắng thế
    • Nhưng mà polecat đã đi đâu mất rồi, tôi tò mò không biết khiếu hài hước của thị trường ra sao
    • Tôi không biết Gas Town là gì, nhưng tôi đã dùng cấu trúc gần giống Claude Code Agent Teams rồi
      Nếu tạo sub-agent từ cuộc trò chuyện chính để chia việc ra thì có thể làm lâu hơn mà không mất ngữ cảnh
    • Thiết kế này có vẻ đơn giản hơn. Một agent leader và nhiều worker, gọn gàng hơn hệ vai trò phức tạp của Gas Town
    • Nhưng việc không có polecat thì vẫn hơi đáng tiếc

  • Tôi không thể giao Claude Code xử lý độc lập các công việc lớn
    Muốn giữ chất lượng code thì tôi phải trực tiếp can thiệp vào quá trình thiết kế
    Team agent có khi còn chỉ làm tăng gánh nặng review và refactor

    • Nếu mã hóa cấu trúc codebase và các quy tắc dùng pattern thành skill, thì có thể để sub-agent giám sát điều đó
      Việc chia ra agent lập kế hoạch, thiết kế, QA, review để phối hợp với nhau chính là bản chất của tính năng này
    • Cũng có cách tạo mô hình đối kháng trong Claude để nâng chất lượng. Một agent sửa, agent khác kiểm chứng
    • Con người cũng xử lý việc lớn bằng cách chia nhỏ, nên nếu để Claude tự lập kế hoạch và tiêu chí kiểm thử thì sẽ hiệu quả hơn
    • Trên thực tế, khoảng 1 trong 3 hoặc 4 lần sẽ cần tinh chỉnh hoặc dừng lại. Chỉ người có kinh nghiệm mới nhận ra điều đó
    • Cũng đang có nghiên cứu về cách LLM chia nhỏ công việc và ghép kết quả lại
      Bài báo liên quan

  • Tôi đang tìm một kiểu điều phối đa LLM dùng Opus làm chính, còn sub-agent chạy Gemini hoặc Codex

    • Có các công cụ hỗ trợ kiểu này như Coder-Codex-Gemini, ccg-workflow, claude_code_bridge
      Tất cả đều là dự án do nhà phát triển Trung Quốc làm, nhưng sau khi dùng thử tôi thấy khá xuất sắc
    • Dùng AgentWorkforce/relay thì có thể chỉ định LLM mình muốn làm lead/orchestrator
      Tôi đã tổng hợp trải nghiệm liên quan trong bài đăng trên Twitter
    • Tôi code bằng Opus và review bằng Codex. Với mỗi task tôi gọi review skill để chạy Codex
      Tôi cũng dùng mã review skill và trình phân tích PR của Greptile
    • Sắp tới nếu Cursor hỗ trợ kiểu cộng tác đa model này thì sẽ thực sự rất hữu ích
    • Như ví dụ Pied-Piper,
      cũng có thể dùng GPT-5.2 Codex Max để lập kế hoạch, Opus 4.5 để triển khai, và Gemini để review

  • Tôi từng tự làm một phương án thay thế cho Beads, và cuối cùng hoàn thiện được một hệ thống agent đồng bộ với dự án GitHub có cấu trúc tương tự
    Tôi dự định sớm open source nó, và nghĩ rằng về lâu dài việc tích hợp với hệ thống ticket sẽ hữu ích hơn
    Việc có nhiều lựa chọn thay thế agnostic không phụ thuộc vào agent nào là điều đáng mong đợi hơn