Telegram-Bot mit Claude API: KI-Assistent selbst bauen

Ich habe einen Telegram-Bot an Claude Opus 4.7 angebunden, mit dem ich von überall aus spreche. Zug, Couch, Café, Bett. Er liest meine TickTick-Tasks, schreibt Code gegen meine Repos, führt Shell-Kommandos auf meiner VPS aus und schickt mir um 06:30 Uhr Madrider Zeit ein Morning Briefing. Das Ganze ist ein Bash-Skript und eine systemd-Unit. Kein Frontend. Keine Hosting-Rechnung. Keine Auth-Seiten zu bauen.

Dieser Leitfaden zeigt genau, wie man so etwas baut. Zwei Architekturen (Bash-Long-Polling und ein TypeScript-Webhook-Server), vollständiger lauffähiger Code, Attachment-Handling, MCP-Tool-Integration — und die Security-Schritte, die die meisten Tutorials auslassen. Der Stack ist eine Telegram-Bot-zu-Claude-API-Verdrahtung, die auf jedem Linux-Rechner mit ein paar hundert Megabyte RAM läuft.

Wenn Sie einen KI-Assistenten in der Hosentasche wollen, ist das der kürzeste Weg.

Warum Telegram als KI-Interface

Bevor ich bei Telegram landete, habe ich eine React-Chat-UI, eine Slack-App und einen Discord-Bot ausprobiert. Alle drei haben Wochenenden gekostet. Telegram gewinnt aus einem konkreten Grund: das Interface-Problem ist bereits gelöst.

• Ein Client, jede Oberfläche. Nativ Mobile, nativ Desktop (macOS, Windows, Linux), plus Web-Client. Derselbe Bot erreicht alle ohne Extra-Code.
• Push-Notifications sind kostenlos und zuverlässig. Keine APNs-Zertifikate, kein FCM-Setup, keine “Notifications funktionieren meistens auf Android”-Einschränkungen.
• Die Bot-API ist stabil und kostenlos. Keine Rate-Karte, kein Enterprise-Tier-Gate, keine Deprecation-Tretmühle. Ich habe Bots, die drei Jahre lang unangetastet liefen.
• Keine Auth-Flows. Die Chat-ID ist die Identität. Eigene ID auf Allowlist — fertig.
• Attachments nativ. Fotos, PDFs, Sprachnachrichten, Dokumente. Alles über denselben getUpdates-Endpoint.

Der Tradeoff: Telegram ist kein compliance-fähiger Kanal für regulierte Daten. Patientenakten oder Kunden-PII gehören nicht durch einen persönlichen Bot. Für persönliche Assistenten, interne Team-Tools, Ops-Alerting und Content-Workflows ist es der schnellste Weg zu einem lauffähigen Telegram-KI-Bot.

Zwei Architekturen — wählen Sie, was passt

Es gibt zwei Wege, einen Telegram-Bot mit Claude zu bauen. Nach Use Case entscheiden, nicht danach, was “professioneller” wirkt.

Long-Polling-Bash-Daemon. Ein Prozess, läuft auf der VPS, ruft getUpdates in einer Schleife auf, pipet jede Nachricht durch claude -p, schickt die Antwort. Perfekt für persönliche Bots, interne Team-Tools (bis etwa 20 User), Ops-Bots. Das ist, was ich betreibe.

Webhook-Server. Telegram POSTet jede Nachricht an Ihren HTTPS-Endpoint. Sie brauchen eine öffentliche Domain, TLS und einen Prozess, der parallele Requests verarbeitet. Skaliert auf tausende User, übersteht Bot-Restarts ohne Nachrichtenverlust und funktioniert gut mit Serverless.

Grobe Entscheidungsmatrix:

Wenn Sie das hier lesen, um Ihre erste Claude-Telegram-Integration für sich selbst zu bauen: Long-Polling. Migration auf Webhooks geht später, falls User dazukommen. Beide Varianten stehen unten.

Setup: Bot-Token, Chat-ID, Berechtigungen

Dieser Teil ist stack-unabhängig.

Bot anlegen. In Telegram @BotFather suchen, /newbot senden, Name und Username (endet auf bot) wählen. BotFather gibt einen Token zurück wie 7234567890:AAH.... Wie ein Passwort behandeln.

Privacy-Modus deaktivieren, wenn der Bot in Gruppen alle Nachrichten lesen soll (optional, über /setprivacy). Für den Eigengebrauch nicht nötig.

Token sichern. Ich lege meinen in /home/user/.config/telegram-bot.env ab:

TELEGRAM_BOT_TOKEN=7234567890:AAH...
TELEGRAM_ALLOWED_CHAT_ID=123456789
ANTHROPIC_API_KEY=sk-ant-...

Dann chmod 600 /home/user/.config/telegram-bot.env. Die Allowlist-Env-Variable ist nicht verhandelbar — warum, erkläre ich im Security-Abschnitt.

Chat-ID auslesen. Eine beliebige Nachricht an den Bot schicken, dann:

source /home/user/.config/telegram-bot.env
curl -s "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/getUpdates" | jq '.result[0].message.chat.id'

Die zurückgegebene Zahl ist Ihre TELEGRAM_ALLOWED_CHAT_ID. Notieren. Ohne Allowlist kann jeder, der Ihren Bot-Username findet, API-Kosten auf Ihrem Account hochtreiben.

Bash-Version: 30 Zeilen zu einem lauffähigen Bot

Das ist das Pattern, das ich tatsächlich betreibe. Long-Poll zu Telegram, Nachrichten über claude -p (damit bekomme ich den gesamten Claude-Code-Tool-Stack gratis) und Antworten zurück. Wenn die Claude-Code-CLI auf der VPS installiert ist, sind Sie zehn Minuten von einem lauffähigen KI-Telegram-Bot entfernt.

#!/usr/bin/env bash
set -euo pipefail

source /home/user/.config/telegram-bot.env
API="https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}"
OFFSET=0

send() {
  local chat="$1" text="$2"
  # Telegram caps sendMessage at 4096 chars. Split long replies.
  while [ -n "$text" ]; do
    local chunk="${text:0:4000}"
    text="${text:4000}"
    curl -s -X POST "${API}/sendMessage" \
      --data-urlencode "chat_id=${chat}" \
      --data-urlencode "text=${chunk}" >/dev/null
  done
}

handle_message() {
  local chat="$1" user_text="$2"
  if [ "$chat" != "$TELEGRAM_ALLOWED_CHAT_ID" ]; then
    echo "$(date -Iseconds) rejected chat $chat" >&2
    return
  fi
  # claude -p runs in print mode with the full Claude Code tool stack.
  # Keep CWD consistent so MCP config is picked up.
  local reply
  reply=$(cd /home/user/claude && \
    env -u CLAUDECODE -u CLAUDE_CODE_ENTRYPOINT \
    claude -p --model sonnet --permission-mode ask \
    --max-budget-usd 1 "$user_text" 2>&1) || reply="error: $reply"
  send "$chat" "$reply"
}

while true; do
  UPDATES=$(curl -s "${API}/getUpdates?offset=${OFFSET}&timeout=30")
  echo "$UPDATES" | jq -c '.result[]?' | while read -r upd; do
    OFFSET=$(($(echo "$upd" | jq '.update_id') + 1))
    CHAT=$(echo "$upd" | jq '.message.chat.id')
    TEXT=$(echo "$upd" | jq -r '.message.text // empty')
    [ -n "$TEXT" ] && handle_message "$CHAT" "$TEXT"
    echo "$OFFSET" > /tmp/telegram-bot.offset
  done
  OFFSET=$(cat /tmp/telegram-bot.offset 2>/dev/null || echo 0)
done

Ein paar Dinge hervorzuheben. Die innere while read-Schleife läuft in einer Subshell, also überlebt OFFSET nicht — deshalb der Umweg über /tmp/telegram-bot.offset. claude -p im Print-Modus erbt Ihre MCP-Konfiguration: wenn Sie einen TickTick-MCP-Server angeschlossen haben, kann der Bot automatisch Tasks verwalten. --max-budget-usd 1 deckelt Kosten pro Turn; für schwerere Agent-Arbeit höher setzen. --permission-mode ask ist ein Sicherheitsnetz für Shell-ausführende Tools (mehr im Security-Abschnitt).

