Tutorial: Füge Sitzungen und Speicher zu einem bestehenden Agenten hinzu

Important

Dieses Feature befindet sich in der Betaversion.

Wenn du bereits einen Agenten in Python gebaut hast, kannst du ihm robuste Konversationshistorie und Langzeitspeicher auf Azure Databricks geben, ohne ihn umschreiben zu müssen. In diesem Tutorial verbinden Sie den Agenten mit einem Sitzungsspeicher, der jede Unterhaltung dauerhaft speichert, einem Memory-Speicher, der dauerhafte Fakten über Gespräche hinweg speichert, und einer Speicherpipeline, die die gespeicherten Gespräche in den Memory-Speicher verdichtet. Die Schritte umfassen Agenten, die mit dem OpenAI Agents SDK, LangGraph oder einem anderen Python-Framework gebaut wurden, egal wo der Agent eingesetzt wird.

Tip

Wenn du noch keinen Agenten hast, fang stattdessen mit dem Agent Bricks Quickstart an. Die Agent Bricks CLI erstellt einen neuen Agenten mit bereits eingerichteten Sitzungen und Speicher.

In diesem Beispiel sollte ein Support-Mitarbeiter das Gespräch eines Kunden dort fortsetzen, wo es aufgehört hat, und sich in späteren, separaten Gesprächen die Präferenzen des Kunden merken.

Wie Sitzungen und Speicher zusammenhängen, erfahren Sie unter Agentenspeicher und Sitzungen.

Requirements

  • Ein bestehender Agent, der in Python 3.10 oder höher geschrieben ist. Die framework-spezifischen Schritte umfassen das OpenAI Agents SDK und LangGraph. Die Schritte für andere Frameworks rufen direkt das AgentKit SDK auf.
  • Azure Databricks-Authentifizierung. Das AgentKit SDK verwendet die Standard-Authentifizierung des Databricks SDK für Python. Für die lokale Entwicklung führen Sie databricks auth login --host <workspace-url> aus, oder setzen Sie die Umgebungsvariablen DATABRICKS_TOKEN und DATABRICKS_HOST.
  • Verwenden Sie die Databricks CLI, um den Status der Speicherpipeline zu überprüfen.
  • Um eine Speicherpipeline zu erstellen, benötigen Sie die Berechtigung zur Abfrage des Modells, das die Pipeline verwendet, sowie die anderen in den Speicherpipeline-Anforderungen aufgeführten Zugriffe.

Schritt 1: Installieren Sie das AgentKit SDK und die Agent Bricks CLI

Das Paket databricks-agentbricks enthält Folgendes:

  • Das AgentKit SDK (databricks_agentkit), der Python-Client für Session- und Memory-Stores.
  • Agent Bricks CLI (agentbricks).
  • Adapter für das OpenAI Agents SDK und LangGraph, die die Session- und Memory-Stores mit den bestehenden Session- und Tool-Schnittstellen jedes Frameworks verbinden. Die Adapter verwenden die Framework-Pakete, die auf Ihrem Agenten bereits installiert sind.

Installieren Sie Version 0.6.0 oder höher in die Umgebung Ihres Agenten:

pip install --upgrade "databricks-agentbricks>=0.6.0"

Schritt 2: Erstellen Sie einen Session-Speicher und einen Memory-Store

Ihr Agent verwendet zwei Stores, die Azure Databricks für Sie verwaltet:

  • Ein Session Store speichert die Gesprächshistorie. Jede Sitzung darin ist das Transkript eines Gesprächs, das der Agent erneut lädt, um das Gespräch dort fortzusetzen, wo es aufgehört hat.
  • Ein Memory-Store enthält dauerhafte Fakten über jeden Nutzer, wie Präferenzen und bisherige Entscheidungen. Der Agent durchsucht es, um sich an das zu erinnern, was er in früheren, separaten Gesprächen erfahren hat.

Der Store ist die Sicherheitsgrenze: Jeder Principal mit Zugriff auf einen Store kann alle seine Einträge lesen und schreiben. Um die Mandanten voneinander zu isolieren, erstellen Sie für jeden Mandant ein separates Paar von Speichern. Siehe Partition und sicherer Speicher.

