Live-Preis, Inventar und Lieferung für AI Shopping Agents

Rezensiert 11. August 2026 · 13 Minuten gelesen

KI-Shopping-Agenten sollten indexierte Daten verwenden, um Kandidaten zu finden, und maßgebliche Live-APIs, um Preis, Inventar und Lieferung zu versprechen. Jede Live-Beobachtung benötigt eine Quelle, einen Markt, einen Kundenkontext, einen Zeitstempel und einen Ablauf. Knappes Inventar benötigt eine Reservierung mit explizitem Lebenszykluszustand. Retries benötigen stabile Idempotenzschlüssel, und der Checkout muss jeden geänderten Zustand abgleichen, anstatt der früheren Konversation zu vertrauen.

Dieser Artikel richtet sich an Wirtschaftsarchitekten, die den Abruf mit der Kasse verbinden. Das Ergebnis ist ein staatliches Modell, das verhindert, dass ein Agent eine indizierte Produkttatsache als aktuelle kommerzielle Verpflichtung darstellt.

Beginnen Sie mit dem E-Commerce Produkt Discovery Guide und der Begleiter agentenlesbares Produktschema.

Stabile Fakten und Live-Fakten gehören auf verschiedene Wege

Indexfelder, die sich langsam ändern: Titel, Produktfamilie, Variantenoptionen, Abmessungen, Materialien, Kompatibilitätsreferenzen und Evidenzverdauung; Felder abrufen, deren Wert vom Zeit- oder Transaktionskontext abhängt:

Google Merchant Center behandelt Preis- und Verfügbarkeitsunterschiede als Datenqualitätsfehler und verlangt, dass die eingereichten Werte mit den Lande- und Kassenflächen übereinstimmen. Produktdatenspezifikation von Google ist kein transaktionales agentenprotokoll, aber es veranschaulicht die betriebskosten des veralteten zustands.

Definieren Sie einen Live-Beobachtungsvertrag

Geben Sie keine bloßen Werte wie price: 49.99 oder in_stock: true.

type LiveOfferObservation = {
  observationId: string;
  offerId: string;
  merchantId: string;
  variantId: string;
  market: string;
  buyerContextId?: string;
  price: { amount: string; currency: string; includesTax: boolean };
  inventory: {
    status: 'available' | 'limited' | 'unavailable' | 'unknown';
    quantity?: number;
    locationId?: string;
  };
  delivery: {
    earliestDate?: string;
    latestDate?: string;
    serviceLevel?: string;
    status: 'estimated' | 'confirmed' | 'unknown';
  };
  observedAt: string;
  expiresAt: string;
  sourceVersion?: string;
};

unknown ist nicht dasselbe wie unavailableWenn die Inventar-API ausfällt, sollte der Agent dem Käufer nicht mitteilen, dass das Produkt ausverkauft ist, sondern sagen, dass die Verfügbarkeit nicht bestätigt werden konnte, und entweder erneut versuchen oder Alternativen anbieten.

Die kontextuelle Preisgestaltung kann von Land, Unternehmen, Kundensegment, Menge oder Vertrag abhängen. Shopify legt die kontextuelle Preisgestaltung für Produkte offen, anstatt einen universellen Wert anzunehmen. Shopifys kontextbezogenes Preisobjekt unterstützt die Design-Regel: Fügen Sie den Preiskontext in den Cache-Schlüssel und den Beweis hinzu.

Abfrage Live-Zustand nach Kandidatenabruf

Rufen Sie nicht drei Händler-APIs für jedes Element in einem 100.000-Produktkatalog auf. Suchen und filtern Sie zuerst, und bereichern Sie dann einen begrenzten Kandidatensatz.

intent
  -> structured and semantic retrieval
  -> 50 candidate variants
  -> compatibility and market filters
  -> 10 eligible offers
  -> parallel live-state reads
  -> remove unknown or invalid candidates according to policy
  -> 3 to 5 evidence-rich choices

Kontrollgleichheit und Fristen: Wenn ein Händler vier Sekunden braucht, sollte die gesamte Antwort nicht unbegrenzt bleiben.

async function enrichCandidates(candidates: Candidate[], ctx: BuyerContext) {
  return mapWithConcurrency(candidates, 8, async (candidate) => {
    const result = await withTimeout(
      merchant.getLiveOffer(candidate.offerId, ctx),
      750,
    );
    return result.ok
      ? { candidate, state: validateObservation(result.value, ctx) }
      : { candidate, state: { status: 'unknown', reason: result.code } };
  });
}

