Projekt: Coding-Agent im Dauerbetrieb, lokaler KI-Agent refactoriert Dein Repo über Nacht

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

Was dieses Projekt macht

Ein Coding-Agent läuft nachts auf Deinem Server: Er liest das Repo, findet Verbesserungen, schreibt Refactorings oder fehlende Tests, legt Pull Requests an und Du reviewst morgens über den Kaffee. Komplett lokal, Dein Code verlässt nie die Firma.

Der Stack:

Git-Repo (Gitea/GitLab lokal)
    └── Agent (OpenHands oder Aider + Ollama)
            ├── Coding-Modell: qwen2.5-coder:32b o.ä.
            ├── Sandbox: Docker-Container pro Run
            └── Ergebnis: Branch + PR + Report an Mattermost

Voraussetzungen: Server mit 64+ GB RAM (oder MS-S1 Max mit 128 GB für die großen Coding-Modelle), Docker, lokaler Git-Server. ~3-4 Stunden Setup.

Warum dieser Aufbau

• OpenHands/Aider statt GitHub Copilot: Keine Cloud, keine Abo-Kosten, Code bleibt intern, für Firmen mit IP-Sensibilität der einzige Weg.
• Dauerbetrieb: Der Agent läuft als Cron/systemd, jede Nacht eine andere Aufgabe (Refactoring-Montag, Test-Dienstag, Doku-Mittwoch).
• Sandbox-Pflicht: Agent-Code läuft in einem wegwerfbaren Container, niemals direkt auf dem Host. Siehe Sandboxing.
• PR-basiert: Der Agent pusht nie nach main, er erstellt Branches + PRs, Du reviewst. Human-in-the-Loop per Design.

Schritt 1: Lokales Coding-Modell

ollama pull qwen2.5-coder:32b    # bestes lokales Coding-Modell ~20GB
# oder deepseek-coder-v2 für mehr Kontext
ollama pull deepseek-coder-v2

Modellwahl siehe Coding-Modelle-Vergleich, für Dauerbetrieb wichtig: gutes Tool-Calling, großer Kontext.

Schritt 2: Git-Server + Repo vorbereiten

Gitea self-hosten (Docker) oder bestehendes GitLab nutzen. Dem Agent einen eigenen Bot-User geben mit Push-Recht nur auf agent/*-Branches:

Repo-Regeln:
- Agent darf pushen auf: agent/**
- Agent darf NICHT pushen auf: main, develop
- PRs brauchen menschliches Review

Schritt 3: Der nächtliche Agent-Run

# docker-compose.yml — Agent-Service
services:
  coding-agent:
    image: docker.all-hands.dev/all-hands-ai/openhands:latest
    environment:
      - LLM_MODEL=ollama/qwen2.5-coder:32b
      - LLM_BASE_URL=http://host.docker.internal:11434
      - SANDBOX_RUNTIME_CONTAINER_IMAGE=nikolaik/python-nodejs:python3.12-nodejs22
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./workspace:/opt/workspace_base
    # Kein dauerhafter Port nötig — läuft headless via Cron

#!/bin/bash
# nightly-agent.sh — Cron: jeden Tag 2 Uhr
TASK=$(cat /opt/agent-tasks/$(date +%A).txt)   # Montag: "refactor", Dienstag: "tests"...

cd /opt/workspace_base/myrepo
git checkout main && git pull

docker run --rm coding-agent \
    --task "$TASK" \
    --headless

git checkout -b "agent/$(date +%Y%m%d)-nightly"
git push origin "agent/$(date +%Y%m%d)-nightly"
# Gitea-API: PR anlegen + Report an Mattermost posten

Aufgaben-Rotation (agent-tasks/):

• Montag.txt: „Finde und refactore duplizierten Code in src/”
• Dienstag.txt: „Schreibe fehlende Unit-Tests für utils/”
• Mittwoch.txt: „Aktualisiere veraltete Docstrings”
• Donnerstag.txt: „Finde potenzielle Bugs, schreibe Findings-Report”

Schritt 4: Der morgendliche Report

Nach jedem Run postet der Agent an Mattermost (Mattermost-Bots):

🤖 Nightly-Report — Repo: backend
Branch: agent/20260922-nightly | PR: #47
Geändert: 3 Dateien | Tests: 12 neu, alle grün
Kern: Duplizierte Validierung in validators/ zusammengeführt
Review nötig: ja — 1 heuristische Änderung in auth.py

Du klickst den PR, reviewst, mergest oder lässt den Branch verfallen. Kosten des Misserfolgs: null.

Schritt 5: Sicherheit, was der Agent NICHT darf

• Kein direkter Push auf main: Git-Server-Regel, nicht nur Bitte.
• Kein Secrets-Zugriff: .env, secrets/ per .agentignore blocken; siehe Secrets.
• Kein Netz ins Internet: Sandbox-Container mit --network=none (außer Ollama-Host).
• Budget-Limit: Max. Laufzeit + Token-Budget pro Nacht, sonst looped er bis zum Stromausfall.
• Audit-Log: Jede Agent-Aktion in ein Log, siehe Audit-Logging.

Erweiterungen

• Multi-Repo: Ein Agent, mehrere Repos: Rotation über die Woche.
• Issue-Triage: Agent liest offene Issues, erstellt Fix-Branches automatisch.
• Hermes-Variante: Hermes Agent als Orchestrierer, er delegiert Coding-Tasks an Subagenten und reported per Telegram.
• Qualitäts-Gate: Agent merged erst nach bestandenem pytest + ruff im Sandbox-Run.
• Cluster: Auf zwei MS-S1 Max laufen zwei Agents parallel: Repo A und B gleichzeitig.

Was Du dabei lernst

• Headless-Agent-Betrieb (kein Chat, nur Tasks)
• Git-Workflows für nicht-menschliche Contributor
• Sandbox- und Berechtigungs-Design
• Wo lokale Coding-Modelle gut sind (Refactoring, Tests, Doku) und wo sie noch schwächeln (komplexe Architektur-Entscheidungen)

Weiterführende Links

• IRC-Coding.de: Programmier-Tutorials: Agent-Integrationen, Git-Automation.
• OpenHands: Das Agent-Framework.
• Coding-Modelle: Modellwahl.
• Coding-Agenten: Konzept-Übersicht.
• Sandboxing: Sicherheit im Detail.
• MS-S1 Max: Die Hardware dafür.
• Proxmox mit OpenHands: Alternative auf Proxmox.

Key Takeaways:

• Lokaler Coding-Agent im Dauerbetrieb: Ollama + OpenHands/Aider + eigener Git-User + Sandbox.
• PR-basiert arbeiten: Agent pushed nie auf main, Mensch reviewt morgens.
• Nightly-Aufgaben-Rotation: Refactoring, Tests, Doku, Bug-Hunt.
• Sicherheit: kein Secrets-Zugriff, kein Internet, Token-Budget, Audit-Log.
• Lokal + Dauerbetrieb = keine API-Kosten, Code bleibt intern, für IP-sensible Firmen der einzige Weg.

FAQ

Quellen und weiterführende Literatur

• OpenHands: GitHub.
• Aider: GitHub.
• IRC-Coding.de: Programmier-Tutorials.

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert