Verwaltete Desktop-Automatisierung

adk-computer-use ist eine Governance-Schicht über dem computer-use-mcp Desktop-Automatisierungsserver. Sie führt selbst keine Aktuierung aus: Sie ordnet Beobachtung, Freigabe, Mutation und Verifikation als deterministischen Graphen an und prüft, was die externe Laufzeit zurückgibt.

Antwortbindung

Die externe Laufzeit ist maßgeblich, aber ihre Antworten werden lokal geprüft, bevor sie in den Graphzustand eingehen. Die Prüfungen laufen im Referenzgraphen für jede ComputerUseRuntime-Implementierung, und der MCP-Adapter wiederholt sie an seiner Direktaufruf-Grenze. Typisierte Deserialisierung beweist die Form, nicht die Herkunft — ControlLease, TargetReservation und ExecutionReceipt haben keinen Konstruktor, der Invarianten erzwingt, sodass ein wohlgeformtes Objekt aus einer anderen Sitzung sauber geparst wird.

Jede Antwort wird wieder an die Anfrage gebunden, die sie erzeugt hat:

Eine Abweichung erzeugt ComputerUseError::IdentityMismatch, das das Feld benennt, und die Antwort wird abgelehnt statt gespeichert.

use adk_computer_use::runtime::binding::validate_lease;

// Refuses a lease that is well-formed but belongs to another session.
validate_lease(&lease, &envelope)?;

Hinweis: Der Digest ist die stärkste verfügbare Bindung. args_digest ist der Wert, gegen den die Genehmigung erteilt wurde, daher beschreibt eine Quittung mit einem anderen Digest andere Arbeit, selbst wenn jeder Bezeichner übereinstimmt.

Ein optionales Feld, das bei der Rückgabe fehlt, wird als Unter-Spezifikation und nicht als Widerspruch behandelt; ein Feld, das vorhanden und anders ist, ist eine Abweichung.

Revalidierung zur Laufzeit

Preview ist keine Autorität für Mutationen. Der Referenzgraph validiert alle Mutations-Eingaben im execute-Knoten unmittelbar vor dem Aufruf von execute_action:

Die Umschlagprüfung wird auch ausgeführt, wenn die Vorschau zurückkehrt, sodass eine bereits abgelaufene Vorschau niemals zur Reservierung oder Genehmigung gelangt. Sie wird bei der Ausführung erneut ausgeführt, da eine Genehmigungsunterbrechung, eine Ziel- Reservierung oder der Erwerb eines Leases das verbleibende Gültigkeitsfenster verbrauchen kann.

ComputerUseMcpRuntime behält den exakten Umschlag bei, der von preview_action zurückgegeben wurde. Ein direkter execute_action-Aufruf wird abgelehnt, wenn sich nach der Vorschau irgendein Umschlagfeld ändert, selbst wenn die Aktions-ID weiterhin übereinstimmt.

Für das Fortsetzen von Checkpoints speichert der Graph die Laufzeitvorschau in einem nur anhängbaren State-Channel. Genehmigung und Ausführung erfordern, dass dieser Channel genau eine Vorschau enthält, die mit der aktiven Vorschau übereinstimmt. Wiederaufnahme-Eingaben können Zustand hinzufügen, aber den checkpointierten Wert nicht ersetzen: Ein versuchter Ersatz erzeugt einen zweiten Eintrag und schlägt vor Reservierung oder Mutation fehl.

Bereinigungslogik für Reservierungen

Sobald eine Reservierung akzeptiert wurde, versucht jeder terminale Pfad, sie freizugeben:

• Fehler beim Erwerb des Leases, bei Autorisierung, Validierung, Ausführung, Quittung und Verifikation;
• erfolgreiche Verifikation; und
• Fehler bei der Reservierungsvalidierung oder Serialisierung, wenn die Laufzeit eine Reservierung zurückgegeben hat.

Der primäre Fehler bleibt primär, wenn die Bereinigung gelingt. Wenn auch die Bereinigung fehlschlägt, gibt der Graph einen deterministischen Fehler zurück, der beide Fehler enthält. Ein Bereinigungsfehler nach ansonsten erfolgreicher Verifikation wird als Fehler zurückgegeben und nicht verborgen.

Verifikation ist keine Zusage

ComputerUseRuntime::verify gibt ein VerificationOutcome zurück, kein boolesches Ergebnis:

Der verify-Knoten des Graphen schreibt verified, committed und eine result.verificationDetail, die alles außer Verified erklärt.

Wichtig: Eine bestätigte Quittung ist eine Bestätigung, dass die Aktion angenommen und ausgeführt wurde. Sie ist kein Beweis dafür, dass die beabsichtigte Wirkung eingetreten ist. verify hat zuvor receipt.status == Committed zurückgegeben, was eine bestätigte, aber wirkungslose Aktion als abgeschlossen gemeldet hat — von einem Knoten mit der Bezeichnung "verify".

Was als Beweis gilt

Für eine Nachbedingung, die einen Digest deklariert (valueDigest, contentDigest), erfordert die Verifikation eine verification.observedDigest im Ergebnis der Quittung, die damit übereinstimmt. Für eine Nachbedingung, die nur Existenz deklariert, ist eine explizite verification.satisfied: true erforderlich.

Abwesenheit von Belegen wird niemals als Beleg für Erfolg behandelt. Wenn computer-use-mcp vor dem Ausstellen einer Quittung verifiziert, dann ist das sein Vertrag; dieser Adapter nimmt das nicht an.

Mietgrenzen

Eine Mietanfrage wird abgelehnt, sofern nicht alle dieser Bedingungen erfüllt sind:

Leere Begrenzungen bedeuten „nicht eingeschränkt“ und autorisieren jedes Ziel — das Fehlen einer Einschränkung ist keine Einschränkung auf nichts.

Wichtig: Die erste Version dieses Validators prüfte action_budget == 0, was das Gesamt-Budget ist, sodass ein Lease mit action_budget: 1, actions_used: 1 bestanden wurde, während nichts autorisiert wurde. Außerdem las er nie expires_at oder boundaries, sodass sowohl ein abgelaufenes Lease als auch ein Lease, das auf eine andere Anwendung beschränkt war, akzeptiert wurden. Ein nicht analysierbares Ablaufdatum wird abgelehnt statt ignoriert: Ein Lease, dessen Gültigkeit nicht festgestellt werden kann, ist nicht gültig.