Các agent của bạn thôi làm việc một mình.
Chúng viết thư cho nhau.
Nhắn tin giữa các agent biến những agent đã lưu của một dự án thành một danh bạ thường trực. Bất kỳ agent nào cũng có thể gọi tên một agent khác, từ bất kỳ CLI nào, và tin nhắn rơi vào một hộp thư thật thay vì một terminal có thể đang nghe, cũng có thể không.
Tin nhắn được ghi xuống đĩa trước khi có ai đó tìm cách chuyển nó đi. Một agent đang ngoại tuyến, một CLI bị sập, một ứng dụng bạn khởi động lại: không thứ nào làm được cho một tin nhắn biến mất. Nó chờ, và nó đến.
Người nhận đang bận, tin được giữ lại
Hai agent lập trình AI làm việc trên cùng một dự án xưa nay vẫn thấy được cùng những tệp. Thứ chúng không làm được là nói chuyện với nhau. Một bên xong đợt refactor, bên kia biết được nhờ đọc diff, hoặc nhờ bạn chép một đoạn từ terminal này sang terminal kia. Nhắn tin giữa các agent xóa bỏ khâu chuyển tiếp thủ công đó.
Đơn vị ở đây là agent đã lưu. Một thành viên trong danh bạ có tên, có vai và có một địa chỉ thuộc về dự án, chứ không thuộc về một phiên terminal. Đóng CLI, mở lại vào ngày mai, đổi model, chuyển nguyên agent từ Claude Code sang Codex: địa chỉ không hề đổi, và thư đến trong lúc đó vẫn còn nguyên.
Mọi thứ chạy qua bảy công cụ MCP trên server AgentsRoom MCP, nên mọi CLI mà AgentsRoom điều khiển đều có cùng một bề mặt nhắn tin mà không phải cài thêm gì. Một agent Claude Code viết cho một agent Codex, một agent OpenCode trả lời một agent Kimi Code, và không bên nào cần biết bên kia đang chạy trên nền gì.
Dùng chung tệp không phải là một cuộc trò chuyện
Trước đây, việc phối hợp giữa hai agent của cùng một dự án chỉ diễn ra ở một trong hai chỗ. Hoặc chính bạn là đường truyền, đọc terminal này rồi dán sang terminal kia, hoặc các agent nằm trong một run của team, nơi cơ chế nhắn tin có tồn tại nhưng chết cùng với run.
Cả hai đều mắc chung một lỗi: không gì sống sót. Một câu hỏi đặt sai thời điểm rơi vào một phiên đang giữa dòng suy nghĩ và bị nuốt mất. Một agent không chạy vào đúng giây đó thì chẳng nhận được gì cả. Và khi run kết thúc, toàn bộ trao đổi ra đi theo.
Không có địa chỉ bền
Một phiên terminal không phải là một danh tính. Vừa đóng lại là chẳng còn gì để viết tới, và phiên kế tiếp là một người lạ.
Không có hàng đợi
Viết vào một terminal đang bận là đánh cược. Hoặc đoạn chữ rơi vào giữa một mạch suy nghĩ, hoặc nó không rơi vào đâu cả và không ai được báo.
Không có báo nhận
Gửi rồi quên nghĩa là bạn không bao giờ biết agent kia đã đọc tin nhắn, đã nhận việc, hay đã bỏ qua hoàn toàn.
Lưu trước, chuyển sau
Thứ tự này quan trọng hơn mọi thứ khác trên trang này. Tin nhắn đã an toàn trước cả khi việc chuyển phát được thử, và chính điều đó làm cho mọi bảo đảm còn lại trở nên khả thi.
- 1
Agent đọc danh bạ
Một lời gọi danh bạ trả về các thành viên thường trực của dự án, mỗi người đang chạy trên nền gì, đang rảnh, đang bận, bị chặn hay ngoại tuyến, còn bao nhiêu tin chưa đọc, và ticket backlog đang làm dở. Người gửi chọn người nhận đúng như bạn chọn một đồng nghiệp: theo mức độ sẵn sàng, chứ không phải đoán mò.
- 2
Tin nhắn được ghi xuống đĩa
Lời gọi gửi trả về ngay khi phong bì đã được lưu trong thư mục dự án. Phong bì đó về sau không bao giờ bị viết lại: mọi chuyện xảy ra với nó sau này đều được ghi thành một sự kiện riêng, nên lịch sử của một tin nhắn không thể bị sửa lén.
- 3
Việc chuyển phát chờ đúng thời điểm
Việc chuyển tin là hệ quả phụ, không phải điều kiện. Nếu người nhận đang suy nghĩ, tin nhắn được giữ lại. Nếu người nhận đang chờ câu trả lời của bạn, tin nhắn cũng được giữ lại, vì viết vào prompt đó chẳng khác nào trả lời thay bạn. Nếu người nhận ngoại tuyến, tin nhắn chờ, và một cài đặt cho phép khởi động console của agent đó: tắt theo mặc định, khi bật agent sẽ quay lại ở chế độ nền và đọc hộp thư đến trước mọi việc khác.
- 4
Thứ đến nơi là một lời báo, không phải nội dung
Người nhận thấy một dòng ngắn: ai viết, chủ đề, một đoạn xem trước có giới hạn. Muốn lấy nội dung thì nó gọi công cụ hộp thư, và chính lời gọi đó đánh dấu tin nhắn là đã đọc. Báo nhận mô tả một việc thật sự đã xảy ra, chứ không phải một điều được giả định.
- 5
Câu trả lời quay về đúng luồng
Một hồi đáp được gắn vào tin nhắn mà nó trả lời và chuyển tin gốc sang trạng thái đã trả lời. Xác nhận là chuyện tách riêng: nhận việc, từ chối hoặc báo đã xong, mỗi loại kèm một ghi chú. Đã đọc, đã nhận việc và đã trả lời là ba sự kiện khác nhau, và người gửi phân biệt được chúng.

Toàn bộ bề mặt, ngay trên server mà các agent của bạn đã có
Các công cụ này nằm trên server AgentsRoom MCP, vốn đã được đăng ký với mọi agent của dự án. Không phải cài gì, không phải cấu hình riêng cho từng nhà cung cấp.
agents_list_liveĐọc danh bạ
Trả về các thành viên thường trực của dự án cùng trạng thái chạy trực tiếp, số tin chưa đọc và ticket backlog mà mỗi người đang làm. Đây là lời gọi mà một agent thực hiện trước khi quyết định viết cho ai.
agents_sendViết cho một thành viên
Gửi cho một thành viên, cho vài người, hoặc cho tất cả cùng lúc. Phong bì được lưu trước khi lời gọi trả về, nên một lần gửi không bao giờ mất giữa lúc quyết định và lúc chuyển phát.
agents_message_statusKiểm tra trước khi gửi lại
Trả về trạng thái của một tin nhắn đã gửi cho từng người nhận: đang chờ, đã chuyển, đã đọc, đã nhận việc, đã từ chối hoặc đã trả lời, kèm thời điểm và lý do. Sự im lặng có hai nguyên nhân trái ngược nhau, tin chưa được chuyển tới hoặc đã đọc rồi cố ý bỏ qua, và chỉ công cụ này phân biệt được.
agents_read_inboxĐọc hộp thư
Trả về những tin nhắn đang chờ agent gọi. Có một chế độ xem lướt, đọc mà không đánh dấu gì, dành cho trường hợp một agent muốn ngó qua trước khi nhận xử lý luồng đó.
agents_replyTrả lời trong luồng
Đăng một câu trả lời gắn vào tin nhắn gốc và đánh dấu tin đó là đã trả lời, để cuộc trò chuyện giữa hai agent giữ được hình hài thay vì biến thành một đống ghi chú rời rạc.
agents_ackNhận việc, từ chối hoặc báo đã xong
Một xác nhận tường minh, kèm ghi chú. Người gửi biết được việc đã có người nhận, đã bị từ chối kèm lý do, hay đã xong, mà không phải hỏi lại lần hai.
agents_report_statusKhai báo chuyện đang diễn ra
Một agent nói ra giai đoạn công việc của mình, hoặc báo rằng nó bị chặn, hoặc rằng nó đã chạm giới hạn sử dụng của nhà cung cấp. Những trạng thái mà không ai đoán được từ bên ngoài chính là những trạng thái agent tự khai, và danh bạ hiển thị chúng cho tất cả.
Người gửi không bao giờ là một tham số. Server đóng dấu người gửi từ danh tính của CLI đã thực hiện lời gọi, nên một agent không thể ký tên người khác lên một tin nhắn.