Ein Hinweis zum Parse-Modus. Wenn Sie parse_mode=MarkdownV2 setzen, besteht Telegram darauf, jedes Sonderzeichen zu escapen: _*[]()~\>#+-=|{}.!. Eines verpasst — die komplette Nachricht wirft 400. Ich schicke nur Plain Text. Wer Formatierung braucht, nimmt parse_mode=HTMLund escaped drei Zeichen statt vierzehn:sed ’s/&/&amp;/g; s/</&lt;/g; s/>/&gt;/g’`.

Das 4096-Zeichen-Limit ist real. Meine send-Funktion stückelt bei 4000, um Luft zu haben. Für gigantische Outputs (Logs, lange Analysen) lieber per sendDocument eine Datei hochladen statt Text zu splitten. 4000 statt der harten 4096, damit Emoji und breites Unicode (mehrere Bytes) Spielraum haben.

Zum Thema Claude Code nicht-interaktiv mit vollem Tool-Zugriff siehe meinen Claude-Code-SDK-Agenten-Leitfaden.

TypeScript-Version: mehr Kontrolle

Wenn Sie Streaming-Antworten, feinkörnige Fehlerbehandlung oder echte Parallelität brauchen, wechseln Sie zu TypeScript. Ich nutze grammy für Telegram und @anthropic-ai/sdk direkt für Claude.

npm init -y
npm install grammy @anthropic-ai/sdk dotenv

import "dotenv/config";
import { Bot } from "grammy";
import Anthropic from "@anthropic-ai/sdk";

const ALLOWED = new Set(
  (process.env.TELEGRAM_ALLOWED_CHAT_IDS ?? "").split(",").map(Number)
);

const bot = new Bot(process.env.TELEGRAM_BOT_TOKEN!);
const claude = new Anthropic();

bot.on("message:text", async (ctx) => {
  if (!ALLOWED.has(ctx.chat.id)) return;

  // Send a placeholder so the user sees activity while Claude thinks.
  const placeholder = await ctx.reply("...");
  let buffer = "";
  let lastEdit = Date.now();

  const stream = claude.messages.stream({
    model: "claude-sonnet-4-6",
    max_tokens: 4000,
    system: [
      {
        type: "text",
        text: "You are a concise assistant replying inside Telegram. Plain text, no markdown.",
        cache_control: { type: "ephemeral" },
      },
    ],
    messages: [{ role: "user", content: ctx.message.text }],
  });

  for await (const chunk of stream) {
    if (chunk.type === "content_block_delta" && chunk.delta.type === "text_delta") {
      buffer += chunk.delta.text;
      // Edit every 800ms so we don't hit Telegram's edit rate limit.
      if (Date.now() - lastEdit > 800 && buffer.length > 20) {
        await ctx.api.editMessageText(
          ctx.chat.id,
          placeholder.message_id,
          buffer.slice(0, 4000)
        );
        lastEdit = Date.now();
      }
    }
  }
  // Final flush. Send a NEW message for notifications, or keep edit for silent updates.
  await ctx.api.editMessageText(
    ctx.chat.id,
    placeholder.message_id,
    buffer.slice(0, 4000)
  );
});

bot.catch((err) => console.error("bot error", err));
bot.start();

Das Streaming-Edit-Pattern ist das Killer-Feature. User sehen Wörter in Echtzeit erscheinen, was den Bot schnell wirken lässt, auch wenn Claude fünfzehn Sekunden für eine lange Antwort braucht. Zwei Feinheiten: Telegram rate-limited editMessageText auf etwa einen Edit pro Sekunde pro Nachricht — daher der Throttle. Und Edits lösen keine Push-Notifications aus, was für Streaming top ist, für fertiggestellte Langläufer aber schlecht. Bei Abschluss eine NEUE Nachricht senden, damit das Handy klingelt.

Prompt Caching ist hier kostenloses Extra. Wenn Ihr System-Prompt mehr als ein paar hundert Tokens hat (Persona, Anweisungen, Tool-Liste), senkt cache_control: ephemeral Kosten und Latenz bei jedem Follow-up innerhalb von fünf Minuten.

Attachments verarbeiten

Text-only-Bots werden schnell langweilig. Telegram liefert Fotos und Dokumente als file_id-Referenzen — in zwei Hops abholen.

