На протяжении нескольких лет я работаю в качестве технического директора в ASRP, компании, которая разрабатывает образовательные проекты и исследует новые подходы в EdTech. Одной из наших ключевых областей стало тестирование возможностей Google ADK в образовательных сценариях и создание прототипа интеллектуальной системы оценки знаний. В этом проекте моя роль заключалась в том, чтобы выступать в качестве главного архитектора и инженера — от проектирования концепции до реализации ключевых модулей системы.
Особенности Google ADK
Для создания агента я выбрал Google ADK (Agent Development Kit) — рамку, специально разработанную для создания систем с агентами LLM. Документация Google ADK подчеркивает, что LlmAgent служит «мыслящей частью» приложения: он использует мощь LLM для рассуждений, понимания естественного языка, принятия решений и генерации ответов [1].
В дополнение к LlmAgent, Google ADK предоставляет инструменты для строго определенных последовательностей выполнения. Например, SequentialAgent является агентом рабочего процесса, который выполняет вложенные подагенты в фиксированном порядке [2]. По сути, он обеспечивает выполнение задач шаг за шагом, точно так, как указано. В своих экспериментах я сначала полагался на LlmAgent с расширенными инструкциями и рассуждениями внутри модели, но позже перешел к явной оркестрации через код: подключение подагентов и инструментов (AgentTool) для поддержания процесса под внешним контролем.
Архитектурные решения
В первой версии я пытался уместить всю бизнес-логику в один LlmAgent: я тщательно описал роль агента, цели и ожидания и полагался на саму LLM для выполнения всех вычислений и оценки ответов студентов. Этот подход позволил быстро создать рабочий прототип, но его ограничения вскоре стали очевидны: модель стала «перегруженной» длинными инструкциями и контекстом, потребление токенов на запрос возросло, и отладка такого «монолитного» решения оказалась сложной [3].
Постепенно я перешел к более модульной архитектуре: система была разделена на несколько агентов и этапов. Например, один LlmAgent отвечал за генерацию вопросов, другой за оценку и анализ ответов, а третий за создание комментариев и подсказок. Для соединения этих этапов я использовал ПоследовательныйАгент и ПараллельныйАгент: первый обеспечивал выполнение шагов в правильном порядке, в то время как второй позволял независимым задачам выполняться одновременно. Этот многопользовательский подход помог снизить нагрузку на каждого отдельного агента и сделал процессы более надежными. Разделение задач также позволило создать более стабильные цепочки обработки для обработки ответов и упростило тестирование каждого модуля.
По мере роста диалога и накопления сессии объем передаваемого текста быстро увеличивался, что приводило к росту вычислительных затрат. Чтобы решить эту проблему, я реализовал оптимизацию на уровне токенов. Вместо того чтобы отправлять всю историю чата на каждом шаге, я начал активно использовать функции памяти. Вместо того чтобы хранить весь диалог в контексте, я сохранял ключевую информацию в ctx.session.state и в сервисе памяти ADK (например, InMemoryMemoryService). Это сделало возможным исключение повторяющихся частей из запросов и сокращение использования токенов. Более того, я разбивал сложные задачи на более мелкие шаги и использовал более короткие подсказки, чтобы избежать перегрузки модели.
Технические проблемы и инженерные уловки
Модель иногда выдавала неожиданные или неполные ответы, поэтому мне пришлось добавить дополнительную валидацию. Например, я определил строгие проверки формата в инструкциях: после получения вывода агента-оценщика система проверяла, соответствовал ли он ожидаемой структуре (например, действительный JSON или четкая схема). Если формат был нарушен, скрипт "переспрашивал" модель с уточняющими подсказками.
Я также реализовал механизм обратной связи: специальный агент-ревьюер проверял качество ответов перед их представлением пользователю. Это позволяло выявлять ошибки на ранних стадиях и значительно улучшало надежность системы.
Еще одной инженерной уловкой было использование встроенных инструментов ADK. Я активно использовал AgentTool: по сути, превращая одного агента в инструмент для другого. Это дало нам гибкость — основной LlmAgent мог динамически вызывать подагентов в зависимости от запроса. Этот подход позволил нам объединить сильные стороны различных моделей внутри одной единой логики.
Чтобы оптимизировать генерацию, я использовал потоковую передачу, где это было уместно, и тонко настраивал параметры модели (temperature, max_output_tokens, и т.д.). На критических этапах я устанавливал temperature=0, чтобы обеспечить детерминированные выходные данные. Я также хранил ключевые результаты (output_key) в сессии, чтобы их можно было передавать от одного агента к другому без избыточного дублирования текста.
Все эти техники помогли сэкономить токены и упростили отладку. Это потребовало обширного тестирования и тонкой настройки, но в конечном итоге привело к гораздо более стабильной системе.
Эволюция роли CTO
Во время разработки моя роль значительно расширилась. Сначала я в основном сосредоточился на инженерных задачах: проектировании архитектуры, написании кода и экспериментах с моделями. Но по мере быстрого роста проекта мне пришлось переключиться на управление. Я обнаружил, что не только проектирую системы, но и создаю команду разработчиков, делегирую задачи и контролирую выполнение. Я все больше участвовал в планировании проекта, согласовывая сроки с партнерами, управляя бюджетом и обучая коллег работать с новыми инструментами.
Каждый новый этап проекта стал для меня личным экзаменом. При интеграции новых API или масштабировании системы на Kubernetes мои обязанности выходили далеко за рамки «просто кода» — мне приходилось наставлять команду, распределять роли, заниматься документацией и координировать с бизнес-стороной. Я понял, что быть CTO значит не только быть «техническим архитектором», но и «лидером команды» и «мостом» между разработчиками и бизнесом. Порой мне приходилось выступать в роли наставника и тренера, а в другие моменты — инспектора, обеспечивая качество. Эти новые «экзамены» в управлении проектами и людьми стали неотъемлемой частью моей роли.
Философские размышления
Создание такого «экзамена» заставило меня задуматься о более широком значении работы. Каждый проект в ИТ ощущается как экзамен: тест на логику, креативность и способность продолжать учиться. Работа с LLM-агентами становится больше похожей на партнерство: они не просто выполняют команды, но вступают в диалог, предлагают идеи или задают уточняющие вопросы. Все больше я вижу их не просто как инструменты, а как коллег — важно давать им четкие задачи, но также оставлять место для собственного «мыслительного процесса» модели.
Я смотрю в будущее EdTech с оптимизмом. Эти системы, безусловно, преобразят образование: личные репетиторы, мгновенная обратная связь, адаптивные курсы. Обучение становится персонализированным — и это меняет правила игры. Вот почему в ASRP мы переносим уроки, извлеченные из прототипов, в наши собственные продукты, включая Arcanum12th платформу. Там LLM-агенты уже поддерживают студентов с заданиями, тестами и интерактивными диалогами. Опыт с ADK стал основой: модульность, память и сценарии диалога были интегрированы в Arcanum12th.
Тем не менее, важно помнить, что человек остается в центре процесса. Экзамен всегда является тестом знаний и навыков, а агенты лишь помощники. Они расширяют возможности, но ответственность за результат по-прежнему лежит на нас.
10 уроков CTO из AI экзамена
Анализируя свой опыт, я выделил следующие уроки как CTO из моего собственного «AI экзамена».
- Делегируйте задачи через агентов.
Не пытайтесь упаковать всю логику в одного «суперагента» — такие системы часто рушатся под собственным весом из-за перегруженных инструкций. Команда специализированных агентов обеспечивает лучшую точность и масштабируемость. Разбейте проект на этапы и заверните отдельные функциональности в индивидуальные агенты. - Проектируйте архитектуру с учетом токенов.
Ограничьте размер запросов и ответов (настройтеmax_output_tokens), и используйте состояние сессии и сервисы памяти, чтобы избежать отправки избыточного контекста модели. Это снижает вычислительные затраты и ускоряет систему. - Используйте сильные стороны ADK.
ПомимоLlmAgent, научитесь использоватьSequentialAgentи других агентов рабочего процесса — они добавляют надежность и предсказуемость процессам. Преобразуйте агентов в AgentTools для гибкого взаимодействия, чтобы основной агент мог вызвать нужного «специалиста» в нужное время. - Параллелизуйте независимые задачи.
Если цепочка имеет шаги, которые не зависят друг от друга, выполняйте их параллельно. ADK предлагаетParallelAgentдля этого. Например, поиск информации и проверка ответов могут выполняться одновременно, экономя время без ущерба для качества. - Отслеживайте сессию и состояние.
Храните важные данные (временные результаты, счетчики, ключи вывода) вctx.session.state. Это делает реализацию более прозрачной и помогает агентам переключать контекст. Четко определите output_key для передачи данных между агентами без ненужного дублирования. - Добавьте обратную связь и валидацию.
Хороший агент дважды проверяет свою работу: я создал отдельного агента-рецензента, который обеспечивает качество перед доставкой окончательного результата. Это позволяет выявлять ошибки на ранней стадии и способствует итеративному улучшению (например, возвращая "неудачу" и запрашивая доработку). - Логируйте и анализируйте.
Реализуйте обратные вызовы и логирование (например, AgentOps, Phoenix, или пользовательские решения). Понимание того, как агенты взаимодействуют и сколько ресурсов потребляется, имеет решающее значение для оптимизации и стабильности системы. - Примите эксперименты.
Работа с ИИ — это непрерывный эксперимент. Модели могут удивлять вас, поэтому терпение и адаптивность имеют решающее значение. Даже неудачные попытки учат нас чему-то новому. - Сотрудничество с ИИ — это новый стандарт.
Научитесь рассматривать LLM как "коллег": ставьте четкие задачи, проверяйте результаты и объединяйте идеи. Это меняет культуру разработки с чисто человеческой на гибридный подход "человек + ИИ". - Будущее принадлежит обучению.
С философской точки зрения: инвестируйте в знания и обмен знаниями. Экзамен как проект — это не только урок для студентов, но и для разработчиков. Непрерывное обучение, готовность адаптироваться и способность обучать других — это то, что позволит нам идти в ногу с технологиями.
Я приглашаю всех, кто заинтересован в создании LLM-агентов, присоединиться к моему авторскому курсу. В нем я делюсь практическим опытом разработки, объясняю возможности Google ADK и демонстрирую, как применять описанные здесь техники на практике. Вместе мы научимся строить надежные системы!