Erstelle jeden Store einmal und verwende ihn für jede Konversation wieder. Dein Agent nennt beide Stores beim Namen.

AgentKit SDK

from databricks.sdk import WorkspaceClient
from databricks_agentkit import AgentKitClient

client = AgentKitClient(WorkspaceClient())
client.session_stores.create("support-agent-sessions", description="Support agent conversations")
client.memory_stores.create("support-agent-memory", description="Support agent long-term memory")

Agent Bricks

agentbricks sessions stores create --name support-agent-sessions --description "Support agent conversations"
agentbricks memory stores create --display-name support-agent-memory --description "Support agent long-term memory"

REST API

Ersetzen Sie DATABRICKS_HOST durch den Hostnamen Ihres Arbeitsbereichs und führen Sie dann Folgendes aus:

export DATABRICKS_TOKEN=$(databricks auth token --profile <profile> | jq -r .access_token)

curl -X POST "https://${DATABRICKS_HOST}/api/2.0/agents/session-stores?session_store_id=support-agent-sessions" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" -H "Content-Type: application/json" \
  -d '{"description": "Support agent conversations"}'

curl -X POST "https://${DATABRICKS_HOST}/api/2.0/agents/memory-stores?managed_memory_store_id=support-agent-memory" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" -H "Content-Type: application/json" \
  -d '{"description": "Support agent long-term memory"}'

Store-IDs müssen im Arbeitsbereich eindeutig sein. Eine Speicher-ID muss 3 bis 56 Zeichen umfassen, mit einem kleinen Buchstabe beginnen, mit einem Buchstaben oder einer Zahl enden und nur Kleinbuchstaben, Zahlen und Bindestriche enthalten. Eine Session Store ID muss 3 bis 55 Zeichen umfassen.

Schritt 3: Wählen Sie Akteur- und Sitzungs-IDs

Jeder Anruf, den Ihr Agent in die Geschäfte tätigt, trägt zwei Kennungen:

  • actor_id identifiziert, wessen Gespräche und Erinnerungen es sind. Beide Speicher verwenden sie, und eine Speicherpipeline schreibt die Erinnerungen jedes Akteurs unter demselben actor_id wie die Sitzungen dieses Akteurs, sodass der Agent destillierte Erinnerungen nur dann abruft, wenn die beiden übereinstimmen.
  • session_id identifiziert ein Gespräch, sodass eine Folgeanfrage es fortsetzt.

Für dieses Tutorial verwenden test-user Sie als die actor_id und conversation-1 als die session_id. Die handle_message Funktionen in den folgenden Schritten verwenden sie als user_id und conversation_id.

In der Produktion sollte man actor_id im Anwendungscode aus einem vertrauenswürdigen Request-Kontext festlegen, etwa aus der verifizierten Identität des angemeldeten Benutzers, und niemals dem Modell oder der Nachricht eines Benutzers die Auswahl darüber überlassen. Um Speicher zwischen einem Team zu teilen oder Tenants zu isolieren, siehe Speicher partitionieren und sichern. Für session_id, verwenden Sie die bestehende Konversations- oder Thread-ID Ihrer App oder generieren Sie ein UUID, wenn ein Gespräch beginnt.

Schritt 4: Gespräche im Session Store speichern

Die Konversationshistorie ist die geordnete Aufzeichnung eines Gesprächs: die Nachrichten des Nutzers, die Antworten des Agenten sowie alle Tool-Anrufe und -Ergebnisse. Ein Session-Store speichert diese Historie für jede Unterhaltung, sodass der Agent sie bei der nächsten Anfrage erneut laden kann, auch nach einem Neustart. Ersetzen Sie den In-Process-Gesprächsverlauf Ihres Agenten durch den Session Store, den Sie in Schritt 2 erstellt haben.

Die Framework-Adapter werden in die Schnittstelle angeschlossen, die jedes Framework bereits für den Sitzungszustand verwendet, sodass das Modell, die Werkzeuge und die Prompts Ihres Agenten gleich bleiben.

OpenAI Agents SDK

