|

Agentic Orchestration Teil 2: Abhängigkeits-Updates automatisieren

AI Agents

Claude

Dependency Management

Automation

In Teil 1 haben wir unsere lokale ~/.claude-Architektur und das Konzept der Verkettung von Agenten über strukturierte Übergabedokumente etabliert. Lassen Sie uns dies nun mit unserem ersten konkreten Workflow in die Praxis umsetzen: /orchestrate dependency-updates <repo>.

Die dependency-updates Pipeline

Wenn man Paket-Updates über mehrere Repositories hinweg verwaltet, ist der Umgang mit Hunderten von Minor- und Patch-Bumps anstrengend. Um dies zu automatisieren, definieren wir den folgenden Workflow in unserer Datei ~/.claude/commands/orchestrate.md:

planner -> security-upgrader -> pr-creator

Schauen wir uns genau an, was jeder Agent in dieser Kette tut.

1. Der Planner Agent

Der planner (angetrieben durch das hochleistungsfähige opus-Modell) ist das Gehirn der Operation. Anstatt nur ein einfaches npm outdated auszuführen, ist unser Planner angewiesen, aktiv drei separate Schwachstellenquellen über Terminalbefehle abzugleichen:

# Source 1: Local pnpm audit
pnpm audit --json > audit-report.json

# Source 2: GitHub Dependabot alerts
gh api "/repos/${REPO}/dependabot/alerts" --jq '.[] | select(.state=="open")'

# Source 3: GitHub Advisory Database
gh api "/advisories" --field type=reviewed --field ecosystem=npm

Er führt diese Berichte zusammen und dedupliziert sie. Dadurch wird sichergestellt, dass ein Paket, selbst wenn es vom lokalen Audit nicht erfasst wird, aber in der GitHub Advisory Database existiert, markiert wird.

Entscheidend ist, dass er logische Abhängigkeiten gruppiert und nach Versionssprung trennt. Er erstellt zwei Eimer (Buckets): Minor/Patch-Updates gehen an den security-upgrader und Major-Updates an den major-upgrader. Er versieht den Plan dann mit den CVE- und GHSA-IDs:

## HANDOFF: planner -> security-upgrader
### Minor/Patch Upgrades
- flatted 3.2.0 -> 3.4.0 (HIGH, CVE-2024-XXXX, GHSA-xxxx-yyyy)
- semver 7.0.0 -> 7.6.3 (MODERATE, GHSA-aaaa-bbbb)

2. Der Security Upgrader Agent

Der security-upgrader erhält die Übergabe und führt den Plan aus. Für jede Gruppe von Paketen führt er die Upgrades sequenziell durch:

  1. Führt pnpm add package@latest aus.
  2. Führt das vollständige Validierungstor aus: test -> format -> lint -> build.
  3. Wenn alle vier erfolgreich sind, geht er zur nächsten Paketgruppe über.

Durch Ausführen der vollständigen Validierungs-Suite nach jedem Paket-Bump garantiert der Agent, dass die Codebasis stabil bleibt.

3. Der PR Creator Agent

Sobald der security-upgrader alle anvisierten Abhängigkeiten erfolgreich aktualisiert hat, übergibt er den endgültigen Status an den pr-creator.

Der pr-creator-Agent öffnet einen GitHub Pull Request. Er liest die PULL_REQUEST_TEMPLATE.md des Repositories, um die Beschreibung perfekt zu formatieren, listet alle aktualisierten Pakete auf und bestätigt, dass das Validierungstor (Test, Lint, Build) erfolgreich bestanden wurde.

Die Schönheit der Kette

Durch die Trennung der Aufgaben in planner, security-upgrader und pr-creator hat jeder Agent einen einzigen, hochgradig fokussierten Prompt. Der Planner muss nicht wissen, wie man das gh auth CLI-Tool verwendet, und der PR Creator muss nicht wissen, wie man pnpm-Konflikte löst.

In Teil 3 werden wir uns der viel schwereren Herausforderung stellen: /orchestrate major-upgrade <repo>, bei der der Agent tatsächlich Anwendungscode umschreiben muss, um Breaking Changes zu überstehen.

Bleiben Sie dran und genießen Sie jeden Schritt Ihrer Coding-Reise.