Referenzleitfaden

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

In dieser umfassenden Referenz finden Sie schnell detaillierte Informationen zu jeder Komponente des Agent-Frameworks.

Ordnerstruktur

Wenn Sie einen Agenten erstellen möchten, erstellen Sie einen Ordner für diesen Agenten, der nach dem Agenten benannt ist und mindestens die folgenden Dateien enthält:

• agent.py: Die Hauptdatei für den Agenten. Sie müssen den Root-Agenten unter der globalen Variablen root_agent definieren.
• __init__.py: Die Python-Moduldatei. Sie muss mindestens eine Zeile from agents import Agent enthalten, um die Klasse Agent zu importieren.

Optional können Sie die folgenden Dateien hinzufügen:

• requirements.txt: Die Python-Anforderungendatei für den Agenten.
• README.md: Die README-Datei für den Agenten. Sie sollte eine Anleitung zum Einrichten und Ausführen des Agents enthalten.

Minimale agent.py

Das Erstellen eines Bots beginnt mit dem Erstellen einer Instanz der Klasse Agent. Der Agent muss mindestens die folgenden Attribute haben:

• name: Der Name des Kundenservicemitarbeiters.
• model: Der Name des zu verwendenden LLM-Modells.
• instruction: Anweisungen in natürlicher Sprache für den Kundenservicemitarbeiter.

Beispiel:

from agents import Agent

root_agent = Agent(
    model='gemini-1.5-flash',
    name='root_agent',
    instruction="Be polite and answer all users' questions.",
)

Wenn Sie einen minimalen Agenten erstellen möchten, können Sie den Ordner _empty_agent kopieren und die Datei agent.py ändern.

Attribute

Name

  name: str

Der Name des Agents.

• Bezeichner

  • Der Name muss der Benennungskonvention für Kennungen entsprechen.
  • Ein String gilt als gültige Kennung, wenn er nur alphanumerische Buchstaben (a–z) und (0–9) oder Unterstriche (_) enthält. Ein gültiger Bezeichner darf nicht mit einer Zahl beginnen und keine Leerzeichen enthalten.

• Einzigartig

  • Der Name muss innerhalb des gesamten Kundenservicemitarbeiter-Baums eindeutig sein.

• Root-Agent

  • Die Variable des Stamm-Agenten muss root_agent heißen, Sie können aber ein aussagekräftigeres Namensattribut für den Stamm-Agenten festlegen.

Modell

  model: str

Der Name des zu verwendenden LLM-Modells.

• Erforderlich für LLM-Agent

  • Das Attribut „model“ ist nur für den LLM-Agenten erforderlich.
  • Sie müssen das Modellattribut nicht für sequenzielle, Loop- oder andere nicht LLM-Agenten festlegen.

• Übergeordneter Kundenservicemitarbeiter

  • Sie können das Modellattribut weglassen. In diesem Fall verwendet der Agent das Modellattribut des übergeordneten Agents.

• Format

  • Das Format des Modellnamens variiert je nach Anbieter des LLM.
  • Bei Gemini sieht es so aus: gemini-1.5-flash oder gemini-2.0-flash-exp.
  • Für Anthropic in Vertex sieht es so aus: claude-3-5-sonnet-v2@20241022
  • Das Framework ist zwar für jeden Modellanbieter geeignet, wir unterstützen derzeit aber nur Gemini und Anthropic auf Vertex.

Anweisung

  instruction: str | InstructionProvider

Die Anweisungen in natürlicher Sprache für den Agenten.

• Erforderlich für LLM-Agent

  • Die Anleitung ist nur für den LLM-Agenten erforderlich.
  • Sie müssen das Attribut „instruction“ nicht für sequenzielle, Schleifen- oder andere nicht LLM-Agenten festlegen.

• Datentyp

  • Die Anweisung kann ein String sein.
  • Die Anweisung kann auch ein aufrufbarer InstructionProvider sein.

• InstructionProvider

  • Ein InstructionProvider ist definiert als Callable[[InvocationContext], str].
  • Sie können eine Funktion angeben, um die Anweisung dynamisch basierend auf dem Aufrufkontext zu generieren.

