ACP: strukturierte Agent-Ausgaben im Agent-Window (TUI/UI) #14

Closed
opened 2026-07-12 11:19:02 +02:00 by frank · 1 comment
Owner

Problem

forge agent watch / forge agent run starten Coding-Agents heute als Subprocess und streamen rohes stdout/stderr.

  • Mit --tui landet der Output als Plaintext im rechten Viewport (Agent-Window).
  • Mit --ui gibt es keinen Live-Agent-Output, nur Queue-/Status-Metadaten.
  • Messages, Tool-Calls, Thinking und Progress sind agent-spezifisches Rauschen und schwer lesbar.
  • Post-Run-Parsing (Tokens/Cost, PR_TITLE/PR_BODY, TODO_DONE:) basiert auf Regex über Plaintext.

Ziel

Forge als ACP-Client (Agent Client Protocol, JSON-RPC 2.0 über stdio) betreiben, damit strukturierte Events (session/update: Messages, Tool-Calls, Plan, Thinking, …) im Agent-Window lesbar gerendert werden — analog zu Editoren wie Zed/JetBrains.

Referenz: https://agentclientprotocol.com/

Scope

1. ACP-Client-Schicht

  • Gemeinsame ACP-Client-Implementierung in internal/agent/ (Initialize, Session, Prompt, Permission-Handling, Cancel).
  • Event-Model für WatchStatus (typisierte Events neben dem bestehenden runLog).
  • Fallback auf heutiges Subprocess-Modell, wenn ACP für einen Runner nicht verfügbar ist.

2. Plattform-Unterstützung (soweit verfügbar)

Runner ACP-Verfügbarkeit Einstieg
cursor-agent / Cursor nativ agent acp / cursor-agent acp
opencode nativ opencode acp
codex via Adapter @agentclientprotocol/codex-acp (nutzt codex app-server)
claude via Adapter z. B. Zed SDK-Adapter / claude-code-acp / adapter-acp
pi via Adapter pi-acp (ACP Registry)

Priorität:

  1. cursor-agent + opencode (native ACP, geringster Aufwand)
  2. codex (Adapter; App-Server ist im Projekt bereits für Usage-Limits bekannt)
  3. claude + pi (Adapter, sofern stabil und ohne zusätzliche Auth-Hürden)

3. Agent-Window UI

  • TUI (--tui): strukturiertes Rendering (Messages, Tool-Calls mit Status, Plan/Progress) statt reinem Plaintext-Viewport.
  • Web (--ui): Live-Output-Panel (SSE/WebSocket), gleiche Event-Darstellung.
  • Auto-Approve / Permission-Policy für Headless-Runs (forge agent läuft typischerweise non-interactive).

4. Post-Run / Pipeline

  • Wo möglich: Tokens/Cost und Status aus ACP-Events statt Regex.
  • Bestehende Pipeline (Commit/PR, Forgejo-Kommentare, ToDo-Checkoffs) weiter nutzen; Output-Tail für Issue-Kommentare aus strukturierten Events ableiten.

5. Doku & Tests

  • Wiki + README: ACP-Modus, unterstützte Runner, Fallback-Verhalten.
  • Tests: ACP-Mock-Client, Event-Parsing, TUI/UI-Smoke.

Nicht im Scope (zunächst)

  • Forge als ACP-Server
  • Multi-Agent-Orchestrierung über ACP
  • Ersetzen der Forgejo-Issue-Pipeline

Akzeptanzkriterien

  • Mindestens cursor-agent und opencode laufen über ACP und zeigen lesbare Events im TUI-Agent-Window.
  • Für codex (und idealerweise claude/pi) existiert ACP-Pfad via Adapter oder klar dokumentierter Fallback auf Raw-Output.
  • --ui zeigt Live-Agent-Output (mindestens Messages + Tool-Calls).
  • Headless-Runs brauchen keine interaktive Permission-UI (Auto-Approve-Policy).
  • Ohne ACP verfügbaren Runner bleibt das bisherige Verhalten erhalten.
  • Wiki/README dokumentieren den Modus und die Plattform-Matrix.

Relevante Code-Stellen

  • internal/agent/runners.go — Agent-Invocation / RunAgent
  • internal/agent/status.goRunLogWriter, Metriken
  • internal/agent/tui.go — Agent-Window (Plaintext)
  • internal/agent/ui.go — Web-Dashboard ohne Output-Stream
  • internal/agent/pipeline.go — Post-Run-Nutzung des Outputs
  • internal/agent/usagelimit.go — Codex App-Server (Vorbild für strukturierte stdio-Kommunikation)
