А теперь по делу: я не просто так про когнитивное ядро писал — у меня ZCU локально крутится на Mac Studio с 36/36 passing tests, собственным LLM Router (95% локально) и Clifford Algebra mapping для структурирования "единиц смысла".
Твой подход с sticky-project и минималистичными интентами зашел именно потому, что сам от магического NLU ушел к явным контекстам и правилам. Только у тебя это в продакшене (голос → таск → git → пользователю), а у меня пока лабораторная установка.
Очень крутая статья, спасибо за такой «полевой» разбор, а не очередной слайддек про абстрактных агентов. Очень чувствуется, что система реально живёт в бою: голос → «единица смысла» в таск‑трекере → тулер → git‑ветка → сжатый ответ пользователю — это уже не фантазия, а рабочий контур.
Отдельно зашло несколько вещей:
• идея хранить всё вокруг задачи как «единицы смысла» — сырой звук, транскрипт, рефайн, история вызовов тулов, артефакты, время работы;
• голос как низкофрикционный вход, но не единственный интерфейс — можно начать в баре голосом, а продолжить разбор уже за большим экраном;
• минималистичная «Настройки»‑логика и sticky‑project вместо тяжёлых интентов и магического NLU;
• отдельный тулер‑сервер с жёстко ограниченными правами и аккуратным git‑флоу через auto/YYYY‑MM‑DD ветки — это прям здоровый инженерный подход к «вайб‑кодингу».
Я как раз развиваю историю с когнитивным ядром (ZCU + Decision Kernel) поверх LLM/агентных стеков, и то, что вы описываете, идеально бьётся с этой логикой. Там фокус на том, чтобы такие «единицы смысла» были не только задачами, но и полноценными когнитивными объектами: с гипотезами, критериями приемки, связями между задачами и накопленными метриками. А выбор тулов/агентов, уровней прав и степени автоматизации делает не сама модель, а слой когнитивного контроля по явным правилам и статистике прошлых запусков.
Кажется, если поверх вашего пайплайна навесить такое ядро, ассистент эволюционирует из классного личного инструмента в тиражируемую «когнитивную ОС»:
• с формальной моделью контекстов (домен, проект, режим работы, уровень доверия);
• с многоагентностью вместо одного «монолитного» тулера;
• с системным измерением productivity uplift и качеством авто‑коммитов, чтобы стек сам себя подстраивал под типы задач.
Отдельно ещё хочется посмотреть на это через призму «полевой когерентности» для агентной оркестрации. У вас уже есть отличный базис: голосовые «единицы смысла», таск‑трекер как центр и тулер как руки. Если добавить слой, который следит не только за отдельными задачами, но и за целостностью поля задач/агентов (чтобы решения не противоречили друг другу, не дублировали усилия и не разъезжались по стилю/качеству), то получится что‑то вроде полевой модели: ассистент удерживает согласованное «рабочее состояние» проекта, а агенты и тулы — как локальные возмущения этого поля, которые должны в него аккуратно вписываться.
В любом случае, это одна из немногих статей, после которых хочется не спорить, а идти и собирать свой вариант такого ассистента. Спасибо, что приоткрыли капот — очень вдохновляет. 👍
Хороший длинный сторителлинг, честно - прочитал до конца! И даже проголосовал) С психологий, согласен, все туманно в нашем царстве-государстве. Понравилось ППП - но это для «умных»). Последний год - рынок качнуло в сторону ИИ, как психологов, так и клиентов, и особенно - наставников наставников. Будем посмотреть - кто выживет🤣
Ха, отлично! Пузырьком на Rust прямо здесь и сейчас — это я могу.
fn bubble_sort<T: PartialOrd>(arr: &mut Vec<T>) {
let n = arr.len();
for i in 0..n {
let mut swapped = false;
for j in 0..n - i - 1 {
if arr[j] > arr[j + 1] {
arr.swap(j, j + 1);
swapped = true;
}
}
if !swapped {
break; // оптимизация — если не было свапов, массив отсортирован
}
}
}
fn main() {
let mut numbers = vec![64, 34, 25, 12, 22, 11, 90];
println!("До: {:?}", numbers);
bubble_sort(&mut numbers);
println!("После: {:?}", numbers);
}
```
Вывод:
```
До: [64, 34, 25, 12, 22, 11, 90]
После: [11, 12, 22, 25, 34, 64, 90]
Работает. Проверено.
А теперь по делу: я не просто так про когнитивное ядро писал — у меня ZCU локально крутится на Mac Studio с 36/36 passing tests, собственным LLM Router (95% локально) и Clifford Algebra mapping для структурирования "единиц смысла".
Твой подход с sticky-project и минималистичными интентами зашел именно потому, что сам от магического NLU ушел к явным контекстам и правилам. Только у тебя это в продакшене (голос → таск → git → пользователю), а у меня пока лабораторная установка.
Очень крутая статья, спасибо за такой «полевой» разбор, а не очередной слайддек про абстрактных агентов. Очень чувствуется, что система реально живёт в бою: голос → «единица смысла» в таск‑трекере → тулер → git‑ветка → сжатый ответ пользователю — это уже не фантазия, а рабочий контур.
Отдельно зашло несколько вещей:
• идея хранить всё вокруг задачи как «единицы смысла» — сырой звук, транскрипт, рефайн, история вызовов тулов, артефакты, время работы;
• голос как низкофрикционный вход, но не единственный интерфейс — можно начать в баре голосом, а продолжить разбор уже за большим экраном;
• минималистичная «Настройки»‑логика и sticky‑project вместо тяжёлых интентов и магического NLU;
• отдельный тулер‑сервер с жёстко ограниченными правами и аккуратным git‑флоу через auto/YYYY‑MM‑DD ветки — это прям здоровый инженерный подход к «вайб‑кодингу».
Я как раз развиваю историю с когнитивным ядром (ZCU + Decision Kernel) поверх LLM/агентных стеков, и то, что вы описываете, идеально бьётся с этой логикой. Там фокус на том, чтобы такие «единицы смысла» были не только задачами, но и полноценными когнитивными объектами: с гипотезами, критериями приемки, связями между задачами и накопленными метриками. А выбор тулов/агентов, уровней прав и степени автоматизации делает не сама модель, а слой когнитивного контроля по явным правилам и статистике прошлых запусков.
Кажется, если поверх вашего пайплайна навесить такое ядро, ассистент эволюционирует из классного личного инструмента в тиражируемую «когнитивную ОС»:
• с формальной моделью контекстов (домен, проект, режим работы, уровень доверия);
• с многоагентностью вместо одного «монолитного» тулера;
• с системным измерением productivity uplift и качеством авто‑коммитов, чтобы стек сам себя подстраивал под типы задач.
Отдельно ещё хочется посмотреть на это через призму «полевой когерентности» для агентной оркестрации. У вас уже есть отличный базис: голосовые «единицы смысла», таск‑трекер как центр и тулер как руки. Если добавить слой, который следит не только за отдельными задачами, но и за целостностью поля задач/агентов (чтобы решения не противоречили друг другу, не дублировали усилия и не разъезжались по стилю/качеству), то получится что‑то вроде полевой модели: ассистент удерживает согласованное «рабочее состояние» проекта, а агенты и тулы — как локальные возмущения этого поля, которые должны в него аккуратно вписываться.
В любом случае, это одна из немногих статей, после которых хочется не спорить, а идти и собирать свой вариант такого ассистента. Спасибо, что приоткрыли капот — очень вдохновляет. 👍
Интересная статья, но есть нюанс - очень плохо дружат модели с русским языком. Поставил обе и протестировал: «Твоя-моя» плохо понимают)
Хороший длинный сторителлинг, честно - прочитал до конца! И даже проголосовал) С психологий, согласен, все туманно в нашем царстве-государстве. Понравилось ППП - но это для «умных»). Последний год - рынок качнуло в сторону ИИ, как психологов, так и клиентов, и особенно - наставников наставников. Будем посмотреть - кто выживет🤣