Недавно Google запустил бесплатный курс по работе с агентами.
Курсы охватывают от Prompt, Agent Loop до Graph Workflow, Multi-Agent и саморазвивающихся систем.На первый взгляд, это похоже на введение нового подхода к разработке агентов.
Но если посмотреть на официальную информацию о Google ADK 2.0, руководство по архитектуре Google Cloud и несколько недавних исследований обзоров агентов, то я думаю, что действительно стоит обратить внимание не на один API, а на более крупные изменения:
Разработка агентов переходит от «моделирования» к «системы проектирования».
В прошлом, большинство приложений AI были такими:
Вход → запрос → модель → выход.
Перевод, резюме, классификация, извлечение информации, переписывание контента - это задачи, которые обычно выполняются одним вызовом.
Быстрая разработка, простая оценка затрат, если ошибка, можно перевзойти один раз.
Но после вызова инструмента агент начинает действовать в бизнес-процессе.
Он может искать материалы, вызывать API, выполнять код, запросить базы данных, а затем принимать решение о следующем шаге на основе результатов, возвращаемых инструментом.
Модели больше не просто «ответы на вопросы».
Он начал «делать что-нибудь».
Но как только модель вошла в реализацию, проблема была совершенно другой.
Контекст постоянно растет, результаты инструментов постоянно входят в историю, а агенты могут повторять вызовы инструментов, отклоняться от цели на середине пути или даже завершить работу раньше срока.
Кроме того, корпоративные процессы дополнительно требуют разрешений, утверждений, состояния, повторных попыток, восстановления и аудита.
Возврат денег, проверка счетов-фактур, прием сотрудников на работу, обработка заказов - это не просто вопрос и ответ
Таким образом, реальные проблемы агента возникли от:
«Как можно сделать так, чтобы модель ответила правильно несколько раз? »
превращается в:
«Как сделать бизнес-процесс, в котором участвует модель, стабильным? »
Это то, что я думаю, что Google ADK 2.0 заслуживает внимания.
В чем разница между Prompt, Agent Loop и Graph?
Многие люди в настоящее время обсуждают агенты, и легко смешивать Prompt, Agent Loop и Workflow.
На самом деле, они решают проблемы на трех разных уровнях.
Прогноз "Понимание"
Prompt говорит модели:
Что вы хотите сделать, как это делать, какой формат вывода, какие ограничения.
Если сами задачи относительно просты, такие как перевод, резюме, классификация, переписка, то Prompt часто достаточно.
Agent Loop решает «Действия».
Когда модель имеет инструменты, она может:
Понимание цели → Составление следующего шага → Вызов инструмента → Прочтение результатов → Решите, что делать дальше.
Это типичный агент Loop.
Он особенно подходит для открытых задач.
Например, поиск материалов, исправление кода, анализ сложных данных.
Поскольку вам трудно заранее записать каждый шаг, модели должны динамически корректировать план в зависимости от результатов на местах.
Graph Workflow - решение задания «Исполнение»
Workflow ориентируется на:
Как должен пройти весь процесс.
Какие шаги необходимо предпринять?
Какие задачи можно выполнять параллельно?
При каких обстоятельствах входить в отделение?
Когда нужно вручную утверждать?
Где попытаться снова после неудачи?
Какие состояния нужно сохранить?
Все эти вопросы не могут быть оставлены на усмотрение моделей.
Они лучше подходят для включения в процедуру.
Таким образом, все три понятия можно легко понять:
Prompt отвечает за понимание, Agent Loop - за действия, а Workflow - за ограничения исполнения.
Они не заменяют друг друга, а могут накладываться.
Проблемы, которые можно решить одним вызовом модели, не требуют принудительного создания рабочего потока.
Задачи, которые один агент уже может выполнять стабильно, не требуется разделить на несколько агентов для «агентики».
Во-вторых, когда начнет действовать Prompt?
Самая большая проблема Prompt не в том, что она недостаточно сильна.
Когда деловые процессы становятся все более сложными,Сам процесс начинает скрываться в Prompt.
Например, процесс возврата денег:
Пользователь предлагает возврат средств → запрос заказа → определение политики → решение о возврат средств → выполнение возврата средств → отправка подтверждения → обновление заказа.
Если все это передать агенту и позволить модели самостоятельно решать следующий шаг, то это выглядит очень гибким.
Однако в производственной среде вскоре возникнут проблемы.
Разработчикам трудно определить:
Выполняете ли вы этот шаг каждый раз?
Выполняется ли проверка полномочий до возврата денег?
Повторяется ли возврат средств после сбоя инструмента?
Где следует продолжить отправку электронной почты после неудачи?
После неудачного обновления базы данных, не нужно отвернуть предыдущую операцию?
Это уже не вопрос о сроках.
Речь идет о программной инженерии.
Таким образом, действительно надежные системы, как правило, используют более реалистичное разделение труда:
Модель несет ответственность за неопределенность, а код несет ответственность за определенность.
Например:
Понимание и анализ содержания жалобы могут быть переданы модели.
Запросы заказов, выполнение возврата денег, обновление базы данных должны контролироваться программой.
В-третьих, Agent Loop гибкий, но производственная среда должна быть «под рукой».
Очарование Agent Loop заключается в том, что ему не нужно знать все пути заранее.
Модель может постоянно корректировать план в зависимости от результатов, возвращаемых инструментом.
Например,:
«Помогите мне проверить последние финансовые данные компании».
Агент может самостоятельно искать веб-страницы, запросить базы данных, организовывать материалы и продолжать поиск, если обнаруживается недостаток информации.
Эта задача может быть громоздкой, если полностью написать процесс.
Но Loop также имеет естественные риски:
Он не знает, когда остановиться.
Таким образом, Agent Loop в производственной среде обычно требует четких настроек:
- Максимальное количество шагов выполнения
- Общее время прерывания
- Бюджет Token / API
- Условия успеха
- Условия отказа
- Путь обновления вручную
В противном случае ошибочное решение может стать:
Вызов инструмента → получение ошибочного результата → повторный вызов → повторная неудача → продолжить попытку.
Итоговый результат:
Расходы увеличились, задержки увеличивались, а задачи не выполнялись.
Таким образом:
Когда путь неопределен, позвольте модели принять решение.
Когда путь определен, не позволяйте модели догадываться.
На самом деле, это очень важный принцип в программе агентов.
Что на самом деле делает Graph Workflow?
Работа Graph Workflow очень проста:
Процессы, скрытые в моделях принятия решений, превращаются в структуры программного обеспечения, которые разработчики могут видеть, тестировать и изменять.
Например, процесс возврата денег может быть спроектирован таким образом, чтобы:
Запрос заказов
↓
Анализ жалоб пользователей
↓
Условия возврата денег
↓
Удовлетворение условий → Выполнение возврата денег
│
Не удовлетворено → закрыть заказ
↓
Создание сообщения подтверждения
↓
Обновление состояния заказа
Таким образом, каждый узел становится ясным.
Какие шаги необходимо предпринять?
Какие шаги могут быть выполнены параллельно?
Где требуется подтверждение?
Где восстановить себя после неудачи?
Какие результаты должны быть устойчивыми?
Все можно четко выразить.
В этом и заключается главная преимущество Workflow:
Это не делает агента умнее, а делает агента более управляемым.
Почему Google ADK 2.0 стоит внимания?
Одним из важных изменений в Google ADK 2.0 является то, что время выполнения Workflow официально стало центральным элементом разработки агента.
Python 2.0 поступит в общее пользование 19 мая 2026 года, а Go 2.0 - 30 июня.
В официальном дизайне агенты, инструменты и функции могут быть узлами в рабочем процессе, управляемым процессом через отношения исполнения.
Последовательное выполнение, условная маршрутизация, параллельные задачи, циклы, динамические рабочие процессы, вложенные процессы и вмешательство человека могут быть включены в единую операционную модель.
Что еще важнее, он начал уделять внимание состоянию и восстановлению длительных миссий.
Реальная корпоративная задача может быть выполнена не за несколько секунд.
Он может работать десятки минут или даже дольше.
Может быть приостановлено в середине.
Возможно, ожидается ручное утверждение.
Возможно, внешняя система временно недоступна.
Система должна знать, что:
Где раньше это было сделано?
Если нет контрольных точек и возможностей восстановления состояния, агент может быть перезапущен только после прерывания.
Именно поэтому корпоративные агенты в конечном итоге будут все больше похожи на традиционные программные системы.
Для этого требуется:
Состояние.
события.
контрольно-пропускные пункты.
Повторная попытка.
полномочия.
Журнал.
Ревизия.
Восстановление.
Длинный контекст не означает надежной памяти
Еще одна проблема, которую легко игнорировать:
Контекст Rot.
Многие считают, что агент «все помнит», если только всю историю вставят в контекст.
На самом деле дело не так просто.
По мере увеличения объема ввода способность модели точно найти действительно важную информацию из контекста может уменьшиться.
А агентам легче столкнуться с этой проблемой, чем в обычном чате.
Потому что каждый вызов инструмента может принести новые данные.
Результаты поиска, содержимое веб-страницы, записи базы данных, возвращаемое значение API, промежуточные рассуждения...
Если все это постоянно добавляется в контекст, то в конечном итоге образуется огромная мусорная свалка информации.
Чем длиннее контекст, не обязательно умнее.
Иногда ошибки легче.
Таким образом, Workflow может быть облегчен в трех направлениях:
Во-первых, узлы изолируют контекст.
Каждый узел читает только ту информацию, которая ему действительно нужна.
Во-вторых, использование структурного состояния.
Не загружайте всю историю чата в модель каждый раз.
В-третьих, создание контрольных пунктов.
Результаты подтверждения сохраняются после завершения одного узла, а следующий узел продолжает с подтвержденного состояния.
Но есть еще одно важное отличие:
Сохранение записи чата не равнозначно восстановлению.
Подлинные механизмы восстановления также должны учитывать:
Контрольные точки, журналы событий, экзопотентные операции и политика воспроизведения для внешних систем.
Чем больше агентов, тем более продвинуты.
Есть еще одна тенденция, которую легко неправильно понять:
Кажется, что чем больше агентов, тем более продвинутая система.
На самом деле, это совсем не так.
Многоагенты действительно ценны там, где, даЧеткое разделение обязанностей。
Например:
Один агент отвечает за поиск.
Один из агентов отвечает за анализ.
Один агент отвечает за исполнение.
Таким образом, каждый агент может иметь разные инструменты, права и контекст.
Возникает также вопрос:
Призывали больше.
Коммуникации больше.
Синхронизация состояния становится более сложной.
Устранение неисправностей стало сложнее.
После одновременности возникают также проблемы ограничения потоков, конкуренции ресурсов и согласованности.
Исследование MAST NeurIPS 2025 проанализировало более 1,600 траекторий исполнения мультиагентов и выявило 14 категорий сбоев.
Многие из этих проблем не связаны с тем, что Prompt плохо написано.
Вместо этого,
Нерациональное разделение задач, неудачи в работе агентов, хаос в управлении состоянием, невозможность проверки результатов.
Поэтому я полностью согласен с простым принципом:
Без четкого разграничения обязанностей не стоит использовать «многих агентов» для «многих агентов».
Проблемы, которые можно решить стабильно с помощью одного агента, сначала используйте один.
Разделение должно рассматриваться только в тех случаях, когда задачи действительно четко разграничены, полномочия отделены или сложная совместная работа.
Оценка агента не может быть просто «нет».
Традиционные LLM приложений легко сделать тест на точность.
Агент - это совсем другое.
Потому что он должен не только «правильно ответить», но и «завершить дело».
Например, агент по возмещению расходов.
В конечном итоге он ответил:
«Вертете деньги для вас».
Это слово не имеет смысла быть более красивым.
Что действительно нужно проверить, то:
Действительно ли возврат был выполнен?
Сумма возврата, верно?
Есть ли повторные возврата?
Были ли какие-то действия, превышающие полномочия?
Обновлен ли рабочий лист?
Пользователи получают уведомление?
Все ли процессы были полностью зарегистрированы?
Поэтому, когда компания оценивает агента, я рекомендую сравнить его с реальными, десенсибилизированными историческими заданиями.
Например, 20 - 50 задач.
Сравните по крайней мере три варианта:
- Однократный вызов модели
- Единый агент с инструментами
- Graph Workflow или Multi-Agent
Используется один и тот же набор задач и критериев приемки.
Основные отчеты:
- Показатель успешного завершения впервые
- Коэффициент успешного выполнения окончательных заданий
- Время изменения вручную
- Комплексная задержка
- Общая стоимость моделей и инструментов
- Число повторных попыток
- На каком узле произошла неудача
- Количество несанкционированных операций
- Полны ли источники и траектории исполнения
В частности, в случае операций с высоким риском нельзя регистрировать только «успех / неудачи».
Следует также сохранить следующее:
Обоснование оценки, исходные свидетельства, траектории осуществления и отчеты о ручной проверке.
Потому что после того, как вы действительно в сети, вам нужно ответить не только:
«Он сделал это правильно? »
Ответить:
«Почему это делаешь? »
Девятый, компания посадки агента, лучшая отправная точка не «создание супер-агента».
Если бы я был агентом компании сейчас, я бы не подумал сначала:
«Нам нужно создать многоагентную систему? »
Сначала я бы спросил:
Имеется ли в компании уже существующий ручный процесс, четко ограниченный и проверяемый результаты?
Например,:
Проверка счетов-фактур
Возврат услуг клиентам.
Ревизия контрактов.
Принятие сотрудников.
Продажи лидеров.
Сначала прояснить процесс работы.
Сколько времени займет?
Сколько это стоит?
Где наиболее распространенные ошибки?
Какие шаги являются наиболее тратными рабочими силами?
Какие шаги относятся к определению правил?
Какие шаги требуют суждения человека?
После этого эталон определяется, где следует использовать модель.
Затем:
Если вы можете решить это одним агентом, не спешите демонтировать несколько.
Если вы можете решить это с помощью кода, не позволяйте модели решать.
Только если процесс появляется ясным:
ответвление, параллельность, утверждение, повторная попытка, восстановление
В случае необходимости внедряйте Workflow.
Если речь идет о необратимых действиях, таких как оплата, запись в базу данных, отправка электронной почты, отправка заказов на работу, необходимо заранее разработать:
Проверка полномочий, равнопотенные ключи, ручное подтверждение, обратный путь.
В этот момент вы обнаружите:
Проектирование агентов по сути все ближе к традиционному программному обеспечению.
И наконец, какой будет настоящий следующий этап агента?
В течение последних двух лет мы работали над:
Как сделать модель умнее?
Как сделать prompt более эффективным?
Как сделать агента лучше использовать инструменты?
Но следующий вопрос, который действительно волнует бизнес, может стать:
Как заставить агента стабильно выполнить работу?
Эти два вопроса совершенно разные.
То, что модель иногда выступает потрясающе, не означает, что она может попасть в производственную среду.
То, что агент может выполнить одну задачу, не означает, что он может выполнить 10 000 задач в день.
То, что действительно нужно предприятию, это:
Устойчивый успех.
контролируемые затраты.
Процесс отслеживается.
Восстановить состояние.
Минимальные права.
Надежная повторная попытка.
Полный аудит.
Вмешательство искусственного человека.
Постоянная оценка.
Поэтому я предпочитаю рассматривать агента как новую программную систему, а не как окно чата, которое вызывает инструменты.
Prompt позволяет модели понять задачи.
Agent Loop позволяет модели действовать в соответствии с результатами.
Graph Workflow ограничивает весь процесс исполнения.
Если все три будут размещены в правильном месте, то можно одновременно получить гибкость ИИ и определенность традиционного программного обеспечения.
Что действительно стоит обратить внимание на Google ADK 2.0 - это, возможно, не то, сколько API он добавляет.
Это дает четкий сигнал:
Агент переходит из «ч-бота, который вызывает инструменты», в «программную систему, которую можно проектировать, эксплуатировать и аудировать».
Graph Workflow - это только шаг на этом пути.
В конечном итоге решение о том, может ли агент выйти в сеть, все еще не насколько удивительным является демо, а:
Успех, переработка вручную, задержки, затраты и отчеты по безопасности.
Возможно, это наиболее важная конкурентоспособность агента после того, как он действительно входит в производственную среду предприятия.