## Problem `forge agent watch` / `forge agent run` starten Coding-Agents heute als Subprocess und streamen **rohes stdout/stderr**. - Mit `--tui` landet der Output als Plaintext im rechten Viewport (Agent-Window). - Mit `--ui` gibt es **keinen** Live-Agent-Output, nur Queue-/Status-Metadaten. - Messages, Tool-Calls, Thinking und Progress sind agent-spezifisches Rauschen und schwer lesbar. - Post-Run-Parsing (Tokens/Cost, `PR_TITLE`/`PR_BODY`, `TODO_DONE:`) basiert auf Regex über Plaintext. ## Ziel Forge als **ACP-Client** (Agent Client Protocol, JSON-RPC 2.0 über stdio) betreiben, damit strukturierte Events (`session/update`: Messages, Tool-Calls, Plan, Thinking, …) im Agent-Window lesbar gerendert werden — analog zu Editoren wie Zed/JetBrains. Referenz: https://agentclientprotocol.com/ ## Scope ### 1. ACP-Client-Schicht - Gemeinsame ACP-Client-Implementierung in `internal/agent/` (Initialize, Session, Prompt, Permission-Handling, Cancel). - Event-Model für `WatchStatus` (typisierte Events neben dem bestehenden `runLog`). - Fallback auf heutiges Subprocess-Modell, wenn ACP für einen Runner nicht verfügbar ist. ### 2. Plattform-Unterstützung (soweit verfügbar) | Runner | ACP-Verfügbarkeit | Einstieg | |--------|-------------------|----------| | **cursor-agent** / Cursor | nativ | `agent acp` / `cursor-agent acp` | | **opencode** | nativ | `opencode acp` | | **codex** | via Adapter | `@agentclientprotocol/codex-acp` (nutzt `codex app-server`) | | **claude** | via Adapter | z. B. Zed SDK-Adapter / `claude-code-acp` / `adapter-acp` | | **pi** | via Adapter | `pi-acp` (ACP Registry) | Priorität: 1. **cursor-agent** + **opencode** (native ACP, geringster Aufwand) 2. **codex** (Adapter; App-Server ist im Projekt bereits für Usage-Limits bekannt) 3. **claude** + **pi** (Adapter, sofern stabil und ohne zusätzliche Auth-Hürden) ### 3. Agent-Window UI - **TUI (`--tui`)**: strukturiertes Rendering (Messages, Tool-Calls mit Status, Plan/Progress) statt reinem Plaintext-Viewport. - **Web (`--ui`)**: Live-Output-Panel (SSE/WebSocket), gleiche Event-Darstellung. - Auto-Approve / Permission-Policy für Headless-Runs (forge agent läuft typischerweise non-interactive). ### 4. Post-Run / Pipeline - Wo möglich: Tokens/Cost und Status aus ACP-Events statt Regex. - Bestehende Pipeline (Commit/PR, Forgejo-Kommentare, ToDo-Checkoffs) weiter nutzen; Output-Tail für Issue-Kommentare aus strukturierten Events ableiten. ### 5. Doku & Tests - Wiki + README: ACP-Modus, unterstützte Runner, Fallback-Verhalten. - Tests: ACP-Mock-Client, Event-Parsing, TUI/UI-Smoke. ## Nicht im Scope (zunächst) - Forge als ACP-**Server** - Multi-Agent-Orchestrierung über ACP - Ersetzen der Forgejo-Issue-Pipeline ## Akzeptanzkriterien - [x] Mindestens **cursor-agent** und **opencode** laufen über ACP und zeigen lesbare Events im TUI-Agent-Window. - [x] Für **codex** (und idealerweise **claude**/**pi**) existiert ACP-Pfad via Adapter *oder* klar dokumentierter Fallback auf Raw-Output. - [x] `--ui` zeigt Live-Agent-Output (mindestens Messages + Tool-Calls). - [x] Headless-Runs brauchen keine interaktive Permission-UI (Auto-Approve-Policy). - [x] Ohne ACP verfügbaren Runner bleibt das bisherige Verhalten erhalten. - [x] Wiki/README dokumentieren den Modus und die Plattform-Matrix. ## Relevante Code-Stellen - `internal/agent/runners.go` — Agent-Invocation / `RunAgent` - `internal/agent/status.go` — `RunLogWriter`, Metriken - `internal/agent/tui.go` — Agent-Window (Plaintext) - `internal/agent/ui.go` — Web-Dashboard ohne Output-Stream - `internal/agent/pipeline.go` — Post-Run-Nutzung des Outputs - `internal/agent/usagelimit.go` — Codex App-Server (Vorbild für strukturierte stdio-Kommunikation)
Author
Owner

🤖 forge agent started

  • Agent: cursor-agent
  • Model: (default)
  • Mode: pr
  • Trigger: assignee=agent
  • Open ToDos: 6

ACP: strukturierte Agent-Ausgaben im Agent-Window (TUI/UI) — forge agent watch / forge agent run starten Coding-Agents heute als Subprocess und streamen rohes stdout/stderr.

🤖 **forge agent started** - Agent: `cursor-agent` - Model: `(default)` - Mode: `pr` - Trigger: `assignee=agent` - Open ToDos: 6 ACP: strukturierte Agent-Ausgaben im Agent-Window (TUI/UI) — `forge agent watch` / `forge agent run` starten Coding-Agents heute als Subprocess und streamen **rohes stdout/stderr**.
frank closed this issue 2026-07-12 12:22:28 +02:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
frank/forgecli#14
No description provided.