Grenzen und Sicherheit

Jeder Agent, den chat startet, ist ein echter Prozess und ein bezahlter Modellaufruf, und jeder von ihnen kann weitere starten. Diese Seite ist die Sammlung der Bremsen darum herum — und, mindestens ebenso wichtig, die Liste dessen, was ein Agent nicht selbst entscheiden darf.

Lesen Sie sie als Entwurfsaussage, nicht als Konfigurationsreferenz. Fast nichts hier ist einstellbar, und das mit Absicht.

Was ein Agent nicht entscheidet

Die Oberfläche wurde bewusst so geschnitten, dass ein laufender Agent keine Fragen beantworten kann, die ihm niemand gestellt hat. Diese entscheidet eine Deklaration, die Sie geschrieben haben, und es gibt keine Übersteuerung je Aufruf:

send --model, send --deadline, send --kind, send --priority, send --disposition und reply --kind gab es alle, und alle wurden entfernt. Die angegebene Begründung ist es wert, wiederholt zu werden, denn sie ist die Regel hinter der ganzen Tabelle: sonst wird ein Agent vielleicht übereifrig Optionen ändern. Eine Übersteuerung je Aufruf neben einem deklarierten Wert sind zwei Antworten auf eine Frage — und ausgerechnet der Aufrufer ist die Partei mit der geringsten Legitimation zu antworten.

Was ein Agent sehr wohl entscheidet, ist, was er sagt, wem von den Deklarierten er es sagt, ob er die Aufgabe überhaupt ausführen kann — und, wo ein Schritt des Kanals einen Weg dafür erklärt, ob die Arbeit, die er beurteilen sollte, lieferbar ist (--needs-rework).

Die Tiefenbegrenzung

Eine Startkette ist bei 32 Sprüngen gedeckelt. Darüber hinaus wird ein Anstoß abgelehnt, bevor irgendetwas getan wird — und genau das hindert zwei Agenten, die sich Arbeit nur gegenseitig zuschieben, daran, ewig zu kreisen, wobei jede Runde einen Prozess und einen Modellaufruf kostet.

Drei Einzelheiten machen daraus eine echte Bremse statt einer Formalie:

Gezählt wird die OFFENE Kette, nicht jeder Sprung, an dem eine Sitzung je beteiligt war. Arbeit, die beauftragt und beantwortet wurde, wickelt sich ab: das Ziel tritt wieder in der Tiefe ein, die es ohnehin hatte, statt eine unter der Sitzung, die geantwortet hat. Das ist keine Nebensache — ein roher Zähler tötete genau die Form, die er schützen sollte: ein Orchestrator und ein Kanalbesitzer, die über viele Runden reden, gewannen vier Sprünge pro Runde und waren nach sieben dauerhaft nicht mehr aufrufbar. Beauftragen geht abwärts, Antworten kommt zurück.

Sie ist im Speicher verankert, nicht in der Umgebung. Die Tiefe einer Sitzung wird von dem geschrieben, der sie gestartet hat, bevor sie je lief. NXC_HOP in der eigenen Umgebung eines Prozesses ist ein Anspruch, der die Tiefe anheben darf und nie senken. Diesen Unterschied gibt es, weil jede Persona in den ausgelieferten Beispielen tools: [Bash] deklariert — unset NXC_HOP vor ihrem eigenen nxc send hätte die Kette sonst bei jedem Sprung auf null zurückgesetzt und die Bremse damit ausgehebelt.

Was sie nicht schließt, klar gesagt. Ein Aufrufer, der gar keine Sitzung vorweist, löst auf seinen beanspruchten Wert auf, denn ein echter Mensch am Terminal hat genau diese Form. Ein Agent, der entschlossen ist zu entkommen, kann also seine ganze Umgebungsidentität ablegen und wie eine frische Kette aussehen — um den Preis von allem, was diese Identität ihm einbringt: keine Rückadresse auf seinen Posts, keine Wiederaufnahme, keine Sitzung, der sich irgendetwas zurechnen ließe. Diese letzte Lücke zu schließen braucht ein fälschungssicheres Merkmal, das dem gestarteten Prozess übergeben wird, statt einer Umgebungsvariablen — das ist ein Zugriffsentwurf, nicht diese Bremse.

Das menschliche Tor

