OpenAI Agents SDK чи Google ADK: як обрати agent framework

OpenAI Agents SDK варто перевіряти першим, коли команда хоче компактний agent loop із tools, handoffs або agents-as-tools, sessions, approval interruptions і вбудованим tracing, а основний шлях працює через OpenAI Responses API. Google ADK варто перевіряти першим, коли потрібен ширший framework surface: LLM-агенти, явні graph або multi-agent workflows, session/event/state model, evaluation tooling і готові шляхи deployment у Google Cloud. Обидва frameworks допускають інші моделі; жодна adapter-обіцянка не гарантує однакової поведінки tools, structured output, usage чи tracing.

Рішення починається з task contract: хто володіє control flow, скільки живе run, де зберігається authoritative state, які side effects дозволені, як людина призупиняє й відновлює дію, який deployment target уже підтримує команда і як буде доведено якість. Для одного короткого assistant loop повний graph або multi-agent topology лише додає failure surface. Для процесу з явними branches, shared state, кількома runtime мовами й platform deployment вузький model-led runner може вимагати забагато власної інфраструктури.

OpenAI Agents SDK визначає Agent, Runner, function/hosted tools, handoffs, agents-as-tools, guardrails, sessions, RunState і tracing. Runner виконує model → tool → observation loop до фінального output, interruption або ліміту. Поточна офіційна документація також описує serializable RunState для approval pause/resume та інтеграції з durable orchestrators для довгих workflow. Це корисно відділяє SDK loop від зовнішнього власника довговічності.

Google ADK визначає LLM agents, graph workflows, multi-agent patterns, tools, callbacks/plugins, sessions, events, state, memory, artifacts, evaluation та deployment surfaces. У поточній ADK 2.0 документації graph workflows є явним способом поєднати deterministic execution з model reasoning; ADK також має Python, TypeScript, Go, Java і Kotlin реалізації. Порівнюйте лише потрібну вам мову й стабільний capability slice: загальна наявність функції в одному SDK не означає паритет у кожній мові або версії.

Для bounded conversational або task agent з кількома tools, delegation і коротким approval Agents SDK дає прямий baseline. Handoff змінює активного агента, agent-as-tool залишає manager власником відповіді, а tool approval може повернути interruption у зовнішній application layer. Якщо команда вже використовує OpenAI models, Responses API і trace surface, інтеграційний шлях коротший — але identity, policy, secrets, domain database та deployment усе одно належать застосунку.

Для workflow, де topology є частиною продуктового дизайну, ADK пропонує явні graph routes та multi-agent patterns поруч із session/event/state моделлю. Це привабливо, коли команда хоче мати один framework vocabulary від local dev UI до evaluation і Google Cloud deployment або підтримує кілька runtime мов. Ціна — більша площа конфігурації, lifecycle semantics і platform-specific перевірок; не кожному agent потрібні graph, artifacts, memory та managed runtime одночасно.

Нейтральний application workflow може бути правильнішим за обидва. Якщо кроки deterministic, правила стабільні, а модель лише класифікує або синтезує, залиште retries, queues і state у звичайному workflow engine. Agent framework отримує вузький typed task і повертає candidate result. Так framework не стає неявною системою обліку замовлень, approvals або платежів.

• Короткий model-led loop, OpenAI-first tools і handoffs → почніть з Agents SDK.
• Явний graph/multi-agent workflow, ADK session model або Google Cloud path → почніть з ADK.
• Кілька мов → перевірте capability parity на потрібних SDK, а не лише список логотипів.
• Provider portability → replay однакових tool, output і error cases через реальні adapters.
• Deterministic process → тримайте business lifecycle поза agent framework.

Conversation history, workflow state і business state — різні речі. Sessions в Agents SDK можуть автоматично зберігати conversation history; RunState серіалізує paused approval flow. ADK session містить event history і state, а memory та artifacts мають окремі ролі. У жодному випадку не зберігайте право на refund, approval status або inventory reservation лише як текст у conversation. Authoritative domain system має перевіряти precondition перед кожною дією.

Resume після crash небезпечний біля side effect. Якщо tool створив invoice, але runtime не записав наступний event, повторний запуск може створити дубль. Потрібні idempotency key, authoritative read-after-write, bounded retry і reconciliation незалежно від SDK. Версіонуйте agent config, tool schema, state/event schema та model route; incompatible paused run або session переходить у migration/review lane, а не тихо продовжується новим кодом.

Agents SDK дозволяє tools позначити потребу approval, серіалізувати RunState і продовжити run після approve або reject. ADK має human-input та action-confirmation surfaces у workflow/tool моделі. Ці primitives переносять рішення, але не визначають, хто має юридичне чи бізнесове право його прийняти. Application policy має встановити authenticated actor, tenant, resource, action, risk tier, expiry і segregation of duties.

Approval прив’язуйте до exact payload hash, tool version і resource precondition. Після паузи повторно перевіряйте identity, scopes і актуальний стан: учорашнє схвалення чернетки не дозволяє сьогодні відправити змінений платіж. Модель може запропонувати route, agent або tool, але не розширює власні permissions. Для destructive action reviewer бачить target, diff, credential owner, незворотні наслідки та rollback/compensation.

Agents SDK має built-in traces для generations, tools, handoffs, guardrails і custom spans та окремі testing utilities; tracing конфігурується або вимикається, а sensitive-data policy треба встановити до rollout. ADK має evaluation criteria, user/environment simulation, custom metrics, logging, metrics і traces. Наявність меню evaluation не створює ваш acceptance contract: потрібні representative tasks, critical slices, deterministic graders, policy checks і verified business outcomes.

Нормалізуйте власний RunEvent envelope: task ID, framework/version, model/provider, agent/node, tool fingerprint, policy verdict, latency, usage, interruption, terminal reason і verified outcome. Сирі prompts, secrets і повні tool results не мають автоматично потрапляти у trace vendor. Перевірте redaction, retention, tenant isolation, export і поведінку при telemetry outage; execution не повинен отримувати ширші права лише тому, що trace backend недоступний.

Візьміть 30–50 репрезентативних tasks як engineering corpus, а не статистичну обіцянку. Реалізуйте однакові ToolContract, PolicyDecision, TerminalResult і RunEvent навколо мінімального Agents SDK та ADK prototype. Де можливо використовуйте ті самі моделі; окремо проведіть native-path test, бо framework цінність часто проявляється саме у first-party integrations. Не додавайте graph або multi-agent pattern, якщо production requirement цього не має.

Інжектуйте malformed tool output, timeout до і після side effect, revoked permission, expired approval, provider rate limit, process restart, session corruption, prompt injection і telemetry outage. Вимірюйте verified task success, prohibited-action rate, recovery/reconciliation, schema validity, reviewer effort, latency і full cost per accepted outcome. Framework проходить gate лише якщо critical failures fail closed, in-flight work можна пояснити, а operator здатен відновити або завершити run без ручного редагування прихованого state.

Exit drill переносить один representative workflow через внутрішні contracts або повертає його на звичайний workflow engine. Не будуйте універсальний abstraction layer наперед: ізолюйте identity, domain state, tool policy й event envelope, а framework-specific orchestration лишайте видимим. Rollback зупиняє нові runs, quarantines incompatible sessions, звіряє side effects і повертає попередню pinned version.

• До prototype → task, authority, state, telemetry та terminal contracts.
• Під час prototype → однакові tools, eval slices і failure injection.
• Перед pilot → redaction, kill switch, session migration і reconciliation drill.
• Перед write access → payload-bound approval та idempotent side effects.
• Перед scale → cost per verified outcome, operator load і tested exit path.