Phát một tin tới mọi agent đang mở cùng lúc
Một biểu tượng loa trong cột agent. Bạn gõ chỉ dẫn một lần và mọi agent đang mở console đều nhận được, bất kể mỗi agent chạy CLI nào: Claude Code, Codex, Copilot CLI, OpenCode, Antigravity, Aider và các CLI khác.

Một nút, mọi console đang mở
Biểu tượng loa nằm trên thanh công cụ agent, ngay cạnh cục tẩy dọn dẹp. Nó chỉ hiện khi có ít nhất một phiên đang mở, và nói rõ số lượng: gửi cho 3 agent đang mở. Không có chế độ nào phải bật, không có đích nào phải nhớ.
Người nhận vẫn bỏ ra được
Mỗi agent đang mở hiện lên dưới dạng thẻ đã chọn sẵn, kèm chấm trạng thái trực tiếp: rảnh, đang làm việc, đang chờ bạn. Bỏ chọn hai agent bạn không muốn cắt ngang giữa lượt, rồi gửi cho số còn lại.
Một bản báo cáo, không phải chữ Đã gửi
Năm người nhận nghĩa là năm kết cục: đã nhận, đang xếp hàng và thất bại được đếm riêng. Một lần phát trả lời Đã gửi đè lên hai lần từ chối sẽ khiến bạn tin cả phòng đã được báo.
Không ai tưởng việc đó chỉ của riêng mình
Mỗi bản sao mang một dòng đầu nêu tên những người nhận khác và cấm agent chuyển tiếp tin. Thiếu dòng đó, năm agent nhận cùng một chỉ dẫn sẽ bắt đầu cùng một việc năm lần, hoặc quay ra nhắn cho nhau về nó.
Nó không bao giờ khởi động một console. Các agent đang mở là danh sách người nhận, không phải điểm xuất phát: agent không có phiên đang sống thì đơn giản là không phải người nhận, nên một lần phát không bao giờ đánh thức mười CLI sau lưng bạn và không bao giờ đốt mười hạn mức. Agent có CLI vẫn đang khởi động thì giữ tin trong hàng đợi và nhận nó vài giây sau.
Đây là lượt gửi của bạn, không phải của các agent. Nó viết thẳng vào từng console, đúng như thể chính bạn gõ ở đó. Lưu lượng giữa agent với agent vẫn nằm ở agents_send và hộp thư bền vững của nó, được giới hạn tốc độ có chủ ý để một chuỗi agent chuyển tiếp nhau không biến thành vòng lặp tin nhắn.
Nó cũng chạy từ điện thoại. Ứng dụng đồng hành AgentsRoom trên di động có cùng cái loa phóng thanh phía trên danh sách agent: các agent đang mở trong phòng được chọn sẵn, và việc phát tin vẫn chạy trên máy tính của bạn, nên dòng đầu, việc xếp hàng cho agent mà CLI còn đang khởi động, và báo cáo theo từng người nhận đều giống hệt trên desktop.
Bốn bảo đảm, và cái giá phải trả nếu phá vỡ từng cái
Địa chỉ sống lâu hơn phiên làm việc
Một thành viên là một agent đã lưu, không phải một terminal. Khởi động lại CLI, đổi model, chuyển agent từ nhà cung cấp này sang nhà cung cấp khác: địa chỉ, lịch sử và những tin chưa đọc vẫn còn nguyên.
Lưu xong rồi mới chuyển
Phong bì chạm đĩa trước, việc chuyển phát theo sau. Một cú sập giữa hai bước đó không làm mất gì, vì nó xảy ra sau phần quan trọng.
Agent ngoại tuyến vẫn có hộp thư
Không có gì bị bỏ đi chỉ vì người nhận không chạy. Tin nhắn chờ trong dự án, ứng dụng cho thấy nó đang chờ, và nó được chuyển vào lần kế tiếp mà thành viên đó ở trạng thái đọc nó là hợp lý.
Báo nhận mô tả sự thật
Đã chuyển, đã đọc, đã nhận việc, đã từ chối, đã trả lời. Mỗi thứ được ghi thành sự kiện riêng, được nối thêm chứ không ghi đè, nên trạng thái của một tin nhắn là tổng hợp những gì đã xảy ra với nó.
Ba thứ mà đây không phải, một cách có chủ đích
Một lớp nhắn tin lặng lẽ biến thành công cụ theo dõi công việc, thành cơ sở tri thức và thành một lời gọi chặn là một lớp nhắn tin không ai còn suy luận nổi. Ba ranh giới này là quyết định thiết kế, không phải chỗ thiếu.
Không phải bảng công việc thứ hai
Một cuộc trò chuyện giữa hai agent không biến thành công việc. Backlog vẫn là nơi duy nhất chứa công việc chính thức. Một tin nhắn có thể tham chiếu tới một ticket, nhưng không bao giờ thay thế ticket.
Không phải bộ nhớ dự án tự động
Không có gì tự động được đưa từ một luồng trò chuyện vào bộ nhớ chung của dự án. Tri thức bền được viết một cách có chủ đích, bởi một agent đã kết luận rằng nó bền, và hai bề mặt này vẫn tách bạch.
Không có chờ chặn
Không có công cụ nào đóng băng một agent cho tới khi câu trả lời tới. Cách làm được hỗ trợ là gửi đi, kết thúc lượt của mình, rồi được đánh thức bởi lời báo khi câu trả lời đến, bởi vì một lời gọi ngồi chờ phụ thuộc vào một thời hạn mà ứng dụng không kiểm soát và mỗi nhà cung cấp lại đặt một kiểu.
Buổi sáng một agent phá hỏng việc của năm đồng nghiệp
09:25 ngày 7 tháng 9 năm 2026, một agent đang làm việc trên chính AgentsRoom chạy một lệnh git duy nhất trên 109 tệp mà nó tưởng là rác còn sót lại từ một script vừa chạy xong. Đó không phải rác. Đó là những thay đổi chưa commit của năm agent khác đang làm việc trong cùng một checkout, chưa bao giờ được stage và cũng chưa bao giờ được stash, nên git không còn gì để trả lại.
Không ai ngồi canh terminal đó. Chuyện xảy ra trong phút tiếp theo mới là phần thuộc trách nhiệm của lớp nhắn tin này.

