Экспериментальные посты!
Долго не мог придумать, как лучше показывать некоторые интересные практические части своей работы. Когда дело доходит до донесения идеи в коде, тебя начинают преследовать три страшных вещи - объём, сложность и NDA.

Вместе с тем, аж разрывает как хочу поделиться с миром результатами предыдущей недели своих изысканий

Попробуем так
https://github.com/virrius/tts_intonation_research

Чтоб вспомнить как работать с ноутбуками и преобразовать всё в удобоваримую статейку ушло 6 часов помимо самой, собственно, работы. Жууть

После решения конфликтов в команде конфликты в гите кажутся такими понятными, милыми и приятными.

А вообще, если правильно помню, первая IT паника на рабочем месте была связана именно с ребейзом. Я тогда ещё более смутно представлял, как оно работает и просто пытался заменить ctrl+c ctrl+v всю цепочку коммитов на финальный вариант.
А оно постоянно пропадало и пыталось перезаписаться каким-то старым состоянием!

Активности? Активности!


В последнее время хорошего происходит у меня не сильно много, самоощущение как на пикче, но хоть под НГ всех поздравить надо. Поразительно, но я таки придумал как особо технично это сделать

Мы
На пару с этим господином
И неким Валерой, ответственным за все формы вайба в проекте

Пильнули SGR Agent Core 0.5.0 прям 31 числа!
Чем опять немного потрогали обратную совместимость. Мне честно-честно очень стыдно, но новые идеи были слишком хороши

Поэтому вместо поздравления публикну чейнджлог. А то автосгенеренный гитхабовский недостаточно хорош:

0) ДОКИ! Я три недели сидел и пилил по вечерам доки(вместо постов)
https://vamplabai.github.io/sgr-agent-core/ru/
Как же красиво они вошли в мою грешную жизнь! Когда буду составлять свои мемуары - отдельной главой копипастну их в полном объёме

1) Динамическое перераспределение файлов проекта. Мы разобрались кто мы и чего хотим, а потому:

sgr agent core выделилась как полноценная фреймворк либа. Только минимально необходимые конструкты и сущности

И уже доступна в ваших venv https://pypi.org/project/sgr-agent-core/

Deep research переехала в examples как демонстрация прикладного применения ферймворка.
Скоро там появится ещё пара интересных вещей

2) Устаканили систему конфигурации агентов. Её примеры, сценарии использования, модели и их параметры

По генеральной задумке чтобы начать пользоваться либой можно даже особо в python код не закапываться - пару строчек в файл конфига или ENV и всё уже на вашем production
Отдельно позаботились о кастомизации и я очень надеюсь, что расширять наши идеи, создавать что-то своё станет удобнее
Чувствую, что работа в этом направлении только начинается

3) Придумали и долго тестили систему импорта файлов относительно конфигов.
Чтоб быть как docker compose . И чтоб промптики можно было класть почти куда угодно и они находились

4) Получили отзыв, что переопределять execute() агента не очень удобно и выделили специально под эти цели _execution_step()
Шлите ещё отзывы)

5) Выпилили две самые странные реализации логики агента

press F SGRAutoToolCallingAgent SGRSOToolCallingAgent. Ибо нефиг экспериментально-тестовой логике лежать в нашем наполовину зрелом фреймворке.

6) Не обошлось без пары фиксов

Оказывается, если динамически побилдить MCP схему тулы, она может не захотеть по-хорошему упаковываться в лог агента
А ещё циклические зависимости мешали прикладному применению в коде гениально-комунистических идей, где все используют всё и сразу

7) Облегчили сборочку проекта, потёрли все неважные зависимости

8) Обложились линтерами, workflow и даже вайб-тестами! Чтобы выглядеть внушительнее, разумеется.


