Design of Multi-Agent Communication Protocols

Core Challenges in Multi-Agent Communication

When 3, 10, or even 100 AI Agents work simultaneously in a system, how do they exchange information efficiently and accurately? This seemingly simple question encompasses the most classic challenges in distributed systems: inconsistent message formats, routing chaos, temporal dependencies, fault propagation, and consistency guarantees. The difference between inter-agent communication and microservice API calls lies in: semantic ambiguity (multiple expressions for the same intent), context dependency (message meaning depends on history), dynamic routing (recipients may not be predetermined), and streaming transmission (intermediate results need to be streamed).

Message Format Design: Balancing Structure and Flexibility

The recommended message structure consists of three parts: header (pure metadata like message_id, session_id, sender/recipient, priority, etc., for routing and deduplication), body (intent label for quick routing, payload with actual task content including natural language and structured parameters), and metadata (orchestration metadata like task_chain_id, retry_count, ttl). This design allows the message middleware and Agents to handle their respective parts independently.

Routing Strategies: From Static to Intelligent

1. Static routing: Sender and recipient are determined at orchestration time; simple but inflexible.
2. Capability-based dynamic routing: Agents declare capability tags to a registry, and the routing layer matches by intent. Currently the most common approach.
3. Semantic-based intelligent routing: Use embeddings to map messages and capability descriptions into the same vector space for matching; highest flexibility.

It is recommended to start with capability-based dynamic routing and introduce semantic routing for edge cases after gaining experience.

Hands-on Practice: Agent Communication Bus

import json, uuid, time
from collections import defaultdict
from openai import OpenAI

client = OpenAI(api_key="your-deepseek-api-key", base_url="https://api.deepseek.com")

class AgentBus:
    def __init__(self):
        self.agents = {}
        self.queue = []
        self.history = {}

    def register(self, aid, caps, handler):
        self.agents[aid] = {"caps": set(caps), "handler": handler}

    def send(self, sid, rid, intent, payload):
        msg = {"header":{"msg_id":str(uuid.uuid4()),"sender":sid,"recipient":rid,
                         "ts":time.time(),"type":intent},"body":{"intent":intent,"payload":payload}}
        self.history[msg["header"]["msg_id"]] = msg
        self.queue.append(msg)
        return msg["header"]["msg_id"]

    def route(self, sid, intent, payload):
        matched = [aid for aid,info in self.agents.items() if aid!=sid and intent in info["caps"]]
        return [self.send(sid, aid, intent, payload) for aid in matched]

    def process(self):
        results = {}
        for msg in self.queue:
            rid = msg["header"]["recipient"]
            if rid in self.agents:
                results[msg["header"]["msg_id"]] = self.agents[rid]["handler"](msg)
        self.queue.clear()
        return results

bus = AgentBus()
bus.register("exec1", ["code_gen"], lambda m: f"executed {m['body']['intent']}")
bus.register("exec2", ["code_gen","test"], lambda m: f"tested {m['body']['intent']}")
bus.route("planner", "code_gen", {"task":"login module"})
print(bus.process())

Communication Patterns and Consistency

Point-to-point: Messages go directly from sender to a specific recipient, suitable for task assignment scenarios. Publish-subscribe: Messages are published to a topic, and all subscribers receive them, suitable for broadcast scenarios. Real systems typically use a mix. Consistency guarantee strategies: idempotency design (deduplication via message_id), transactional sessions (atomic processing under the same session_id), heartbeat and timeout (monitor online status and automatically reassign), dead letter queue (failed messages are not discarded but analyzed by a fault-handling Agent).

Production Environment Recommendations

1. Message persistence: Use Kafka/RabbitMQ instead of in-memory queues.
2. Monitoring and tracing: Trace ID across the call chain, distributed tracing with Jaeger/Zipkin.
3. Message size limits: Set an upper limit (e.g., 1MB), and use shared storage references for larger payloads.
4. Version compatibility: Semantic versioning, declare protocol version in message header.

Performance Benchmark and Stress Testing of Communication Protocols

Before deploying the multi-Agent communication bus to production, thorough performance testing is essential. We designed a benchmark suite: throughput test—simulate 10/50/100 Agents sending messages concurrently, measure the number of messages the bus can process per second (target >1000 msg/s); latency test—measure P50/P95/P99 message delivery latency (from sending to the recipient starting processing, target P99 <100ms); backpressure test—when the recipient's processing speed

When it cannot keep up with the sending speed, whether the bus can correctly apply backpressure instead of dropping messages or OOM; failure recovery testing—simulate agent downtime, network partitions, and message broker restarts to verify no message loss and session consistency. The test results guided several optimizations: message batching (deliver in batches after accumulating 10 messages or waiting 5ms), zero-copy transmission (use shared memory for large messages instead of serialization copy), and priority queues (high-priority messages go through a dedicated channel and are not blocked by low-priority ones).

Message Queue Selection Comparison

The choice of the underlying message middleware for the Agent communication bus has far-reaching implications. Redis Streams — the simplest to deploy (shares a Redis with the cache), supports consumer groups and message acknowledgments, suitable for small systems with message volume <10,000 messages/second. RabbitMQ — mature and stable, supports complex routing rules and dead-letter queues, suitable for scenarios with extremely high reliability requirements. Apache Kafka — ultra-high throughput (millions of messages/second), strongest message persistence and ordering guarantees, suitable for large-scale Agent clusters and event sourcing patterns. NATS — ultra-low latency (microsecond level), suitable for real-time Agent collaboration that is extremely sensitive to latency. Our choice is Kafka — every message from an Agent is valuable audit data, and Kafka's long-term storage and event replay capabilities are invaluable during troubleshooting.

Agent Identity Authentication and Message Signing

In a multi-Agent system, ensuring the authenticity of message sources is the foundation of security. We have implemented a JWT-based Agent identity authentication mechanism: each Agent receives an identity token issued by the communication bus upon registration (containing agent_id, public key fingerprint, and expiration time). When sending messages, the Agent signs the message body with its private key, and the receiver verifies the signature and token validity through the communication bus. This mechanism prevents two common attacks: Agent impersonation (malicious processes forging agent_id to send messages — they are directly rejected without valid tokens and signatures) and message tampering (man-in-the-middle modifying message content — signature verification fails). In terms of performance, the Ed25519 signature algorithm takes only microseconds on ordinary CPUs, and its impact on message latency is negligible.