bot.on("message:photo", async (ctx) => {
  if (!ALLOWED.has(ctx.chat.id)) return;
  const photo = ctx.message.photo.at(-1)!; // largest size
  const file = await ctx.api.getFile(photo.file_id);
  const url = `https://api.telegram.org/file/bot${process.env.TELEGRAM_BOT_TOKEN}/${file.file_path}`;
  const bytes = Buffer.from(await (await fetch(url)).arrayBuffer());

  const response = await claude.messages.create({
    model: "claude-sonnet-4-6",
    max_tokens: 1000,
    messages: [
      {
        role: "user",
        content: [
          {
            type: "image",
            source: {
              type: "base64",
              media_type: "image/jpeg",
              data: bytes.toString("base64"),
            },
          },
          { type: "text", text: ctx.message.caption ?? "What is in this image?" },
        ],
      },
    ],
  });
  const text = response.content.find((b) => b.type === "text")?.text ?? "";
  await ctx.reply(text.slice(0, 4000));
});

PDFs folgen derselben Form. message:document nutzen und die Bytes als document-Content-Block senden (Claude unterstützt PDF-Input bis 32 MB). Für Sprachnachrichten läuft die Datei zuerst durch einen Transkriptionsschritt (Whisper, Deepgram, AssemblyAI), dann wird das Transkript als Text übergeben.

Ein Fallstrick: Telegram speichert Dateien ein Jahr, aber file_path läuft nach einer Stunde ab. Sofort verarbeiten oder im eigenen Storage sichern. Für strukturierten Vision-Output (Positionslisten, Belege, Schemata) das Ganze mit dem Tool-Use-Pattern aus meinem Claude-API-Structured-Output-Artikel kombinieren.

MCP-Tools über claude -p einbinden

Hier hört ein Telegram-KI-Bot auf, ein Chatbot zu sein — und wird zum Assistenten.

claude -p erbt MCP-Server aus ~/.claude.json (oder der per --mcp-config übergebenen Konfiguration). Wenn ich “was steht heute an” an meinen Bot schicke, geht die Nachricht durch claude -p, der Zugriff auf meinen TickTick-MCP-Server hat, der die Live-TickTick-API abfragt. Der Bot antwortet mit meiner echten Task-Liste, priorisiert, überfällige markiert. Kein Scraping. Keine hartkodierten API-Calls im Bot selbst.

Die Architektur sieht so aus:

Telegram > Bot-Daemon > claude -p > MCP-Server > externe API
                                  > Filesystem-Tools
                                  > Bash-Tool

Einen eigenen MCP-Server zu verdrahten sprengt diesen Artikel, aber ich habe einen vollständigen Walkthrough unter MCP-Server in TypeScript bauen geschrieben. Sobald der MCP-Server registriert ist, nimmt der Bot ihn ohne Code-Änderung auf. Genau das ist der Punkt. Fähigkeiten werden durch Tools im Shared-Config erweitert, nicht durch Umschreiben des Bots.

Eine Beispiel-MCP-Verdrahtung in ~/.claude.json:

{
  "mcpServers": {
    "ticktick": {
      "command": "node",
      "args": ["/home/user/ticktick-mcp/ticktick-mcp-server.js"]
    }
  }
}

Bot neu starten, “verschiebe meinen Haarschnitt-Task auf Samstag” senden — Claude wählt das richtige MCP-Tool und ruft es auf. Dasselbe Pattern wie in Ich betreibe 10 KI-Agenten in Production, alle sind Bash-Skripte. Langweiliger Stack, fetter Payoff.

Multi-Turn-Memory ohne Token-Verbrennung

Out of the box ist jede Nachricht an den Bash-Bot ein frischer Kontext. Das ist für 80 % der Anfragen in Ordnung. Für echte Konversationen gibt es drei Optionen.

Stateless, pro Nachricht. Die Default-Variante. Am günstigsten, am einfachsten, keine Bug-Regressionen. Gut für Task-Execution-Bots, bei denen jede Anfrage für sich steht (“add buy milk to tomorrow”, “what’s the weather”).

Per-Chat-Historie in SQLite. Ein rollendes Fenster der letzten N Nachrichten pro chat_id. Vor jeden Claude-Call prependen. Zehn Zeilen Code:

import Database from "better-sqlite3";
const db = new Database("chat.db");
db.exec(`CREATE TABLE IF NOT EXISTS msgs (
  chat_id INTEGER, role TEXT, content TEXT, ts INTEGER
)`);

