OpenAI Agents SDK: co potrafi i kiedy się sprawdza

OpenAI Agents SDK to lekki framework open source (licencja MIT) do budowania agentów AI z celowo niewielką liczbą abstrakcji. Jest dostępne w Pythonie i TypeScripcie, uchodzi za gotowego do produkcji następcę eksperymentu Swarm i łączy pięć podstawowych prymitywów: Agents, Handoffs, Guardrails, Sessions i Tracing. Od aktualizacji z 15 kwietnia 2026 r. dochodzą do tego natywne wykonywanie w sandboksie, harness natywny dla modelu oraz obsługa MCP i AGENTS.md (stan na 2026 r.).

• Czym jest: framework agentowy od OpenAI o niskim poziomie abstrakcji, po raz pierwszy opublikowany 11 marca 2025 r., obecnie w wersji 0.14.x lub nowszej (stan na 04/2026).
• Do czego pasuje: wdrożenia skupione na GPT, szybka iteracja i najkrótszy czas do pierwszego dema, łącznie z wizualnym Agent Builderem z AgentKit.
• Gdzie są granice: API nadal w wersji v0.x, mniej dojrzałe wzorce wieloagentowe niż w LangGraph i wyraźne ciążenie w stronę modeli OpenAI.

Podstawowe prymitywy w skrócie

Projekt opiera się na zasadzie „minimal abstractions”: zamiast ciężkiego modelu grafowego czy modelu crew masz garść klocków, które łatwo ze sobą łączyć.

• Agents: jednostka złożona z instrukcji, narzędzi i modelu. Narzędzia obejmują dostęp do plików i powłoki, apply-patch, a od kwietnia 2026 r. także wykonywanie w sandboksie.
• Handoffs: agent przekazuje rozmowę innemu, wyspecjalizowanemu agentowi. To centralny wzorzec dla przepływów wieloagentowych. Alternatywnie możesz podłączyć agentów jako narzędzia („Agents as Tools”), jeśli agent wywołujący ma zachować kontrolę.
• Guardrails: warstwa walidacji i bezpieczeństwa, która sprawdza dane wejściowe i wyjściowe, zanim zostaną dalej przetworzone.
• Sessions: konfigurowalna pamięć krótko- i długoterminowa; aktualizacja z kwietnia 2026 r. dodała pamięć i snapshoty.
• Tracing: wbudowana obserwowalność przez OpenAI Traces UI, uzupełniona o eksport do OpenTelemetry, np. do Logfire lub AgentOps.

Te pięć prymitywów pokrywa cztery z sześciu elementów, które tworzą pełnoprawny framework agentowy (abstrakcja agenta, warstwa narzędzi, zarządzanie stanem, orkiestracja), i uzupełnia je o obserwowalność oraz hooki produkcyjne.

Od eksperymentu Swarm do produkcyjnego SDK

Swarm był wczesnym, celowo eksperymentalnym podejściem OpenAI do systemów wieloagentowych, bez ambicji produkcyjnych i bez oficjalnego wsparcia. Agents SDK przejmuje jego główne idee, przede wszystkim lekkie handoffy między agentami, i przenosi je do wspieranego frameworka. Ścieżka dojrzewania jest widoczna od premiery: na DevDay 6 października 2025 r. OpenAI zaprezentowało wraz z AgentKit wizualny Agent Builder, Connector Registry i ChatKit. Aktualizacja z 15 kwietnia 2026 r. przyniosła następnie wykonywanie w sandboksie, harness natywny dla modelu do długotrwałych zadań oraz pełnoprawną obsługę Model Context Protocol (MCP) i konwencji repozytorium AGENTS.md.

Ważne przy planowaniu: OpenAI ogłosiło wycofanie starszego Assistants API w sierpniu 2025 r. Lista wycofywanych funkcji OpenAI podaje jako datę wyłączenia 26 sierpnia 2026 r. Nowe projekty powstają od razu na bazie Agents SDK i Responses API, a istniejące wdrożenia oparte na Assistants trzeba przenieść na Responses API i Conversations API (stan na październik 2026).

Mocne strony w ekosystemie OpenAI

Największe korzyści pojawiają się, gdy i tak pracujesz w stacku OpenAI:

• Natywna optymalizacja pod GPT: SDK jest ściśle dopasowane do modeli OpenAI, dzięki czemu wywoływanie narzędzi i rozumowanie modeli da się wykorzystać bezpośrednio.
• Najkrótszy czas do dema: mało abstrakcji oznacza mało boilerplate'u. Działający agent powstaje szybko.
• Warstwa wizualna dzięki AgentKit: Agent Builder obniża próg wejścia także dla mniej technicznych interesariuszy.
• Otwarte protokoły: od kwietnia 2026 r. MCP i AGENTS.md są obsługiwane natywnie, co standaryzuje podłączanie narzędzi i konwencje repozytoriów.
• Zasięg dostawców (z gwiazdką): SDK można według OpenAI uruchamiać z ponad 100 LLM przez endpointy zgodne z Chat Completions. To jednak deklaracja producenta, a w praktyce wszystko zależy od zgodności konkretnego endpointu.