Die Timeout- und Parallelitätswerte sind illustrativ, messen sie mit den Zielen des Händlerservice und dem Wert des Wartens auf einen anderen Kandidaten.

Lieferung ist eine Berechnung, kein Katalogattribut

Die Lieferung hängt von Lagerort, Bestimmungsort, Bearbeitungszeit, Spediteurservice, Bestellschluss, Wochenenden, Feiertagen und manchmal dem Inhalt des vollen Warenkorbes ab. ships_in_2_days Das Feld kann das nicht repräsentieren.

Fragen Sie den autoritativen Fulfillment-Service nach der tatsächlichen Variante, Menge und Zielort. Geben Sie an, ob es sich bei der Antwort um eine Schätzung oder ein bestätigtes Versprechen handelt.

Googles Merchant Center-Update für 2026 fügte den Handhabungs-Cutoff- und Mindestbestell-Attributen auf Produktebene hinzu, was zeigt, wie sich der Erfüllungskontext über einen einzigen Versandstring hinaus ausdehnt. Das Produktdaten-Update 2026 unterstützt die Discovery-Präsentation, aber der Checkout benötigt immer noch die Live-Berechnung des Händlers.

Vorbehalte verwandeln Beobachtungen in temporäre Ansprüche

Eine Beobachtung sagt, dass Inventar verfügbar war. Eine Reservierung fordert den Händler auf, eine Menge für eine begrenzte Zeit zu halten.

type Reservation = {
  reservationId: string;
  idempotencyKey: string;
  offerId: string;
  variantId: string;
  quantity: number;
  locationId: string;
  status: 'pending' | 'held' | 'committed' | 'released' | 'expired' | 'unknown';
  createdAt: string;
  expiresAt: string;
  merchantReference?: string;
};

Reservierungen nur dann verwenden, wenn ihre Betriebskosten gerechtfertigt sind. Jedes angesehene Produkt zu reservieren kann den Bestand sperren und zu einem Missbrauchsvektor werden. Eine Reservierung nach eindeutiger Kaufabsicht auslösen oder wenn der Artikel knapp ist und der Käufer den Kompromiss akzeptiert hat.

Der Händler besitzt den Reservierungsstaat. Der Agent speichert eine Referenz, nicht einen erfundenen lokalen Besitz.

Verwenden Sie eine Zustandsmaschine für Ablauf und Unsicherheit

OBSERVED -> RESERVATION_PENDING -> HELD -> CHECKOUT_PENDING -> COMMITTED
                         |          |              |
                         v          v              v
                      UNKNOWN    EXPIRED        RELEASED

Wenn eine Reservierungsanfrage ausläuft, erstellen Sie keine zweite Reservierung mit einem neuen Schlüssel. unknown und den Händler nach dem ursprünglichen idempotency-Schlüssel abfragen.

async function recoverReservation(op: ReservationOperation) {
  const remote = await merchant.findReservation({
    idempotencyKey: op.idempotencyKey,
  });
  if (remote.found) return reconcileLocal(remote);
  if (remote.authoritativelyAbsent) return retrySameRequest(op);
  return keepUnknownAndEscalate(op);
}

"Nicht gefunden" muss maßgebend sein. Eine verzögert gelesene Replik kann Abwesenheit melden, während das Schreiben an anderer Stelle existiert.

Preisakzeptanz braucht eine Angebotsversion

Ein Agent kann 129,90 EUR vorzeigen und nach Ablauf der Aktion an die Kasse gehen.

{
  "offer_id": "offer:merchant-7:TS8-BLU-43:DE",
  "revision": 18,
  "price": { "amount": "129.90", "currency": "EUR" },
  "quantity": 1,
  "delivery_latest": "2026-08-14",
  "valid_until": "2026-08-11T10:15:00Z",
  "digest": "sha256:a482..."
}

An der Kasse halten Sie sich entweder an dieses unterzeichnete oder vom Server ausgestellte Angebot oder geben eine strukturierte Änderung zurück.

Die Checkout-Fähigkeit von UCP modelliert eine Stateful Checkout-Sitzung und erfordert verbindliche Transaktionsdaten für die Förderfähigkeit und Richtlinie bei Abschluss. UCP Checkout bietet eine nützliche Protokollgrenze zwischen dem vorläufigen Kontext und dem endgültigen Handelszustand.

Retry- und Idempotenzregeln

Verwenden sie separate stabile schlüssel für reservierung, checkout-abschluss und zahlung eine konversations-turn-id ist ein schlechter idempotenz-schlüssel, da der agent während der genesung eine neue wende erstellen kann.