И про будущее:
- красивый роадмап, возможно с привлечением топовых дизайнеров
- Больше прикладных примеров работы. Возможно удобно загружаемых и разворачиваемых в сервис под ваши нужды
- Лучше работа с контекстом - добавление на вход агенту не одной текстовой задачи, а полноценной истории. С картинками. - уже Done
- Ещё лучше работа с контекстом - отслеживание расхода токенов и границ контекстного окна
- Шажок к AGI - добавление возможностей кодогенерации под нужды агента
- Шажок к AGI матрёшке - добавление добавления агентов как тулзов. Чтоб агент мог вызывать агента который бы вызвал.. ну вы поняли
- Улучшеный Reasoning, план и следование этому плану.
- Более удобные эвенты работы агента (сейчас, с openai like streaming адаптером понимать, что делает система как минимум неприятно)
- Бенч система, сокрытая в недрах наших серваков. как перф так и качественная.
- + раскурить, кто это ваши skills. Возможно они нам тоже нужны

И ещё много-много идей, которые пока в менее определённом бэклоге

Так и запишем, топ-1 вайбкодер всея Сербии

Это даже немного удивительно, что есть комьюнити сходки Cursor

😗новые штучки😗
Сыренько но миленько

Теперь надо понять, где этот выигрыш по скорости применять, если TTFT моделек это сотни мс

https://github.com/pydantic/monty

Фанаты sgr-agent-core регулярно спрашивают нас, с чего мы взяли, что они наши фанаты?

Уже неделю чувствую себя ненормированно свободным, впервые за долгое время проснулось кодовдохновение. А потому - делюсь! Много мыслей и немного кода.

В чем экзистенциальный ужас платформенной разработки? Приходится поддерживать и учитывать разные платформы, их версии, ограничения. И как бы я ни бегал от мрака версионности, всё-же напоролся на примере sgr core

Итак, проблема:
Фреймворк построен на Structured Output, но его поддерживают далеко не все конфигурации локальных/проприетарных LLM. Что самое страшное, даже если поддерживают, то не всегда однородно! Требуемые JSON схемы могут различаться.
Если фреймворк может работать, а может не работать на неопределённом множестве моделей - это ужасненько.

Structured output(SO) по моему скромному мнению это железная база, без которой сложно представить взаимодействие агентов хаоса вольного контекста и неопределëнных суждений и системы требующей, как правило, некоторой детерминированности, свойственной формальным языкам.


Примеры:
- Кто-то гарантирует ответ строго по формату, а кто-то может допустить ошибки даже при заданной схеме
- Кто-то поддерживает вложенные AnyOf и прочие агрегаты схем, а кто-то нет
- Где-то можно прокинуть ограничения min_length=1, max_length=3, а где-то нет, они в лучшем случае будут проигнорированы
- Кто-то хавает литералы и сопутствующие им enums, а кто-то отказывается

Как общий знаменатель пришла мысля создать решение, которое бы эмулировало независимый от ллмки SO без реальной в нём потребности на стороне провайдера . Идея "попроси модель сделать как надо" далеко не нова, и тем не менее было полезно посмотреть, насколько хорошо и стабильно это могут делать современные LLM


Концепция:
class ToolInstantiator принимает в свой init Pydantic модель, и имеет два основных метода интерфейса:
- Сгенерить промпт с описанием схемы для LLM
- Провалидировать полученный ответ LLM на предмет возможности билда инстанса Pydantic модели
На каждом следующем этапе промпт,выдаваемый классом, учитывает ошибки и проблемы предыдущей итерации, корректируя/фокусируя LLM

Путём некоторых экспериментов было выявлено, что прямая json схема для LLM сложновата ввиду нотации и неконсистентной информации о полях и их типах. А ещё иногда модельки путались и выдавали JSON schema аналогичную промптовой в ответ. Поэтому появился класс-помогатор SchemaSimplifier, разбирающий схему и преобразующий в более минималистичную нотацию

Ещё была интересная концепция, где каждое поле валидировалось по отдельности и даже если модель выдала в общем не полностью корректный JSON, часть верных полей принимались и не требовались на дальнейших итерациях генерёжки. Идея была отброшена ввиду нелицеприятности кодреализации такой фичи.
Лучше никому не видеть мою попытку в конвертацию типов raw context regex parsing -> json string->python type -> pydantic validator

