Construindo uma Rede de Agentes Distribuídos em Rust: Lições da Arquitetura do Cord

Construir um sistema de agentes distribuídos que se comunica com vários servidores MCP sem entrar em colapso devido à latência ou ao caos de memória é difícil. Aprendi isso da maneira mais difícil enquanto construía o Cord, uma estrutura de agentes que coordena dezenas de provedores de ferramentas em uma malha de trabalhadores concorrentes—e o modelo de propriedade do Rust e a concorrência de custo zero transformaram o que poderia ter sido um pesadelo de depuração em uma experiência surpreendentemente tranquila.

O desafio central: cada agente é executado como uma tarefa assíncrona leve, comunicando-se com servidores MCP via JSON-RPC. Você precisa compartilhar estado (identidade do agente, registro de ferramentas, solicitações pendentes) sem bloqueios ou condições de corrida, e precisa fazer isso rapidamente—as transferências de agentes acontecem em microssegundos. O Arc<tokio::sync::RwLock> do Rust é a escolha óbvia, mas a verdadeira vantagem é o compilador te avisando quando você acidentalmente clonou uma referência que deveria ser um empréstimo, ou quando um &mut entra em conflito em uma fronteira de .await.

Aqui está um trecho simplificado de como o Cord inicia um trabalhador de agente MCP que encaminha chamadas de ferramentas para o servidor correto sem bloquear:

use tokio::sync::RwLock;
use std::sync::Arc;
use mcp_client::{McpClient, ToolCall};

struct AgentWorker {
    tool_registry: Arc<RwLock<HashMap<String, McpClient>>>,
}

impl AgentWorker {
    async fn handle_tool_call(&self, tool: &str, input: serde_json::Value) -> Result<String> {
        let client = {
            let registry = self.tool_registry.read().await;
            registry.get(tool).cloned()? // clone the Arc<McpClient>
        };
        client.call(tool, input).await // no lock held during I/O
    }
}

A chave: liberamos o bloqueio de leitura antes da chamada assíncrona call. As regras de escopo do Rust tornam isso explícito e o verificador de empréstimos o impõe. Sem contenção acidental de bloqueio, sem "referência pendente" em uma fronteira assíncrona—apenas um fluxo de propriedade limpo e previsível.

O que mais me surpreendeu foi o desempenho. Com Go ou Node.js, o GC do tempo de execução causaria picos ocasionais quando a estrutura de agentes estava sob carga (por exemplo, transmitindo logs de 50 servidores MCP simultaneamente). A falta de GC no Rust significa pausas zero, e como controlamos a alocação, podemos pré-alocar buffers de conexão por trabalhador. Em produção, a latência p99 caiu de 12ms para 3ms após a migração da estrutura central de Go para Rust—e o uso de memória foi reduzido pela metade.

Se você está construindo sua própria malha de agentes–MCP, eu também recomendaria adotar camadas tower para middleware (repetição, tempo limite, limitação de taxa) e tokio’s select! para uma queda graciosa. Mas a maior lição: não lute contra o verificador de empréstimos. Ele não é um guardião—é a prova de correção mais barata do mundo para o seu estado distribuído.

A arquitetura completa do Cord é de código aberto e está ao vivo no Smithery. Eu a empacotei para que você possa executar sua própria estrutura de agentes sem experiência em Rust se você apenas quiser experimentar a topologia de rede.

Veja a entrada do catálogo aqui: https://smithery.ai/servers/vishar-rumbling

Adoraria saber como você lida com estado mutável compartilhado em seus próprios sistemas de agentes—comente ou faça um PR se você tiver um padrão assíncrono mais inteligente.