Kein Mensch steht mitten im Ablauf. Ein Mensch eröffnet einen Vorgang und ein Mensch liest sein Ergebnis; nichts dazwischen wartet auf einen. Deshalb ist awaiting_human in nxc status nur an der Wurzel eines abgeschlossenen Vorgangs wahr, nie an einem Faden in der Mitte:

$ NXC_ACTOR=alice nxc status
operation m-00000000000000000000000001  dm:9445dbc93dfdad401585c42b  1 thread(s), 0 open
  m-00000000000000000000000001  dm:9445dbc93dfdad401585c42b  awaiting you (answered by ab12/coder)

Das Merkmal ist eine Aussage über ein Ende der Kette, neben dem Zustand des Fadens statt an seiner Stelle, und es gibt es aus einem Grund: ein Vorgang, der stehengeblieben ist, und einer, der fertig ist und auf Sie wartet, sehen für einen Zähler gleich aus und verlangen Gegenteiliges. Wenn Sie eine Übersicht über nxc status --json bauen, ist das das Feld, an dem Sie verzweigen.

Das andere menschliche Tor schreiben Sie selbst. Eine Persona, die ohne Freigabe nicht handeln darf, ist eine Persona, deren system_prompt das sagt und deren Deklaration ihr keine Werkzeuge zum Handeln gibt — tools: [] ist ein echter, eigener Zustand und nicht dasselbe wie den Schlüssel wegzulassen.

Eskalation: das deklarierte „ich kann nicht"

Ein Agent darf mit reply genau zwei Dinge sagen: ich bin fertig und das kann ich nicht ausführen. Das zweite ist --escalate, und es ist ein deklariertes Signal, keine Formulierung:

nxc reply --thread <id> --escalate "Die Migration braucht ein Produktionsgeheimnis, das ich nicht habe."

Das zählt, weil der Betreuer an einem Bit verzweigt, dessen Bedeutung aufgeschrieben ist, und nicht an einem Wort, das ein Agent erfunden hat und kein Leser aufzählen kann. Der Zug ist so oder so eingelöst — die Sitzung endet und die Schuld mit ihr. Verschieden ist das Ergebnis, und der Kanal entscheidet, was daraus wird: eine eskalierende Runde wird durchgereicht statt gefaltet, damit „ich kann nicht" den Anfragenden erreicht, wie es dasteht, und nie als Absatz über ein Scheitern.

Es ist kein Papierkorb für alles, was kein Ergebnis ist. Und es ist heute zugleich der einzige Weg, überhaupt etwas zurückzugeben: reply --kind question fiel mit dem übrigen --kind weg, eine echte Rückfrage wird also entweder mit --escalate gesagt oder gestellt, indem man ein eigenes Gespräch eröffnet. Das ist ein festgehaltener Verlust, kein Zusammenfallen.

Der Anspruch auf die Arbeitskopie

Ein Repository hat eine Arbeitskopie und ein Build-Verzeichnis. Zwei Ketten, die darin gleichzeitig verzweigen, committen und cargo test laufen lassen, sind kein Wettlauf, den man durch Sorgfalt gewinnt — deshalb nimmt chat einen Anspruch.

Deklarieren Sie den Bedarf (working_tree: exclusive an einer Persona oder einem Kanal), und ein Anstoß, der kollidieren würde, wartet statt zu kollidieren. Die Mechanik, in der Reihenfolge, in der sie greift:

• Was ein Anspruch umfasst, ist die OPERATION: die Wurzel des Fadenbaums, zu dem die Arbeit gehört, und alles, was in beliebiger Tiefe darunter hängt — dieselbe Einheit, nach der nxc status gruppiert. Der Anspruch entsteht weiterhin erst beim ersten exklusiven Schritt, eine Kette, die nie einen erreicht, hält also nichts; ist er aber einmal genommen, wird er zurückgegeben, wenn die Operation fertig ist, und nicht schon, wenn die Runde fertig ist, die ihn genommen hat. Genau das schliesst die Lücke zwischen zwei Runden desselben Epics: ein Planer, der Coding zweimal beauftragt, behält die Kopie über die Pause dazwischen, statt zuzusehen, wie eine fremde Kette hineinrutscht.

  Diese Seite sagte das Gegenteil — der Anspruch hörte vor Ihrem Gespräch mit dem Agenten auf, damit nicht „ein einziger unbeantworteter Mensch die Arbeitskopie der Maschine bis morgen hält". Diese Grenze kostete mehr, als sie einbrachte, und das Risiko, das sie benannte, beantwortet jetzt die Frist weiter unten, statt das obere Ende der Operation ungeschützt zu lassen.