Das OpenAI Agents SDK liest und schreibt den Gesprächsverlauf über ein Session Objekt. session_store() gibt ein Session zurück, das vom verwalteten Sitzungsspeicher unterstützt wird. Gib es an Runner.run:

from agents import Agent, Runner
from databricks_agentkit.openai import session_store

SESSION_STORE = "support-agent-sessions"

# Your existing agent, unchanged.
agent = Agent(name="Support agent", instructions="You help customers with their Databricks workspaces.")

async def handle_message(user_id: str, conversation_id: str, message: str) -> str:
    session = session_store(conversation_id, actor=user_id, store=SESSION_STORE)
    result = await Runner.run(agent, message, session=session)
    return result.final_output

Bei der ersten Nachricht eines Gesprächs erstellt der Adapter die Sitzung. Bei jedem Durchlauf lädt das SDK den Verlauf der Konversation aus der Sitzung und fügt die neue Benutzernachricht, Modellausgabe und Werkzeugelemente hinzu.

LangGraph

LangGraph persistiert den Graphzustand über einen Checkpointer mit einer Thread-ID als Schlüssel. checkpointer() gibt einen Checkpointer zurück, der vom verwalteten Sitzungsspeicher unterstützt wird, und thread_config() ordnet eine Konversation und ihren Benutzer einem Thread zu:

from langchain.agents import create_agent
from databricks_agentkit.langgraph import checkpointer, thread_config

SESSION_STORE = "support-agent-sessions"

# Your existing model and tools, unchanged, with the managed checkpointer added.
agent = create_agent(model=model, tools=tools, checkpointer=checkpointer(store=SESSION_STORE))

async def handle_message(user_id: str, conversation_id: str, message: str) -> str:
    result = await agent.ainvoke(
        {"messages": [{"role": "user", "content": message}]},
        config=thread_config(conversation_id, actor=user_id),
    )
    return result["messages"][-1].content

Wenn Ihr Agent bereits einen Checkpointer verwendet, ersetzen Sie ihn durch checkpointer(). Wenn du direkt einen StateGraph baust, gib den Checkpointer an compile(). Der Checkpointer speichert den vollständigen Graphenzustand, einschließlich Human-in-the-Loop-Interrupts, sodass ein pausierter Lauf nach einem Neustart fortgesetzt werden kann.

Note

Der Checkpointer speichert serialisierte Graph-Checkpoints, die eine Speicherpipeline nicht liest. Um eine Speicherpipeline mit einem LangGraph-Agenten zu verwenden, zeichnen Sie auch ein Transkript auf.

Andere Frameworks

Für jedes andere Framework oder für direkte Modellaufrufe lesen und hängen Sie den Gesprächsverlauf mit dem AgentKit SDK an. Speichere jede Nachricht als {"type": "message", "role": "user" | "assistant", "content": "<text>"}. Eine Memory-Pipeline destilliert Benutzer- und Assistenten-Nachrichten in dieser Form und in der OpenAI Responses-Nachrichtenform mit Textinhaltsteilen. Es überspringt alle anderen Elemente, wie Werkzeugaufrufe und Werkzeugergebnisse.

from databricks.sdk import WorkspaceClient
from databricks_agentkit import AgentKitClient

client = AgentKitClient(WorkspaceClient())
session_store = client.session_stores.get("support-agent-sessions")

def start_conversation(user_id: str, conversation_id: str) -> None:
    session_store.add(actor_id=user_id, session_id=conversation_id)

def handle_message(user_id: str, conversation_id: str, message: str) -> str:
    session = session_store.get(conversation_id)
    if session.actor_id != user_id:
        raise PermissionError("This conversation belongs to a different user.")

    # Rebuild context from the stored history, oldest first.
    history = [item.data for item in session.list_items(order_by="create_time asc")]
    user_item = {"type": "message", "role": "user", "content": message}
    reply = run_agent([*history, user_item])  # Your framework or model call.

    session.append_items([user_item, {"type": "message", "role": "assistant", "content": reply}])
    return reply

Das Nachschlagen einer Sitzung nach session_id ist nicht auf einen Akteur beschränkt, also prüfe, ob die Sitzung dem anfordernden Benutzer gehört, bevor du sie fortsetzt.

Der Wechsel zum Session Store verschiebt keine Gespräche, die dein Agent anderswo gespeichert hat. Um ein bestehendes Gespräch weiterzuführen, fügen Sie seine Elemente einer neuen Sitzung hinzu.

Schritt 5: Geben Sie dem Agenten ein Gedächtnis

Der Sitzungsverlauf umfasst eine Konversation. Um das, was der Agent in früheren Gesprächen gelernt hat, zu nutzen, verbinden Sie den Agenten mit dem Memory-Store. Es gibt zwei Muster, die man kombinieren kann:

  • Speicherwerkzeuge: Das Modell entscheidet, wann es Speicher abruft und wann es eine neue Tatsache speichert.
  • Abruf vor jeder Ausführung: Ihre Anwendung sucht im Speicher nach der eingehenden Nachricht und fügt die Ergebnisse dem Kontext des Agenten hinzu, sodass der Agent den relevanten Speicher sieht, ohne ein Werkzeug aufzurufen.

Wenn eine Speicherpipeline in Ihren Speicher schreibt (siehe Schritt 6), muss der Agent nur den Speicher abrufen. Sie können Werkzeuge überspringen, die Speicher belegen.

OpenAI Agents SDK

Das folgende Beispiel verwendet beide Muster in einer Kopie pro Anfrage Ihres Agenten:

  • memory_tools() gibt vier Werkzeuge zurück: recall Durchsucht das Gedächtnis des Benutzers, remember speichert eine Tatsache unter einem Thema, forget entfernt eine Tatsache und list_memories listet auf, was gespeichert ist. Die Werkzeuge sind an einen Akteur gebunden, sodass das Modell den Speicher eines anderen Benutzers nicht lesen oder schreiben kann.
  • recalled_facts() sucht im Speicher nach der eingehenden Nachricht vor der Ausführung und fügt die Ergebnisse den Anweisungen des Agenten hinzu.
from databricks.sdk import WorkspaceClient
from databricks_agentkit import AgentKitClient
from databricks_agentkit.openai import memory_tools, session_store

MEMORY_STORE = "support-agent-memory"
memory_store = AgentKitClient(WorkspaceClient()).memory_stores.get(MEMORY_STORE)

def recalled_facts(user_id: str, message: str) -> str:
    results = memory_store.search(actor_id=user_id, query=message, limit=5)
    return "\n".join(f"- {r.memory.content}" for r in results)

async def handle_message(user_id: str, conversation_id: str, message: str) -> str:
    instructions = agent.instructions  # Your agent's existing instructions, as a string.
    if facts := recalled_facts(user_id, message):  # Recall before the run.
        instructions += f"\n\nWhat you know about this user:\n{facts}"
    user_agent = agent.clone(
        instructions=instructions,
        tools=[*agent.tools, *memory_tools(user_id, store=MEMORY_STORE)],  # Memory tools.
    )
    session = session_store(conversation_id, actor=user_id, store=SESSION_STORE)
    result = await Runner.run(user_agent, message, session=session)
    return result.final_output

Die zurückgerufenen Fakten kommen in die Anweisungen, nicht in die Eingabe, sodass die Sitzung sie nicht speichert. Um nur ein Muster zu verwenden, lassen Sie das andere weg: Entfernen Sie die memory_tools() Zeile oder entfernen Sie den recalled_facts() Aufruf. Wenn du die Tools behältst, aktualisiere die Anweisungen deines Agenten, um ihm zu sagen, wann er sie verwenden soll, zum Beispiel: „Nutze recall, um die Einstellungen des Nutzers nachzuschlagen, bevor du antwortest.“ Verwenden Sie „Erinnern“, um dauerhafte Informationen zu speichern, die der Nutzer teilt. Verwende 'forget', wenn der Nutzer dich bittet, etwas zu vergessen.

LangGraph

Das folgende Beispiel verwendet beide Muster und erstellt den Agenten für jede Anfrage. Der Checkpointer wird einmal erstellt und geteilt:

  • memory_tools() gibt vier Werkzeuge zurück: recall Durchsucht das Gedächtnis des Benutzers, remember speichert eine Tatsache unter einem Thema, forget entfernt eine Tatsache und list_memories listet auf, was gespeichert ist. Die Werkzeuge sind an einen Akteur gebunden, sodass das Modell den Speicher eines anderen Benutzers nicht lesen oder schreiben kann.
  • recalled_facts() sucht im Speicher nach der eingehenden Nachricht vor dem Ausführen und fügt die Ergebnisse dem System-Prompt hinzu.
from databricks.sdk import WorkspaceClient
from databricks_agentkit import AgentKitClient
from langchain.agents import create_agent
from databricks_agentkit.langgraph import checkpointer, memory_tools, thread_config

MEMORY_STORE = "support-agent-memory"
memory_store = AgentKitClient(WorkspaceClient()).memory_stores.get(MEMORY_STORE)

def recalled_facts(user_id: str, message: str) -> str:
    results = memory_store.search(actor_id=user_id, query=message, limit=5)
    return "\n".join(f"- {r.memory.content}" for r in results)

async def handle_message(user_id: str, conversation_id: str, message: str) -> str:
    system_prompt = SYSTEM_PROMPT  # Tell the agent when to use the memory tools.
    if facts := recalled_facts(user_id, message):  # Recall before the run.
        system_prompt += f"\n\nWhat you know about this user:\n{facts}"
    agent = create_agent(
        model=model,
        tools=[*tools, *memory_tools(user_id, store=MEMORY_STORE)],  # Memory tools.
        system_prompt=system_prompt,
        checkpointer=checkpointer(store=SESSION_STORE),
    )
    result = await agent.ainvoke(
        {"messages": [{"role": "user", "content": message}]},
        config=thread_config(conversation_id, actor=user_id),
    )
    return result["messages"][-1].content

LangGraph fügt die Systemaufforderung zu jedem Modellaufruf hinzu, ohne sie im Graphzustand zu speichern, sodass der Checkpointer die abgerufenen Fakten nicht speichert. Um nur ein Muster zu verwenden, lassen Sie das andere weg: Entfernen Sie die memory_tools() Zeile oder entfernen Sie den recalled_facts() Aufruf.

Andere Frameworks

Durchsuchen Sie vor jedem Durchlauf den Speicher nach der eingehenden Nachricht und geben Sie die Ergebnisse als Kontext an den Agenten weiter. Die Suche stimmt sowohl bei Schlüsselwörtern als auch bei der Bedeutung überein, sodass die Nachricht des Nutzers gut als die Anfrage funktioniert.

memory_store = client.memory_stores.get("support-agent-memory")

def recall(user_id: str, message: str) -> list[dict]:
    results = memory_store.search(actor_id=user_id, query=message, limit=5)
    if not results:
        return []
    facts = "\n".join(f"- {r.memory.content}" for r in results)
    return [{"role": "system", "content": f"What you know about this user:\n{facts}"}]

In handle_message aus Schritt 4 fügen Sie den abgerufenen Kontext zur Eingabe des Agenten hinzu. Füge es nicht der Sitzung an:

reply = run_agent([*recall(user_id, message), *history, user_item])

Damit der Agent selbst Speicher sichern kann, packen Sie die search und add Operationen des Speichers als Werkzeuge für Ihr Framework ein. Siehe Geben Sie Ihrem Agenten Speicherwerkzeuge.

Schritt 6: Erstellen Sie eine Speicherpipeline

Eine Speicherpipeline liest die Gespräche in Ihrem Sitzungsspeicher und destilliert dauerhafte Fakten, Präferenzen und Entscheidungen für jeden Akteur in den Memory-Store. Außerdem werden überlappende Einträge im Laufe der Zeit zusammengeführt, sodass der Speicher deines Agenten ohne zusätzlichen Agentencode konsolidiert bleibt.

  1. Erstellen Sie eine Pipeline, die die beiden Stores verbindet:

    agentbricks memory pipeline create \
  --session-store support-agent-sessions \
  --memory-store support-agent-memory \
  --trigger scheduled \
  --model system.ai.claude-sonnet-5 \
  --instructions "Focus on durable customer preferences and account details. Ignore one-off troubleshooting steps."
    • --trigger scheduled führt die Pipeline etwa alle 24 Stunden automatisch aus. Ohne sie verwendet die Pipeline den Standard-Trigger manual und wird nur ausgeführt, wenn Sie eine Ausführung starten. Siehe Ausführen einer Pipeline nach Zeitplan.
    • --model legt das Modell fest, das Erinnerungen destilliert. Du kannst jedes Modell verwenden, für das du die Berechtigung hast, es abzufragen. Wenn du --model weglässt, verwendet die Pipeline ein Standardmodell, das Azure Databricks wählt.
    • --instructions ist optional und bestimmt, was die Pipeline behält. Siehe Destillation mit Anleitungen steuern.

    Der Befehl gibt den Ressourcennamen der Pipeline in der Form memory-pipelines/<pipeline-id>zurück. Für jede Option führen Sie aus oder lesen Sie die agentbricks memory pipeline create --help.

  2. Der Scheduler wählt, wann der erste geplante Lauf beginnt. Um die bereits im Sitzungsspeicher vorhandenen Konversationen zusammenzufassen, starten Sie jetzt eine Ausführung:

    agentbricks memory pipeline run <pipeline-id>

    Der Befehl gibt den Ressourcennamen des Laufs in der Form memory-pipelines/<pipeline-id>/runs/<run-id>zurück.

  3. Überprüfen Sie das Ergebnis des Laufs mit der REST-API. Ersetzen Sie DATABRICKS_HOST durch den Hostnamen Ihres Arbeitsbereichs und führen Sie dann Folgendes aus:

    export DATABRICKS_TOKEN=$(databricks auth token --profile <profile> | jq -r .access_token)
curl "https://${DATABRICKS_HOST}/api/2.0/agents/memory-pipelines/<pipeline-id>/runs/<run-id>" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}"

    Wenn der Status der Ausführung stateSUCCEEDED ist, befinden sich die destillierten Erinnerungen im Speicher.

Pipeline-Läufe verwenden die Identität, die die Pipeline erstellt hat, nicht die Identität deines Agenten. Eine Pipeline kann jeden Eintrag unter einem actor_id, das sie verarbeitet, umschreiben, zusammenführen oder löschen, einschließlich Einträgen, die Ihr Agent mit Speicherwerkzeugen gespeichert hat. Für die REST-API, Laufzeitzustände und Einschränkungen siehe Agent-Speicherpipelines.

Zeichnen Sie ein Transkript für LangGraph-Agenten auf

Eine Speicherpipeline destilliert nur Benutzer- und Assistentennachrichten. Der LangGraph-Checkpointer speichert serialisierte Checkpoints, sodass eine Pipeline, die den Sitzungsspeicher des Checkpointers liest, keine Nachrichten zum Destillieren findet. Um eine Pipeline mit einem LangGraph-Agenten zu verwenden, fügen Sie außerdem die Nachrichten jeder Runde einem separaten Session-Speicher an und erstellen Sie die Pipeline auf diesem Speicher:

transcripts = client.session_stores.create("support-agent-transcripts")  # Create once.

def start_conversation(user_id: str, conversation_id: str) -> None:
    transcripts.add(actor_id=user_id, session_id=conversation_id)

def record_turn(conversation_id: str, message: str, reply: str) -> None:
    transcripts.get(conversation_id).append_items(
        [
            {"type": "message", "role": "user", "content": message},
            {"type": "message", "role": "assistant", "content": reply},
        ]
    )

Rufen Sie start_conversation auf, wenn ein Gespräch anfängt, vor dem ersten ainvoke, und rufen Sie record_turn nach jedem ainvoke auf. Übergeben Sie --session-store support-agent-transcripts, wenn Sie die Pipeline erstellen. Alternativ überspringen Sie die Pipeline und lassen Sie den Agenten mithilfe von Speicherwerkzeugen Erinnerungen speichern.

Schritt 7: Gewähren Sie Ihrem eingesetzten Agenten Zugriff

