ThumbAgent

Lokale First-Plattform, die KI-Agenten einen echten Daumen auf mobilen Geräten gibt.

中文 | English

Lokale First-, plattformübergreifende Mobile-Device-Skills-Plattform für KI-Agenten.

Aktueller Fortschritt

Das Projekt hat ITER-0052 Desktop Device Screen & Live Observation abgeschlossen: Der Desktop-Arbeitsplatz zeigt während der Ausführung von Agent-Aufgaben ein Gerätebildschirm-Panel, das nach jeder Runde den echten Screenshot nach der Aktion in Echtzeit aktualisiert; der Aufgabenbericht kann die Screenshot-Nachweise pro Runde aufklappen. Die Runtime hat einen neuen schreibgeschützten Inhalts-Endpunkt GET /v1/artifacts/{artifact_id}/content (Bearer-token-Authentifizierung, nur Screenshot-PNG, Dateilimit 8 MiB, no-store) hinzugefügt, und das Ereignis task.step_completed trägt die screenshot_artifact_id dieser Runde.

Der Desktop-Arbeitsplatz (Tauri 2) startet und authentifiziert automatisch die lokale Runtime, die Startseite zeigt eine einheitliche Bereitschaftsdiagnose und die Liste der erkannten Geräte, unterstützt die Einreichung von Aufgaben in natürlicher Sprache, eine Ausführungs-Timeline und vollständige Berichte. Die Desktop-Entwicklung siehe apps/desktop/README.md. Python 3.11+ verwenden:

make check
make run

Die Runtime lauscht standardmäßig auf 127.0.0.1:8765 und bietet /v1/health, /v1/devices und POST /v1/devices/{device_id}/observe.

Related MCP server: Android MCP Server

MCP-Skills-Entwicklervorschau

Für die lokale Abnahme auf echten Geräten mit macOS + Codex-Desktop kann das Ein-Klick-Skript verwendet werden:

./scripts/run-mcp-preview.zsh

Beim ersten Lauf fordert das Skript zur Eingabe des Modell-Keys auf und speichert den Modell-Key sowie ein stabiles lokales Runtime-Token getrennt im macOS-Login-Keychain; bei späteren Starts wird nicht erneut gefragt. Das Skript stoppt sicher den alten mobile_agent.api.server, der den Zielport belegt, verwendet die unveränderte MCP-Registrierung erneut und startet eine neue Runtime. Wenn Codex/ChatGPT bereits läuft, muss es nicht geschlossen oder neu geöffnet werden. Nur bei der ersten Registrierung, bei explizitem --refresh-mcp, bei Änderungen der MCP-Konfiguration oder des Tool-Katalogs muss ein laufendes Codex einmal neu gestartet und eine neue Aufgabe erstellt werden, um die zwischengespeicherte MCP-Umgebung zu aktualisieren; ein normaler Runtime-Neustart ist nicht erforderlich.

Der Modell-Key gelangt nur in den Keychain und die Prozessumgebung der Runtime, nicht in das Repository oder die Skriptausgabe. Das Skript bleibt im Vordergrund; mit Ctrl+C wird die Runtime gestoppt. Wenn nur Python, ADB, Codex und der Modellkonfigurationspfad geprüft werden sollen, ohne Schlüssel zu lesen oder die MCP-Konfiguration zu ändern, verwenden Sie:

./scripts/run-mcp-preview.zsh --check

Wenn die MCP-Registrierung erzwungen aktualisiert oder das Vorschau-Secret gelöscht werden soll:

./scripts/run-mcp-preview.zsh --refresh-mcp
./scripts/run-mcp-preview.zsh --forget-secrets

Die Aktualisierung der Registrierung rotiert das Token im Keychain nicht. Wenn der Zielport von einem anderen Programm belegt ist, verweigert das Skript das versehentliche Beenden; es stoppt nur automatisch Prozesse, die in der Befehlszeile eindeutig zu mobile_agent.api.server gehören.

Damit Web, CLI und MCP dieselbe Runtime gemeinsam nutzen, starten Sie den Dienst mit einem expliziten lokalen Token:

MOBILE_AGENT_API_TOKEN=<local-random-token> \
MOBILE_AGENT_ADB_PATH=/usr/local/platform-tools/adb \
make run

Konfigurieren Sie dann im MCP-Host einen stdio-Server mit demselben Token. Ein Beispiel finden Sie unter mcp-server.example.json. Der tatsächlich vom MCP-Host gestartete Befehl lautet:

PYTHONPATH=runtime \
MOBILE_AGENT_API_TOKEN=<same-local-random-token> \
python3.11 -m mobile_agent.mcp

