6 kopierfertige JSON-Vorlagen · A2A v1.0

A2A Agent Card Beispiele

Durchsuche praktische A2A-v1.0-Vorlagen, verstehe ihre Designentscheidungen, und passe dann jedes Beispiel für deinen eigenen Agenten an.

Vorlagen durchsuchen Generator öffnen

Öffentliche Agent-Entdeckung

Nutze diese Beispiele, um das JSON zu gestalten, das ein anderer A2A-Client abruft, bevor er entscheidet, ob dein Agent eine Aufgabe erledigen kann.

Marketplace-Einreichung

Passe Provider, Skills, Tags, Capabilities, und Sicherheitsmetadaten an, damit Prüfer verstehen, was der Agent tut und wer ihn betreibt.

Interne Agent-Kataloge

Standardisiere Endpunkt-, Authentifizierungs-, und Skill-Beschreibungen über interne Agenten hinweg, bevor Teams sie in Workflows integrieren.

JSON-Vorlagen

Beispiel-Agent Cards für Support-, Buchungs-, Shopping-, Coding-, Recherche-, und Workflow-Agenten.

Eine Vorlage validieren

Filter

Kundensupport-Agent

Bearbeitet Produktfragen, Bestellabfragen, Retouren, und Eskalations-Übergaben.

Warum es so aufgebaut ist

OAuth-2.0-Client-Credentials schützen Bestelldaten: Die Agent Card deklariert die Token-URL und den Scope, damit Clients ohne Out-of-Band-Dokumentation authentifizieren können.
streaming und pushNotifications sind beide true, weil Support-Konversationen lange dauern und Lösungsupdates asynchron eintreffen.
Die einzelne Skill ist auf eine Aufgabengrenze beschränkt (klassifizieren, lösen, eskalieren) statt einer vagen "Kunden helfen"-Beschreibung, sodass Router sie präzise zuordnen können.

customer-support.json