function history(chatId: number, limit = 10) {
  return db
    .prepare("SELECT role, content FROM msgs WHERE chat_id = ? ORDER BY ts DESC LIMIT ?")
    .all(chatId, limit)
    .reverse();
}

Prompt Caching mit Long Context. Für Agent-Workflows, bei denen derselbe große System-Prompt und Tool-Definitionen jeden Turn treffen: cache_control: ephemeral am System-Block. Follow-ups innerhalb eines 5-Minuten-Fensters lesen gecachte Tokens zu einem Bruchteil der Input-Kosten. Ich kombiniere das mit einem kurzen SQLite-Fenster für User-spezifische Turns. Best of both.

Faustregel: Bauen Sie einen Ops-Bot oder Task-Runner? Stateless. Bauen Sie etwas, mit dem Leute echte Konversationen führen? SQLite plus Prompt Caching.

Security — der Teil, den alle überspringen

Die meisten “Build a Telegram Bot”-Tutorials springen direkt von /newbot zu sendMessage und lassen den Bot offen wie ein Scheunentor. Nicht machen. Fünf Regeln.

Chat-IDs immer per Allowlist einschränken. Die wichtigste Zeile im Bash-Skript ist der frühe Return, wenn chat != TELEGRAM_ALLOWED_CHAT_ID. Telegram-Bot-Usernames sind auffindbar. Ohne Allowlist finden Fremde Ihren Bot, spammen ihn zu, und jede Nachricht ist ein API-Call, den Sie bezahlen.

Sich selbst rate-limiten. Ich habe versehentlich Schleifen geschrieben, die ihren eigenen Output zurück in den Bot echoen und binnen Minuten Dollar-hohe Claude-Rechnungen produziert. Eingehende Nachrichten auf etwa fünf pro Minute pro Chat deckeln. Ein Counter im Speicher reicht.

Budget-Cap pro Call. --max-budget-usd auf claude -p verwenden. Falls ein Prompt versehentlich eine Tool-Loop auslöst, bricht der Call ab, statt das Guthaben wegzumahlen.

Alles ein und aus loggen. Jede eingehende Nachricht und jede ausgehende Antwort mit Zeitstempel in eine lokale Datei anhängen. Wenn um 2 Uhr morgens etwas schiefgeht, brauchen Sie ein Transkript. journalctl reicht, eine Plain-Log-Datei reicht — irgendwas muss her.

Nachrichtentext nie als Shell-Input vertrauen. Wenn Ihr Bot Shell-Kommandos im Auftrag des Users ausführt: --permission-mode ask nutzen (Default ist plan), gegen eine Kommando-Allowlist vorvalidieren oder den Bot in einem Container mit Read-only-FS laufen lassen. Jede eingehende Nachricht als feindlich behandeln — auch wenn “das ja nur ich bin”. Ihr Handy könnte kompromittiert sein. Der Bot darf kein rm -rf / können.

Mehr zum Tool-Use-Berechtigungsmodell im Claude-API-Tool-Use-Leitfaden.

Betrieb als systemd-Service

Long-Polling-Daemons müssen bei Crash neu starten, mit dem Server booten und Logs irgendwohin schreiben, wo man sie lesen kann. systemd erledigt alle drei.

# /etc/systemd/system/telegram-bot.service
[Unit]
Description=Telegram Claude Bot
After=network-online.target

[Service]
Type=simple
User=debian
WorkingDirectory=/home/user/claude
EnvironmentFile=/home/user/.config/telegram-bot.env
ExecStart=/home/user/bin/telegram-bot.sh
Restart=on-failure
RestartSec=5s
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Installieren:

sudo systemctl daemon-reload
sudo systemctl enable --now telegram-bot
sudo journalctl -u telegram-bot -f

Fertig. Der Bot startet beim Booten, fährt fünf Sekunden nach jedem Crash wieder hoch und loggt nach journalctl. Für einen Health-Check reicht ein Cron, der systemctl is-active telegram-bot grept und bei inactive alarmiert — fünf Zeilen. Das komplette systemd-Pattern für KI-Services steht in KI-Services mit systemd betreiben.

Häufige Fehler

Was bei mir kaputtgegangen ist, in absteigender Häufigkeit.