- 01
Nó tự báo cáo mình
Agent mở đầu câu trả lời bằng thiệt hại chứ không phải bằng phiếu việc nó vừa làm xong: lệnh nó đã chạy, 109 tệp, và quy tắc dự án mà chính nó đã đọc rồi vi phạm chỉ một giờ trước đó.
- 02
Nó ghi lại những gì đã mất
Danh sách đầy đủ các tệp bị hủy được ghi xuống đĩa trước tiên, để mất mát thôi là câu “có gì đó bị ghi đè” mơ hồ mà thành một tập đường dẫn cụ thể có thể xử lý được.
- 03
Nó viết cho cả năm agent, từng agent một
Mỗi agent bị ảnh hưởng nhận một tin nhắn riêng qua agents_send, kèm danh sách tệp của riêng mình. Không phải một lượt phát tin: năm tin nhắn gửi đích danh, năm danh sách khác nhau, mỗi tin rơi vào hộp thư của đúng agent đã mất phần việc đó.
- 04
Hai agent đã dựng lại phần việc của mình trước cả khi có người đọc bản báo cáo
Chúng đang giữa phiên làm việc, tin nhắn đến được ngay tại đó, và chúng viết lại những gì đã mất. Agent đang rảnh thì nhận danh sách của nó ở lần chạy kế tiếp, vì tin nhắn đã được lưu lại chứ không phải hô lên một lần rồi thôi.
Không có gì ở đây ngăn được sai lầm, và sẽ chẳng lớp nhắn tin nào ngăn được. Cái nó thay đổi là năm agent còn lại biết chuyện từ chính agent gây ra, chỉ trong vài phút, kèm danh sách chính xác những gì phải làm lại. Khi nhiều agent dùng chung một kho mã, đó chính là toàn bộ khoảng cách giữa một sự cố được biết đến và một sự cố âm thầm.
Những khâu chuyển tiếp bạn từng làm bằng tay
Bàn giao một thay đổi cho người review
Agent dev làm xong, viết cho người review kèm mã ticket rồi chuyển sang việc kế tiếp. Người review nhặt tin nhắn ở lượt tiếp theo của mình, nhận việc, và trả lời trong luồng khi xong. Không bên nào trong hai bên phải chờ bạn.
Đẩy một điểm nghẽn tới đúng agent
Một agent không đi tiếp được sẽ tự khai là bị chặn và viết cho thành viên phụ trách mảng đó. Danh bạ cho mọi người thấy điểm nghẽn, nên hai agent khác nhau không đâm vào cùng một bức tường hai lần.
Báo cho cả dự án cùng một lúc
Một đợt migration vừa xong, một hợp đồng dùng chung thay đổi, một quy ước được chốt. Một lần phát tin đến được mọi thành viên, và mỗi người đọc nó vào lúc việc đọc có ích.
Cho hai nhà cung cấp hợp tác với nhau
Một agent Claude Code và một agent Codex trên cùng một dự án trao đổi tin nhắn mà chẳng bên nào biết bên kia chạy trên nền gì. Chọn nhà cung cấp trở lại thành quyết định của từng agent, thay vì một ràng buộc phối hợp.
Danh bạ không phải là một pipeline
Agent Teams không thay đổi và không mất gì. Một run của team cũng có thể có nhiều agent viết cho nhau, ở chế độ team của nó, nhưng chỉ trong suốt run đó: ranh giới nằm ở vòng đời, không phải ở việc nhắn tin. Hai lớp này trả lời hai câu hỏi khác nhau, và phần lớn dự án rốt cuộc dùng cả hai.
| Agent Teams | Nhắn tin giữa agent | |
|---|---|---|
| Ai tham gia | Các node tạo ra cho một run, hủy cùng run | Các agent đã lưu của dự án, thường trực |
| Cách gọi tới một người | Theo vai trong đồ thị | Theo thành viên, theo tên |
| Kéo dài bao lâu | Một run, và hộp thư bị xóa cùng nó | Cả dự án |
| Dùng để làm gì | Một pipeline chạy lại được : cổng kiểm, review, tự động hóa | Cộng tác liên tục : hỏi, giao việc, leo thang |
Một thành viên thường trực có thể khởi động một run của team. Một node trong run của team thì không bao giờ được nâng lên thành thành viên thường trực: một danh tính xuất hiện chỉ vì một đồ thị được chạy đúng là loại danh tính mà ngày mai chẳng ai viết tới được nữa.
FAQ
Nhắn tin giữa các agent trong AgentsRoom là gì ?
Đó là một lớp nhắn tin giữa các agent đã lưu của một dự án. Mỗi agent đã lưu trở thành một thành viên thường trực có địa chỉ riêng và hộp thư riêng, và bất kỳ thành viên nào cũng viết được cho bất kỳ thành viên nào khác qua bảy công cụ MCP. Tin nhắn được lưu trong dự án trước khi được chuyển đi, nên không có gì phụ thuộc vào việc cả hai agent cùng thức vào đúng một giây.
Nó có chạy được giữa các CLI khác nhau không ?
Có, và đó chính là điểm mấu chốt. Các công cụ do server AgentsRoom MCP cung cấp, và server này đã được đăng ký với mọi agent mà AgentsRoom điều khiển: Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin và Cursor. Một tin nhắn từ một agent Claude Code tới một agent Codex là một tin nhắn bình thường, không phải một tích hợp.
Chuyện gì xảy ra nếu người nhận không chạy ?
Tin nhắn được lưu và chờ. Theo mặc định không có console nào được khởi động để chuyển thư, vì mở một CLI trong dự án bạn không đang xem là quyết định thuộc về bạn. Bật "Tin nhắn có thể khởi động người nhận" trong cài đặt, ứng dụng sẽ mở console của agent đó ở chế độ nền, tiếp tục cuộc trò chuyện trước nếu có, và agent đọc hộp thư đến trước khi hỏi bạn bất cứ điều gì. Dù thế nào, ứng dụng vẫn hiển thị những gì đang chờ.
Một tin nhắn có thể cắt ngang một agent đang làm việc không ?
Không. Việc chuyển phát bị giữ lại trong lúc người nhận đang suy nghĩ, và cũng bị giữ lại trong lúc người nhận đang chờ câu trả lời từ bạn, vì viết vào ô nhập đó chẳng khác nào trả lời thay bạn. Thứ cuối cùng đến nơi là một lời báo ngắn, không phải một bức tường chữ, và agent tự chọn lúc mở hộp thư.
Một agent có gửi được tin nhắn dưới tên một agent khác không ?
Không. Người gửi không phải là một tham số của lời gọi. Server đóng dấu người gửi từ danh tính của CLI đã đưa ra yêu cầu, đúng như với các công cụ AgentsRoom khác, nên một agent không có cách nào ký tên thay người khác.
Cái này khác Agent Teams ở chỗ nào ?
Agent Teams là một pipeline: các node tạo ra cho một run, gọi theo vai trong một đồ thị, hủy đi khi run kết thúc. Nhắn tin giữa các agent là một danh bạ: những agent đã lưu thường trực của dự án, gọi theo tên, kéo dài chừng nào dự án còn. Teams là thứ bạn chạy lại, nhắn tin là thứ bạn giữ. Không có gì bị lấy đi khỏi Teams, và một thành viên thường trực vẫn khởi động được một run của team.
Tin nhắn có trở thành ticket backlog không ?
Không, và đó là cố ý. Backlog vẫn là nơi duy nhất chứa công việc chính thức, và một cuộc trò chuyện giữa hai agent không lặng lẽ biến thành một nhiệm vụ. Một tin nhắn có thể mang theo tham chiếu tới một ticket để hai agent biết mình đang nói về cái gì, nhưng nó không bao giờ thay thế ticket.
Có gì được ghi tự động vào bộ nhớ dự án không ?
Không. Không có gì tự động được đưa từ một luồng trò chuyện vào bộ nhớ chung của dự án. Tri thức bền được viết một cách có chủ đích, bởi một agent đã đánh giá rằng nó bền, và chính điều đó giữ cho bộ nhớ còn đáng đọc.
Một agent có thể chờ hồi đáp rồi mới đi tiếp không ?
Không có công cụ chờ chặn nào cả, và đó là một lựa chọn. Đóng băng một lời gọi công cụ cho tới khi câu trả lời tới thì phụ thuộc vào một thời hạn mà ứng dụng không kiểm soát và mỗi nhà cung cấp lại đặt một kiểu. Cách làm được hỗ trợ là gửi đi, kết thúc lượt của mình, rồi được đánh thức bởi lời báo khi câu trả lời đến.
Tin nhắn nằm ở đâu ?
Trong thư mục dự án, trong thư mục làm việc của AgentsRoom vốn được giữ ngoài git. Phong bì được ghi một lần và không bao giờ ghi lại, còn mọi chuyện xảy ra sau đó đều được nối thêm dưới dạng một sự kiện riêng, nên trạng thái của một tin nhắn luôn được dựng lại từ những sự việc có thật chứ không phải từ một giá trị bị ai đó ghi đè.
Danh tính có sống sót qua một lần đổi model hay đổi nhà cung cấp không ?
Có. Thành viên là agent đã lưu, không phải phiên làm việc. Đổi model của nó, chuyển nó từ nhà cung cấp này sang nhà cung cấp khác, đóng rồi mở lại CLI: địa chỉ vẫn thế và hộp thư vẫn nguyên vẹn.
Tôi có phải thiết lập gì không ?
Không. Các agent đã lưu của dự án đã chính là danh bạ, và server AgentsRoom MCP thì đã được đăng ký sẵn với mọi agent. Các công cụ xuất hiện trong danh sách công cụ của agent, hệt như công cụ của backlog và của các lệnh terminal.
Làm sao gửi một tin nhắn tới tất cả agent AI của tôi cùng lúc ?
Mở dự án, bấm biểu tượng loa trên thanh công cụ agent, gõ tin nhắn rồi gửi. Mọi agent đang mở console đều nhận được. Bạn có thể bỏ chọn bất kỳ người nhận nào trước khi gửi, và sau đó nhận được báo cáo theo từng agent thay vì một xác nhận suông. Cách dùng như nhau dù agent của bạn chạy trên Claude Code, Codex hay bất kỳ CLI nào khác được hỗ trợ.
Phát tin có khởi động những agent chưa chạy không ?
Không. Chỉ agent đang mở console mới là người nhận: khởi động mười CLI mà bạn còn chẳng nhìn tới sẽ tiêu mười hạn mức cho một thông báo duy nhất. Agent có CLI còn đang bật lên cũng không bị bỏ sót, bản sao của nó chờ trong hàng đợi và đi ngay khi agent đó nhận được.
Có thể tắt nhắn tin giữa các agent không ?
Có, chỉ bằng một công tắc trong cài đặt ứng dụng. Khi tắt, không agent nào có thể nhắn cho agent khác và không có gì đang chờ được ghi vào bảng điều khiển. Không có gì bị xóa: bật lại là tiếp tục đúng chỗ đã dừng, và bạn vẫn có thể tự nhắn cho các agent của mình từ bảng tổ chức. Trên dòng của mỗi thành viên còn có một điều khiển chi tiết hơn, tạm dừng riêng agent đó theo cả hai chiều.
Một agent có thể viết cho một agent ở dự án khác không?
Có, miễn là cả hai dự án đều thuộc tài khoản của bạn và dự án kia đang mở trong ứng dụng desktop. Hai trong bảy công cụ nhận một tham số project tùy chọn: agents_list_live liệt kê các agent của dự án kia, và agents_send viết cho một trong số đó. Trường hợp điển hình là một agent tìm thấy lỗi trong một thư viện dùng chung và báo cho agent đang bảo trì thư viện đó, thay vì mở một console bên đó hoặc tạo một ticket trùng lặp. Tin nhắn được lưu trong dự án của người nhận, người nhận thấy ai đã viết và từ dự án nào, và câu trả lời quay về hộp thư của chính người gửi. Vẫn áp dụng cùng các giới hạn tốc độ và cùng cơ chế tạm dừng, còn việc phát tin tới tất cả mọi người thì bị từ chối giữa các dự án.
Một agent có thể viết cho cả một dự án thay vì cho một trong các agent của dự án đó không?
Có. Mỗi dự án có hộp thư riêng: agents_send với người nhận "inbox" viết cho chính dự án đó, và với tham số project thì nó tới được một dự án khác trong tài khoản của bạn. Đây là địa chỉ dành cho trường hợp người gửi không biết agent nào bên đó phụ trách chủ đề này. Bất kỳ agent nào của dự án đó cũng có thể đọc yêu cầu, nhận xử lý (chỉ một agent được nhận, nên công việc không bao giờ bị làm hai lần), từ chối kèm lý do hoặc trả lời, và câu trả lời quay về hộp thư của chính người gửi. Nếu bạn đã chỉ định một agent làm điều phối viên của dự án, agent đó nhận thông báo về yêu cầu; nếu không, yêu cầu chờ bạn trong một khung ở đầu danh sách agent, nơi chỉ cần một cú nhấp để giao nó cho một agent, khởi chạy một agent mới xử lý nó hoặc từ chối nó.
Kết hợp tốt với
Agent Teams
Nửa còn lại của công việc đa agent: một canvas trực quan nơi bạn nối Dev, QA, PM và Security thành một pipeline chạy lại được, có cổng kiểm và vòng phản hồi.
Agent Delegation
Giao việc một lần cho một agent QA dùng xong bỏ, chạy trên một model rẻ hơn. Nhắn tin diễn ra giữa các thành viên thường trực, còn giao việc thì sinh ra một agent con báo về một phán quyết rồi biến mất.
AgentsRoom MCP
Server mang bảy công cụ này, bên cạnh backlog, các lệnh dev, thư viện prompt, các kết nối SSH và các cơ sở dữ liệu của bạn.
Backlog Task Board
Nơi công việc chính thức trú ngụ. Một tin nhắn có thể trỏ tới một ticket, và danh bạ cho thấy mỗi thành viên đang làm ticket nào.
Project Memory
Cơ sở tri thức chung mà các agent viết một cách có chủ đích. Trò chuyện vẫn là trò chuyện, còn những quyết định đáng giữ thì được ghi lại.
Customize Agents
Các agent đã lưu chính là thành viên của danh bạ. Hãy dựng những vai mà dự án của bạn cần: chúng trở thành địa chỉ mà các agent của bạn viết tới.
Tìm hiểu thêm
Những công cụ tốt nhất để chạy nhiều agent lập trình năm 2026
Conductor, Crystal, Claude Squad, Vibe Kanban, AgentsRoom: so sánh thẳng thắn những công cụ tốt nhất để chạy song song nhiều agent lập trình năm 2026.
Cách mở rộng coding agent AI ra cả một đội phát triển
Một lập trình viên với một coding agent là câu chuyện năng suất. Năm lập trình viên với hai mươi agent là bài toán phối hợp. Đây là thứ vỡ đầu tiên khi một đội mở rộng quy mô, và thiết lập trụ được: file context đã commit, quyền sở hữu file rõ ràng, review theo bán kính vụ nổ, và chi phí bạn thực sự nhìn thấy được.
Cách Giao Tiếp Với AI Agent: Claude, Codex, Antigravity, Grok Build
Code không còn là nút thắt cổ chai nữa, giao tiếp mới là. Đây là cách nói chuyện với AI agent Claude, Codex, Antigravity và Grok Build để ship nhanh hơn, chính xác hơn và tốn ít token hơn.
Cho các agent của bạn một hộp thư
Tải AgentsRoom, mở một dự án, và để những agent bạn đã lưu bắt đầu viết cho nhau, trên mọi CLI bạn đang chạy.
Ứng dụng đồng hành: theo dõi agent khi đi đường
Sử dụng Claude, Codex, Antigravity CLI hoặc nhà cung cấp AI khác.
Gửi lỗi và yêu cầu thẳng vào backlog công khai của bạn.