MCP bietet zielgerichtete Tools, die Bereitschaftsdiagnose, Geräte- und installierte-App-Prüfung, App-Lebenszyklus, asynchrone Agent-Aufgaben, Aufgabenabfrage/-abbruch, entschärfte Protokolle, aggregierte Leistungssnapshots, Diagnose-Nachweispakete, Leistungsvergleiche und lokale Artifact-Aufbewahrungsbereinigung abdecken. Es werden keine ADB-, beliebige Shell-, beliebige Dateipfad- oder atomaren Tools wie input.tap bereitgestellt. Aktionen, die eine Bestätigung erfordern, dürfen nur dann mit confirmed=true übergeben werden, wenn der MCP-Host dem Benutzer die Parameter und Auswirkungen bereits angezeigt und eine Bestätigung erhalten hat.

Nach dem Start kann die einheitliche Bereitschaftsdiagnose angezeigt werden:

PYTHONPATH=runtime python3.11 -m mobile_agent.cli.runtime_diagnose

GET /v1/readiness und die Web-UI zeigen Android-Gateway, Geräteverbindung/-autorisierung, Session, Lease-Belegung und Reparaturempfehlungen. Wenn ADB nicht installiert ist oder der Pfad falsch ist, startet die Runtime trotzdem die Diagnoseoberfläche und beendet sich nicht mehr direkt mit ADB_NOT_FOUND.

Aktuelle Fähigkeiten, Risiken, Bestätigungsanforderungen und Einschränkungen eines einzelnen Geräts anzeigen:

PYTHONPATH=runtime python3.11 -m mobile_agent.cli.device_inspect <device_id>

MCP bietet außerdem die schreibgeschützten mobile_list_apps und mobile_inspect_app zum begrenzten Auflisten von App-Identifikatoren und zum Abfragen von Version, Installationsquelle und Aktivierungsstatus einer einzelnen App. Sie geben keine APK-Pfade, Signaturen, Berechtigungen oder rohe dumpsys-Ausgaben zurück und starten oder ändern keine Apps.

Die lokale APK-Installation akzeptiert nur eine einzelne .apk im Verzeichnis <data-dir>/apks. Ein externer Agent muss zuerst mobile_prepare_apk_install aufrufen, um eine kurzfristige Genehmigung mit Dateiname, Größe, SHA-256, Manifest-Paket-ID und Ersetzungsauswirkungen zu erhalten; der MCP-Host muss dem Benutzer diese Zusammenfassung anzeigen und eine eindeutige Bestätigung einholen, bevor mobile_install_apk aufgerufen werden kann. Die Genehmigung läuft nach zehn Minuten ab und kann standardmäßig nur einmal verwendet werden. Die Runtime lädt keine URLs herunter und akzeptiert keine Split-APKs oder beliebigen ADB-Parameter.

Die Deinstallation von Apps verwendet einen separaten zweistufigen Prozess mobile_prepare_app_uninstall → mobile_uninstall_app. Prepare gibt schreibgeschützt die App-Version, die System-App-Bewertung und die Auswirkungen der Datenlöschung zurück; System-Apps oder Apps mit unbekannten Eigenschaften werden direkt abgelehnt. Der Benutzer muss diese Zusammenfassung erneut eindeutig bestätigen, bevor eine asynchrone Deinstallationsaufgabe eingereicht werden kann. Bei Fehlern oder unbekanntem Ergebnis darf nicht automatisch erneut versucht werden.

Der App-Lebenszyklus bietet mobile_inspect_app_state, mobile_launch_app und mobile_stop_app. Die Statusprüfung gibt nur zurück, ob der Prozess existiert, ob er im Vordergrund ist und das stopped-Flag; Start und Stopp geben eine asynchrone task_id zurück, und vor dem Stoppen einer Nicht-System-App muss eine eindeutige Bestätigung erfolgen. Zum dauerhaften Löschen von App-Daten muss zuerst mobile_prepare_app_data_clear aufgerufen werden, das Paketname, Version und Auswirkungen der Datenlöschung anzeigt und eine neue eindeutige Bestätigung einholt, bevor mobile_clear_app_data aufgerufen wird. Das Löschen von App-Daten deinstalliert die App nicht; bei Fehlern oder unbekanntem Ergebnis darf nicht automatisch erneut versucht werden.

Nach expliziter Bestätigung wird ein Snapshot der letzten Protokolle erfasst (das lokale API-Token, das beim Runtime-Start generiert wurde, muss übergeben werden):

