Насчет потерь, я проводил тестирование и процент успешных найденных инструментов не падала, там на гите более подробно все расписано. Но думаю я не все сценарии рассмотрел поэтому буду рад любому фитбеку)
Спасибо! Да, узкие агенты частично решают проблему, но остаются три нюанса:
Потеря автономности: усли задача комплексная (посмотреть логи БД -> поправить код -> пушнуть в Git), вам придется руками переключать агентов и таскать контекст между ними. А хочется дать агенту права на всё и уйти пить кофе.
Сжатие самих схем: даже у 2-3 нужных MCP-серверов сырые JSON-схемы весят неприлично много из-за дублирования. toolc не просто прячет лишнее, он компилирует и физически “сплющивает” схемы, делая их плотнее.
Вендор-лок: Copilot - отличная, но закрытая среда. Шлюз же работает везде: в Cursor, Roo Code или вообще с локальной llama.cpp, где каждый токен на вес золота. Для мелких изолированных тасок Copilot - топ. Но для сложных автономных цепочек без шлюза токены улетают в трубу.
Хаха, справедливое замечание! 😅 Речь, конечно, про математику сгорания токенов на дистанции, а не про то, что я положил в карман тысячу баксов за выходные.
Два момента:
Про "3 дня назад": это дата первого пуша в паблик. Локально шлюз писался, тестировался и экономил мне токены гораздо дольше.
Откуда такие цифры: агенты отправляют список всех тулзов на каждом шаге. У тебя висит 40k токенов схем, агент делает 40 циклов для решения одной таски = 1.6 млн токенов (около $5 по тарифам Claude).
Шлюз срезает 60-80% этого паразитного трафика на каждом запросе. Если гонять автономных агентов каждый день на рефакторинг, набегают огромные суммы!
Спасибо за идеи! Обе фичи - крутые. В текущем релизе v1.0 их пока нет, но с удовольствием забираю обе в бэклог для следующих версий.
@Prikalel (про конвертацию вывода): абсолютно согласен. Сейчас toolc жестко сжимает схемы на входе, но результаты выполнения от серверов возвращает агенту «как есть». Если перехватывать жирные JSON-ответы и на лету конвертить их во что-то компактное перед отдачей в LLM - это сэкономит еще гору токенов на возврате. Забираю в бэклог.
@headliner1985 (про агентную оркестрацию): тоже крутая идея. Сейчас у меня честный stateless-прокси, чтобы не усложнять ядро на старте. А то, что вы описываете - это макро-инструменты: когда модель дергает одну ручку, а шлюз под капотом сам прогоняет нужный цикл вызовов и отдает готовую выжимку, экономя дорогие сетевые раундтрипы к Claude/GPT.
Короче, идеи отличные. Забрал их себе, хочется сделать реально интересный инструмент
Спасибо за ссылку! Да, lazy-mcp я смотрел. Проект классный и бьет ровно в ту же боль: не вываливать на агента весь зоопарк инструментов разом и беречь стартовый контекст.
Но у меня задача стояла шире. Я хотел не просто прикрутить ленивую загрузку к MCP-серверам, а решить проблему комплексно:
Переваривать не только MCP, но и огромные OpenAPI-спеки.
Свести всё это в единый слой с жестким контролем (рулить политиками доступа и отрезать опасные ручки еще до того, как их увидит модель).
Сделать основным режимом быстрый плоский список (flat), а ленивую подгрузку схем (staged) оставить как запасной вариант для самых тяжелых случаев.
Так что lazy-mcp - отличный сфокусированный инструмент. Просто под мой замес из OpenAPI, десятков серверов и желания жестко контролировать то, что в итоге долетает до VS Code, готового решения я для себя не нашел.
Я проверял в отдельном тесте (в исходниках это режим prompt_debias_baseline).
Добавил соло-агенту жесткий промпт: "Обязательно сомневайся и ищи опровержения". И это реально сработало!
Смотрите на цифры (Байесовская ошибка):
Обычный агент: 1.47
Агент, которого заставили сомневаться: 0.67 (в 2 раза лучше)
Слепой судья: 0.09 (в 15 раз лучше)
То есть метод 100% работает. Но есть нюанс. Даже когда мы заставляем агента сомневаться, он всё равно помнит свои прошлые выводы. Он начинает генерировать сомнения "для галочки", чтобы угодить промпту, но в итоге часто всё равно притягивает ответ к изначальной гипотезе.
Вывод: просить сомневаться - это отличный «пластырь», если у вас всего один агент.
Спасибо за развернутый комментарий и отдельный респект за то, что заглянули в исходники! Вы поднимаете абсолютно правильные вопросы методологии. Давайте проясню моменты, которые в статье могли показаться мутными:
1. Про сравнение «теплого с мягким» (разная логика vs размышления)
Мы не сравнивали думающего агента с бездумным судьей напрямую. Мы сделали честную матрицу 2x2 и тестировали режимы внутри одной и той же логики.
В разделе «Инсайт 2» есть график Thinking vs Non-Thinking, на котором четко видно:
Мы взяли same_model_locked_agent и запустили его с размышлениями (регрет 0.15) и БЕЗ размышлений (регрет улетел в 2.26).
Затем мы взяли blind_checker и тоже запустили его с размышлениями (регрет 0.16) и БЕЗ размышлений (регрет 0.10).
То есть мы сравнивали агентов самих с собой. Вывод именно в том, что включение CoT помогает генератору, но вредит верификатору.
2. Про кросс-модельный тест и GPT-5.4
Результаты скрипта run_cross_model_compact.py как раз подробно описаны в предпоследнем разделе статьи - «Фронтир-модели не спасают». Там же есть график Compact Cross-Model Regret. Мы протестировали GPT-5.4 в режимах thinking и non-thinking (это gpt 5.3 instant так как 5.4 без ризонинга нет) и получили ровно тот же паттерн удваивания ошибки при включении размышлений. Про Gemini 3.1 Pro в статье не упоминали, так как на момент тестов ее strict-json endpoint в OpenRouter работал нестабильно (падает с ошибкой схемы при отключении reasoning), поэтому в финальный чарт пошли только модели OpenAI.
3. Про дисперсию, рандом и количество запусков
Вы абсолютно правы про влияние temperature, но здесь архитектура стенда страхует от сильного разброса:
Во-первых, сама среда (ответы тулзов и улики) полностью детерминирована.
Во-вторых, режим non-thinking запускается с temperature = 0.0, то есть он детерминирован на стороне генерации.
В-третьих, R_mean (Байесовский регрет) - это уже усредненная метрика. Стенд прогоняет агента не через одну задачу, а через набор эпизодов (в шоукейсе это 5 прогонов, в полном frozen_harness_v1 - прогон по всему корпусу событий). Мы усредняем ошибку распределения вероятностей на всем датасете, что сглаживает локальные флуктуации от temperature = 0.6 в режиме thinking.
Спасибо за отличный комм! Вы ударили в самую точку. Именно классическая теория синтеза надежных систем из ненадежных элементов стала для нас главным ориентиром.
Ваша «новая задачка» уже в активной разработке у меня :) Мы собрали измерительный стенд и прямо сейчас краш-тестируем разные топологии (Star, Tree, Chain) под атаками на фронтир-моделях. Могу дать небольшой спойлер: результаты оказались весьма контринтуитивными, особенно когда мы включили моделям internal reasoning. Плоские графы рассыпаются совсем не так, как ожидалось. Будет 2 часть и обновленный репо!
Я выше писал, что всё через vllm и докер было запущено. Насчёт Тессеракта: возьмите большую таблицу и текст и посмотрите, что вернёт Тессеракт и в каком формате, а также что вернёт PaddleVL.
Время покажет. На таблицах paddle, всё остальное — VL-модели какие-то, с хорошими промтами. Если задача чисто OCR без проверки и всего остального, можно и что-то попроще. Qwen8b VL отлично справлялся.
Это да, но мощности были ограничены на нашей серверной машине, и не все могут запустить 235 кВ локально. Тут рассмотрены модели, которые используются у нас.
Я думаю, что qwen3 VL большой, например, 235Б, либо же, если касаться только таблиц, paddle VL умеет их отлично распознавать. Там есть настройки, чтобы он понимал ориентацию их, да и вообще довольно гибок в этом плане.
Напишите в лс
Насчет потерь, я проводил тестирование и процент успешных найденных инструментов не падала, там на гите более подробно все расписано. Но думаю я не все сценарии рассмотрел поэтому буду рад любому фитбеку)
Спасибо! Да, узкие агенты частично решают проблему, но остаются три нюанса:
Потеря автономности: усли задача комплексная (посмотреть логи БД -> поправить код -> пушнуть в Git), вам придется руками переключать агентов и таскать контекст между ними. А хочется дать агенту права на всё и уйти пить кофе.
Сжатие самих схем: даже у 2-3 нужных MCP-серверов сырые JSON-схемы весят неприлично много из-за дублирования. toolc не просто прячет лишнее, он компилирует и физически “сплющивает” схемы, делая их плотнее.
Вендор-лок: Copilot - отличная, но закрытая среда. Шлюз же работает везде: в Cursor, Roo Code или вообще с локальной llama.cpp, где каждый токен на вес золота. Для мелких изолированных тасок Copilot - топ. Но для сложных автономных цепочек без шлюза токены улетают в трубу.
Хаха, справедливое замечание! 😅 Речь, конечно, про математику сгорания токенов на дистанции, а не про то, что я положил в карман тысячу баксов за выходные.
Два момента:
Про "3 дня назад": это дата первого пуша в паблик. Локально шлюз писался, тестировался и экономил мне токены гораздо дольше.
Откуда такие цифры: агенты отправляют список всех тулзов на каждом шаге. У тебя висит 40k токенов схем, агент делает 40 циклов для решения одной таски = 1.6 млн токенов (около $5 по тарифам Claude).
Шлюз срезает 60-80% этого паразитного трафика на каждом запросе. Если гонять автономных агентов каждый день на рефакторинг, набегают огромные суммы!
Спасибо за идеи! Обе фичи - крутые. В текущем релизе v1.0 их пока нет, но с удовольствием забираю обе в бэклог для следующих версий.
@Prikalel (про конвертацию вывода): абсолютно согласен. Сейчас
toolcжестко сжимает схемы на входе, но результаты выполнения от серверов возвращает агенту «как есть». Если перехватывать жирные JSON-ответы и на лету конвертить их во что-то компактное перед отдачей в LLM - это сэкономит еще гору токенов на возврате. Забираю в бэклог.@headliner1985 (про агентную оркестрацию): тоже крутая идея. Сейчас у меня честный stateless-прокси, чтобы не усложнять ядро на старте. А то, что вы описываете - это макро-инструменты: когда модель дергает одну ручку, а шлюз под капотом сам прогоняет нужный цикл вызовов и отдает готовую выжимку, экономя дорогие сетевые раундтрипы к Claude/GPT.
Короче, идеи отличные. Забрал их себе, хочется сделать реально интересный инструмент
Спасибо за ссылку! Да,
lazy-mcpя смотрел. Проект классный и бьет ровно в ту же боль: не вываливать на агента весь зоопарк инструментов разом и беречь стартовый контекст.Но у меня задача стояла шире. Я хотел не просто прикрутить ленивую загрузку к MCP-серверам, а решить проблему комплексно:
Переваривать не только MCP, но и огромные OpenAPI-спеки.
Свести всё это в единый слой с жестким контролем (рулить политиками доступа и отрезать опасные ручки еще до того, как их увидит модель).
Сделать основным режимом быстрый плоский список (
flat), а ленивую подгрузку схем (staged) оставить как запасной вариант для самых тяжелых случаев.Так что
lazy-mcp- отличный сфокусированный инструмент. Просто под мой замес из OpenAPI, десятков серверов и желания жестко контролировать то, что в итоге долетает до VS Code, готового решения я для себя не нашел.Я проверял в отдельном тесте (в исходниках это режим
prompt_debias_baseline).Добавил соло-агенту жесткий промпт: "Обязательно сомневайся и ищи опровержения". И это реально сработало!
Смотрите на цифры (Байесовская ошибка):
Обычный агент: 1.47
Агент, которого заставили сомневаться: 0.67 (в 2 раза лучше)
Слепой судья: 0.09 (в 15 раз лучше)
То есть метод 100% работает. Но есть нюанс. Даже когда мы заставляем агента сомневаться, он всё равно помнит свои прошлые выводы. Он начинает генерировать сомнения "для галочки", чтобы угодить промпту, но в итоге часто всё равно притягивает ответ к изначальной гипотезе.
Вывод: просить сомневаться - это отличный «пластырь», если у вас всего один агент.
Спасибо за развернутый комментарий и отдельный респект за то, что заглянули в исходники! Вы поднимаете абсолютно правильные вопросы методологии. Давайте проясню моменты, которые в статье могли показаться мутными:
1. Про сравнение «теплого с мягким» (разная логика vs размышления)
Мы не сравнивали думающего агента с бездумным судьей напрямую. Мы сделали честную матрицу 2x2 и тестировали режимы внутри одной и той же логики.
В разделе «Инсайт 2» есть график Thinking vs Non-Thinking, на котором четко видно:
Мы взяли
same_model_locked_agentи запустили его с размышлениями (регрет 0.15) и БЕЗ размышлений (регрет улетел в 2.26).Затем мы взяли
blind_checkerи тоже запустили его с размышлениями (регрет 0.16) и БЕЗ размышлений (регрет 0.10).То есть мы сравнивали агентов самих с собой. Вывод именно в том, что включение CoT помогает генератору, но вредит верификатору.
2. Про кросс-модельный тест и GPT-5.4
Результаты скрипта
run_cross_model_compact.pyкак раз подробно описаны в предпоследнем разделе статьи - «Фронтир-модели не спасают». Там же есть графикCompact Cross-Model Regret. Мы протестировали GPT-5.4 в режимах thinking и non-thinking (это gpt 5.3 instant так как 5.4 без ризонинга нет) и получили ровно тот же паттерн удваивания ошибки при включении размышлений. Про Gemini 3.1 Pro в статье не упоминали, так как на момент тестов ее strict-json endpoint в OpenRouter работал нестабильно (падает с ошибкой схемы при отключении reasoning), поэтому в финальный чарт пошли только модели OpenAI.3. Про дисперсию, рандом и количество запусков
Вы абсолютно правы про влияние temperature, но здесь архитектура стенда страхует от сильного разброса:
Во-первых, сама среда (ответы тулзов и улики) полностью детерминирована.
Во-вторых, режим non-thinking запускается с
temperature = 0.0, то есть он детерминирован на стороне генерации.В-третьих,
R_mean(Байесовский регрет) - это уже усредненная метрика. Стенд прогоняет агента не через одну задачу, а через набор эпизодов (в шоукейсе это 5 прогонов, в полномfrozen_harness_v1- прогон по всему корпусу событий). Мы усредняем ошибку распределения вероятностей на всем датасете, что сглаживает локальные флуктуации отtemperature = 0.6в режиме thinking.Есть такое :)
Спасибо за отличный комм! Вы ударили в самую точку. Именно классическая теория синтеза надежных систем из ненадежных элементов стала для нас главным ориентиром.
Ваша «новая задачка» уже в активной разработке у меня :) Мы собрали измерительный стенд и прямо сейчас краш-тестируем разные топологии (Star, Tree, Chain) под атаками на фронтир-моделях. Могу дать небольшой спойлер: результаты оказались весьма контринтуитивными, особенно когда мы включили моделям internal reasoning. Плоские графы рассыпаются совсем не так, как ожидалось. Будет 2 часть и обновленный репо!
Я выше писал, что всё через vllm и докер было запущено. Насчёт Тессеракта: возьмите большую таблицу и текст и посмотрите, что вернёт Тессеракт и в каком формате, а также что вернёт PaddleVL.
Время покажет. На таблицах paddle, всё остальное — VL-модели какие-то, с хорошими промтами. Если задача чисто OCR без проверки и всего остального, можно и что-то попроще. Qwen8b VL отлично справлялся.
Тестировали, конечно. Просто в данной статье это не было указано :)
Да, знаем об этом решении, но нам нужны были решения с открытым исходным кодом)
Тут данные из интернета, но в нашем проде важно было решение из коробки, так как данных даже для теста не так много, не говоря уж про дообучение.
Конечно)
Это да, но мощности были ограничены на нашей серверной машине, и не все могут запустить 235 кВ локально. Тут рассмотрены модели, которые используются у нас.
Верно, это был инференс, все модели были на vLLM развёрнуты)
Я думаю, что qwen3 VL большой, например, 235Б, либо же, если касаться только таблиц, paddle VL умеет их отлично распознавать. Там есть настройки, чтобы он понимал ориентацию их, да и вообще довольно гибок в этом плане.
Я думаю, либо лучшие модели, которые сейчас есть, как, например, Квен 235Б или Gemini. Ну, либо какие-то коммерческие решения.