Ein Agent, der sich zwischen den Sitzungen an Ihr Projekt "erinnert", erinnert sich an gar nichts. Etwas hat ihm eine Datei gereicht, und er hat die Datei gelesen. Die interessante Frage ist nicht, wie das Modell Wissen speichert, sondern wer entscheidet, was weitergereicht wird, und das Model Context Protocol beantwortet diese Frage in einem Satz, den die meisten überspringen.
Der Satz, der die Sache klärt
Die MCP-Spezifikation beschreibt Ressourcen, den Mechanismus, mit dem ein Server einem Modell Daten zugänglich macht, und benennt deren Designabsicht unmissverständlich:
Ressourcen in MCP sind so konzipiert, dass sie anwendungsgesteuert sind, wobei Host-Anwendungen bestimmen, wie Kontext entsprechend ihren Anforderungen einbezogen wird.
Achten Sie darauf, was hier wem zugewiesen wird. Der Server bietet an. Die Host-Anwendung entscheidet. Das Modell erhält, was diese Entscheidung überlebt hat.
Die Spezifikation weigert sich dann, die Entscheidung selbst zu standardisieren: Implementierungen können Ressourcen über jedes Interface-Muster bereitstellen, das ihnen passt, und das Protokoll selbst schreibt kein bestimmtes Benutzerinteraktionsmodell vor. Es schlägt Möglichkeiten vor, eine Auswahl in einer Baum- oder Listenansicht, ein Suchfeld oder die automatische Einbeziehung auf Basis von Heuristiken oder der eigenen Auswahl des Modells, ohne eine davon zu verlangen.
Zwei Agenten, die dasselbe Protokoll sprechen und mit demselben Server verbunden sind, können also bei völlig unterschiedlichem Kontext landen. Das ist kein Mangel. Es ist das Protokoll, das sich weigert, eine Produktentscheidung für Sie zu treffen.
Was eine Ressource konkret ist
Eine Ressource sind Daten, die durch eine URI identifiziert werden: eine Datei, ein Datenbankschema, anwendungsspezifische Informationen. Server, die sie unterstützen, müssen eine resources-Capability deklarieren und können zwei optionale Funktionen ankündigen:
listChanged, ob der Server eine Benachrichtigung sendet, wenn sich die Liste der verfügbaren Ressourcen ändert.subscribe, ob er Aktualisierungsbenachrichtigungen für bestimmte Ressourcen unterstützt, die ein Client beobachten möchte.
Ein Server kann eine davon, beide oder keine ankündigen. Clients ermitteln mit resources/list, was vorhanden ist, und lesen Inhalte mit resources/read.
Bei einer Einschränkung der Spezifikation lohnt sich ein Innehalten, denn sie schließt eine ganze Kategorie raffinierter Entwürfe aus. Die Menge der Ressourcen, die ein Server zurückgibt, darf nicht pro Verbindung oder als Nebeneffekt anderer Anfragen auf der Verbindung variieren. Sie kann sich im Laufe der Zeit ändern, und sie darf je nach der in der Anfrage vorgelegten Autorisierung variieren, da Anmeldedaten eine Eingabe pro Anfrage und kein Verbindungszustand sind.
Mit anderen Worten: Ein Server kann Ihnen nicht klammheimlich einen anderen Katalog zeigen, weil Sie früher in der Sitzung etwas anderes gefragt haben. Was variiert, ist das, was Ihre Anmeldedaten erlauben, nicht das, was Ihr Verlauf nahelegt.
Die Annotationen sind die eigentliche Gedächtnisrichtlinie
Wenn es einen Ort gibt, an dem "Gedächtnis" entschieden wird, dann hier. Ressourcen tragen optionale Annotationen, die Clients einen Hinweis darauf geben, wie sie zu verwenden sind:
audience: für wen der Inhalt bestimmt ist,"user","assistant"oder beide.priority: eine Zahl von 0.0 bis 1.0. Die Spezifikation ist ungewöhnlich deutlich zu den Enden dieser Skala: 1 bedeutet am wichtigsten, faktisch erforderlich, während 0 am unwichtigsten bedeutet, vollständig optional.lastModified: ein ISO-8601-Zeitstempel.
Clients nutzen diese, um nach Zielgruppe zu filtern, um zu priorisieren, welche Ressourcen in den Kontext aufgenommen werden, und um nach Aktualität zu sortieren.
Das ist der gesamte Mechanismus. Woran sich ein Agent "erinnert", ist das, was im Prioritätsfeld eines anderen hoch genug bewertet wurde, um das Kontextbudget zu überleben. Es gibt kein Abrufen, kein Vergessen, keine Konsolidierung. Es gibt eine sortierte Liste und eine Grenze.
Zwei Fehlerregeln, die die Designphilosophie offenlegen
Die Fehlerbehandlung der Spezifikation sagt etwas darüber aus, wie ernst sie Mehrdeutigkeit nimmt.
Eine fehlende Ressource muss einen JSON-RPC-Fehler zurückgeben, Code -32602. Und dann dies: Server dürfen nicht ein leeres contents-Array für eine nicht existierende Ressource zurückgeben, denn ein leeres Array ist mehrdeutig, es könnte bedeuten, dass die Ressource existiert, aber keinen Inhalt hat, oder dass sie überhaupt nicht existiert.
Ein Protokoll, das ausbuchstabiert, warum ein leeres Array inakzeptabel ist, ist ein Protokoll von Leuten, die Agenten debuggt haben. Stille Leere ist der Weg, auf dem ein Agent am Ende voller Überzeugung über eine Datei nachdenkt, die er nie gelesen hat.
Die Sicherheitsregeln, die Sie mit der Nutzung erben
Weil Ressourcen über URIs adressiert werden und oft auf Dateien verweisen, bringt die Spezifikation ausdrückliche Pflichten mit sich. Server müssen alle Ressourcen-URIs validieren. Sie müssen Dateipfade bereinigen, um Directory-Traversal-Angriffe zu verhindern, wenn sie file://-Ressourcen ausliefern. Für sensible Ressourcen sollten Zugriffskontrollen implementiert werden, und Berechtigungen sollten vor Operationen geprüft werden.
Das sind keine exotischen Anforderungen, und genau darum geht es. Ihr Dateisystem einem Modell über ein Protokoll zugänglich zu machen, ändert nichts daran, was ein Path Traversal ist. Es erhöht nur die Zahl derer, die am Seil ziehen.
Was das an Ihrem Denken über Agenten ändert
Hören Sie auf zu fragen, woran sich das Modell erinnert. Fragen Sie, welche Ressourcen die Host-Anwendung einzubeziehen beschlossen hat, mit welcher Priorität und unter welchen Anmeldedaten. Das ist die gesamte Antwort, und sie liegt in der Anwendung, nicht im Modell.
Persistenz ist eine Datei, keine Fähigkeit. Ein Agent, der sich über Sitzungen hinweg an Ihre Konventionen erinnert, liest ein Dokument, das etwas erneut bereitzustellen beschlossen hat. Ändern Sie die Bereitstellung, und das Gedächtnis ändert sich, sofort und vollständig.
Bei der Priorität findet das eigentliche Design statt. Ein Feld von 0.0 bis 1.0 entscheidet, was einen begrenzten Kontext überlebt. Diese Zahl, festgelegt von demjenigen, der den Server geschrieben hat, prägt das Verhalten eines Agenten stärker als das meiste Prompt Engineering.
Das Wort "Gedächtnis" bringt Erwartungen aus der menschlichen Kognition mit, die der Mechanismus nicht trägt. Was MCP tatsächlich spezifiziert, ist ein Katalog, eine Zugriffsrichtlinie und eine Rangfolge. Das zu wissen ist der Unterschied zwischen dem bewussten Entwerfen des Kontexts eines Agenten und dem Überraschtwerden davon.
Die hier gegebene Beschreibung von MCP-Ressourcen, einschließlich der anwendungsgesteuerten Designabsicht, der Aussage, dass das Protokoll kein Benutzerinteraktionsmodell vorschreibt, der resources-Capability mit listChanged und subscribe, der Einschränkung, dass die Ressourcenmenge nicht pro Verbindung variieren darf, während sie je nach Autorisierung variieren kann, der Annotationen audience, priority und lastModified, des Fehlercodes -32602, des Verbots, ein leeres contents-Array zurückzugeben, sowie der Anforderungen zur URI-Validierung und Pfadbereinigung, stammt aus der Spezifikation des Model Context Protocol, geprüft zum Zeitpunkt der Erstellung. Die Spezifikation entwickelt sich weiter; prüfen Sie die aktuelle Revision, bevor Sie sich auf ein bestimmtes Detail verlassen.