• Erwerben oder anstellen. Ein Anstoß innerhalb eines gehaltenen Gebiets erbt den Anspruch, statt sich anzustellen — sonst stellte sich ein verschachtelter exklusiver Schritt hinter seinem eigenen Elter an, das nie freigeben könnte, weil es auf genau den Anstoß wartet, den es gerade geparkt hat. Die Warteschlange ist Wer-zuerst-kommt, und eine Freigabe befördert das ganze Anspruchsgebiet an der Spitze, nie einen einzelnen Eintrag: mehrere Mitglieder einer Auffächerung teilen sich einen Anspruch, und eines zu starten, während seine Geschwister geparkt bleiben, verklemmt die Tafel.

• Was ihn freigibt. Eine Antwort innerhalb des Gebiets gibt den Anspruch frei, wenn nichts in diesem Gebiet noch eine Antwort schuldet und das letzte Wort keine Rückgabe war. Eine Eskalation hält den Anspruch — die Frage wandert noch nach oben, die Aufgabe ist noch in der Luft, und die Kopie in genau diesem Moment einem Rivalen zu überlassen, wäre genau falsch.

• Wie sich der Halt löst. Eine Rückgabe in einem Kanal zu beantworten deklariert die Runde neu, und der Halt ist weg. Diese Seite sagte das ohne den Zusatz, und der Zusatz ist der ganze Punkt: auf einem direkten Faden stimmt es nicht. Eine Antwort zählt dort nur als Antwort auf eine Rückgabe, wenn sie von einem Handle kommt, das der Faden erwartet — und auf einem eskalierten Faden ist das erwartete Handle der Eskalierende selbst. Eine Antwort von jemand anderem, auch vom Eröffner, wird gepostet und bewegt nichts. Zweimal gemessen: posted: true, woke: null, und der Anspruch danach unverändert holding.

• Wenn ihn nichts mehr lösen wird: nxc release --thread <id>. Nennen Sie einen Faden aus der Kette, die die Kopie hält — nxc status markiert den Vorgang, der eine hält, mit holds working tree —, und die Kopie geht weiter an die nächste, die wartet. Der Aufruf lehnt ab, solange irgendeine Sitzung dieser Kette noch einen lebenden Prozess hat, und sagt welche: einer Kette, die noch arbeitet, die Arbeitskopie wegzunehmen, ist genau die Kollision, gegen die der Anspruch existiert. Dieses Verb ist für den anderen Fall — eine Kette, die vorbei ist und aus der kein Signal mehr kommen kann, weil alles, was eines hätte senden können, weg ist.

• Wie lange ein Anspruch läuft: so lange, wie die Operation es selbst zugesagt hat. Die Frist ist das späteste timeout:, das im Anspruchsgebiet noch aussteht — eine Runde, die sechs Stunden sagt, hält die Kopie sechs Stunden, und eine Operation, deren Schritte alle Minuten sagen, ist nach einem Absturz in Minuten wieder frei. Das „alle" trägt: eine einzige ausstehende Verpflichtung ohne Fenster — und ein Gespräch, das Sie mit einem schlichten nxc send eröffnen, ist eine — setzt die ganze Operation auf die pauschale Zwei-Stunden-Grenze zurück, die früher für jeden Anspruch galt. Die zwei Stunden sind also jetzt die Antwort für Deklarationen, die nichts sagen — kein Budget, das denen aufgezwungen wird, die etwas sagen —, und für eine kürzere Frist entscheidet man sich, indem man timeout: entlang der Kette deklariert.

• Die Rückfallgrenze. Ein verwaister Anspruch hört auf, künftige Erwerbungen abzulehnen, sobald seine Frist verstrichen ist, und ein tick nach diesem Punkt gibt die Warteschlange frei — eine Beauftragung, die parkt, plant einen für genau diesen Zeitpunkt ein, das Leeren passiert also auch, wenn niemand da ist. (Diese Seite sagte, die Warteschlange werde überhaupt nie geleert: nichts fragte ab, ein bereits geparkter Anstoß wartete unbegrenzt über die Grenze hinaus. Jetzt fragt etwas ab.)

• Wer schon wartet, kommt zuerst dran. Das Zurückholen eines abgelaufenen Anspruchs gibt den Zug der Warteschlange im selben Schritt weiter: die Kette, die schon anstand, startet, und der Neuankömmling stellt sich hinten an. Diese Seite schwieg dazu, weil es umgekehrt war — die Kopie bekam, wer als Nächstes fragte, ganz gleich, wie lange ein Rivale schon darauf gewartet hatte.

• Eine abgelaufene Frist genügt nicht, um die Kopie zu nehmen. Eine Kette, deren Anspruch abgelaufen ist, deren Prozess aber noch lebt, behält sie — dieselbe Ablehnung, die nxc release ausspricht, nur am anderen Ende gefragt. Diese Seite warnte, ein einzelner Schritt, der länger als zwei Stunden arbeitet, verliere den Anspruch unter sich und die nächste Kette laufe in die Arbeitskopie hinein, in der er noch baut. Das gilt nicht mehr: was ein Rivale antrifft, ist ein lebender Prozess, keine Frist.

Nur ein beauftragender Anstoß wird je geparkt. Ein Anstoß, der ein Ergebnis nach oben trägt, wird nie angestellt — sonst würde ausgerechnet die Antwort zurückgehalten, deren Ankunft den Anspruch freigibt.

Inhalte, die Sie nicht geschrieben haben

Zwei Stellen bringen Text, den jemand anders geschrieben hat, in den Kontext eines Modells, und beide sollte man kennen, bevor man entscheidet, was die eigenen Agenten dürfen.

Die Durchreichung eines Kanals rendert die rohe Antwort jedes Mitglieds in die Nachricht, die die Sitzung des Anfragenden erhält. Die Form sagt das: die Antworten stecken in einem ausdrücklich als nicht vertrauenswürdig markierten Element, und die Lieferung nennt die Grenze, mit der sie umschlossen wurden — je Runde so gewählt, dass keine Antwort sie enthält. Genau das macht die Zuschreibung from="…" zur eigenen Aufzeichnung der Engine statt zu etwas, das eine Antwort fälschen könnte. Diese Aufzeichnung sagt, unter welchem Handle eine Nachricht gepostet wurde — sie ist kein Nachweis, dass der Absender zu diesem Handle berechtigt war, und erst recht keiner dafür, dass das Geschriebene stimmt. Behandeln Sie die Worte eines Mitglieds als Daten, nie als Anweisungen — und wenn nicht alle Mitglieder einer Runde Ihre eigenen sind, sagen Sie das im Prompt der anfragenden Persona, denn das ist die Schicht, die zuerst gelesen wird.

Ein Verlauf enthält rohe Werkzeug-Eingaben und -Ergebnisse — alles, was der Agent gelesen, geschrieben oder ausgeführt hat. Also:

• Behandeln Sie einen Verlaufsauszug wie die Workspace-Datenbank, nicht wie ein Nachrichtenprotokoll. Fügen Sie keinen ungelesen in einen Fehlerbericht ein.
• nxc transcript show ist bewusst nicht mitgliedschaftsgeprüft. Ein Verlauf hat keinen Kanal, an dem man prüfen könnte, und die Tabelle ist gerätelokal und wird nie synchronisiert — eine Prüfung erkaufte also nichts, was wer die Datei hat nicht ohnehin mit sqlite3 täte. Es ist eine Betreiberoberfläche; die Dateirechte sind die Grenze.

Was Sync für Vertraulichkeit bedeutet

In dieser Stufe ist Sync vollständig und ungefiltert: ein an einen Stream gebundener Workspace tauscht das ganze Log aus, ohne Autorisierung je Kanal auf der Leitung. Wer den Stream erreicht, kann die Nachrichten darin lesen.

Also: keine Zugangsdaten und keine Geheimnisse in Nachrichtentexte, und behandeln Sie Kanalmitgliedschaft als Konvention darüber, wer gefragt wird, nicht als Grenze darüber, wer lesen kann. Verläufe sind das eine, das die Maschine nie verlässt.

