Изучите прямой API до агентного framework
Соблазн начать с фреймворка велик - он обещает "агента из коробки". Но прямой API показывает реальный протокол: как именно устроены tool calling и state. Фреймворк экономит код, когда нужны sessions, tracing, handoffs и human in the loop; он не отменяет проектирование прав, tool schemas и evals. Поэтому понимать стоит сначала протокол, а брать фреймворк - осознанно.
Выбор удобно свести к трём вариантам, у каждого своя цена.
Выбор · Преимущество · Цена · Когда брать
- Прямой API - Прозрачный цикл, полный контроль, простая переносимость; Вы сами пишете state, loop, tracing; Один агент, 4-10 tools, важен multi-provider
- OpenAI Agents SDK - Tools, sessions, tracing, handoffs, approvals; Связь с семантикой SDK; Сложная OpenAI-native система
- Anthropic Tool Runner - Автоматический tool loop и типизация; Поверхность beta; После проверки beta-ограничений на вашем workload
- Google ADK - Agents, workflow agents, sessions, evals; Отдельная runtime-модель; Google-native оркестрация или multi-agent
Логика во всех строках одна. Прямой API даёт прозрачный цикл, полный контроль и простую переносимость между провайдерами - ценой того, что state, loop и tracing вы пишете сами; это оптимально для одного агента с несколькими tools, где важен multi-provider. OpenAI Agents SDK даёт tools, sessions, tracing, handoffs и approvals - ценой привязки к семантике SDK. Anthropic Tool Runner даёт автоматический tool loop и типизацию - ценой того, что это beta.
И главная оговорка, ради которой вообще стоит держать прямой API в голове.
Framework не является стандартом. Даже если три продукта используют слово "agent", их состояние, lifecycle, tracing и tool protocol различаются. Общим делайте собственный бизнес-контракт, а не все внутренние объекты SDK.
Именно поэтому книга строит агента на едином контракте поверх прямых API, а фреймворки показывает как опцию. Дальше - готовим проект, в котором этот контракт будет жить.