Neue Tools für den Aufbau von Agenten
(openai.com)- OpenAI hat die Responses API, integrierte Tools, das Agents SDK und Observability-Tools vorgestellt, um die Entwicklung von produktionsreifen Agenten zu erleichtern
- Die Responses API kombiniert die Einfachheit der Chat Completions API mit den Tool-Nutzungsfunktionen der Assistants API, sodass Websuche, Dateisuche und Computernutzung in einem einzigen Ablauf verarbeitet werden können
- Für neue Integrationen wird die Verwendung der Responses API empfohlen; die Assistants API soll nach Erreichen der Funktionsgleichheit mit dem Ziel einer Einstellung Mitte 2026 in den Deprecation-Prozess übergehen
- Die integrierten Tools unterstützen aktuelle Webinformationen, die Suche in umfangreichen Dokumenten und die Automatisierung computerbasierter Aufgaben per Maus und Tastatur, jedoch wird bei computer use insbesondere in Nicht-Browser-Umgebungen menschliche Aufsicht empfohlen
- Entwickler können APIs, Tools, SDK und Funktionen für Tracing und Evaluierung auf einer Plattform kombinieren, um Agenten zu erstellen, bereitzustellen und zu optimieren
Neue Bausteine für die Entwicklung von Agenten
- OpenAI betrachtet Agenten als Systeme, die Aufgaben im Auftrag von Nutzern eigenständig ausführen
- Im vergangenen Jahr wurden fortgeschrittene Reasoning-Fähigkeiten, multimodale Interaktionen und neue Sicherheitsmethoden eingeführt, wodurch die Grundlage für die Verarbeitung komplexer mehrstufiger Aufgaben geschaffen wurde
- Kunden hatten Schwierigkeiten, diese Funktionen in produktionsreife Agenten zu überführen
- Es sind umfangreiche Prompt-Iterationen nötig
- Eigene Orchestrierungslogik muss direkt selbst erstellt werden
- Es fehlen ausreichende Transparenz und integrierte Unterstützung
- Die jetzt vorgestellten Bausteine sind:
- Responses API: kombiniert die Einfachheit der Chat Completions API mit den Tool-Nutzungsfunktionen der Assistants API
- Integrierte Tools: web search, file search, computer use
- Agents SDK: orchestriert Single-Agent- und Multi-Agent-Workflows
- Observability-Tools: verfolgen und inspizieren die Ausführung von Agent-Workflows
Responses API
- Die Responses API ist die neue grundlegende API-Einheit zum Erstellen von Agenten unter Nutzung der integrierten Tools von OpenAI
- Sie kombiniert die Einfachheit von Chat Completions mit den Tool-Nutzungsfunktionen der Assistants API
- Mit einem einzelnen Aufruf der Responses API lassen sich komplexere Aufgaben mithilfe mehrerer Tools und mehrerer Model-Turns bearbeiten
- Zu den anfangs unterstützten Tools gehören:
- Websuche
- Dateisuche
- Computernutzung
- Auch Verbesserungen bei der Nutzbarkeit sind enthalten
- einheitliches item-basiertes Design
- einfachere Polymorphie
- intuitive Streaming-Events
- SDK-Helfer wie
response.output_text
- Sie wurde für Entwickler konzipiert, die OpenAI-Modelle und integrierte Tools in ihre Apps einbinden möchten, ohne mehrere APIs oder externe Anbieter separat zu integrieren
- Wenn Daten bei OpenAI gespeichert werden, erleichtern Tracing- und Evaluierungsfunktionen die Bewertung der Agent-Leistung
- OpenAI verwendet Geschäftsdaten standardmäßig nicht für das Training von Modellen; das gilt auch dann, wenn Daten bei OpenAI gespeichert werden
- Sie steht ab heute allen Entwicklern zur Verfügung, ohne separate Zusatzkosten; Tokens und Tools werden zu den Standardtarifen auf der Preisseite abgerechnet
- Ein Einstiegsdokument steht im Responses API quickstart guide bereit
Beziehung zu bestehenden APIs
- Die Chat Completions API bleibt die am weitesten verbreitete API von OpenAI und wird weiterhin unterstützt
- Entwickler, die keine integrierten Tools benötigen, können sie weiterhin verwenden
- Neue Modelle für Funktionen, die nicht auf integrierte Tools oder mehrere Modellaufrufe angewiesen sind, werden weiterhin auch für Chat Completions veröffentlicht
- Die Responses API ist eine Obermenge der Chat Completions API und bietet dieselbe Leistung, daher wird sie für neue Integrationen empfohlen
- Beta-Feedback zur Assistants API ist in die Responses API eingeflossen, wodurch sie flexibler, schneller und einfacher nutzbar wird
- Die Herstellung vollständiger Funktionsgleichheit zwischen Assistants API und Responses API ist im Gange, einschließlich assistant-ähnlicher Objekte, thread-ähnlicher Objekte und des Code-Interpreter-Tools
- Sobald die Funktionsgleichheit erreicht ist, soll die Einstellung der Assistants API offiziell angekündigt werden
- Der angestrebte Endzeitpunkt ist Mitte 2026
- Mit der offiziellen Deprecation-Ankündigung soll ein Migrationsleitfaden bereitgestellt werden, der Datenaufbewahrung und die Migration von Anwendungen ermöglicht
- Bis zur offiziellen Deprecation-Ankündigung werden auch für die Assistants API weiterhin neue Modelle bereitgestellt
- OpenAI positioniert die Responses API als zukünftige Richtung für den Aufbau von Agenten bei OpenAI
Integrierte Tools der Responses API
-
Websuche
- Entwickler können schnelle und aktuelle Antworten aus dem Web zusammen mit klaren Quellenangaben erhalten
- In der Responses API wird Websuche bei Verwendung von
gpt-4oundgpt-4o-minials Tool bereitgestellt und kann zusammen mit anderen Tools oder Function Calling genutzt werden - Erste Testeinsätze zeigten Anwendungsfälle in Apps, die aktuelle Webinformationen benötigen, etwa Shopping-Assistenten, Research-Agenten und Agenten für Reisebuchungen
- Hebbia unterstützt mit dem Websuche-Tool Vermögensverwalter, Private-Equity- und Kreditfirmen sowie Juristen dabei, schnell umsetzbare Erkenntnisse aus großen öffentlichen und privaten Datensätzen zu gewinnen
- Die Websuche der API basiert auf denselben Modellen wie ChatGPT search
- In SimpleQA erreichte GPT‑4o search preview 90 % und GPT‑4o mini search preview 88 % Genauigkeit
- Websuch-Antworten der API enthalten Quelllinks wie Nachrichtenartikel und Blogbeiträge
- Websites oder Publisher können sich dafür entscheiden, in der API-Websuche angezeigt zu werden
- Das Websuche-Tool ist in der Responses API als Preview für alle Entwickler verfügbar
- In der Chat Completions API kann direkt über
gpt-4o-search-previewundgpt-4o-mini-search-previewauf Suchmodelle zugegriffen werden - Die Preise beginnen bei 30 US-Dollar pro 1.000 Abfragen für GPT‑4o search und 25 US-Dollar pro 1.000 Abfragen für 4o-mini search
-
Dateisuche
- Mit dem verbesserten Tool file search lassen sich relevante Informationen in umfangreichen Dokumenten leicht durchsuchen
- Unterstützt werden mehrere Dateiformate, Query-Optimierung, Metadatenfilterung und benutzerdefiniertes Reranking
- In der Responses API ist die Integration mit wenigen Zeilen Code möglich
- Zu den Anwendungsfällen gehören:
- Kundensupport-Agenten greifen auf FAQs zu
- Rechtsassistenten verweisen für qualifizierte Fachkräfte schnell auf frühere Fälle
- Coding-Agenten schlagen technische Dokumentation nach
- Navan nutzt file search in seinem KI-gestützten Reiseagenten, um schnell präzise Antworten aus Wissensdokumenten wie Reiserichtlinien von Unternehmen bereitzustellen
- Mit integrierter Query-Optimierung und Reranking lassen sich RAG-Pipelines ohne zusätzliches Tuning oder Setup aufbauen
- Mit dedizierten Vektorspeichern pro Benutzergruppe können Antworten an Kontoeinstellungen und Benutzerrollen angepasst werden
- file search steht in der Responses API allen Entwicklern zur Verfügung
- Die nutzungsbasierte Preisgestaltung beträgt 2,50 US-Dollar pro 1.000 Abfragen; Dateispeicher kostet 0,10 US-Dollar pro GB und Tag, das erste 1 GB ist kostenlos
- Es wird auch weiterhin in der Assistants API angeboten
- Dem Vector Store API-Objekt wurde ein neuer Search-Endpunkt hinzugefügt, über den Daten für andere Anwendungen und APIs direkt abgefragt werden können
-
Computernutzung
- Das Tool computer use ist eine Funktion der Responses API zum Erstellen von Agenten, die Computeraufgaben ausführen
- Das Tool wird vom Computer-Using Agent(CUA)-Modell angetrieben, das Operator ermöglicht hat
- Das Research-Preview-Modell erzielte folgende Benchmark-Ergebnisse
- OSWorld: 38,1 % bei allgemeinen Computer-Use-Aufgaben
- WebArena: 58,1 %
- WebVoyager: 87 % bei webbasierten Interaktionen
- Das integrierte Tool computer use erfasst vom Modell erzeugte Maus- und Tastaturaktionen
- Entwickler können diese Aktionen in Befehle umwandeln, die in ihrer eigenen Umgebung ausführbar sind, um Computeraufgaben zu automatisieren
- Anwendungsfälle sind die Automatisierung browserbasierter Workflows wie Qualitätssicherung für Web-Apps oder Dateneingabe zwischen Legacy-Systemen
- Unify nutzt das Tool computer use in einem System zur Umsatzsteigerung, in dem Agenten Absichten erkennen, Accounts recherchieren und Käufer kontaktieren
- Auch Informationen, auf die per API nicht zugegriffen werden konnte, können von Agenten genutzt werden
- Beispielsweise kann ein Immobilienverwaltungsunternehmen über Online-Karten prüfen, ob ein Unternehmen seine Immobilienfläche erweitert hat
- Luminai integriert das Tool computer use in die Automatisierung komplexer operativer Workflows großer Unternehmen mit Legacy-Systemen ohne APIs und standardisierte Daten
- In einem Pilotprojekt bei einer großen Community-Service-Organisation wurden Antragsbearbeitung und Benutzerregistrierung innerhalb weniger Tage automatisiert
- Traditionelle RPA hätte dieselbe Aufgabe selbst nach monatelangen Versuchen nur schwer erreichen können
- Vor der Einführung von CUA in Operator wurden umfangreiche Sicherheitstests und Red-Teaming in drei Bereichen durchgeführt: Missbrauch, Modellfehler und Frontier-Risiken
- Um die Risiken zu adressieren, die dadurch entstehen, dass Operator-Funktionen über CUA in der API auf lokale Betriebssysteme ausgeweitet werden, wurden ebenfalls zusätzliche Sicherheitsbewertungen und Red-Teaming durchgeführt
- Auch Schutzmaßnahmen für Entwickler wurden ergänzt
- Sicherheitsprüfungen zur Abwehr von Prompt Injection
- Bestätigungsaufforderungen für sensible Aufgaben
- Tools zur Unterstützung von Umgebungsisolierung
- verbesserte Erkennung potenzieller Richtlinienverstöße
- Diese Schutzmaßnahmen senken das Risiko, aber das Modell kann insbesondere in Nicht-Browser-Umgebungen unbeabsichtigte Fehler machen
- Die OSWorld-Leistung von 38,1 % zeigt, dass bei der Automatisierung von Betriebssystemaufgaben noch keine hohe Zuverlässigkeit erreicht ist; in diesem Fall wird menschliche Aufsicht empfohlen
- Weitere Details zu den API-spezifischen Sicherheitsmaßnahmen finden sich in der aktualisierten system card
Agents SDK und Workflow-Orchestrierung
- Agenten benötigen neben Kernlogik und Tool-Zugriff auch Workflow-Orchestrierung
- Das neue Open-Source-Agents SDK vereinfacht die Orchestrierung von Multi-Agent-Workflows
- Es ist eine Verbesserung gegenüber dem im letzten Jahr veröffentlichten experimentellen SDK Swarm
- Zu den Hauptfunktionen gehören:
- Agents: leicht konfigurierbare LLMs mit klaren Anweisungen und integrierten Tools
- Handoffs: intelligente Übergabe der Kontrolle zwischen Agenten
- Guardrails: konfigurierbare Sicherheitsprüfungen zur Validierung von Eingaben und Ausgaben
- Tracing & Observability: visualisiert Agent-Ausführungen und unterstützt Debugging sowie Leistungsoptimierung
- Praktische Anwendungsfälle sind Automatisierung im Kundensupport, mehrstufige Recherche, Content-Erstellung, Code-Review und die Generierung von Vertriebskontakten
- Coinbase nutzte das Agents SDK, um AgentKit schnell zu prototypisieren und bereitzustellen, sodass KI-Agenten mit Krypto-Wallets und Onchain-Aktivitäten interagieren können
- Innerhalb weniger Stunden wurden benutzerdefinierte Aktionen aus dem Developer Platform SDK in einen vollständig funktionsfähigen Agenten integriert
- Die vereinfachte Architektur von AgentKit erleichtert das Hinzufügen neuer Agent-Aktionen
- Box entwickelte innerhalb weniger Tage einen Agenten mit Websuche und Agents SDK, der Suche, Abfragen und das Extrahieren von Erkenntnissen aus unstrukturierten Daten innerhalb von Box und aus öffentlichen Internetquellen ermöglicht
- Unternehmenskunden können nicht nur aktuelle Informationen abrufen, sondern auch interne proprietäre Daten unter Einhaltung interner Berechtigungen und Sicherheitsrichtlinien durchsuchen
- Beispielsweise kann ein Finanzdienstleister einen benutzerdefinierten Agenten erstellen, der interne Marktanalysen in Box mit Echtzeit-Nachrichten und Wirtschaftsdaten aus dem Web kombiniert
- Das Agents SDK funktioniert mit der Responses API und der Chat Completions API
- Es kann auch mit Modellen anderer Anbieter verwendet werden, sofern diese Chat-Completions-artige API-Endpunkte bereitstellen
- Es lässt sich sofort in Python-Codebasen integrieren; Unterstützung für Node.js soll in Kürze folgen
- OpenAI ließ sich beim Design des Agents SDK von der Arbeit an Pydantic, Griffe, MkDocs inspirieren
- OpenAI plant, das Agents SDK weiterhin als Open-Source-Framework auszubauen, damit die Community den Ansatz erweitern kann
Ausbau der Agentenplattform
- OpenAI geht davon aus, dass Agenten bald ein zentrales Element der Arbeitswelt werden und die Produktivität branchenübergreifend deutlich steigern
- Da die Nachfrage von Unternehmen steigt, KI für komplexe Aufgaben einzusetzen, konzentriert man sich darauf, Entwicklern und Unternehmen Bausteine bereitzustellen, mit denen sie autonome Systeme mit realer Wirkung schaffen können
- Die aktuelle Veröffentlichung ist ein erster Satz von Bausteinen, um den Aufbau, die Bereitstellung und die Skalierung vertrauenswürdiger und leistungsfähiger KI-Agenten zu erleichtern
- Mit der weiteren Entwicklung der Modellfähigkeiten hin zu stärker agentischen Systemen will OpenAI weiterhin in tiefere Integrationen über die gesamte API hinweg und in neue Tools investieren, die bei Bereitstellung, Evaluierung und Optimierung von produktionsreifen Agenten helfen
- Ziel ist es, eine nahtlose Plattformerfahrung bereitzustellen, um Agenten zu schaffen, die bei unterschiedlichsten Aufgaben in jeder Branche helfen können
1 Kommentare
Hacker-News-Kommentare
Ich bin mir nicht sicher, wie sehr solche API-Änderungen Entwicklern helfen, die OpenAI an ein echtes Produkt anbinden wollen.
Vendor-verwaltete Zustandsmaschinen für Konversationen, Nachrichten, Prompt-Übergabe usw. waren für meine Zwecke am Ende entweder unzureichend, machten zu viele Annahmen oder standen im Weg.
Am Ende nutze ich einfach die Chat Completions API mit aktivierter strukturierter Ausgabe und mache darin auch Tool-Nutzung, rekursive Dialoge, RAG usw. völlig ausreichend.
Ich sehe keinen Wert darin, das Zustandsmanagement meines „Agenten“ einem Drittanbieter zu überlassen; so etwas lokal zu halten gibt mir viel mehr Autonomie.
Im Kern geht es nur darum, irgendein String-Literal in eine Blackbox zu stecken und einen neuen String zurückzubekommen, möglichst in einem angeforderten Format wie JSON.
Wenn man sich darauf konzentriert, jedes Mal den passenden String zusammenzusetzen, verschwindet der Rest; es wird zu der Aufgabe, aus dem Business-Zustand in einer Datenbank einen hochstrukturierten String zu erzeugen.
Im Grunde ist das dasselbe wie serverseitiges Rendering einer Webseite mit PHP; der eigentliche Unterschied ist nur die Art der Bereitstellung.
Ich habe noch kein Agent-Framework gefunden, das mir auf einem simplen Aufruf zur strukturierten Generierung wirklich das ergänzt, was ich brauche.
Die meisten LLM-Anfragen sollten „Prompt rein, strukturierte Ausgabe raus“ sein, und das passt auch zur Unix-Philosophie: eine Sache gut machen.
Agent-Frameworks sind zu früh dran; sie sind nur eine Abstraktionsschicht über einem Bündel noch nicht verbreiteter Design Patterns.
Man sollte erst dann abstrahieren, wenn klar ist, dass alle das Rad neu erfinden. Bei Agenten gibt es aber kein Rad zu erfinden; es sind alles simple Sprachmodell-Aufrufe.
Ich sage oft: „Das Sprachmodell sollte der langweiligste Teil des Codes sein.“
Die meiste Zeit sollte man damit verbringen, echte Software und Tools zu bauen; das LLM sollte nur eine kleine Komponente der Software sein.
Agent-Frameworks machen die Präsenz des Sprachmodells in der Codebasis für meinen Geschmack viel zu groß.
Selbst OpenAIs function calling-Abstraktion halluziniert Parameter und Schemas, und JSON Schema selbst ist so umständlich, dass alles, was nur ein wenig komplexer als fünf sehr einfache Funktionsaufrufe ist, komplett auseinanderfällt.
Es wirkt, als würde man auf eine bereits kaputte Blackbox-Abstraktion noch mehr oben drauf stapeln, und für echte Anwendungen ist das wenig nützlich.
Es kann hilfreich sein, um kleine Proof-of-Concept-Apps schnell zu bauen.
Man muss naiv sein, um auf solchen APIs ein Unternehmen aufzubauen.
LLMs werden zur Commodity werden, und OpenAI wird zwangsläufig gegen dieses Schicksal ankämpfen müssen, um seine Bewertung und den weiterhin nötigen Investitionsumfang zu rechtfertigen.
Wenn man auf der Assistant API aufgebaut hat, sollte man den Wink verstehen und nicht einfach alles auf die Responses API umschreiben, sondern das eigene Produkt selbst besitzen.
Die heutigen LLMs packt man besser hinter eine Blackbox.
Grund ist die Passage: „Bei der Verwendung von Chat Completions ruft das Modell vor einer Antwort immer Informationen aus dem Web ab. Wenn Sie möchten, dass Modelle wie gpt-4o und gpt-4o-mini web_search_preview nur bei Bedarf als Tool aufrufen, wechseln Sie zur Responses API.“
Auf die neue Responses API zu portieren ist nicht trivial, und wir haben bereits Historie, RAG und alles, was für Assistenten nötig ist.
Ich habe mehrere Agenten nur mit function calling und strukturierter Ausgabe entwickelt und betreibe sie seit über einem Jahr in Produktion.
Früher hätte man das nicht einmal Agenten genannt.
Das hier scheint sich an Leute zu richten, die bereits Agent-Frameworks zusammen mit der OpenAI API nutzen.
Es gibt einen guten Twitter-Thread des Designers der neuen API, der die Hintergründe mehrerer Designentscheidungen erklärt: https://twitter.com/athyuttamre/status/1899541471532867821
Für alle, die nicht bei Twitter eingeloggt sind, gibt es auch einen alternativen Link: https://nitter.net/athyuttamre/status/1899541471532867821
Diese Versuche mit AI-Agenten scheinen mir am Kern vorbeizugehen.
Denn sie versuchen, Menschen in bestehenden Systemen zu ersetzen, statt neue Wege zu schaffen.
Wirtschaft und Leben, letztlich alles, dreht sich um Interaktionen zwischen Menschen; insofern ist das grundsätzlich kurzsichtig.
Der heutige Ansatz bei AI-Agenten wirkt wie eine Variante des Witzes: „Eine KI bläht einen Satz zu einer langen, plausibel klingenden E-Mail auf, und die KI auf Empfängerseite fasst diese lange E-Mail wieder zu einem Satz zusammen.“
Ich verstehe den Nutzen, Aufgaben in bestehenden Systemen zu automatisieren, aber die eigentliche Chance liegt darin, den Großteil dieser bestehenden Systeme zu entfernen.
Menschen sind gar nicht so schlecht.
Ich frage mich, ob es wirklich der Weg nach vorn ist, mit KI UIs für Menschen zu bauen und dann wieder KI diese UIs bedienen zu lassen.
Wie viele Körbe benutzt du, die aus per Hand gebrochenen Zweigen geflochten wurden?
Die Geschichte zeigt, dass automatisiert wird, was automatisiert werden kann, und dass Dinge billiger oder schneller gemacht werden, wenn das möglich ist.
Zum Beispiel als unterstützende User Experience im B2B-SaaS-Ökosystem, mit der Power-User in einer Organisation Kundeneinstellungen und Projektmanagement-Aufgaben makroisieren können.
Wenn Abstraktion, Kontext und Nutzergruppe gut eingegrenzt sind, kann Tool-Nutzung ziemlich stabil sein.
Auffällig fehlend: Model Context Protocol
https://www.anthropic.com/news/model-context-protocol
Agenten brauchen immer irgendeine Form von Kommunikationsprotokoll, und die Welt der agentischen Frameworks ist ein Meer aus Logos; ohne offene Standards wird es schwierig
Ich bin derzeit bei Comet, habe selbst an einer MCP-Implementierung gearbeitet und auch zum Agent SDK beigetragen, in Form nativer Integration und Verbesserungen der Testsuite
https://github.com/comet-ml/opik-mcp
https://github.com/openai/openai-agents-python/pull/91
Die jüngste Integration haben wir direkt am ersten Tag veröffentlicht
https://www.comet.com/docs/opik/tracing/integrations/openai_...
Meiner Ansicht nach geht es OpenAI im Kern darum, Entwicklern durch einfach nutzbare Komponenten Einfachheit zu bieten
Zu Strategie oder Preisen sage ich nichts, aber aus Entwicklersicht wirkte der einfache, modulare Ansatz des SDK und der Verzicht auf Ballast beim ersten Blick erfrischend
Das ist nicht allgemein gedacht, sondern dafür, mcp.run-Tool-Calls mit OpenAI-Modellen zu nutzen
Trotzdem ist es für Entwickler so ziemlich einer der feindseligsten Schritte, MCP nicht direkt zu unterstützen, und bei OpenAI überrascht das nicht
Wenn es ergänzt würde, wäre das sehr gut
Auf die Frage „Unterstützt das Agents SDK MCP-Verbindungen? Kann man einem bestimmten Agenten über eine MCP-Client-Server-Verbindung einfach Tools geben?“ lautet die Antwort: „Da man beliebige Tools definieren kann, kann man MCP-Tools per Function Calling implementieren“
Kurz gesagt: Ein wenig Klempnerarbeit muss man selbst erledigen
Zugehöriges Issue: https://github.com/openai/openai-agents-python/issues/23
Ich bin swyx
Ich hatte Gelegenheit, mir die neuen APIs insgesamt vorab mit dem API/DX-Team anzusehen und häufig gestellte Fragen zu stellen
https://latent.space/p/openai-agents-platform
Der interessante Kernpunkt ist, ob man die Responses API wie eine Datenbank missbrauchen kann, da Antworten jetzt standardmäßig kostenlos gespeichert werden
Es gibt auch Fragen, die HN-Leuten gefallen dürften
Hyperparameter der Websuche, also wie man Tiefe und Breite der Suche steuert, wenn man DIY Deep Research baut
Wann sollte man eigenes RAG bauen, jetzt wo OAI RAG und Re-Ranking als Teil der Responses API nativ anbietet?
Persönlich finde ich, dass jemand die RAG-Performance der Files API benchmarken sollte. Der Eindruck in der Community scheint seit dem ersten Launch der Assistants API kaum aktualisiert worden zu sein
Die Unterschiede zwischen Agents SDK und OAI Swarm sind grob gesagt Typen, Tracing und austauschbare LLMs
Ich frage mich auch, ob
search-preview- undcomputer-use-preview-Fine-Tuning in GPT5 zusammengeführt werden0 - https://ai.pydantic.dev/
Einer der Hauptgründe, solche KI-Suchtools selbst zu bauen, ist, dass man Tiefe und Breite vollständig kontrollieren und auch die Loader für die gewünschten Daten oder Websites anpassen kann
Die aktuelle Websuche ist nicht transparent darin, welche Websites keinen Volltext haben und bei welchen nur Snippets verwendet werden
Computer Use und Websuche zusammen zu haben, ist definitiv mächtig. Im Kern ist es so etwas wie OpenAIs Deep Research
In der Präsentation wurden keine Preise genannt
vermutlich, weil man wusste, dass es sehr teuer sein würde
Websuche [0]: GPT‑4o search und 4o-mini search kosten jeweils 30 bzw. 25 US-Dollar pro 1.000 Abfragen
Dateisuche [1]: 2,50 US-Dollar pro 1.000 Abfragen, Dateispeicher 0,10 US-Dollar/GB/Tag, das erste GB ist kostenlos
Computer-Use-Tool (Modell computer-use-preview) [2]: 3 US-Dollar pro 1 Mio. Input-Tokens, 12 US-Dollar pro 1 Mio. Output-Tokens
[0] https://platform.openai.com/docs/pricing#web-search
[1] https://platform.openai.com/docs/pricing#built-in-tools
[2] https://platform.openai.com/docs/pricing#latest-models
Mir ist nicht klar, inwiefern diese API besser sein soll als https://www.anthropic.com/news/model-context-protocol
Die Motivation scheint eher „Wie verdienen wir mehr Geld?“ gewesen zu sein als „Wie werden wir für Nutzer nützlicher?“
Gefällt mir, ein mutiger Schritt
Wenn die langsamen Leute bei Google endlich aufholen, könnte es für Google schon zu spät sein
Ich habe auch ein Script geschrieben, das das Web durchsucht und ziemlich gut funktioniert. Es nutzt das vercel ai sdk [1]
[0] - https://brave.com/search/api/
[1] - https://gist.github.com/bramses/41e90b27d156590154bcefd4119f...
Ich habe selbst eine deutlich einfachere und leistungsfähigere Version der Responses API gebaut, die mit allen LLM-Anbietern funktioniert
https://github.com/Anilturaga/aiide
Schön anzusehen, sieht wirklich gut aus
Es gibt die Formulierung: „Wir planen, die Einstellung der Assistant API offiziell anzukündigen; angepeilter Abschaltzeitpunkt ist Mitte 2026“
Die neue Responses API ist ein Schritt in die richtige Richtung, einschließlich eingebauter „handoff“-Funktion
Für agentische Anwendungsfälle wirkt sie allerdings noch etwas eingeschränkt, und es fehlt an offizieller Guardrail- und Zustandsmaschinen-Logik
Sie sagten: „Unser Ziel ist es, eine nahtlose Plattform-Erfahrung zu bieten, mit der Entwickler Agents bauen können“; spannend, wie der Wechsel auf diese Plattform aussehen wird
Ich vermute, dass wir in ein paar Monaten graphbasierte Kontrollflüsse sehen werden
Schon jetzt gibt es unzählige Open-Source-Lösungen, aber die meisten sind unzureichend oder fügen unnötige Intransparenz und Komplexität hinzu
Mit einer Kombination aus Tool-Aufrufen und JSON-Antworten konnte man zwar agentische Abläufe bauen, aber es fehlt noch die übergeordnete Komponente, die bisher niemand richtig gelöst hat
Die Fortschritte bei Computer Use, die hier erwähnt werden, sind beeindruckend; da frage ich mich, ob es schon reif genug ist, um es für Usability-Tests einzusetzen
Wenn eine UI für eine KI im Allgemeinen schwer zu navigieren ist, ist sie dann wahrscheinlich auch für Menschen relativ schwierig und sollte das als Signal gelten, sie in irgendeiner Weise zu vereinfachen oder zu verbessern?
Die Art, wie ein LLM mit einer UI interagiert, unterscheidet sich stark davon, wie Menschen eine UI benutzen
Das verlinkte Agents SDK liefert 404
Zur Info: MindRoot hat mit der task API etwas, das Teilen von Responses und File Search ähnelt: https://github.com/runvnc/mindroot/blob/main/api.md
Das lässt sich mit dem query_kb-Tool des mr_kb-Plugins kombinieren und erlaubt die Suche in mehreren KBs, könnte also tatsächlich besser sein als File Search
Wer mir bei meinem Programm helfen, Plugins bauen oder PRs schicken möchte, kann mich gern über GitHub, E-Mail oder Discord/Telegram (runvnc) kontaktieren
Vielleicht liegt es daran, dass ich eingeloggt bin