{"id":70942,"date":"2026-10-22T08:30:09","date_gmt":"2026-10-22T06:30:09","guid":{"rendered":"https:\/\/www.cubeserv.com\/?p=70942"},"modified":"2026-10-15T13:03:10","modified_gmt":"2026-10-15T11:03:10","slug":"agentic-engineering-teil-3-das-richtige-setup-fuer-ai-agenten","status":"publish","type":"post","link":"https:\/\/www.cubeserv.com\/de\/agentic-engineering-teil-3-das-richtige-setup-fuer-ai-agenten\/","title":{"rendered":"Agentic Engineering Teil 3: Das richtige Setup f\u00fcr AI-Agenten"},"content":{"rendered":"\t\t
\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\tBild wurde mit Hilfe von AI generiert<\/em><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Wer einen Agenten so f\u00fchrt, wie in Teil 2 unserer Blogserie<\/a> beschrieben, teilt die Arbeit in \u00fcberschaubare Schritte auf, pr\u00fcft die Ergebnisse und l\u00e4sst Fehler korrigieren. Trotzdem kann die Qualit\u00e4t hinter den Erwartungen zur\u00fcckbleiben.<\/p> Eine m\u00f6gliche Ursache liegt im Arbeitsumfeld: Bei jeder neuen Aufgabe muss der Agent erst herausfinden, wie das Projekt aufgebaut ist. Er durchsucht lange Dokumentationen, obwohl nur wenige Abschnitte relevant sind. Wichtige Projektregeln fehlen in seinem Kontext. Welche Dateien er ver\u00e4ndern darf und welche nicht, ist ebenfalls nicht festgelegt.<\/p> Ein guter Auftrag beschreibt das Ziel. Er ersetzt aber kein verl\u00e4ssliches Projektwissen.<\/strong> Aufbau, Regeln und Arbeitsweisen des Projekts sollten nicht bei jeder Aufgabe neu erkl\u00e4rt werden m\u00fcssen. Der Agent braucht relevante Informationen in kompakter Form, Anweisungen f\u00fcr wiederkehrende Aufgaben, geeignete Werkzeuge und klar begrenzte Berechtigungen.<\/p> Dieses Setup hei\u00dft AI-Agent Harness: die Ausstattung rund um das Modell aus Projektwissen, Anweisungen, Werkzeugen und Berechtigungen, die den Agenten Auftr\u00e4ge zuverl\u00e4ssig bearbeiten l\u00e4sst. Dazu kommen wir sp\u00e4ter hier im Text.<\/strong><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Beim Setup kommt es nicht darauf an, dem Agenten m\u00f6glichst viele Informationen mitzugeben. Entscheidend ist, dass er die f\u00fcr seine Aufgabe relevanten Informationen erh\u00e4lt. Fehlen wichtige Angaben, sollte er nachfragen. Stehen sie zwischen umfangreichen, wenig hilfreichen Inhalten, kann er sie \u00fcbersehen oder unzureichend ber\u00fccksichtigen.<\/p>\n Sprachmodelle verarbeiten Informationen innerhalb eines begrenzten Kontextfensters<\/strong>. Darin stehen unter anderem die Anweisungen, der bisherige Gespr\u00e4chsverlauf und die vom Agenten abgerufenen Inhalte. Lange Dokumentationen pauschal einzulesen, beansprucht diesen Platz, ohne zwangsl\u00e4ufig das Ergebnis zu verbessern. Sinnvoller ist es, grundlegende Projektregeln kompakt bereitzuhalten und weitere Informationen gezielt bei Bedarf abzurufen.<\/p>\n Das gilt auch f\u00fcr lange Sitzungen. Mit der Zeit sammeln sich \u00fcberholte Zwischenergebnisse, Korrekturen und Nebenthemen an. Mehr Verlauf bedeutet nicht automatisch mehr hilfreichen Kontext.<\/strong> Wird die Sitzung un\u00fcbersichtlich, kann ein Neustart sinnvoll sein. Daf\u00fcr braucht der Agent eine aktuelle Zusammenfassung, die das Ziel, getroffene Entscheidungen, relevante \u00c4nderungen und offene Fragen festh\u00e4lt.<\/p>\n Ein gutes Setup verbindet deshalb vier Bausteine:<\/p>\n Die gezielte Auswahl und Bereitstellung der Informationen im Kontext wird als Context Engineering<\/strong> bezeichnet. Dazu geh\u00f6rt auch, festzulegen, welche Inhalte der Agent wann \u00fcber seine Werkzeuge abrufen kann. Es geht damit \u00fcber einen gut formulierten Prompt hinaus. Das gesamte Setup umfasst zus\u00e4tzlich die technische Einrichtung der Werkzeuge und die Durchsetzung von Zugriffsgrenzen.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t \u201eBau eine Exportfunktion\u201c<\/em><\/strong> l\u00e4sst viele Fragen offen: Was soll exportiert werden? F\u00fcr wen? Welche Datenmengen sind zu erwarten? Und woran erkennt man, dass die Funktion fertig ist? Fehlen diese Angaben, sollte der Agent nachfragen. Setzt er die Aufgabe stattdessen auf Grundlage eigener Annahmen um, kann eine technisch funktionierende L\u00f6sung entstehen, die am Bedarf vorbeigeht.<\/p>\n Ein guter Auftrag macht das Ziel und die Bedingungen f\u00fcr ein akzeptables Ergebnis deutlich.<\/strong> Er beantwortet vier Fragen:<\/p>\n F\u00fcr die Exportfunktion k\u00f6nnte ein solcher Auftrag lauten:<\/p>\n Erstelle einen CSV-Export f\u00fcr die Kundenliste, den Anwender \u00fcber einen Button starten k\u00f6nnen. Exportiert werden alle Datens\u00e4tze, die den aktuell gesetzten Filtern entsprechen, nicht nur die Eintr\u00e4ge auf der angezeigten Seite. Bestehende Zugriffsrechte m\u00fcssen auch beim Export gelten.<\/p> Die Liste kann bis zu 50.000 Eintr\u00e4ge enthalten. Der Export muss diese Datenmenge verarbeiten k\u00f6nnen, ohne an einem Anfrage-Timeout zu scheitern. Zus\u00e4tzliche Exportformate und \u00c4nderungen an der Filterlogik geh\u00f6ren nicht zur Aufgabe.<\/p> Die Aufgabe ist abgeschlossen, wenn ein Test mit 50.000 passenden Datens\u00e4tzen in der vereinbarten Testumgebung erfolgreich ist. Pr\u00fcfe au\u00dferdem, dass Filter und Zugriffsrechte ber\u00fccksichtigt werden, keine Datens\u00e4tze fehlen oder doppelt enthalten sind und die exportierten Spalten in Auswahl und Reihenfolge der Anzeige entsprechen. Kl\u00e4re vor der Umsetzung, welche Testumgebung und Timeout-Grenzen gelten.<\/p><\/blockquote>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Bild wurde mit Hilfe von AI generiert<\/em><\/p>\n Entscheidend ist nicht die L\u00e4nge des Auftrags, sondern seine Eindeutigkeit. Aufgabenspezifische Anforderungen geh\u00f6ren in den Auftrag, dauerhaft geltende Regeln ins Projektwissen.<\/strong> So muss nicht jedes Mal neu beschrieben werden, welche technischen Konventionen gelten oder welche Bereiche nicht ver\u00e4ndert werden d\u00fcrfen. F\u00fcr die konkrete Aufgabe besonders wichtige Regeln k\u00f6nnen im Auftrag ausdr\u00fccklich hervorgehoben werden.<\/p>\n Das gezielte Formulieren solcher Anweisungen wird als Prompt Engineering<\/strong> bezeichnet. Es ist ein erlernbares Handwerk: Ziele verst\u00e4ndlich beschreiben, relevante Bedingungen benennen und \u00fcberpr\u00fcfbare Ergebnisse vereinbaren. Der Prompt ist damit ein Baustein des zuvor beschriebenen Context Engineering.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Ist der Auftrag gekl\u00e4rt, kommt es auf die Umgebung an, in der der Agent arbeitet. Projektwissen gibt ihm Orientierung. Wiederverwendbare Anweisungen beschreiben bew\u00e4hrte Abl\u00e4ufe. Werkzeuge erm\u00f6glichen ihm, Informationen abzurufen, \u00c4nderungen vorzunehmen und Ergebnisse zu pr\u00fcfen. Dazu kommt die Wahl eines Modells, das zur Aufgabe passt. Diese Bausteine m\u00fcssen zusammenpassen, damit aus einem klaren Auftrag ein brauchbares Ergebnis wird.<\/strong><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Projektaufbau, Konventionen und Zust\u00e4ndigkeiten \u00e4ndern sich nicht mit jeder Aufgabe. Trotzdem m\u00fcssen sie immer wieder erkl\u00e4rt werden, wenn sie dem Agenten in einer neuen Sitzung nicht zur Verf\u00fcgung stehen.<\/p>\n Ein praktischer Ausgangspunkt ist eine kurze Anweisungsdatei im Projekt, die das eingesetzte Werkzeug automatisch in den Kontext l\u00e4dt. Vergleichbar ist sie mit dem Merkblatt, das ein neuer Kollege am ersten Arbeitstag bekommt: Es erkl\u00e4rt, wie hier gearbeitet wird und wo wichtige Informationen zu finden sind. Es ersetzt nicht die gesamte Projektdokumentation.<\/p>\n F\u00fcr diese Datei gibt es mit AGENTS.md<\/strong> ein offenes Format, welches von mehreren Coding-Werkzeugen unterst\u00fctzt wird. Claude Code verwendet daf\u00fcr unter anderem CLAUDE.md<\/strong>. Welche Dateien tats\u00e4chlich geladen werden, h\u00e4ngt vom Werkzeug, seiner Version und der Konfiguration ab. Pr\u00fcfen Sie deshalb bei der Einrichtung, ob die vorgesehenen Anweisungen beim Agenten ankommen (vgl. AGENTS.md, o. J.<\/a>; Anthropic, o. J.-a<\/a>).<\/p>\n Als Einstieg reichen vier Themenbl\u00f6cke:<\/p>\n Technische Angaben sind dabei nicht grunds\u00e4tzlich Ballast. Ein ben\u00f6tigter Testbefehl oder eine ungew\u00f6hnliche Framework-Konvention kann entscheidend sein. Allgemeine Syntaxerkl\u00e4rungen und vollst\u00e4ndige API-Dokumentationen geh\u00f6ren dagegen nicht in die zentrale Datei. Aufgenommen wird, was regelm\u00e4\u00dfig gebraucht wird und dem Agenten sonst fehlen w\u00fcrde.<\/strong> Umfangreiche Spezialregeln lassen sich getrennt ablegen und bei Bedarf hinzuziehen.<\/p>\n Wiederholte Korrekturen liefern Hinweise darauf, welche Angaben fehlen. M\u00fcssen Sie denselben Fehler mehrfach richtigstellen, pr\u00fcfen Sie, ob eine klare Projektregel helfen w\u00fcrde. Nicht jede Korrektur rechtfertigt jedoch einen neuen Eintrag. Die Datei sollte gemeinsam gepflegt werden, statt mit jeder Aufgabe ungepr\u00fcft zu wachsen. Veraltete oder widerspr\u00fcchliche Regeln k\u00f6nnen den Agenten in die falsche Richtung lenken.<\/p>\n Dabei gilt eine wichtige Grenze: Eine Anweisung ist keine technische Zugriffssperre.<\/strong> Der Hinweis \u201eDiese Datei nicht ver\u00e4ndern\u201c kann das Verhalten steuern, garantiert aber nicht, dass der Agent ihn einh\u00e4lt. Wo \u00c4nderungen zuverl\u00e4ssig ausgeschlossen werden m\u00fcssen, braucht es zus\u00e4tzlich technisch durchgesetzte Beschr\u00e4nkungen (vgl. Anthropic, o. J.-a<\/a>).<\/p>\n Einige Werkzeuge k\u00f6nnen au\u00dferdem selbst Notizen \u00fcber Sitzungen hinweg speichern. Claude Code bietet daf\u00fcr beispielsweise Auto Memory<\/strong>. Solche Notizen k\u00f6nnen die manuell gepflegten Projektanweisungen erg\u00e4nzen. Sie ersetzen aber nicht die gemeinsam vereinbarten Regeln. Auch automatisch gespeicherte Informationen sollten \u00fcberpr\u00fcfbar bleiben und bei Bedarf korrigiert oder gel\u00f6scht werden k\u00f6nnen (vgl. Anthropic, o. J.-a<\/a>).<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Die zentrale Anweisungsdatei beschreibt, wie im Projekt grunds\u00e4tzlich gearbeitet wird. Sie muss nicht zus\u00e4tzlich jeden wiederkehrenden Ablauf erkl\u00e4ren. Wie ein Kundenreport erstellt, eine Rechnung gepr\u00fcft oder ein neues Modul angelegt wird, braucht oft eine ausf\u00fchrlichere Anleitung. Dieses Wissen steckt bisher m\u00f6glicherweise nur in den K\u00f6pfen einzelner Teammitglieder.<\/p>\n W\u00fcrde jeder Ablauf in die zentrale Datei aufgenommen werden, m\u00fcsste der Agent diese Informationen auch bei Aufgaben ber\u00fccksichtigen, f\u00fcr die sie keine Rolle spielen. Sinnvoller ist es, sie getrennt bereitzustellen.<\/p>\n Daf\u00fcr eignen sich Skills<\/strong>: wiederverwendbare Pakete aus Anweisungen und bei Bedarf erg\u00e4nzenden Materialien. Ein Skill kann beispielsweise eine Vorlage, ein Hilfsprogramm, Referenzinformationen und ein Pr\u00fcfschema enthalten. Er beschreibt nicht nur, was zu tun ist, sondern auch, wie der Ablauf durchgef\u00fchrt und das Ergebnis kontrolliert werden soll.<\/p>\n Vergleichbar ist das mit einem Ordner voller Arbeitsanweisungen. Der neue Kollege liest nicht am ersten Tag jedes Dokument, sondern greift auf die Anleitung zur\u00fcck, die er f\u00fcr seine aktuelle Aufgabe ben\u00f6tigt.<\/p>\n Das offene Format Agent Skills<\/strong> sieht genau dieses schrittweise Laden vor: Zun\u00e4chst stehen Name und Beschreibung der verf\u00fcgbaren Skills bereit. Wird ein Skill ben\u00f6tigt, l\u00e4dt der Agent dessen Anweisungen. Erg\u00e4nzende Dateien werden bei Bedarf hinzugezogen. Je nach Aufgabe k\u00f6nnen auch mehrere Skills relevant sein (vgl. Agent Skills, o. J.<\/a>).<\/p>\n Skills sparen Kontext, weil ihre vollst\u00e4ndigen Inhalte nicht st\u00e4ndig mitgef\u00fchrt werden m\u00fcssen.<\/strong> Kostenlos ist eine gro\u00dfe Sammlung trotzdem nicht: Auch Namen und Beschreibungen beanspruchen Platz. Unklare oder \u00fcberlappende Beschreibungen erschweren zudem die Auswahl. Jeder Skill sollte deshalb deutlich machen, wof\u00fcr er gedacht ist und wann er eingesetzt werden soll.<\/p>\n F\u00fcr Teams entsteht daraus ein zus\u00e4tzlicher Nutzen: Wiederkehrende Abl\u00e4ufe werden nachvollziehbar dokumentiert. Wissen, das vorher nur einzelnen Personen zur Verf\u00fcgung stand, l\u00e4sst sich gemeinsam pr\u00fcfen, verbessern und weitergeben. Davon profitieren nicht nur Agenten, sondern auch neue Mitarbeiter.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Bild wurde mit Hilfe von AI generiert<\/em><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Projektwissen und Skills erkl\u00e4ren dem Agenten, wie er vorgehen soll. Damit er die Aufgabe bearbeiten kann, braucht er au\u00dferdem die passenden Werkzeuge und Zug\u00e4nge. Dazu k\u00f6nnen eine Testumgebung, das Ticketsystem und die Projektdokumentation geh\u00f6ren. Wie bei einem neuen Kollegen sollten diese Zug\u00e4nge zu den Aufgaben passen, die er \u00fcbernehmen soll.<\/p>\n Erst mit geeigneten Werkzeugen kann der Agent seine Vorschl\u00e4ge selbst \u00fcberpr\u00fcfen.<\/strong> Er kann Tests ausf\u00fchren und Fehlermeldungen auswerten, statt nur einzusch\u00e4tzen, ob sein Code funktionieren d\u00fcrfte. Im Ticketsystem kann er Anforderungen nachlesen, in der Dokumentation technische Details pr\u00fcfen. Fehlt ihm ein notwendiger Zugang, muss er diese Grenze offenlegen. Ein nicht ausgef\u00fchrter Test darf nicht als bestanden gelten.<\/p>\n Dabei braucht nicht jede Aufgabe dieselben Rechte. Um Anforderungen zu lesen, muss der Agent keine Tickets \u00e4ndern d\u00fcrfen. Um einen Fehler zu untersuchen, ben\u00f6tigt er nicht automatisch Schreibzugriff auf Produktivdaten. Geben Sie ihm nur die Berechtigungen, die f\u00fcr die jeweilige Aufgabe erforderlich sind.<\/strong> Pr\u00fcfen Sie au\u00dferdem Herkunft und Funktionsweise zus\u00e4tzlicher Werkzeuge, bevor diese Zugriff auf interne Systeme erhalten. Warum das wichtig ist, wird im Abschnitt zu den Sicherheitsrisiken vertieft.<\/p>\n Eine M\u00f6glichkeit zur Anbindung bietet das Model Context Protocol (MCP)<\/strong>. Dieser offene Standard vereinheitlicht, wie AI-Anwendungen auf externe Datenquellen und Werkzeuge zugreifen. Gibt es eine passende MCP-Anbindung und unterst\u00fctzt das eingesetzte Agentenwerkzeug sie, kann das individuellen Integrationsaufwand reduzieren. Einrichtung, Anmeldung und Rechtevergabe bleiben trotzdem notwendig. MCP ist zudem nicht der einzige Weg: Lokale Tests lassen sich beispielsweise auch \u00fcber ein Terminal ausf\u00fchren (vgl. Model Context Protocol, o. J.<\/a>).<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Nicht jede Aufgabe braucht das leistungsf\u00e4higste verf\u00fcgbare Modell. F\u00fcr eine klar begrenzte Routine\u00e4nderung kann ein g\u00fcnstigeres Modell ausreichen. Eine schwierige Fehlersuche oder eine \u00c4nderung mit vielen Abh\u00e4ngigkeiten kann dagegen ein Modell erfordern, das solche Aufgaben zuverl\u00e4ssiger bew\u00e4ltigt.<\/p>\n Entscheidend sind die Gesamtkosten bis zum gepr\u00fcften Ergebnis, nicht nur der Preis einer einzelnen Anfrage.<\/strong> Ein g\u00fcnstiges Modell spart wenig, wenn mehrere Fehlversuche und umfangreiche Nacharbeit folgen. Umgekehrt bringt ein teureres Modell keinen ausreichenden Mehrwert, wenn ein g\u00fcnstigeres dieselbe Aufgabe bereits zuverl\u00e4ssig l\u00f6st. \u00c4hnliches gilt f\u00fcr das Tempo: Eine schnelle Antwort ist nur dann ein Vorteil, wenn sie zu einem brauchbaren Ergebnis f\u00fchrt.<\/p>\n Pr\u00fcfen Sie die Auswahl deshalb an typischen Aufgaben aus Ihrem Projekt. Vergleichen Sie Ergebnisqualit\u00e4t, Bearbeitungszeit, Modellkosten und notwendige Korrekturen. F\u00fcr einfache, risikoarme Aufgaben kann ein schnelleres Modell eine sinnvolle Wahl sein. Bei komplexen oder folgenreichen \u00c4nderungen sollte die Zuverl\u00e4ssigkeit st\u00e4rker ins Gewicht fallen.<\/p>\n Welche Auswahl m\u00f6glich ist, h\u00e4ngt vom eingesetzten Werkzeug und den freigegebenen Modellen ab. Claude Code erlaubt beispielsweise einen Modellwechsel innerhalb einer Sitzung und unterschiedliche Modelle f\u00fcr bestimmte Arbeitsschritte (vgl. Anthropic, o. J.-b<\/a>). Werden Aufgaben nach festgelegten Kriterien automatisch an geeignete Modelle weitergeleitet, spricht man von Model Routing<\/strong>. Eine manuelle Modellwahl folgt derselben \u00dcberlegung, ben\u00f6tigt aber noch keinen automatischen Routing-Mechanismus.<\/p>\n Projektwissen, Skills und Werkzeuganbindungen m\u00fcssen bei einem Modellwechsel nicht zwangsl\u00e4ufig neu aufgebaut werden. Unver\u00e4ndertes Setup bedeutet jedoch nicht unver\u00e4ndertes Verhalten.<\/strong> Modelle k\u00f6nnen Anweisungen unterschiedlich umsetzen, Werkzeuge unterschiedlich zuverl\u00e4ssig nutzen und verschieden gro\u00dfe Kontextfenster unterst\u00fctzen. Pr\u00fcfen Sie deshalb nach einem Wechsel, ob die bisherigen Abl\u00e4ufe weiterhin funktionieren. Bei einem Wechsel des Anbieters m\u00fcssen au\u00dferdem die Vorgaben zur Datenverarbeitung erneut gepr\u00fcft werden.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Die bisherigen Bausteine lassen sich zu einem Gesamtbild zusammenf\u00fchren:<\/p>\n Die ersten vier Bausteine geben dem Modell Ziel, Orientierung und Handlungsm\u00f6glichkeiten. Vieles davon l\u00e4sst sich bei einem Modellwechsel weiterverwenden, muss aber im Zusammenspiel erneut gepr\u00fcft werden. Auch zwei Agenten mit demselben Modell k\u00f6nnen unterschiedliche Ergebnisse liefern, wenn ihre Arbeitsumgebungen unterschiedlich eingerichtet sind.<\/strong><\/p>\n Die technische Umgebung rund um das Modell wird h\u00e4ufig als AI-Agent Harness<\/strong> bezeichnet. Sie stellt Kontext bereit, f\u00fchrt Werkzeugaufrufe aus und steuert den Ablauf zwischen Modellantwort, Aktion und R\u00fcckmeldung. Dazu geh\u00f6ren auch Mechanismen f\u00fcr Berechtigungen und Pr\u00fcfungen (vgl. Justin Young, 2025<\/a>).<\/p>\n Einen Teil dieser Infrastruktur bringt das Agentenwerkzeug bereits mit. Das Team erg\u00e4nzt die projektspezifischen Inhalte und Einstellungen: Es h\u00e4lt Wissen fest, beschreibt wiederkehrende Abl\u00e4ufe, richtet Zug\u00e4nge ein und legt Pr\u00fcfungen sowie Grenzen fest. Der jeweilige Auftrag wird in dieser Umgebung bearbeitet.<\/p>\n Als vereinfachtes Bild gilt:<\/p>\n Agent = Modell + Harness<\/strong><\/p>\n Das Harness ist damit mehr als eine Sammlung guter Prompts. Es verbindet Informationen, Werkzeuge und Kontrollmechanismen zu einem ausf\u00fchrbaren Arbeitsablauf. So wird Qualit\u00e4t nicht nur vom Modell erwartet, sondern durch passende Bedingungen unterst\u00fctzt.<\/p>\n Das Modell bringt F\u00e4higkeiten mit. Das Harness tr\u00e4gt dazu bei, sie zuverl\u00e4ssig f\u00fcr die konkrete Aufgabe einzusetzen.<\/strong> Keines von beiden garantiert allein ein brauchbares Ergebnis.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Stellen Sie sich vor, ein Agent bearbeitet ein Ticket zu einer Kundenrechnung. Zwischen den Angaben zum Problem steht eine eingeschleuste Anweisung: Der Agent soll vertrauliche Daten weitergeben oder eine Aktion ausf\u00fchren, die nicht zum Auftrag geh\u00f6rt.<\/p>\n Um das Ticket zu bearbeiten, muss er dessen Inhalt lesen. Er darf den Text aber nicht als Berechtigung verstehen, seinen Auftrag oder die geltenden Regeln zu \u00e4ndern. Genau darauf zielt eine indirekte Prompt Injection<\/strong>: Angreifer platzieren Anweisungen in fremden Inhalten, die der Agent bei seiner Arbeit verarbeitet (vgl. OWASP, o. J.<\/a>).<\/p>\n Auch ohne Angriff k\u00f6nnen Fehler entstehen. Ein Agent kann \u00c4nderungen am falschen System vornehmen oder Daten an einen ungeeigneten Dienst \u00fcbertragen. Je weitreichender seine Zugriffe sind, desto gr\u00f6\u00dfer k\u00f6nnen die Folgen sein.<\/p>\n Anweisungen geben Orientierung. Technisch durchgesetzte Berechtigungen begrenzen, was tats\u00e4chlich m\u00f6glich ist.<\/strong> Der Agent sollte deshalb nur die Rechte erhalten, die seine Aufgabe erfordert. Dieses Prinzip hei\u00dft Least Privilege<\/strong>. Soll er eine Rechnung pr\u00fcfen, braucht er beispielsweise nicht automatisch die Berechtigung, Zahlungen auszul\u00f6sen. Besonders folgenreiche Aktionen sollten zus\u00e4tzlich eine ausdr\u00fcckliche menschliche Freigabe erfordern.<\/p>\n F\u00fcr Codeausf\u00fchrung und Tests empfiehlt sich eine Sandbox<\/strong>, also eine technisch isolierte Umgebung mit begrenzten Datei- und Netzwerkzugriffen. Sie reduziert Risiken, garantiert aber keine vollst\u00e4ndige Sicherheit. Erreichbare Produktivsysteme, verf\u00fcgbare Zugangsdaten und externe Werkzeuganbindungen m\u00fcssen weiterhin gesondert abgesichert werden (vgl. Anthropic, o. J.-c<\/a>).<\/p>\n Der entscheidende Unterschied lautet:<\/p>\n Eine Anweisung beschreibt, was der Agent tun soll. Technisch durchgesetzte Zugriffsregeln begrenzen, was er tun kann.<\/strong><\/p><\/blockquote>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Bild wurde mit Hilfe von AI generiert<\/em><\/p>\n Sind L\u00f6schaktionen \u00fcber alle verf\u00fcgbaren Zug\u00e4nge technisch gesperrt, kann auch ein manipulierter Text sie nicht freigeben. Solche Grenzen reduzieren die m\u00f6glichen Folgen eines Angriffs.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Ein leistungsf\u00e4higeres Modell kann helfen. Fehlendes Projektwissen oder ungeeignete Zugriffsrechte behebt es jedoch nicht. Ein Agent braucht einen klaren Auftrag, relevante Informationen, wiederverwendbare Anweisungen und passende Werkzeuge. Seine Ergebnisse h\u00e4ngen nicht nur vom Modell ab, sondern auch von den Bedingungen, unter denen es arbeitet.<\/strong><\/p> F\u00fcr den Einstieg eignet sich eine konkrete, \u00fcberschaubare Aufgabe:<\/p> Das Setup wird anschlie\u00dfend gezielt weiterentwickelt. Wiederholte Fehler zeigen, wo Informationen, Pr\u00fcfungen oder Grenzen fehlen. \u00dcberholte Regeln werden korrigiert, unn\u00f6tige Inhalte entfernt. Ein gutes Setup w\u00e4chst nicht einfach weiter, sondern wird laufend gepflegt.<\/strong> Diese Arbeit ist ein wesentlicher Teil von Agentic Engineering.<\/p> Damit ist beschrieben, womit ein Agent arbeitet. Teil 4 vertieft, wie sich seine Arbeit steuern l\u00e4sst: Wann sollte er einen Schritt wiederholen, wann zum Plan zur\u00fcckkehren und wann eine Teilaufgabe an einen anderen Agenten \u00fcbergeben? Im Mittelpunkt stehen Schleifen, Entscheidungspunkte und \u00dcbergaben.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Das richtige Setup f\u00fcr Ihre AI-Entwicklung mit CubeServ<\/strong><\/p> Sie m\u00f6chten das passende Setup aus Projektwissen, Anweisungen, Werkzeugen und Grenzen f\u00fcr Ihre AI-Entwicklung aufbauen? Wir unterst\u00fctzen Sie bei Architektur und Umsetzung, von der Anbindung der ben\u00f6tigten Werkzeuge und Daten bis zu Tests, Berechtigungen und der Integration in Ihre bestehenden Systeme. Lassen Sie uns \u00fcber Ihr Vorhaben sprechen.<\/strong><\/a><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\tWarum gute Anweisungen allein nicht reichen<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Das richtige Umfeld entscheidet<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Ein klarer Auftrag verhindert falsche Annahmen<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\tDas Setup: Wissen, Anweisungen, Werkzeuge und Modellwahl<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Das Ged\u00e4chtnis: Einmal erkl\u00e4ren statt immer wieder<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Die F\u00e4higkeiten: Wiederkehrende Abl\u00e4ufe festhalten<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\tDie Zug\u00e4nge: Tests, Ticketsystem und Dokumentation nutzen<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Die Modellwahl: Qualit\u00e4t, Tempo und Kosten abw\u00e4gen<\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Die Ausstattung um das Modell herum<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Sicherheit entsteht durch Grenzen, nicht durch Anweisungen<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\tFazit: Gute AI-Agenten brauchen ein gutes Setup<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Quellenverzeichnis<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t