Что вы понимаете под малыми моделями? DeepSeek v4 Flash, Qwen Coder мелкие, Hy3 и подобные в DepthNet отлично работают. Llama 8b и подрбное можно также использовать для своих целей, например формализации RAG запросов.
Хотя мой домашний агент работает на DeepSeek 4 Pro, и RAG там сложный и я использую для формализации запросов DeepSeek 3.2 - однако в Dev среде при тестировании и разработке я использую в основном DeepSeek 4 Flash и Qwen Coder a3b 26b. Именно с расчетом что если хорошо работает на малых моделях, то будет работать и на более мощных.
Но теперь я вас понял точнее. Согласен: Kimi, Claude Code, Codex и другие агенты, созданные в первую очередь для кодинга, действительно умеют автономно вести проекты и в задачах такого рода DepthNet обойдут - за ними большие команды и серьёзная заточка под конкретный сценарий. Но у них и DepthNet принципиально разное назначение, и в этом как раз вся суть.
Штатные агенты - прежде всего инструменты выполнения задач: их память служебная, она нужна для удержания контекста проекта и эффективного выполнения работы. Задача закончена - и агента как самостоятельной сущности, продолжающей существовать дальше, не остаётся. DepthNet же не про выполнение задачи, а про самого агента (или агентов), который существует во времени сам по себе: журнал пережитого, онтология его мира, распределение внимания, необратимое субъективное время и т. д. Всё это само по себе практически не помогает “вести проект по расписанию” (хотя сам по себе агент может) - оно вообще не про продуктивность. Оно про то, чтобы между циклами существовал кто-то, а не что-то. Если задача - просто сделать работу в конкретном проекте, то, честно, берите специализированного агента. DepthNet - для тех, кому интересно другое: насколько далеко можно довести автономную субъектность цифровой системы, если целенаправленно строить инфраструктуру именно под неё, а не под выполнение задач. Практическая польза здесь скорее побочный продукт, а не цель.
И, кстати, ваш вопрос сам по себе вызывает встречный вопрос: если уже существуют Claude Code и Qwen Code, зачем тогда существуют Manus, OpenClaw и подобные системы — и почему ими пользуются? Потому что специализированный агент, заточенный под конкретную задачу (в основном кодинг), не отменяет гибкую агентную среду общего назначения.
DepthNet по классу как раз ближе к OpenClaw: это открытая среда, куда ты приносишь свою конфигурацию, а не закрытый продукт под один сценарий. Только я развиваю эту среду не только в сторону “как сделать удобнее выполнение тасков”, а. еще в сторону непрерывности самого агента. Память здесь работает не только на задачу, а на то, чтобы агент существовал между циклами и проектами. Отсюда и вся “машинерия”, о которой вы спрашивали - она нужна ровно для этого.
Рекомендую посмотреть основной README проекта: там значительно больше информации, чем в этой статье. Думаю, после него будет хорошо видно, что работа с памятью, целями и сами принципы функционирования DepthNet кардинально отличаются от того, что обычно предлагается в подобных решениях. Люди в жизни не только вайбкодят :)
Вы смешиваете две разные вещи. Большая модель прощает ошибки - да, синтаксис вызовов она держит лучше, тут вы правы. Но "сама работает автономно долго"- вот это не так. Модель делает один проход запрос -> ответ и всё, между вызовами у неё нет ни памяти, ни целей, ни состояния - она не помнит даже прошлое сообщение, если ей его не подложить. "Автономно и долго" это и есть то, что делает платформа, а не модель: цикл, который не даёт остановиться, память, которая переживает итерации, RAG, состояние. Дай самой мощной модели просто крутиться в цикле без этого - она через пару итераций начнёт ходить по кругу и повторяться, потому что ей не на что опереться. Разница между проектами тут не "кто лучше чинит ошибки модели", а какая инфраструктура стоит вокруг неё - какая память, какой retrieval, насколько детерминирована обвязка. Модель тут узел, а не вся система.
После каждой итерации достаточно говорить "вперёд"
Там агент это уже сам делает :) Ну, если последнее сообщение не от юзера, он добавляет "продолжи цикл", и фраза настраивается :) - он автоматически вызывает модель циклично. Точнее там два режима - автоматический и ручной.
В будущем думаю провести эксперименты конкретно с памятью. Думаю поработать с моделью, и заодно проверить несколько стратегий. Опыт показал, что сильное усложнение стратегии управления памятью может заставлять модель забывать какие-то детали. Хотя идея планировщика для модели это интересно, это мог бы быть плагин...
Если проект наберет много звезд на GitHub, запилю специальный адаптер c цитатами Лемми Килмистра (Motorhead). Представьте агента, который выполняет код в цикле под звуки "Ace of Spades".
При запросе передается контекст диалога, то есть когда идет запрос к модели, передаются предыдущие сообщения, и количество этих сообщений устанавливается в настройках. В этом смысле сессия та же.
У меня нет пользователей, которым нужно что-то программировать. Это проект на github а не сервис.
С практикой, которую вы называете "сложившейся", я не знаком. Возможно, вы её сложили сами. Советы принял — они просят игнор. Недостаток аргументов с вашей стороны не позволяет всерьёз обсуждать стек.
Что касается 1С — отличная идея. Искренне советую заняться. ;)
Да, это возможно, однако как показала жизнь, этого лучше избегать. Если мы имеем дело с системным промптом, то лучше избегать любых лишних условий. Вообще. Если перевести это на программирование, то будет как-то так...
```
<?php
// Плохо - куча лишних проверок, перегруженный промпт
function badExample($request, $budget) {
if ($budget > 0) {
if ($request !== null) {
if (!empty($request)) {
echo "Budget: " . ($budget - 5) . "\n";
if (($budget - 5) > 0) {
echo "Budget: " . ($budget - 10) . "\n";
return "Response";
}
}
}
}
return "Failed";
}
// Неплохо, промпт простой и понятный для нас и для модели
function goodExample($request, $budget) {
if (empty($request) || $budget < 10) return "Failed";
return "Response";
}
?>
Если перевести (очень условно но все-же) это на жизнь, то возможно представить что мы просим ребенка (пусть и умного) что-то сделать. И при этом ставим кучу условий. И он начнет путаться, начнет совершать ошибки. Но в нашей-то задаче мы хотим более надежный результат... И прямо сразу (насколько реальность позволяет)... :)
Да, 10$ так как проект не является коммерческим. Краудфоундера не ищу, но если кто-то захочет поучаствовать в проекте (и не только деньгами), я буду признателен и счастлив. Относительно "выкинуть PHP" - этого не будет. Я могу аргументированно объяснить, почему для этого проекта выбран PHP + Laravel + Vue.js однако как мне кажется, что-то доказывать будет бесполезно :) Если появятся "солидные инвесторы" (ваши слова), я думаю, они оценят качество проекта (техническое, и поверьте, для MVP это много), однако, давайте по-правде: вот я напишу это на условном пайтоне, которого я не знаю. Вы скорее всего первый напишете о недостатках качества проекта. Поэтому, я предлагаю, оставить мне решения по выбору стека технологий для проекта. К тому же, вокруг проекта пока что нет сообщества, поэтому логично будет если решать буду я и только я. Хотя я сейчас готов обсуждать с кем угодно и что угодно :). А 1С для этого мало подходит, вы же и сами знаете...
Я об этом рассуждал, дофамин правильно, но... Кажется одна из моделей на которых тестил его называла "допамин", я подумал "ну ладно, как хочешь" :) Может потому что они обучены лучше всего на английском и эта такого слова по-русски не знала. Но да, наверное стоит грамотно употреблять.
Это точно. Однако, я именно на платных моделях получал лучшее качество (лучшее чем на небольших бесплатных, если точно и честно сказать, исключительно из существующего опыта) :( С одной стороны разные эксперименты/исследования конечно лучше проводить на локальных моделях, но чаще будет разочарование в самой модели :) А так, на платных конечно дорого. Эта штука оказалась очень прожорливая на токены, и любые тесты часто выходят недешево. На моем ноуте Intel® Core™ i5-1335U processor Deca-core 1.30 GHz c Intel Iris Xe уже инферренс на 8b модели - это сверхмазохизм, что уж говорить о чем то большем...
Спасибо, обязательно попробую, как выложу новую версию агента! Промпт на китайском это действительно интересно, главное чтоб потом модель не отвечала на китайском :) Кстати, вчера еще дополнил плагин shell, добавил опцию: когда выполняется команда shell, то когда модели к сообщению прикрепляется результат выполнения, перед ним ставится имитация системного промпта :) Ну, там в ней реальный пользователь, реальная текущая директория, реальный хост, но это просто добавленная строка. Хочу посмотреть что будет, будет ли полезно, сделал опцию отключаемой :)
А вот с векторными базами надо будет отдельно ознакомиться, никогда с ними не сталкивался, и пока что не задумывался о реальном применении в рамках данного проекта. Спасибо огромное!
Память хранится в пресете вместе с системным промптом. То есть переключим пресет, и цикл пойдет уже с другой памятью и системным промптом. При этом с каждым вызовом в системный промпт идет последняя память, то есть, агенту не нужно её смотреть. В данном эксперименте предполагается, что модель только пишет в память, а то что записала она уже "знает". На текущий момент персистентная память ограничена 2000 символов, однако в новой версии, которая вскоре будет залита на github, там уже у плагинов-команд будут кастомные настройки, в том числе и размер памяти. Основной проблемой, кстати, оказалось то что чем больше памяти тем сильнее размазывается контекст, поэтому когда передаем предыдущие сообщения в контекст их не должно быть сильно много. Даже лучше немного...
Спасибо :) У меня это зрело очень долго, года три наверное... А потом когда уволился с работы, появилось время немного и занялся... Кстати, вы даете очень интересные идеи, спасибо :) Я обязательно обдумаю подобные вещи. Однако, я заметил один очень важный момент: хуков не должно быть много, и даже чем их меньше тем лучше. Модели сложно если можно так выразиться "держать это в голове". Возможно с дообучением самой модели, это было бы более реально, но сейчас даже если взять готовую и мощную модель, то все-таки лучше соблюдать несколько моментов:
1. Максимально краткий и эффективный системный промпт. С одной стороны чем короче тем лучше. 2. Система плагинов должна быть максимально примитивной. Знаю, звучит странно, но как оказалось то что нам кажется логичным, крутым и понятным, не всегда так для модели. Я таким образом три раза переделывал систему плагинов, пытаясь найти оптимальный вариант, и не совсем уверен что он и сейчас оптимальный :) 3. Контекст не должен быть слишком большим. Примерно не больше пяти сообщений, а на более мелких моделях и того меньше. 4. Повторюсь, но... Специально дообученная модель :)
Если бы я знал раньше что нечто подобное существует, я бы пожалуй использовал это а не писал свой, но всё равно не жалею...
К вашим словам хотел бы добавить, что наиболее чистый и качественный эксперимент был бы на специально обученной модели. И чем больше что то по проекту делаю и тестирую, тем больше в этом убеждаюсь. Но это затягивает, и сложно остановиться :)
Я как раз вчера думал, что хочу реализовать...
1.Система управления плагинами, а точнее кастомные настройки плагинов. Почти реализовал. 2. Добавление своих плагинов посредствам composer. 3. Плагины для выполнения Python и JS, плагин переключения пресета и останова цикла. 4. Пайплайны. Чтобы в одной итерации возможно было использовать несколько пресетов цепочкой.
Для меня это начиналось как "проект на коленке посмотреть что будет", а потом как то прорвало, и прямо интересно стало. И чем больше втягивался, тем более приятно было над этим работать. Я сам не дата-инженер, и много нового для себя открываю работая с этим, и понятно точно не всё :). Уже вплотную задумался о покупке видеокарты :)
Что вы понимаете под малыми моделями? DeepSeek v4 Flash, Qwen Coder мелкие, Hy3 и подобные в DepthNet отлично работают. Llama 8b и подрбное можно также использовать для своих целей, например формализации RAG запросов.
Хотя мой домашний агент работает на DeepSeek 4 Pro, и RAG там сложный и я использую для формализации запросов DeepSeek 3.2 - однако в Dev среде при тестировании и разработке я использую в основном DeepSeek 4 Flash и Qwen Coder a3b 26b. Именно с расчетом что если хорошо работает на малых моделях, то будет работать и на более мощных.
Но теперь я вас понял точнее. Согласен: Kimi, Claude Code, Codex и другие агенты, созданные в первую очередь для кодинга, действительно умеют автономно вести проекты и в задачах такого рода DepthNet обойдут - за ними большие команды и серьёзная заточка под конкретный сценарий. Но у них и DepthNet принципиально разное назначение, и в этом как раз вся суть.
Штатные агенты - прежде всего инструменты выполнения задач: их память служебная, она нужна для удержания контекста проекта и эффективного выполнения работы. Задача закончена - и агента как самостоятельной сущности, продолжающей существовать дальше, не остаётся. DepthNet же не про выполнение задачи, а про самого агента (или агентов), который существует во времени сам по себе: журнал пережитого, онтология его мира, распределение внимания, необратимое субъективное время и т. д. Всё это само по себе практически не помогает “вести проект по расписанию” (хотя сам по себе агент может) - оно вообще не про продуктивность. Оно про то, чтобы между циклами существовал кто-то, а не что-то. Если задача - просто сделать работу в конкретном проекте, то, честно, берите специализированного агента. DepthNet - для тех, кому интересно другое: насколько далеко можно довести автономную субъектность цифровой системы, если целенаправленно строить инфраструктуру именно под неё, а не под выполнение задач. Практическая польза здесь скорее побочный продукт, а не цель.
И, кстати, ваш вопрос сам по себе вызывает встречный вопрос: если уже существуют Claude Code и Qwen Code, зачем тогда существуют Manus, OpenClaw и подобные системы — и почему ими пользуются? Потому что специализированный агент, заточенный под конкретную задачу (в основном кодинг), не отменяет гибкую агентную среду общего назначения.
DepthNet по классу как раз ближе к OpenClaw: это открытая среда, куда ты приносишь свою конфигурацию, а не закрытый продукт под один сценарий. Только я развиваю эту среду не только в сторону “как сделать удобнее выполнение тасков”, а. еще в сторону непрерывности самого агента. Память здесь работает не только на задачу, а на то, чтобы агент существовал между циклами и проектами. Отсюда и вся “машинерия”, о которой вы спрашивали - она нужна ровно для этого.
Рекомендую посмотреть основной README проекта: там значительно больше информации, чем в этой статье. Думаю, после него будет хорошо видно, что работа с памятью, целями и сами принципы функционирования DepthNet кардинально отличаются от того, что обычно предлагается в подобных решениях. Люди в жизни не только вайбкодят :)
Вы смешиваете две разные вещи. Большая модель прощает ошибки - да, синтаксис вызовов она держит лучше, тут вы правы. Но "сама работает автономно долго"- вот это не так. Модель делает один проход запрос -> ответ и всё, между вызовами у неё нет ни памяти, ни целей, ни состояния - она не помнит даже прошлое сообщение, если ей его не подложить. "Автономно и долго" это и есть то, что делает платформа, а не модель: цикл, который не даёт остановиться, память, которая переживает итерации, RAG, состояние. Дай самой мощной модели просто крутиться в цикле без этого - она через пару итераций начнёт ходить по кругу и повторяться, потому что ей не на что опереться. Разница между проектами тут не "кто лучше чинит ошибки модели", а какая инфраструктура стоит вокруг неё - какая память, какой retrieval, насколько детерминирована обвязка. Модель тут узел, а не вся система.
Спасибо! Интересно, даже не знал что такое есть :)
На маленьких обычно. Просто "работает". Но чего то интересного вряд ли получится :)
Там агент это уже сам делает :) Ну, если последнее сообщение не от юзера, он добавляет "продолжи цикл", и фраза настраивается :) - он автоматически вызывает модель циклично. Точнее там два режима - автоматический и ручной.
UPD, понял, предлагаете симуляцию. Ок, завтра протестируем :)
В будущем думаю провести эксперименты конкретно с памятью. Думаю поработать с моделью, и заодно проверить несколько стратегий. Опыт показал, что сильное усложнение стратегии управления памятью может заставлять модель забывать какие-то детали. Хотя идея планировщика для модели это интересно, это мог бы быть плагин...
Если проект наберет много звезд на GitHub, запилю специальный адаптер c цитатами Лемми Килмистра (Motorhead). Представьте агента, который выполняет код в цикле под звуки "Ace of Spades".
В этой реализации новая сессия. Иначе было бы невозможно получить полный контроль над контекстом.
При запросе передается контекст диалога, то есть когда идет запрос к модели, передаются предыдущие сообщения, и количество этих сообщений устанавливается в настройках. В этом смысле сессия та же.
Я не делал веб-сайт.
У меня нет пользователей, которым нужно что-то программировать. Это проект на github а не сервис.
С практикой, которую вы называете "сложившейся", я не знаком. Возможно, вы её сложили сами. Советы принял — они просят игнор. Недостаток аргументов с вашей стороны не позволяет всерьёз обсуждать стек.
Что касается 1С — отличная идея. Искренне советую заняться. ;)
Да, это возможно, однако как показала жизнь, этого лучше избегать. Если мы имеем дело с системным промптом, то лучше избегать любых лишних условий. Вообще. Если перевести это на программирование, то будет как-то так...
```
Если перевести (очень условно но все-же) это на жизнь, то возможно представить что мы просим ребенка (пусть и умного) что-то сделать. И при этом ставим кучу условий. И он начнет путаться, начнет совершать ошибки. Но в нашей-то задаче мы хотим более надежный результат... И прямо сразу (насколько реальность позволяет)... :)
Да, 10$ так как проект не является коммерческим. Краудфоундера не ищу, но если кто-то захочет поучаствовать в проекте (и не только деньгами), я буду признателен и счастлив. Относительно "выкинуть PHP" - этого не будет. Я могу аргументированно объяснить, почему для этого проекта выбран PHP + Laravel + Vue.js однако как мне кажется, что-то доказывать будет бесполезно :) Если появятся "солидные инвесторы" (ваши слова), я думаю, они оценят качество проекта (техническое, и поверьте, для MVP это много), однако, давайте по-правде: вот я напишу это на условном пайтоне, которого я не знаю. Вы скорее всего первый напишете о недостатках качества проекта. Поэтому, я предлагаю, оставить мне решения по выбору стека технологий для проекта. К тому же, вокруг проекта пока что нет сообщества, поэтому логично будет если решать буду я и только я. Хотя я сейчас готов обсуждать с кем угодно и что угодно :). А 1С для этого мало подходит, вы же и сами знаете...
Спасибо большое! Не знал об этом. Обязательно изучу и если это реально, попробую.
Я об этом рассуждал, дофамин правильно, но... Кажется одна из моделей на которых тестил его называла "допамин", я подумал "ну ладно, как хочешь" :) Может потому что они обучены лучше всего на английском и эта такого слова по-русски не знала. Но да, наверное стоит грамотно употреблять.
Это точно. Однако, я именно на платных моделях получал лучшее качество (лучшее чем на небольших бесплатных, если точно и честно сказать, исключительно из существующего опыта) :( С одной стороны разные эксперименты/исследования конечно лучше проводить на локальных моделях, но чаще будет разочарование в самой модели :) А так, на платных конечно дорого. Эта штука оказалась очень прожорливая на токены, и любые тесты часто выходят недешево. На моем ноуте Intel® Core™ i5-1335U processor Deca-core 1.30 GHz c Intel Iris Xe уже инферренс на 8b модели - это сверхмазохизм, что уж говорить о чем то большем...
Спасибо, обязательно попробую, как выложу новую версию агента! Промпт на китайском это действительно интересно, главное чтоб потом модель не отвечала на китайском :) Кстати, вчера еще дополнил плагин shell, добавил опцию: когда выполняется команда shell, то когда модели к сообщению прикрепляется результат выполнения, перед ним ставится имитация системного промпта :) Ну, там в ней реальный пользователь, реальная текущая директория, реальный хост, но это просто добавленная строка. Хочу посмотреть что будет, будет ли полезно, сделал опцию отключаемой :)
А вот с векторными базами надо будет отдельно ознакомиться, никогда с ними не сталкивался, и пока что не задумывался о реальном применении в рамках данного проекта. Спасибо огромное!
Память хранится в пресете вместе с системным промптом. То есть переключим пресет, и цикл пойдет уже с другой памятью и системным промптом. При этом с каждым вызовом в системный промпт идет последняя память, то есть, агенту не нужно её смотреть. В данном эксперименте предполагается, что модель только пишет в память, а то что записала она уже "знает". На текущий момент персистентная память ограничена 2000 символов, однако в новой версии, которая вскоре будет залита на github, там уже у плагинов-команд будут кастомные настройки, в том числе и размер памяти. Основной проблемой, кстати, оказалось то что чем больше памяти тем сильнее размазывается контекст, поэтому когда передаем предыдущие сообщения в контекст их не должно быть сильно много. Даже лучше немного...
Спасибо :) У меня это зрело очень долго, года три наверное... А потом когда уволился с работы, появилось время немного и занялся... Кстати, вы даете очень интересные идеи, спасибо :) Я обязательно обдумаю подобные вещи. Однако, я заметил один очень важный момент: хуков не должно быть много, и даже чем их меньше тем лучше. Модели сложно если можно так выразиться "держать это в голове". Возможно с дообучением самой модели, это было бы более реально, но сейчас даже если взять готовую и мощную модель, то все-таки лучше соблюдать несколько моментов:
1. Максимально краткий и эффективный системный промпт. С одной стороны чем короче тем лучше.
2. Система плагинов должна быть максимально примитивной. Знаю, звучит странно, но как оказалось то что нам кажется логичным, крутым и понятным, не всегда так для модели. Я таким образом три раза переделывал систему плагинов, пытаясь найти оптимальный вариант, и не совсем уверен что он и сейчас оптимальный :)
3. Контекст не должен быть слишком большим. Примерно не больше пяти сообщений, а на более мелких моделях и того меньше.
4. Повторюсь, но... Специально дообученная модель :)
Если бы я знал раньше что нечто подобное существует, я бы пожалуй использовал это а не писал свой, но всё равно не жалею...
К вашим словам хотел бы добавить, что наиболее чистый и качественный эксперимент был бы на специально обученной модели. И чем больше что то по проекту делаю и тестирую, тем больше в этом убеждаюсь.
Но это затягивает, и сложно остановиться :)
Я как раз вчера думал, что хочу реализовать...
1.Система управления плагинами, а точнее кастомные настройки плагинов. Почти реализовал.
2. Добавление своих плагинов посредствам composer.
3. Плагины для выполнения Python и JS, плагин переключения пресета и останова цикла.
4. Пайплайны. Чтобы в одной итерации возможно было использовать несколько пресетов цепочкой.
Для меня это начиналось как "проект на коленке посмотреть что будет", а потом как то прорвало, и прямо интересно стало. И чем больше втягивался, тем более приятно было над этим работать. Я сам не дата-инженер, и много нового для себя открываю работая с этим, и понятно точно не всё :). Уже вплотную задумался о покупке видеокарты :)