Кажется, что все приходят к единой архитектуре агентов: LLM, работающая в цикле, вызывающая инструменты, работающая в песочнице. Claude Code — пожалуй, первое заметное проявление этого подхода — вышла более полутора лет назад. Deep Agents, наша инфраструктура для агентов, была запущена более года назад. Этот паттерн развивается ужекоторое время.
В самой по себе такой сходимости нет ничего плохого, однако среди некоторых AI-инженеров, с которыми я общался в последнее время, это привело к возникновению мнения, что «все сложные проблемы уже решены» или что «больше нет новых проблем AI-инженерии для решения».
Когда люди высказывают такое мнение, я думаю, они в основном имеют в виду практики контекстной инженерии, которые мы используем для обеспечения работы агентов. И отчасти они правы — существует множество относительно стандартных решений в области контекстной инженерии, к которым мы все пришли:
- Суммаризация длинных веток, когда контекстное окно начинает переполняться
- Выгрузка результатов крупных вызовов инструментов
- для прогрессивного раскрытия информации
- Поиск по инструментам для работы с большим количеством инструментов
- для изоляции контекста
- Bash в качестве основного инструмента
Хорошая новость (для энтузиастов контекстной инженерии, подобных мне) заключается в том, что мы наблюдаем качественный скачок в возможностях агентов или по крайней мере в том, как они используются. В частности, за последние несколько месяцев каждый разработчик агентов, с которым я общался, размышлял о проактивных, работающих постоянно, ориентированных на цели агентах. Ядро такого агента во многом схоже с агентами для написания кода, но здесь возникает и ряд новых задач. Ниже я выделяю некоторые из них. У нас (в LangChain и в индустрии в целом) не обязательно есть решения (или по крайней мере общие решения) для них, поэтому размышления над ними доставили мне наибольшее удовольствие за последнее время!
Как быть проактивным и не раздражать: эти проактивные агенты работают в фоновом режиме, либо прослушивая потоки событий, либо просыпаясь по сигналам таймера. С одной стороны, они должны иметь возможность доносить информацию до пользователя — это создает ощущение помощи. С другой стороны, если отправлять пользователю слишком много уведомлений, вы рискуете перегрузить его. Настройка этого процесса для обеспечения приятного пользовательского опыта (не слишком много, не слишком мало) по-прежнему остается сложной задачей контекстной инженерии!
Память: память для агентов — это то, о чем мы уже некоторое время говорим с разработчиками. Системы памяти в конечном итоге состоят из двух частей: базовой структуры данных и интеллектуального слоя (агента) вокруг этих данных. Структуры данных зачастую довольно просты (файлы, одна строка). Самая сложная часть интеллектуального слоя — это определение того, что именно следует запоминать. Как и в случае с проактивностью, легко впасть в крайности (ничего не запоминать или сохранять слишком детализированную информацию). Поскольку этот интеллектуальный слой, решающий, что запоминать, часто сам является (простым) агентом, контекстная инженерия вокруг того, что и когда запоминать, остается открытой проблемой.
Асинхронность: эти агенты работают все дольше и дольше, взаимодействуя с другими системами (tools, другими агентами), которые в свою очередь также работают все дольше и дольше. Тем не менее, почти всегда необходимо обеспечивать, чтобы основной агент, взаимодействующий с пользователем, быстро реагировал на новые сообщения. Все это приводит к архитектуре, при которой больший объем работы выполняется в асинхронных инструментах и субагентах. Это порождает ряд новых задач контекстной инженерии: как уведомить основного агента о завершении этой работы? Как обрабатывать ситуации, когда основной агент все еще работает, по сравнению с теми, когда он завершил работу? Что делать, если он приостановлен в ожидании одобрения человека?
Отслеживание целей: агенты переходят от выполнения задач к работе над достижением целей. Такие агенты, как Hone, являются прекрасным тому примером. Как проектировать агентов, которые могут разбивать цели на более мелкие шаги, проводить эксперименты, получать обратную связь и продолжать итерации для достижения более масштабной цели? Сложно заставить агентов пробовать новые эксперименты в стремлении к цели (а не просто повторять действия). Сложно заставить агентов думать о широких целях, а не только о мелких задачах. Сложно поддерживать их согласованность на больших временных горизонтах.
Выравнивание ( Alignment): связано с предыдущим пунктом. Проектирование целей само по себе является сложной задачей. Пользователям будет очень сложно сформулировать цели так, чтобы агенты не могли их обойти. Если агенты будут слепо пытаться оптимизировать цель, они могут ее достичь, но при этом могут схитрить способами, которые мы не можем предвидеть. Например: классический пример «избавиться от всех багов в кодовой базе» → полностью удаляет кодовую базу (нет кода — нет багов). Как спроектировать инфраструктуру, которая будет удерживать агентов не только сосредоточенными на целях, но и не позволяющих им чрезмерно оптимизировать эти цели.
Использование браузера: для агентов-программистов наиболее важным инструментом был bash-инструмент, способный запускать и выполнять код. Для многих из этих агентов общего назначения таким инструментом становится браузер. Управлять браузером гораздо сложнее, чем терминалом! Взаимодействуете ли вы с изображениями или с DOM? И то, и другое — крупные объекты; как управлять контекстом в связи с этим? Это лишь некоторые из возникающих вопросов.
Еще несколько месяцев назад я бы, пожалуй, согласился с тем, что в контекстной инженерии осталось не так много открытых вопросов. Но с появлением этих постоянно работающих проактивных агентов мы видим, как возникает целый ряд новых задач! Какое прекрасное время для жизни.