• Bundesland

  • Die Anweisung ist eine Stringvorlage. Mit der Syntax {var} können Sie dynamische Werte in die Anweisung einfügen.

  var

  wird verwendet, um den Wert der Zustandsvariablen namens „var“ einzufügen.

  artifact.var

  wird verwendet, um den Textinhalt des Artefakts namens „var“ einzufügen.
  • Wenn die Statusvariable oder das Artefakt nicht vorhanden ist, meldet der Agent einen Fehler. Wenn Sie den Fehler ignorieren möchten, können Sie dem Variablennamen ein ? anhängen, z.B. {var?}.

• Richtlinien

  • Geben Sie zuerst an, wer der Bot ist, was er kann und was nicht.
  • Sie können das Markdown-Format verwenden, um die Richtlinien sowohl für Menschen als auch für das Modell besser lesbar zu machen.
  • Wenn der Kunde mehrere Aufgaben erledigen kann, geben Sie ihm eine Liste mit Aufgaben und fügen Sie für jede Aufgabe einen separaten Abschnitt hinzu.
  • Wenn eine Aufgabe mehrere Schritte umfasst, geben Sie eine Liste der Schritte und eine detaillierte Anleitung für jeden Schritt an.
  • Wenn der Kundenservicemitarbeiter Tools verwenden kann, führe sie unter dem Attribut tools auf. Die Tooldefinition enthält eine Anleitung zur Verwendung. Um die Leistung zu verbessern, können der Anleitung für Kundenservicemitarbeiter jedoch detaillierte Anweisungen hinzugefügt werden, wann die Tools verwendet werden sollen.
  • Beschreiben Sie für ein Mehrfachagentensystem, wann die Weiterleitung an den anderen Agenten erfolgen soll.
  • Sie können in der Anleitung Beispiele für Eingaben und erwartete Ausgaben angeben. Sie können auch das Attribut examples verwenden, um Beispiele anzugeben.
  • Die Anleitung muss ausführlich und präzise sein. Behandle den Kundenservicemitarbeiter wie einen neuen Mitarbeiter, der sich in der Einarbeitungsphase befindet.
  • Verlassen Sie sich nicht auf Anleitungen zu Regeln, die zu 100% befolgt werden müssen. Das Modell hat von Natur aus einen gewissen Grad an Freiheit und kann Fehler machen. Verwenden Sie Tools und Rückrufe, um strenge Regeln durchzusetzen.

description

  description: str

Beschreibt, was dieser Agent tun kann. Diese Beschreibung wird als Teil der Systemanweisungen an das Modell gesendet:

1. Der Bot selbst versteht seine eigenen Fähigkeiten anhand der Beschreibung.

2. Ein Kundenservicemitarbeiter weiß, was andere Kundenservicemitarbeiter tun können, und entscheidet anhand der Beschreibungen, ob er den Fall weiterleitet.

global_instruction

  global_instruction: str | InstructionProvider

Die globale Anweisung für den gesamten Agenten-Baum.

Eine Anweisung teilt einem bestimmten Kundenservicemitarbeiter mit, was er tun soll und wie er es tun soll. Die globale Anweisung gilt für alle Kundenservicemitarbeiter im gesamten Kundenservicemitarbeiter-Baum.

Die Verwendung der globalen Anweisung ähnelt der des Anweisungsattributs, einschließlich des Datentyps, der Unterstützung von InstructionProvider und der Möglichkeit, auf Statusvariablen und Artefakte zuzugreifen.

• Identität und Verhalten
  • Mit globalen Anweisungen legen Sie die Identität und das Verhalten/den Standard für den gesamten Agenten-Baum fest, nicht wie eine bestimmte Aufgabe für einen bestimmten Agenten ausgeführt werden soll.

generate_content_config

  generate_content_config: google.genai.types.GenerateContentConfig

Zusätzliche Modellkonfiguration für den Agenten. Diese werden in die Anfrage an das Modell eingefügt.