Вот тут реализация - почти хорошо

работает следующим образом

for attempt in range(max_retries):
    async with self.openai_client.chat.completions.stream(
        messages=messages + [{"role": "user", "content": instantiator.generate_format_prompt()}],
    ) as stream:
        completion = await stream.get_final_completion()
        try:
            content = completion.choices[0].message.content
            tool_instance = instantiator.build_model(content)
            return tool_instance
        except ValueError:
            continue

А дальше был бенчмарк на всех моделях, до которых я смог дотянуться.
Тестировалось четыре кейса из числа тулов фреймворка:
- ReasoningTool, где было много ограничений на длину строк и списков
- WebSearchTool - прост
- CreateReportTool - сгенерить объёмный вывод
- NextStepToolSelector - по динамически составляемой схеме сделать корректный инпуту выбор function_name_choice

Так много GPTшек тут ибо на прогонах обнаружил, что разные версии очень неравномерно по выдаваемому результату себя ведут.
gpt-4o>>gpt-5-mini>gpt-5>>gpt-4.1

Upd: глянул приложенную версию бенча, там всё даже слишком хорошо, почти все задачи закрылись с первых попыток. Так было далеко не на всех итерациях и некоторые модельки включая gpt-5 любили забывать кавычки внутри кавычек и уходить в самоповторы все пять раз.

Тем не менее, если хитрый вайбкодинг бенча меня нигде не попутал, сама по себе возможность получения такового прогона говорит о качестве современных моделек на задачах генерёжки JSON форматированного текста

Файл бенча отдельно, чтоб пост красивее выглядел💅

От @evilfreelancer прилетело дельное замечание по поводу объёма бенча.

Посчитал расширенные результаты + сделал дополнительный бенч на усложнённых кейсах, где надо не просто сгенерить схему, а выбрать подсхему и заполнить её в виде вложенного объекта в соответствии с контекстом.
Схема в пост не влезла, поэтому будет на скрине


Первый файл: 10 попыток на модель, 4 базовых кейса
Второй файл: 10 попыток на модель, 2 продвинутых кейса

Модельки:
- gpt-oss-120b
- qwen3-30b-a3b-instruct-2507
- glm-4.7-flash:30b
- gpt-oss:20b

- gpt-4o
- gpt-4o-mini
- gpt-5-mini
- gpt-5-nano
temperature: 0.3

Тест кейс с примером контекста для модельки:

    nextstep_tools_6 = [
        ReasoningTool,
        WebSearchTool,
        ExtractPageContentTool,
        AdaptPlanTool,
        CreateReportTool,
        ClarificationTool,
    ]
    NextStepTools6 = NextStepToolsBuilder.build_NextStepTools(nextstep_tools_6)

    test_cases.append(
        (
            NextStepTools6,  # type: ignore
            "The user has found several relevant web pages during their research on 'Machine Learning in Healthcare'. "
            "They have URLs of articles and research papers that contain detailed information they need: "
            "https://www.nature.com/articles/s41591-021-01614-0 and "
            "https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6568067/. "
            "The user wants to extract the full content from these specific pages to analyze the information "
            "and include it in their research report.",
            "extractpagecontenttool",  # Expected tool name
            "NextStepTools (6 tools)",  # Case name
        ),
    )

(!)Поток мыслей(!)

Хочу для разнообразия от технички что-нибудь измыслить и пованговать чтоб сначала говорить "А я это ещё тогда говорил" а потом "надо же как интересно получилось"

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

(1)
На меня снизошло озарение, что по сути мы в работе с агентами движемся к светлому декларативному будущему над императивными инструментами

