В прошлом году я написал пост о том, как искать литературу при помощи OpenAlex и NotebookLM. Там описан дешевый (если не бесплатный) способ, который, по иронии судьбы, я перестал использовать спустя пару месяцев после публикации. Данная заметка — это переосмысление прошлогоднего материала в эру ИИ-агентов.

Мир меняется очень быстро (линк), и появление агентов совершило революцию, мне лично кажется, схожую с релизом ChatGPT на основе GPT-3.5 в ноябре 2022 года. Сложно сказать, когда именно эта революция случилась, да и нужно ли это. Недавно OpenRouter опубликовал данные о том, что 6 февраля 2026 года основной поток токенов стал идти через агентов. Вот, вероятно, тот день, когда использование агентов стало массовым. Весь 2026 год инструменты поиска и разработки подстраиваются в первую очередь под агентов, а не под людей. И как в свое время почил StackOverflow, так все и пророчат смерть GitHub. А научным сотрудникам и всем, кто занимается исследованиями, надо подстраиваться под меняющиеся инструменты.

В этом посте я хочу рассказать про опыт работы в Feynman — терминальном харнессе, который был разработан специально для проведения научных исследований (звучит громко, но это их слоган). Сразу скажу, что Feynman не идеальный инструмент, далекого будущего у которого, мне кажется нет (уверен, что в 2027 будет 3ья версия этого поста, с новыми инструментами 🤗). Но я нахожу Feynman самой удачной реализацией агентского литобзора на данный момент. Подход, который там реализован, до конца года точно останется актуальным.

TL;DR

Feynman — терминальный харнесс для научных исследований на базе Pi. Воркфлоу /lit и /deepresearch запускают четырех субагентов (Researcher, Writer, Verifier, Reviewer). Они собирают источники, пишут черновик, проверяют ссылки и рецензируют текст. Главная идея заключается в том, чтобы не держать все в одной модели. Как вариант, роли можно распределить между моделями подписки OpenCode Go ($10/мес) по бенчмаркам AA-Omniscience (галлюцинации) и AA-LCR (длинный контекст). Для сбора данных (ака Researcher) подойдет честный и дешевый MiniMax-M3, для проверки (Verifier) — честная и дешевая модель другого семейства, например, Qwen3.7 Plus. Для рецензента и оркестратора лучше взять разные модели более высокого класса. GLM-5.2 и Grok 4.5 отлично подходят.

Feynman

Очевидно названный в честь Ричарда Ф. Фейнмана, этот харнесс построен на базе Pi ❤️(про который надо сделать отдельный пост, кстати). К минимальному набору инструментов, доступных в Pi, в Feynman добавили веб-поиск через Exa/Google/Perplexity, поиск по alphaXiv и OpenAlex, субагентов, парсинг документов и еще пару инструментов, необходимых для корректной работы.

Feynman можно использовать как обычный харнесс, работающий по принципу BYOK. Но разработчиком задумывалось, что вы будете использовать заранее прописанные воркфлоу на основе скиллов (что такое скиллы — см. тут). Их там порядка десяти штук, но нас интересуют в первую очередь /deepresearch и /lit с говорящими названиями. Большой разницы между ними я не вижу, кроме того, что /lit отдает предпочтение научной литературе, а /deepresearch не ранжирует веб, репозитории и литературу. Работу всех воркфлоу обеспечивают четыре агента:

• Researcher — сбор данных из статей, веб-ресурсов, репозиториев и документации.
• Writer — подготовка структурированных черновиков на основе исследовательских заметок.
• Reviewer — внутренняя критическая оценка исследований с комментариями по степени значимости замечаний.
• Verifier — проверка внутритекстовых ссылок, верификация URL источников и удаление нерабочих ссылок.

Задумано, в целом, все просто прекрасно. Вы вызываете скилл /lit, пишете что вас интересует, и дальше основной агент (т.н. оркестратор, тот в котором вы начали сессию) запускает субагентов согласно воркфлоу. Сначала оркестратор разбивает ваш промпт на отдельные вопросы, определяет топики и запускает несколько агентов класса Researcher. Те идут в интернет, смотрят на локальную базу (если есть) и записывают на диск результаты своих изысканий. Потом наступает очередь Writer, который синтезирует все в один черновик на диске со ссылками на источники.

Дальше моя любимая часть — Verifier. Этот субагент проверяет, правильно ли Researcher и Writer обработали источники. Вы удивитесь тому, насколько много он находит косяков. Его задача не только проверить цитирования, но и удалить из черновика тезис, если его ничем подкрепить нельзя. В конце концов наступает черед Reviewer, который критически рецензирует получившийся текст на наличие ошибок. Если Verifier проверяет, правильно ли информация (чаще всего цифры) из источника перекочевала в черновик, то Reviewer ищет более глубокие несостыковки.