{
  "name": "Kundensupport-Agent",
  "description": "Beantwortet Fragen des Kundensupports, ruft den Bestellkontext ab und leitet ungelöste Probleme an ein menschliches Team weiter.",
  "supportedInterfaces": [
    {
      "url": "https://api.example.com/a2a/customer-support",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "provider": {
    "organization": "Beispiel Inc.",
    "url": "https://example.com"
  },
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": false
  },
  "defaultInputModes": [
    "text/plain",
    "application/json"
  ],
  "defaultOutputModes": [
    "text/plain",
    "application/json"
  ],
  "skills": [
    {
      "id": "resolve-customer-support-request",
      "name": "Lösen Sie die Kundensupportanfrage",
      "description": "Klassifiziert eine Kundensupportanfrage, sammelt den erforderlichen Kontext, schlägt eine Lösung vor und eskaliert, wenn das Vertrauen gering ist.",
      "tags": [
        "support",
        "orders",
        "returns"
      ],
      "examples": [
        "Helfen Sie mir, meine Bestellung zurückzugeben."
      ]
    }
  ],
  "securitySchemes": {
    "oauth2": {
      "oauth2SecurityScheme": {
        "flows": {
          "clientCredentials": {
            "tokenUrl": "https://api.example.com/a2a/customer-support/oauth/token",
            "scopes": {
              "agent.invoke": "Invoke agent skills"
            }
          }
        }
      }
    }
  },
  "security": [
    {
      "oauth2": [
        "agent.invoke"
      ]
    }
  ]
}

Buchungs-Agent

Findet verfügbare Termine und bereitet Buchungsbestätigungen vor.

Warum es so aufgebaut ist

Ein API-Schlüssel in einem Header genügt hier: Buchungen sind mandantenbezogen, tragen aber nicht das Problem der delegierten Nutzerzustimmung, das OAuth löst.
defaultOutputModes ist nur application/json, was signalisiert, dass Aufrufer strukturierte Reservierungsvorschläge statt Fließtext erhalten.
pushNotifications ist true, damit der Agent eine Reservierung bestätigen kann, nachdem sich das Slot-haltende Backend gesetzt hat, ohne dass der Client pollen muss.

booking.json

{
  "name": "Buchungs-Agent",
  "description": "Sucht nach Verfügbarkeit, schlägt Buchungsoptionen vor und bereitet Terminreservierungen zur Genehmigung vor.",
  "supportedInterfaces": [
    {
      "url": "https://api.example.com/a2a/booking",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "provider": {
    "organization": "Beispiel Inc.",
    "url": "https://example.com"
  },
  "version": "1.0.0",
  "capabilities": {
    "streaming": false,
    "pushNotifications": true,
    "extendedAgentCard": false
  },
  "defaultInputModes": [
    "text/plain",
    "application/json"
  ],
  "defaultOutputModes": [
    "application/json"
  ],
  "skills": [
    {
      "id": "find-and-prepare-booking",
      "name": "Buchung finden und vorbereiten",
      "description": "Überprüft die Ressourcenverfügbarkeit, vergleicht Buchungsfenster und gibt einen strukturierten Reservierungsvorschlag zurück.",
      "tags": [
        "booking",
        "calendar",
        "availability"
      ],
      "examples": [
        "Finden Sie morgen Nachmittag einen 30-minütigen Termin."
      ]
    }
  ],
  "securitySchemes": {
    "apiKey": {
      "apiKeySecurityScheme": {
        "location": "header",
        "name": "X-API-Key"
      }
    }
  },
  "security": [
    {
      "apiKey": []
    }
  ]
}

Shopping-Agent

Vergleicht Produkte, Verfügbarkeit, Preise, und Kaufbeschränkungen.

Warum es so aufgebaut ist

Bewertete Empfehlungen werden gestreamt, sobald sie berechnet werden, daher ist streaming true, während pushNotifications false bleibt — nach Abschluss der Antwort passiert nichts mehr.
Die Skill-Beschreibung verpflichtet sich, Kompromisse und Begründungen zurückzugeben, was Orchestratoren signalisiert, dass dieser Agent Rankings erklärt statt nur Produkte aufzulisten.
OAuth-Scopes schützen kaufnahe Daten; eine öffentliche Shopping-Demo könnte Sicherheit komplett weglassen und trotzdem eine gültige Agent Card bleiben.

shopping.json

{
  "name": "Shopping-Agent",
  "description": "Vergleicht Produkte mit Benutzereinschränkungen und gibt bewertete Kaufoptionen mit Kompromissen zurück.",
  "supportedInterfaces": [
    {
      "url": "https://api.example.com/a2a/shopping",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "provider": {
    "organization": "Beispiel Inc.",
    "url": "https://example.com"
  },
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false,
    "extendedAgentCard": false
  },
  "defaultInputModes": [
    "text/plain",
    "application/json"
  ],
  "defaultOutputModes": [
    "application/json"
  ],
  "skills": [
    {
      "id": "compare-shopping-options",
      "name": "Vergleichen Sie Einkaufsmöglichkeiten",
      "description": "Bewertet Kandidatenprodukte, filtert nach Einschränkungen und gibt bewertete Empfehlungen mit Begründung zurück.",
      "tags": [
        "shopping",
        "commerce",
        "recommendations"
      ],
      "examples": [
        "Vergleichen Sie leichte Laptops unter 1.200 $."
      ]
    }
  ],
  "securitySchemes": {
    "oauth2": {
      "oauth2SecurityScheme": {
        "flows": {
          "clientCredentials": {
            "tokenUrl": "https://api.example.com/a2a/shopping/oauth/token",
            "scopes": {
              "agent.invoke": "Invoke agent skills"
            }
          }
        }
      }
    }
  },
  "security": [
    {
      "oauth2": [
        "agent.invoke"
      ]
    }
  ]
}

Coding-Agent

Prüft Code-Aufgaben, schlägt Patches vor, und erklärt Implementierungsentscheidungen.

Warum es so aufgebaut ist

extendedAgentCard ist true: Die öffentliche Agent Card listet eine generische "Code-Änderung implementieren"-Skill, während repository-spezifische Skills nur authentifizierten Clients über GetExtendedAgentCard offenbart werden.
Sowohl text/plain- als auch application/json-Ausgaben werden deklariert, weil der Agent menschenlesbare Erklärungen zusammen mit maschinell anwendbaren Patches zurückgibt.
Streaming ist wichtig für lange Compile-und-Test-Schleifen; Clients sehen Zwischenfortschritt statt eines stillen mehrminütigen Aufrufs.

coding.json

{
  "name": "Coding-Agent",
  "description": "Hilft bei Softwareentwicklungsaufgaben, indem er Code analysiert, Änderungen vorschlägt und Implementierungshinweise zurücksendet.",
  "supportedInterfaces": [
    {
      "url": "https://api.example.com/a2a/coding",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "provider": {
    "organization": "Beispiel Inc.",
    "url": "https://example.com"
  },
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": true
  },
  "defaultInputModes": [
    "text/plain",
    "application/json"
  ],
  "defaultOutputModes": [
    "text/plain",
    "application/json"
  ],
  "skills": [
    {
      "id": "implement-code-change",
      "name": "Codeänderung implementieren",
      "description": "Liest eine Codierungsanfrage, prüft relevante Dateien, gibt einen Patch-Vorschlag zurück und fasst die Überprüfungsschritte zusammen.",
      "tags": [
        "coding",
        "review",
        "patches"
      ],
      "examples": [
        "Fügen Sie der Benutzer-API Paginierung hinzu."
      ]
    }
  ],
  "securitySchemes": {
    "apiKey": {
      "apiKeySecurityScheme": {
        "location": "header",
        "name": "X-API-Key"
      }
    }
  },
  "security": [
    {
      "apiKey": []
    }
  ]
}

Recherche-Agent

Sammelt Quellen, extrahiert Belege, und liefert strukturierte Rechercheergebnisse.

Warum es so aufgebaut ist

Überhaupt kein securitySchemes: Der Endpunkt ist absichtlich öffentlich, und das Weglassen des Feldes ist die korrekte Art, dies auszudrücken — eine leere Scheme-Map wäre mehrdeutig.
Die Eingabe ist nur text/plain, weil Rechercheaufträge mit natürlichsprachigen Fragen beginnen; strukturierte Ausgabe erfolgt als application/json-Notizen.
Dies ist die minimal nützliche v1.0-Agent Card: Identität, eine Schnittstelle, Capabilities, Modi, und eine gut getaggte Skill.

research.json

{
  "name": "Recherche-Agent",
  "description": "Sammelt Quellenmaterial, extrahiert Beweise und erstellt strukturierte Forschungsnotizen mit Zitaten.",
  "supportedInterfaces": [
    {
      "url": "https://api.example.com/a2a/research",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "provider": {
    "organization": "Beispiel Inc.",
    "url": "https://example.com"
  },
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false,
    "extendedAgentCard": false
  },
  "defaultInputModes": [
    "text/plain"
  ],
  "defaultOutputModes": [
    "text/plain",
    "application/json"
  ],
  "skills": [
    {
      "id": "prepare-research-brief",
      "name": "Bereiten Sie einen Forschungsbericht vor",
      "description": "Durchsucht genehmigte Quellen, extrahiert Behauptungen und Beweise und gibt einen prägnanten Forschungsbericht zurück.",
      "tags": [
        "research",
        "evidence",
        "citations"
      ],
      "examples": [
        "Bereiten Sie einen zitierten Brief zur Politik im Bereich erneuerbare Energien vor."
      ]
    }
  ]
}

Interner Workflow-Agent

Koordiniert Genehmigungen, Statusprüfungen, und Back-Office-Workflow-Updates.

Warum es so aufgebaut ist

application/json ist der einzige Ein- und Ausgabemodus: Dieser Agent wird von anderen Systemen aufgerufen, niemals von Menschen, die Fließtext eintippen.
OAuth 2.0 plus extendedAgentCard passt zu Unternehmensaudits — Sicherheitsteams können die Authentifizierungsanforderungen öffentlich sehen, während sensible Workflow-Skills hinter der Authentifizierung bleiben.
pushNotifications ist essenziell, weil Genehmigungsketten Stunden oder Tage dauern; Webhooks ersetzen Polling für Zustandsänderungen.

internal-workflow.json

{
  "name": "Interner Workflow-Agent",
  "description": "Koordiniert interne Genehmigungen, prüft den Systemstatus und bereitet Workflow-Updates für Betriebsteams vor.",
  "supportedInterfaces": [
    {
      "url": "https://api.example.com/a2a/workflow",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "provider": {
    "organization": "Beispiel Inc.",
    "url": "https://example.com"
  },
  "version": "1.0.0",
  "capabilities": {
    "streaming": false,
    "pushNotifications": true,
    "extendedAgentCard": true
  },
  "defaultInputModes": [
    "application/json"
  ],
  "defaultOutputModes": [
    "application/json"
  ],
  "skills": [
    {
      "id": "coordinate-internal-workflow",
      "name": "Koordinieren Sie den internen Arbeitsablauf",
      "description": "Empfängt Workflowabsichten, prüft Richtlinienanforderungen, holt Genehmigungen ein und meldet den endgültigen Status.",
      "tags": [
        "workflow",
        "operations",
        "approval"
      ],
      "examples": [
        "Fordern Sie die Genehmigung zur Bereitstellung der Gehaltsabrechnungsaktualisierung an."
      ]
    }
  ],
  "securitySchemes": {
    "oauth2": {
      "oauth2SecurityScheme": {
        "flows": {
          "clientCredentials": {
            "tokenUrl": "https://api.example.com/a2a/workflow/oauth/token",
            "scopes": {
              "agent.invoke": "Invoke agent skills"
            }
          }
        }
      }
    }
  },
  "security": [
    {
      "oauth2": [
        "agent.invoke"
      ]
    }
  ]
}

Selbstbewusst anpassen

So passt du ein Agent Card-Beispiel an

Jedes Agent Card-Beispiel ist absichtlich vollständig genug zum Kopieren, aber die Agent Card sollte nicht unverändert veröffentlicht werden. Behandle sie als Feldkarte für deinen eigenen A2A-Server: ersetze Identität, Endpunkt, Provider, Authentifizierung, Capabilities, Modi, und Skill-Details durch Produktionswerte.

Die stärksten Agent Cards erklären die Aufgabengrenze des Agenten sowohl in einfacher Sprache als auch in maschinenlesbaren Metadaten. Ein Client sollte erkennen können, was der Agent kann, was nicht, welche URL aufzurufen ist, und ob Credentials erforderlich sind.

Vor der Veröffentlichung

Ersetze jede example.com-URL durch deinen bereitgestellten A2A-Endpunkt und die Provider-Website.

Schreibe Skill-Name, Beschreibung, Tags (in v1.0 erforderlich), und Beispiele für die tatsächliche Aufgabengrenze neu.

Setze provider.organization und erhöhe die Top-Level-version, wann immer sich der Agent Card ändert.

Entferne Authentifizierungsfelder nur, wenn der Endpunkt absichtlich öffentlich ist.

Halte defaultInputModes und defaultOutputModes mit dem in Einklang, was dein Server tatsächlich akzeptiert und zurückgibt.

Validiere das finale JSON und veröffentliche es unter /.well-known/agent-card.json auf deiner Service-Domain.

Ein Beispiel validieren Schema-Leitfaden lesen

Bereit zum Bauen

Beginne mit einem Beispiel und mach es zu deinem eigenen.

Öffne ein beliebiges Muster im Agent Card Generator, überprüfe das JSON, und validiere es vor der Veröffentlichung.

Agent Card Generator öffnen Eine Agent Card validieren