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