PYTHONPATH=runtime python3.11 -m mobile_agent.cli.device_logs_collect \
  <device_id> --max-lines 500 --minimum-level info --confirm --token <runtime-token>

Die Protokolle werden zuerst entschärft und dann als lokales Artifact mit maximal 1 MiB gespeichert; CLI und REST geben den Protokolltext nicht zurück. Mit --async-task kann sofort eine task_id erhalten werden, und der einheitliche Ausführungsstatus, Ereignisse, Abbruch und Aufgabenberichte werden verwendet:

PYTHONPATH=runtime python3.11 -m mobile_agent.cli.device_logs_collect \
  <device_id> --confirm --async-task --deadline-seconds 60 --token <runtime-token>

Aggregierte CPU-, Speicher-, Batterietemperatur- und Systemlast-Snapshots erfassen:

PYTHONPATH=runtime python3.11 -m mobile_agent.cli.device_performance_snapshot \
  <device_id> --async-task --deadline-seconds 90 --token <runtime-token>

Das Leistungs-Artifact enthält nur aggregierte JSON-Metriken, keine dumpsys-Rohdaten, Prozessnamen oder App-Details.

Einmalige Erfassung von Screenshot, UI-Tree, entschärften Protokollen, aggregierter Leistung und optionalem App-Status sowie Erstellung eines lokalen ZIP mit SHA-256-Manifest:

PYTHONPATH=runtime python3.11 -m mobile_agent.cli.diagnostic_bundle_collect \
  <device_id> --app-id <package-id> --max-log-lines 500 \
  --minimum-log-level info --confirm --token <runtime-token>

Das Diagnosepaket ist ein Medium-Risiko und muss eindeutig bestätigt werden. CLI, Web, REST und MCP geben nur Artifact-Metadaten und eine Sicherheitszusammenfassung zurück, keine Inline-Screenshots, UI-Trees, Protokolle oder ZIP-Inhalte; die Dateinamen im Paket sind fest, die Gesamtgröße überschreitet 24 MiB nicht, und es wird nichts hochgeladen oder nach außen gesendet.

Lokale Artifact-Belegung anzeigen und schreibgeschützt eine Vorprüfung der Nachweise durchführen, die den standardmäßigen Aufbewahrungszeitraum von 7 Tagen überschreiten:

PYTHONPATH=runtime python3.11 -m mobile_agent.cli.local_storage
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.local_data_cleanup_prepare \
  --retention-days 7 --max-artifacts 500 --token <runtime-token>

Prepare löscht keine Dateien, sondern gibt nur Kandidatenanzahl, Größe, Fälligkeitsdatum und eine kurzfristige Genehmigung zurück. Erst nachdem der Benutzer die Auswirkungszusammenfassung geprüft und erneut eindeutig bestätigt hat, kann eine asynchrone Bereinigungsaufgabe eingereicht werden:

PYTHONPATH=runtime python3.11 -m mobile_agent.cli.local_data_cleanup \
  <approval-id> --confirm --token <runtime-token>

Die Bereinigung akzeptiert nur systemgenerierte Artifact-IDs, relative Pfade, Größen und SHA-256, die in der Genehmigung gebunden sind; keine beliebigen Pfade, keine Löschung der Aufgabendatenbank, Konfiguration, Schlüssel oder APKs, kein automatischer Hintergrundbetrieb und kein automatischer Wiederholungsversuch bei Fehlern.

Zwei abgeschlossene Leistungssnapshot-Aufgaben auf demselben Gerät vergleichen:

PYTHONPATH=runtime python3.11 -m mobile_agent.cli.device_performance_compare \
  <baseline_task_id> <candidate_task_id> --token <runtime-token>

Der Web-Aufgabenbericht kann auch einen erfolgreichen Snapshot als Baseline festlegen und dann einen anderen Snapshot zum Vergleich auswählen. Das Vergleichsergebnis zeigt nur die numerische Richtung und die Stabilitätsschwelle der zwei Stichprobenpunkte und beurteilt nicht automatisch Kausalität oder Leistungsrückgang.

Wenn adb nicht im PATH ist, kann es explizit konfiguriert werden:

MOBILE_AGENT_ADB_PATH=/usr/local/platform-tools/adb

ITER-0003 fügt GET /v1/tools, POST /v1/tools/{tool_id}/invoke und POST /v1/skills/app.open/invoke hinzu. input.tap ist ein Medium-Risiko und erfordert standardmäßig eine eindeutige Bestätigung.

