Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 37
Актуально как никогда, я своего попросил все папки на диске как окрщик разложить и он сам ведет дневник в Обсидиан
Хмм, у меня это решает свой самописный агент, у него есть специальная память незакрытых тем, с весами, если я что то обсуждаю с ним, и откладываю на потом, он периодически мне напоминает, чем дольше я откладываю решение тем чаще агент пристает ко мне с этим вопросом =)
Вот это и есть менеджер для моей доски только с характером. Два вопроса, если не секрет: по какому правилу растёт вес, просто от времени или от того, сколько раз тема всплывала в разговоре? И может ли агент сам закрыть тему, если видит, что она решилась по ходу, или закрываете только вы? У меня больше всего карточек протухает именно потому, что их решили, а не потому, что забыли.
У меня там все не совсем просто....
Посмотрел код, я чуток ошибся, у меня сделано наоборот, заряд весов падает во времени, примерно за трое суток, чем дальше тем реже агент напоминает, но если тема всплывает в разговоре, или я к примеру игнорирую напоминание агента, то тема получает заряд к весам, и тем самым она не когда по сути не умирает полностью, заряд есть всегда, и так же это завязано на производственный календарь, агент может поставить себе постоянный циклический будильник, который так же влияет на заряд весов =)
Снять тему я могу только сам, то-есть агент ее без моей отмашки сам не снимает некогда, но тут есть нюанс, как вы и сказали если тема решена агент просто уточняет, закрыть ? я даю отмашку и тема уходит в историю. а так как память у него постоянная можно всегда спросить что мы обсуждали полгода назад, и он дословно проецирует если нужно и чем это было закрыто
Спасибо, что заглянули в код. Получается, забытая тема сама по себе исчезает из поля зрения, а «отмахнулся от напоминания» её наоборот подзаряжает. Захотелось даже смоделировать, как в среднем будет реагировать на поток задач такая система.
«Закрыть?» с отмашкой это мои пожелания к агенту-проект менеджеру. А вот «чем это было закрыто» через полгода у меня размазано: у карточек из кода ответ в коммите, у маркетинговых в ссылке на публикацию, и спросить одним вопросом «что мы решили в апреле» некого. Трёхдневный спад вы подбирали руками или просто первое число прижилось? И не копится ли внизу слой тем, которые никогда не всплывают, но и не умирают?
Даже не знаю, будет ли работать такая схема незакрытых тем как отдельный механизм, так как появилась она по мере развития агента и все это связанно с его памятью от части.
Трехдневный спад появился эмпирически, и прижился, а веса заряда калибровались, и подобраны таким образом что бы не захватывать проходные темы, и концентрироваться на том что важно.
Накопление тем не происходит, от части из за того, что у моего агента память ассоциативная и многоуровневая с несколькими механизмами, хеббиан, матричная факторизация графа, механизм (tip-of-the-tongue): “знаю, что знаю, но не могу вспомнить” и т.д.
При этом время встроено в саму память, с дословным архивом.
То-есть в отличии от RAG или тем более стандартного подхода с .md файлами, память работает как накопление опыта, а тот же rag как поиск по смыслу.
Таким образом когда он вспоминает какую-то горячую незакрытую тему он так же может подтянуть и остальные незакрытые темы которые могли потеряться, и напомнить о них или перечислить, либо использовать инструмент и просто посмотреть что там висит =)
И на счет вашего "размазано" как раз по этому я и строил ассоциативную память, она связывает факты которые встречались вместе, и могут быть разнесены во времени.
Записи связываются по сущностям и совместным всплытиям независимо от того, насколько далеко они разнесены, поэтому "что мы решили в апреле" агенту не нужен расклад по датам, достаточно вопроса, ассоциация сама подтянет и решение, и чем оно закончилось в октябре, а агент залезет в память и прочитает все события дословно если нужно
Спасибо за подробный ответ, это уже не «агент с напоминалкой», а своя память. Тогда у меня один вопрос по существу. У нас с коллегами есть наблюдение, что устаревший текст в досягаемости агента ему скорее вредит, чем помогает: старая инструкция или уже отменённое решение подхватываются с той же уверенностью, что и свежие. У вас спад заряда работает только на незакрытые темы или на факты тоже? То есть если в апреле решили одно, а в октябре переиграли, ассоциация подтянет оба, и кто из них побеждает: более позднее, более «заряженное», или агент отдаёт оба и спрашивает? И есть ли это где-то описано или в коде, почитать? Я бы попробовала для себя такое применить
Тут схема с несколькими механиками. Спад заряда работает только на незакрытые темы. Факты стареют другим механизмом, календарным уменьшение веса записи : вес записи = результат × 0.5^(возраст/период) × частота использования.
Решение, которым полгода не пользовались, тонет само, без всякого конфликта.
Ретривер подтягивает по релевантности запроса с приоритетом, записи в памяти резонируют не на саму фразу пользователя а на весь контекст текущей беседы который в данный момент в окне, но имеется ранжирование. и Top N что бы не тащить все.
Вот тут я приведу цитату из свое статьи которую я все не как не допишу =) один из механизмов памяти конфликтные ребера.
Конфликтные рёбра - ассоциативная память учится на опыте, удачный ход укрепляет связи между поднятыми записями, неудачный штрафует. Учиться на неудачах обязательно, иначе агент будет повторять ошибки.
Как работает этот механизм. Агент получил задание, активация разошлась по графу и подняла какие-то записи. Это повлияло на то, как он построил ход: что сделал, какие инструменты вызвал, что сказал. Ход закончился провалом. Система учится по результатам ходов: раз ход провалился, значит, связи, которые в нём участвовали, получают штраф.
Обучение связи и её старение:
w(n, m) ← w(n, m) + η · r w(n, m) ← w(n, m) · 2^(−Δt / T½)
w(n, m) — вес связи; η — скорость обучения, насколько один ход меняет вес; r — результат хода: +1 успех, −1 провал; Δt — время с последнего использования связи; T½ — период полураспада, за время, равное T½, невостребованная связь теряет половину веса.
Где проблема. Провал мог быть не из-за записей. Записи могли быть абсолютно верные и релевантные, а ход провалился потому, что упал сервер, не хватило данных или любой внешний сбой. Но система этого не знает: она видит только ход провалился и вот записи, которые в нём участвовали. И штрафует их за то, к чему они не имеют отношения. Вторая проблема, дрейф знаний: правило, выученное полгода назад, устаревает, и рядом появляется новое, ему противоречащее.
Решается это через отдельный фоновый контур который разбирает накопившиеся конфликтные пары записей. Контур читает обе записи, вес ребра, историю использования и дает одно из трех заключений.
Ложный штраф: конфликтное ребро удаляется, обе записи остаются, связи между ними больше нет. Если в будущем они будут подниматься вместе в удачных ходах, связь вырастет заново, уже положительная.
Обе записи утверждают одно и то же правило, но одна устарела, устаревшая помечается удалённой с указанием причины, и агент больше её не вспомнит.
Оба верны при разных условиях, живут обе, и при совместной выдаче агент видит пометку: записи спорные, первая верна при одних условиях, вторая при других.
В ситуации если к примеру обе записи доехали вместе, ретривер не выбирает, он клеит пометку DISAGREE («обе оставлены: применимы при разных условиях»). Агент видит противоречие и решает сам: разобраться по контексту или спросить пользователя.
Так же, каждая запись в [RELEVANT MEMORY] рендерится с датой yyyy-MM-dd, модель сама видит «апрель» и «октябрь» рядом и решает, опираясь на видимую причину.
Спасибо, это самый подробный ответ из всех, что я получала под статьями. Два места совпали с тем, к чему я пришла с другой стороны. Дата рядом с каждой записью, чтобы модель сама видела «апрель» и «октябрь»: у меня в историях на worklore так же, дата и пометка «может быть устаревшим» видны агенту, и решает он, а не фильтр. И «обе верны при разных условиях» с пометкой DISAGREE: у меня это называется исправлением с примечанием, старая версия не удаляется, а читателю видно, почему появилась новая.
Про фоновый контур вопрос: кто выносит одно из трёх заключений, модель, которая читает обе записи и историю рёбра, или правило? И когда агент при DISAGREE спрашивает пользователя, ответ записывается обратно как условие, или пара так и остаётся спорной до следующего прохода?
Допишите статью, пожалуйста. Я бы на неё сослалась, когда организую свой новый метод хранения идей и буду им делиться в новой статье.
Да, фоновый контур это модель, у меня контура разделены, есть оркерстратор, тот с кем общается пользователь, воркер, тот кто выполняет указания оркерстратора, и фоновые контура, обслуживающие механизмы, там есть как код на основе разных метрик, который следит за чистотой графа, так и вызовы LLM, это все может быть настроено на разные модели или провайдеров, в зависимости от надобности.
При DISAGREE ответ уходит стандартным каналом в память, далее его обрабатывает фоновый вызов LLM, так же агент сразу может себе записать в заметки нужный вариант ответа от пользовался, тем самым выбрав правильную стратегию.
Потому что когда агент спрашивает пользователя, вопрос обычно не «кто прав», а «какое из двух условий сейчас действует».
Так же, главное, не переборщить с контекстом, как вы выше правильно заметили, старые и разнородные записи сильно путают модель, отсюда релевантность запросу дедупликация, и ограничение выдачи играет одну из ключевых ролей в том насколько агент будет адекватен, я на это потратил довольно много времени что бы добиться правильной работы ретривера, контекстное окно у меня пересобирается каждый ход, и не просто абы как, а по весу и релевантности записей ранжируется.
Отсюда есть и негативные технические моменты, kv кеш сильно страдает, по замерам его эффективность порядка 60% по этому я и ввел разделение на оркерстратора и воркера,
У них совершенно разный подход к памяти и контекстному окну, если первый играет роль мозга, и работает реже, то воркер решает задачи которые требуют множества вызовов( к примеру работа с кодом) и его контур лоялен к кешу и достигает 90% эффективности.
Про 60% против 90% для кеша — спасибо, что назвали цену. Это как раз то, что я хотела понять: пересборка окна по весу каждый ход звучит красиво, но за неё платят, и вы это померили. Разделение на «мозг» и «руки» с разной дисциплиной памяти выглядит разумным ответом, у меня похожее получилось случайно, когда длинные кодовые задачи ушли в отдельные сессии, а планирование осталось в одной.
Один вопрос, если позволите: когда ретривер ранжирует по весу и релевантности и режет выдачу, бывает, что он выкидывает запись, которую пользователь явно просил держать всегда? Как у вас устроены такие «прибитые» записи, или их нет и всё решает вес?
Мне кажется, ваша система пользовалась бы популярностью у разработчиков, если бы вы поделились репозиторием. Не каждый готов столько времени удалить настройке рабочих сессий с агентом
Ретривер получает и ранжирует записи только из графа, сами по себе эти записи являются структурированным json с четкими полями которые заполняет фоновый контур, так достигается точное соответствие, и даже малые модели, с этим справляются хорошо.
Остальные записи вроде заметок самого агента, профиля пользователя, правила поведения агента, хроника наблюдений, календарь, контуры досье, и остальные ночные аналитики, которые выдают советы и поправки, не входят в зону ответственности ретривера, все эти записи помечаются отдельными тегами вроде [RELEVANT MEMORY] и т.д, а так как все это единообразно, модель понимает что это и откуда.
В зависимости от природы, записи, могут либо всегда висеть в окне, либо показываться на каком то определенном шаге.
Такая компоновка нужна и для внешних интеграций, в агенте нет MCP и скилов, там совсем другой принцип взаимодействия с внешним миром, который позволяет следить за тысячами устройств или задач, без роста контекстного окна, и почти детерминированным качеством выполнения алертов.
Ладно, думаю хватит рассказывать, а то это уже похоже на какую-то рекламу агента =)))))
Мне кажется, ваша система пользовалась бы популярностью у разработчиков, если бы вы поделились репозиторием.
По поводу этого, репозитория нет, я не открывал код, этот проект я делал в первую очередь для себя, в качестве помощника на работе, я не программист, а сисадмин, отсюда больше интересовало не возможность агента работы с кодом, а прикладное применение в реальных повседневных задачах, мониторинг разного железа с софтом, алерты, рассылки, ответы пользователям, оповещением меня в Matrix и т.д.
Короче младший технический работник который не требует перекуров и плюшек с кофе, и ведет себя вполне адекватно как это и должен делать в теории настоящий ИИ =)))
Поддерживаю. Я бы тоже с удовольствием почитал про устройство памяти Вашего агента
Идея с угасанием веса за трое суток звучит круто, чистый аналог человеческой памяти. Если тема не всплыла в работе, значит туда ей и дорога)
Ну, на самом деле я старался выстраивать архитектуру агента по своим собственным ощущениям, прикидывал, как вы правильно подметили, что если тема не всплыла то ну ее лесом =)
Но в тоже время так как у нас это все же компьютерная программа которая в первую очередь должна помогать человеку а не быть таким же маразматиком, то прикрутил к нему постоянную память, где все что он забыл так или иначе сохраняется дословно, и может быть найдено по запросу, что бы в случае как это часто бывает, через месяц или два, кто то вспомнил, что оказывается прошлое решение было необходимо еще вчера =)))
Агенту говорю добавь этот вопрос, задачу в todo.md с выставленным приоритетом, раз в час скрипт обходит все todo.md и plan.md, добавляет на доску в gitea, того что нет, помечает закрыто если задачу сделали или переместили на доске. Раз в сутки проверочный скрипт проверяет на коллизии и ошибки (так как синхронизация двунаправленная). От захломления пока спасает дисциплина.
Это почти моя доска, только источник правды перевёрнут: у вас todo.md в репозитории, а доска в Gitea его отражение, у меня наоборот, и именно поэтому доска и захламилась: файл агент видит каждую сессию, а посмотреть на доску его надо попросить. Два вопроса. Что чаще всего ловит суточная проверка: одну и ту же задачу, переименованную с двух сторон, или закрытое в файле и живое на доске? И «дисциплина» это что конкретно: вы перечитываете todo.md перед сессией, или просто не даёте агенту писать туда без приоритета?
Я сам доску почти не трогую. Она чиста визуал, чтобы открыть понять объем работ и над чем сейчас нужно поработать, todo.md или plan.md такого эффекта мне не дает. Я говорю агенту давай сделаем задачу №15 из доски backlog'а, и над ней начинаем работать, и он сам двигает задачу, отмечает ее выполненной в todo.
Суточная проверка ловила пока только косяки агента, например что он при добавление забыл поставить идентификатор карточки доски (отметка чтобы было понятно добавлена ли карточка на доску или нет)
Дисциплина тут скорее в том что не ленится открывать доску и смотреть за какую приоритетную задачу взяьться
Если агент умеет сам выставлять приоритеты по контексту разговора, это здорово экономит силы
Останется только не забывать раз в неделю чистить выполненные пункты, чтобы файл не разрастался до мегабайта)
Плюсую Обсидиан. Несколько папок. Одна со стратегическими темами, одна с заметками по текущим задачам и бэклог, одна с идеями, которые было бы прикольно пощупать, но совсем не обязательно. Ну и ещё ряд папок, не относящихся к делу.
И главное — жёсткая резня идей. Их один фиг будет больше, чем реально воплотить, а в большом количестве часть протухает, часть теряется. Идеи сейчас безумно дёшевы, плодятся как тараканы. Если появляются сомнения — удаляю. Они тормозят и мешают сфокусироваться на чём-то важном, создавая лишь иллюзию полезного изобилия.
С «идеи дешевы» полностью согласна, за шесть недель моя доска это и доказала. Вопрос про резню: вы режете в момент, когда идея появилась, или проходом раз в какое-то время? У меня в момент появления рука не поднимается, все кажутся хорошими. Они и через месяц не так уж плохи и вполне могут пойти в дело, просто к тому времени находятся идеи ещё лучше, и старые на их фоне уже не такие. Так что удалять приходится не плохое, а то, на что времени не хватило. И папку с идеями читаете только вы, или агент тоже в неё заглядывает, когда предлагает, что делать дальше?
Всё динамично, потому что агенты умнеют и практики перестраиваю. Я пользуюсь тем, что наш (как минимум мой) мозг в разные моменты времени мыслит очень по разному, и что-то кажется в один момент гениальным и срочным к воплощению, в другой момент полной чушью, потом ещё под каким-то углом.
Записываю сразу всё, что мне в моменте кажется полезным. Зачищаю периодически то, что кажется не воплощу, и то, в отношении чего появляется мысль "если вспомню эту идею ещё раз и опять покажется значимой — впишу, а иначе на свалку"
Агент имеет доступ ко всему, и иногда предлагает совместить что-то с чем-то или предлагает решение, которое заодно продвинет другую идею. Но каталог идей (не путать с бэклогом насущного) это скорее мой плейграунд, где я могу оглядеться и выбрать направления движения. Причём не факт, что движение будет по какой-то из идей, обычно у меня происходит синтез, когда я замечаю совпадающие ключевые моменты у нескольких идей, и реализую что-то другое, более точное. Если же каталог разбухает настолько, что его нельзя оглядеть, а в нём оказывается что-то уже не актуальное, то это уже мешающая мусорка. Агент в принципе не может ни произвести синтез (ведь он не знает, чем именно меня привлекает каждая идея), ни отсеять мусор (ведь это тоже зачастую субъективно).
Ну и бэклоги, и каталоги идей всегда будут больше возможностей. Зачастую приходится выбирать не то, что больше хочется реализовать, а то, что не готов отказаться реализовывать. Забавно, но это два разных приритета, "насколько хочу сделать" и "насколько готов не делать". Чистка каталога отлично помогает понять второй.
Имхо, слишком много задач. Напоминает задачу коммивояжёра, где при увеличении количества параметров задача становится нерешаемой. Все дела не переделаешь, брать главное, выбрасывать ненужное не жалея.
Я от Обсидиана подустал немножко, вот Tolaria пробую вторую неделю — https://tolaria.md, в принципе норм, там достаточно разумно всё (особенно если с GTD знакомы), хотя и не без багов.
Спасибо за наводку, не знала. Посмотрела: каждый vault это git-репозиторий и в комплекте AGENTS-файл для Claude Code и Codex, то есть та схема, о которой выше пишут про Обсидиан, только из коробки. Из-за чего от Обсидиана устали, если не секрет: от плагинов или от того, что агент в него не заглядывает? И как в Tolaria с устарешими заметками: там есть что-то, кроме дисциплины, чтобы старое не попадалось агенту наравне с новым?
В обсидиане, пожалуй, чуть больше "информационного шума" и да, плагины нужны, он в общем более навроченный. Тут более минималистично. Мне понравилась система фильтров-видов, когда на заметки можно посмотреть под разными "углами", легко сделать систему контекстов (я вообще люблю GTD). Старые заметки можно архивировать, в контектном меню есть такой пункт, там при этом просто в заголовке проставляется _archived: true, ну и можно агента просить в такие на лазить. Очень зашла интеграция с гитхабом - настроил и забыл, в статусе всё показано, автокоммитит прямо в мастер - всё как мы любим, настоящиим джедаям бранчи не нужны ;). Типы и папки норм, в общем больше ничего не надо. В Обсидиане я темплейтами пользуюсь, тут тоже есть, хоть и примитивно. Опять же никто не запрещает то же самое хранилище и обсидианом открыть - они на маркдауне практически совместимы. Но тут надо просто попробовать - оно или приживётся или нет.
Тоже поглядывал на Tolaria из-за прямой интеграции с репозиториями, для кода и документации концепция отличная, но для быстрых мыслей на ходу телефон все равно удобнее
Напрашивается необходимость какого-то личного классификатора и маркировки мета-данными. С тех точек зрения, по которым потом намереваешься поискать. Но при этом коассификация и маркировка не должны превращаться в самостоятельную трудоемкую и напряженную задачу. Как бы разрешить это противоречие? ))
Ну вот посмотрите Tolaria, что комментом выше, я только что попробовал запустить в хранилище OpenCode, у меня накопилось там в инбоксе куча скриншотов, я попросил их классифицировать как мне надо, она проанализировала их содержимое, создала заголовки заметок, всё разумно. В принципе это с Обсидианом можно сделать, но там довольно удобно, что это дело с ИИ в одном флаконе и с гитхабом уже интегрировано, она сама комитит, если что не так, всегда можно откатиться.
Противоречие у меня разрешилось тем, что размечает не человек. Идея рождается в сессии, и агент в этот момент знает про неё больше, чем я вспомню через месяц, так что теги, проект и «откуда взялось» он ставит сам. Я могу только добавить что-то дополнительное, когда что-то ищу.
Я пришел к тому, что держу один локальный файл TODO.md в корне репозитория строго для текущей итерации. Все что не попало в ближайший спринт или коммит - удаляется прям во время сессии с агентом. Если идея действительно стоящая, она всплывет в голове еще раз во время тестов
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Куда девать идеи из сессий с coding‑агентом: пять мест, и доска, которая за шесть недель стала свалкой