Harnesses
Eine Sitzung verwendet ein Agent-Harness: Standard-Harness oder Experimental-Harness. Auf dieser Seite erfahren Sie, wie ein Projekt eines auswählt und welche Funktionen die jeweiligen Harnesses unterstützen.
Ein Harness ist die Agent-Laufzeit innerhalb der Sandbox einer Sitzung. Es führt die Modellausführung aus, ruft Tools auf und erstellt das Transkript. Beeuni bietet zwei Harnesses: Standard-Harness (Standard) und Experimental-Harness. Eine Sitzung führt genau eines davon aus.
Beide Harnesses lesen dasselbe Projekt: beeuni.yaml, die Agent-Dateien in agents/, die Skills in skills/, die Stammdatei AGENTS.md und memory/. Die Clients (Web, CLI, TUI, Mobilgerät, SDK) greifen über dieselbe Sitzungs-API auf beide zu. Die Unterschiede betreffen die Sitzungsfunktionen in der Matrix unten sowie die Dateien, die jedes Harness für seine eigene Konfiguration liest.
So wählt eine Sitzung ihr Harness aus
Beeuni entscheidet, wenn eine Sitzung gestartet, neu gestartet oder fortgesetzt wird. Bis dahin behält eine laufende Sitzung ihr Harness bei.
| Regel, der Reihe nach | Harness |
|---|---|
Das Flag llm_gateway des Projekts ist deaktiviert |
Standard-Harness |
Das Flag pi_harness des Projekts ist aktiviert |
Experimental-Harness |
beeuni.yaml setzt runtime: pi |
Experimental-Harness |
| Alles andere | Standard-Harness |
- Experimental-Harness ruft Modelle ausschließlich über das Beeuni-LLM-Gateway auf. Ein Projekt, bei dem
llm_gatewaydeaktiviert ist, startet Standard-Harness, unabhängig vom Flag oder Manifest. Siehe Modelle. runtimeist ein Manifest-Schlüssel vom Typbeeuni_version: 2. Ein Projekt mit dem veraltetenbeeuni.tomlkann ihn nicht festlegen. Siehe Manifestreferenz.pi_harnessist ein projektbezogenes Feature-Flag, das standardmäßig deaktiviert ist. Siehe Feature-Flags.
Um zu sehen, welches Harness eine Sitzung ausführt, lesen Sie harness.id in der Antwort GET /beeuni/health des Sandbox-Daemons: opencode oder pi.
Unterstützte Funktionen der einzelnen Harnesses
Ein Harness führt die optionalen Sitzungsfunktionen, die es bereitstellt, im Array capabilities von GET /beeuni/health auf. Ein Client blendet ein Steuerelement aus, wenn capabilities der Sitzung die ID nicht enthält. Die SDK-Prüfung lautet runtimeSupports.
Beide Harnesses
| Funktion | Standard-Harness | Experimental-Harness |
|---|---|---|
| Chat-Nachrichten, Streaming, Abbrechen | Ja | Ja |
Agent-.md: Prompt, model, variant, mode, permission, temperature, top_p, steps |
Ja | Ja. Experimental-Harness wendet options (Anbieteroptionen) nicht an. |
Toolzugriff pro Agent (agents.<name>.tools in beeuni.yaml: all, none, eine Liste, exclude) |
Ja | Ja |
permission-Regeln und Berechtigungsanfragen pro Agent |
Ja | Ja |
Fragen (Tool question) |
Ja | Ja |
Die Regeldatei AGENTS.md im Projektstamm oder CLAUDE.md, wenn der Stamm kein AGENTS.md enthält |
Ja. Standard-Harness liest auch die Datei in den übergeordneten Verzeichnissen von /workspace und liest /workspace, während es eine Konfigurationsversion ausführt. |
Ja, nur die Datei im Stammverzeichnis. Sie ist Teil des System-Prompts der Sitzung und jedes Subagents. Mit aktivierten Konfigurationsversionen liest Experimental-Harness die Kopie der Version. |
Subagents (Tool task), session.subagents |
Ja | Ja: general, explore (schreibgeschützt) und jeder Projekt-Agent mit mode: subagent oder all. Ein Subagent kann keinen weiteren Subagent starten. |
Skills (skills/ und verwaltete Skills aus beeuni-*) mit der Freigabe skills des Agents |
Ja. Der Agent lädt einen Skill mit dem Tool skill. |
Ja. Der System-Prompt führt jeden freigegebenen Skill auf; der Agent liest die Datei. |
Beeuni-Tools: web_search, image_search, scrape_webpage, memory, show. Alle fünf, wenn beeuni.yaml keinen Schlüssel tools: enthält; andernfalls diejenigen, die darin als beeuni:<name> aufgeführt sind |
Ja | Ja |
Projekt-Tools (tools: in beeuni.yaml) |
Ja | Ja |
Konfigurationsversionen, config.release.v1 |
Ja | Ja |
Unterhaltung bei Bedarf und automatisch nahe dem Kontextfenster des Modells zusammenfassen (kompakt halten), session.compact |
Ja | Ja. Wenn eine Modellanfrage das Kontextfenster überschreitet, wird die Unterhaltung kompakt gehalten und die Anfrage einmal wiederholt. |
Projekt-Slash-Befehle, session.commands |
Ja, aus commands/ im Standard-Harness-Konfigurationsverzeichnis. |
Ja, aus den Prompt-Vorlagen in prompts/ im Experimental-Harness-Konfigurationsverzeichnis und in Experimental-Harness-Paketen. Experimental-Harness liest commands/ von Standard-Harness nicht. |
| Terminal in der Sandbox (PTY) | Ja | Ja |
Tools bash, read, write, edit, glob, grep; Secrets in der Shell; die CLI beeuni |
Ja | Ja |
Die Beeuni-Tools und die Projekt-Tools sind Harness-unabhängig: Der Sandbox-Daemon führt für beide Harnesses pro Tool ein Modul mit denselben Namen, Argumenten und Ausgaben aus. Experimental-Harness ruft sie im Prozess des Daemons auf; Standard-Harness ruft sie über ein Plugin auf, das der Daemon erstellt. Beide Harnesses erhalten dieselbe Liste: Ein Beeuni-Tool, das der Schlüssel tools: des Projekts nicht aufführt, steht keinem der beiden zur Verfügung. Ein Projekt, das noch Kopien der Beeuni-Tools in harnesses/opencode/tools/ hat, behält diese Kopien in Standard-Harness, bis es sie löscht.
Die Web-Tools beachten bei beiden Harnesses die Berechtigungsschlüssel websearch (web_search, image_search) und webfetch (scrape_webpage). In Standard-Harness können diese Tools keine Berechtigungsanfrage stellen: Eine Regel ask verweigert den Zugriff. In Experimental-Harness löst eine Regel ask eine Berechtigungsanfrage aus. In Experimental-Harness beachtet ein Befehl memory, der eine Datei ändert, edit, und view beachtet read; in Standard-Harness regelt das Tool nur eine Regel memory.
AGENTS.md in Experimental-Harness
Experimental-Harness fügt das AGENTS.md im Projektstamm als Abschnitt <project_instructions path="AGENTS.md"> im System-Prompt ein, nach dem Prompt des Agents. Wenn der Stamm kein AGENTS.md enthält, verwendet Experimental-Harness stattdessen CLAUDE.md, wie bei Standard-Harness. Experimental-Harness liest kein AGENTS.md in einem Unterverzeichnis oder übergeordneten Verzeichnis.
- Quelle. Bei deaktivierten Konfigurationsversionen liest Experimental-Harness
/workspace/AGENTS.md. Bei aktivierten Versionen liest Experimental-Harness die Kopie in der Version und niemals die in/workspace: Eine Änderung in/workspacewird erst nach dem Zusammenführen mit dem Basis-Branch in der Sitzung übernommen. Sind Konfigurationsversionen aktiviert und gibt es keine Version, die bereitgestellt werden kann (config.source: image-default), liest Experimental-Harness keinAGENTS.md, genauso wie Experimental-Harness keinen Projekt-Skill liest. - Zeitpunkt. Experimental-Harness liest die Datei beim Start der Laufzeit, beim Neuladen der Konfiguration (eine neue Version, ein
/beeuni/env-Push) und nach einer Repository-Aktualisierung. Die Datei wird nicht vor jeder Nachrichtenrunde gelesen. Eine neue Version wird in der nächsten Runde übernommen, ohne dass ein Neustart erforderlich ist; eine laufende Runde verwendet weiterhin die alte Datei. - Übersprungen. Eine leere Datei, eine Datei, die keine reguläre Datei ist, und ein symbolischer Link, der außerhalb des Repositorys aufgelöst wird, tragen nichts bei. In den letzten beiden Fällen wird jeweils eine Warnung in das Daemon-Protokoll geschrieben.
- Prüfen.
harness.details.agentsMdinGET /beeuni/healthdes Daemons nennt die Datei, die Experimental-Harness geladen hat:source(releaseoderworkspace),path,bytesundsha(die ersten 12 hexadezimalen Zeichen der sha256-Prüfsumme). Wenn Experimental-Harness keine Datei geladen hat, ist der Wertnull.
Derzeit nur in Standard-Harness
| Funktion | Fähigkeit | Standard-Harness | Experimental-Harness |
|---|---|---|---|
| Zu einer Nachricht zurückkehren und sie wiederherstellen. Bei Bearbeiten und erneutem Senden wird zurückgesprungen. | session.rewind |
Ja | Nein |
MCP-Server (mcp in opencode.jsonc) |
session.mcp |
Ja | Kein MCP-Client. Connectors funktionieren mit beiden Harnesses über die CLI beeuni connectors. |
Aufgabenliste (Tool todowrite) und Planungskarte |
session.todo |
Ja | Nein. Die Planungskarte bleibt leer. |
Den eigenen Terminal-Client des Harnesses anhängen (beeuni connect, TUI Alt+o) |
session.attach |
Ja | Nein. Siehe TUI. |
Laufzeit-Konfigurationsdokument (/global/config) |
session.config |
Ja | Nein. Agents und Modelle stammen bei beiden aus dem Projekt. |
| Sitzung an einer Nachricht verzweigen | session.fork |
Ja | Nein |
| Shell-Befehl als Nachrichtenrunde ausführen | session.shell |
Ja | Nein |
| Modellanbieter ohne LLM-Gateway | — | Ja | Nein. Für Experimental-Harness muss llm_gateway aktiviert sein. |
Eine Experimental-Harness-Sitzung beantwortet eine Anfrage nach einer nicht unterstützten Funktion mit 501 feature_not_supported oder mit 404, wenn das angeforderte Dokument nicht vorhanden ist (/global/config). Die Anfrage wird nicht ignoriert.
Konfigurationsdateien der Harnesses
Jedes Harness hat ein eigenes Verzeichnis für die Dateien, die nur dieses Harness liest.
| Standard-Harness | Experimental-Harness | |
|---|---|---|
| Verzeichnis | harnesses/opencode/ oder opencode.config_dir |
harnesses/pi/ oder pi.config_dir |
| Veraltetes Verzeichnis | .beeuni/opencode/ |
.beeuni/pi/ |
| Inhalt | opencode.jsonc, plugins/, tools/, commands/ |
settings.json, extensions/, skills/, prompts/ |
| Erweiterungen | Plugins und Standard-Harness-spezifische Tools in diesem Verzeichnis | Experimental-Harness-Pakete in harnesses.pi.packages sowie Erweiterungsdateien in extensions/ |
Eine Experimental-Harness-Sitzung liest weder opencode.jsonc noch plugins/, tools/ oder commands/. Eine Standard-Harness-Sitzung liest das Experimental-Harness-Verzeichnis nicht. Ein Tool, das beide Harnesses benötigen, ist ein Projekt-Tool, das in beeuni.yaml deklariert wird, und keine Datei in einem der beiden Verzeichnisse.
Experimental-Harness-Pakete stammen von packages. Ein Paket kann Tools hinzufügen, die Experimental-Harness nicht mitbringt, zum Beispiel einen MCP-Adapter oder ein Aufgabenlisten-Tool. Beeuni lädt das Paket, testet aber keine Pakete von Drittanbietern.