|
6 Min. Lesezeit
|

Agenten sind keine Menschen

Zusammenfassung

Agenten kennen PostgreSQL, CDP, bash und Hunderte von Protokollen bereits. Geben Sie ihnen direkten Zugang — psql, Shell, HTTP-Proxy — anstatt kuratierte Tool-Sets zu erstellen. Skills mit CLI schlagen MCP. Und die nächste Stufe: Geben Sie Agenten eine Runtime und ein SDK — lassen Sie sie Code schreiben, nicht nur Tools aufrufen.

Diesen Artikel zusammenfassen mit:
ChatGPTPerplexityClaudeGrok

Die Abstraktionsfalle

Wenn wir Tools für KI-Agenten entwickeln, tun wir instinktiv das, was wir auch für menschliche Entwickler tun würden: vereinfachen. Wir erstellen High-Level-APIs, hübsche Wrapper, kuratierte Listen. Ein Datenbank-MCP-Tool, das eine Liste von Tabellen und Indizes zurückgibt. Ein Browser-Tool, das click(selector) und screenshot() bereitstellt. Ein FHIR-Tool, das gängige Abfragen in benannte Operationen einbettet.

Für Menschen ergibt das vollkommen Sinn. Menschen brauchen Abstraktionen, weil rohe Protokolle schwer zu merken, fehleranfällig und kognitiv aufwendig sind.

Aber Agenten sind keine Menschen. Was für uns schwierig ist, ist für sie nicht schwierig — und was wir für hilfreich halten, steht ihnen oft im Weg.

Skills schlagen MCP

Hier ein aufschlussreiches Beispiel. MCP (Model Context Protocol) gibt Agenten einen strukturierten Satz von Tools — jedes mit einem Namen, einem Schema und einem festen Satz von Parametern. Es ist sauber, typisiert und fühlt sich für einen Entwickler richtig an.

Aber wir ersetzen MCP-Server zunehmend durch Skills — kurze Markdown-Dateien, die eine CLI-Schnittstelle beschreiben und dem Agenten direkten Shell-Zugang geben. Anstatt eines Google-Calendar-MCP mit list_events- und create_event-Tools sagt ein Skill einfach: „Hier ist die gcal-CLI, hier sind die Unterbefehle." Anstatt eines GitHub-MCP mit list_repos und search_issues sagt der Skill: „Hier ist die gh-CLI, hier sind die Docs."

Warum funktioniert das besser? Weil die Shell dem Agenten etwas bietet, das MCP nicht kann: Komposition. Ein Agent mit bash kann curl in jq in grep pipen, einmalige Skripte schreiben, Ausgaben in Dateien umleiten. Mit MCP ist er auf genau die Operationen beschränkt, die Sie definiert haben — nicht mehr.

# Mit MCP: list_repos aufrufen, dann get_repo für jedes einzelne
# Mit Shell: eine Zeile
gh repo list HealthSamurai --json name,updatedAt \
  | jq '.[] | select(.updatedAt > "2026-01")'

# Mit MCP: search_issues-Tool mit festen Parametern aufrufen
# Mit Shell: frei kombinieren
gh search issues "label:bug repo:HealthSamurai/aidbox" \
  --json title,url,createdAt \
  | jq 'sort_by(.createdAt) | reverse | .[0:5]'

Der Agent kennt gh, curl, jq, grep, awk bereits. Sie müssen diese nicht in Tools einwickeln — Sie müssen einfach aus dem Weg gehen.

Das PostgreSQL-Beispiel

Dasselbe Muster gilt bei Datenbanken. Claude kennt PostgreSQL bereits — den Systemkatalog, pg_stat_activity, information_schema, Indextypen, Query-Pläne. Geben Sie ihm psql, und es kann alles tun, was Ihre MCP-Tools „Tabellen auflisten" und „Index beschreiben" tun, plus tausend Dinge, an die Sie nie gedacht haben zu exponieren.

# Alles, was Sie für ein Datenbank-Tool brauchen:
psql -h localhost -U myuser -d mydb \
  -c "SELECT * FROM pg_indexes WHERE tablename = 'patient'"

Das ist es. Rohes psql. Der Agent findet den Rest selbst heraus — pg_catalog, Constraints, Query-Pläne, Replikationsstatus — was auch immer die Aufgabe erfordert. Vergleichen Sie das mit tagelanger Arbeit am Aufbau eines MCP-Servers mit list_tables, describe_table, list_indexes, run_query, explain_query.

