AWR
GitHub
Deutsch
English中文Españolहिन्दीPortuguêsРусский日本語한국어DeutschFrançais

Schnellstart

Quelldatei auf GitHub ansehen

Dieser Rundgang führt dich von einer frischen AWR-Installation zu einer verifizierten Session-Übergabe: die CLI installieren, ein Projekt initialisieren, eine Arbeitssession starten und beweisen, dass eine Nachfolge-Session dort weitermachen kann, wo die erste aufgehört hat. Alles ist per Copy-Paste ausführbar; AWR bringt sein eigenes SQLite mit.

1. AWR installieren

AWR wird als native Pakete auf npm und PyPI ausgeliefert. Beide Kanäle installieren dieselbe Rust-CLI (awr) und denselben MCP-Server (awr-mcp); es gibt kein separates JavaScript- oder Python-SDK.

Mit npm (erfordert Node 22.14 oder neuer):

npm install -g @originoneai/agent-work-runtime@0.5.1

Oder mit pip, in einer virtuellen Umgebung (erfordert Python 3.9 oder neuer):

python -m pip install agent-work-runtime==0.5.1

Überprüfe beide ausführbaren Dateien:

awr --version
awr-mcp --version

Unterstützte Plattformen sind macOS 15+ (arm64 und Intel x64), Linux x64 und arm64 mit glibc 2.39 oder neuer (die Ubuntu-24.04-Basislinie) sowie Windows x64. Prüfe unter Linux zuerst deine glibc:

ldd --version | head -n 1

Bei npm-Installationen: Lass optionale Abhängigkeiten aktiviert — der Launcher löst ein plattformspezifisches natives Paket auf. Es gibt kein Installationsskript und keinen Netzwerk-Downloader; die pip-Wheels enthalten die Binärdateien eingebettet. Ein dritter Kanal existiert für Anwendungsautoren: ein gepinntes natives Paket der beiden Binärdateien, das eine Host-App einbetten kann, sodass ihre Nutzer zur Laufzeit weder Node, Python noch Rust benötigen.

2. Dein Projekt initialisieren

Die Initialisierung ist ein zweistufiger Vorgang: eine Vorschau, dann eine explizite Annahme. Nichts wird geschrieben, bis du --accept übergibst.

AWR_PROJECT=/absolute/path/to/your/project
awr --project "$AWR_PROJECT" init

Lies die Vorschau: Sie zeigt den Bestand, den AWR gefunden hat — vorhandene Markdown-Aufgaben-Ledger, YAML-Quellen, Ziele — und die Quellenzuordnung, die es vorschlägt. Vorhandene Dateien werden niemals überschrieben; deine ursprünglichen Dokumente bleiben die maßgebliche Quelle. Wenn die Vorschau stimmt, nimm sie an:

awr --project "$AWR_PROJECT" init --accept

Bei einem leeren Projekt gib seinen Zweck von Anfang an an:

awr --project "$AWR_PROJECT" init --goal "Deliver a document portal" --accept

Wenn dein Markdown-Ledger nicht standardmäßige Statuswörter verwendet, bilde sie zum Zeitpunkt der Initialisierung ab:

awr --project "$AWR_PROJECT" init \
  --status-map pending=planned --status-map complete=completed --accept

Sieh dir dann den Organisationsbericht an:

awr --project "$AWR_PROJECT" intake inspect --json

Das organization.state des Berichts sagt dir, wo du stehst: ready bedeutet, mindestens eine Aufgabe hat ein quellendeklariertes Ziel, Abnahmekriterien, eine nächste Aktion und aufgelöste Voraussetzungen. needs_organization bedeutet, etwas fehlt — die geordneten actions des Berichts sagen dir, was du deinen Quelldateien hinzufügen musst.

3. Eine Arbeitssession starten

Eine Session ist die Einheit der Arbeitszuständigkeit in AWR. Diese Befehle nutzen einen kleinen Shell-Helfer, damit jeder Aufruf den Projektpfad und JSON-Ausgabe mitführt:

AWR_BIN=$(command -v awr)
AWR_WORK=INTAKE-001          # a task key from your intake report
AWR_AGENT=agent-primary      # a label for who is working
AWR_MODEL=your-current-model # a recorded label; AWR does not invoke the model
AWR_NOTES=$(mktemp -d "${TMPDIR:-/tmp}/awr-session.XXXXXX")
awrj() { "$AWR_BIN" --project "$AWR_PROJECT" --json "$@"; }

Prüfe, was ausführbar ist, und starte dann eine Session mit einem Claim (Laufzeit-Zuständigkeit für das Arbeitselement) und der aktuellen Projektrevision:

awrj ready
AWR_REV=$(awrj status | jq -er '.project_revision')
awrj session start --work "$AWR_WORK" --agent "$AWR_AGENT" \
  --provider generic --model "$AWR_MODEL" --claim --ttl-ms 3600000 \
  --expected-revision "$AWR_REV" > "$AWR_NOTES/start.json"
AWR_SESSION=$(jq -er '.session.id' "$AWR_NOTES/start.json")

Kompiliere den Arbeitskontext — Ziel, Abnahmekriterien, aufgezeichnete Fakten und Verlauf, zusammengestellt zu einem begrenzten Paket:

awrj context compile --work "$AWR_WORK" --session "$AWR_SESSION" \
  --budget 5000 > "$AWR_NOTES/context.json"
jq -e '.completeness.complete and (.work_context != null)' "$AWR_NOTES/context.json"

Lies das Paket, nicht nur den booleschen Wert. Bei BudgetExceeded vergrößere --budget; bei SourceStale führe awrj source reindex aus und kompiliere erneut.

4. Fortschritt mit einem Checkpoint aufzeichnen

Bevor du weggehst — oder bevor eine lange Host-Konversation kompaktiert wird — speichere einen Checkpoint mit dem Kontext-Hash, den du tatsächlich verwendet hast, einem ehrlichen Digest, der exakten nächsten Aktion und jeder offenen Schleife:

AWR_CONTEXT_HASH=$(jq -er '.work_context.context_hash' "$AWR_NOTES/context.json")
AWR_REV=$(awrj status | jq -er '.project_revision')
awrj session checkpoint --session "$AWR_SESSION" --agent "$AWR_AGENT" \
  --context-hash "$AWR_CONTEXT_HASH" \
  --digest "Record the work actually done; do not invent a passing review." \
  --next-action "State the exact next operator or agent action." \
  --open-loop "List every unresolved loop." \
  --expected-project-revision "$AWR_REV" > "$AWR_NOTES/checkpoint.json"

Ein Checkpoint kann unvollendete Arbeit aufzeichnen; er ist kein Beweis für bestehende Tests oder erfüllte Abnahmekriterien.

5. Die Arbeit in einer neuen Session fortsetzen

Um zu beweisen, dass die Fortsetzung funktioniert, beende die erste Session und setze von ihr aus fort — derselbe Übernahmeweg, den ein neuer Agent, eine neue Maschine oder eine neue Host-Konversation verwenden würde. Das Beenden gibt den Claim frei; es markiert die Quellenarbeit nicht als abgeschlossen:

AWR_REV=$(awrj status | jq -er '.project_revision')
awrj session end --session "$AWR_SESSION" --outcome incomplete \
  --expected-revision "$AWR_REV"

Setze nun fort. Jeder Agent — ein anderer oder derselbe später — erstellt aus dem Vorgänger eine Nachfolge-Session:

AWR_PREDECESSOR="$AWR_SESSION"
awrj session show "$AWR_PREDECESSOR"
AWR_REV=$(awrj status | jq -er '.project_revision')
awrj session resume --from-session "$AWR_PREDECESSOR" \
  --agent successor --provider generic --model "$AWR_MODEL" \
  --budget 5000 --expected-revision "$AWR_REV" > "$AWR_NOTES/resume.json"
jq -e '.context_ready' "$AWR_NOTES/resume.json"
AWR_SESSION=$(jq -er '.resumed.session.id' "$AWR_NOTES/resume.json")

Zwei Prüfungen bestätigen, dass die Übergabe funktioniert hat:

  • jq -e '.context_ready' endet mit 0: Der Nachfolger hat den aufgezeichneten Kontext des Vorgängers erhalten, einschließlich des letzten erfolgreichen Checkpoints.
  • Die fortgesetzte Session hat eine neue ID — Resume erstellt eine neue AWR-Session, statt die alte zu verändern.

Du kannst den Wiederherstellungszustand auch jederzeit schreibgeschützt einsehen:

awrj recovery inspect --session "$AWR_SESSION"

Arbeitest du im Chat eines Coding-Agents? Binde die Host-Konversation an die AWR-Session, damit Checkpoints die Host-Kompaktierung überleben:

awrj client bind --client generic --external-session "myhost:$HOST_CONVERSATION_ID" \
  --work "$AWR_WORK" --session "$AWR_SESSION"

AWR überträgt nicht den Prozessspeicher eines Hosts und übernimmt keine beliebigen bestehenden Prozesse — Kontinuität entsteht aus dem, was explizit aufgezeichnet wurde.

Wie es weitergeht