ITER-0004 fügt sicheres UI-Hierarchie-Parsing, semantische Selektoren, input.tap_element und POST /v1/skills/settings.navigate/invoke hinzu. Semantisches Tippen ist ein Medium-Risiko; bei nicht eindeutigen Übereinstimmungen wird die Ausführung abgelehnt.

ITER-0005 fügt richtliniengebundenes input.swipe, input.text, begrenzte semantische Scroll-Suche und POST /v1/skills/settings.scroll_navigate/invoke hinzu. Scrollen und Eingaben sind Medium-Risiko und erfordern standardmäßig eine eindeutige Bestätigung; Passwörter, Verifizierungscodes, Zahlungen, Kontosicherheit und automatische Übermittlungsszenarien liegen außerhalb des Umfangs dieser Iteration.

ITER-0006 fügt einen minimalen Task-Runner, TaskRun-Nachweisberichte und den Vorschau-Synchron-Endpunkt POST /v1/tasks/settings.scroll_navigate/run hinzu. Dieser Endpunkt kapselt nur den vorhandenen settings.scroll_navigate-Skill und ersetzt nicht das spätere asynchrone Aufgabenwarteschlangen-Design.

ITER-0007 fügt einen In-Process-Task-Store, TaskEvent und die Abfrage-Endpunkte GET /v1/tasks/{task_id}, GET /v1/tasks/{task_id}/events hinzu. Dieser Store ist nur während des Lebenszyklus des aktuellen Runtime-Prozesses gültig und bietet noch keine Wiederherstellung nach Neustart.

ITER-0008 fügt die erste CLI-Aufgabenberichtsansicht hinzu, die TaskRun und TaskEvent als benutzerlesbaren Bericht rendern kann:

PYTHONPATH=runtime python3.11 -m mobile_agent.cli.task_report <task_id>

Dieser Befehl fragt Aufgaben und Ereignisse von der lokalen Runtime-API ab.

ITER-0009 fügt einen SQLite-Task-Store hinzu, der Aufgaben und Ereignisse standardmäßig in <data-dir>/mobile-agent.db speichert. Wenn MOBILE_AGENT_DATA_DIR gesetzt ist, befindet sich die Datenbank in diesem Verzeichnis; andernfalls wird das plattformstandardmäßige lokale Datenverzeichnis verwendet.

ITER-0010 fügt eine Verlaufsliste der Aufgaben hinzu:

PYTHONPATH=runtime python3.11 -m mobile_agent.cli.task_list --limit 20

Die Liste zeigt Zusammenfassungen der letzten Aufgaben; die task_id kann kopiert und mit task_report für Details verwendet werden.

ITER-0011 fügt eine lokale Web-UI hinzu. Nach dem Start der Runtime öffnen:

http://127.0.0.1:8765/ui

Dann können der Aufgabenverlauf und die Aufgabenberichtdetails angezeigt werden.

ITER-0012 fügt in der Web-UI eine Schaltfläche „Sicheres Demo ausführen" hinzu. Diese Schaltfläche wählt ein Online-Android-Gerät aus und führt eine feste Aufgabe aus: Systemeinstellungen öffnen und zur Anzeige/Helligkeit-Seite wechseln. POST-Anfragen verwenden weiterhin das lokale Runtime-Token und dürfen nur von gleichherkunfts-Loopback-Seiten ausgelöst werden.

ITER-0013 fügt eine Agent-Loop-Vorschau vor der Modellintegration hinzu: POST /v1/tasks/agent.run. Dieser Endpunkt verwendet einen deterministischen Planner zur Erzeugung eingeschränkter Entscheidungen und unterstützt derzeit nur das sichere Demonstrationsziel „Zur Anzeige/Helligkeit-Seite der Systemeinstellungen wechseln" und schreibt Beobachtungszusammenfassungen, Planner-Entscheidungen, Skill-Ausführungsergebnisse und Nachweise in den Aufgabenbericht.

ITER-0014 fügt in der Web-UI ein Eingabefeld für natürliche Sprache und eine Schaltfläche „Agent-Vorschau ausführen" hinzu. Die Seite ruft POST /v1/tasks/agent.run auf und aktualisiert nach der Rückkehr der Aufgabe die Verlaufsliste und öffnet den Aufgabenbericht.

ITER-0015 fügt einen internen Vorschauvertrag für den LLM-Planner und MockLLMPlanner hinzu. Modellartige Ausgaben müssen zuerst eine strukturierte Analyse und Feldvalidierung durchlaufen, dann eine zweite Validierung durch die Skill-Allowlist des Agent-Runners; diese Iteration ruft keinen echten Modellservice auf und liest keine Modellschlüssel.

