Prompt vs. 流水线 – 别让智能体随意聊天 – Agentic Engineering

Prompt vs. Pipeline – warum ich Agents nicht mehr frei chatten lasse

Datum: 2026-02-01

Der verführerische 200-Zeilen-Prompt

Ein langer Prompt im Chat fühlt sich mächtig an: „Lies das Repo, fix alle Tests, update Briefings, prüf Translations.“ In der Praxis liefert das inkonsistente Halbfertigkeiten – weil nichts die Reihenfolge, die Logs und das Ende erzwingt.

Agentic Engineering verschiebt Wiederholbares von der Prompt-Ebene in Pipelines: versionierte Scripts, Orchestratoren, Step-Services – die KI arbeitet innerhalb der Pipeline, nicht als freier Interpret.

Das Problem

Chat-PromptFolge
Nicht versioniertJeder Entwickler promptet anders
Nicht testbarKein Gate vor Merge
Jedes Mal andersModell-Update = anderes Verhalten
Kein Exit-CodeCI weiß nicht, ob grün

Exploration im Chat ist wertvoll. Produktion will Steps, Logs und Wiederholbarkeit.

Das Pattern: Pipeline statt Prompt

AnsatzStärkeSchwäche
Chat-PromptSchnell, explorativNicht reproduzierbar
CLI-PipelineSteps, Logs, Exit-CodeBraucht Architektur
Ralph-LoopKonvergenz bis objektiv grünBraucht Subagent-Scope

`start-vendor-development-workflow.php` führt feste Steps aus – Logs leeren, Checks, Tests, Zusammenfassung. Nicht „mach mal alles“.

Anatomie einer Pipeline

001. Entry: `start-vendor-*.php` – ein Kommando für Mensch/CI.

002. Orchestrator: Kennt nur die Reihenfolge der Steps.

003. Step-Services: Je eine `execute…`-Methode, ein fachlicher Teil.

004. Agent-Aufruf: Nur wo nötig – innerhalb eines Steps, mit Subagent-Scope.

005. Exit + Logs: Objektives Ende.

Die KI bekommt keine offene Weltaufgabe, sondern: „Führe Step 003 aus Briefing X aus.“

So sieht es bei uns aus

PipelineZweck
`start-vendor-development-workflow.php`Tägliche Qualität
`start-vendor-feature.php`Feature aus `features/`
`start-vendor-phpunit-tests.php`Schichtweise Tests
`start-vendor-subagent-ralph-loop.php`Subagent bis konvergent
`start-vendor-check-screen.php`Alle Screens curl/UI

Jeder Step ist ein Service mit PHPDoc und Briefing. Der Orchestrator enthält keine versteckte Business-Logik in If-Ketten – nur Step-Aufrufe.

Wann Prompt, wann Pipeline?

SituationEmpfehlung
„Erkläre diese Funktion“Chat-Prompt
Spike, 30-Min-ExperimentChat-Prompt
Neuer Screen + Tests + i18nPipeline + Subagents
Nightly QualityCron + Pipeline
Vor jedem PushDevelopment-Workflow

Regel: Wiederholt sich die Aufgabe zum zweiten Mal → Pipeline oder Subagent bauen.

Anti-Patterns

001. Pipeline im Chat nachbauen – „Zuerst A, dann B“ ohne Script → driftet sofort.

002. Orchestrator als God-Class – 2000 Zeilen Logik statt Step-Services.

003. Steps ohne Briefing – KI halluziniert Reihenfolge und Namen.

004. Kein Test-Gate – Pipeline endet ohne PHPUnit/curl.

005. Prompt-Logik in `start-*.php` – Gehört in Orchestrator/Services.

Verzahnung mit Rules und Subagents

Pipelines allein reichen nicht. Rules setzen Grenzen (kein try-catch, Briefing-First). Subagents liefern Spezialisten pro Step. Ralph-Loop macht das Ende messbar.

code
Pipeline-Step „Translations prüfen“
    → start-vendor-subagent-ralph-loop.php subagent-check-translations
    → OPEN_FAILURES=0

Häufige Fragen

Ist das nicht Overhead für kleine Fixes?

Für einen Tippfehler: ja, Chat reicht. Für alles, was Schichten berührt: Pipeline spart Zeit über die Woche.

Muss jede Pipeline einen Agent haben?

Nein – reine PHPUnit-Steps brauchen keinen LLM-Lauf. Agent nur wo Interpretation nötig ist.

Wie dokumentiere ich neue Pipelines?

Briefing unter `briefing/CLIOrchestrator/`, dann PHP – Briefing-First.

Verwandte Beiträge

BeitragThema
Orchestrator-PatternDünner Screen, fette Steps
Cursor Agent per CLIHeadless Ausführung
Feature-Workflow`features/` als Deploy-Pipeline
Ralph-LoopKonvergenz

Takeaway

Produktion will Steps, Logs und Wiederholbarkeit – nicht Kreativität pro Run. Prompts bleiben für Exploration; alles Wiederholbare gehört in versionierte Pipelines. Wer Agents nicht mehr „frei chatten“ lässt, gewinnt Vorhersagbarkeit – und verliert nur Chaos.