Доработайте workgraph.ru под интерфейсы, чтобы схемки не в фигджеме рисовать, а в WG сам агент это делал и получится спека для UX/UI, с информационным слоем и историей. Храните информацию не в силах, а в графе. Когда проект связан, агенту проще в нем ориентироваться.
Если коротко, то Work Graph пытается решить фундаментальную проблему AI-разработки: разрыв между намерением человека и исполнением машины.
Paperclip управляет агентами как сотрудниками, но не проверяет качество их работы.
Work Graph создаёт слой смысла (BVC-атом), связывает его с кодом, а затем может автоматически верифицировать, что код действительно реализует задуманный смысл.
Это делает Work Graph не просто трекером задач и не просто оркестратором, а инструментом формальной верификации соответствия кода намерению. И граф здесь — это не только связи между задачами, но и связи между атомами смысла (BVC) и конкретными строками кода.
У меня прямо вот каких-то знаний в проекте обычно нет, кроме как архитектуры и истории принятия решений. И под свой флоу я создал продукт Work Graph и выложил в оупенсорс. Для соло и пет-проектов очень удобно.
Юзер флоу такой: В архитектуру добавляем домены (верхний уровень архитектуры). Далее: Анализ вопроса > Выбор решения > Создание эпика/задач > Выполнение > Тестирование > Сохранение
Получился навигатор для AI-разработки.
Как будет время, напишу статью, пока руки не дошли.
250 т/с это у компоузер 2.0 ?, сейчас 2,5 вышел, и еще 2,5 Fast, он намного быстрее я игрался локально с qwen3,6-27b, и даже карту поменял на 3090Ti 24gb, но с контекстом 240 тыс скорость 2-3 т/с, чтобы не вылетало в память, нужно контекст 60 тыс ставить, тогда 10 т/с. Но после 250, а сейчас и все 1500+ т/с — эти игры быстро надоели.
Прочитал статью и комментарии — очень откликается то, что вы описываете про смешивание уровней и «мёртвые» артефакты, которые нельзя проверить сценарием.
Это BVC (Базис · Вектор · Цель) — формат атомов, специально спроектированный под работу AI-агентов. Не Excel, не ERD, не Mermaid, а именно машиночитаемый формат с жёсткой структурой.
Что там есть:
1. Типизированные профили атомов. Каждый атом имеет profile: charter, charter_section, work_item, plan, prompt_rule, trace. Это решает проблему смешивания уровней — модель не может перепутать «что есть» с «что делается» и «зачем», потому что структура атома жёсткая: Basis (контекст) → Vector (действие) → Goal (цель) + Labels (метаданные).
2. Встроенные проверки — checks. Прямо в атом можно записать массив сценариев проверки. То есть то самое «пока результат нельзя проверить сценарием, это не проектный артефакт» — вшито в формат.
3. Машиночитаемые доказательства — structuredEvidence. Массив с типами (command, test, file, change, decision, worker-run, manual-review, blocker) и статусами (succeeded, failed, pending, skipped, blocked). Это закрывает вопрос trace-связей и оснований для приёмки, который вы поднимали в ответе ASenchenko.
4. Профиль trace — отдельный тип атома для трассировки. Связывает артефакты с доказательствами.
Пример того, как выглядит ваш «резерв товара» в BVC:
#ПроцессРезервации<[
Базис:
- заказ на резервирование товара
Вектор:
- создать резерв на складе
Цель:
- гарантировать наличие товара для клиента
Метки:
profile: work_item
trace.status: pending
Проверки:
- товар существует в номенклатуре
- количество на складе >= заказанного
- статус заказа = "подтверждён"
Доказательства:
- тип: test
статус: succeeded
задача: test-reservation-001
резюме: "Проверка остатков пройдена"
]>
Что это меняет по сравнению с Excel-ядром:
Не нужно поддерживать связанные таблицы — вся предметная логика в типизированных .bvc файлах
Каждый артефакт самодостаточен: содержит и смысл, и проверки, и доказательства
LLM работает с жёсткой структурой, а не восстанавливает предметку заново
Проверка сценарием — не надстройка, а часть формата
Что остаётся за скобками BVC: BVC описывает один атом. Для бизнес-процессов нужна надстройка — граф атомов с последовательностями, ветвлениями и альтернативными маршрутами. Мы это решаем через Work Graph (граф атомов в .bvc файлах), но это уже следующий слой.
Если интересно — посмотрите спецификацию, она небольшая. Мне самому было бы полезно услышать профессиональную критику от человека, который реально мучает LLM на проектных задачах, а не просто теоретизирует.
Что могу сказать: я второй месяц собираю автономного агента на локальных LLM, в которого можно закинуть идею, а он сам бы её исследовал, расписал, согласовал, разбил на задачи и реализовал. На текущий момент Qwen 3.6-27b для агентских задач — самая продвинутая из доступных для моей 3090Ti локально. Но это всё ещё далеко от качества облачных решений типа Composer 2.0.
Хочу дополнить резюме автора своим наблюдением: одного Reviewer Agent недостаточно.
Без жесткой архитектуры это превращается в бесконечный цикл «отклонение → переделка → отклонение», который никогда не закончится, пока не иссякнет контекст или терпение.
В базе нужна действительно большая модель (уровня Kimi-k2,6), способная удерживать весь контекст проекта, плюс обязательное дообучение (LoRA) под специфические инструменты среды.
Нужен не просто Reviewer, а комплексная система оркестрации, включающая:
Детерминированный роутинг сценариев: Четкое разделение на роли (Архитектор, Инженер, Тестировщик, Дебаггер и тд), где каждая роль имеет свои права доступа к инструментам и лимиты итераций.
Верификатор как внешний арбитр: Механизм, который не доверяет словам модели, а самостоятельно запускает тесты/линтеры и принимает решение о статусе задачи (done/blocked) только на основе объективных доказательств (DoD).
Safety Kernel и Loop Guards: Жесткие ограничители, которые прерывают цикл после N неудачных попыток и автоматически эскалируют задачу на человека или меняют стратегию (например, переход от «попытки исправить» к «перепланированию»).
Память проекта в виде артефактов: Хранение контекста не в чате, а в версионируемых файлах, чтобы агент мог обращаться к истории решений, а не галлюцинировать заново.
Стратегии сжатия контекста: Автоматическое архивирование старых частей диалога в краткие резюме для освобождения места под текущую работу без потери смысла.
Контур самообучения: Автоматическое извлечение регрессионных кейсов из неудачных попыток для обновления базы знаний системы.
Сквозная индексация: Единое промежуточное представление и граф зависимостей, связывающие код, тесты, требования и правила в единую сеть. Это позволяет агенту видеть влияние изменений (если я поменяю эту функцию, какие тесты и модули затронуты?) и поддерживать трассируемость от бизнес-цели до конкретной строки кода.
Управление блокировками и конкурентным доступом: Механизм блокировки файлов и ресурсов, предотвращающий конфликты записи при параллельном выполнении задач разными ролями.
Бюджетирование и лимиты ресурсов: Контроль расхода токенов, времени GPU и стоимости операций в реальном времени с автоматической остановкой при превышении лимитов.
Мета-тестирование поведения агента: Набор адверсарных тестов специально для проверки устойчивости самой системы оркестрации к сбоям и галлюцинациям.
Объяснимость решений: Визуализация цепочки рассуждений и причин принятия решений прямо в UI (почему агент выбрал именно этот файл?).
Реакция на внешние события: Возможность автоматически создавать задачи в при внешних триггерах (падение CI, пуш в репозиторий).
Версионирование промптов и конфигураций: Хранение версий системных промптов и правил ролей в Git для возможности отката поведения агента при деградации качества.
Я тоже навайбкодил за месяц проектик, но не рвусь бежать и писать про это статьи. В чем смысл поста, не понятно. Описанный процесс вообще не похож на тот, который выработался у меня. Все лимиты этих умных гипермоделей я потратил в первую неделю, толку от них никакого, пишут кучу не того что нужно. $200 в плане ультра улетели и оставшиеся 3 недели я дописывал на компоузере 1.5, который судя по всему безлимитный, так как по графику затрат он показывал в районе $800 под конец месяца, то есть далеко за пределами самого тарифа. За этот месяц я собрал дизайн систему с компонентами на дизайн токенах. Интегрировал сторонние сервисы по геокодированию, поисковым подсказкам, отображению карт. Выстроил флоу заказчика и исполнителя. Админку для управления контентом и настройкой. Всякие там адаптеры для платежных провайдеров, цели для метрики и тому подобное. MVP еще не закончен, но если интересно, лежит тут мастерклик.рф
Я правильно понимаю, что вы вместо того, чтобы изучать и копировать привычные и устоявшиеся паттерны поведения продукта-конкурента, зачем-то еще занимаетесь UX-исследованием и внесением изменений в эти устоявшиеся паттерны на основе ваших тестов?
Как мне кажется, ваша стратегия должна состоять из точного копирования и закрытия по функциональности, а изменения, это перспектива будущего, в зависимости от скорости ваших возможностей по клонированию.
Что первым делают пользователи обновившиеся с 10 на 11 винду? Правильно, идут прибивать кнопку пуск к левому-нижнему углу. Им эти новые механики *** не сдались...
Текущие схемы не понятны не из-за визуальной формы, а из-за информационной неполноты. Графы тоже визуально отображаются в виде DAG-графов, это тоже схемы, просто без циклов. Смысл ioHasC в уходе от функционального описания к информационному, с указанием целей.
Мне как дизайнеру ваши схемки абсолютно не понятны, (вы их уже привыкли строить, поэтому топите за схемки), но заполнить таблицу последовательности действий я могу и мне это просто. А по фен-шую делается эксперимент, берутся 3 разных бизнес-процесса и описываются разными способами, а потом тестируется понимание на разных пользователях. Сразу уберётся весь судейский субъективизм, с которым мы так боремся в автоматизации процессов :)
Мы используем Хаск-модель Зайцева (ioHasC) весь продукт декомпозируем на информационные графы в логистическом формате, где начало графа — это позиция того что имеем, конец графа — это цель и маршрут — как из А попасть в Б. Я сокращено это назвал АБВ (point A, point B, Way). Такой формат понимают и аналитики и дизайнеры и программисты и даже не имеющие отношение к решению люди, он прост, понятен и универсален, так как в этом формате можно описать любые процессы, алгоритмы, продукты, договора, интерфейсы и тд. Так же ABW является техзаданием, частью бэклога и даже документацией и комментариями к коду и дизайну. Не понимаю, зачем люди себе усложняют жизнь используя чужие методики )))
Доработайте workgraph.ru под интерфейсы, чтобы схемки не в фигджеме рисовать, а в WG сам агент это делал и получится спека для UX/UI, с информационным слоем и историей. Храните информацию не в силах, а в графе. Когда проект связан, агенту проще в нем ориентироваться.
да — длинные тире (alt+0151) я всегда сам пишу, а аналитические разборы отдаю нейронке
Если коротко, то Work Graph пытается решить фундаментальную проблему AI-разработки: разрыв между намерением человека и исполнением машины.
Paperclip управляет агентами как сотрудниками, но не проверяет качество их работы.
Work Graph создаёт слой смысла (BVC-атом), связывает его с кодом, а затем может автоматически верифицировать, что код действительно реализует задуманный смысл.
Это делает Work Graph не просто трекером задач и не просто оркестратором, а инструментом формальной верификации соответствия кода намерению. И граф здесь — это не только связи между задачами, но и связи между атомами смысла (BVC) и конкретными строками кода.
У меня прямо вот каких-то знаний в проекте обычно нет, кроме как архитектуры и истории принятия решений. И под свой флоу я создал продукт Work Graph и выложил в оупенсорс. Для соло и пет-проектов очень удобно.
Юзер флоу такой: В архитектуру добавляем домены (верхний уровень архитектуры).
Далее: Анализ вопроса > Выбор решения > Создание эпика/задач > Выполнение > Тестирование > Сохранение
Получился навигатор для AI-разработки.
Как будет время, напишу статью, пока руки не дошли.
250 т/с это у компоузер 2.0 ?, сейчас 2,5 вышел, и еще 2,5 Fast, он намного быстрее
я игрался локально с qwen3,6-27b, и даже карту поменял на 3090Ti 24gb, но с контекстом 240 тыс скорость 2-3 т/с, чтобы не вылетало в память, нужно контекст 60 тыс ставить, тогда 10 т/с. Но после 250, а сейчас и все 1500+ т/с — эти игры быстро надоели.
Какой оркестратор используете, в какой среде?
Когда наиграетесь, просто купите подписку на курсор за $200 и получите 1500 т/с, а может и больше.
Прочитал статью и комментарии — очень откликается то, что вы описываете про смешивание уровней и «мёртвые» артефакты, которые нельзя проверить сценарием.
Хочу показать одну штуку, которая, как мне кажется, закрывает ровно вашу боль: https://github.com/bvc-lang/spec
Это BVC (Базис · Вектор · Цель) — формат атомов, специально спроектированный под работу AI-агентов. Не Excel, не ERD, не Mermaid, а именно машиночитаемый формат с жёсткой структурой.
Что там есть:
1. Типизированные профили атомов. Каждый атом имеет
profile:charter,charter_section,work_item,plan,prompt_rule,trace. Это решает проблему смешивания уровней — модель не может перепутать «что есть» с «что делается» и «зачем», потому что структура атома жёсткая: Basis (контекст) → Vector (действие) → Goal (цель) + Labels (метаданные).2. Встроенные проверки —
checks. Прямо в атом можно записать массив сценариев проверки. То есть то самое «пока результат нельзя проверить сценарием, это не проектный артефакт» — вшито в формат.3. Машиночитаемые доказательства —
structuredEvidence. Массив с типами (command,test,file,change,decision,worker-run,manual-review,blocker) и статусами (succeeded,failed,pending,skipped,blocked). Это закрывает вопрос trace-связей и оснований для приёмки, который вы поднимали в ответе ASenchenko.4. Профиль
trace— отдельный тип атома для трассировки. Связывает артефакты с доказательствами.Пример того, как выглядит ваш «резерв товара» в BVC:
Что это меняет по сравнению с Excel-ядром:
Не нужно поддерживать связанные таблицы — вся предметная логика в типизированных
.bvcфайлахКаждый артефакт самодостаточен: содержит и смысл, и проверки, и доказательства
LLM работает с жёсткой структурой, а не восстанавливает предметку заново
Проверка сценарием — не надстройка, а часть формата
Что остаётся за скобками BVC: BVC описывает один атом. Для бизнес-процессов нужна надстройка — граф атомов с последовательностями, ветвлениями и альтернативными маршрутами. Мы это решаем через Work Graph (граф атомов в
.bvcфайлах), но это уже следующий слой.Если интересно — посмотрите спецификацию, она небольшая. Мне самому было бы полезно услышать профессиональную критику от человека, который реально мучает LLM на проектных задачах, а не просто теоретизирует.
Мне 9b весь код запорола, на более сложных задачах. Qwen3.6-27b себя показывает лучше чем 35b. Но это все равно рядом не стояло с облачными моделями.
так это уже давно, просто некоторые просят шифроваться стилем написания и не бросаются в глаза, как эти пункты.
Что могу сказать: я второй месяц собираю автономного агента на локальных LLM, в которого можно закинуть идею, а он сам бы её исследовал, расписал, согласовал, разбил на задачи и реализовал. На текущий момент Qwen 3.6-27b для агентских задач — самая продвинутая из доступных для моей 3090Ti локально. Но это всё ещё далеко от качества облачных решений типа Composer 2.0.
Хочу дополнить резюме автора своим наблюдением: одного Reviewer Agent недостаточно.
Без жесткой архитектуры это превращается в бесконечный цикл «отклонение → переделка → отклонение», который никогда не закончится, пока не иссякнет контекст или терпение.
В базе нужна действительно большая модель (уровня Kimi-k2,6), способная удерживать весь контекст проекта, плюс обязательное дообучение (LoRA) под специфические инструменты среды.
Нужен не просто Reviewer, а комплексная система оркестрации, включающая:
Детерминированный роутинг сценариев: Четкое разделение на роли (Архитектор, Инженер, Тестировщик, Дебаггер и тд), где каждая роль имеет свои права доступа к инструментам и лимиты итераций.
Верификатор как внешний арбитр: Механизм, который не доверяет словам модели, а самостоятельно запускает тесты/линтеры и принимает решение о статусе задачи (
done/blocked) только на основе объективных доказательств (DoD).Safety Kernel и Loop Guards: Жесткие ограничители, которые прерывают цикл после N неудачных попыток и автоматически эскалируют задачу на человека или меняют стратегию (например, переход от «попытки исправить» к «перепланированию»).
Память проекта в виде артефактов: Хранение контекста не в чате, а в версионируемых файлах, чтобы агент мог обращаться к истории решений, а не галлюцинировать заново.
Стратегии сжатия контекста: Автоматическое архивирование старых частей диалога в краткие резюме для освобождения места под текущую работу без потери смысла.
Контур самообучения: Автоматическое извлечение регрессионных кейсов из неудачных попыток для обновления базы знаний системы.
Сквозная индексация: Единое промежуточное представление и граф зависимостей, связывающие код, тесты, требования и правила в единую сеть. Это позволяет агенту видеть влияние изменений (если я поменяю эту функцию, какие тесты и модули затронуты?) и поддерживать трассируемость от бизнес-цели до конкретной строки кода.
Управление блокировками и конкурентным доступом: Механизм блокировки файлов и ресурсов, предотвращающий конфликты записи при параллельном выполнении задач разными ролями.
Бюджетирование и лимиты ресурсов: Контроль расхода токенов, времени GPU и стоимости операций в реальном времени с автоматической остановкой при превышении лимитов.
Мета-тестирование поведения агента: Набор адверсарных тестов специально для проверки устойчивости самой системы оркестрации к сбоям и галлюцинациям.
Объяснимость решений: Визуализация цепочки рассуждений и причин принятия решений прямо в UI (почему агент выбрал именно этот файл?).
Реакция на внешние события: Возможность автоматически создавать задачи в при внешних триггерах (падение CI, пуш в репозиторий).
Версионирование промптов и конфигураций: Хранение версий системных промптов и правил ролей в Git для возможности отката поведения агента при деградации качества.
Ну и там много чего еще...
Я тоже навайбкодил за месяц проектик, но не рвусь бежать и писать про это статьи. В чем смысл поста, не понятно. Описанный процесс вообще не похож на тот, который выработался у меня. Все лимиты этих умных гипермоделей я потратил в первую неделю, толку от них никакого, пишут кучу не того что нужно. $200 в плане ультра улетели и оставшиеся 3 недели я дописывал на компоузере 1.5, который судя по всему безлимитный, так как по графику затрат он показывал в районе $800 под конец месяца, то есть далеко за пределами самого тарифа. За этот месяц я собрал дизайн систему с компонентами на дизайн токенах. Интегрировал сторонние сервисы по геокодированию, поисковым подсказкам, отображению карт. Выстроил флоу заказчика и исполнителя. Админку для управления контентом и настройкой. Всякие там адаптеры для платежных провайдеров, цели для метрики и тому подобное. MVP еще не закончен, но если интересно, лежит тут мастерклик.рф
Flash, который сейчас Adobe Animate поддерживает публикацию в html5.
Я правильно понимаю, что вы вместо того, чтобы изучать и копировать привычные и устоявшиеся паттерны поведения продукта-конкурента, зачем-то еще занимаетесь UX-исследованием и внесением изменений в эти устоявшиеся паттерны на основе ваших тестов?
Как мне кажется, ваша стратегия должна состоять из точного копирования и закрытия по функциональности, а изменения, это перспектива будущего, в зависимости от скорости ваших возможностей по клонированию.
Что первым делают пользователи обновившиеся с 10 на 11 винду? Правильно, идут прибивать кнопку пуск к левому-нижнему углу. Им эти новые механики *** не сдались...
Тоже не вижу причин, описывайте Хаск-модель в формате BPMN, вам никто не запрещает. Если всей команде будет понятно, кто же вас отговорит от этого.
Текущие схемы не понятны не из-за визуальной формы, а из-за информационной неполноты. Графы тоже визуально отображаются в виде DAG-графов, это тоже схемы, просто без циклов. Смысл ioHasC в уходе от функционального описания к информационному, с указанием целей.
В схеме bpmn есть: клиент —> принятие заявки —> регистрация заказа —> принятие оплаты —> доставка —> закрытие заказа.
В ioHasC: Получить данные от пользователя —> Проверить наличие товара —> Получить оплату от пользователя —> Доставить товар
Мне как дизайнеру ваши схемки абсолютно не понятны, (вы их уже привыкли строить, поэтому топите за схемки), но заполнить таблицу последовательности действий я могу и мне это просто. А по фен-шую делается эксперимент, берутся 3 разных бизнес-процесса и описываются разными способами, а потом тестируется понимание на разных пользователях. Сразу уберётся весь судейский субъективизм, с которым мы так боремся в автоматизации процессов :)
Мы используем Хаск-модель Зайцева (ioHasC) весь продукт декомпозируем на информационные графы в логистическом формате, где начало графа — это позиция того что имеем, конец графа — это цель и маршрут — как из А попасть в Б. Я сокращено это назвал АБВ (point A, point B, Way). Такой формат понимают и аналитики и дизайнеры и программисты и даже не имеющие отношение к решению люди, он прост, понятен и универсален, так как в этом формате можно описать любые процессы, алгоритмы, продукты, договора, интерфейсы и тд. Так же ABW является техзаданием, частью бэклога и даже документацией и комментариями к коду и дизайну. Не понимаю, зачем люди себе усложняют жизнь используя чужие методики )))
да, пишите в личку