Proyecto: Agente de Coding en Operación Continua, Agente IA Local Refactoriza tu Repositorio Durante la Noche

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

Qué hace este proyecto

Un agente de coding corre cada noche en tu servidor: lee el repositorio, identifica mejoras, escribe refactorizaciones o tests faltantes, crea Pull Requests y tú los revisas por la mañana con tu café. Completamente local, tu código nunca sale de la empresa.

El stack:

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

Requisitos: Servidor con 64+ GB RAM (o MS-S1 Max con 128 GB para los modelos de coding más grandes), Docker, Git-Server local. Aproximadamente 3-4 horas de configuración.

Por qué esta arquitectura

• OpenHands/Aider en lugar de GitHub Copilot: Sin cloud, sin costos de suscripción, el código permanece interno, para empresas con sensibilidad a la propiedad intelectual es el único camino.
• Operación continua: El agente corre como Cron/systemd, cada noche una tarea diferente (Refactoring-Lunes, Test-Martes, Documentación-Miércoles).
• Sandbox obligatorio: El código del agente corre en un contenedor desechable, nunca directamente en el host. Ver Sandboxing.
• Basado en PR: El agente nunca hace push a main, crea ramas y PRs, tú revisas. Human-in-the-Loop por diseño.

Paso 1: Modelo de Coding Local

ollama pull qwen2.5-coder:32b    # mejor modelo local para coding ~20GB
# o deepseek-coder-v2 para más contexto
ollama pull deepseek-coder-v2

Elección de modelo en Comparativa de Modelos de Coding, para operación continua es importante: buen tool-calling, contexto amplio.

Paso 2: Preparar Git-Server + Repositorio

Auto-alojar Gitea (Docker) o usar GitLab existente. Darle al agente un usuario bot propio con permisos de push solo en ramas agent/*:

Reglas del Repo:
- Agent puede hacer push a: agent/**
- Agent NUNCA puede hacer push a: main, develop
- Los PRs requieren revisión humana

Paso 3: El Run del Agente Nocturno

# 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
    # No se necesita puerto persistente, corre headless vía Cron

#!/bin/bash
# nightly-agent.sh, Cron: cada día a las 2:00
TASK=$(cat /opt/agent-tasks/$(date +%A).txt)   # Lunes: "refactor", Martes: "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: crear PR + postear reporte a Mattermost

Rotación de Tareas (agent-tasks/):

• Monday.txt: “Encuentra y refactoriza código duplicado en src/”
• Tuesday.txt: “Escribe Unit-Tests faltantes para utils/”
• Wednesday.txt: “Actualiza Docstrings obsoletos”
• Thursday.txt: “Encuentra bugs potenciales, escribe reporte de hallazgos”

Paso 4: El Reporte Matutino

Después de cada ejecución, el agente publica en Mattermost (Mattermost-Bots):

[BOT] Nightly-Report, Repo: backend
Branch: agent/20260922-nightly | PR: #47
Modificado: 3 archivos | Tests: 12 nuevos, todos en verde
Core: Validación duplicada en validators/ consolidada
Revisión requerida: sí, 1 cambio heurístico en auth.py

Haces clic en el PR, revisas, merges o dejas que la rama caduque. Costo del fracaso: cero.

Paso 5: Seguridad, Lo Que el Agente NO Puede Hacer

• Sin push directo a main: Regla del Git-Server, no solo una petición.
• Sin acceso a Secrets: .env, secrets/ bloqueados por .agentignore, ver Secrets.
• Sin red hacia Internet: Sandbox-Container con --network=none (excepto host de Ollama).
• Límite de presupuesto: Tiempo máximo de ejecución y presupuesto de tokens por noche, sino entra en bucle hasta apagón.
• Audit-Log: Cada acción del agente en un log, ver Audit-Logging.

Extensiones

• Multi-Repo: Un agente, múltiples repos: rotación a lo largo de la semana.
• Issue-Triage: El agente lee issues abiertos, crea fix-branches automáticamente.
• Variante Hermes: Hermes Agent como orquestador, delega tasks de coding a subagentes y reporta vía Telegram.
• Quality-Gate: El agente solo mergea después de pasar pytest + ruff en el run de sandbox.
• Cluster: En dos MS-S1 Max corren dos agentes en paralelo: Repo A y B simultáneamente.

Qué aprendes con esto

• Operación de agentes headless (sin chat, solo tasks)
• Workflows de Git para contributors no humanos
• Diseño de sandbox y permisos
• Dónde son buenos los modelos de coding locales (refactoring, tests, documentación) y dónde todavía flaquean (decisiones arquitectónicas complejas)

Enlaces relacionados

• IRC-Coding.de: Tutoriales de programación, integraciones con agentes, automatización de Git.
• OpenHands: El framework del agente.
• Modelos de Coding: Elección de modelo.
• Agentes de Coding: Resumen conceptual.
• Sandboxing: Seguridad en detalle.
• MS-S1 Max: El hardware para esto.
• Proxmox con OpenHands: Alternativa en Proxmox.

Puntos clave:

• Agente de coding local en operación continua: Ollama + OpenHands/Aider + usuario Git propio + Sandbox.
• Trabajar basado en PR: El agente nunca hace push a main, el humano revisa por la mañana.
• Rotación de tareas nocturnas: Refactoring, tests, documentación, búsqueda de bugs.
• Seguridad: sin acceso a secrets, sin internet, límite de tokens, audit-log.
• Local + operación continua = sin costos de API, código permanece interno, para empresas sensibles a la PI el único camino.

FAQ

Fuentes y lecturas adicionales

• OpenHands: GitHub.
• Aider: GitHub.
• IRC-Coding.de: Tutoriales de programación.

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert