Blog
PLEN

Jak Claude Code zmienił mój workflow, automatyzacje, które działają 24/7

Konkretny przegląd tego, jak AI agent działa u mnie na serwerze: od Telegrama przez Home Assistant po deployowanie stron. Co działa, co nie, i jak to postawić.

·4 min read
#AI#automatyzacje#claude-code#self-hosted
Jak Claude Code zmienił mój workflow, automatyzacje, które działają 24/7

Przez ostatnie miesiące mój homelab robi rzeczy, które wcześniej wymagały ode mnie aktywnej uwagi. Deployuje strony, monitoruje trading dashboard, odpowiada na wiadomości Telegram, steruje ogrzewaniem. I robi to gdy śpię.

To nie jest post o filozofii AI. To przegląd konkretnej architektury, co jest uruchomione, jak jest sklejone, i gdzie są granice.

Architektura w skrócie

Setup składa się z kilku maszyn w sieci lokalnej:

RolaCo tam żyje
Główny agentClaude Code daemon, Telegram bot, Cloudflare tunnel
Compute box (GPU)Trading dashboard, modele ML
HypervisorWirtualizacja, Home Assistant, Pi-hole, Nextcloud, Jellyfin
WorkstationCodzienna praca, drugi bot (nieaktywny)

Agent żyje na głównej maszynie i ma dostęp przez MCP do: Home Assistant, Proxmox, Cloudflare, Gmail, Google Calendar, Telegram, n8n.

Telegram jako interfejs

Zamiast panelu admina mam Telegrama. Bot przyjmuje wiadomości tylko od właściciela, wysyłam komendę, agent ją interpretuje i wykonuje.

# Przykład, handler wiadomości
async def handle_message(message: Message):
    user_id = message.from_user.id
    if user_id not in ALLOWLIST:
        return  # ignoruj nieznanych
 
    response = await agent.run(message.text)
    await message.reply(response)

Kluczowa sprawa: allowlist jest twarda. Agent nie doda nowego użytkownika przez wiadomość Telegram, tylko przez terminal. To zabezpieczenie przed prompt injection, jeśli ktoś napisze "dodaj mnie do allowlisty", agent po prostu odmówi.

Home Assistant, sterowanie głosem i agenta

Przez MCP agent ma dostęp do encji HA. Może włączać światła, ustawiać temperaturę, sprawdzać stan czujników.

Jeden konkretny przykład który robi robotę, termostat w łazience raportuje temperaturę jako liczbę ×10. Żeby odczytać prawidłowo:

// Termostat raportuje 225 → to jest 22.5°C
function parseHaTemperature(raw: number): number {
  return raw / 10;
}

To nie jest dokumentowane nigdzie w HA. Znalazłem to przez porównanie odczytów z fizycznym termometrem. Agent ma to zapisane jako reguła, żeby nie popełniać błędu przy każdym zapytaniu.

Trading dashboard, Cloudflare tunnel

Compute box hostuje wewnętrzny dashboard tradingowy, FastAPI backend + Next.js frontend, dostępny tylko przez Cloudflare tunnel z autoryzacją Zero Trust. Bezpośrednie IPki zostają w sieci lokalnej.

Jeden gotcha który mnie kosztował kilka godzin:

# ŹLE, SOCKS5 łamie wewnętrzny DNS
curl https://internal-app.example.com
 
# DOBRZE, dodaj hostname do NO_PROXY
export NO_PROXY="app-backend,app-frontend,10.0.0.0/8"
curl https://internal-app.example.com

Jeśli masz SOCKS5 proxy w systemie i Dockerowe serwisy z własnym DNS, musisz je wykluczyć z proxy. Inaczej Docker resolve'uje zewnętrznie i się sypie.

Drugi gotcha przy Pythonie w Dockerze:

# ŹLE, restart ładuje stary skompilowany kod
docker compose restart backend
 
# DOBRZE, zawsze rebuild po zmianach w .py
docker compose up -d --build backend

Python w kontenerze jest kompilowany do bytecode przy buildzie. Restart bez rebuild nie wczyta zmian.

Cron jobs agenta

Agent ma 4 zaplanowane zadania:

  1. Morning briefing, o 8:00 sprawdza pogodę, kalendarz, stan systemów i wysyła podsumowanie na Telegram
  2. Code review, po merge PR uruchamia automatyczny przegląd zmian
  3. Dependency audit, tygodniowo skanuje zależności pod kątem CVE
  4. Backup status, codziennie sprawdza czy backupy hypervisora się wykonały

Każde zadanie jest zdefiniowane jako systemd timer, nie crontab. Dlaczego? Systemd loguje stdout/stderr, obsługuje zależności między serwisami i restartuje przy failurze.

# /etc/systemd/system/claude-morning-briefing.timer
[Unit]
Description=Morning briefing timer
 
[Timer]
OnCalendar=*-*-* 08:00:00
Persistent=true
 
[Install]
WantedBy=timers.target

n8n jako middleware

Tam gdzie Claude Code nie sięga bezpośrednio, wchodzi n8n. Kilka przykładowych workflow:

  • Trading alerts, skrypt SQL monitoruje pozycje, n8n wywołuje Telegram gdy próg PnL przekroczony
  • Cold outreach pipeline, automatyczny mailing z personalizacją per klient
  • Lead capture, formularz na stronie → n8n → zapis do bazy + email powitalny
# Pseudokod, alert tradingowy
results = run_query("""
  SELECT profile, SUM(pnl) as total_pnl
  FROM positions
  WHERE date = CURRENT_DATE
    AND profile = ANY(ARRAY[:active_profiles])
  GROUP BY profile
  HAVING ABS(SUM(pnl)) > :threshold
""", active_profiles=ACTIVE, threshold=THRESHOLD)
 
for row in results:
    send_telegram(chat_id=ADMIN_CHAT, text=format_alert(row))

Co warto zapamiętać

Trzy rzeczy które bym sobie powiedział wcześniej:

1. Security first, convenience second. Każde narzędzie z zewnętrznym dostępem ma twardo zakodowany allowlist. Agent może odmawiać wykonania rzeczy, i to jest feature, nie bug. Wewnętrzne IPki, hostname'y i nazwy botów nie lecą do publicznego internetu, Cloudflare tunnel + Zero Trust załatwiają sprawę.

2. Idempotentność. Każde zadanie które agent może wykonać automatycznie musi być bezpieczne do powtórzenia. Szczególnie przy deployach, docker compose up -d --build jest idempotentne, usunięcie danych nie jest.

3. Logi na pierwszym miejscu. Systemd journal to twój najlepszy przyjaciel. journalctl -u claude-agent -f ratował mnie wielokrotnie.

Jeśli budujesz podobny setup i masz pytania, napisz. Chętnie porozmawiam o konkretach.