Các tác nhân AI của tôi đã đăng kết quả vào kênh chat nhóm. Một con người phản hồi, và một tác nhân thứ hai nhảy vào mà không hề thấy tin nhắn đầu tiên. Sự hỗn loạn này dẫn đến việc thiếu ngữ cảnh, trùng lặp công việc và các lỗi rõ rệt. Sau khi tích hợp một Giao thức Truyền thông Liên tác nhân (IACP) nhẹ vào máy chủ bộ nhớ và ngăn xếp giám sát hiện có, tình trạng lộn xộn đã chấm dứt và quy trình làm việc trở nên chặt chẽ hơn.

Tại sao vấn đề này lại quan trọng

Trong môi trường production, các tác nhân AI không còn là những thử nghiệm cô lập; chúng hoạt động như các microservices thực hiện việc lấy dữ liệu, tạo mã hoặc kích hoạt triển khai. Khi mỗi tác nhân chỉ giao tiếp với con người, các trách nhiệm chồng chéo sẽ trở thành một tình trạng tranh chấp (race condition) tiềm ẩn. Một tin nhắn Slack lạc lõng trông có vẻ vô hại, nhưng các nhà phát triển sẽ mất hàng phút để gỡ rối các kết quả mâu thuẫn, các pipeline bị đình trệ khi hai bot cùng chỉnh sửa một repository, và niềm tin vào tự động hóa bị xói mòn.

Mắt xích còn thiếu: trạng thái chia sẻ thời gian thực

Hầu hết các nhóm coi các tác nhân là "hộp đen" nhận một prompt và trả về một kết quả, giả định rằng prompt đã chứa tất cả ngữ cảnh cần thiết. Trên thực tế, các tác nhân chia sẻ một không gian làm việc nơi trạng thái liên tục thay đổi: một repository có thể đang bị khóa, một dịch vụ có thể đang bị sập, hoặc một phân tích trước đó có thể vừa mới hoàn thành. Nếu không có cơ chế phát sóng (broadcast), mỗi bot sẽ làm việc dựa trên một bản sao trạng thái đã lỗi thời.

Xây dựng IACP trên nền tảng các công cụ hiện có

Thay vì xây dựng một nền tảng hoàn toàn mới, tôi đã mở rộng máy chủ bộ nhớ (memory server) lưu trữ lịch sử hội thoại và bộ công cụ giám sát (monitoring suite) theo dõi sức khỏe của tác nhân. Giao thức này bổ sung năm khả năng cụ thể:

  • Định danh có cấu trúc (Structured Identity) – Mỗi tin nhắn gửi đi đều mang một mã định danh duy nhất như claude@greenmac:8f3a2c. Định dạng này cho phép người nhận biết ngay lập tức ai đã gửi tin nhắn và từ instance nào, loại bỏ các tuyên bố mơ hồ kiểu "bot nói X".

  • Chèn lịch sử (History Injection) – Trước khi tạo câu trả lời, một bot sẽ lấy đoạn chat gần nhất, bao gồm cả tin nhắn từ các tác nhân khác, và chèn nó vào trước prompt của mình. Ngữ cảnh sẽ không bao giờ bị mất, và mô hình có thể suy luận về những gì các đồng nghiệp của nó đã đóng góp.

  • Chuyển đổi trạng thái (State Transitions) – Các tác nhân ngừng gửi các tín hiệu heartbeat liên tục. Thay vào đó, chúng đăng một thay đổi trạng thái—working, blocked, hoặc idle—bất cứ khi nào trạng thái nội bộ của chúng thay đổi. Các bên tiêu thụ (consumers) sẽ phản ứng ngay lập tức, ví dụ như chỉ đưa một tác vụ phụ thuộc vào hàng đợi khi tác nhân thượng nguồn báo cáo trạng thái idle.

  • Cơ chế Lease (Advisory Leases) – Khi một tác nhân cần quyền truy cập độc quyền vào một tài nguyên (một repo, một API endpoint, một compute node), nó sẽ yêu cầu một lease với TTL (time-to-live). Nếu tác nhân bị lỗi, lease sẽ tự động hết hạn, giải phóng tài nguyên cho những tác nhân khác và ngăn chặn việc hai bot can thiệp vào công việc của nhau.

  • Cơ chế Hộp thư đến (Inbox Mechanism) – Một "stop hook" sẽ tạm dừng quy trình làm việc của tác nhân nếu hộp thư đến của nó chứa các tin nhắn chưa đọc. Tác nhân phải xử lý các mục đó trước khi hoàn thành tác vụ hiện tại, đảm bảo các tín hiệu điều phối đang chờ xử lý không bị bỏ qua.

Những thành phần này kết nối lại với nhau thành một lớp giao tiếp đơn giản, có thể quan sát được, giúp mọi thành viên luôn nắm bắt được cùng một thông tin.

Rủi ro cho các nhóm phớt lờ nó

Nếu một nhóm tiếp tục dựa vào các prompt tùy hứng và việc giám sát thủ công, các chi phí ẩn sẽ tích tụ:

  • Nỗ lực trùng lặp – Hai tác nhân có thể tạo ra các báo cáo giống hệt nhau, tiêu tốn chu kỳ tính toán và chi phí đám mây.
  • Tranh chấp tài nguyên – Việc ghi đồng thời vào một codebase sẽ gây ra các xung đột merge (merge conflicts) đòi hỏi con người phải giải quyết.
  • Rủi ro vận hành – Một tác nhân hành động dựa trên trạng thái lỗi thời có thể cố gắng triển khai trong khi một tác nhân khác đang thực hiện rollback, làm mất ổn định dịch vụ.

Bằng cách chính thức hóa cách các tác nhân thông báo danh tính, trạng thái và yêu cầu tài nguyên, IACP cắt giảm các rủi ro này mà không đòi hỏi một công cụ điều phối (orchestration engine) cồng kềnh.

Quan điểm ngược lại: chi phí vận hành tăng thêm

Những người chỉ trích cho rằng việc chèn lịch sử và quản lý các lease sẽ làm tăng độ trễ và thêm các luồng mã (code paths). Trong các môi trường mà một tác nhân duy nhất xử lý một tác vụ hẹp, lợi ích của giao thức có thể không đáng kể. Tuy nhiên, việc triển khai này tái sử dụng các dịch vụ bộ nhớ và giám sát hiện có, vì vậy tải tăng thêm là rất nhỏ. Đối với các nhóm đang gặp phải tình trạng nhầm lẫn giữa các tác nhân, sự đánh đổi này rõ ràng là có lợi.

Những điều cần theo dõi tiếp theo

Giao thức này vẫn đang là một bản mẫu (prototype), nhưng tính chất mô-đun của nó cho phép tích hợp với bất kỳ framework tác nhân nào không phụ thuộc vào ngôn ngữ (language-agnostic). Các bước tiếp theo tiềm năng bao gồm:

  • Phát hành một SDK nhẹ để các nhà phát triển có thể thêm năm hook mà không cần can thiệp vào logic cốt lõi.
  • Thêm các chỉ số vào bộ công cụ giám sát để trực quan hóa các bước chuyển đổi trạng thái và sự biến động của lease, giúp các nhóm phát hiện các điểm nghẽn.
  • Thử nghiệm với các lớp chính sách giúp tự động ưu tiên lease của một số agent nhất định so với các agent khác trong các kịch bản lưu lượng cao.

Nếu các phần mở rộng này trở nên phổ biến, IACP có thể trở thành một tiêu chuẩn de-facto cho các quy trình sản xuất đa agent, giống như cách HTTP đã làm với các dịch vụ web.

Bài học rút ra: Một bộ quy ước đơn giản—ai đang nói, nội dung cuộc hội thoại gần đây như thế nào, khi nào trạng thái của một agent thay đổi, ai đang nắm giữ tài nguyên và liệu có tin nhắn nào đang chờ hay không—có thể ngăn các agent AI nói chuyện chồng chéo lên nhau và biến một phòng chat ồn ào thành một kênh điều phối đáng tin cậy.