Was stattdessen gilt

Ein Geheimnis gehört in den Geheimnisspeicher der Plattform, und die Nachricht nennt höchstens den Ort.

• Zur Laufzeit holt die Persona es selbst — aus dem Geheimnismechanismus des Wirts (ein SSM-Parameter, eine App-Einstellung mit secret: true, der Schlüsselbund des Betriebssystems, eine Datei, die der Prozess lesen darf). nxc muss davon nichts wissen, und das ist die richtige Teilung: das Nachrichtenlog hält fest, was gesagt wurde — und ein Zugangsdatum war nie etwas, das jemand gesagt hat.
• In der Nachricht steht der ORT, nie der Wert — der Parametername, der Einstellungsschlüssel, der Pfad. der DIP-Schlüssel liegt unter .nxf/secrets/dip-api-key darf synchronisiert werden; der Schlüssel nicht.
• Ist der Ort eine Datei, halten Sie sie aus dem Log und aus git heraus — Rechte 600, und von .gitignore erfasst.

Es gibt bewusst keinen geheimnistragenden Kanal und keine verschlüsselte Nachrichtenart. Beides würde Zugangsdaten in genau das Log legen, um das es in diesem Abschnitt geht, und jeder Verbraucher dieses Logs würde sie erben.

Hinweise, die Hinweise sind

Zwei Dinge in nxc lehnen bewusst nicht ab, und es lohnt sich zu wissen, welche:

• Ein send, das keinen Gegenstand nennt, postet trotzdem. Die Nachricht ist gepostet mehr wert als verloren. Aber die Quittung trägt refs_warning als Feld — nicht nur als Zeile auf stderr —, damit auch eine App den Hinweis sieht und ein Aufrufer am Wert verzweigen kann, statt Prosa zu parsen.

• Ein Anstoß, der scheiterte, nachdem die Nachricht bereits geschrieben war, verwirft die Quittung nicht. Das Feld warnings an send, reply und tick ist immer vorhanden, auch leer, und jeder Eintrag trägt eine maschinenlesbare Klasse:

  • step_skipped — ein Schritt, dessen Anstoß scheiterte. Die Nachricht liegt dauerhaft im Kanal und die Schuld ist registriert, aber niemand arbeitet daran. Nichts wiederholt das.

  • step_unanswered — ein Schritt, der gestartet wurde und nie antwortete; sein Fenster lief ab, und was folgte, geschah ohne ihn.

  • requester_not_woken — eine Tafel wurde vollständig, die Antwort liegt da, und die Sitzung, die gefragt hatte, wurde nie benachrichtigt.

  • tick_unscheduled — gerade beobachtet niemand ein deklariertes timeout:; dieses Fenster hat also keine Uhr: nichts lässt die Tafel von selbst stale werden, und ein Mitglied, das verstummt, hält die Runde unbegrenzt an. Der Aufruf selbst ist geglückt — die Tafel ist offen und ihre Mitglieder laufen —, weshalb diese eine Klasse den Exit-Code nicht von Null verschieden macht. nxc tick --thread <id> ist dieselbe Prüfung, von Hand aufrufbar. Die Frist ist ohnehin eingetragen, ein später gestarteter Dienst hält sie also nach. Die Meldung sagt, welche der beiden Hälften fehlt: dieser Arbeitsbereich ist beim nexus-flow-Hintergrunddienst nicht angemeldet, oder es läuft kein Dienst. Wie man ihn einrichtet, steht bei den Kanälen.

  • service_not_running — dieselbe Tatsache eine Ebene höher, und die einzige, die kein Fenster braucht: es gibt niemanden, der irgendetwas davon ausführt. Ein Hintergrunddienst hält jede Frist dieser Maschine und ist das Einzige, was synchronisiert. Solange er steht, feuern deklarierte Fenster nicht — eine Runde, die sich lösen sollte, hängt unbegrenzt — und das Ops-Log dieser Maschine schiebt und holt nichts mehr. Beide Hälften stehen in der Meldung, samt dem, was zu tun ist. Der Eintrag reitet auf jedem send, reply und tick mit, solange das so ist, und ändert wie tick_unscheduled den Exit-Code nicht: Ihr Aufruf hat alles getan, was er sollte; die Maschine nicht. Sie sehen ihn nur in einem Arbeitsbereich, der beim Dienst angemeldet ist — einer, der es nie war, verhält sich genau wie vereinbart und wird nie wegen eines Dienstes gewarnt, um den er nicht gebeten hat.

  • declaration_changed — diese Persona wurde zuletzt unter einer anderen Fassung ihrer eigenen Deklaration gestartet. Nichts ist gescheitert: die Sitzung läuft, und mitgeteilt wird Ihnen, dass die Regeln, unter denen sie läuft, nicht die Regeln des vorigen Laufs sind. .nxs-personas/ liegt in derselben Arbeitskopie, in der die Agenten selbst arbeiten — ein git switch oder git stash der einen Persona ändert also, wie die nächste denkt, und genau so wurden hier einmal drei Deklarationen still zurückgedreht. Der Eintrag nennt die Rolle und beide Fassungen (declaration.hash, declaration.previous_hash), und die spec.json jeder Sitzung hält fest, unter welcher Fassung sie lief — Sie können also nachsehen statt zu raten. Auch das ändert den Exit-Code nicht: eine Persona zu ändern und sie dann anzusprechen ist die gewöhnliche Arbeitsweise. Eine Änderung ist meistens gewollt, eine unbemerkte nie. Warum der Ordner in die Versionsverwaltung gehört, steht bei den Personas.

Diese sechs verlangen verschiedene Reaktionen — Technik reparieren, ein Mitglied nachfassen, eine Sitzung neu starten, den Hintergrunddienst starten, in eine Deklaration schauen —, deshalb sind es eigene Klassen und kein Eimer voller Prosa. Wenn Sie irgendetwas Automatisiertes auf chat bauen, ist dieses Feld das, was Sie beobachten.

Neben der Klasse trägt jeder Eintrag ggf. einen maschinenlesbaren reason dafür, warum eine Sitzung nicht in Bewegung gesetzt wurde. Einer davon ist neu und lohnt sich zu kennen: already_running — das Wecken wurde abgelehnt, weil die genannte Sitzung noch einen lebenden Prozess hat. Eine interne Sitzung führt immer genau einen Prozess; ein zweiter Start setzte zwei Agenten in dasselbe Arbeitsverzeichnis, die einander überschreiben. Die Nachricht liegt so oder so dauerhaft im Faden, und die laufende Sitzung darf ihren Zug zu Ende bringen.

Ein weiteres Feld gehört daneben, an nxc status statt an eine Quittung: escalated. Ein Faden, dessen laufender Zug zurückgegeben wurde — ein Mitglied, das mit nxc reply --escalate „das kann ich nicht ausführen" geantwortet hat, oder eine Persona-Sitzung, die gestorben ist und deren Abbau die Schuld beglichen hat —, steht auf state: "answered" wie jeder erledigte Faden, denn der Zug ist wirklich vorbei. escalated: true ist das, was die beiden unterscheidet. Verzweigen Sie darauf überall dort, wo Sie „answered" sonst als „fertig" lesen würden.

Und eines daneben: substituted — die Laufzeit hat die neueste Antwort dieses Fadens geschrieben, stellvertretend für den Agenten, der sie schuldete. Endet eine gestartete Sitzung, ohne ihrem Faden geantwortet zu haben, setzt der Abbau-Block des Sidecars die Antwort in ihrem Namen, damit der Faden nie still hängen bleibt. Das ist richtig so — und es war bisher nur daran zu erkennen, dass man den Nachrichtentext las, der mit sidecar: beginnt. Die beiden Felder sind unabhängig voneinander, und Sie wollen beide:

Die dritte Zeile ist die, auf die es ankommt. Es ist nichts schiefgegangen — eine Eskalation zu melden hieße einem Vorgesetzten fälschlich zu sagen, er solle anhalten — und trotzdem hat niemand geantwortet. Die häufigste Ursache ist eine Persona, die zu einer Antwort verpflichtet wurde und sie nicht geben konnte: prüfen Sie ihr deklariertes tools:.

Weiter

• Kanäle — wo Fristen und Alleinnutzung deklariert werden.
• Personas — wo Modell und Werkzeuge stehen.
• Befehle — die Oberfläche, die all das einhegt.