ITER-0016 fügt eine standardmäßig deaktivierte OpenAI-kompatible Planner-Provider-Vorschau hinzu. Der Provider kann Chat-Completions-Stil-Anfragen konstruieren, strukturierte Antworten über einen injizierbaren Transport analysieren und die Planner-Ausgabevalidierung von ITER-0015 wiederverwenden; die Standard-Runtime aktiviert keinen echten Provider, und Tests hängen nicht von Netzwerk oder Modellschlüsseln ab.

ITER-0017 fügt ein Konfigurationsgate für den Modell-Provider hinzu: Die Standardkonfiguration gibt weiterhin RuleBasedPlanner zurück; nur wenn openai_compatible explizit aktiviert ist, base_url, model und api_key_ref bereitgestellt werden und der Schlüssel über den injizierten SecretResolver aufgelöst wird, wird ein OpenAI-kompatibler Planner konstruiert. Diese Iteration integriert keine Standard-Runtime und liest keine echten Schlüssel.

ITER-0018 fügt einen schreibgeschützten Status-Endpunkt für den Modell-Provider hinzu: GET /v1/model-provider/status und ein „Modell-Provider"-Statuspanel in der Web-UI. Der Status zeigt nur, ob aktiviert, Provider, Modell und ob eine Schlüsselreferenz konfiguriert ist, und gibt keine echten Schlüssel oder den api_key_ref-Originaltext zurück; die Standard-Runtime aktiviert weiterhin kein echtes Modell.

ITER-0019 fügt das Lesen der lokalen Modellkonfiguration hinzu: Beim Start liest die Runtime <data-dir>/model-provider.json oder die durch MOBILE_AGENT_MODEL_CONFIG angegebene Datei und erlaubt MOBILE_AGENT_MODEL_*-Umgebungsvariablen, Konfigurationsfelder zu überschreiben. Die Konfigurationsdatei speichert nur api_key_ref; der Vorschau-SecretResolver löst nur env:MOBILE_AGENT_MODEL_SECRET_*-Referenzen auf; der Standard-Agent-Runner ruft weiterhin kein echtes Modell auf.

ITER-0020 integriert den Modell-Planner kontrolliert in die Standard-Runtime: Bei deaktivierter Konfiguration wird weiterhin der Regel-Planner verwendet; bei aktivierter Konfiguration und auflösbarer Schlüsselreferenz wird der OpenAI-kompatible Planner verwendet; bei aktivierter, aber nicht verfügbarer Konfiguration schlagen Agent-Aufgaben eindeutig mit MODEL_UNAVAILABLE fehl, ohne stillschweigend auf den Regel-Planner zurückzufallen. Modellausgaben müssen weiterhin strukturierte Analyse, Skill-Allowlist, Policy-Engine und Device-Gateway durchlaufen.

ITER-0021 erweitert die Modell-Provider-Statuskarte der Web-UI: Unterscheidung zwischen nicht aktiviert, integriert, Konfiguration nicht verfügbar und Konfiguration gelesen, und bei Nichtverfügbarkeit Hinweis auf Prüfung der Konfigurationsdatei, MOBILE_AGENT_MODEL_CONFIG und MOBILE_AGENT_MODEL_SECRET_*. Das Repository bietet ein Konfigurationsbeispiel: model-provider.example.json.

ITER-0022 aktualisiert die Agent-Vorschau von „ein Runden-Modellentscheidungsaufruf mit großem Skill" auf „mehrere Runden Modellentscheidung + atomare Tool-Ausführung + erneute Beobachtung pro Runde". Der Planner kann run_tool, finish ausgeben; die Runtime erlaubt nur Whitelist-Tools und führt bei finish eine deterministische Verifizierung über UI-Selektoren durch; der alte run_skill-Pfad bleibt kompatibel.

ITER-0023 hebt AgentObservationSummary, AgentDecision und AgentStepResult in den Rundenberichten des Agenten auf öffentliche JSON-Schemas und aktualisiert das TaskRun-Schema zur formalen Unterstützung von agent.run. Desktop, CLI und zukünftige externe Agenten können mehrrundige Observe–Plan–Act-Berichte stabil konsumieren.

ITER-0024 fügt Fortschrittsfeedback für Agent-Aktionen hinzu: Die Runtime vergleicht die Vordergrund-App und den UI-Tree vor und nach dem Tool, gibt changed / unchanged-Feedback an die nächste Runde des Modells und verhindert die erneute Zuweisung derselben nicht fortschreitenden Aktion. Der Web-Bericht zeigt synchron das tatsächliche Tool, die Parameter und den Seitenfortschritt.

