HarwnessZum Repository
Harwness — originale Löwen- und Wortmarke
SYSTEM ENGINEERING FÜR AGENTEN

Agenten denken.
Harwness setzt
den Rahmen.

Aus Modellvorschlägen wird kontrollierte Arbeit. Mit expliziten Befugnissen, dauerhaften Jobs und einem Abschluss, der Evidenz braucht.

Das System verstehen Was heute implementiert ist

RUST / LINUX-FIRST / AKTIVE ENTWICKLUNG

Entwicklungssnapshot 0.10.0 · in EntwicklungRust 2024 / Linux-firstQuellstand 14082d16

01 / DIE IDEE

Nicht nur ein Agent.
Ein System um
seine Arbeit.

Harwness ist ein Linux-first Systemprojekt für Agenten, die recherchieren, programmieren und operative Aufgaben bearbeiten.

Ein Modell kann einen nächsten Schritt formulieren. Ob dieser Schritt erlaubt ist, welche Ressourcen er bekommt und wann Arbeit als abgeschlossen gilt, ist eine andere Frage. Harwness verankert diese Entscheidungen in einer Rust-basierten Laufzeit.

01

Befugnis ist explizit. Delegation muss innerhalb der übergeordneten Rechte bleiben.

02

Arbeit hat einen Zustand. Jobs, Leases und Abbruchsignale reichen über den einzelnen Turn hinaus.

03

Erfolg ist kein Textlabel. Verifikation und Zielabnahme bleiben eigenständige Schritte.

02 / VOM AUFTRAG ZUR EVIDENZ

Vier Ebenen.
Eine Verantwortungs­kette.

Definition, Befugnis, Ausführung und Evidenz sind getrennte Aufgaben. Wähle eine Ebene und sieh, wie sie im Quellcode verankert ist.

Im Quellcode implementiertharw-agent-compiler

Agenten werden definiert.
Nicht nur beschrieben.

Aus geschichteten TOML-Definitionen entsteht eine typisierte Zwischenrepräsentation. Acht geordnete Compiler-Pässe prüfen Rollen, Rechte, Skills, erreichbare Werkzeuge, Modelle und Kinddefinitionen.

TOMLTypisierte IR8 Prüf-PässeArtefakt

Ein Content-Hash bindet die Definition. Er beweist weder die Identität ihres Autors noch die Sicherheit ihrer Ausführung.

Compiler-Pipeline im Quellcode

Konzeptionelle Darstellung anhand des verlinkten Quellstands. Kein laufender Agent und keine Runtime-Messung.

03 / BEGRENZUNG BRAUCHT MEHR ALS ABSICHT

Nicht nur
„darf ich?“
Sondern auch:
„unter welchen
Bedingungen?“

Befugnis und Isolation sind unterschiedliche Schichten.

Der stärkste implementierte Linux-Jobpfad kombiniert cgroups, Bubblewrap und einen inneren Executor. Dieser prüft den Ausführungskontext und setzt unter anderem Landlock, Ressourcenlimits und reduzierte Privilegien ein.

  1. 01
    Äußerer Job-Executorcgroup-Zugehörigkeit vor dem Start
  2. 02
    BubblewrapNamespaces und begrenzte Mounts
  3. 03
    Innerer Job-ExecutorLandlock · rlimits · NO_NEW_PRIVS
  4. 04
    JobAusführung im geprüften Rahmen

Angefordert ist nicht gleich durchgesetzt. Host, Backend und Policy bestimmen die tatsächlich erreichbaren Kontrollen. Required-Jobs sollen bei fehlenden Anforderungen scheitern; BestEffort ist nicht gleichwertig. Darwin bietet keine Linux-Isolationsparität.

Die Linux-Komposition prüfen

04 / ENTWICKLUNGSSTAND

Klar darüber,
was da ist. Und was nicht.

Implementiert heißt hier: im untersuchten Quellcode vorhanden. Es ist keine Aussage über Produktionsreife, unabhängige Tests oder erreichte Sicherheit.

10 Bereiche
Begrenzt integriert

Profilbezogene TUI-Einstellungen

Fünf sofort wirksame Oberflächenpräferenzen und zehn eingebettete Sprachkataloge. Bedienung nur als Operator; schrittweise Lokalisierung, kein vollständig übersetztes Produkt.

Quelle
Implementiert

Fortsetzung von Provider-Tool-Turns

Die Responses-Verarbeitung erhält identitätsgebundene leere Tool-Runden und erlaubt gewöhnliche, identitätslose Tool-Ergebnisse ohne Reasoning. Für verschlüsseltes Reasoning bleiben strenge Identitätsprüfungen bestehen.

Quelle
Implementiert

Agenten-Compiler

