ADK Go 1.0: релиз фреймворка для AI-агентов на Go с OpenTelemetry, HITL и мультиагентной архитектурой
ADK Go 1.0 уже здесь
AI-агенты, если уж говорить без прикрас, стремительно вырастают из набора экспериментальных скриптов в полноценные production-сервисы. А это уже совсем другой разговор: тут нужны наблюдаемость, управляемость, безопасность и внятная архитектура AI-агентов, а не только «оно вроде работает у меня локально».
И вот на этом фоне Google выпускает Agent Development Kit for Go 1.0. Релиз, прямо скажем, не косметический. ADK Go развивает уже знакомую модель разработки и даёт инструменты для построения серьёзных мультиагентных систем: от последовательных и параллельных сценариев с SequentialAgents и ParallelAgents до циклических, итеративных процессов на базе LoopAgents.
Что нового в ADK Go 1.0? Коротко — вот самое важное:
- нативная интеграция с OpenTelemetry для глубокой трассировки и наблюдаемости;
- Plugin System для расширения поведения агента без захламления основной логики;
- механизмы подтверждения действий человеком для чувствительных операций;
- описание агентов через YAML, чтобы быстрее менять конфигурацию и не трогать лишний раз код.
И да, это уже выглядит как шаг от «игрушек» к промышленной разработке AI-агентов и автоматизации. Не на словах, а по делу.
Ссылка на видео YouTube (видно только при отключенном JS)
OpenTelemetry: когда агент перестаёт быть чёрным ящиком
Одна из самых неприятных вещей в агентных системах — их недетерминированность. Агент ошибся. Хорошо. Но где именно всё поехало? Инструмент вернул мусор? Модель «догадалась» не туда? Внутренний вызов API отработал криво? Пока этого не видно, отладка превращается в гадание на кофейной гуще.
В ADK Go 1.0 появилась встроенная интеграция с OpenTelemetry (OTel). Подключаете TraceProvider — и дальше вызовы модели, обращения к инструментам и циклы исполнения начинают формировать структурированные traces и spans. То есть появляется нормальная наблюдаемость, а не «ну, кажется, агент где-то тут свернул не туда».
Для команд, которые строят корпоративные AI-решения, это особенно важно: без трассировки сложно говорить и про эксплуатацию, и про аудит, и про безопасность AI-агентов. В общем, штука совсем не декоративная.
// OTel Initialization in ADK Go
telemetryProviders, err := telemetry.New(ctx, telemetry.WithOtelToCloud(true),
)
if err != nil {
log.Fatal(err)
}
defer telemetryProviders.Shutdown(ctx)
// Register as global OTel providers
telemetryProviders.SetGlobalOtelProviders()
// Initialize the runner with Telemetry support
r, _ := runner.New(runner.Config{
Agent: myAgent,
Telemetry: telemetry.NewOTel(tp),
})На практике это даёт возможность видеть ход выполнения агента рядом с привычными метриками приложения — например, в Cloud Trace. Удобно. И, честно говоря, давно пора.
Plugin System: расширяемость без лишнего шума в коде
Есть старая инженерная боль: как добавить логирование, проверки, ретраи и прочие сквозные механики так, чтобы основной код агента не превратился в спутанный клубок? В ADK Go 1.0 на это отвечает новая Plugin System.
Смысл простой: базовая логика агента остаётся компактной, а дополнительные функции — логирование, защитные фильтры, самокоррекция, обработка ошибок — подключаются отдельно. Не идеально магически, конечно, но очень близко к тому, как и должно быть в зрелом фреймворке.
Особенно любопытен плагин Retry and Reflect. Он перехватывает ошибки инструментов, возвращает их модели и позволяет агенту скорректировать параметры перед повторной попыткой. По сути, это встроенная self-healing-логика. Немного дерзко звучит, да, но польза вполне приземлённая: меньше ручного вмешательства, меньше хрупких костылей.
// Adding Plugins to the Runner
r, _ := runner.New(runner.Config{
Agent: myAgent,
SessionService: mySessionService,
PluginConfig: runner.PluginConfig{
Plugins: []*plugin.Plugin{
// Automatically retries failed tool calls with reflection
retryandreflect.MustNew(retryandreflect.WithMaxRetries(3),
// Centralized logging for every turn
loggingplugin.MustNew(""),
},
},
})Human-in-the-Loop: доверяй агенту, но не безоглядно
Когда речь заходит о чувствительных действиях, романтика автономии быстро заканчивается. Финансовые операции, удаление данных, изменения в production — тут нужен контроль со стороны человека. И желательно встроенный, а не прикрученный на скорую руку в пятницу вечером.
Следуя рекомендациям Safe AI Framework (SAIF), ADK Go 1.0 поддерживает надёжный механизм Request Confirmation. Если инструмент помечен как RequireConfirmation, агент останавливает выполнение, создаёт событие на подтверждение и ждёт решения человека.
Для enterprise-сценариев это критично: такие механизмы напрямую связаны и с управлением рисками, и с AI compliance и соответствием требованиям. Короче, без этого в серьёзной среде никуда. Вообще никуда.
// Human-in-the-loop Tool Setup
myTool, _ := functiontool.New(functiontool.Config{
Name: "delete_database",
Description: "Deletes a production database instance.",
RequireConfirmation: true, // Triggers the HITL approval flow
}, deleteDBFunc)YAML-конфигурации: меньше шаблонного кода, больше скорости
Ещё одно заметное нововведение в релизе 1.0 — возможность описывать агентов напрямую через YAML. Это даёт функциональную согласованность между языками и избавляет от необходимости писать boilerplate-код на Go при каждом изменении конфигурации.
Проще говоря, команды могут менять поведение агента, его роль, набор инструментов и структуру подагентов без пересборки основного бинарника. Для быстрых итераций — прямо то, что доктор прописал. Ну, или архитектор платформы.
# agent_config.yaml
name: customer_service
description: Агент, который обрабатывает вопросы клиентов авиакомпании.
instruction: >
You are a customer agent that helps users booking flights.
You are always helpful.
tools:
- name: "google_search"
- name: "builtin_code_executor"
sub_agents:
- "policy_agent"
- "booking_agent"Такой подход упрощает разделение конфигурации и бизнес-логики, а ещё ускоряет эксперименты с персоной агента, иерархией подагентов и сценариями оркестрации. Иногда именно это и решает, полетит проект или увязнет в бесконечных пересборках. Мелочь? Да нет, не мелочь.
A2A и полиглотные сценарии: агенты больше не живут поодиночке
Современный агент редко существует в вакууме. Один отвечает за поиск, другой — за политику доступа, третий — за выполнение действий. Поэтому важна не только логика отдельного агента, но и то, как он взаимодействует с остальными.
Протокол Agent2Agent (A2A) был доработан так, чтобы обеспечить более гладкое взаимодействие между агентами на Go, Java и Python. В ADK Go эта оркестрация упрощена: фреймворк берёт на себя порядок событий и агрегацию ответов, включая сценарии с потоковой передачей частичных результатов.
Это важный шаг для команд, которые строят распределённые агентные платформы, где нужны и переносимость, и надёжный обмен контекстом, и масштабируемая мультиагентная архитектура. Иначе всё быстро начинает скрипеть. А потом — ломаться.
Что дальше
Если хотите попробовать ADK Go 1.0 в деле, начните с краткого руководства по быстрому старту и загляните в репозиторий на GitHub. Там уже есть всё, чтобы перейти от знакомства к первым рабочим прототипам.
А если смотреть шире, релиз хорошо показывает, куда движется рынок: к наблюдаемым, безопасным, конфигурируемым агентным системам, которые можно запускать в реальной корпоративной среде, а не только демонстрировать на слайдах. И это, пожалуй, главное.
Не забудьте присоединиться к сообществу на Reddit или в Google Group сообщества ADK и рассказать, что вы собираете на базе ADK Go. Правда, интересно посмотреть, куда всё это вырулит.
Эпоха Go-агентов уже началась. Теперь осталось, ну да, просто взять и построить что-то стоящее.