Например, я делал литобзор по реке Раздольная в Приморском крае. Агент Writer почему-то написал, что р. Раздольная — это приток реки Амур, а на деле она впадает в Амурский залив Японского моря. Это заметил именно Reviewer, а Verifier пропустил.

После окончания рецензии агент-оркестратор исправляет косяки, и через какое-то время ваш обзор в формате .md готов. Прекрасно, скажете вы, где кнопка скачать? Поначалу хочется бросить все, добавить свою подписку Codex и начать поиск литературы, используя фронтир модели (подписку Claude Code добавить, увы, нельзя никуда 🤷‍♂).

Но не все так просто. Во-первых, с рабочим контекстным окном моделей от OpenAI в 272k токенов вы упретесь в потолок после прочтения первого десятка статей. Это не говоря о том, что стоить это будет ощутимо. Еще одна проблема в том, что пока нельзя искать информацию, вытаскивать ее из источника, проверять и писать на основе этого выводы внутри одной сессии. Такой подход не только увеличивает риск галлюцинаций и перегрузки контекста, но и ведет к потере информации посередине (т.н. эффект lost in the middle (Liu et al., 2023)). Модели хорошо работают с данными в начале и в конце сессии, но систематически теряют то, что в середине. В третьих, смесь агентов из разнородных моделей стабильно обходит одну фронтир модель (правда при росте токенов, см. Wu et al. (2026)).

Кстати, модели от OpenAI обладают одними из самых высоких процентов галлюцинаций на рынке. Об этом подробнее ниже.

Помучавшись с Feynman несколько месяцев, я выработал для себя протокол, который меня устраивает и по цене, и по результату. Ниже я показываю, как я решил распределение ролей для запуска литобзора практически на ежедневной основе.

OpenCode Go

Вместо подписки Codex я использую подписку Go от Anomaly, компании разрабатывающей харнесс OpenCode. За $10 USD в месяц (а первый месяц вообще $5 USD) она дает токенов на $60 USD в месяц. Лимиты на них распределены как на картинке ниже (подробнее тут). До недавнего времени там были исключительно китайские модели, и только летом стали появляться американские (Grok 4.5 и GPT 5.6 Luna).

Я лично очень люблю эту подписку (в конце поста рефералка 😉), потому что за небольшие деньги она дает пользователю попробовать все современные китайские разработки (при этом модели хостятся в США, кроме DeepSeek) и доступна из РФ. Однако в данном случае намного интереснее то, что подписка дает доступ сразу к ряду семейств моделей, которые отлично дополняют друг друга в Feynman.

Смотря на распределение лимитов, да и на данные пользования подпиской Go, как будто бы логично для Feynman использовать DeepSeek V4 Pro/Flash. Быстрая и дешевая модель, с 1М контекста. Но я хочу предостеречь от этого, потому что DeepSeek — это лидер галлюцинаций. Это может быть не так заметно для агентских задач и написания кода, но очень важно для поиска и синтеза информации.

Галлюцинации в данном случае — это когда модель вместо того, чтобы признаться, что не знает или не нашла информацию, начинает придумывать и нести чушь. Обычно это измеряется как частота случаев, когда модель отвечает неверно, хотя должна была отказаться от ответа или признаться в незнании. Показатель определяется как доля неверных ответов среди всех ответов, кроме правильных, то есть: incorrect / (incorrect + partial answers + not attempted).

Для задач литобзора модели должны быть в первую очередь честными. То есть с минимумом галлюцинаций и уметь удерживать длинный контекст. Сложно дать какие-то рекомендации по выбору конкретных моделей, потому что они меняются чуть ли не ежедневно. Каждый день на OpenRouter появляется 1.5 новые модели, пока я писал этот пост, уже успели выйти Grok-4.6, Gemini-3.7-Flash, GLM-5.3 и DeepSeek-V4-Pro-0813. То же касается и бенчмарков. Кому верить, Artificial Analysis, Vals.ai, Vulcan Bench или Terminal Bench?

На момент написания поста, для себя я остановился на AA-Omniscience: Knowledge and Hallucination Benchmark и Long Context Reasoning Benchmark от Artificial Analysis. Первый не следует путать с популярным Artificial Analysis Index от той же компании. Бенч AA-Omniscience показывает то, как модели отвечают на научно-практические вопросы. Второй показывает как раз то, как модели держат контекст и вытаскивают информацию из больших текстов. Мне показались их результаты сравнимыми с моими личными ощущениями. Согласно бенчмарку AA-Omniscience, модели из OpenCode Go распределены следующим образом.

