Если коротко, то 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 для возможности отката поведения агента при деградации качества.
Фишка курсора, что он индексирует до 50 000 файлов проекта для понимания контекста, как вы решили данную задачу? Мне как дизайнеру смотреть в код практически не приходится, всё взаимодействие через чат. Я на node.js собираю веб проект, лежит на домене мастерклик.рф Все лимиты на тарифе ультра этих гиперконтекстных моделей я выжигаю за неделю и основная работа идёт на компоузере 1.5, он видимо безлимитный. Как можно перейти на плагины, я не очень понимаю, так как по API бесплатных токенов не видел.
Я тоже навайбкодил за месяц проектик, но не рвусь бежать и писать про это статьи. В чем смысл поста, не понятно. Описанный процесс вообще не похож на тот, который выработался у меня. Все лимиты этих умных гипермоделей я потратил в первую неделю, толку от них никакого, пишут кучу не того что нужно. $200 в плане ультра улетели и оставшиеся 3 недели я дописывал на компоузере 1.5, который судя по всему безлимитный, так как по графику затрат он показывал в районе $800 под конец месяца, то есть далеко за пределами самого тарифа. За этот месяц я собрал дизайн систему с компонентами на дизайн токенах. Интегрировал сторонние сервисы по геокодированию, поисковым подсказкам, отображению карт. Выстроил флоу заказчика и исполнителя. Админку для управления контентом и настройкой. Всякие там адаптеры для платежных провайдеров, цели для метрики и тому подобное. MVP еще не закончен, но если интересно, лежит тут мастерклик.рф
Я правильно понимаю, что вы вместо того, чтобы изучать и копировать привычные и устоявшиеся паттерны поведения продукта-конкурента, зачем-то еще занимаетесь UX-исследованием и внесением изменений в эти устоявшиеся паттерны на основе ваших тестов?
Как мне кажется, ваша стратегия должна состоять из точного копирования и закрытия по функциональности, а изменения, это перспектива будущего, в зависимости от скорости ваших возможностей по клонированию.
Что первым делают пользователи обновившиеся с 10 на 11 винду? Правильно, идут прибивать кнопку пуск к левому-нижнему углу. Им эти новые механики *** не сдались...
Текущие схемы не понятны не из-за визуальной формы, а из-за информационной неполноты. Графы тоже визуально отображаются в виде DAG-графов, это тоже схемы, просто без циклов. Смысл ioHasC в уходе от функционального описания к информационному, с указанием целей.
Мне как дизайнеру ваши схемки абсолютно не понятны, (вы их уже привыкли строить, поэтому топите за схемки), но заполнить таблицу последовательности действий я могу и мне это просто. А по фен-шую делается эксперимент, берутся 3 разных бизнес-процесса и описываются разными способами, а потом тестируется понимание на разных пользователях. Сразу уберётся весь судейский субъективизм, с которым мы так боремся в автоматизации процессов :)
Мы используем Хаск-модель Зайцева (ioHasC) весь продукт декомпозируем на информационные графы в логистическом формате, где начало графа — это позиция того что имеем, конец графа — это цель и маршрут — как из А попасть в Б. Я сокращено это назвал АБВ (point A, point B, Way). Такой формат понимают и аналитики и дизайнеры и программисты и даже не имеющие отношение к решению люди, он прост, понятен и универсален, так как в этом формате можно описать любые процессы, алгоритмы, продукты, договора, интерфейсы и тд. Так же ABW является техзаданием, частью бэклога и даже документацией и комментариями к коду и дизайну. Не понимаю, зачем люди себе усложняют жизнь используя чужие методики )))
да — длинные тире (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 для возможности отката поведения агента при деградации качества.
Ну и там много чего еще...
У меня почему то 2.5 coder не дружит с tool calling. А его с агентом так и не подружил.
3.6 уже выкатили
Насколько дешевле курсора вышло?
Фишка курсора, что он индексирует до 50 000 файлов проекта для понимания контекста, как вы решили данную задачу? Мне как дизайнеру смотреть в код практически не приходится, всё взаимодействие через чат. Я на node.js собираю веб проект, лежит на домене мастерклик.рф Все лимиты на тарифе ультра этих гиперконтекстных моделей я выжигаю за неделю и основная работа идёт на компоузере 1.5, он видимо безлимитный. Как можно перейти на плагины, я не очень понимаю, так как по API бесплатных токенов не видел.
Я тоже навайбкодил за месяц проектик, но не рвусь бежать и писать про это статьи. В чем смысл поста, не понятно. Описанный процесс вообще не похож на тот, который выработался у меня. Все лимиты этих умных гипермоделей я потратил в первую неделю, толку от них никакого, пишут кучу не того что нужно. $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 является техзаданием, частью бэклога и даже документацией и комментариями к коду и дизайну. Не понимаю, зачем люди себе усложняют жизнь используя чужие методики )))