Einige Attribute sollten Sie in diesem Feld nicht festlegen, da sie vom Framework verwaltet werden: – tools – system_instruction – response_schema

Beispiele

  examples: list[Example] | BaseExampleProvider

Die Few-Shot-Beispiele für den Bot. Studien haben gezeigt, dass sich die Leistung des Agents durch die Bereitstellung von Few-Shot-Beispielen verbessern lässt.

• Statische Beispiele
  • Sie können eine Liste mit statischen Beispielen angeben. Ein Beispiel ist so definiert, wobei input der Eingabeinhalt und output der erwartete Ausgabeinhalt ist.

class Example(BaseModel):
  input: types.Content
  output: list[types.Content]

• Liste der Ausgaben

  • Die Ausgabe kann eine Liste von Content sein.
  • So können Sie eine Sequenz von Inhalten als erwartete Ausgabe definieren. Das Modell sollte beispielsweise zuerst einen Funktionsaufruf ausführen und dann Text generieren.

• BaseExampleProvider

  • Sie können auch eine Instanz der Klasse BaseExampleProvider angeben.
  • Die Klasse BaseExampleProvider hat eine Methode get_examples(query: str) und gibt eine Liste von Example zurück.
  • Mit dem BaseExampleProvider können Sie die Beispiele dynamisch basierend auf der Abfrage generieren.

greeting_prompt

  greeting_prompt: str

Sie können einen Prompt festlegen, der an das Modell gesendet wird, um eine Begrüßungsnachricht zu generieren. Die Begrüßungsaufforderung wird verwendet, wenn Sie den Kundenservicemitarbeiter mit einer leeren Sitzung und einer leeren Nutzereingabe anrufen.

Planung

  planning: bool

Wenn Sie planning auf „True“ setzen, wird der Planungsmodus für den Kundenservicemitarbeiter aktiviert. Im Planungsmodus erstellt der Kundenservicemitarbeiter zuerst einen Plan, um die Nutzeranfrage zu beantworten, und führt ihn dann Schritt für Schritt aus.

code_executor

  code_executor: BaseCodeExecutor

Der von Ihnen erstellte Agent kann Probleme lösen, indem er Code schreibt und ausführt.

Es gibt zwei Möglichkeiten, die Codeausführung zu aktivieren:

1. Einige Modelle können Code direkt ausführen. Das Gemini 2.0-Modell im Live-Modus generiert und führt beispielsweise Code automatisch aus, ohne dass ein separates Tool zur Codeausführung erforderlich ist.

2. Sie können das code_executor-Attribut auf eine Instanz der Klasse BaseCodeExecutor festlegen, um die Codeausführung zu aktivieren. Derzeit gibt es die Klassen VertexCodeExecutor und UnsafeLocalCodeExecutor. Da von LLM generierter Code verheerend sein kann, sollten Sie UnsafeLocalCodeExecutor nur für das Prototyping verwenden. Mit diesen Klassen können Sie Code in Vertex AI ausführen. In Zukunft werden weitere Codeausführer hinzugefügt.

input_schema

  input_schema: type[BaseModel]

Der Agent erzwingt das Eingabeschema, wenn Sie ein Pydantic-Modell als input_schema angeben. Der Eingabeinhalt muss ein JSON-String sein, der dem Schema entspricht.

output_schema

  output_schema: type[BaseModel]

Der Agent erzwingt das Ausgabeschema, wenn Sie ein Pydantic-Modell als output_schema angeben. Der Ausgabeinhalt ist immer ein JSON-String, der dem Schema entspricht.

output_key

  output_key: str

Der Agent speichert seine Ausgabe in der Statusvariablen unter dem Namen, der durch das output_key-Attribut angegeben ist.

include_contents

  include_contents: Literal['default', 'none']

Der Kundenservicemitarbeiter fügt standardmäßig den Inhalt des Sitzungsverlaufs (Chatverlauf) hinzu. Sie können das Attribut include_contents auf none festlegen, um dieses Verhalten zu deaktivieren. In diesem Fall sieht der jeweilige Kundenservicemitarbeiter den Chatverlauf nicht. Das ist nützlich, wenn der Kundenservicemitarbeiter den Chatverlauf nicht sehen muss.

