Рефакторинг агентов для эпохи Claude 4: отказ от сложного шардинга и реализация цикла из 3 агентов в коде

Стратегия миграции данных от legacy-шардинга к циклу из 3 агентов

Микрошардинг, который продвигали старые версии LangChain или AutoGPT, потерпел неудачу. Разделение процесса на десятки этапов может сделать логическую цепочку изысканной на вид, но на деле это лишь обрывает контекст при каждом вызове и повышает недетерминированность. При использовании LLM с резко возросшими способностями к рассуждению, таких как Claude 3.5 или грядущая модель 4, стратегию необходимо менять. Перестаньте бороться с фрагментированными узлами. Вместо этого интегрируйте их в централизованную структуру управления состоянием под контролем Planner.

Для успешного перехода архитектуры сначала сгруппируйте существующие микрозадачи в методы одного класса, инкапсулировав их в «хранилище инструментов» (Tool Box). Затем определите единый объект State, на который ссылаются все агенты. Он обязательно должен содержать поля: plan (поэтапный план), history (лог выполнения инструментов) и artifacts (сгенерированные данные).

Используйте функцию редьюсеров в LangGraph, чтобы каждый агент обновлял это общее состояние по завершении своей работы. Физическое предотвращение разрыва контекста устраняет передачу дублирующих токенов. Команды, перешедшие на эту структуру, на практике мгновенно сократили расходы на API более чем на 30%.

Реализация кода количественной системы показателей для Evaluator

Субъективные суждения о том, что результат агента «выглядит неплохо», в производственной среде подобны бомбе замедленного действия. Внедрите паттерн LLM-as-a-Judge, но обязательно закрепите его на уровне кода. Агент Evaluator должен разбивать результат Generator на 4 показателя: точность, последовательность, читаемость и эффективность, переводя их в числовые значения.

Используйте библиотеку Pydantic, чтобы гарантировать соответствие результатов оценки определенной схеме JSON.

• Объявите класс RubricScore и установите каждый показатель как целочисленное поле от 1 до 5.
• В промпте четко пропишите условия для каждого балла (например: 5 баллов за эффективность выставляются при достижении временной сложности $O(n)$ или ниже).
• Если средний балл ниже 4.0, выполняется Merge Block, который автоматически останавливает деплой в CI/CD пайплайне и отправляет сигнал на доработку.

Создание такой системы автоматизированной проверки сокращает время верификации, которая раньше занимала у человека 5 часов, до менее чем 10 минут. Механическая оценка хладнокровна, но именно она повышает предсказуемость системы.

Оптимизация затрат с помощью Anthropic Prompt Caching

Как только цикл агентов запускается, токены накапливаются со страшной скоростью. Повторная отправка системных инструкций и определений инструментов каждый раз — это выбрасывание денег на ветер. Кэширование промптов в Claude позволяет платить за кэшированные токены лишь около 10% от стандартного тарифа. Чтобы воспользоваться этим преимуществом, используйте стратегию сопоставления префиксов, располагая структуру промпта от статических частей к динамическим (Tools → System → Messages).

• Разместите неизменяемые инструкции и определения инструментов в самом верху и установите точку прерывания cache_control.
• В сообщениях пользователя используйте теги <system-reminder> для вставки переменной информации. Это необходимо, чтобы не нарушить кэш верхнего префикса.
• Стратегически расставляйте дополнительные точки прерывания каждые 20 блоков окна просмотра (look-back window) при затяжных диалогах.

Правильно спроектированная стратегия кэширования может снизить затраты на вызовы API до 90%. Скорость ответа также заметно увеличится. Это единственный способ сэкономить и деньги, и время.

Проектирование автоматического выключателя (Circuit Breaker) для предотвращения бесконечных циклов

Если Generator и Evaluator упрямятся и не могут прийти к согласию, агент попадает в тупик (deadlock). Это не просто ошибка, а катастрофа, ведущая к резкому росту расходов. Чтобы предотвратить это, необходим многоуровневый «автоматический выключатель», отслеживающий количество итераций и сходство ответов. В частности, если косинусное сходство между предыдущим и текущим ответами составляет 0.95 или выше, это явный сигнал того, что агент повторяется и глупо ходит по кругу.

1. Добавьте в основной цикл счетчик, ограничивающий максимальное количество ходов за одну сессию (Max-Turn Limit) до 15.
2. Установите лимит бюджета на сессию (Budget Cap) и отслеживайте его в реальном времени на API-шлюзе.
3. При срабатывании выключателя немедленно отправляйте краткое резюме трассировки выполнения в Slack и запрашивайте вмешательство человека (Human-in-the-loop).

Давать агенту полный карт-бланш — это не смелость, а безответственность. Системы агентов без предохранителей лучше вообще не эксплуатировать.

Дашборд наблюдаемости специально для команд агентов

Процесс совместной работы трех агентов — это «черный ящик». Без понимания того, где возникают узкие места, улучшения невозможны. Подключите систему трассировки, соответствующую стандарту OpenTelemetry, для визуализации потоков сообщений между агентами. Реализация чекпоинтов на базе Redis позволит в случае сбоя системы продолжить работу с последней успешной точки, а не начинать все заново.

Извлекайте значение cache_read_input_tokens из заголовков ответов API и отображайте его на дашборде. Низкий показатель попадания в кэш (cache hit rate) — свидетельство неправильной структуры промпта. Кроме того, метрика скорости сходимости цикла позволит числово доказать эффективность промпт-инжиниринга. Сохранение ID сессий и версий артефактов в PostgreSQL даст возможность детально анализировать, в каких моментах команда агентов сталкивалась с трудностями в прошлом. Агенты, действия которых не фиксируются, никогда не станут умнее.