Нам всё ещё необходимо дотошно представлять поведение выстраиваемой системы примерно на уровне алгоритмов и структурно-архитектурной логики чтоб хотя бы прицениться к возможностям/перспективам реализации. Эти принимаемые решения о поведении весьма многообразны, зависят от опыта/видения/настроения разработчика и могут различаться вплоть до основополагающих принципов организации проекта.
Кто-то эвентики пуляет, кто-то шину данных пильнёт, кто-то подумает нунахер и построит на сырых запросиках. А! О! Или на очередях.

Большая проблема разработки - построение технологических систем в современных масштабах требует дичайшей когнитивной нагрузки. Для этого, разумеется, придумываются целые слои абстракций и инструментов и всё становится ещё хуже, что делает возможным работу почти со всем имеющимся зоопарком для команды из 3-5 людей, помноженных на необходимую скорость поставки и требования к обслуживанию.
Как процесс - мы с самого начала находимся в стадии автоматизации, подменяя изначальную сложность системы чем-то более высокоуровневым и имеющим проблему уже конфигурирования оного

> Фундаментальные проблемы решаются сложной абстракцией
> Сложная абстракция получает в конфигурируемые интерфейсы
> Конфигурационная надстройка упрощается и дробится на специализированные более простые технологии
> технологии получают экосистему для их встраивания и сопровождения
> Начинается новый виток абстрации


Как некоторый поинт:
У нас в профессии уже сейчас наработано достаточно инструментов, опыта, кодоартефактов чтобы при должной адаптации под агентов можно было исходить из декларативного подхода, что более и более успешно доказывает claude/codex/cursor в локальных задачах и современные PAAS и MLOps платформы на глобальных

Если принять (1) за правду, что мы начинаем жить в более декларативном мире


(2)
Происходит какаето гиперфиксация непосредственно на кодинге, его вайб собрате в то время как имеет место быть более глобальный процесс. По крайней в публичных холиварах я чаще вижу "как можно не контролировать код?!" чем "Где найти x100 заказчиков с деньгами для теста гипотез"

Вангую: Цель тренда - заменить ВЕСЬ процесс разработки на декларативно-агентную систему.
Представим очень грубо, что у нас есть глобальный пайплайн-комбайн с задачей
- найти заказчика (ну или хотя бы продукт холдера)
-положить его на громадный фреймворк сбора информации
- Собрать хотелки
- Проанализировать хотелки
- Прикинуть хотелки с возможностями
- Прикинуть как возможности соотносятся с реальным миром, rpsами, байтами данных и затратами на электричество
- Реализовать
- Развернуть
- Выставить вкусный счёт
Чтоб оно выглядело как солидный процесс надо расставить ещё какое-то количество стрелочек и циклов между этими этапами.

Здесь хорошо выделить три части
1) Exploration - выделить всё существенное и запустить сопутствующие процессы проработки
-> Изначальный бизнес контекст формируется, расширяется, уточняется
2) Формализация бизнес контекста - организация всё ещё высокоуровневой информации в домен. Натягивание структуры, общеизвестных паттернов. К реализации будет предполагается именно то, что описано на этом этапе.
-> Имеющийся контекст сужается
3) Разработка - фривольная трансляция некоторого подготовленного бизнес домена на императивные структуры формальных ЯП или куда пониже.
-> автоматизация как цель

Или ещё проще: расширение-сужение-трансляция

Текущие процессы/фреймворки/подходы направлены на то, чтобы для всех этих этапов сократить количество сопутствующих потерь информации. А они так или иначе будут. И сопоставить это с человеческими возможностями, скоростями, проблемами коммуникаций

Если представить агентную систему, которая может простраивать все три этапа, то стоимость и скорость одного такого прохода изменится порядка 10^4-5 раз. И в этом случае центральным стоит задать вопрос "Что мы хотели и что получили" - сравнения некоторой узкой идеи, не подвергшейся расширению человеком на первом этапе, и финального результата. Прелесть в том, что этих результатов можно управляемо и итерируемо создать необходимое количество за считанные дни. Разрыв от идеи до реализованного концепта - минимален.

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

1к звёздочек!

⎛⎝( ` ᢍ ´ )⎠⎞ bugagashenki