Panoramica
Un processo che fai girare accanto al tuo agente, non una libreria attorno a cui il tuo agente è costruito. Tiene l’esecuzione tra un passo e l’altro e registra ognuno. Questa pagina è la forma dell’insieme in una sola lettura.
Un solo processo
mcpd fa due cose con un solo processo. Tiene un’esecuzione durevole tra un passo e l’altro: il cursore, i nuovi tentativi, i timer e le attese, mentre il tuo codice, in qualsiasi linguaggio, fa il lavoro dentro ogni passo. E riceve quello che il tuo agente ha fatto, lo archivia e te lo restituisce come esecuzioni che puoi leggere. È un solo binario con SQLite collegato dentro. Non c’è un database da mettere in piedi, non c’è un collector da far girare a fianco, e non c’è nessun account da nessuna parte.
Il daemon ascolta sulla porta 4317 e serve cinque cose da
quella sola porta:
-
L’ingest OTLP su
/v1/traces,/v1/logse/v1/metrics, così una configurazione OpenTelemetry già in piedi non richiede codice nuovo. -
L’ingest nativo su
/v1/ingest, che porta le parti del modello per cui OTLP non ha posto, compresi i punteggi e il feedback delle persone. -
L’API di lettura sotto
/v1/api, che usano sia l’interfaccia sia gli SDK. Non c’è nessuna API privata dietro quella che ricevi tu. -
La superficie delle esecuzioni sotto
/v1/api/runs,/v1/api/eventse/v1/api/steps: le definizioni, le esecuzioni, gli eventi che rispondono a un’attesa e il protocollo che parla un worker. Vedi Workflow. -
L’interfaccia per chi lo gestisce su
/, incorporata nel binario.
Una sola porta è una decisione di deploy, non una scorciatoia. Un collector, un database e una UI sono tre cose da far girare, tre cose da aggiornare e tre punti tra i quali una traccia si può perdere.
Tutta l’installazione, una volta pubblicata
docker run -p 4317:4317 ghcr.io/mcpd/mcpd Nessuna release, per ora.
L'immagine, il chart e i pacchetti che i comandi di questo sito nominano sono la distribuzione prevista. Nessuno di essi è stato pubblicato. Quello che funziona oggi è una compilazione dai sorgenti, che richiede Rust e Node:
Compila ed esegui
git clone https://github.com/mcpd/mcpd && cd mcpd && make build && ./target/release/mcpd demo Quello che di proposito non è
Gran parte del valore qui viene da quello che mcpd si rifiuta di fare. Ogni rifiuto toglie un motivo per cui avresti dovuto cambiare il tuo agente.
- Non è un framework. mcpd non esegue mai il tuo modello, non lo sceglie e non avvolge il client del tuo fornitore. Tiene un’esecuzione tra un passo e l’altro e lascia al tuo codice tutto quello che sta dentro un passo. Dopo che hai adottato mcpd, il tuo codice chiama un modello nello stesso modo di prima.
- Non sta sul percorso della richiesta. Non si mette mai tra il tuo agente e un fornitore. Niente di quello che vedono i tuoi utenti dipende da mcpd acceso, perché niente di quello che vedono passa da lui.
- Non è un servizio. Per impostazione predefinita il daemon
non chiama niente. Non c’è telemetria, non c’è un controllo di licenza e
non c’è un endpoint del fornitore. L’unico traffico in uscita che farà mai
è quello che configuri tu: un
--forward-endpoint, il webhook di un monitor, o un modello giudice. Non impostare nessuno dei tre e i tuoi prompt non lasciano mai la macchina su cui lo hai avviato. - Non è una dipendenza obbligatoria. Se cancelli mcpd dalla tua infrastruttura, l’unica cosa che si ferma è la registrazione.
I sei segnali
mcpd archivia sei tipi di cose, e li archivia insieme. Gli span sono quello che è stato eseguito. I log sono le righe che un’esecuzione ha emesso. Le metriche sono numeri nel tempo. I punteggi sono il giudizio di una macchina su un’esecuzione. Il feedback è quello di una persona. Una nota di aspetto è una frase che un modello ha scritto su un’esecuzione conclusa.
Il punto è tutto qui: tenerli in un solo storage. Ogni segnale porta l’id di traccia e l’id di span a cui appartiene, così la domanda «che cosa ha detto davvero il modello nell’esecuzione di cui questo cliente si è lamentato, e quanto è costata» è una sola query invece di quattro prodotti e un timestamp da far combaciare a occhio.
-
Spans
What ran, nested, with timings
-
Logs
Lines the run emitted
-
Metrics
Numbers, with exemplars back to a run
-
Scores
Machine evaluation
-
Feedback
What a person thought
-
Aspect notes
A sentence a model wrote about the run
I punteggi e il feedback restano separati apposta. Lo 0.8 di uno scorer e il pollice verso di una persona misurano cose diverse, e farne una media produce un numero che non vuol dire niente.
Perché un daemon e non un framework
L’osservabilità dei framework è buona, e arriva attaccata al framework. Perché un agente sia visto, ci si aspetta che sia stato costruito con quel framework, di solito in un solo linguaggio. È uno scambio equo per un progetto nuovo e uno scambio impossibile per un agente che esiste già e già funziona. I workflow dei framework sono lo stesso scambio: durevoli, finché ogni passo è scritto nel linguaggio del framework e gira dentro il suo processo.
Un daemon ribalta tutti e due. Il grafo di un workflow è un dato che tiene il daemon; i corpi dei suoi passi sono codice che tiene il tuo processo, presi in carico un lease alla volta attraverso un protocollo HTTP che qualsiasi linguaggio sa parlare. Il daemon non vede mai un modello, un prompt o una credenziale. Vedi Workflow e Worker.
Un daemon ribalta lo scambio. mcpd parla OTLP, che è un protocollo e non una
dipendenza, quindi registra agenti scritti in qualsiasi linguaggio, con
qualsiasi framework, compresi quelli scritti prima che mcpd esistesse. Se il
tuo agente esporta già OpenTelemetry, puntare
OTEL_EXPORTER_OTLP_ENDPOINT su mcpd è tutta l’integrazione.
Gli SDK esistono perché OTLP non ha un vocabolario per un prompt, una completion, un conteggio di token o un punteggio, e sono proprio quei campi che sei venuto a cercare. Usarne uno è una scelta, non una condizione. Tutti e sei si comportano allo stesso modo: registrare uno span aggiunge a una coda limitata e ritorna, il lavoro di rete avviene su un worker in secondo piano, e niente nel percorso di strumentazione solleva mai un’eccezione. Un sistema di osservabilità che può far cadere il sistema che osserva è peggio di non averne nessuno.
Un solo binario, due deploy
Il container che fai girare su un portatile è il container che gira come Deployment sul cluster di qualcuno. La conservazione, l’oscuramento, il campionamento e le chiavi API sono opzioni di quello stesso binario, non una build diversa e non un livello di licenza. Non c’è nessuna funzione che esiste solo in una versione che non puoi avere.
I valori predefiniti sono tarati sul portatile, il che vuol dire che l’ingest e le letture sono aperti quando non è configurata nessuna chiave. In quello stato mcpd avverte a chiare lettere all’avvio, quando è in ascolto su un indirizzo che non è di loopback. Parte lo stesso, perché rifiutarsi romperebbe il percorso di cinque minuti per la persona a cui è rivolto, ma tacere sarebbe irresponsabile.
Dove andare adesso
- Farlo girare adesso: Avvio rapido porta sullo schermo una traccia del tuo agente, oppure Installazione copre tutte le strade per entrare.
- Imparare il vocabolario: Concetti definisce traccia, span, tipo e correlazione, che il resto della documentazione dà per scontati.
- Tenere un’esecuzione tra un passo e l’altro: Workflow, poi Worker ed Esecuzioni.
- Hai già OpenTelemetry: il percorso OTLP per intero, compreso quello che mcpd deduce dagli attributi standard.
- Farlo girare per altre persone: Docker e Kubernetes, poi Oscuramento e conservazione.
mcpd è rilasciato con licenza Apache-2.0. Il protocollo in entrata, il formato in uscita e la licenza attorno sono tutti aperti, così andarsene costa quanto arrivare.