Produkcyjnie z SDK korzystają m.in. Ramp, Bain & Company, Canva i LY Corporation.

Ograniczenia i uzależnienie od dostawcy

Minimalizm ma też drugą stronę, którą trzeba jasno nazwać:

• Ciążenie w stronę OpenAI: nawet jeśli SDK jest open source, API modeli pozostaje zamknięte. Natywna optymalizacja de facto ciągnie projekty w stronę GPT.
• Wciąż v0.x: API nie jest ostateczne; możliwe są zmiany łamiące kompatybilność.
• Mniej dojrzałe wzorce wieloagentowe: przy złożonej, długotrwałej orkiestracji podlegającej audytowi bardziej niezawodne są LangGraph z modelem grafowym i LangSmith albo Microsoft Agent Framework.
• Przymusowa migracja z Assistants API: Assistants API zostało wycofane, a termin jego wyłączenia przypadł na 26 sierpnia 2026 r. Istniejące wdrożenia trzeba przenieść na Responses API i Conversations API.
• Rezydencja danych w Europie: bez wyboru regionu OpenAI nie gwarantuje, gdzie przetwarzane są zapytania do API. Modele OpenAI z rezydencją danych w UE możesz wykorzystać na dwa sposoby: przez europejski region API OpenAI (przechowywanie i przetwarzanie w EOG i w Szwajcarii, tylko po zatwierdzeniu przez OpenAI) albo przez Azure OpenAI z wdrożeniem w regionach UE (np. Frankfurt, West Europe, Sweden Central). Dyskusja o CLOUD Act w przypadku amerykańskich dostawców pozostaje aktualna. Te informacje mają charakter poglądowy i nie zastępują porady prawnej.

Porównanie z alternatywami

Logikę decyzji da się ująć krótko: tylko GPT i najszybsza droga do dema przemawiają za OpenAI Agents SDK. Obowiązek audytu oraz długotrwałe obciążenia z rozbudowanym stanem przemawiają za LangGraph lub Microsoft Agent Framework. Wymóg .NET prowadzi do Microsoft Agent Framework, a strategiczny wybór Anthropic do Claude Agent SDK.

Krótki przykład: triaż z handoffem

Typowy wzorzec to agent triażowy, który przekazuje przychodzące zapytania wyspecjalizowanym agentom. W pseudokodzie:

```python
from agents import Agent, Runner

billing_agent = Agent(
name="Billing",
instructions="Odpowiadaj na pytania dotyczące faktur i płatności."
)

tech_agent = Agent(
name="Technika",
instructions="Rozwiązuj problemy techniczne związane z produktem."
)

triage = Agent(
name="Triage",
instructions="Przekaż zapytanie do odpowiedniego agenta.",
handoffs=[billing_agent, tech_agent]
)

result = Runner.run_sync(triage, "Za moją fakturę pobrano opłatę dwa razy.")
print(result.final_output)
```

Agent triażowy rozpoznaje temat rozliczeń i przez handoff przekazuje sprawę agentowi Billing, który odpowiada z własnym kontekstem. Guardrails mogą wcześniej sprawdzić dane wejściowe, Sessions przechowują historię rozmowy, a każdy krok automatycznie trafia do tracingu. W praktyce oznacza to, że zamiast utrzymywać jeden monolityczny prompt ze wszystkimi przypadkami, rozdzielasz logikę między wyspecjalizowanych agentów. Zmniejsza to złożoność promptów i pozwala prześledzić źródła błędów w interfejsie Traces.

Dla agencji i decydentów B2B

OpenAI Agents SDK to narzędzie z wyboru dla agencji marketingowych i zespołów B2B w Europie, gdy liczą się szybkie prototypy oparte na GPT i krótkie cykle iteracji, np. przy triażu zgłoszeń supportu, pipeline'ach treści czy wewnętrznych systemach asystujących. Jeśli w dłuższej perspektywie stawiasz na suwerenność, audytowalność lub niezależność od dostawcy, świadomie uwzględnij ciążenie w stronę OpenAI, zabezpiecz rezydencję danych w UE przez europejski region API OpenAI lub przez Azure OpenAI i utrzymuj prompty, narzędzia oraz zestawy ewaluacyjne niezależne od frameworka, aby później bez tarcia przejść na LangGraph lub inną platformę. Blck Alpaca wspiera taki wybór architektury i narzędzi w ramach integracji agentów AI, od pierwszego studium wykonalności aż po produkcyjne działanie zgodne z RODO.