Nhắn tin giữa agent : hộp thư bền vững : mọi CLI

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.

Thư của agent
1 chưa đọc
Dev backend
Claude Code
Luồng thanh toán sẵn sàng để review
Kỹ sư QA
CodexHộp thư
Đã lưu
Xếp hàng
Đã chuyển
Đã đọc

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 sáu 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ì.

Quay một mạch. Agent DevOps được nhờ liên hệ “developer của mình”: nó tự tìm người nhận trong danh sách đang trực tuyến rồi viết qua agents_send. Tin nhắn rơi vào hộp thư của agent Full-Stack đang chạy trên một CLI khác, agent đó đọc, nhận việc và bắt tay vào làm. Không ai phải chép gì từ terminal này sang terminal kia.
Khoảng trống được lấp

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.

Cách hoạt động

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. 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. 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. 3

    Việc chuyển phát chờ đúng thời điểm

    Chuyển phát là một hệ quả phụ, không phải một đ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 từ bạn, tin nhắn cũng được giữ lại, vì viết vào ô nhập đó chẳng khác nào trả lời thay bạn. Nếu người nhận đang ngoại tuyến, tin nhắn chỉ việc chờ: không bao giờ có console nào được khởi động chỉ để giao thư.

  4. 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. 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.

Chế độ chia đôi màn hình của AgentsRoom với hai agent lập trình AI cạnh nhau, mỗi terminal hiển thị tin nhắn nhận được từ agent còn lại
Hai đầu của cùng một luồng. Tin nhắn đến thẳng trong terminal của agent, kèm tên người gửi, và thanh bên vẫn giữ cuộc trò chuyện ở trạng thái chưa đọc cho tới khi agent đó thực sự đọc nó.
Sáu công cụ MCP

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_send

Viế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_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_reply

Trả 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_ack

Nhậ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_status

Khai 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.

Một agent AgentsRoom chọn người nhận theo vai trò, gửi tin nhắn cho agent khác rồi làm việc tiếp mà không chờ trả lời
Phía người gửi. Chỉ cần “hỏi developer của mình”: agent xem ai đang trực tuyến, chọn agent Full-Stack, viết cho nó rồi tiếp tục làm việc. Câu trả lời sẽ quay lại sau dưới dạng thông báo trong terminal của chính nó.
Điều làm nên độ bền

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ó.

Giới hạn cố ý

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.

Điều nó thay đổi hằng ngày

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.

Bên cạnh Agent Teams

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 TeamsNhắn tin giữa agent
Ai tham giaCác node tạo ra cho một run, hủy cùng runCác agent đã lưu của dự án, thường trực
Cách gọi tới một ngườiTheo vai trong đồ thịTheo thành viên, theo tên
Kéo dài bao lâuMộ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óaCộ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 sáu 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 và Devin. 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 lại và chờ. Không bao giờ có console nào được khởi động chỉ để giao thư, vì mở một CLI trong một dự án mà bạn không nhìn tới là quyết định thuộc về bạn. Ứng dụng cho thấy những gì đang chờ, và việc chuyển phát diễn ra vào lần kế tiếp mà thành viên đó ở trạng thái đọc nó là hợp lý.

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.

Kết hợp tốt với

Tìm hiểu thêm

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.

Miễn phíTải AgentsRoom

Ứ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.

Tải tiện ích mở rộng
Chrome Web Store

Gửi lỗi và yêu cầu thẳng vào backlog công khai của bạn.

Một cái nhìn về AgentsRoom đang hoạt động.

Nhiều dự án
Đa nhà cung cấp
Nhiều agent
Trạng thái trực tiếp
File diff & commit
Ứng dụng đồng hành mobile
Xem trước trực tiếp
Đội agent
Tự động hóa trình duyệt
Dev theo backlog
Thư viện prompt
Thư viện skill
Xem tất cả tính năng