Переход от ответа к действиям
В течение последних нескольких лет большинство из нас относились к языковым моделям так же, как мы относимся к очень хорошо начитанному коллеге. Ты задаешь вопрос — получаешь ответ, а что будет дальше, зависит от тебя. Такой способ работы тихо заменяется. Теперь интересные задачи — не в том, чтобы заставить модель сказать правильное. Они в том, чтобы заставить систему сделать правильное — на многих этапах, с реальными инструментами, в запутанных средах, где первый план почти никогда не переживает столкновения с реальностью.
В этом и заключается агентная инженерия. Это дисциплина проектирования, сборки и эксплуатации систем, в которых модель не просто генерирует текст, а выполняет действия, оценивает результаты и решает, что делать дальше, пока не будет достигнута цель. Модель по-прежнему находится в центре событий, но теперь она — один компонент внутри более крупной машины, и большинство реальной сложности живет во всем, что находится вокруг нее.
Этот сдвиг важен, потому что различаются навыки. Написание промптов вознаграждает за удачные формулировки. Агентная инженерия вознаграждает то, что всегда делало ПО надежным: четкие интерфейсы, хорошую наблюдаемость, разумное обращение с ошибками и плотный цикл между тем, что вы выпускаете, и тем, чему вы учитесь. Единственный по-настоящему новый ингредиент — непредсказуемый компонент, который сидит в самом центре всего этого.
Что такое агент на самом деле
Слово «агент» растягивают так, чтобы охватить почти что угодно, поэтому стоит быть точными. Агент — это система, которая преследует цель, многократно выбирая действия на основе того, что она наблюдает, а не следуя фиксированному сценарию. Определяющая особенность — цикл, а не «интеллект». Термостат следует правилу. Агент принимает решение.
Полезно рассматривать автономность как спектр, а не как «да или нет». На одном конце — один вызов модели, который классифицирует письмо. Чуть дальше — конвейер, который связывает несколько вызовов в фиксированном порядке; это полезно, но все еще запрограммировано. Еще дальше — модель выбирает, какой инструмент вызывать и когда, и продолжает работу, пока не решит, что задача сделана. На другом конце система ставит собственные подцели, управляет собственной памятью и работает часами. Большинство систем в продакшене сегодня находится где-то посередине, и обычно это и есть правильное место, потому что полноценная автономность редко является тем, что реально нужно решаемой задаче.
Понять, где именно ваш процесс находится в этом спектре, — одно из самых проясняющих действий, которые можно сделать в самом начале. Это подсказывает, насколько можно опираться на суждение модели, сколько структуры нужно навязать и где будет концентрироваться риск.
Цикл агента
Снимите названия фреймворков и маркетинг — и почти каждый агент запускает один и тот же цикл. Он собирает контекст о своей ситуации, рассуждает о том, что нужно делать, выполняет действие и наблюдает, что произошло. Затем цикл повторяется, используя то, чему он только что научился, пока не будет достигнута цель или пока он не сдастся.
Каждый проход через этот цикл — точка принятия решения, а точки принятия решения — там, где все идет либо правильно, либо неправильно. Хороший цикл агента — не тот, у которого самая «хитрая» подсказка. Он тот, где каждому этапу достаточно информации, чтобы принять обоснованное решение — и не больше. Дайте модели всю историю того, что произошло, — и она потеряет нить. Дайте слишком мало — и она будет действовать вслепую. Большое мастерство — в том, чтобы решить, что именно модель получает видеть на каждом шаге.
Цикл также объясняет, почему создание агентов ощущается так по-другому, чем обычная разработка ПО. В обычном коде вы можете рассуждать о каждом пути. Здесь модель может выбрать путь, которого вы никогда не представляли, восстановиться после ошибки способом, который вы не планировали, или уйти в направлении, которое выглядит разумным три шага подряд, а затем рассыпается. Вы не пишете сам путь. Вы формируете пространство возможных путей и пытаетесь сделать хорошие пути легкими для обнаружения.
Анатомия агента
Полезно представить агента как небольшое набор частей, каждая из которых делает одну работу. Есть модель, которая поставляет рассуждения и язык. Есть инструменты, которые позволяют системе действовать в мире и читать ответ обратно. Есть память и контекст, которые несут релевантную информацию в каждое решение. И есть оркестрация вокруг всего этого: она запускает цикл, накладывает ограничения и решает, когда остановиться.
Что бросается в глаза, когда вы соберете несколько таких систем, так это то, как мало тяжелой работы связано непосредственно с самой моделью. Модель — в основном фиксированный выбор. Вы выбираете одну, формулируете ей промпт и идете дальше. Инженерные усилия уходят в части вокруг нее. Хорошие инструменты, хорошая обработка контекста и хорошая оркестрация — это то, что отличает демо, которое работает один раз, от системы, которую можно оставить в работе. Команды, которые слишком суетятся вокруг формулировок промптов и при этом пренебрегают остальным, обычно создают вещи, выглядящие впечатляюще во вторник, а к пятнице уже сломаны.
Инструменты и контекст — это настоящая поверхность
Если цикл — это скелет, то инструменты и контекст — там, где инженерия происходит на практике.
Инструмент — это руки модели. Через него агент читает базу данных, отправляет сообщение, выполняет запрос или перемещает файл. Качество ваших инструментов задает жесткий потолок того, что агент вообще может сделать, а дизайн инструментов, как выясняется, — это ремесло само по себе. Хороший инструмент делает одно понятное дело, имеет имя и описание, которые точно подсказывают модели, когда именно к нему обращаться, проверяет входные данные и возвращает результаты, с которыми легко действовать. Туманный инструмент с неоднозначным описанием хуже, чем вообще отсутствие инструмента, потому что модель будет использовать его уверенно и неправильно. Забота, которую вы вложили бы в проектирование интерфейса для компетентного, но нового коллеги, примерно соответствует той заботе, которую заслуживает инструмент, потому что это примерно та же ситуация.
Контекст — вторая половина. Модель знает только то, что вы ставите перед ней, так что на каждом шаге вы отвечаете на тихий вопрос: что модели нужно увидеть прямо сейчас, чтобы выбрать хорошо? Отсюда и происходит фраза «инженерия контекста», и это стало одной из центральных проблем в области. Наивный подход — продолжать запихивать в окно еще больше: историю, документы, инструкции. Это не масштабируется. Внимание размывается, затраты растут, и модель начинает пропускать именно ту вещь, которая действительно была важна. Лучший подход рассматривает контекст как бюджет, который нужно тратить целенаправленно. Вы извлекаете релевантное, кратко суммируете старое, убираете завершенное и держите рабочее множество небольшим и точным. Правильно настроить это — часто разница между агентом, который остается связным на протяжении долгой задачи, и тем, который постепенно теряет нить.
Почему агенты сложны
Вот неприятный факт, который в итоге обнаруживает каждая команда. Один вызов модели достаточно надежен. Свяжите вместе двадцать таких — и небольшие вероятности ошибок накапливаются в системы, которые чаще терпят неудачу, чем добиваются успеха.
Арифметика беспощадна. Если каждый шаг в задаче из десяти шагов верен в 95% случаев, то вся задача будет успешной примерно в 60% случаев — и это при допущении, что ошибки независимы, а так бывает далеко не всегда. Одна плохая наблюдательная ситуация в начале может отравить каждое последующее решение. Это наибольшая причина, почему агенты, которые сногсшибательно выглядят в демо, в продакшене начинают буксовать. Демо — это один счастливый путь. Продакшн — это десять тысяч путей, а «длинный хвост» полон входными данными, о которых никто не подумал.
У режимов отказа со временем появляется собственный характер — когда вы увидите их достаточно, чтобы привыкнуть. Агенты застревают в циклах, снова и снова вызывая один и тот же инструмент и ожидая другой ответ. Они галлюцинируют инструмент или результат, которого не было. Они объявляют успех, хотя ничего не сделали. Они тихо выполняют неправильную задачу с полной уверенностью. Ни один из этих случаев — не баг, за которым можно погнаться по stack trace. Это поведение, против которого нужно проектировать, которое нужно уметь распознавать, и от которого нужно уметь восстанавливаться аккуратно. Принять это заранее — вместо надежды, что более хорошая модель все исчезнет сама — и отличает команды, которые реально выкатывают агентов, от команд, которые их только демо-ят.
Evals и наблюдаемость
Если агенты терпят неудачу незаметно, накапливаясь и непредсказуемо, то самое важное, что вы можете построить, — это не сам агент. Это способность видеть, что он делает, и измерять, делает ли ваши изменения его лучше.
Наблюдаемость — в первую очередь. Вы не можете отлаживать то, чего не видите, и рассуждения агента по умолчанию невидимы. Каждый запуск должен оставлять след: что агент видел