В правом нижнем углу собраны модели, у которых правильных ответов было больше, чем неправильных, и мало галлюцинаций. В верхнем левом — наоборот. Для меня удивительным оказалось наличие в зеленом квадранте модели MiniMax-M3, релиз которой в мае прошел абсолютно мимо меня. Поразительно, что именно MiniMax-M3 входит в тройку лидеров этой подписки и на втором бенчмарке. При этом видно, как аналогичные дешевые модели может быть и превосходят по AA Index (один из самых популярных комплексных бенчмарков), очень ненадежны и непостоянны.

Распределение ролей

Опираясь на вышеуказанные бенчмарки, я распределил модели по ролям следующим образом. Это делается либо командой /feynman-model непосредственно в харнессе, либо правкой front matter в инструкциях агентов, то есть файлов в директории ~/.feynman/agent/agents/.

main (default): opencode-go/glm-5.2
researcher: opencode-go/minimax-m3
reviewer: xai/grok-4.6
verifier: opencode-go/qwen3.7-plus
writer: default

Оркестратор
Оркестратор или дефолтная модель сессии должна быть достаточно умной, чтобы смочь сформировать структурированные запросы для агентов-исследователей. Дополнительно она должна иметь окно контекста минимум 500k, чтобы вместить весь воркфлоу. По-хорошему надо выбирать какую-то из фронтир-моделей. Я получал приличные результаты как с GLM-5.2 (high), которые есть в подписке, так и с Grok-4.6 (high) (из SuperGrok). Уровень размышлений я поставил на high.

Researcher
Этот агент по сути рабочая лошадка всего воркфлоу Feynman. Тут нужна модель, которая обладает большим контекстом (в который может уместиться около 10+ статей), умеет его держать и мало придумывает. При этом сильно умной она быть не должна, задача у нее достаточно простая. Дополнительно, поскольку через нее идет основной поток токенов, она должна быть дешевой. Вы, наверное, поняли, что я выбрал MiniMax-M3 🤗. Касательно уровня размышлений, я поставил medium, потому что длинной цепочки мыслей ей не нужно. Таким образом, заголовок файла ~/.feynman/agent/agents/researcher.md у меня выглядит так:

---
name: researcher
description: Gather primary evidence across papers, web sources, repos, docs, and local artifacts.
model: opencode-go/minimax-m3
thinking: medium
<!-- Остальная часть файла без изменений -->

Verifier
Задача этого агента, в целом, очень похожа на Researcher, в плане удержания контекста и галлюцинаций, только вызывается она меньше раз. Меня так и подмывало выбрать снова MiniMax-M3, но все же лучше проверка происходит моделью другого класса. Я остановился на Qwen3.7 Plus, которая в целом похожа по метрикам на MiniMax-M3, только тупее, с большей фантазией и ± той же стоимости (запросов в час в Go разрешено больше, но цена за 1М токен выше). Смотря на бенчмарки, кстати, MiMo-V2.5 как будто тоже может быть неплохим вариантом. Я не пробовал. Уровень размышлений, опять же можно понизить до medium, тут больших chain-of-thoughts нам не нужно. Заголовок файла ~/.feynman/agent/agents/verifier.md:

---
name: verifier
description: Post-process a draft to add inline citations and verify every source URL.
model: opencode-go/qwen3.7-plus
thinking: medium
<!-- Остальная часть файла без изменений -->

Writer
Этот субагент вызывается ровно один раз для записи черновика на примерно 300-500 LoC. Я не стал давать специальную модель для этой роли, у меня она наследует модель оркестратора. Уровень размышлений — medium (поставить в файле ~/.feynman/agent/agents/writer.md).

Reviewer
Для модели рецензента я выбрал самую умную модель из списка OpenCode Go — Grok 4.5 (high). Если у вас есть подписка Codex, сюда отлично подойдет GPT-5.6-Sol, если SuperGrok — Grok 4.6. Тут нужна способная модель, которая на основании своих внутренних знаний найдет проблемные участки. Лучше выбрать модель другого класса, отличную от оркестратора и писателя. Файл ~/.feynman/agent/agents/reviewer.md начинается так:

---
name: reviewer
description: Run tough but constructive internal research critique of an AI research artifact.
model: xai/grok-4.6
thinking: high
<!-- Остальная часть файла без изменений -->

Tweaks

Помимо распределения моделей по ролям, я эмпирическим путем нашел некоторые небольшие tips&tweaks, которые сделали работу с Feynman лучше для меня.

