Rückerstattungsagenten: LangGraph hat überlebt, wo CrewAI und AutoGen versagten
Dieselben Werkzeuge und Richtlinien in allen drei Frameworks – nur explizite Zustandsangaben, Idempotenz und Kontrollpunkte überstanden die Zerstörungen durch Chaos.
Die Arbeitsbelastung, die Demo-Agenten zum Scheitern bringt
Mehr-Agenten-Frameworks wirken in Forschungs- und Blog-Demos perfekt. Es steht nichts auf dem Spiel, wenn ein Tool zweimal ausgeführt wird. Ein Agent zur Bearbeitung von Rückerstattungen ist da weitaus anspruchsvoller. Er muss eine Kundennachricht analysieren, die Absicht erkennen, die Bestellung laden, Richtlinien prüfen (Fristen, Kategorie, frühere Rückerstattungen), gegebenenfalls einmalig auf das Zahlungsgateway zugreifen, bei Nicht-Eignung mit schriftlicher Begründung weiterleiten und einen Prüfverlauf hinterlassen.
Diese Struktur ist in der Produktion üblich: Entscheidungen treffen, auf Zustandsysteme zugreifen und für die Ergebnisse verantwortlich sein. Dafür sind dauerhafter Zustandsverlust über mehrere Schritte hinweg, deterministische Entscheidungswege zwischen Rückerstattung und Weiterleitung, idempotente Nebeneffekte sowie menschliche Pausen erforderlich, die auch bei Neustart des Prozesses bestehen bleiben – und nicht nur ein einfacher „Sleep“-Zustand.
Drei Implementierungen nutzten dieselben Tools, dasselbe Modell sowie dieselbe Richtlinienlogik. Nur eine überstand die Chaos-Tests, bei denen der Prozess mitten im Lauf abgebrochen wurde.
Gemeinsame Tools
Achten Sie darauf, dass der Wettbewerb fair bleibt: identische Funktionalitäten der Tools, einschließlich eines „flaky Gateway“ sowie einer Idempotenzschlüssel, der mit der Bestell-ID verknüpft ist.
# tools.py — identical across all three implementations
import time
import uuid
from dataclasses import dataclass
from typing import Literal
class PaymentGatewayError(Exception):
pass
@dataclass
class Order:
order_id: str
customer_id: str
item_category: str
amount_cents: int
purchased_at: float
refund_count: int
# Fake DB — in prod this is Postgres behind a repository class
_ORDERS = {
"ORD-4471": Order("ORD-4471", "CUST-991", "electronics", 8999, time.time() - 86400 * 5, 0),
"ORD-2210": Order("ORD-2210", "CUST-102", "electronics", 4200, time.time() - 86400 * 45, 1),
}
_PROCESSED_REFUNDS: set[str] = set() # idempotency ledger
def get_order(order_id: str) -> Order | None:
return _ORDERS.get(order_id)
def check_refund_policy(order: Order) -> tuple[bool, str]:
days_since_purchase = (time.time() - order.purchased_at) / 86400
if days_since_purchase > 30:
return False, f"Purchase was {days_since_purchase:.0f} days ago, outside the 30-day window."
if order.refund_count >= 1:
return False, "Customer has already received a refund on this order."
return True, "Eligible: within window, no prior refund."
def issue_refund(order_id: str, idempotency_key: str) -> dict:
"""Calls the payment gateway. MUST be idempotent — retries are expected."""
if idempotency_key in _PROCESSED_REFUNDS:
return {"status": "already_processed", "idempotency_key": idempotency_key}
order = _ORDERS[order_id]
# simulate a flaky gateway — this matters later
if uuid.uuid4().int % 5 == 0:
raise PaymentGatewayError("gateway timeout, retry with same idempotency_key")
_PROCESSED_REFUNDS.add(idempotency_key)
return {"status": "refunded", "amount_cents": order.amount_cents, "idempotency_key": idempotency_key}
Idempotenz ist keine Dekoration – sie ist der Unterschied zwischen einem Agentenframework und einem bloßen Spielzeug für Agenten.
CrewAI: starke Demonstrationen, schwache Steuerung
CrewAI modelliert Rollen und Aufgaben innerhalb eines Crew. Produktpräsentationen schätzen die Metapher des Organigramms.
Naives Muster
from crewai import Agent, Task, Crew, Process
from crewai.tools import tool
@tool("Get Order")
def get_order_tool(order_id: str) -> str:
"""Fetch order details by ID."""
order = get_order(order_id)
return str(order) if order else "NOT_FOUND"
@tool("Check Policy")
def check_policy_tool(order_id: str) -> str:
"""Check refund eligibility for an order."""
order = get_order(order_id)
if not order:
return "NOT_FOUND"
eligible, reason = check_refund_policy(order)
return f"eligible={eligible}, reason={reason}"
@tool("Issue Refund")
def issue_refund_tool(order_id: str) -> str:
"""Issue a refund for an order."""
result = issue_refund(order_id, idempotency_key=f"refund-{order_id}")
return str(result)
triage_agent = Agent(
role="Refund Triage Specialist",
goal="Decide whether a customer refund request should be approved or escalated",
backstory="You are an experienced support agent who follows policy strictly.",
tools=[get_order_tool, check_policy_tool, issue_refund_tool],
verbose=True,
)
triage_task = Task(
description="A customer says: '{customer_message}'. Order ID: {order_id}. "
"Decide if this qualifies for a refund and act accordingly.",
expected_output="A short summary of the action taken.",
agent=triage_agent,
)
crew = Crew(agents=[triage_agent], tasks=[triage_task], process=Process.sequential)
result = crew.kickoff(inputs={"customer_message": "I want a refund, item broke", "order_id": "ORD-4471"})
Die erfolgreichen Abläufe scheinen in Ordnung zu sein. Als Service ist er auf drei Arten fehlgeschlagen. Die Reihenfolge der Tools war nicht deterministisch – manchmal wurde issue_refund vor check_policy ausgeführt, weil das Modell frei Assoziationen zwischen den Tools herstellt. Wiederholte Versuche nach einem PaymentGatewayError konnten neue Toolaufrufe sowie neue Schlüssel erzeugen, sofern das Tool die Idempotenz nicht hardcodet. kickoff() wird ohne unterbrechende menschliche Eingriffe bis zum Ende ausgeführt; ein gefälschter Fortsetzungsversuch erforderte das Wiederherstellen des Zustands außerhalb des Frameworks.
Verstärkte hierarchische Vorgehensweise
manager_agent = Agent(
role="Refund Process Manager",
goal="Enforce strict order: lookup, then policy check, then refund or escalate. Never skip steps.",
backstory="You strictly enforce process compliance and never let steps be skipped.",
allow_delegation=True,
)
crew = Crew(
agents=[triage_agent],
tasks=[triage_task],
process=Process.hierarchical,
manager_agent=manager_agent,
)
Ein Manager-Agent sowie laute Anweisungen verringerten die übersprungenen Schritte, schufen aber keine festen Invarianten. Natürliche Sprache kann eine sequenzielle Abfolge auf Compliance-Niveau nicht durchsetzen. CrewAI eignet sich für flexible Rollenspiele – zunächst Forschung, anschließend Kritik – nicht für auf Zahlungen ausgerichtete Abläufe.
AutoGen: flexibles Chatten, ungenaue Steuerung
Der Gruppenchat mit automatischer Sprecherauswahl fügt bei jedem Schritt einen LLM-Anruf hinzu, um zu entscheiden, wer sprechen soll.
import autogen
config_list = [{"model": "gpt-4o", "api_key": "..."}]
llm_config = {"config_list": config_list, "temperature": 0}
triage_agent = autogen.AssistantAgent(
name="TriageAgent",
system_message=(
"You triage refund requests. Look up the order, check policy, "
"then either call issue_refund or hand off to EscalationAgent."
),
llm_config=llm_config,
)
escalation_agent = autogen.AssistantAgent(
name="EscalationAgent",
system_message="You write a human-readable escalation note explaining why a refund needs manual review.",
llm_config=llm_config,
)
user_proxy = autogen.UserProxyAgent(
name="ToolExecutor",
human_input_mode="NEVER",
code_execution_config=False,
function_map={
"get_order": lambda order_id: str(get_order(order_id)),
"check_refund_policy_tool": lambda order_id: str(check_refund_policy(get_order(order_id))),
"issue_refund": lambda order_id: str(issue_refund(order_id, f"refund-{order_id}")),
},
)
groupchat = autogen.GroupChat(
agents=[user_proxy, triage_agent, escalation_agent],
messages=[],
max_round=10,
speaker_selection_method="auto", # an LLM call decides who speaks next
)
manager = autogen.GroupChatManager(groupchat=groupchat, llm_config=llm_config)
user_proxy.initiate_chat(manager, message="Customer wants a refund on ORD-2210, item broke on arrival.")
Fehler: Gesprächsschleifen zwischen Triage und Eskalation ohne strukturierten „bereits entschieden“-Zustand – nur Transkripte – was zu groben max_round-Einschränkungen führt. Die Frage „Haben wir das Geld zurückgezahlt?“ wurde mithilfe von Freitextsuchen beantwortet. Der Nichtdeterminismus prägte das gesamte Ausführungsgraphen, wodurch Vorfälle aus Chatprotokollen statt aus getippten Spuren rekonstruiert werden mussten.
LangGraph: Der Überlebende
Getippte Zustände, explizite Kanten, Checkpoint-Funktionen sowie Wiederholungsversuche passten zum Problem.
from typing import TypedDict, Literal, Optional
from langgraph.graph import StateGraph, END
from langgraph.checkpoint.sqlite import SqliteSaver
from langgraph.types import interrupt, Command
import uuid
class RefundState(TypedDict):
order_id: str
customer_message: str
order: Optional[dict]
eligible: Optional[bool]
policy_reason: Optional[str]
decision: Optional[Literal["refund", "escalate", "denied"]]
refund_result: Optional[dict]
audit_log: list[str]
def lookup_order_node(state: RefundState) -> RefundState:
order = get_order(state["order_id"])
log = state["audit_log"] + [f"Looked up {state['order_id']}: {'found' if order else 'not found'}"]
if not order:
return {**state, "decision": "escalate", "audit_log": log}
return {**state, "order": order.__dict__, "audit_log": log}
def policy_check_node(state: RefundState) -> RefundState:
order = Order(**state["order"])
eligible, reason = check_refund_policy(order)
log = state["audit_log"] + [f"Policy check: eligible={eligible}, reason={reason}"]
return {**state, "eligible": eligible, "policy_reason": reason, "audit_log": log}
def route_after_policy(state: RefundState) -> str:
# Plain Python. No LLM call decides this branch. This is the whole point.
if state.get("decision") == "escalate":
return "escalate"
return "refund" if state["eligible"] else "escalate"
def human_approval_node(state: RefundState) -> RefundState:
# Durable pause: this literally suspends the graph run and persists state
# via the checkpointer. It can resume hours or days later, across restarts.
decision = interrupt({
"reason": "Ambiguous or ineligible refund needs human sign-off",
"order": state["order"],
"policy_reason": state["policy_reason"],
})
return {**state, "decision": decision, "audit_log": state["audit_log"] + [f"Human decision: {decision}"]}
def issue_refund_node(state: RefundState) -> RefundState:
idempotency_key = f"refund-{state['order_id']}" # stable across retries — this is the whole trick
try:
result = issue_refund(state["order_id"], idempotency_key)
except PaymentGatewayError as e:
# LangGraph re-raises into the node; retry policy (below) handles this,
# and because the key is stable, a retried call is safe.
raise
log = state["audit_log"] + [f"Refund issued: {result}"]
return {**state, "decision": "refund", "refund_result": result, "audit_log": log}
def escalate_node(state: RefundState) -> RefundState:
log = state["audit_log"] + ["Escalated to human queue"]
return {**state, "audit_log": log}
from langgraph.pregel.retry import RetryPolicy
graph = StateGraph(RefundState)
graph.add_node("lookup_order", lookup_order_node)
graph.add_node("policy_check", policy_check_node)
graph.add_node(
"issue_refund",
issue_refund_node,
retry=RetryPolicy(max_attempts=3, retry_on=PaymentGatewayError),
)
graph.add_node("human_approval", human_approval_node)
graph.add_node("escalate", escalate_node)
graph.set_entry_point("lookup_order")
graph.add_edge("lookup_order", "policy_check")
graph.add_conditional_edges("policy_check", route_after_policy, {
"refund": "issue_refund",
"escalate": "human_approval",
})
graph.add_edge("human_approval", "issue_refund") # human can still approve
graph.add_edge("issue_refund", END)
graph.add_edge("escalate", END)
checkpointer = SqliteSaver.from_conn_string("refunds.db")
app = graph.compile(checkpointer=checkpointer)
Thread-Konfigurationen werden nach Abstürzen wieder aufgenommen:
config = {"configurable": {"thread_id": "order-2210-refund-req"}}
# Kick off the run — it will pause at human_approval_node
result = app.invoke(
{"order_id": "ORD-2210", "customer_message": "second refund please", "audit_log": []},
config=config,
)
# result contains an interrupt payload; the process can now exit entirely.
# ... hours later, possibly a different process, different machine ...
final_result = app.invoke(Command(resume="escalate"), config=config)
Deterministische Tests stellen sicher, dass unzulässige Bestellungen eskalieren:
def test_ineligible_order_escalates():
state = {"eligible": False, "decision": None}
assert route_after_policy(state) == "escalate"
def test_eligible_order_refunds():
state = {"eligible": True, "decision": None}
assert route_after_policy(state) == "refund"
Durch das Eingreifen gegen das Chaos während des Rückzahlungsprozesses wurde dieser mit derselben Idempotenzschlüssel vom Checkpoint aus neu gestartet. Dieser Test entschied schließlich über den Ausgang.
Wenn CrewAI oder AutoGen dennoch gewinnen
CrewAI eignet sich für gemeinsames Entwerfen mit flexibler Anordnung. AutoGen ist geeignet für exploratives Mehr-Agenten-Forschung, bei dem die Konversation das Ergebnis ist. Keines von beiden ersetzt eine Zustandsmaschine, wenn Geld im Spiel ist.
Lektion
Passen Sie die Abstraktion an den Fehlermodus an. Wenn eine falsche Reihenfolge der Tools oder doppelte Nebeneffekte inakzeptabel sind, wählen Sie explizite Graphen mit dauerhaftem Zustand statt promptbasierten Teams. Frameworks sind keine austauschbaren Hüllen für „Agenten“; sie kodieren unterschiedliche Annahmen bezüglich Kontrolle, Speicherung und Wiederherstellung.
Produktions-Checkliste nach dem Wettbewerb
Vor der Einführung eines agents, der eine Rückerstattung simuliert, sind folgende Anforderungen erforderlich: ein als Text eingegebener Zustand mit einem Flag already_refunded (oder äquivalentem); Idempotenzschlüssel, die aus Geschäftsidentifikatoren erstellt werden; Policenprüfungen als Code-Node, nicht als Vorschläge im Prompt; HITL-Unterbrechungen hinter einem Checkpointer; Chaos-Tests, die Worker während Nebenwirkungen beenden; Audit-Logs, die nicht auf der Suche in Texten beruhen. Wenn ein Framework diese Eigenschaften ohne einen zusätzlichen Schatten-Workflow-Engine nicht ausdrücken kann, ist die Schatten-Engine der eigentliche Orchesterer – und das Framework nichts weiter als teure Verbindemittel.
Messen Sie in der Staging-Umgebung die unterschiedlichen Ausfallraten: übersprungenen Policen, doppelten Rückerstattungsversuchen, verloren gegangenen Unterbrechungen nach Neustart sowie unlesbaren Audit-Trailen. Crew- und AutoGen-Prototypen, die bei diesen Metriken LangGraph nicht übertreffen können, sollten im Labor bleiben. Feiern Sie ihren Rückzug – Unkontrollierter Ausbau hat schließlich Kosten.
Dokumentieren Sie die Entscheidung für zukünftige Teams, damit ein weiterer Wettbewerb nicht notwendig ist. Fügen Sie den Link zum Chaos-Harness in die README hinzu. Ziehen Sie langweilige Diagramme vor, die auch nach Ausfällen bestehen bleiben, anstelle cleverer Chat-Beiträge, die nur bei Demonstrationen funktionieren. Dieser Standard erstreckt sich über Rückerstattungen hinaus auf jeden Agenten, der unter Prüfdruck externe Systeme verändert – was im Grunde das ist, was Unternehmen tatsächlich von „KI-Agenten“ erwarten, sobald die Vorführsoftware endet und das Buchhaltungssystem wieder jedes Quartal eine reale Bedeutung erhält.
Fehler auf Annahmen des Frameworks zurückführen
CrewAI geht von einer flexiblen Aufgabenteilung aus. AutoGen betrachtet das Gespräch als ausreichenden Steuerungsmechanismus. LangGraph setzt voraus, dass man den Steuerungsmechanismus selbst entwirft. Die Automatisierung von Rückerstattungen verstößt gegen die ersten beiden Annahmen: Die Eignung ist nicht verhandelbar, und die Auswahl des Sprechers ist kein Mechanismus zur Zahlungsautorisierung. Wenn Annahmen mit den geltenden Vorschriften kollidieren, gewinnt das Framework mit weniger Annahmen – auch wenn es in der ersten Woche weniger „magisch“ wirkt.
Ingenieure versuchen manchmal, CrewAI oder AutoGen mit immer längeren Systemanweisungen zu „beheben“. Das ist, als würde man einen Wirbelwindzaun wie eine Tresortür behandeln. Bringen Sie die Konformitätsprüfung in typisierte Knoten und halten Sie die Sprachmodelle in Knoten, die kategorisieren oder Entwürfe erstellen, und nicht in Knoten, die entscheiden, ob Geld überwiesen wird.
Gemeinsame Anforderungen an die Beobachtbarkeit
Egal, was Sie wählen – geben Sie für jeden Tool-Aufruf Spans mit Order-ID, Idempotenzschlüssel und Ergebnis der Richtlinie aus. Ohne das werden Diskussionen im Framework religiös, während die Produktion im Dunkeln bleibt. LangGraph hat diese Mechanismen sichtbar gemacht, weil Knoten Funktionen sind; Sie können dieselbe Disziplin auch anderswo anwenden, doch die Vergleiche zeigten, dass dies der einfachste Weg für diese Art von Arbeitslast ist.
Fazit
Bauen Sie einen Agenten, der zu den Fehlern Ihres Systems passt. Bei Rückerstattungen war dieser Agent ein Graph mit Speicherfunktionen – nicht ein Team mit „Vibes“. Behalten Sie die anderen Tools für Probleme, zu denen sie tatsächlich passen, und hören Sie auf, so zu tun, als würde eine einzige Abstraktion alle Aufgaben im Backlog abdecken.
Durchgang durch die von LangGraph verwendete Struktur
Das erfolgreiche Diagramm behielt Klassifizierung, Abruf, Richtlinie, Rückerstattung, Eskalation und Prüfung als separate Knoten bei. Die Kanten kodierten die einzigen zulässigen Übergänge. Das Modell wählte niemals selbst aus, ob die Richtlinie übersprungen werden sollte; es füllte lediglich die strukturierten Felder aus, die vom Richtliniencode interpretiert wurden. Wiederholte Anfragen am Gateway-Knoten nutzten denselben Idempotenzschlüssel, der im Zustand gespeichert war. Für die Eskalation wurde interrupt() zusammen mit einem Checkpointer verwendet, damit ein Manager Stunden später auf einer anderen Kopie zustimmen konnte.
Im Vergleich zu einer Definition mit drei Agenten erscheint dieses Design überaus ausführlich. Genau diese Ausführlichkeit ist der Zweck: Jeder irreversible Schritt kann bei einer Code-Überprüfung benannt werden. Neue Ingenieure können das Diagramm lesen und das Verhalten vorhersagen, ohne zehn stochastische Gespräche nachspielen zu müssen.
Vergleich von Vorgehensweisen bei Incidents
Als CrewAI ein Tool in der Vorbereitungsphase mehrfach ausführte, wurde im Nachgang „Prompt-Drift“ als Ursache genannt. Als AutoGen in Schleifen geriet, lag die Schuld beim „Sprecherauswahl-Verfahren“. Als LangGraph versagte, wies der Nachgang auf einen bestimmten Knoten sowie fehlende Reduzierfunktionen hin – Probleme, die ohne Diskussionen gelöst werden konnten. Allein die Klassifizierung der Vorfälle rechtfertigte die Wahl eines mit Zahlungsverarbeitung verbundenen Workflows.
Kosten- und Latenzhinweise aus dem Wettbewerb
AutoGen führte durch den LLM für jeden Turn zu zusätzlicher Latenz und mehr Tokenverbrauch. CrewAIs Wiederholungsversuche verdoppelten manchmal die Anzahl der Toolaufrufe. LangGraph hatte zwar stets geringe Kosten für das Schreiben von Checkpoints, gewann aber durch vorhersehbare Ausgaben. Bei Tausenden von Supportanfragen pro Tag ist Vorhersehbarkeit wichtiger als gelegentliche Sparmaßnahmen.
Teamkompetenzen und Rekrutierung
Die Nachfrage nach Fachkräften mit Erfahrung in „CrewAI“ ist geringer als die Nachfrage nach Experten für „State Machines plus LLMs“. LangGraph-Fähigkeiten lassen sich auf jeden expliziten Orchestrierer übertragen. Falls das Unternehmen Standards einführt, sollten übertragbare Konzepte wie Zustände, Idempotenz, HITL und Evaluierungen bevorzugt werden. Frameworks entwickeln sich schneller als solche Konzepte.
Erweiterung des Chaos-Setups
Mehr als nur Stoppen und Neustarten: Einfügen von 503-Fehlern am Gateway, doppelte Übertragungen von Webhooks, Zeitverschiebungen innerhalb von Policy-Fenstern sowie Menschen, die Eskalationen ablehnen. Graphen, die nur den „glücklichen“ Ablauf überstehen, bleiben weiterhin Spielzeuge. Automatisieren Sie das gesamte Setup in CI mit deterministischen Simulierungen, damit Refaktorisierungen nicht heimlich Sicherheitsmechanismen ausschalten.
Weicher Landeplatz für Prototypen
Bewahren Sie die Sandboxes von CrewAI/AutoGen für Content-Workflows mit menschlichen Editoren auf. Blockieren Sie nicht das Experimentieren – blockieren Sie stattdessen die Produktionsanmeldeinformationen. Eine Plattformrichtlinie, die besagt „keine Zahlungstools in prompt-gesteuerten Workflows“, verhindert weitere knappe Missgeschicke, ohne Neugierde zu unterdrücken.
Letzter Nachdruck
Die Behauptung des Artikels ist präzise und überzeugend: Bei der Automatisierung von Rückerstattungen mit echten Nebeneffekten hat LangGraph überlebt, wo CrewAI und AutoGen bei identischen Werkzeugen versagten. Extrapolieren Sie vorsichtig – aber extrapolieren Sie frei die zugrundeliegende Lektion: Bewerten Sie Frameworks anhand Ihrer eigenen Fehlermuster, nicht anhand von Demo-Aesthetik – dann war das Wettbewerbsszenario die Woche wert, die es in Anspruch nahm.
Detaillierte Zeitlinie der Fehler seit dem Staging
Woche eins: Die CrewAI-Demo beeindruckte die Interessengruppen. Woche zwei: Zwei Versuche einer doppelten Rückerstattung im Staging-Bereich nach Ausfällen des Gateways. Woche drei: Der AutoGen-Pilot verbrauchte Token bei wiederholten Anfragen für abgelehnte Bestellungen. Woche vier: Das LangGraph-Chaos-Management aktivierte die Funktion zur Stoppung der Rückerstattung mitten im Prozess. Der Zeitplan ist wichtig, denn die organisatorische Dynamik friert oft bei der ersten Demo ein; dokumentieren Sie den Zeitverlauf der Fehler im ADR, damit die Dynamik keine Beweise löschen kann.
Idempotenz als durchgängige Anforderung
Jedes hier getestete Framework kann Tools aufrufen. Nur Designs, die bei Wiederholungsversuchen eine stabile Schlüsselverwaltung nutzen, sind im Umgang mit Zahlungen sicher. Speichern Sie den Schlüssel im Graphenzustand vor dem ersten Versuch. Weigern Sie sich, bei Wiederholungsversuchen einen neuen Schlüssel zu erstellen. Protokollieren Sie zusammen mit dem Schlüssel, der Bestellnummer und den Gateway-Antwortcodes. Wenn ein Framework dies erschwert, ist diese Schwierigkeit ein Signal – kein Problem mit den Papierarbeiten.
Ergonomie bei der Übertragung an Menschen
Der Eskalationstext muss Policy-Klausel-IDs, Zeitstempel der Bestellungen sowie die Anzahl früherer Rückerstattungen enthalten – Strukturen aus dem State, nicht nur freie Prosa. Manager sollten dieselben Felder sehen wie der Policy-Node. LangGraph macht das einfach, weil State ein TypedDict ist; Crew/AutoGen erforderte die Rekonstruktion von Fakten aus Transkripten, wodurch Prüflücken entstehen.
Was wir von den weniger erfolgreichen Ansätzen übernommen haben
Die Rollenmetaphern von CrewAI halfen bei Produktgesprächen – sie wurden in LangGraph-Node-Names umgewandelt. Die explizite Agentenliste von AutoGen führte zu einer klareren Zuordnung der Tools pro Node. Das Übernehmen von UX-Ideen bei Ablehnung unsicherer Steuerungsmechanismen ist zulässig.
Erweiterte Produktions-Checkliste
- Katastrophenfall: Abbruch während der Tool-Nutzung, während des Wartens auf Unterbrechungen oder während des Retry-Backoffs.
- Eigenschaftstests: Inkompatible Fälle erreichen niemals den Rückerstattungs-Node.
Warum „einfach einen weiteren Agent hinzufügen“ fehlgeschlagen ist
Das Hinzufügen eines „PolicyEnforcer“-Agents in CrewAI ließ die Durchsetzung der Regeln weiterhin probabilistisch. Das Hinzufügen eines „RefundGuardian“ in AutoGen blieb auf der Ebene des Chats. Guardians, die Kanten nicht fest blockieren können, sind lediglich dekorativ. Die feste Blockierung gehört in die Graph-Topologie.
Fazit
Dieselben Werkzeuge, dasselbe Modell – unterschiedliche Steuerungsphilosophie. Nur das explizite Diagramm überstand die Fehler, die für Rückerstattungen relevant sind. Verwenden Sie Teams und Chats, in denen eine falsche Reihenfolge günstig ist; verwenden Sie Diagramme, bei denen eine falsche Reihenfolge ein Buchungsevent darstellt. Veröffentlichen Sie diese Regel intern, um dem nächsten Team eine vierwöchige Herausforderung zu ersparen.
Weitere Hinweise zur Stärkung von Rückerstattungsdiagrammen
Politikfenster, die von Uhren abhängen, müssen die beim Abrufen gespeicherte Serverzeit verwenden und nicht die im Modell angegebenen Datumsangaben. Kategorienprüfungen sollten als Mitgliedschaft im Code festgelegt werden. Die Anzahl der vorherigen Rückerstattungen stammt aus dem Buchungssystem, nicht aus der Chat-Erinnerung. Jede dieser Entscheidungen beseitigt eine Art von Prompt-Injektion, die versucht, die Eignung in natürlicher Sprache umzuschreiben. Diagramme machen diese Entscheidungen sichtbar; Teams verstecken sie in den Hintergrundgeschichten der Agenten, wo die Prüfer nicht mehr hinschauen.