Вы точно правы, что стена именно в рутине интеграций.
Пара мест, где поспорю. Цикл «Сенсорика → Сон → Разум → Действие» - это по сути расписанный пошаговый обход, то есть поллинг. Я же сознательно уходил от поллинга к проактивности: мы не проверяем все на каждом тике, а давление само растёт и действие рождается при переходе порога. Это другая динамика - событийная, а не по кругу. За простоту сборки из кубиков платишь именно этим.
Про локалки - рад, если у вас Qwen тянет автономку. У меня для слоя сознания они не дотягивали: не ловили корреляции, игнорировали инструкции. Для медленных когнитивных фаз на часы - возможно, ок, но для отзывчивого компаньона в реальном времени критично.
И главное: готовые утилиты снимают инфраструктурную боль, но не убирают детерминизм. Трекеру калорий всё равно нужна схема и БД - markdown-вектор тут не спасёт. Рутину можно сократить, но не обнулить.
При этом по сути вы описываете ровно то, к чему я и склоняюсь - переложить рутину на готовый каркас, оставив LLM рефлексию. Сейчас прикидываю это как плагин к Hermes Agent.
Справедливо про порог, согласен, что более мощная модель его сдвигает, а не убирает. Потолок текущих моделей никуда не девается, и локалки просто упёрлись в него первыми. Это, по сути, и есть вывод статьи, модель побольше не требует такой тщательной работы с промптом.
А вот про очередной RAG не согласен. RAG — это получение данных на момент запроса: пришёл вопрос, мы подтянули контекст, ответили. Здесь весь смысл обратный: агент действует без запроса. Heartbeat, накопление давления, пробуждение по порогу, слои с энергобюджетом - это про проактивный контур управления, а не про то, как достать релевантный кусок памяти. Память - это лишь одна деталь. Я в этом проекте использовал векторный и графовый поиск. Можно собрать систему вообще без RAG, и проактивность не исчезнет, а можно прикрутить идеальный RAG к чат-боту — и он останется реактивным.
А ни за что, у меня нет кармы, чтобы снижать карму :)
но многие боятся писать статьи и комментарии дальше и превращаются в ReadOnly без ReadOnly.
Я как раз из таких, и даже этот комментарий страшновато писать, вдруг кому-нибудь не понравится. Достаточно того, чтобы твоя точка зрения не совпала с большинством - и ты лишаешься почти всех функций хабра.
Тоже несколько дней пытался понять, почему же комп просыпается. Отключал все, что только можно, помогла остановка службы TeamViewer 10. При этом, что странно, источник был не таймер generic, а неизвестный источник.
А поясните, пожалуйста, после оплаты будет возможность распечатать платежное поручение или какой-нибудь документ, который может подтвердить факт оплаты? Потому как я сделал платеж, а теперь сомневаюсь, что поступил правильно. При оплате через банк я могу получить квитанцию, а у вас?
Вы точно правы, что стена именно в рутине интеграций.
Пара мест, где поспорю. Цикл «Сенсорика → Сон → Разум → Действие» - это по сути расписанный пошаговый обход, то есть поллинг. Я же сознательно уходил от поллинга к проактивности: мы не проверяем все на каждом тике, а давление само растёт и действие рождается при переходе порога. Это другая динамика - событийная, а не по кругу. За простоту сборки из кубиков платишь именно этим.
Про локалки - рад, если у вас Qwen тянет автономку. У меня для слоя сознания они не дотягивали: не ловили корреляции, игнорировали инструкции. Для медленных когнитивных фаз на часы - возможно, ок, но для отзывчивого компаньона в реальном времени критично.
И главное: готовые утилиты снимают инфраструктурную боль, но не убирают детерминизм. Трекеру калорий всё равно нужна схема и БД - markdown-вектор тут не спасёт. Рутину можно сократить, но не обнулить.
При этом по сути вы описываете ровно то, к чему я и склоняюсь - переложить рутину на готовый каркас, оставив LLM рефлексию. Сейчас прикидываю это как плагин к Hermes Agent.
Справедливо про порог, согласен, что более мощная модель его сдвигает, а не убирает. Потолок текущих моделей никуда не девается, и локалки просто упёрлись в него первыми. Это, по сути, и есть вывод статьи, модель побольше не требует такой тщательной работы с промптом.
А вот про очередной RAG не согласен. RAG — это получение данных на момент запроса: пришёл вопрос, мы подтянули контекст, ответили. Здесь весь смысл обратный: агент действует без запроса. Heartbeat, накопление давления, пробуждение по порогу, слои с энергобюджетом - это про проактивный контур управления, а не про то, как достать релевантный кусок памяти. Память - это лишь одна деталь. Я в этом проекте использовал векторный и графовый поиск. Можно собрать систему вообще без RAG, и проактивность не исчезнет, а можно прикрутить идеальный RAG к чат-боту — и он останется реактивным.
А ни за что, у меня нет кармы, чтобы снижать карму :)
Я как раз из таких, и даже этот комментарий страшновато писать, вдруг кому-нибудь не понравится. Достаточно того, чтобы твоя точка зрения не совпала с большинством - и ты лишаешься почти всех функций хабра.