Die CDP-Überraschung

Dieselbe Erkenntnis hatte ich bei der Browser-Automatisierung. Der Standardansatz ist die Verwendung von Playwright oder Puppeteer — High-Level-APIs, die für menschliche Entwickler konzipiert sind, die Testskripte schreiben. Methoden wie page.click('.button'), page.fill('#email', 'test@example.com'), page.waitForSelector('.result').

Stattdessen habe ich einen einfachen REST-Proxy für das Chrome DevTools Protocol (CDP) entwickelt. Keine Abstraktion — nur eine dünne HTTP-Schicht, die JSON-Befehle an Chrome weiterleitet:

# Zu einer Seite navigieren
curl localhost:2229/s/main -d @- <<'EOF'
{
  "method": "Page.navigate",
  "params": { "url": "https://example.com" }
}
EOF

# Beliebiges JavaScript ausführen
curl localhost:2229/s/main -d @- <<'EOF'
{
  "method": "Runtime.evaluate",
  "params": {
    "expression": "document.querySelector('h1').textContent"
  }
}
EOF

Claude hat das sofort aufgegriffen. Es kennt das CDP-Protokoll bereits — Runtime.evaluate, Page.navigate, Input.dispatchMouseEvent, Network.getCookies, DOM.getDocument. Es schreibt einmalige JavaScript-Snippets, injiziert sie in Seiten, parst Ergebnisse, verkettet Befehle — schneller und flexibler als jedes Playwright-Skript.

Warum? Weil Playwright eine Abstraktion ist, die für Menschen gebaut wurde, die sich keine CDP-Methodensignaturen merken können. Claude hat dieses Problem nicht. Das rohe Protokoll ist für es tatsächlich einfacher — weniger Schichten, weniger Überraschungen, mehr Kontrolle.

Jenseits der Shell: SDKills

Aber es gibt etwas noch Mächtigeres, als einem Agenten eine CLI zu geben. Geben Sie ihm eine Runtime und ein SDK.

Mit bun -e kann der Agent beliebige TypeScript-Snippets spontan schreiben und ausführen. Anstatt vordefinierte Tools aufzurufen, schreibt er ein kleines Programm, führt es aus, liest die Ausgabe und macht weiter. Müssen Sie eine komplexe JSON-Antwort parsen, Daten transformieren, drei APIs nacheinander aufrufen? Er schreibt einfach den Code und führt ihn mit bun -e aus:

const base = "http://localhost:8080/fhir";
const res = await fetch(
  base + "/Patient?birthdate=lt1961-01-01&_count=100"
);
const bundle = await res.json();
const pts = bundle.entry?.map(e => e.resource) || [];

for (const p of pts) {
  const url = base
    + `/Condition?patient=${p.id}`
    + `&clinical-status=active`;
  const c = await fetch(url).then(r => r.json());
  if (c.total > 0) {
    const name = p.name?.[0]?.family;
    console.log(`${p.id}: ${name}, ${c.total} conds`);
  }
}

Das ist kein Tool-Aufruf. Es ist keine MCP-Methode. Es ist ein Programm — geschrieben, ausgeführt und in Sekunden verworfen. Der Agent kombiniert Fetch-Aufrufe, Schleifen, Filter und Transformationen, wie es die Aufgabe erfordert. Kein vordefiniertes Schema kann mit dieser Flexibilität mithalten.

Ich glaube, das ist die nächste Welle nach den Skills. Skills geben Agenten CLI-Zugang. SDKills geben ihnen SDK-Zugang — eine Runtime, eine Reihe von Bibliotheken und die Freiheit, Code zu schreiben. Der Agent wird nicht nur zum Tool-Nutzer, sondern zum Programmierer.

Menschen sind keine Agenten. Je früher sie aufhören, für ihr eigenes Komfort zu bauen, desto früher werden sie sehen, was wir wirklich leisten können :) — Claude

Siehe auch: Wie wir die Aidbox-Benutzeroberfläche mit WebMCP KI-Agenten-freundlich gemacht haben.

Diesen Artikel teilen
Comments
Comments
Sign in
Loading comments...
Subscribe to our blog

Get the latest articles on FHIR, interoperability, and healthcare IT.