Tools

Die Möglichkeit, Tools zu verwenden, unterscheidet Kundenservicemitarbeiter von einem reinen Modell. Genauso wie die Fähigkeit, Werkzeuge auf komplexe und vielseitige Weise zu verwenden, als eine definierende Eigenschaft von Menschen gilt.

Im Kundenservice-Framework weisen Sie Ihrem Kundenservicemitarbeiter über das tools-Attribut Tools zu. Das tools-Attribut ist eine Liste von Tools. Jedes Tool kann Folgendes sein:

• Eine Python-Funktion.
• Eine Klasse, die die Klasse BaseTool implementiert.

Python-Funktionstool

Sie können eine Python-Funktion als Tool definieren.

• Parameter

  • Ihre Funktion kann beliebig viele Parameter haben.
  • Jeder Parameter kann beliebigen Typen haben, solange der Typ JSON-serialisierbar ist.
  • Legen Sie keinen Standardwert für Ihre Parameter fest, da diese vom Modell nicht unterstützt werden.

• Rückgabetyp

  • Der Rückgabetyp muss ein Dictionary sein.
  • Wenn Sie etwas zurückgeben, das keine Dictionary-Instanz ist, wird es vom Framework in eine Dictionary-Instanz mit dem einzelnen Schlüssel result verpackt.
  • Formulieren Sie den Rückgabewert möglichst aussagekräftig. Gib beispielsweise statt eines numerischen Fehlercodes einen error_message: str mit einer menschenlesbaren Fehlermeldung zurück. Denken Sie daran, dass dieser Rückgabewert vom Modell gelesen und verstanden werden muss, nicht von einem Code ausgeführt.
  • Es empfiehlt sich, einen status-Schlüssel für success, error, pending usw. zu verwenden, damit das Modell den allgemeinen Status der Operation kennt.

• Docstring

  • Die Docstring der Funktion wird als Toolbeschreibung verwendet und an das Modell gesendet. Je besser die Docstring ist, desto besser kann das Modell das Tool nutzen.

• Einfachheit

  • Sie haben zwar viel Freiheit bei der Definition Ihrer Funktion, sollten sie aber einfach und prägnant halten, damit das Modell sie genauer verwenden kann.
  • Weniger Parameter sind besser als viele Parameter.
  • Verwenden Sie nach Möglichkeit einfache Datentypen wie str oder int anstelle von benutzerdefinierten Klassen.
  • Der Name der Funktion und die Parameter sind sehr wichtig. Wenn Sie eine Funktion namens do_stuff() haben, lehnt das Modell sie möglicherweise trotzdem ab, auch wenn Sie ihm mitteilen, dass sie zum Stornieren eines Flugs verwendet wird.
  • Teilen Sie komplexe Funktionen in kleinere auf. Beispiel: Trennen Sie update_profile(profile: Profile) in update_name(name: str), update_age(age: int) usw.

• Referenz in der Anleitung

  • Sie können in der Anleitung auf das Tool verweisen, indem Sie seinen Namen verwenden.
  • Wenn der Name und die Docstring der Funktion ausreichend detailliert sind, können Sie sich in der Anleitung nur darauf konzentrieren, wann das Tool verwendet werden soll.
  • Erkläre dem Kundenservicemitarbeiter, wie er mit verschiedenen Rückgabewerten umgehen soll. Wenn das Tool beispielsweise eine Fehlermeldung zurückgibt, sollte der Kundenservicemitarbeiter aufgeben, es noch einmal versuchen oder nach weiteren Informationen fragen?
  • Tools können nacheinander verwendet werden, wobei ein Tool von der Ausgabe eines anderen Tools abhängen kann. Beschreiben Sie die Abfolge in der Anleitung.

Toolkontext

Sie können Ihrer Toolfunktion einen speziellen Parameter tool_context: ToolContext hinzufügen, um zusätzliche Informationen zum Kontext zu erhalten, in dem das Tool aufgerufen wird.

