Книга Антонио Гулли очень хороша для старта в понимании агентских ИИ-систем, но оказалась слишком поверхностна, а темы разрозненны, чтобы покрыть спектр практического понимания, а как же на самом деле строить эти системы.
Я испробовал почти всё популярное: LangChain/LangGraph для python и typescript, CrewAI, ADK, даже Koog для Kotlin и yaml-ориентированный Composio. Каждый фреймоворк предлагает свои особенности и уровень простоты. Чем проще инструмент, тем меньше остается контроля над происходящим. Наш путь - заглянуть под капот, разобраться в нюансах и сделать для себя правильный выбор.
План такой:
1️⃣ Сначала разберемся, а из чего же состоит AI-агент и что, собственно, его делает агентом.
2️⃣ Исследуем, какие подходы предлагают фреймворки для смешивания детерминированной бизнес-логики c тем бардаком, что генерируют LLM
3️⃣ Столкнемся главным вызовом разработчика агентской системы - как заставить группу агентов работать совместно, защититься от галлюцинаций, таск-дрифта и других побочных эффектов работы систем с нечеткой логикой
4️⃣ В конце, обсудим плюсы и минусы, сделаем наметки на будущие шаги, возможно даже построим свой агентский фреймворк, обсуждая его дизайн в прямом эфире.
Мой собственный кейс зачем я полез с этим разбираться - создание AI-плейбука менеджера по продажам. Важнейший шаг плейбука - глубокое исследование клиентской компании. Суть задачи в том, чтобы взять целевую компанию, коммерческое предложение продавца, обойти интернет и скомпилировать отчет, который подскажет менеджеру как правильно зайти в
Это отличная задача для ИИ, но со звездочкой. Я для себя разделил целевое использование ИИ-агентов на 2 части:
- Исследовательское - компиляция данных, с LLM-верификацией источника. Мы не знаем заранее куда пойдет Агент и мы не можем полагаться на достоверность источника.
- Функциональное - компиляция данных из заранее верифицированного источника. Агент ходит в базы данных или в документы и предоставляет результат, которому мы, в целом, можем доверять.
Моя задача исследовательская, однако к результату особые требования. В отличие результатов, которые дают Deep Research режимы популярных вендоров, нам нужна строгая форма отчета + структурированный вывод, соблюдение акцентов на специфике оффера, переносимость workflow между разными LLM, достоверность и верификации найденных данных на уровне процесса, восставливаемость при сбое в точке остановки. И вот какие проблемы вылезли по дороге:
👻 Галлюцинации
OSS модели (а именно такие являются приритетными для российских реалий) легко выдумывают людей, факты, гипотезы ценности. Понижение температуры и требование “НИКОГДА НЕ ВЫДУМЫВАЙ …” в большом контексте не дает ожидаемого результата.
🏎️ Дрифт задачи
По мере заполнения контекстного окна агент отклоняется от исходной задачи и возвращает ответ, косвенно связанный с целевым.
🥵 Переполнение контекста
Контекстное окно в 1М токенов - привилегия проприетарных моделей, но такой объем драматически удорожает исследование. Стандартные подходы к сжатию режут массу полезных данных, а значит хорошо бы знать как сжимать контекст избегая потерь
💾 Сохранение состояния
Когда агентов в коллаборации много, результат работы каждого нужно держать в структурированном виде в виде обычной структуры данных в коде, учить одного из агентов управлять этим состоянием, выстраивать циклы обратной связи если возврат одного из агентов по какой-то причине не смог сохраниться.
... продолжение ниже