ITER-0025 optimiert die Beobachtung auf Modellseite: Filtert semantisch bedeutungslose Layout-Knoten, bevorzugt sichtbaren Text und bedienbare Knoten, ergänzt Zusammenfassungs-Trunkierungsmetadaten und entschärft häufige Telefonnummern, E-Mail-Adressen und lange numerische Identifikatoren im UI-Text, bevor er in den Modell-Prompt und die Aufgaben-Zusammenfassung gelangt.

ITER-0026 fügt einen strengen Agent-ToolCall-Vertrag, eine begrenzte Reparatur ungültiger Modellparameter und die Aufbewahrung von Nachweisen für fehlgeschlagene Runden hinzu. Auf echten Geräten wurde der mehrrundige Modell-Loop „Anzeige und Helligkeit öffnen" abgeschlossen.

ITER-0027 schafft die Grundlage für zielgetriebene Online-Agent-Evaluierung: Das echte Modell plant jedes Mal neu basierend auf der aktuellen Geräteoberfläche; die Evaluierung beschränkt nur Ziel, Endzustand, verbotene Tools und Rundenbudget, nicht feste Aktionspfade. Abgeschlossene agent.run-Aufgaben können über POST /v1/tasks/{task_id}/evaluate evaluiert werden; ein Szenariobeispiel befindet sich in agent-evaluation-scenario.example.json.

ITER-0042 organisiert mehrere pfadunabhängige Szenarien in versionierten Suites. Zuerst werden die Ziele der Suite über Web oder MCP einzeln ausgeführt, dann werden die abgeschlossenen task_ids an das schreibgeschützte Aggregations-CLI übergeben; dieser Befehl ruft nur die vorhandenen Evaluierungs-APIs auf und übermittelt oder wiederholt keine Geräteaktionen:

./scripts/report-mcp-evaluation.zsh \
  --suite evaluations/android-settings-smoke-v1.json \
  --task settings.bluetooth.v1=task_<id> \
  --task settings.display-brightness.v1=task_<id> \
  --task settings.battery.v1=task_<id>

Der Bericht zeigt die Gesamterfolgsrate, die Erfolgsrate pro Szenario, p50/p95 der Dauer, die durchschnittliche Runden- und Tool-Anzahl sowie Provider-Wiederholungen, NO_PROGRESS, MODEL_UNAVAILABLE und Richtlinienverletzungsstatistiken. Die Suite definiert Ziele und unabhängige Erfolgsbedingungen, keine festen Aktionspfade. Das Skript liest nur die in Codex registrierten lokalen Verbindungsinformationen von mobile-agent, gibt kein Token aus und übermittelt keine Geräteaufgaben.

ITER-0028 stärkt die Zuverlässigkeit: Fehlgeschlagene zielgerichtete Lokalisierung ohne Nebenwirkungen und fehlgeschlagene finish-Verifizierung können als fehlgeschlagene Runde an das Modell zurückgegeben werden, um die Planung fortzusetzen; finish kann Vordergrund-App/Activity und UI-Selektoren kombinieren; Klicks auf den oberen Systembereich und den unteren Gestenbereich werden vor der Zuweisung abgefangen. Provider-Timeout-, HTTP-, Verbindungs- und Antwortformatfehler werden kategorisiert protokolliert, und retryable Modellanfragen werden höchstens einmal wiederholt; ungültige Selektoren zeigen nur feldweise entschärfte Diagnosen. Wenn das Modell das nicht sicherheitskritische reason weglässt, generiert die Runtime einen festen Audit-Hinweis, ohne dafür eine zusätzliche Modellreparaturanfrage zu starten; Tools, Selektoren, Richtlinien und Abschlussbedingungen bleiben streng validiert.

ITER-0029 fügt optionale, von der Runtime verwaltete Erfolgsbedingungen für Aufrufer hinzu. POST /v1/tasks/agent.run kann acceptance empfangen und verwendet die All-of-Semantik von Vordergrund-App-ID, Activity und eindeutigem UI-Selektor, um das vom Modell ausgegebene finish zu verifizieren; der Pfad wird weiterhin dynamisch vom Modell basierend auf Echtzeit-Beobachtungen geplant. Der Aufgabenbericht persistiert und zeigt goal_acceptance und completion_source. Ein Anfragebeispiel befindet sich in agent-run-runtime-acceptance.example.json.