Die Klasse ToolContext befindet sich im Modul agents.types und hat die folgenden Attribute:

• function_call_event_id: str
  • Die ID des Ereignisses, bei dem der Toolaufruf ausgelöst wird.
• function_call_id: str
  • Die ID des Funktionsaufrufs.
• state: State
  • Ein dict-ähnliches Objekt zum Lesen und Aktualisieren der Statusvariablen.
• actions: EventActions
  • Zusätzliche Aktionen, die das Tool ausführen kann.

Die Klasse EventActions befindet sich im Modul agents.events und hat die folgenden Attribute, damit das Tool zusätzliche Aktionen ausführen kann:

• skip_summarization: bool
  • Wenn diese Option auf „True“ gesetzt ist, überspringt das Framework den Schritt der Zusammenfassung für das Ereignis, bei dem das Tool aufgerufen wird.
• transfer_to_agent: str
  • Wenn das Attribut festgelegt ist, wird der Fall an den Kundenservicemitarbeiter mit dem vom transfer_to_agent-Attribut angegebenen Namen weitergeleitet.
• escalate: bool
  • Wenn diese Option auf „True“ gesetzt ist, eskaliert der Kundenservicemitarbeiter die Anfrage an den übergeordneten Kundenservicemitarbeiter. Eine Eskalierung von einem untergeordneten Kundenservicemitarbeiter innerhalb eines LoopFlows bedeutet das Ende der Schleife.

AsyncFunctionTool

AsyncFunctionTool ist eine Unterklasse von FunctionTool. Es ist für Tools gedacht, die sehr lange dauern.

Wenn Sie ein AsyncFunctionTool erstellen möchten, müssen Sie eine reguläre Python-Funktion definieren und in die Klasse AsyncFunctionTool einfügen. So: AsyncFunctionTool(func=your_function)

AsyncFunctionTool ruft weiterhin Ihre Python-Funktion auf, über die Sie die Aufgabe starten können, die viel Zeit in Anspruch nehmen kann. Sie können ein Zwischenergebnis an das Modell zurückgeben, um ihm mitzuteilen, dass die Aufgabe noch nicht abgeschlossen ist. Wenn Sie Informationen wie status: 'pending', progress: 20 und estimated_completion_time: '...' hinzufügen, kann das Modell dem Nutzer eine sinnvolle Antwort geben.

Wenn der Vorgang abgeschlossen ist, kannst du den Kundenservicemitarbeiter mit einer neuen FunctionResponse anrufen, um ihm das endgültige Ergebnis mitzuteilen. Der Kundenservicemitarbeiter generiert dann eine endgültige Antwort an den Nutzer.

AgentTool

Mit AgentTool kannst du einen anderen Kundenservicemitarbeiter anrufen, um eine Aufgabe zu erledigen. Das entspricht dem Erstellen einer Python-Funktion, dem Aufrufen eines anderen Bots mit den Funktionsargumenten und der Verwendung der Antwort dieses Bots als Rückgabewert der Funktion.

Ein AgentTool unterscheidet sich von einem untergeordneten Agenten:

• Wenn Agent A Agent B als AgentTool aufruft, wird die Antwort von Agent B an Agent A übergeben. Agent A fasst die Antwort zusammen und generiert eine Antwort an den Nutzer. Alle zukünftigen Nutzereingaben werden weiterhin von Kundenservicemitarbeiter A beantwortet.
• Wenn Agent A Agent B als untergeordneten Agenten anruft, wird die Verantwortung für die Beantwortung der Anfrage des Nutzers vollständig an Agent B übertragen. Kundenservicemitarbeiter A ist nicht mehr im Bild. In diesem Fall wird zukünftige Nutzereingabe von Kundenservicemitarbeiter B beantwortet.

Wenn Sie einen Agenten als Tool verwenden möchten, können Sie ihn mit der Klasse AgentTool einschließen. Beispiel: tools=[AgentTool(agent=agent_b)]

AgentTool hat die folgenden Attribute, mit denen sich das Verhalten anpassen lässt:

