LangGraph vs AutoGPT (Production-Vergleich) + Code

  • Wähle richtig, ohne Demo-getriebene Reue.
  • Sieh, was in Prod bricht (Ops, Kosten, Drift).
  • Migration + Entscheidungs-Checkliste bekommen.
  • Defaults mitnehmen: Budgets, Validation, Stop-Reasons.
AutoGPT-style Autonomie ist lustig, bis es loopen und dich abrechnen lässt. LangGraph-style Flows sind weniger magisch, aber governable. Wo es in Prod bricht — und wie du’s sicher machst.
Auf dieser Seite
  1. Problem (aus der Praxis)
  2. Schnelle Entscheidung (wer sollte was wählen)
  3. Warum man in Prod die falsche Wahl trifft
  4. Vergleichstabelle
  5. Wo das in Production bricht
  6. Implementierungsbeispiel (echter Code)
  7. Echter Incident (mit Zahlen)
  8. Migrationspfad (A → B)
  9. Entscheidungshilfe
  10. Abwägungen
  11. Wann du es NICHT nutzen solltest
  12. Checkliste (Copy/Paste)
  13. Sicheres Default-Config-Snippet (JSON/YAML)
  14. FAQ (3–5)
  15. Verwandte Seiten (3–6 Links)

Problem (aus der Praxis)

AutoGPT ist der Archetyp von “lass es laufen”. LangGraph ist der Archetyp von “mach den Loop explizit”.

In Prod zählt diese Philosophie mehr als API-Details. Eins optimiert für Autonomie. Das andere für Kontrolle.

Wenn du echte User und echte Budgets hast: erst Kontrolle verdienen, dann Autonomie.

Schnelle Entscheidung (wer sollte was wählen)

  • LangGraph: wenn du Replay, Tests, und explizite Stop Reasons brauchst. Sicherer Default.
  • AutoGPT-style Autonomie: nur wenn Risk niedrig ist und Budgets/Monitoring/Kill Switches schon stehen.
  • Multi-Tenant + Writes: nicht mit “let it run” starten.

Warum man in Prod die falsche Wahl trifft

  • Autonomie wird überbewertet: in Prod heißt das oft Tool Spam + Budget Explosion.
  • “Boring code” wird unterschätzt: explizite Flows sind debugbar um 03:00.
  • Control Layer fehlt: Budgets/Permissions/Validation/Stop Reasons sind nicht optional.

Vergleichstabelle

| Kriterium | LangGraph-style | AutoGPT-style | Prod-Relevanz | |---|---|---|---| | Kontrolle | Hoch | Niedrig/mittel | Runaway Loops stoppen | | Debuggability | Hoch | Niedrig | Replay + Trace | | Kosten | besser | schlechter | Spend spikes | | Outage Amplification | geringer | höher | Abhängigkeiten schützen |

Wo das in Production bricht

Autonomie bricht:

  • “one more try” loops
  • Retries auf mehreren Ebenen
  • Tool Space wird “explored”

Explizite Flows brechen:

  • State Machine wächst
  • trotzdem keine Validation
  • zu viel im Prompt, zu wenig in Code

Implementierungsbeispiel (echter Code)

Autonomie braucht Sandbox: Budgets + Tool Allowlist + Stop Reasons.

PYTHON
from dataclasses import dataclass
from typing import Any
import time


@dataclass(frozen=True)
class Budgets:
  max_steps: int = 30
  max_seconds: int = 90
  max_tool_calls: int = 15


class Stop(RuntimeError):
  def __init__(self, reason: str):
      super().__init__(reason)
      self.reason = reason


class GuardedTools:
  def __init__(self, *, allow: set[str]):
      self.allow = allow
      self.calls = 0

  def call(self, tool: str, args: dict[str, Any], *, budgets: Budgets) -> Any:
      self.calls += 1
      if self.calls > budgets.max_tool_calls:
          raise Stop("max_tool_calls")
      if tool not in self.allow:
          raise Stop(f"tool_denied:{tool}")
      return tool_impl(tool, args=args)  # (pseudo)


def run(task: str, *, budgets: Budgets) -> dict[str, Any]:
  tools = GuardedTools(allow={"search.read", "kb.read", "http.get"})
  started = time.time()

  for _ in range(budgets.max_steps):
      if time.time() - started > budgets.max_seconds:
          return {"status": "stopped", "stop_reason": "max_seconds"}
      action = llm_decide(task)  # (pseudo)
      if action.kind == "final":
          return {"status": "ok", "answer": action.final_answer}
      try:
          obs = tools.call(action.name, action.args, budgets=budgets)
      except Stop as e:
          return {"status": "stopped", "stop_reason": e.reason}
      task = update(task, action, obs)  # (pseudo)
  return {"status": "stopped", "stop_reason": "max_steps"}
