Агентские фреймворки больше не нужны

Мне стали часто попадаться видео автора Jake Van Clief, который в каждом видео говорит, что LangChain и прочие агентские фреймворки — это пустая трата времени, и что для разработки агента достаточно написать несколько .md-файлов.

И я не смог не попасться на такой кликбейт, особенно если учесть, что я уже два года на LangChain разрабатываю. Вдруг я и правда зря время потратил))
Пришлось погрузиться в статью этого автора на arxiv.org, чтобы в этом разобраться. Оказалось, это был не совсем кликбейт.

Interpretable Context
Methodology
Вообще это скорее маркетинговое название подхода, а не термин. А идея подхода состоит в том, что для построения поэтапного пайплайна работы агента достаточно воспользоваться пронумерованными папками, которые и будут являться шагами этого пайплайна.

В каждой папке лежит свой промпт, которому агент должен следовать на текущем этапе, и описание контракта на вход и на выход. И какие-нибудь скрипты, которые на этом этапе нужно выполнить.

Конечно, лучше всего это работает с Claude или чем-то похожим — для этого подхода нужен агент, способный ходить по папкам и читать .md-файлы с контекстом.

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

Во-вторых, при переходе на каждый последующий этап контекст из нужного файла попадёт в конец контекстного окна, что должно исключать Lost in the Middle.

В-третьих, если вдруг вам понадобится поменять шаги пайплайна местами, то достаточно просто переименовать папку с этим этапом. Не придётся заново инженирить обвязку, переносить тулы, менять схемы полей местами и т. д.

Неким подобием observability будут служить те же .md-файлы, которые будут создаваться на выходе на каждом этапе. И их же при необходимости можно поправить руками в VS Code перед тем, как агент приступит к следующему этапу и загрузит их в контекст.

В чём минусы, или почему агентские фреймворки всё-таки нужны
В статье честно говорится, что у подхода есть ряд ограничений: например, ICM последовательный buy design, параллельные вызовы LLM в нем не настроить. В нём нет отказоустойчивости: ни ретраев, ни фоллбэков, только ручной перезапуск. Нет алгоритмических проверок structured_output, нет четкого роутинга, нет многопользовательскости. Энтерпрайз решение на .md-файлах пока что не построишь.

Для чего тогда нужен ICM?
Лично я использую этот подход как один из способов написания скиллов для Claude и гигакода.
Он удобен в случаях, когда от скилла требуется поэтапное выполнение инструкций, когда нужна возможность валидировать и править промежуточные результаты, или если вам важно не подмешивать в LLM лишний контекст раньше времени.

В репозитории ICM есть несколько примеров таких скиллов.

Я для прикола решил по образу и подобию собрать пайплайн поиска инфы в интернете через гигакод. Ходит теперь, чейньжлоги с гитхаба собирает для меня, статьи с хабра и посты с реддита, агрегирует это всё, а потом собирает дайджест.

На LangChain я бы точно поленился это писать))