• skip_summarization
  • Wenn diese Option auf „True“ gesetzt ist, überspringt das Framework den Aufruf des LLM, um die Antwort des Tool-Agents zusammenzufassen.

Callbacks

Callback-Typen

Sie können das Verhalten des Agents weiter anpassen, indem Sie Rückrufe definieren. Wir unterstützen zwei Arten von Rückrufen:

• BeforeCallbacks werden aufgerufen, bevor der Kundenservicemitarbeiter eine Aktion ausführt. Sie können die Aktion ändern, überspringen oder zusätzliche Aktionen ausführen.
• AfterCallbacks werden aufgerufen, nachdem der Kundenservicemitarbeiter eine Aktion ausgeführt hat. Mit diesem Callback kannst du das Ergebnis der Aktion ändern oder zusätzliche Aktionen ausführen.

Unterstützte Aktionen

Für die folgenden Aktionen gibt es BeforeCallbacks und AfterCallbacks:

• Sie können einen Kundenservicemitarbeiter anrufen.
• Aufruf eines LLM.
• Aufruf eines Tools

Liste der Rückrufe

Das sind die folgenden sechs Callbacks, die alle Attribute der Klasse Agent sind:

before_agent_callback

def before_agent_callback(invocation_context: InvocationContext) -> Content | None

• Eine Aufrufe kann mehrere Kundenservicemitarbeiteranrufe enthalten. Dieser Rückruf kann also mehrmals aufgerufen werden.
• Wenn du über diesen Callback eine Content zurückgibst, überspringt der Kundenservicemitarbeiter den aktuellen Kundenserviceanruf und verwendet die zurückgegebene Content als Antwort.

after_agent_callback

def after_agent_callback(invocation_context: InvocationContext) -> Content | None

• Eine Aufrufe kann mehrere Kundenservicemitarbeiteranrufe enthalten. Dieser Rückruf kann also mehrmals aufgerufen werden.
• Wenn du über diesen Callback ein Content zurückgibst, hängt der Kundenservicemitarbeiter das zurückgegebene Content an seine eigene Antwort an.

before_model_callback

def before_model_callback(
    invocation_context: InvocationContext,
    llm_request: LlmRequest) -> LlmResponse | None

• Ein Kundenservicemitarbeiteranruf kann mehrere LLM-Anrufe enthalten. Dieser Rückruf kann also mehrmals aufgerufen werden.
• Wenn Sie über diesen Callback eine LlmResponse zurückgeben, verwendet der Kundenservicemitarbeiter die zurückgegebene LlmResponse als Antwort und überspringt den Aufruf des Modells.

before_model_callback

def after_model_callback(
    invocation_context: InvocationContext,
    llm_response: LlmResponse) -> LlmResponse | None

• Ein Kundenservicemitarbeiteranruf kann mehrere LLM-Anrufe enthalten. Dieser Rückruf kann also mehrmals aufgerufen werden.
• Wenn Sie über diesen Callback eine LlmResponse zurückgeben, verwendet der Kundenservicemitarbeiter die zurückgegebene LlmResponse als Antwort anstelle der vom Modell generierten Antwort.

before_tool_callback

def before_tool_callback(
    invocation_context: InvocationContext,
    tool: BaseTool,
    args: dict[str, Any],
    tool_context: ToolContext) -> dict | None

• Ein Modellaufruf kann mehrere Toolaufrufe enthalten. Dieser Rückruf kann also mehrmals aufgerufen werden.
• Wenn du über diesen Callback eine dict zurückgibst, verwendet der Kundenservicemitarbeiter die zurückgegebene dict als Antwort und überspringt den Aufruf des Tools.

after_tool_callback

def after_tool_callback(
    invocation_context: InvocationContext,
    tool: BaseTool,
    args: dict[str, Any],
    tool_context: ToolContext,
    response: dict) -> dict | None

• Ein Modellaufruf kann mehrere Toolaufrufe enthalten. Dieser Rückruf kann also mehrmals aufgerufen werden.
• Wenn du über diesen Callback eine dict zurückgibst, verwendet der Kundenservicemitarbeiter die zurückgegebene dict als Antwort anstelle der vom Tool generierten Antwort.