ITER-0030 fügt eine zweistufige Zielkompilierung hinzu: POST /v1/goals/compile wandelt kurze natürliche Sprachziele in einen überprüfbaren AgentGoalSpec-Entwurf um, der erweiterte Ausführungsziele, Annahmen, Konfidenz und optionale Erfolgsbedingungen enthält. Der Modellentwurf muss vom Benutzer explizit bestätigt werden, bevor er an agent.run übergeben werden kann; die Aufgabe wird weiterhin dynamisch vom Modell basierend auf Echtzeit-Beobachtungen geplant, ohne feste Aktionspfade zu generieren. Ein Beispiel finden Sie unter agent-goal-spec.example.json.

ITER-0031 fügt asynchrone Agent-Ausführung hinzu: POST /v1/tasks/agent.run/async gibt sofort 202 Accepted und eine task_id zurück, GET /v1/task-executions/{task_id} und /events bieten persistenten Status und Ereignisse pro Runde, POST /v1/task-executions/{task_id}/cancel fordert einen Abbruch an der Sicherheitsgrenze an. Die asynchrone Erstellung unterstützt Idempotency-Key; der ursprüngliche synchrone POST /v1/tasks/agent.run bleibt kompatibel. Die lokale Web-UI verwendet standardmäßig den asynchronen Einstieg.

ITER-0032 fügt für die öffentlichen Schreib-Einstiege der Runtime eine exklusive Lease pro Gerät hinzu und fügt für synchrones/asynchrones agent.run optionales deadline_seconds hinzu (Standard 600 Sekunden, Bereich 1–1800). Wenn das Gerät von einer anderen Aufgabe belegt ist, wird DEVICE_LOCKED zurückgegeben; Aufgaben, die das Budget an der Sicherheitsgrenze überschreiten, enden mit timed_out/TASK_DEADLINE_EXCEEDED, und die Nachweise der bereits ausgeführten Aktionen bleiben erhalten.

ITER-0033 fügt eine Single-Instance-Sperre der Runtime für dasselbe Datenverzeichnis hinzu und generiert eine session_id für jede kontinuierliche Online-Geräteverbindung. Aufgaben und Leases sind an die aktuelle Session gebunden; nach Gerätetrennung oder -wiederverbindung werden alte Aufgaben mit DEVICE_SESSION_CHANGED gestoppt und senden keine nachfolgenden Aktionen an die neue Verbindung. Device, TaskExecution, TaskRun und Web/CLI-Berichte zeigen die Sitzungskennung.

ITER-0034 fügt eine einheitliche Runtime/Device-Bereitschaft hinzu: Web und CLI verwenden denselben schreibgeschützten Vertrag zur Interpretation von ADB, Geräteverbindung und -autorisierung, Session- und Lease-Status; nur ready-Geräte können Aufgaben vom Web aus starten. Bei fehlendem ADB wechselt die Runtime in den Diagnosemodus und bietet Reparaturempfehlungen, ohne Tools automatisch zu installieren oder Gerätekonfigurationen zu ändern.

ITER-0035 fügt Device-Inspection und einen Capability-Katalog hinzu. In der Web-UI kann auf ein Gerät geklickt werden, um acht grundlegende V1-Fähigkeiten anzuzeigen; GET /v1/devices/{device_id}/inspection und CLI zeigen aktuelle Verfügbarkeit, Risiko, Idempotenz, Verifizierungsanforderungen, zugehörige Tools und Einschränkungen. Inspection liest nur Geräteerkennung und Lease, macht keine Screenshots, liest keine UI und führt keine Aktionen aus.

ITER-0036 fügt den ersten Engineering-Diagnose-Skill hinzu: POST /v1/skills/device.logs.collect/invoke. Der Android-Adapter akzeptiert nur begrenzte Zeilenzahlen und feste Protokollebenen und verwendet feste logcat-Parameter zur Erfassung von Snapshots; der Skill erfordert eine explizite Bestätigung für Medium-Risiko und generiert nach lokaler Entschärfung ein device_log-Artifact. Web und CLI zeigen nur Artifact-Metadaten. Kontinuierliche Streaming-Erfassung, beliebige logcat-Filter und Protokoll-Uploads liegen außerhalb des Umfangs dieser Iteration.

ITER-0037 integriert die Protokollerfassung in die einheitliche asynchrone Aufgabenkette: POST /v1/tasks/device.logs.collect/async gibt 202 Accepted zurück und verwendet TaskExecution-Status, inkrementelle Ereignisse, Idempotency-Key, Abbruch, Deadline, Device-Session, Lease und persistente TaskRun-Berichte wieder. Die Web-Protokollschaltfläche übermittelt standardmäßig asynchron; der synchrone Skill-Endpunkt bleibt erhalten. Der Executor erlaubt nur im Code registrierte Agent- und Protokollaufgabentypen; Clients können keine beliebigen Handler übermitteln.