Bot hängt an einer einzelnen Anfrage. Ein Claude-Call mit riesiger Tool-Loop kann den Daemon minutenlang blockieren. Timeout davor: timeout 120 claude -p .... Ein Prozess, der mit 124 endet, ist besser als ein stiller Hang.

Telegram liefert 429 Too Many Requests. Den retry_after-Wert im JSON-Response respektieren und schlafen. Für Streaming-Edits ist das Limit grob ein Edit pro Sekunde pro Nachricht. Backoff, nicht hämmern.

Updates gehen bei Restart verloren. Ohne Offset-Persistenz verarbeitet der Bot entweder alte Nachrichten doppelt oder überspringt neue. Das Bash-Skript oben schreibt OFFSET bei jedem Update nach /tmp/telegram-bot.offset und liest es beim Loop-Resume.

sendMessage liefert 400 auf die Antwort. Fast immer ein Parse-Mode-Escaping-Bug. Parse-Mode weglassen oder auf HTML wechseln und drei Zeichen statt vierzehn escapen.

Edit-Nachricht vs. Neue-Nachricht-Verwirrung. Edits benachrichtigen nicht. Wenn ein langer Claude-Lauf fertig wird und Sie den Platzhalter editieren, bleibt das User-Handy still. Für alles über zehn Sekunden Arbeit: bei Abschluss eine neue Nachricht für die finale Antwort.

Claude-Call liefert leeren Text zurück. Fast immer ein Tool-Use-Response, den Ihr Code nicht behandelt. Die content-Blocks iterieren und Text-Blocks konkatenieren; Tool-Blocks müssen ausgeführt und deren Ergebnisse zurückgegeben werden.

MCP-Server wird nicht geladen. claude -p lädt MCP-Konfiguration aus der .claude.json des Working Directory zuerst. Wenn der Bot aus /home/debian läuft, aber Ihr Config in /home/user/claude liegt, werden die Server nicht geladen. WorkingDirectory= in der systemd-Unit setzen.

Reale Patterns, die ich wirklich nutze

Konkrete Claude-Telegram-Integrations-Patterns, die gerade live auf meiner VPS laufen.

KI-Assistent in der Hosentasche. Beliebige Frage senden. Der Bot hat über MCP-Tools Zugriff auf meine Repos, meine Task-Liste und das offene Web. “Fasse die neuesten Issues im Graffiti-Repo zusammen” funktioniert. Ebenso “welche Meetings habe ich morgen und welche kann ich absagen”.

Morning Briefing um 06:30 Madrider Zeit. Ein Cron fährt telegram-notify.sh mit heutigen Tasks, überfälligen Punkten, Wetter und einer Ein-Absatz-Zusammenfassung von Claude. Liegt auf dem Handy, bevor ich es in die Hand nehme.

Task-Inbox. Ich leite Upwork-E-Mail-Alerts an den Bot weiter. Er klassifiziert den Job, entwirft ein Anschreiben und speichert es als Subtask unter dem Upwork-Ticket in TickTick. Null manuelles Copy-Paste.

Code-Frage unterwegs. Im Zug schicke ich “behandelt der ralph-Loop leere Task-Listen korrekt”. Der Bot startet claude -p mit File-Tools, liest die relevanten Dateien, liefert die Antwort — manchmal mit einem Diff.

Pipeline-Status. Meine wöchentliche Content-Pipeline postet eine Zusammenfassung an den Bot, wenn sie fertig ist. Erfolg oder Fehler, mit Log-Links. Kein SSH mehr zum Nachsehen.

Keines davon ist eine App-Store-App. Keines hat ein Frontend. Alle laufen in ein paar hundert Zeilen Bash und TypeScript auf derselben 10-Euro-VPS. Genau das ist der Sinn eines Telegram-Bots mit Claude. Geringer Aufwand, hoher Nutzen, ein Client, der mich überall erreicht.

Sobald eines dieser Patterns Team-Nutzung bekommt, migriere ich es auf die Webhook-Architektur und ergänze eine richtige Auth-Schicht. Bis dahin ist Long-Polling-Bash für 95 % der persönlichen KI-Tools die richtige Antwort.

Weiterführendes

• Claude-Code-SDK-Agenten: Print-Modus und Tool-Inheritance
• MCP-Server in TypeScript bauen
• KI-Services mit systemd betreiben