Dați unui agent LangChain un număr WhatsApp

Cum încarcă un agent LangChain uneltele WhatsApp?

Prin MCPAdapter, clientul MCP din LangChain, care predă uneltele unui server MCP lui create_agent ca unelte LangChain obișnuite. Necesită langchain[mcp] la versiunea 1.4.0 sau mai nouă și este marcat beta.

Autentificarea este delegată către FastMCP. Dacă transmiteți auth="oauth" pe client, rulează fluxul complet OAuth 2.1: descoperirea, înregistrarea dinamică a clientului, redirecționarea din browser și schimbul de token. Exact asta așteaptă serverul MCP EasyCoexistence, deci nu aveți nicio cheie de creat sau de lipit. Implicit, token-urile rămân în memorie și fiecare rulare repetă pasul din browser; un furnizor OAuth FastMCP cu un depozit de token-uri le păstrează între rulări.

După încărcare, agentul vede uneltele împreună cu descrierile lor: mai întâi list_numbers, pentru că toate celelalte unelte primesc de la ea un connection_id, apoi send_message, send_template, list_templates, get_number_health și restul.

from fastmcp.client import Client
from langchain.agents import create_agent
from langchain.mcp import MCPAdapter

URL = "https://easycoexistence.com/api/mcp"

async def build_agent(model: str):
    async with MCPAdapter(Client(URL, auth="oauth")) as adapter:
        tools = await adapter.list_tools()
        return create_agent(model, tools)

Cum ajunge un mesaj WhatsApp primit la agent?

Prin webhook, pentru că MCP nu poate face asta. Protocolul funcționează pe schema cerere și răspuns, deci nimic din el nu permite unui server să trezească un client când scrie un client al dumneavoastră.

Setați destinația webhook-ului numărului către o rută din aplicația dumneavoastră, cu un secret lung și aleatoriu în calea URL-ului. Ruta răspunde la GET-ul de verificare al Meta cu challenge-ul brut, acceptă fiecare POST, returnează imediat 200 și pune munca în coadă. Apoi un proces de lucru ia expeditorul și textul din payload și invocă agentul cu ele, folosind numărul expeditorului ca identificator de fir (thread id), astfel încât memoria să rămână separată pentru fiecare client.

Verificați secretul din URL, nu antetul X-Hub-Signature-256. Meta semnează cu app secret-ul Tech Provider-ului, care nu este niciodată partajat, așa că acel antet nu poate fi validat de client.

Ar trebui agentul să trimită prin MCP sau prin Cloud API?

Merg amândouă, iar diferența este cine ține regulile. Uneltele MCP poartă regulile WhatsApp în descrierile lor: send_message funcționează doar în fereastra de 24 de ore, iar send_template este calea de a ajunge la cineva care nu a scris. Un model care citește aceste descrieri alege corect de cele mai multe ori, iar acolo unde agentul decide liber, asta ajută.

O unealtă proprie simplă, care trimite către endpoint-ul de mesaje din Cloud API cu token-ul numărului, este mai simplă când sarcina agentului este îngustă, de exemplu să răspundă mereu persoanei care tocmai a scris. Atunci verificarea ferestrei stă în codul dumneavoastră, locul potrivit pentru o regulă care nu trebuie încălcată niciodată. Textul liber trimis în afara ferestrei întoarce eroarea 131047, iar clientul nu vede nimic.

Greșeli frecvente

• Să așteptați ca MCP să livreze mesajele primite. Fără o rută de webhook, agentul nu aude niciodată de la un client.
• Să lăsați token-urile OAuth în memorie pe un server. Fiecare repornire cere o autentificare din browser; păstrați-le cu un depozit de token-uri.
• Să folosiți un singur fir pentru toți clienții. Legați memoria agentului de numărul expeditorului.

Întrebări frecvente

Continuați să citiți