Typisierte IR und acht Prüf- und Auflösungspässe. Rollen und Rechte werden vor der Artefakterzeugung geprüft.

Quelle
Implementiert

Laufzeit & dauerhafte Jobs

Gemeinsame RuntimeAssembly, Ledger, Leases, Fencing und Abbruch. Keine pauschale Zusage für jede verschachtelte Wiederaufnahme.

Quelle
Implementiert

Linux-Job-Isolation

Komponierte Ausführungskette mit expliziten Enforcement-Berichten. Anforderungen hängen von Host und verfügbarem Backend ab.

Quelle
Begrenzt integriert

Adaptive Intent-Zyklen

Persistenz, Wiederaufnahme und evidenzgebundener Fortschritt sind vorhanden. Das freigegebene Rezept ist aktuell ausschließlich lesend.

Quelle
Begrenzt integriert

Exact-file-Writer

Der neue Pilot erzeugt Review-Artefakte statt Checkout-Änderungen. Das ist keine Einschränkung aller bestehenden Coding-Pfade.

Quelle
Begrenzt integriert

Harw-DoD · Host-Beobachtung

Optionale eBPF-Sensoren erfassen Prozessereignisse und TCP-Verbindungsversuche. Rechte, Sensorverluste und Abdeckungslücken bleiben relevant.

Quelle
Integration offen

Warden-Autorisierung

Ein signiertes Protokoll existiert als Bibliothek, ist aber nicht durchgängig an das betrachtete Warden-Binary angeschlossen.

Quelle
Evaluierung offen

Messbare Systemgarantien

Diese Darstellung liefert keine neuen Benchmarks, unabhängigen Sicherheitsnachweise oder bestätigten Produktionsresultate.

Einordnung

Quellstand: 30.10.2026, 05:02 UTC · Mit dev abgeglichen: 30.10.2026, 06:47 UTC · Offene Punkte sind keine terminierte Release-Zusage.

05 / NACHVOLLZIEHBAR STATT NUR BEHAUPTET

Geh eine Ebene tiefer.

Die beste Erklärung bleibt überprüfbar. Die aktuelle Übersicht verlinkt einen festen Repository-Stand, nicht einen beweglichen Branch.

01 / SOURCE SNAPSHOT

Den Quellstand
selbst lesen.

Repository und Architektur unter 14082d16. Workspace-Version 0.10.0 (noch nicht veröffentlicht), Rust Edition 2024.

Fixierte Revision öffnen02 / ERHALTENES ARCHIV

Abhängigkeiten
erkunden.

Der vorhandene interaktive Crate-Explorer bleibt erhalten. Sein Datenstand ist v0.3.0, nicht der aktuelle Snapshot.

Historischen Explorer öffnen03 / ERHALTENE DOKUMENTATION

Hintergründe
nachschlagen.

Die bisherige technische Dokumentation — sichtbar als historischer Stand gekennzeichnet, unverändert erhalten.

Dokumentationsarchiv öffnen

Was diese Seite belegt.

Eine quellengestützte Darstellung ausgewählter Mechanismen. Für diese Übersicht wurden weder die vollständige Rust-Workspace noch privilegierte Host-Dienste neu gebaut, ausgeführt oder unabhängig auditiert. Implementierung, Integration und Evaluation bleiben getrennte Aussagen.

Forschungsentwürfe und Pläne gelten nicht als fertig implementierte Funktionen. Der jüngste Merge dokumentiert vom Maintainer berichtete lokale Validierung; diese Website-Aktualisierung wiederholt diese Läufe nicht und belegt keine erfolgreiche Remote-CI. Merge-Nachweis lesen.

Ist Harwness ein eigenes Sprachmodell?

Nein. Im Mittelpunkt steht die Systemschicht um modellgestützte Arbeit: Definitionen, Laufzeit, Rechte, Jobs und Evidenz. Die Auswahl eines Modellproviders ist eine separate Entscheidung und verleiht keine zusätzliche Autorität.

Ist das eine fertige Produktionsplattform?

Harwness befindet sich in aktiver Entwicklung vor Version 1.0. Schnittstellen und Konfiguration können sich ändern. Vorhandener Code ist nicht mit geprüfter Produktionsreife gleichzusetzen.

Wie lässt sich das Projekt nachvollziehen?

Beginne mit dem README der fixierten Revision, folge den Quelllinks auf dieser Seite und prüfe die Bedingungen des jeweiligen Ausführungspfads. Die ältere Website bleibt im Übersichtsarchiv erhalten.

HARWNESS / IN AKTIVER ENTWICKLUNG

Mehr Handlungs­spielraum.
Mit überprüfbaren Grenzen.

Das Projekt auf GitHub