Speichern Sie einen Anfrage-Fingerabdruck mit jedem Schlüssel: Wenn der gleiche Schlüssel mit einer anderen Menge, einem anderen Angebot oder einem anderen Ziel ankommt, geben Sie einen Konflikt zurück.

INSERT INTO commerce_operations
  (tenant_id, operation_type, idempotency_key, request_digest, state)
VALUES
  ($1, 'reserve_inventory', $2, $3, 'pending')
ON CONFLICT (tenant_id, operation_type, idempotency_key) DO NOTHING;

Der Anrufer liest dann die vorhandene Zeile und überprüft den Digest. Datenbankdeduplizierung allein sagt Ihnen nicht, ob der Händler ausgeführt hat.

Fehler- und Wiederherstellungsmatrix

Reproduzierbare Bewertung

Bauen Sie einen gefälschten Händlerservice mit einer kontrollierbaren Uhr und einer deterministischen Fehlerinjektion auf.

Führen Sie diese Szenarien aus:

1. Abrufen des Angebots, Vorauszeit darüber hinaus expiresAt, und überprüfen Checkout lehnt es ab.
2. Senden Sie eine Reservierung, lassen Sie die Antwort fallen, versuchen Sie es erneut mit dem gleichen Schlüssel und überprüfen Sie, ob ein Halteplatz vorhanden ist.
3. Versuchen Sie es mit dem gleichen Schlüssel, aber Nummer zwei, und überprüfen Sie einen Idempotenzkonflikt.
4. Geben Sie Inventarereignisse außerhalb der Reihenfolge zurück und überprüfen Sie, ob die ältere Version den Bestand nicht wiederherstellen kann.
5. Variieren Sie den Käuferkontext und überprüfen Sie die Vertragspreise niemals über Cache-Schlüssel.
6. Läuft ein Halten während des Checkouts ab und stellt sicher, dass kein Zahlungsanruf erfolgt.

Upstream-Call-Zählung, Endreservierungszustand, Grundcodes und die angezeigte Kundennachricht aufzeichnen; die Bewertung wird nur dann bestanden, wenn das System eine falsche Verfügbarkeit und Duplikate vermeidet.

Aktuelle Intelliger-Grenze

Live-Händlerkonnektoren, maßgebliche Preis- und Inventargespräche, Reservierungsorchestrierung, Commerce Graph und Merchant Agent Runtime sind Zielzustandskomponenten im Intelliger-Blueprint vom August 2026.

OATI Commerce bietet derzeit Entwickler-Vorschau-Schemata und deterministische Auswertungen für signierte Preis-, Währungs-, Budget-, Nutzungs- und Substitutionsbeschränkungen. Seine lokale Sandbox zeigt eine bezahlte API-Transaktion. Das gehostete Commerce-Profil beweist die Profilerkennung, nicht eine Live-Einzelhandelsinventar oder Checkout-Integration.

Die Agentic-Commerce-Infrastrukturartikel erklärt, warum der Live-Zustand unter den Assistenten gehört. Agentische Commerce Architektur zeigt die vorgesehene käuferseitige Schicht.

Checkliste der Durchführung

• Index stabile Produkt Fakten und holen volatile Zustand spät.
• Fügen Sie Markt, Käuferkontext, Quelle, Beobachtung und Ablauf hinzu.
• Unterscheiden Sie unbekannt von nicht verfügbar in APIs und Kundensprache.
• Berechnen Sie die Lieferung für die tatsächliche Menge und Bestimmung.
• Inventar nur nach geeigneter Kaufabsicht reservieren.
• Modell gehalten, abgelaufen, freigegeben und unbekannte Zustände explizit.
• Tragen Sie stabile Idempotenzschlüssel durch Retries.
• Speicheranfrage verdaut und lehnt Schlüsselwiederverwendung mit geänderter Absicht ab.
• Abgleichen Sie den Handelsstaat nach mehrdeutigen Antworten.
• Aktualisieren oder binden Sie akzeptierte Bedingungen an der Kasse.
• Testen Sie Mandanten-Cache-Isolation, Ereignisreihenfolge und Ablauf der Uhr.

Überprüfungshinweis: Ein Experte der Commerce-Plattform sollte die Reservierungssemantik, die Inventarbehörde, die Steuer- und Preisannahmen und die Idempotenz jedes Händlersteckers vor der Verwendung der Produktion überprüfen.

Verwendung der agentenlesbare Schemavorrichtung Testen Sie dann den Live-Übergang mit den oben genannten Bewertungsszenarien.