• Модель-оркестратор постоянно хочет делать поиск сама. Это нормальное желание, особенно если контекст и бюджет позволяют. Но меня это расстраивало, так как лимиты улетали в космос. Поэтому я добавил ограничения в ~/.feynman/agent/AGENTS.md через следующие правила, чтобы поиск шел только через Researcher.

Don't gather evidence. Spawn a `researcher` for any search, fetch, paper, or database lookup — even one citation. Lead work is plan, spawn, read their files, synthesize.

• Поскольку Feynman основан на Pi, все дополнения Pi можно поставить и в Feynman. Маркетплейс плагинов огромен, все не перепробуешь. Я добавил pi-fff, который заменяет fd и grep на fffind и fffgrep соответственно, ускоряя поиск файлов и поиск по контенту (ссылка на репозиторий). Разработчик как-то писал про 1000x ускорение. Я честно такого не замечал, но работает действительно шустро. Особенно полезно на этапе синтеза и проверки, когда агенту нужно искать информацию в скачанном корпусе статей. Команда feynman install npm:@ff-labs/pi-fff не сработает, проще добавить запись в ~/.feynman/agent/settings.json в "pacakges". При следующем запуске Feynman библиотека установится сама.

• Очень удачно аккурат под написание поста Firecrawl выпустил свой Research Index и сделал его бесплатным. Это быстрый семантический поиск по PubMed, bioRxiv, medRxiv и arXiv. Корпус смещен в сторону наук о жизни, но в PubMed встречаются и отдельные статьи из других сфер. Он отчасти дублирует "Feynman Bio Tools", а в свежем релизе Feynman v0.3.22 даже вроде добавлен в web-search, я еще не обновлялся. В любом случае, чтобы дать агенту этот скилл, я установил /firecrawl-research-index и добавил в ~/.feynman/agent/AGENTS.md:

Don't use alphaxiv. Add `/firecrawl-research-index` to the other literature tools (exa, Gemini, etc.); it doesn't replace them.

Минусы

На деле все не так радужно, как может казаться. Feynman — это чистый вайбкодинг-продукт со всеми присущими косяками. У него соло-разработчик, который просто игнорирует issues и PR. С каждым новым релизом что-то ломается, поэтому я стараюсь не обновляться без необходимости. А релизов порой очень много, иногда по несколько раз в день.

У меня постоянно чешутся руки, чтобы взять и переписать все на базе Pi, с GUI и меньшими костылями. Дайте знать если кто-то еще хочет заколлабиться.

Отдельная боль — это поиск по alphaXiv. Идея поиска прекрасная, но реализация автором Feynman через https://github.com/companion-inc/alpha-hub тоже суперкосячная и совершенно не следует принципам OSS. Там тоже мертвые issues и PR, комьюнити просто начало форкать и придумывать костыли.

Надо признать, что субагенты часто висят и не возвращают информацию. Их поведение меняется от релиза к релизу и от модели к модели. Но чаще всего, как я заметил, причиной является тот самый поиск alphaxiv_search. Проблема в том, что он может разлогиниться в сессии субагента или вернуть пустые массивы, что почему-то приводит субагентов в ступор. Я в итоге просто отключил alphaXiv совсем.

Даже с диверсификацией ролей по моделям поиск все равно очень токенозатратный. У меня влезает два литобзора в 5-часовые лимиты OpenCode Go. Ниже показаны примерные сессии.

Итоги

В качестве результатов посмотрите на пример двух сессий Feynman. Первая сессия была до того, как я ввел ограничения на поиск информации только через субагента, а дефолтной моделью был Grok 4.6. Вторая сессия — это сетап из данного поста, который показался мне оптимальным, с дефолтом на GLM-5.2 и рецензентом на Grok 4.6. По моим замерам это наиболее показательная сессия с характерными тратами. В среднем каждый из агентов Researcher, Verifier и Reviewer тратит по 1М токенов. С оркестратором ситуация всегда разная, так как она зависит от формулировки изначального промпта и качества найденного материала.

Если сравнить первую и вторую сессии, то видно, что если дать волю быстрой фронтир модели оркестратору (Grok 4.6), то он начнет искать информацию сам, пока более медленные модели класса Researcher что-то там шерстят в своем темпе. Поэтому вводить ограничения в AGENTS.md мне кажется обязательным. А вот выбор основной модели между GLM, Grok или Opus, если бюджет позволяет, остается вопросом предпочтений и личных ощущений.

P.S.

Держите рефералку на OpenCode Go (https://opencode.ai/go?ref=C4T1JT082C) которая дает вам первый месяц пользоваться бесплатно (т.е. дарит $5 USD) и без ВПН.