Demo агента — легкая часть#
Google в своем developer blog собрал пять уроков из Google Cloud AI Agent Bake-Off — соревнования на время, где команды строили автономных агентов для задач вроде возвратов в e-commerce, модернизации legacy-банкинга и автоматизации go-to-market для стартапов.
Полезна здесь не сама форма соревнования. Полезен описанный Google failure mode: разрыв между chat-style LLM demo и production-агентом в основном архитектурный. Более удачные prompts помогают, но не решают состояние, routing, доступ к tools, validation, latency и maintenance.
Формулировка Google достаточно жесткая, чтобы быть важной. «Honeymoon phase» общения с LLM закончилась. Agent systems теперь нужны более четкие границы: специализированные компоненты, deterministic execution, строгие schemas и план замены частей, когда возможности модели изменятся.
Это хороший взгляд для команд, которые уже строят агентов. Вопрос не столько в том, «может ли модель сделать это один раз», сколько в том, «может ли система восстановиться, проверить результат, правильно направить задачу, заменить tools и безопасно отказать».
Разделите агента, пока он не стал liability#
Один из главных уроков Google — не превращать один большой LLM prompt во все приложение.
Single agent, который должен извлекать intent, получать данные, рассуждать по policy, вызывать tools и генерировать user-facing output, быстро становится трудным для debugging. Он также может стать медленным. Google приводит пример из bake-off, где узко ограниченные агенты, работающие параллельно, сократили processing time примерно с одного часа до примерно десяти минут.
Общий паттерн знаком из software architecture: разделяйте работу. Относитесь к агентам скорее как к microservices, а не как к одному универсальному мозгу.
Практичная multi-agent схема может включать:
- intent extraction agent
- retrieval или database agent
- policy или rules agent
- visual generation или multimodal agent
- supervisor, который маршрутизирует задачи и объединяет результаты
Это не делает систему автоматически безопасной или корректной. Зато делает ее проще для inspection. Если один компонент ломается, drift-ит или требует новой модели, команда может заменить эту часть без переписывания всего workflow.
Компромисс — coordination cost. Multi-agent system добавляет orchestration, state handling и больше точек частичного отказа. Но для production-задач эти издержки обычно управляемее, чем монолитный prompt, который после третьей итерации уже никто не может объяснить.
Проектируйте под замену, а не под вечность#
Второй урок Google неприятный, но реалистичный: agent harness, который вы пишете сегодня, скоро может устареть.
В блоге как пример используется challenge с e-commerce virtual try-on. Команды под жесткий deadline строили multi-step решения на Gemini 2.0. Google отмечает, что вскоре после этого новые возможности image model сделали похожую работу достижимой с гораздо более простым prompt.
Это ловушка для создателей агентов. Сложный workflow может быть необходим сегодня, потому что базовая модель еще не умеет выполнять задачу напрямую. Но возможности frontier model позже могут поглотить части этого workflow.
Поэтому правильное проектное допущение — непостоянство.
Не относитесь к каждому agent harness как к священной инфраструктуре. Стройте его как replaceable layer. Держите interfaces узкими. Изолируйте model-specific code. Сделайте возможным удаление sub-agent, замену tool или сворачивание multi-step flow, когда модель станет достаточно хорошей, чтобы справляться напрямую.
Это важно не только для архитектурной элегантности, но и для cost.