ITER-0038 fügt device.performance.snapshot hinzu: Der Android-Adapter erfasst über feste schreibgeschützte Befehle die Gesamt-CPU, Total/Free-RAM, Batterieladung/-temperatur, Uptime und Load-Average und schreibt nur normalisierte numerische Werte in ein lokales JSON-Artifact. Synchroner Skill, asynchrone Aufgabe, Web und CLI verwenden denselben Vertrag; keine App/PID-Details und keine kontinuierliche Abtastung.

ITER-0039 fügt POST /v1/performance-comparisons hinzu, das zwei erfolgreiche Leistungssnapshot-TaskRuns auf demselben Gerät als Eingabe verwendet und Zwei-Punkt-Differenzen und Schwellenwerttrends für CPU, Speicher, Batterie, Temperatur und Last berechnet. Der Vergleich liest vollständig lokal strukturierte Aufgabennachweise, ohne auf Gerät, Modell oder rohe dumpsys zuzugreifen; Web und CLI weisen ausdrücklich darauf hin, dass Zwei-Punkt-Stichproben allein keine Kausalität oder Leistungsrückgang beweisen können.

ITER-0040 fügt die MCP-2025-11-25-stdio-Entwicklervorschau hinzu. Der MCP-Subprozess ruft nur die feste localhost-REST-API der bereits gestarteten Runtime auf und teilt daher Aufgaben, Session, Lease und Policy mit Web; alle zeitaufwändigen Fähigkeiten geben asynchron eine ThumbAgent-task_id zurück. Tool-Eingaben stammen aus dem öffentlichen Vertrag, werden vor dem Aufruf streng validiert und begrenzt, und Domänenfehler werden als structuredContent zurückgegeben. MCP-Tasks, Remote-Transport, Resources oder Prompts sind vorerst nicht implementiert.

ITER-0047 fügt device.diagnostics.bundle hinzu. Eine einmal bestätigte asynchrone Aufgabe kombiniert in derselben Device-Session und -Lease Observation, entschärfte Protokolle, aggregierte Leistung und optionalen App-Status und generiert ein lokales ZIP mit festem Inhalt. Das Manifest zeichnet die Namen, Größen und SHA-256 der vier Quell-Artifacts auf; die Runtime überprüft vor der Veröffentlichung des Diagnosepakets erneut die Quellintegrität und die ZIP- Dateisammlung und behält bei Fehlern die bereits abgeschlossenen sicheren Artifact-Referenzen.

ITER-0048 fügt eine lokale Artifact-Speicherzusammenfassung und zweistufige Ablaufbereinigung hinzu. Preview scannt nur systemgenerierte Dateien und gibt eine aggregierte Auswirkungszusammenfassung zurück; Submit akzeptiert nur eine zehn Minuten gültige, einmalige, bereichsgebundene High-Risiko-Genehmigung und löscht nach Einzelprüfung von Pfad, Größe, SHA-256 und Fälligkeitsdatum. Asynchrone Aufgaben erhalten keine Device-Session oder -Lease; Abbruch und Deadline an der Sicherheitsgrenze zwischen Artifacts verhindern nachfolgende Löschungen und bewahren die abgeschlossene Löschzusammenfassung.

Wenn ein echter Provider kontinuierlich Antworten nahe dem standardmäßigen 30-Sekunden-Budget abschließt, kann in der lokalen Konfiguration timeout_seconds auf 60 erhöht werden (zulässiger Bereich 1–120) oder über MOBILE_AGENT_MODEL_TIMEOUT_SECONDS=60 überschrieben werden. Timeout-Wiederholungen können zusätzliche Modellaufrufe verursachen; der Aufgabenbericht zeigt die Anzahl der Wiederholungen.

Produktdokumentation

• Produktpositionierung

• Produktkonzept V1

• Technisches Design V1

Engineering-Standards

• Agent-Entwicklungseinstieg

• Beitragsleitfaden

• Dokumentations- und Iterationsrichtlinien

• Engineering-Entwicklungsrichtlinien

• Contract- und API-Evolutionsrichtlinien

• Capability-Modell

• Skill-Entwicklungsrichtlinien

• Zuverlässigkeit und Ausführungssemantik

• Daten- und Migrationsrichtlinien

• Fehler- und Diagnoserichtlinien

• Architekturgrenzen

• Testrichtlinien

• Sicherheitsrichtlinien

• Richtlinien für Multi-Agent-Kollaboration

• Architekturentscheidungsprotokoll

• Iterationsindex

Lizenz

Apache-2.0