Wenn du den Agenten lokal ausführst, verwendet er deine eigenen Zugangsdaten. Ein bereitgestellter Agent wird in der Regel als Dienstprinzipal ausgeführt, der Zugriff auf jeden Speicher benötigt, aus dem er Daten liest oder in den er schreibt. Gewähren Sie Zugriff mit dem AgentKit SDK, wobei die Anwendungs-(Client-)ID des Service-Principals weitergegeben wird:

from databricks.sdk import WorkspaceClient
from databricks_agentkit import AgentKitClient

w = WorkspaceClient()
client = AgentKitClient(w)

# For an agent deployed as a Databricks app, look up the app's service principal.
sp_client_id = w.apps.get("support-agent").service_principal_client_id

client.session_stores.get("support-agent-sessions").grant_permission(sp_client_id)
client.memory_stores.get("support-agent-memory").grant_permission(sp_client_id)

grant_permission gewährt standardmäßig Schreibzugriff. Um Lesezugriff zu gewähren, übergeben Sie permission="READ". Wenn du einen Transkript-Store für einen LangGraph-Agenten erstellt hast, gewähre auch Zugriff darauf. Die Speicherpipeline benötigt keine Berechtigung für den Dienstprinzipal Ihres Agenten, weil Pipeline-Ausführungen die Identität verwenden, die die Pipeline erstellt hat.

Schritt 8: Testen Sie den Agenten von Anfang zu Ende

  1. Rufen Sie handle_message mit user_id="test-user" und conversation_id="conversation-1"an und teilen Sie eine dauerhafte Präferenz, wie zum Beispiel: "Ich bevorzuge E-Mail statt Telefon und bin in der Pazifikzeitzone." Wenn Sie die Schritte für andere Frameworks befolgt haben, rufen start_conversation("test-user", "conversation-1") Sie zuerst an. Senden Sie im selben Gespräch eine Folgenachricht und bestätigen, dass der Agent den vorherigen Kontext hat.

  2. Bestätigen Sie, dass der Session Store die Konversation speichert:

    agentbricks sessions items list --store support-agent-sessions --session-id conversation-1

  3. Starten Sie eine Speicherpipeline-Ausführung und warten Sie, bis ihr state ist SUCCEEDED, wie in Schritt 6.

  4. Bestätigen Sie, dass der Memory Store die Präferenz für den Testbenutzer enthält:

    agentbricks memory entries search --store support-agent-memory --actor-id test-user --query "contact preferences"

  5. Starte ein neues Gespräch für test-user mit conversation_id="conversation-2"und frage: "Wie solltest du mich kontaktieren?" Der Agent antwortet aus dem Gedächtnis.

Troubleshooting

  • PERMISSION_DENIED (HTTP 403) vom eingesetzten Agenten stammt. Der Dienstprinzipal des Agenten hat keinen Zugriff auf einen Speicher. Gewähren Sie ihm Zugang, wie in Schritt 7.
  • Ein Pipeline-Run gelingt, schreibt aber keine Einträge. Bestätigen Sie, dass der Session Store Benutzer- und Assistenten-Nachrichten in einer Struktur speichert, die die Pipeline liest. Eine Pipeline überspringt Werkzeugaufrufe, Werkzeugergebnisse und LangGraph-Checkpoints. Ein Run verarbeitet nur die Turns, die seit dem Checkpoint des Akteurs hinzugefügt wurden, und Turns aus den letzten 60 Sekunden warten auf den nächsten Run.
  • Der Agent erinnert sich nicht an Distilled Memories. Bestätigen Sie, dass der Agent den Speicher mit demselben actor_id durchsucht, das seine Sitzungen verwenden.
  • Der Start eines Durchlaufs schlägt mit ABORTED fehl. Ein weiterer Durchlauf der Pipeline ist im Gange. Warte, bis es fertig ist, und starte dann einen neuen Durchlauf.

Aufräumen

Um die von diesem Tutorial erstellten Ressourcen zu löschen, führen Sie Folgendes aus. Das Löschen eines Speichers löscht alle Inhalte darin.

agentbricks memory pipeline delete <pipeline-id>
agentbricks sessions stores delete support-agent-sessions
agentbricks memory stores delete support-agent-memory

Nächste Schritte

  • Zuletzt aktualisiert um