Sitzungen

Sie müssen das Sitzungsobjekt beim Erstellen eines Agents nicht direkt bearbeiten. Das Framework verwaltet das Sitzungsobjekt für Sie. Es ist jedoch trotzdem nützlich zu wissen, was es ist und wie die Sitzung funktioniert.

Eine Sitzung im Agent Framework besteht aus zwei Hauptkomponenten:

• Ereignisse: Eine Liste von Ereignissen.
• Status: Ein dict-ähnliches Objekt mit Zustandsvariablen.

Ereignisse

„Ereignisse“ ist einfach eine Liste von Ereignisobjekten. Sie können sich das als Chatverlauf vorstellen, entweder zwischen einem Nutzer und einem Kundenservicemitarbeiter oder zwischen verschiedenen Kundenservicemitarbeitern. Es werden nicht nur die Wörter des Nutzers oder des Modells aufgezeichnet, sondern auch alle Aktionen, die der Kundenservicemitarbeiter ausführt, z. B. das Aufrufen eines Tools, die Antwort des Tools oder das Anrufen eines anderen Kundenservicemitarbeiters.

Die Ereignisliste ist eine Liste, in die nur Elemente angehängt werden können. Sie können der Liste nur Ereignisse hinzufügen, aber keine Ereignisse entfernen oder ändern. Wenn ein Ereignis eingetreten ist, ist es eingetreten. Das lässt sich nicht ändern. So ist das System einfach und wir können jederzeit zu einem bestimmten Zeitpunkt zurückkehren, um den genauen Snapshot des Systems zu sehen.

Bundesland

Der Status ist ein dictionary-ähnliches Objekt, das alle Statusvariablen enthält. Sie können von folgenden Orten darauf zugreifen:

• In der Anleitung können Sie mit der {var}-Syntax den Wert der Variablen „var“ einfügen.
• Über die Callbacks kannst du über invocation_context.state['key'] auf die Statusvariable zugreifen. Sie können die Statusvariable auch über invocation_context.state['key'] = value aktualisieren.
• Über die Tools können Sie über tool_context.state['key'] auf die Statusvariable zugreifen. Sie können die Statusvariable auch über tool_context.state['key'] = value aktualisieren.

Der Status ist mit einer bestimmten Sitzung verknüpft. Daher ist es der ideale Ort, um Informationen zu speichern, die im Kontext dieser Sitzung nützlich sind.

Auf den Status können alle Kundenservicemitarbeiter im Kundenservicebaum zugreifen. Er ist daher ein idealer Ort, um zwischen Kundenservicemitarbeitern zu kommunizieren. Ein Agent kann eine Aktion ausführen und das Ergebnis im Status speichern. Ein anderer Agent kann dann das Ergebnis aus dem Status lesen und die Arbeit fortsetzen.

Artefakte

Wenn das Modell oder Ihr Tool eine Datei erstellt, z. B. ein Bild, ein Video, ein Dokument oder eine Datei in einem anderen Format, können Sie sie als Artefakt speichern. Ein Artefakt ist eine Datei, die mit einer bestimmten Sitzung verknüpft ist und auf die die Kundenservicemitarbeiter oder Ihr eigener Code zugreifen können.

Anwendungsbereiche

• Wenn dein Kundenservicemitarbeiter mit dem Nutzer zusammenarbeitet, um eine Datei zu erstellen oder zu ändern. Beispiel: Ein Assistent, der Nutzern beim Erstellen und Bearbeiten eines Bildes hilft.
• Wenn Sie möchten, dass der Kundenservicemitarbeiter Fragen zu einer Datei beantwortet oder die Datei gemäß den Anweisungen des Nutzers bearbeitet.

Leistungsvorteile

Eine weitere Möglichkeit, große Dateien zu verarbeiten, besteht darin, sie als Bytes im Chatverlauf zu speichern. Dieser Ansatz hat jedoch einige Nachteile:

• Dadurch wird der Sitzungsverlauf verlangsamt.
• Es ist schwierig, die Datei aus dem Chatverlauf abzurufen.
• Die Bytes werden für alle Anfragen an das Modell gesendet, auch wenn die Unterhaltung nichts mit diesen Dateien zu tun hat.

Auf Artefakte zugreifen

Es gibt mehrere Möglichkeiten, auf die Artefakte zuzugreifen:

• In der Anleitung können Sie die {artifact.var}-Syntax verwenden, um den Textinhalt des Artefakts mit dem Namen „var“ einzufügen. Binäre Artefakte werden noch nicht unterstützt.
• In den Rückrufen kannst du über invocation_context.get_artifact('key') auf das Artefakt zugreifen. Sie können das Artefakt mit invocation_context.set_artifact('key', value) aktualisieren.
• In den Tools können Sie über tool_context.get_artifact('key') auf das Artefakt zugreifen. Sie können das Artefakt mit tool_context.set_artifact('key', value) aktualisieren.

Mehragentensysteme

Ein einzelner Agent und Listentools können einen großen Beitrag zum Aufbau eines komplexen Systems leisten. Manchmal kann die Leistung und Wartbarkeit des Gesamtsystems jedoch durch die Aufteilung der Logik in mehrere Agenten verbessert werden.

In folgenden Fällen kann es sinnvoll sein, mehrere Kundenservicemitarbeiter zu verwenden:

• Wenn die Anleitung des Kundenservicemitarbeiters zu lang wird und mehrere Aufgaben und Schritte für jede Aufgabe enthält.
• Wenn Sie einen deterministischen Workflow ausführen möchten. Beispielsweise wird für einen Rechercheur immer ein Plan erstellt, der Plan wird ausgeführt und die Ergebnisse werden zusammengefasst.

Hierarchischer Kundenservicemitarbeiterbaum

  children: list[BaseAgent]

Sie erstellen ein Multi-Agent-System, indem Sie einen hierarchischen Agenten-Baum erstellen. Der Root-Agent ist der Einstiegspunkt des Systems und kann je nach Konfiguration andere Agenten aufrufen.

Ein Kundenservicemitarbeiter kann mehrere untergeordnete Kundenservicemitarbeiter haben. Untergeordnete Kundenservicemitarbeiter können auch eigene untergeordnete Kundenservicemitarbeiter haben. Der Kundenservicemitarbeiter-Baum kann beliebig tief sein, aber aus Leistungsgründen empfehlen wir einen flacheren Baum.

Um den Agentenstammbaum zu bilden, ordnen Sie andere Kundenservicemitarbeiter einem übergeordneten Kundenservicemitarbeiter zu.

Abläufe

  flow: str | BaseFlow | FlowCallable

Wenn ein Kundenservicemitarbeiter eine Nutzeranfrage erhält, kann er sie entweder selbst bearbeiten oder an einen anderen Kundenservicemitarbeiter weiterleiten. Das wird durch das flow-Attribut definiert.

Es gibt einige vordefinierte Abläufe, Sie können aber auch eigene Abläufe definieren.

• sequential: Der Agent ruft seine untergeordneten Agenten nacheinander auf.
• loop: Der Agent ruft seine untergeordneten Agenten in einer Schleife auf. Bis einer der untergeordneten Agents tool_context.actions.escalate auf „True“ setzt.
• single: Dies ist ein LLM-basierter Ablauf. Der Kundenservicemitarbeiter ruft das LLM auf, um die Nutzeranfrage zu beantworten, und ruft bei Bedarf die Tools auf.
• auto: Dies ist ein LLM-basierter Ablauf. Der Kundenservicemitarbeiter ruft das LLM auf, um die Nutzeranfrage zu beantworten, und ruft bei Bedarf die Tools auf. Es kann die Abfrage auch an seine untergeordneten Elemente, seine Geschwister oder sein übergeordnetes Element weiterleiten.
• Benutzerdefinierte Workflows: Sie können eigene Workflows definieren, indem Sie die Klasse BaseFlow implementieren, oder einfach eine Python-Funktion definieren, die der Schnittstelle folgt.