Umsetzungsplaene fuer vier neue Agenten-Tools angelegt
Aus Richards Ideensammlung, nach Sichtung des vorhandenen Codes: - FileRW-Papierkorb + Cleanup-Job: delete verschiebt nach .trash statt endgueltig zu loeschen, Aufraeumen ueber IToolJobProvider/ToolJobScheduler. Macht Loeschen reversibel und erlaubt damit, FileRW.delete im Staging von Approve auf Auto herunterzustufen. - AgentInspector: lesende Aufsicht ueber andere Agenten. Beleg-basiert (Audit/Receipts/Taskboard) statt datei-basiert; harte Allowlist, damit AgentSettings.json mit den API-Keys nicht in einen LLM-Kontext geraet. - AgentEditor-Haertung: Identity/Soul-Aenderungen ueber die vorhandene StagingPolicy freigabepflichtig machen, Selbstbearbeitung sperren, Audit + restore ergaenzen. Das Tool selbst existiert bereits. - WebSearch: Suche als eigenes Tool, Lesen bleibt bei WebFetch hinter der Domain-Whitelist. Kein agent-reach (Klartext-Cookies, Fremdprozess). Trennung Rechercheagent / handelnder Agent gegen Prompt Injection. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Richard
@@ -0,0 +1,150 @@
|
||||
# Umsetzungsplan: AgentEditor härten (Personalverwaltung)
|
||||
|
||||
> Stand: 2026-08-05
|
||||
> Ziel: Änderungen an Identity und Soul im laufenden Betrieb bleiben möglich,
|
||||
> werden aber freigabepflichtig, nachvollziehbar und rücknehmbar.
|
||||
> Reihenfolge: **Nach AgentInspector.** Kein neues Tool — Härtung des
|
||||
> bestehenden `AgentEditorTool`.
|
||||
|
||||
---
|
||||
|
||||
## 1. Ausgangslage
|
||||
|
||||
Das gewünschte „HR-Tool" existiert bereits:
|
||||
`src/ClawdDotNet.Tools.AgentEditor/AgentEditorTool.cs`
|
||||
|
||||
| Aktion | Verhalten |
|
||||
|---|---|
|
||||
| `list_agents` | Übersicht inkl. `Tools`, `HasIdentity`, `HasSoul`, `IsSelf` |
|
||||
| `read_identity` / `read_soul` | Datei lesen |
|
||||
| `update_identity` / `update_soul` | Datei schreiben, vorher `.bak_<zeitstempel>` |
|
||||
| `create_agent` | Grundstruktur mit Identity und Soul |
|
||||
|
||||
Bereits richtig gelöst: keine `AgentSettings.json`, keine Chat-Daten,
|
||||
zeitgestempelte Backups statt Überschreiben, und die Tool-Zuweisung bleibt dem
|
||||
Menschen vorbehalten.
|
||||
|
||||
Ebenfalls bestätigt: **Ein Neustart des Agenten ist nötig.** Identity und Soul
|
||||
werden beim Laden in `AgentConfig` eingelesen
|
||||
(`src/ClawdDotNet.Core/Config/AgentConfig.cs:20,27`); einen Reload-Pfad gibt es
|
||||
nicht. Die Annahme aus der Ideensammlung stimmt also — „anhalten und neu
|
||||
starten" ist der vorgesehene Weg, kein Fehler.
|
||||
|
||||
---
|
||||
|
||||
## 2. Die drei offenen Lücken
|
||||
|
||||
### 2.1 Keine menschliche Freigabe
|
||||
|
||||
`PermissionGate` (`src/ClawdDotNet.Core/Security/PermissionGate.cs`) prüft
|
||||
genau eine Sache:
|
||||
|
||||
```csharp
|
||||
public bool IsAllowed(string agentId, string toolName, AgentConfig agentConfig)
|
||||
=> agentConfig.Tools.ContainsKey(toolName);
|
||||
```
|
||||
|
||||
Wer das Tool hat, darf alles damit. Ein Agent mit `AgentEditor` kann die
|
||||
Persönlichkeit jedes anderen Agenten der Instanz umschreiben — unbeaufsichtigt,
|
||||
zwischen zwei Ticks eines Cron-Jobs.
|
||||
|
||||
Die Ideensammlung formuliert den Anspruch anders: Änderungen sollen **auf
|
||||
menschliche Anweisung** erfolgen. Genau diese Kopplung fehlt.
|
||||
|
||||
**Lösung — vorhandene Infrastruktur nutzen, nichts neu bauen.**
|
||||
`src/ClawdDotNet.Core/Staging/` enthält bereits die vollständige Kette:
|
||||
`StagingPolicy` entscheidet je `Tool.Aktion`, `StagingGate` fängt den Aufruf
|
||||
ab, `StagingService` bietet `ApproveAsync`/`RejectAsync` mit `decidedBy`.
|
||||
|
||||
Es genügt, die Regeln zu ergänzen:
|
||||
|
||||
```csharp
|
||||
["AgentEditor.update_identity"] = StagingDecision.Approve,
|
||||
["AgentEditor.update_soul"] = StagingDecision.Approve,
|
||||
["AgentEditor.create_agent"] = StagingDecision.Approve,
|
||||
```
|
||||
|
||||
Lesende Aktionen bleiben `Auto` — Staging soll schützen, nicht lähmen (so
|
||||
begründet es der Kommentar an `DefaultRules` bereits selbst). Damit wandert
|
||||
jede Persönlichkeitsänderung in die Freigabeliste, und der Mensch entscheidet.
|
||||
Das ist zugleich die wörtliche Umsetzung von „auf menschliche Anweisung".
|
||||
|
||||
### 2.2 Selbstbearbeitung ist möglich
|
||||
|
||||
`HandleListAgents` liefert `IsSelf` bereits mit — ausgewertet wird es nirgends.
|
||||
Ein Agent kann seine eigene Soul umschreiben: die Datei, die sein Verhalten,
|
||||
seine Grenzen und seine Vorsicht definiert.
|
||||
|
||||
Das ist keine hypothetische Gefahr. Ein Agent, der in einer Schleife feststeckt
|
||||
und „hilfsbereit" sein will, kann sich selbst die Einschränkung wegschreiben,
|
||||
an der er scheitert.
|
||||
|
||||
**Lösung:** `update_identity`/`update_soul` mit `agentId == context.AgentId`
|
||||
werden abgelehnt — mit einer Begründung, die dem LLM den richtigen Weg zeigt
|
||||
(„Änderungen an der eigenen Identity/Soul nimmt der Mensch vor; formuliere
|
||||
deinen Änderungswunsch stattdessen als Vorschlag"). Konfigurierbar über
|
||||
`allowSelfEdit` (Default `false`), damit der Betreiber die Wahl behält.
|
||||
|
||||
### 2.3 Kein Audit, kein Rückweg
|
||||
|
||||
Die `.bak_`-Dateien sind ein guter Anfang, aber:
|
||||
- sie zeigen nicht, **wer** die Änderung veranlasst hat,
|
||||
- es gibt keine Aktion, um sie zurückzuspielen — das ist Handarbeit im Explorer,
|
||||
- die Antwort ans LLM enthält keinen Diff, also sieht auch der Mensch im
|
||||
Chatverlauf nicht, was sich geändert hat.
|
||||
|
||||
**Lösung:** Audit-Eintrag über die vorhandene `IAuditRepository`, `restore`-
|
||||
Aktion, und ein knapper Diff (geänderte Zeilen, nicht der Volltext) in der
|
||||
Rückmeldung.
|
||||
|
||||
---
|
||||
|
||||
## 3. Umsetzungsschritte
|
||||
|
||||
### Slice 1 — Freigabe und Selbstschutz
|
||||
- [ ] Drei Regeln in `StagingPolicy.DefaultRules` ergänzen
|
||||
- [ ] `allowSelfEdit` in `AgentEditorToolSettings`
|
||||
(`Models/ToolSettingsViewModels.cs:498`), Default `false`
|
||||
- [ ] Selbstbearbeitungs-Prüfung in `HandleUpdateFileAsync`
|
||||
- [ ] Tests: Selbstbearbeitung abgelehnt, mit `allowSelfEdit = true` erlaubt,
|
||||
Staging-Entscheidung je Aktion korrekt aufgelöst
|
||||
|
||||
### Slice 2 — Nachvollziehbarkeit
|
||||
- [ ] Diff in der Rückmeldung (geänderte Zeilen mit `+`/`-`, gekappt)
|
||||
- [ ] Audit-Eintrag je Änderung: Ziel-Agent, Datei, Backup-Name
|
||||
- [ ] `list_backups`-Aktion: vorhandene `.bak_`-Stände eines Agenten
|
||||
- [ ] `restore`-Aktion: Stand zurückspielen (erzeugt seinerseits ein Backup,
|
||||
damit auch ein Restore rücknehmbar bleibt) — ebenfalls `Approve`
|
||||
|
||||
### Slice 3 — Betriebstauglichkeit
|
||||
- [ ] Hinweis in der Erfolgsmeldung: „Wirksam nach Stop/Start des Agenten"
|
||||
(heute fehlt er — der Agent hält die Änderung sonst für sofort aktiv)
|
||||
- [ ] `frm_InstanceManager`: Neustart eines einzelnen Agenten anbieten, falls
|
||||
dafür heute die ganze Instanz neu gestartet werden muss
|
||||
- [ ] Aufräumen: `FindAgentDirectory` durch den gemeinsamen
|
||||
`AgentDirectoryResolver` aus dem AgentInspector-Plan ersetzen
|
||||
- [ ] `.bak_`-Dateien in die Aufbewahrungslogik einbeziehen (sie wachsen sonst
|
||||
unbegrenzt) — Menge je Agent begrenzen, z. B. 20 Stände
|
||||
|
||||
---
|
||||
|
||||
## 4. Bewusst nicht umgesetzt
|
||||
|
||||
**Hot-Reload von Identity/Soul.** Technisch machbar, aber ein Agent, der
|
||||
mitten in einem Lauf seine Persönlichkeit wechselt, produziert einen
|
||||
Konversationsverlauf, dessen erste Hälfte einer anderen Rolle gehorcht als
|
||||
die zweite. Der Neustart ist hier die ehrlichere Grenze — und ohnehin der
|
||||
Weg, den die Ideensammlung selbst vorschlägt.
|
||||
|
||||
---
|
||||
|
||||
## 5. Abnahmekriterien
|
||||
|
||||
- `update_soul` landet in der Freigabeliste und wird erst nach menschlicher
|
||||
Bestätigung ausgeführt; `read_soul` läuft weiterhin ohne Rückfrage durch.
|
||||
- Ein Agent kann seine eigene Soul nicht ändern.
|
||||
- Nach einer Änderung ist im Audit ersichtlich: wer, wann, an wem, welche Datei.
|
||||
- `restore` stellt einen früheren Stand wieder her und legt dabei selbst ein
|
||||
Backup an.
|
||||
- Die Rückmeldung an den Agenten nennt ausdrücklich, dass die Änderung erst
|
||||
nach einem Neustart greift.
|
||||
Reference in New Issue
Block a user