JAVASCRIPT
export class Stop extends Error {
constructor(reason) {
  super(reason);
  this.reason = reason;
}
}

export class GuardedTools {
constructor({ allow = [] } = {}) {
  this.allow = new Set(allow);
  this.calls = 0;
}

call(tool, args, { budgets }) {
  this.calls += 1;
  if (this.calls > budgets.maxToolCalls) throw new Stop("max_tool_calls");
  if (!this.allow.has(tool)) throw new Stop("tool_denied:" + tool);
  return toolImpl(tool, { args }); // (pseudo)
}
}

Echter Incident (mit Zahlen)

Autonomer Research-Agent ohne harte Budgets. Er suchte, bis er “confident” war.

Impact:

  • ein Run: ~17 Minuten
  • tool calls: ~140
  • spend: ~$74
  • User retryten, weil UI “stuck” wirkte → Kosten multipliziert

Fix: Budgets + degrade mode + Stop Reasons in UI.

Migrationspfad (A → B)

  • AutoGPT → LangGraph: instrumentieren, happy path explizit codieren, autonomy nur bounded als Branch.
  • LangGraph → mehr Autonomie: risky Transitions explizit lassen, autonomy nur in bounded Investigation Nodes.

Entscheidungshilfe

  • Predictable behavior → explicit flow.
  • Exploration, aber bounded → autonomy branch.
  • Ohne Monitoring/Spend-Metering → keine Autonomie.

Abwägungen

  • Explizite Flows brauchen mehr upfront Engineering.
  • Autonomie löst weird tasks, erhöht operational risk.
  • Hybrid ist oft best.

Wann du es NICHT nutzen solltest

  • Keine Autonomie mit Write Tools in Multi-Tenant Prod.
  • Graphs sind keine Ausrede, Validation/Monitoring zu skippen.
  • Framework ist keine Governance.

Checkliste (Copy/Paste)

  • [ ] Happy path explizit
  • [ ] Autonomie bounded
  • [ ] Default-deny Tools
  • [ ] Stop Reasons
  • [ ] Monitor tool_calls/run und spend/run
  • [ ] Kill Switch (writes/expensive tools)

Sicheres Default-Config-Snippet (JSON/YAML)

YAML
mode:
  default: "explicit_flow"
autonomy:
  allowed_for: ["investigation_nodes"]
budgets:
  max_steps: 30
  max_seconds: 90
  max_tool_calls: 15
tools:
  allow: ["search.read", "kb.read", "http.get"]
writes:
  require_approval: true

FAQ (3–5)

Ist AutoGPT ‘schlecht’?
Nein. Gut für Exploration. Prod braucht nur Governance, sonst wird’s teuer.
Garantieren Graphs correctness?
Nein. Sie geben Struktur. Validation + Guardrails bleiben Pflicht.
Welche Metric zuerst?
Tool calls/run. Driften früh, wenn Autonomie thrash’t.
Kann man Autonomie sicher nutzen?
Ja: Budgets + Allowlists + Stop Reasons als Minimum.

Nicht sicher, ob das dein Fall ist?

Agent gestalten ->
⏱️ 5 Min. LesezeitAktualisiert Mär, 2026Schwierigkeit: ★★☆
Integriert: Production ControlOnceOnly
Guardrails für Tool-Calling-Agents
Shippe dieses Pattern mit Governance:
  • Budgets (Steps / Spend Caps)
  • Tool-Permissions (Allowlist / Blocklist)
  • Kill switch & Incident Stop
  • Idempotenz & Dedupe
  • Audit logs & Nachvollziehbarkeit
Integrierter Hinweis: OnceOnly ist eine Control-Layer für Production-Agent-Systeme.
Autor

Diese Dokumentation wird von Engineers kuratiert und gepflegt, die AI-Agenten in der Produktion betreiben.

Die Inhalte sind KI-gestützt, mit menschlicher redaktioneller Verantwortung für Genauigkeit, Klarheit und Produktionsrelevanz.

Patterns und Empfehlungen basieren auf Post-Mortems, Failure-Modes und operativen Incidents in produktiven Systemen, auch bei der Entwicklung und dem Betrieb von Governance-Infrastruktur für Agenten bei OnceOnly.