Forwarded from Alex LLM Neighbors
🧠 LLM Neighbors - Vol.11
🗣Pitch and workshop
по традиции в Сб 23 августа 18:00 (UTC+3) (отметься чтобы записаться на звонок )
✍️Agenda:
- 18:00-18:30 ~ 30 min - small talk, think big =)
- ~18:30 - 21:00 Guro Bokum - Liman AI Agentics
(30 min
- ~ 21:30-до ночи до упора) - Глеб Кудрявцев - Shotgun
Кудрявцев Глеб
CEO Карьерный Цех, microboard.io, ex CPO Skyeng.
Разработчик. Эксперт в AI-assisted разработке. Автор популярного приложения для программирования с ИИ — Shotgun (1500 звезд на гитхабе).
Область интереса — программирование агентов, промпт-инженерия и подготовка контекстов (в т.ч. RAG, Knowledge graph и т.д.), b2b/b2c продукты на основе AI.
После успеха Шотгана, решил расширить его возможности и сейчас делаю "взрослый" suite для агентского кодинга:
— Автоматизированное составление онтологии проекта с помощью скана репозитория и релевантных документов
— Собственная система агентов для кодинга
Сейчас это напоминает OpenAI Codex. Нахожусь в фазе активной разработки, делаю приложение с помощью него самого 🙂
Guro Bokum
Всем привет! меня зовут Гуро, я разработчик, работал в разработке и инфраструктуре в разных областях и языках (15+ лет)
сейчас хайпят агенты, и я последний год ими заниваюсь
за время работы над ними у меня накопились решения, которые я решил завернуть во фрейморк - Liman AI
это YAML декларативный фреймворк с костомным CE DSL, что-то близкое к кубернетес манифестам, где ты описываешь граф в виде нод, а они потом обходятся в зависимости от условий executor’ом
Вчера написал блог пост - как можно из коробки обернуть ваше апи в агента с помощью лимана (парсится делкрация OpenAPI и создаются нужные тулы)
https://www.liman-ai.dev/blog/2025-08-17_simple_openapi
Ах да, Если будешь, пожалуйста: Отметься⚠️ в голосовалке!
Приходите, у нас как заведено - приветствуется проактивность и готовность делиться с другими практическим опытом
#meeting@llm_neighbors
Call link 1 min before event
🗣Pitch and workshop
по традиции в Сб 23 августа 18:00 (UTC+3) (отметься чтобы записаться на звонок )
✍️Agenda:
- 18:00-18:30 ~ 30 min - small talk, think big =)
- ~18:30 - 21:00 Guro Bokum - Liman AI Agentics
(30 min
coffee break☕️ && || сократовские беседы)- ~ 21:30-до ночи до упора) - Глеб Кудрявцев - Shotgun
Кудрявцев Глеб
CEO Карьерный Цех, microboard.io, ex CPO Skyeng.
Разработчик. Эксперт в AI-assisted разработке. Автор популярного приложения для программирования с ИИ — Shotgun (1500 звезд на гитхабе).
Область интереса — программирование агентов, промпт-инженерия и подготовка контекстов (в т.ч. RAG, Knowledge graph и т.д.), b2b/b2c продукты на основе AI.
После успеха Шотгана, решил расширить его возможности и сейчас делаю "взрослый" suite для агентского кодинга:
— Автоматизированное составление онтологии проекта с помощью скана репозитория и релевантных документов
— Собственная система агентов для кодинга
Сейчас это напоминает OpenAI Codex. Нахожусь в фазе активной разработки, делаю приложение с помощью него самого 🙂
Хочу поделиться опытом построения системы для кодинга, ключевыми проблемами и своим подходам к решениюGuro Bokum
Всем привет! меня зовут Гуро, я разработчик, работал в разработке и инфраструктуре в разных областях и языках (15+ лет)
сейчас хайпят агенты, и я последний год ими заниваюсь
за время работы над ними у меня накопились решения, которые я решил завернуть во фрейморк - Liman AI
это YAML декларативный фреймворк с костомным CE DSL, что-то близкое к кубернетес манифестам, где ты описываешь граф в виде нод, а они потом обходятся в зависимости от условий executor’ом
Вчера написал блог пост - как можно из коробки обернуть ваше апи в агента с помощью лимана (парсится делкрация OpenAPI и создаются нужные тулы)
https://www.liman-ai.dev/blog/2025-08-17_simple_openapi
Я хочу рассказать в субботу про фреймворк на реальном примере, и вот думаю про MCP сервер под claude code. Что думаете? Какой бы сервер мы могли сделать, чтобы поиграться на звонке? Делитесь идеями!Ах да, Если будешь, пожалуйста: Отметься⚠️ в голосовалке!
Приходите, у нас как заведено - приветствуется проактивность и готовность делиться с другими практическим опытом
#meeting@llm_neighbors
Call link 1 min before event
Liman AI
Auto-generate AI agent from OpenAPI specs
A look at how Liman automatically generates AI agent from existing API specifications, with a practical example.
👍3
📝 Список задач Claude Code - схема "ТРИ ВОЛШЕБНЫХ ПУНКТА"
1/2
Поделюсь приёмами, которые использую при сеансах "вайбкодинга".
Когда "все по науке", тогда после процесса проектирования агент часами работает над планами реализации и тестовыми стратегиями. Тогда вся его работа происходит по длинным воркфлоу, много этапов и все такое.
Но сегодня мы не про AI-SWE, а про "вульгарный" вайбкодинг)) Это - о кейсе, когда мы условно в "свободном" режиме допиливаем чего то с СС.
Для таких кейсов я действую следующим образом: обычно в режиме plan mode (переключается Shift+Tab) обсуждаю с агентом план действий.
У моего плана действий для вайбкодинг сессии есть ТРИ обязательных пункта: два в начале, один в конце.
1️⃣ Сначала я прошу сделать ЧЕК-ЛИСТ по выполнению текущего плана в корне проекта со всеми ключевыми деталями для кода и документации.
2️⃣ Следом я прошу через субагента внести изменения в документацию, обновить мемори банк: проанализировать текущие duo файлы по индексу, найти какие файлы нужно обновить/актуализировать, какиу удалить, какие дополнить. То есть для того плана, который я собираюсь реализовать, первым пунктом делается документация - docs first.
▶️ Далее идёт сам план, который мы разработали с агентом.
3️⃣ Последним пунктом плана я прошу взять чек-лист из файла, и запустить субагента на сверку фактических файлов кода и документации с чек-листом, проверить как все реализовано, и исправить недостатки.
Наверное, делать typecheck / linit / build - об этом не говорим, это общая гигиена при создании кода.
Тестовая стратегия - использовать минималистичный набор тестов только для core functionality.
❓ Зачем такие сложности?
Агент при длительном выполнении в основном потоке (тот самый вайбкодинг) может слегка забывать план, отклоняться в стороны, не сделать чего то, или "лениться". Чек-лист первым пунктом, когда план "свеж в памяти" агента - он помогает зафиксировать важные детали плана, чтобы потом быть "стержнем" при выполнении задуманного.
❓ Почему обновление мемори банка вторым пунктом? А не последним? логично было бы сначала сделать код, а потом все документировать!
Нет, не логично. И примерной по той же причине, что и чек-лист на первом пункте - агент пока ещё хорошо помнит план и его детали. В конце выполнения в контексте агента будет много всего, и документировать в таком "смурном" состоянии - затея не очень хорошая.
Если чек-лист важен чтобы агент ВЫПОЛНИЛ план с полными деталями, то документация на втором пункте важна чтобы агент ЗАДОКУМЕННТОВАЛ чего мы тут навайбкодили "на память" для последующего использования - что не менее важно. Вам ещё с этим кодом жить!
❓ Если в процессе постоянно говорить "сверяйся с чек-листом" - это поможет?
Конечно, поможет, - я так и делаю, особенно если агент остановился "передохнуть" после значительных этапов. Но можно и в процессе работы "напоминать", особенно если дело дошло до компакта.
❓ А зачем тогда финальный чекап по чек-листу?
Как ни странно, агент регулярно упускает какие-то детали. Если его "стегали" по ходу дела возвращаться к чек-листу, то такого будет меньше - но полностью исключить не выходит.
Поэтому проверка в конце очень важна, она позволяет доработать все, и код и документацию - как предполагалось первоначально.
❓ У агента же есть свой список задач! Зачем ему чек-лист?
Верно, но я "синхронизирую" список задач: когда нужно выполнить план, я прошу взять план и выполнить, и сохранить план себе в TodoWrite (это инструмент записи в список задач агента) - тогда агент часто берет прям структуру моего плана и буквально переносит его в свойс список задач.
Вот тут твиттерские нарыли, что агент постоянно возвращается к своему плану работы, буквально постоянно. Это говорит о пользе "синхронизации" нашего плана с планом агента:
https://x.com/vitransformer/status/1958135188749509016
Ну и напоминалки агенту никогда не помешают, поэтому напоминаем про чек-лист почаще!
(... продолжение: https://t.me/deksden_notes/65)
1/2
Поделюсь приёмами, которые использую при сеансах "вайбкодинга".
Когда "все по науке", тогда после процесса проектирования агент часами работает над планами реализации и тестовыми стратегиями. Тогда вся его работа происходит по длинным воркфлоу, много этапов и все такое.
Но сегодня мы не про AI-SWE, а про "вульгарный" вайбкодинг)) Это - о кейсе, когда мы условно в "свободном" режиме допиливаем чего то с СС.
Для таких кейсов я действую следующим образом: обычно в режиме plan mode (переключается Shift+Tab) обсуждаю с агентом план действий.
У моего плана действий для вайбкодинг сессии есть ТРИ обязательных пункта: два в начале, один в конце.
1️⃣ Сначала я прошу сделать ЧЕК-ЛИСТ по выполнению текущего плана в корне проекта со всеми ключевыми деталями для кода и документации.
2️⃣ Следом я прошу через субагента внести изменения в документацию, обновить мемори банк: проанализировать текущие duo файлы по индексу, найти какие файлы нужно обновить/актуализировать, какиу удалить, какие дополнить. То есть для того плана, который я собираюсь реализовать, первым пунктом делается документация - docs first.
▶️ Далее идёт сам план, который мы разработали с агентом.
3️⃣ Последним пунктом плана я прошу взять чек-лист из файла, и запустить субагента на сверку фактических файлов кода и документации с чек-листом, проверить как все реализовано, и исправить недостатки.
Наверное, делать typecheck / linit / build - об этом не говорим, это общая гигиена при создании кода.
Тестовая стратегия - использовать минималистичный набор тестов только для core functionality.
❓ Зачем такие сложности?
Агент при длительном выполнении в основном потоке (тот самый вайбкодинг) может слегка забывать план, отклоняться в стороны, не сделать чего то, или "лениться". Чек-лист первым пунктом, когда план "свеж в памяти" агента - он помогает зафиксировать важные детали плана, чтобы потом быть "стержнем" при выполнении задуманного.
❓ Почему обновление мемори банка вторым пунктом? А не последним? логично было бы сначала сделать код, а потом все документировать!
Нет, не логично. И примерной по той же причине, что и чек-лист на первом пункте - агент пока ещё хорошо помнит план и его детали. В конце выполнения в контексте агента будет много всего, и документировать в таком "смурном" состоянии - затея не очень хорошая.
Если чек-лист важен чтобы агент ВЫПОЛНИЛ план с полными деталями, то документация на втором пункте важна чтобы агент ЗАДОКУМЕННТОВАЛ чего мы тут навайбкодили "на память" для последующего использования - что не менее важно. Вам ещё с этим кодом жить!
❓ Если в процессе постоянно говорить "сверяйся с чек-листом" - это поможет?
Конечно, поможет, - я так и делаю, особенно если агент остановился "передохнуть" после значительных этапов. Но можно и в процессе работы "напоминать", особенно если дело дошло до компакта.
❓ А зачем тогда финальный чекап по чек-листу?
Как ни странно, агент регулярно упускает какие-то детали. Если его "стегали" по ходу дела возвращаться к чек-листу, то такого будет меньше - но полностью исключить не выходит.
Поэтому проверка в конце очень важна, она позволяет доработать все, и код и документацию - как предполагалось первоначально.
❓ У агента же есть свой список задач! Зачем ему чек-лист?
Верно, но я "синхронизирую" список задач: когда нужно выполнить план, я прошу взять план и выполнить, и сохранить план себе в TodoWrite (это инструмент записи в список задач агента) - тогда агент часто берет прям структуру моего плана и буквально переносит его в свойс список задач.
Вот тут твиттерские нарыли, что агент постоянно возвращается к своему плану работы, буквально постоянно. Это говорит о пользе "синхронизации" нашего плана с планом агента:
https://x.com/vitransformer/status/1958135188749509016
Ну и напоминалки агенту никогда не помешают, поэтому напоминаем про чек-лист почаще!
(... продолжение: https://t.me/deksden_notes/65)
X (formerly Twitter)
Vision Transformers (@vitransformer) on X
New blog post by @AmanGokrani:
Everyone says Claude Code "just works" like magic.
He proxied its API calls to see what's happening.
The secret? It's riddled with <system-reminder> tags that never let it forget what it's doing.
(1/6)
[🔗 link in final post…
Everyone says Claude Code "just works" like magic.
He proxied its API calls to see what's happening.
The secret? It's riddled with <system-reminder> tags that never let it forget what it's doing.
(1/6)
[🔗 link in final post…
🔥5👍4
📝 Список задач Claude Code - схема "ТРИ ВОЛШЕБНЫХ ПУНКТА"
2/2
(начало тут - https://t.me/deksden_notes/64)
❓ А как же планирование с гемини?
Оно все ещё работает лучше, чем планировать с агентом - потому что с большим контекстом гемини все работает "сразу" и модель все видит, а агентом планировать - это надо проследить, чтобы контекст нужный "втянулся": при некотором опыте это несложно, но хлопот всяко больше.
Поэтому я люблю планировать с Гемини в АИ-Студии пока размер проекта позволяет, и вам советую! Схема действий аналогичная: просим гемини добавить эти же ТРИ ВОЛШЕБНЫХ пункта.
Дальше очищаем контекст, праймим задачу от Гемини через меморибанк "/mb {сюда_вставляем_задачу}". Тогда агент подхватит контекст мемори банка по индексным файлам, и приступит к задаче уже немного соображающий в теме.
❓ А как же агенты?
Построить такой сеанс на агентах сильно повысит консистентность выполнения плана на верхнем уровне, но требует очень внимательного прописывания задач на каждом этапе работы. Не всегда это возможно прописать без полноценных спеков и многоэтапно разрабатываемого плана реализации.
Поэтому такой флоу - это более примитивный вайбкодерских "подход", который да, грешен - встречается на практике.
❓ А почёму не использовать AI-SWE? Чтобы все правильно: сначала спеки, потом план реализации, потом кодинг и верификация.
Это, конечно, более правильный подход, на который я перевожу все свои проекты, но переход ещё не завершён. "Компиляция" проекта из спеков - более грамотная и продвинутая технология, которую я всячески развиваю. Но потребность в сеансах работы с агентом в неполностью готовых под AI-SWE проектах все ещё есть - поэтому и такие сеансы я стараюсь делать "по методике".
␄
#post
@deksden_notes
2/2
(начало тут - https://t.me/deksden_notes/64)
❓ А как же планирование с гемини?
Оно все ещё работает лучше, чем планировать с агентом - потому что с большим контекстом гемини все работает "сразу" и модель все видит, а агентом планировать - это надо проследить, чтобы контекст нужный "втянулся": при некотором опыте это несложно, но хлопот всяко больше.
Поэтому я люблю планировать с Гемини в АИ-Студии пока размер проекта позволяет, и вам советую! Схема действий аналогичная: просим гемини добавить эти же ТРИ ВОЛШЕБНЫХ пункта.
Дальше очищаем контекст, праймим задачу от Гемини через меморибанк "/mb {сюда_вставляем_задачу}". Тогда агент подхватит контекст мемори банка по индексным файлам, и приступит к задаче уже немного соображающий в теме.
❓ А как же агенты?
Построить такой сеанс на агентах сильно повысит консистентность выполнения плана на верхнем уровне, но требует очень внимательного прописывания задач на каждом этапе работы. Не всегда это возможно прописать без полноценных спеков и многоэтапно разрабатываемого плана реализации.
Поэтому такой флоу - это более примитивный вайбкодерских "подход", который да, грешен - встречается на практике.
❓ А почёму не использовать AI-SWE? Чтобы все правильно: сначала спеки, потом план реализации, потом кодинг и верификация.
Это, конечно, более правильный подход, на который я перевожу все свои проекты, но переход ещё не завершён. "Компиляция" проекта из спеков - более грамотная и продвинутая технология, которую я всячески развиваю. Но потребность в сеансах работы с агентом в неполностью готовых под AI-SWE проектах все ещё есть - поэтому и такие сеансы я стараюсь делать "по методике".
␄
#post
@deksden_notes
X (formerly Twitter)
Vision Transformers (@vitransformer) on X
New blog post by @AmanGokrani:
Everyone says Claude Code "just works" like magic.
He proxied its API calls to see what's happening.
The secret? It's riddled with <system-reminder> tags that never let it forget what it's doing.
(1/6)
[🔗 link in final post…
Everyone says Claude Code "just works" like magic.
He proxied its API calls to see what's happening.
The secret? It's riddled with <system-reminder> tags that never let it forget what it's doing.
(1/6)
[🔗 link in final post…
🔥6👍5
🧩 Memory bank для существующих проектов :: Реверс-проектирование и реверс-документирование в brownfield
1/2
Польза меморибанка могут ощутить все, кто на практике работал с ИИ ассистентом в проекте, где такой подход применялся. Обычно это делают с самого начала, и меморибанк растёт, пополняется и эволюционирует вместе с проектом.
Но что делать, если хочется использовать меморибанк с существующим проектом, для которого нет меморибанка? Это - территория brownfield, и она значительно сложнее greenfiled.
Ситуация внедрения меморибанка в существующий проект требует творческого подхода. О чем необходимо подумать при старте такого начинания:
- размер проекта: чем крупнее проект, тем сложнее задача создания меморибанка, который является "памятью" проекта: очевидно что для крупных проектов там должно быть очень много информации; документирование отдельных крупных систем порой может потребовать сопоставимых с разработкой с нуля количество усилий;
- наличие существующей документации: если она есть, структурировать её для ИИ агентов будет технической задачей; хуже когда документации нет, или она не точная, причём, согласно исследованиям, неточная документация вреднее её отсутсвия;
- документирование кода: jsdoc/docstrings в проекте уже составляют неплохую базу для ИИ агента;
- степень понимания проекта участниками: иногда есть реально работающие системы, которые НИКТО из сотрудников/подрядчиков не понимает полностью, потому что они долго эволюционно развивались, пережили ротации разработчиков, эволюцию бизнеса, меняющиеся требования, интеграцию с внешними системами - и все это в реальной жизни, без особой документации (которой иногда и не делали), со схемой работы в головах сотрудников (которые потом увольнялись без полной качественной передачи знаний). Такое и приводит к ситуации: система работает, но ПОЧЕМУ ИМЕННО ТАК - не известно достоверно никому;
Процесс создания меморибанка в любом случае будет связан с реверс-проектированием всей системы, а это значит вам необходимо будет получить достаточное понимание кк система работает.
Совсем готовых рецептов нет, но я поделюсь практическими подходами, которые использовал сам в ряде проектов.
▶️ Базовый принцип: мы "строим" в меморибанке усровень абстракции "выше" кода, потому что именно этих уровней не хватает агентам для эффективной работы
▶️ Что за уровни? Тут на помощь приходят классические архитектурные паттерны (да, теперь мы говорим о ренессансе традиционного SWE, прости, agile!) - например, простым и практически удобным для применения будет паттерн C4, подробнее - https://t.me/deksden_notes/55
▶️ Верхний уровень L1 документировать просто - описываем что у нас за система, кто и зачем ей пользуется; концептуальная информация скорее, пректически - задаёт домент рассуждениям агентов;
▶️ L2 уровень очень важен: тут мы описываем крупные блоки вашей системы - назовём их подсистемами: databse, ui, api server, processing engine, - все что имеем; важно правильно выбрать "нарезку", чтобы это имело практический смысл. Например, если у вас огромный Api сервер, имеет смысл выделять в нем свои структурные блоки вроде аутентификации/авторизации, CRUD по модулям. "Крупность" нарезки блоков определяется так: фиче приложения желательно взаимодействовать с одним блоком - то есть, если "пользователь вносит заказ", то он взаимодействует с одним блоком базы данных. Так мы сможем в контекст агента положить всего один документ про подсистему БД "Заказы".
▶️ L3 Уровень - это фичи приложения, это "элементарные" блоки функциональности вашей системы. Делятся аналогично, по автономии: например, вы можете реализовать фичу "пользователь создаёт заказ в системе" отдельно от "пользователь редактирует заказ в системе". Самый многочисленный уровень для документирования. Про его сбор чуть далее.
▶️ L4: у вас уже есть, мы как раз строили мостик между L1 -> L4.
(... продолжение тут: https://t.me/deksden_notes/67)
#post
@deksden_notes
1/2
Польза меморибанка могут ощутить все, кто на практике работал с ИИ ассистентом в проекте, где такой подход применялся. Обычно это делают с самого начала, и меморибанк растёт, пополняется и эволюционирует вместе с проектом.
Но что делать, если хочется использовать меморибанк с существующим проектом, для которого нет меморибанка? Это - территория brownfield, и она значительно сложнее greenfiled.
Ситуация внедрения меморибанка в существующий проект требует творческого подхода. О чем необходимо подумать при старте такого начинания:
- размер проекта: чем крупнее проект, тем сложнее задача создания меморибанка, который является "памятью" проекта: очевидно что для крупных проектов там должно быть очень много информации; документирование отдельных крупных систем порой может потребовать сопоставимых с разработкой с нуля количество усилий;
- наличие существующей документации: если она есть, структурировать её для ИИ агентов будет технической задачей; хуже когда документации нет, или она не точная, причём, согласно исследованиям, неточная документация вреднее её отсутсвия;
- документирование кода: jsdoc/docstrings в проекте уже составляют неплохую базу для ИИ агента;
- степень понимания проекта участниками: иногда есть реально работающие системы, которые НИКТО из сотрудников/подрядчиков не понимает полностью, потому что они долго эволюционно развивались, пережили ротации разработчиков, эволюцию бизнеса, меняющиеся требования, интеграцию с внешними системами - и все это в реальной жизни, без особой документации (которой иногда и не делали), со схемой работы в головах сотрудников (которые потом увольнялись без полной качественной передачи знаний). Такое и приводит к ситуации: система работает, но ПОЧЕМУ ИМЕННО ТАК - не известно достоверно никому;
Процесс создания меморибанка в любом случае будет связан с реверс-проектированием всей системы, а это значит вам необходимо будет получить достаточное понимание кк система работает.
Совсем готовых рецептов нет, но я поделюсь практическими подходами, которые использовал сам в ряде проектов.
▶️ Базовый принцип: мы "строим" в меморибанке усровень абстракции "выше" кода, потому что именно этих уровней не хватает агентам для эффективной работы
▶️ Что за уровни? Тут на помощь приходят классические архитектурные паттерны (да, теперь мы говорим о ренессансе традиционного SWE, прости, agile!) - например, простым и практически удобным для применения будет паттерн C4, подробнее - https://t.me/deksden_notes/55
▶️ Верхний уровень L1 документировать просто - описываем что у нас за система, кто и зачем ей пользуется; концептуальная информация скорее, пректически - задаёт домент рассуждениям агентов;
▶️ L2 уровень очень важен: тут мы описываем крупные блоки вашей системы - назовём их подсистемами: databse, ui, api server, processing engine, - все что имеем; важно правильно выбрать "нарезку", чтобы это имело практический смысл. Например, если у вас огромный Api сервер, имеет смысл выделять в нем свои структурные блоки вроде аутентификации/авторизации, CRUD по модулям. "Крупность" нарезки блоков определяется так: фиче приложения желательно взаимодействовать с одним блоком - то есть, если "пользователь вносит заказ", то он взаимодействует с одним блоком базы данных. Так мы сможем в контекст агента положить всего один документ про подсистему БД "Заказы".
▶️ L3 Уровень - это фичи приложения, это "элементарные" блоки функциональности вашей системы. Делятся аналогично, по автономии: например, вы можете реализовать фичу "пользователь создаёт заказ в системе" отдельно от "пользователь редактирует заказ в системе". Самый многочисленный уровень для документирования. Про его сбор чуть далее.
▶️ L4: у вас уже есть, мы как раз строили мостик между L1 -> L4.
(... продолжение тут: https://t.me/deksden_notes/67)
#post
@deksden_notes
Telegram
DEKSDEN notes
🧩 Модель С4
Начнём, пожалуй, потихоньку к архитектурным вопросам накидывать!
Сначала поговорим про модель С4: на мой взгляд эта модель довольно удачно позволяет декомпозировать архитектуру программного продукта и концептуально удачно подходит для работы…
Начнём, пожалуй, потихоньку к архитектурным вопросам накидывать!
Сначала поговорим про модель С4: на мой взгляд эта модель довольно удачно позволяет декомпозировать архитектуру программного продукта и концептуально удачно подходит для работы…
🔥5👍4
🧩 Memory bank для существующих проектов :: Реверс-проектирование и реверс-документирование в brownfield
2/2
(.. начало тут: https://t.me/deksden_notes/66)
Немного практики:
🔵 Нет смысла документировать очевидные из кода вещи: агент может прочитать и воспринять что написано в коде. Делать дублирование логики функций в документации особенной ценности не имеет и будет забивать контекст - агент будет читать и документацию, и код.
🔵 полезно вносить в мемори банк то, для сбора чего агенту нужно совершить несколько действий. Например: схему взаимодействия между модулями (кто кого и откуда вызывает), контракты подсистем, публичное api модулей, примеры и паттерны их использования
🔵 Отличную почву для дополнения меморибанков дают ошибки агента - когда он сделал что-то "не то". Это верный знак необходимости рефакторинга документации: отсутствие правильного контекста, или его качеством. Проверим что у агента документация была: индексные файлы, duo файлы. Проверяем - опирался ли агент на корректную документацию? противоречий или ошибок в документации не было? важные вещи документированы?
🔵 Используем агентов:
- собраем полную карту апи-роутов сервера;
- исследовать и документировать схему из БД и связанных файлов кода, "вытаскиваем" максимум мета-информации;
- описать существующий UI: перечень экранов, их структурных элементов; data test id атрибуты для тестирования; идентифицировать основные actions в интерфейсе;
- call graph: агент может составить схему взаимодействия модулей - какие функции/методы вызывают другие модули/функции; конечно, специализированные системы (типа qoder) сделают это лучше, но и простыми способами зафиксировать "соседние ветки" дерева зависимостей несложно и весьма полезно.
🔵 Самое сложное - это вытащить нормальную структуру фич из кода. Тут может помочь фиксация типовых сценариев использования системы - как пользователи с ней работают. Элементы системы, которые участвуют в сценарии и могут стать отправными точками для фич. Пример: "Пользователь входит в систему: на экране логина он вводит имя пользователя и пароль. Система валидирует пароль и загружает главный экран с доступными пользвоателю разделами." (фича аутентификации, фича авторизации).
🔵 Используйте методологии CRUD анализа: еси в системе зафиксирована работа с некоей сущностью "заказ" - типа, "пользователь создал заказ", то для сущности "заказ" должны быть описаны все CRUD методы: как создавать, просматривать, менять и удалять такие сущности (бывает, что удаление часто выпадает при документирвовании).
🔵 Используйте методики Use Case Analysis: сценарии часто описывают только "happy path". Но что будет если пользователь ввёл неправильный пароль? 10 раз подряд? если при регистрации пользователь с таким паролем уже существует? Если api станет недоступно посередине регистрации? Такие сценарии называются "exception flows" и "alternative paths".
🔵 Анализ Перехода Состояний (State Transition Analysis) : если в системе есть сущности с состоянием, надо разобраться со схемой переходов состояний. Составляем агентами список состояний и карту возможных переходов между ними, и смотрим - документировали ли мы все, что касается доступных переходов. Как именно заказ из состояния on-hold переводится обратно в processing. Документировали ли мы как заказ из "paid" становится "shipped"? Такая карта здорово помогает найти пробелы в документировании.
🔵 В целом - практики "классического" "enterprise" моделирования процессов, проектирования, бизнес-инжиниринга будут работать на пользу процессу и тут - ведь мы решаем похожие задачи: если раньше эти практики использовались чтобы люди понимали как работает система в бизнесе, то теперь у нас даже более практичное применения - мы должны растолковать все то же самое ИИ агентам!
Надеюсь, дал какие то намётки подхода! И помните - задача творческая, жёстких методик пока не сформировано, все познается на практике.
🙇♂️ Пробуем, анализируем, делимся, улучшаем!
␄
#post
@deksden_notes
2/2
(.. начало тут: https://t.me/deksden_notes/66)
Немного практики:
🔵 Нет смысла документировать очевидные из кода вещи: агент может прочитать и воспринять что написано в коде. Делать дублирование логики функций в документации особенной ценности не имеет и будет забивать контекст - агент будет читать и документацию, и код.
🔵 полезно вносить в мемори банк то, для сбора чего агенту нужно совершить несколько действий. Например: схему взаимодействия между модулями (кто кого и откуда вызывает), контракты подсистем, публичное api модулей, примеры и паттерны их использования
🔵 Отличную почву для дополнения меморибанков дают ошибки агента - когда он сделал что-то "не то". Это верный знак необходимости рефакторинга документации: отсутствие правильного контекста, или его качеством. Проверим что у агента документация была: индексные файлы, duo файлы. Проверяем - опирался ли агент на корректную документацию? противоречий или ошибок в документации не было? важные вещи документированы?
🔵 Используем агентов:
- собраем полную карту апи-роутов сервера;
- исследовать и документировать схему из БД и связанных файлов кода, "вытаскиваем" максимум мета-информации;
- описать существующий UI: перечень экранов, их структурных элементов; data test id атрибуты для тестирования; идентифицировать основные actions в интерфейсе;
- call graph: агент может составить схему взаимодействия модулей - какие функции/методы вызывают другие модули/функции; конечно, специализированные системы (типа qoder) сделают это лучше, но и простыми способами зафиксировать "соседние ветки" дерева зависимостей несложно и весьма полезно.
🔵 Самое сложное - это вытащить нормальную структуру фич из кода. Тут может помочь фиксация типовых сценариев использования системы - как пользователи с ней работают. Элементы системы, которые участвуют в сценарии и могут стать отправными точками для фич. Пример: "Пользователь входит в систему: на экране логина он вводит имя пользователя и пароль. Система валидирует пароль и загружает главный экран с доступными пользвоателю разделами." (фича аутентификации, фича авторизации).
🔵 Используйте методологии CRUD анализа: еси в системе зафиксирована работа с некоей сущностью "заказ" - типа, "пользователь создал заказ", то для сущности "заказ" должны быть описаны все CRUD методы: как создавать, просматривать, менять и удалять такие сущности (бывает, что удаление часто выпадает при документирвовании).
🔵 Используйте методики Use Case Analysis: сценарии часто описывают только "happy path". Но что будет если пользователь ввёл неправильный пароль? 10 раз подряд? если при регистрации пользователь с таким паролем уже существует? Если api станет недоступно посередине регистрации? Такие сценарии называются "exception flows" и "alternative paths".
🔵 Анализ Перехода Состояний (State Transition Analysis) : если в системе есть сущности с состоянием, надо разобраться со схемой переходов состояний. Составляем агентами список состояний и карту возможных переходов между ними, и смотрим - документировали ли мы все, что касается доступных переходов. Как именно заказ из состояния on-hold переводится обратно в processing. Документировали ли мы как заказ из "paid" становится "shipped"? Такая карта здорово помогает найти пробелы в документировании.
🔵 В целом - практики "классического" "enterprise" моделирования процессов, проектирования, бизнес-инжиниринга будут работать на пользу процессу и тут - ведь мы решаем похожие задачи: если раньше эти практики использовались чтобы люди понимали как работает система в бизнесе, то теперь у нас даже более практичное применения - мы должны растолковать все то же самое ИИ агентам!
Надеюсь, дал какие то намётки подхода! И помните - задача творческая, жёстких методик пока не сформировано, все познается на практике.
🙇♂️ Пробуем, анализируем, делимся, улучшаем!
␄
#post
@deksden_notes
Telegram
DEKSDEN notes
🧩 Memory bank для существующих проектов :: Реверс-проектирование и реверс-документирование в brownfield
1/2
Польза меморибанка могут ощутить все, кто на практике работал с ИИ ассистентом в проекте, где такой подход применялся. Обычно это делают с самого…
1/2
Польза меморибанка могут ощутить все, кто на практике работал с ИИ ассистентом в проекте, где такой подход применялся. Обычно это делают с самого…
🔥7👍6
🖼️ Claude Code: Paste Images
Неужели починили старый баг?
Version 1.0.93:
• Windows: Add alt + v shortcut for pasting images from clipboard
ℹ️ Ну и кто не в курсе, в CC, да прям в терминал, "всегда" (когда это работало) можно было вставлять картинки (скриншоты например). Только на маке это работало через Control+V (а не привчынй Command+V), а на windows нынче сделали alt+V (тоже нестандартный). Ну - хоть так!
Кстати, drag and drop картинок работал давно и понадёжнее.
#news
@deksden_notes
Неужели починили старый баг?
Version 1.0.93:
• Windows: Add alt + v shortcut for pasting images from clipboard
ℹ️ Ну и кто не в курсе, в CC, да прям в терминал, "всегда" (когда это работало) можно было вставлять картинки (скриншоты например). Только на маке это работало через Control+V (а не привчынй Command+V), а на windows нынче сделали alt+V (тоже нестандартный). Ну - хоть так!
Кстати, drag and drop картинок работал давно и понадёжнее.
#news
@deksden_notes
👍4🔥2👌2
ℹ️ Claude Code: подумать глубже
☝️ Тоже могут не все знать: в CC есть возможность для Соннета / Опуса включать режим thinking - для этого пишем "think hard" / "ultrathink".
▶️ У меня почему то не в каждом промпте это срабатывает, поэтому я останавливаю CC через нажатие Esc, и пишу отдельно в интерактивном режиме: think hard. После этого можно будет увидеть немного другим оформлением "мысли" модели. Соответственно, - например, поиск бага получает инъекцию сообразительности!
"Хозяйке на заметку" (ц)
#post
@deksden_notes
☝️ Тоже могут не все знать: в CC есть возможность для Соннета / Опуса включать режим thinking - для этого пишем "think hard" / "ultrathink".
▶️ У меня почему то не в каждом промпте это срабатывает, поэтому я останавливаю CC через нажатие Esc, и пишу отдельно в интерактивном режиме: think hard. После этого можно будет увидеть немного другим оформлением "мысли" модели. Соответственно, - например, поиск бага получает инъекцию сообразительности!
"Хозяйке на заметку" (ц)
#post
@deksden_notes
🔥9
🔃 Claude Code: очередное обновление 1.0.94
На самом деле уже 1.0.95, но про .95 ничего не рассказали, а вот что у нас в 1.0.94:
• Vertex: add support for global endpoints for supported models
• /memory command now allows direct editing of all imported memory files
• SDK: Add custom tools as callbacks
• Added /todos command to list current todo items
Помимо того что можно быстро и удобно открыть CLAUDE.md уровня проекта/системы (/memory командой), появилась возможность посмотреть текущий список задач через /todos, что удобно - теперь не надо скроллить чат в поисках где там СС последний раз его трогала.
А вот что такое "Add custom tools as callbacks" - это надо разбираться, интересно. Пока из документации особо не понятно, будем искать)
https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
#news
@deksden_notes
На самом деле уже 1.0.95, но про .95 ничего не рассказали, а вот что у нас в 1.0.94:
• Vertex: add support for global endpoints for supported models
• /memory command now allows direct editing of all imported memory files
• SDK: Add custom tools as callbacks
• Added /todos command to list current todo items
Помимо того что можно быстро и удобно открыть CLAUDE.md уровня проекта/системы (/memory командой), появилась возможность посмотреть текущий список задач через /todos, что удобно - теперь не надо скроллить чат в поисках где там СС последний раз его трогала.
А вот что такое "Add custom tools as callbacks" - это надо разбираться, интересно. Пока из документации особо не понятно, будем искать)
https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
#news
@deksden_notes
GitHub
claude-code/CHANGELOG.md at main · anthropics/claude-code
Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflo...
👍5🔥3🕊1
🔃 Claude Code: очередное обновление 1.0.97
Version 1.0.97:
• Settings: /doctor now validates permission rule syntax and suggests corrections
⚠️ Да, уже .0.98, но в 97 включили поддержку линтинга правил в настройках - и если у вас перестал работать ccstatusline, время проверить что за ошибки в settings. Если выявлены ошибки - то возможны всякие "спецэффекты" в виде отключения части прописанных в настройках штук, имейте ввиду!
#post
@deksden_notes
Version 1.0.97:
• Settings: /doctor now validates permission rule syntax and suggests corrections
⚠️ Да, уже .0.98, но в 97 включили поддержку линтинга правил в настройках - и если у вас перестал работать ccstatusline, время проверить что за ошибки в settings. Если выявлены ошибки - то возможны всякие "спецэффекты" в виде отключения части прописанных в настройках штук, имейте ввиду!
#post
@deksden_notes
🔥5👌2
↔️ XML-like теги
Поговорим немного о конекст - инжиниринге. Хотел напомнить про простую, но крайне эффективную технику, которую можно применять в промптах, меморибанке, агентах.
Это XML-like теги. Рекомендации от "лучших собаководов" прилагаются!
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags
❓ Почему я пришу XML-like, а не XML? Потому что это не "классический" XML со схемой, атрибутами тэгов, нет - без этих усложнений. Усложнения в виде схемы путают модель без очевидной необходимости. Атрибуты - по желанию, если семантика подходит.
▶️ Мы просто используем тэги в угловых скобках для разметки структуры промптов. Какие задачи наиболее эффективно решаются:
- явная разметка начала и конца некоего семантического блока
- явное и однозначное указание вложенности блоков друг в друга
Этого достаточно, чтобы пользоваться этим почти в каждом промпте.
❓Какие теги применять? Конечно, семантические, что даёт дополнительный плюс. Пример:
Думаю, идея понятна. В сложных случаях: <элемент_списка порядковый_номер="1" важность="обычная">
❓ Зачем такие сложности? Чтобы явно показать структуру, когда она не тривиальная. С тривиальной и маркдаун вполне подходит, а вот вложденные многоуровневые списки модель иногда "парсит" с ошибками: проверка может быть очень простая - попросите модель составить структуру вашего промпта с многоуровневыми нумерованными элементами структуры, можно иногда удивится!
❓ А как же маркдаун? Такие теги с ним вполне совместимы. Я пишу обычные md файлы и добавляю xml-like теги в "сложные места", где модель можнт неоднозначно определить логическое начало и конец блоков.
❓Можешь пояснить "за фрактальный промптинг"? Конечно, и, как ни странно - сабж и xml теги вполне себе имеют место быть: для авторегрессионных казуальных моделей (а это почти все современные трансформеры, с треуголными масками внимания на всех этапах обработки, включая prefill) - они "условно" читают текст слева направо, поэтому наличие уникального закрывающего тега для них "удобно".
ℹ️ Удобно в кастомной слеш команде делать так:
❓ Что именно улучшают тэги? Только восприятие моделью
структуры промпта - содержательно тэги сами по себе не будут какой то магической «пилюлей».
#post
@deksden_notes
Поговорим немного о конекст - инжиниринге. Хотел напомнить про простую, но крайне эффективную технику, которую можно применять в промптах, меморибанке, агентах.
Это XML-like теги. Рекомендации от "лучших собаководов" прилагаются!
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags
❓ Почему я пришу XML-like, а не XML? Потому что это не "классический" XML со схемой, атрибутами тэгов, нет - без этих усложнений. Усложнения в виде схемы путают модель без очевидной необходимости. Атрибуты - по желанию, если семантика подходит.
▶️ Мы просто используем тэги в угловых скобках для разметки структуры промптов. Какие задачи наиболее эффективно решаются:
- явная разметка начала и конца некоего семантического блока
- явное и однозначное указание вложенности блоков друг в друга
Этого достаточно, чтобы пользоваться этим почти в каждом промпте.
❓Какие теги применять? Конечно, семантические, что даёт дополнительный плюс. Пример:
<инструкции>
...
<некий_блок>
...
<вложенный_блок>
...
</вложенный_блок>
...
<и_еще_один>
...
</и_еще_один>>
</некий_блок>
...
</инструкции>
Думаю, идея понятна. В сложных случаях: <элемент_списка порядковый_номер="1" важность="обычная">
❓ Зачем такие сложности? Чтобы явно показать структуру, когда она не тривиальная. С тривиальной и маркдаун вполне подходит, а вот вложденные многоуровневые списки модель иногда "парсит" с ошибками: проверка может быть очень простая - попросите модель составить структуру вашего промпта с многоуровневыми нумерованными элементами структуры, можно иногда удивится!
❓ А как же маркдаун? Такие теги с ним вполне совместимы. Я пишу обычные md файлы и добавляю xml-like теги в "сложные места", где модель можнт неоднозначно определить логическое начало и конец блоков.
❓Можешь пояснить "за фрактальный промптинг"? Конечно, и, как ни странно - сабж и xml теги вполне себе имеют место быть: для авторегрессионных казуальных моделей (а это почти все современные трансформеры, с треуголными масками внимания на всех этапах обработки, включая prefill) - они "условно" читают текст слева направо, поэтому наличие уникального закрывающего тега для них "удобно".
ℹ️ Удобно в кастомной слеш команде делать так:
some_command.md:
Вот команда пользователя:
<команда_пользователя>
$ARGUMENTS
</команда_пользователя>
И дополнительно делай так: ...
❓ Что именно улучшают тэги? Только восприятие моделью
структуры промпта - содержательно тэги сами по себе не будут какой то магической «пилюлей».
#post
@deksden_notes
Claude API Docs
Use XML tags to structure your prompts
Claude API Documentation
👍6🔥4❤2
🥳 🎁 🎉 Маленький юбилей Claude Code: круглая версия v1.0.100
Жаль, что без release notes, багфикс релиз или какие то скрытые пока функции.
Радует, что проект довольно динамично развивается, и на данный момент является лидером по возможностям среди агентов.
Пожелаем дальнейших успехов!
#news
@deksden_notes
Жаль, что без release notes, багфикс релиз или какие то скрытые пока функции.
Радует, что проект довольно динамично развивается, и на данный момент является лидером по возможностям среди агентов.
Пожелаем дальнейших успехов!
#news
@deksden_notes
🔥8👍4🥱1
☎ Сегодня я буду на звонке в канале у Алмаза
@aiclubsweggs - ИИчница
поговорим о меморибанках в частности и памяти для агентов в общем! Welcome!
18:30 msk
#news
@deksden_notes
@aiclubsweggs - ИИчница
поговорим о меморибанках в частности и памяти для агентов в общем! Welcome!
18:30 msk
#news
@deksden_notes
4🔥8🤩4👍2💊2
📝 Агентская память - немного теории
Начнем шарить контент с созвона. Поговорим немного о памяти для агентов - чего это такое в целом. Довольно глобальная тема!
▶️ При работе LLM все что есть в распоряжении модели - это контекст. Наверное, можно считать это текущей операционной памятью модели, где содержатся все сведения для выполнения текущей задачи. Создание "правильного" контекста - самое главное дело для обеспечения качественной работы модели и агентской системы. Но вот живёт контекст на время сессии работы с моделью, и он не бесконечен: кончился контекст, надо начинать новую сессию. Но новая сессия - все как в первый раз.
Когда мы помещаем модель в окружение, поддерживающее инструменты (tools, через functional calling), такая система становится агентом и получает возможность выполнения некоторых действий. Например, сохранения и извлечения необходимой информации, что даёт нам возможность создания системы памяти агента.
▶️ Название "память агента" довольно условное, потому что модель также владеет огромным объёмом информации "внутри" своих весов, но это "неизменная" память, она не меняется от задачи к задаче.
Для текущей задачи модель всегда использует свой контекст.
Роль памяти - помогать в формировании контекста. Безусловно, контекст можно сформировать и "руками", для каждой задачи промпты вводить, и все нужные сведения в контекст положить. Но память как раз и помогает избавится от необходимости каждый раз растолковывать агенту все заново - "каждый раз - как в первый раз!". Память позволяет сохранить сведения для бьудущего использования, и извлекать нужную для текущей задачи информацию.
🟢 Осознание роли памяти важно, когда решаешь - чего бы в этой памяти сохранить. Нужно ли агенту сведения об истории изменения файла? Для работы было бы полезно, но зачем они именно в памяти - ведь эти сведения у нас и так сохранены в истории коммитов git репозитория, и модель про это знает. Получается, хранение информации в памяти агента- дублирование, эти сведения несложно будет получить и без запоминания. Единственный момент: если эти сведения сохранены "заодно", например, в jsdoc шапке файла - экономим время/запрос модели с тулюзом.
🟢 Применяем фокусирование: память призвана обеспечить выполнение будущих задач. Например, сведения о легаси коде, который образовался в ходе рефакторинга. В будущих задачах он не участвует, поэтому из памяти все связанное с ним убираем: у нас не летопись, за летописью идём в git, вестимо! У нас своя фокусная задача.
☝️ Итак, важно понимать домен термина "память":
- память - это про контекст инжиниринг
- память = механизм сохранения + загрузки сведений
- фокусная цель: обеспечить выполнение будущих задач
- способ: предоставить необходимые сведения в контекст для выполнения задач моделью
#post
@deksden_notes
Начнем шарить контент с созвона. Поговорим немного о памяти для агентов - чего это такое в целом. Довольно глобальная тема!
▶️ При работе LLM все что есть в распоряжении модели - это контекст. Наверное, можно считать это текущей операционной памятью модели, где содержатся все сведения для выполнения текущей задачи. Создание "правильного" контекста - самое главное дело для обеспечения качественной работы модели и агентской системы. Но вот живёт контекст на время сессии работы с моделью, и он не бесконечен: кончился контекст, надо начинать новую сессию. Но новая сессия - все как в первый раз.
Когда мы помещаем модель в окружение, поддерживающее инструменты (tools, через functional calling), такая система становится агентом и получает возможность выполнения некоторых действий. Например, сохранения и извлечения необходимой информации, что даёт нам возможность создания системы памяти агента.
▶️ Название "память агента" довольно условное, потому что модель также владеет огромным объёмом информации "внутри" своих весов, но это "неизменная" память, она не меняется от задачи к задаче.
Для текущей задачи модель всегда использует свой контекст.
Роль памяти - помогать в формировании контекста. Безусловно, контекст можно сформировать и "руками", для каждой задачи промпты вводить, и все нужные сведения в контекст положить. Но память как раз и помогает избавится от необходимости каждый раз растолковывать агенту все заново - "каждый раз - как в первый раз!". Память позволяет сохранить сведения для бьудущего использования, и извлекать нужную для текущей задачи информацию.
🟢 Осознание роли памяти важно, когда решаешь - чего бы в этой памяти сохранить. Нужно ли агенту сведения об истории изменения файла? Для работы было бы полезно, но зачем они именно в памяти - ведь эти сведения у нас и так сохранены в истории коммитов git репозитория, и модель про это знает. Получается, хранение информации в памяти агента- дублирование, эти сведения несложно будет получить и без запоминания. Единственный момент: если эти сведения сохранены "заодно", например, в jsdoc шапке файла - экономим время/запрос модели с тулюзом.
🟢 Применяем фокусирование: память призвана обеспечить выполнение будущих задач. Например, сведения о легаси коде, который образовался в ходе рефакторинга. В будущих задачах он не участвует, поэтому из памяти все связанное с ним убираем: у нас не летопись, за летописью идём в git, вестимо! У нас своя фокусная задача.
☝️ Итак, важно понимать домен термина "память":
- память - это про контекст инжиниринг
- память = механизм сохранения + загрузки сведений
- фокусная цель: обеспечить выполнение будущих задач
- способ: предоставить необходимые сведения в контекст для выполнения задач моделью
#post
@deksden_notes
👍9🔥5❤2
🔧 Агентская память : реализации
Давайте поговорим как все устроено в этой агентской памяти. Запоминать и извлекать сведения определённо можно совершенно по-разному.
Принципиальные варианты реализации:
- 👈 контекст сохраняет/извлекает система ИИ агента - "обвязка" модели, не сама модель;
- 👉 агент "самостоятельно" рулит сохранением/извлечением информации из памяти
Посмотрим - какие готовые механизмы памяти есть в существующих ИИ системах.
1️⃣ Модули памяти общего профиля для чатов
До всего движения с агентами мы работали с LLM в чатах. Для чатов и были сделаны первые варианты "памяти". Сведения были довольно простые: блокнотик с фактами о пользователе. Механизм сохранения: тулюз инструмента записи в память. Механизм извлечения: помещаем "блокнотик" в системпромпт.
С ростом количества чатов встала необходимость "возвращаться" к обсуждавшимся в прошлых чатах вопросам. Реализацию такой фичи сделали на уже отработанной технологии RAG, всё несложно:
⊖ все чаты чанкаем, чанки контекстно обогащаем, делаем саммари чатов - и генерим эмбеддинги всего этого богатства
⊖ эмбеддинги укладываем в любую базу с векторным поиском расстояний - нынче это может быть даже Postgres/SQLite, но классикой будет Chroma/Qdrant/FAISS и товарищи
⊖ эмбеддингами обрабатываем запрос пользователя
⊖ ищем вектором похожее на эмбеддинг запроса пользователя в векторной базе, а классическим BM25 - по ключевым словам
⊖ итоги реранкаем быстрой моделью и отдаём в контекст модели
⊖ модель формирует ответ пользователю
У chatgpt не все чаты сохранены, а только "полезная" на взгляд какой то модели выжимка - https://help.openai.com/en/articles/8590148-memory-faq
Что то в этом духе работает сейчас у антропиков.
https://support.anthropic.com/en/articles/10185728-understanding-claude-s-personalization-features#h_4afb5dcf4b
Известны сторонние реализации: mem0, zep - они, конечно, предлагают дополнительные фичи.
▶️ zep (https://getzep.com/)
Интересно, что продукт называется Agent Memory (https://www.getzep.com/product/agent-memory/ ), но его фичи ясно указывают что это память скорее для чат бота, причём с поддержкой специфических бизнес-данных.
Штука работает на их же open source проекте Graphiti (https://www.getzep.com/product/open-source/), предлагает RAG на графовой базе (neo4j) + специальную поддержку темпоральных тэгов. То есть поиск учитывает временной аспект, и если пользователь летом любил кроссовки адидас, а осенью полюбил кроссовки puma, то поиск вернёт разные данные в зависимости от указанного временного периода.
Есть возможность подключения сервиса через MCP сервер.
▶️ mem0 (https://mem0.ai/)
Продукт также очень похож на zep, тоже скорее предназначен для чатботов, с сохранением фактов и поиском по перепискам. Тоже есть MCP сервер, всё как полагается (https://mem0.ai/openmemory-mcp).
Фичи для такого класса продуктов стандартные - https://docs.mem0.ai/platform/features/platform-overview
Эмбеддинги, гибридный поиск, реранкинг, фильтры, граф.
#post
@deksden_notes
Давайте поговорим как все устроено в этой агентской памяти. Запоминать и извлекать сведения определённо можно совершенно по-разному.
Принципиальные варианты реализации:
- 👈 контекст сохраняет/извлекает система ИИ агента - "обвязка" модели, не сама модель;
- 👉 агент "самостоятельно" рулит сохранением/извлечением информации из памяти
Посмотрим - какие готовые механизмы памяти есть в существующих ИИ системах.
1️⃣ Модули памяти общего профиля для чатов
До всего движения с агентами мы работали с LLM в чатах. Для чатов и были сделаны первые варианты "памяти". Сведения были довольно простые: блокнотик с фактами о пользователе. Механизм сохранения: тулюз инструмента записи в память. Механизм извлечения: помещаем "блокнотик" в системпромпт.
С ростом количества чатов встала необходимость "возвращаться" к обсуждавшимся в прошлых чатах вопросам. Реализацию такой фичи сделали на уже отработанной технологии RAG, всё несложно:
⊖ все чаты чанкаем, чанки контекстно обогащаем, делаем саммари чатов - и генерим эмбеддинги всего этого богатства
⊖ эмбеддинги укладываем в любую базу с векторным поиском расстояний - нынче это может быть даже Postgres/SQLite, но классикой будет Chroma/Qdrant/FAISS и товарищи
⊖ эмбеддингами обрабатываем запрос пользователя
⊖ ищем вектором похожее на эмбеддинг запроса пользователя в векторной базе, а классическим BM25 - по ключевым словам
⊖ итоги реранкаем быстрой моделью и отдаём в контекст модели
⊖ модель формирует ответ пользователю
У chatgpt не все чаты сохранены, а только "полезная" на взгляд какой то модели выжимка - https://help.openai.com/en/articles/8590148-memory-faq
Что то в этом духе работает сейчас у антропиков.
https://support.anthropic.com/en/articles/10185728-understanding-claude-s-personalization-features#h_4afb5dcf4b
Известны сторонние реализации: mem0, zep - они, конечно, предлагают дополнительные фичи.
▶️ zep (https://getzep.com/)
Интересно, что продукт называется Agent Memory (https://www.getzep.com/product/agent-memory/ ), но его фичи ясно указывают что это память скорее для чат бота, причём с поддержкой специфических бизнес-данных.
Штука работает на их же open source проекте Graphiti (https://www.getzep.com/product/open-source/), предлагает RAG на графовой базе (neo4j) + специальную поддержку темпоральных тэгов. То есть поиск учитывает временной аспект, и если пользователь летом любил кроссовки адидас, а осенью полюбил кроссовки puma, то поиск вернёт разные данные в зависимости от указанного временного периода.
Есть возможность подключения сервиса через MCP сервер.
▶️ mem0 (https://mem0.ai/)
Продукт также очень похож на zep, тоже скорее предназначен для чатботов, с сохранением фактов и поиском по перепискам. Тоже есть MCP сервер, всё как полагается (https://mem0.ai/openmemory-mcp).
Фичи для такого класса продуктов стандартные - https://docs.mem0.ai/platform/features/platform-overview
Эмбеддинги, гибридный поиск, реранкинг, фильтры, граф.
#post
@deksden_notes
OpenAI Help Center
Memory FAQ | OpenAI Help Center
Learn more about managing memory in ChatGPT.
1🔥11❤3👍2
Google Jules: Очередная порция приятных апдейтов
* теперь мы видим работу агента-критика! Довольно важно: сам по себе критик сильно улучшает качество, а теперь ещё его работу можно и посмотреть достаточно удобным способом
* новый UI для просмотра diff -стеки в дополнение к табам
* подсказки для промпта агента на старте - добавляются в чат одним кликом
Развивается довольно бодро! Респект команде
https://jules.google/docs/changelog/
#news
@deksden_notes
* теперь мы видим работу агента-критика! Довольно важно: сам по себе критик сильно улучшает качество, а теперь ещё его работу можно и посмотреть достаточно удобным способом
* новый UI для просмотра diff -стеки в дополнение к табам
* подсказки для промпта агента на старте - добавляются в чат одним кликом
Развивается довольно бодро! Респект команде
https://jules.google/docs/changelog/
#news
@deksden_notes
🔥7👍1
📝 Память AI SWE Tools
Давайте продолжимспамить обзор инструментов «памяти» у различных ИИ инструментов на рынке и рассмотрим э, что нам предлагают ИИ агенты для разработки программного обеспечения.
На самом деле, на рынке уже сложился некоторый подход к управлению памятью: агенты хранят наборы инструкций, которые по разным схемам и правилам применяют во время своей работы путем «подмешивания» в контекст.
Давайте рассмотрим механизмы Cursor, Claude Code, ...
1️⃣ Cursor
Наверное, первым стоит упомянуть один из самых популярных инструментов - Cursor. Система памяти (в Cursor это называется rules) основана на добавлении в контекст файлов из папки .cursor/rules/. Это - единственный инструмент, который «придумал» добавлять целыми папками.
▶️ Схема «скоупов» (на что распространяются правила из папки .cursor/rules) зависит от того, где размещена эта папка. Если в корне проекта - то распространяется на все файлы проекта. Можно разместить папку «выше» по иерархии папок, тогда она будет «действовать» на все проекты, расположенные внутри этой папки. Если разместить в домашней папке пользователя, то правила будут применяться для всех проектов пользователя в этой системе.
Соответственно, правила, размещенные внутри папки «ниже» по иерархии «действуют» по работе с файлами из этих папок и «глубже» по иерархии.
☝️ Таким образом, можно назвать это «иерархическим» скоупом правил, на базе иерархии папок.
Правила у Cursor описываются в файлах mdс (это обычный md + yaml frontmatter). Дополнительно к "иерархическому" скоупу на папках, во frontmatter конкретного файла можно установить индивидуальные правила скоупа:
*
*
*
*
Да, правила поддерживают схему "упоминания" какого то файла через указание его пути в конструкции вида @file_name. В этом случае содержимое файла будет обязательно добавлено в контекст системой, и не потребует использования тулюза через ИИ - что экономично по времени/токенам.
Cursor поддерживает спецификацию AGENTS.ms (https://agents.md/), но с некоторыми ограничениями: скоуп - только проекта, файл должен быть в корне проекта.
ℹ️ Вот ссылка на полную документацию: https://docs.cursor.com/en/context/rules
Также стоит упомянуть довольно интересный отдельный механизм Memories (https://docs.cursor.com/en/context/memories). Это когда ИИ агент извлекает из чата с пользователем правила, и самостоятельно формирует иp них файл правил со скоупом проекта.
2️⃣ Claude Code
Claude Code предоставляет, пожалуй, самые развитые средства работы с памятью. Используется файл с именем (внезапно!) CLAUDE.md, стандарт AGENTS.md не поддерживается.
- файл уровня проекта (стандартно, в корне)
- файлы выше уровня - на любой цепочке иерархии вплоть до папки пользователя "~", где может "жить" файл в "~/.claude/CLAUDE.md"; благодаря этому при старте в проекте монорепо в папке вложенного проекта - подтянется в том числе файл CLAUDE.md для всего проекта
- Organization-level memory management - что то на энтерпрайзном (возможность указывать правила уровня всей организации, управляется devOps компании);
- поддерживаются файлы CLAUDE.md вложенные в текущую папку: они аналогично будут обладать "иерархическим" скоупом, то есть распространяться при работае с файлами из нужной папки
- важно обращать внимание на расширение файла - ".md", если использовать ".MD", то не сработает
- поддерживается императивный @file импорт файлов (экономия тулюза)
- просматривать текущую память можно слеш-коммандой "/memory"
- есть команда чата "# {инструкция}" для быстрого добавления инструкции в текущий CLAUDE.md файл
- нет тонких настроек скоупов: glob - скоупов, по решению агента
Почитать подробнее тут: https://docs.anthropic.com/en/docs/claude-code/memory
#post
@deksden_notes
Давайте продолжим
На самом деле, на рынке уже сложился некоторый подход к управлению памятью: агенты хранят наборы инструкций, которые по разным схемам и правилам применяют во время своей работы путем «подмешивания» в контекст.
Давайте рассмотрим механизмы Cursor, Claude Code, ...
1️⃣ Cursor
Наверное, первым стоит упомянуть один из самых популярных инструментов - Cursor. Система памяти (в Cursor это называется rules) основана на добавлении в контекст файлов из папки .cursor/rules/. Это - единственный инструмент, который «придумал» добавлять целыми папками.
▶️ Схема «скоупов» (на что распространяются правила из папки .cursor/rules) зависит от того, где размещена эта папка. Если в корне проекта - то распространяется на все файлы проекта. Можно разместить папку «выше» по иерархии папок, тогда она будет «действовать» на все проекты, расположенные внутри этой папки. Если разместить в домашней папке пользователя, то правила будут применяться для всех проектов пользователя в этой системе.
Соответственно, правила, размещенные внутри папки «ниже» по иерархии «действуют» по работе с файлами из этих папок и «глубже» по иерархии.
☝️ Таким образом, можно назвать это «иерархическим» скоупом правил, на базе иерархии папок.
Правила у Cursor описываются в файлах mdс (это обычный md + yaml frontmatter). Дополнительно к "иерархическому" скоупу на папках, во frontmatter конкретного файла можно установить индивидуальные правила скоупа:
*
Always: всегда применять это правило *
Auto Attached: применять при совпадении glob паттерна с файлом, с коротым работает ИИ агент*
Agent Requested : позволить агенту определить - следует ли включать это правило; но в этос случает требуется предоставить описание правила*
Manual : правило добавляется только "вручную" пользователем через @file упоминание файла с правилом в чатеДа, правила поддерживают схему "упоминания" какого то файла через указание его пути в конструкции вида @file_name. В этом случае содержимое файла будет обязательно добавлено в контекст системой, и не потребует использования тулюза через ИИ - что экономично по времени/токенам.
Cursor поддерживает спецификацию AGENTS.ms (https://agents.md/), но с некоторыми ограничениями: скоуп - только проекта, файл должен быть в корне проекта.
ℹ️ Вот ссылка на полную документацию: https://docs.cursor.com/en/context/rules
Также стоит упомянуть довольно интересный отдельный механизм Memories (https://docs.cursor.com/en/context/memories). Это когда ИИ агент извлекает из чата с пользователем правила, и самостоятельно формирует иp них файл правил со скоупом проекта.
2️⃣ Claude Code
Claude Code предоставляет, пожалуй, самые развитые средства работы с памятью. Используется файл с именем (внезапно!) CLAUDE.md, стандарт AGENTS.md не поддерживается.
- файл уровня проекта (стандартно, в корне)
- файлы выше уровня - на любой цепочке иерархии вплоть до папки пользователя "~", где может "жить" файл в "~/.claude/CLAUDE.md"; благодаря этому при старте в проекте монорепо в папке вложенного проекта - подтянется в том числе файл CLAUDE.md для всего проекта
- Organization-level memory management - что то на энтерпрайзном (возможность указывать правила уровня всей организации, управляется devOps компании);
- поддерживаются файлы CLAUDE.md вложенные в текущую папку: они аналогично будут обладать "иерархическим" скоупом, то есть распространяться при работае с файлами из нужной папки
- важно обращать внимание на расширение файла - ".md", если использовать ".MD", то не сработает
- поддерживается императивный @file импорт файлов (экономия тулюза)
- просматривать текущую память можно слеш-коммандой "/memory"
- есть команда чата "# {инструкция}" для быстрого добавления инструкции в текущий CLAUDE.md файл
- нет тонких настроек скоупов: glob - скоупов, по решению агента
Почитать подробнее тут: https://docs.anthropic.com/en/docs/claude-code/memory
#post
@deksden_notes
agents.md
AGENTS.md is a simple, open format for guiding coding agents. Think of it as a README for agents.
👍4🔥2
📝 Память AI SWE Tools
Продолжаем дальше: ..., Gemini, Codex, Kiro, ...
3️⃣ Gemini CLI
Гугл использовал отличную тактику - просто скопировать все фичи у лидера - Claude Code, потому система памяти практически идентична, но используем, конечно, файлы GEMINI.md. Правда, есть возможность (конфиг context.fileName) указать имя файла памяти любое, а AGENTS.md поддерживается по-умолчанию. То есть можно настроить gemini на чтение CLAUDE.md файлов
* все возможности "иерархического" скоупа на месте (папки выше/ниже корня проекта поддерживаются);
* поддержка @file импортов
* поддержка команды /memory
* индикатор в чате какие файлы памяти "подтянуты" в контекст;
* есть инструмент работы с памятью для ИИ агента: https://github.com/google-gemini/gemini-cli/blob/main/docs/tools/memory.md
ℹ️ Подробнее: https://github.com/google-gemini/gemini-cli/blob/main/docs/core/memport.md
С документацией заментно хуже чем у Claude Code.
4️⃣ Codex CLI:
В последнее время Codex CLI очень динамично развивается. Новая реализация на rust работает шустро и сделана довольно удобно. Фич пока категорически не хватает по сравнению с лидерами, но развитие довольно активное, поэтому даже несколько недель меняет картину. Из критического на сентябрь 2025 - мне не хватает сессий.
Память в Codex выполнена аналогичным образом:
* стандарт AGENTS.md поддерживается
* поддерживаются иерархические AGENTS.md файлы.
* глобальный файл в
* файл проекта - в корне проекта
* файлы "ниже" в иерархии - специфические для файлов из этих папок;
* просмотр памяти - только упоминание загруженных файлов в /status
ℹ️ С документацией тоже не особо густо: https://github.com/openai/codex/blob/main/docs/getting-started.md#memory-with-agentsmd
5️⃣ Kiro
Первая IDE с явной поддержкой режима SDD (spec-driven development) в противовес vibe coding: https://kiro.dev/docs/chat/vibe/
В части организации памяти - принципы похожие, но сделано все немного самобытно: если для девелопмента фич используется процесс requirements -> design -> implementation, то для организации памяти используется концепция Steering файлов (steering - "подруливающие" файлы, интересный и довольно точный термин). Это почти полный аналог rules/.md Файлов других агентов, которые подмешиваются в контекст.
* живут в проекте в выделенной папке
* немного в изначальной концепции похоже на концепцию меморибанка, просто, но "по науке":
* product.md : описание продукта, аудитория, топовые фичи, деловые цели;
* tech.md : техстек - зависимости, инструменты разработки, тех ограничения;
* structure.md : организация файлов, схема именования, импортов и архитектурные решения;
* дополнительные файлы: описывают какие-то аспекты системы;
* скоуп файла, как у cursor rules: always (включать всегда), fileMatch (по глоб паттерну в fileMatchPattern), manual (добавлять этот файл вручную через `#имя_файла`)
* можно добавить линк на файл, чтобы поддерживать steering айл в текущем состоянии через
ℹ️ Доп документация тут: https://kiro.dev/docs/steering/
#post
@deksden_notes
Продолжаем дальше: ..., Gemini, Codex, Kiro, ...
3️⃣ Gemini CLI
Гугл использовал отличную тактику - просто скопировать все фичи у лидера - Claude Code, потому система памяти практически идентична, но используем, конечно, файлы GEMINI.md. Правда, есть возможность (конфиг context.fileName) указать имя файла памяти любое, а AGENTS.md поддерживается по-умолчанию. То есть можно настроить gemini на чтение CLAUDE.md файлов
* все возможности "иерархического" скоупа на месте (папки выше/ниже корня проекта поддерживаются);
* поддержка @file импортов
* поддержка команды /memory
* индикатор в чате какие файлы памяти "подтянуты" в контекст;
* есть инструмент работы с памятью для ИИ агента: https://github.com/google-gemini/gemini-cli/blob/main/docs/tools/memory.md
ℹ️ Подробнее: https://github.com/google-gemini/gemini-cli/blob/main/docs/core/memport.md
С документацией заментно хуже чем у Claude Code.
4️⃣ Codex CLI:
В последнее время Codex CLI очень динамично развивается. Новая реализация на rust работает шустро и сделана довольно удобно. Фич пока категорически не хватает по сравнению с лидерами, но развитие довольно активное, поэтому даже несколько недель меняет картину. Из критического на сентябрь 2025 - мне не хватает сессий.
Память в Codex выполнена аналогичным образом:
* стандарт AGENTS.md поддерживается
* поддерживаются иерархические AGENTS.md файлы.
* глобальный файл в
~/.codex/AGENTS.md* файл проекта - в корне проекта
* файлы "ниже" в иерархии - специфические для файлов из этих папок;
* просмотр памяти - только упоминание загруженных файлов в /status
ℹ️ С документацией тоже не особо густо: https://github.com/openai/codex/blob/main/docs/getting-started.md#memory-with-agentsmd
5️⃣ Kiro
Первая IDE с явной поддержкой режима SDD (spec-driven development) в противовес vibe coding: https://kiro.dev/docs/chat/vibe/
В части организации памяти - принципы похожие, но сделано все немного самобытно: если для девелопмента фич используется процесс requirements -> design -> implementation, то для организации памяти используется концепция Steering файлов (steering - "подруливающие" файлы, интересный и довольно точный термин). Это почти полный аналог rules/.md Файлов других агентов, которые подмешиваются в контекст.
* живут в проекте в выделенной папке
.kiro/steering/* немного в изначальной концепции похоже на концепцию меморибанка, просто, но "по науке":
* product.md : описание продукта, аудитория, топовые фичи, деловые цели;
* tech.md : техстек - зависимости, инструменты разработки, тех ограничения;
* structure.md : организация файлов, схема именования, импортов и архитектурные решения;
* дополнительные файлы: описывают какие-то аспекты системы;
* скоуп файла, как у cursor rules: always (включать всегда), fileMatch (по глоб паттерну в fileMatchPattern), manual (добавлять этот файл вручную через `#имя_файла`)
* можно добавить линк на файл, чтобы поддерживать steering айл в текущем состоянии через
#[[file:{relative_file_name}]]ℹ️ Доп документация тут: https://kiro.dev/docs/steering/
#post
@deksden_notes
GitHub
gemini-cli/docs/tools/memory.md at main · google-gemini/gemini-cli
An open-source AI agent that brings the power of Gemini directly into your terminal. - google-gemini/gemini-cli
🔥6❤3
📝 Память AI SWE Tools
Закончим обзор китайскими инструментами - там тоже есть достойные варианты!
... Trae и Quoder.
6️⃣ Trae
Интересен инновационным режимом SOLO, но сегодня мы про систему памяти, которая очень базовая:
* скоуп - правила пользователя (settings - rules - user rules)
* правила проекта:
* frontmatter не применяется, настройки скоупа нет;
в целом - это все что можно сказать. Довольно скудно! прочитать тут: https://docs.trae.ai/ide/rules-for-ai?_lang=en
6️⃣ Qoder
‼️ Один из самых интересных релизов последнего времени. Релиз упакован рядом иновационных и интересных фишек:
- repoWiki : огромный подробный автоматически создаваемый/обновляемый wiki по проекту,
- quest mode : их тейк про spec-driven development,
- быстрый code search : graph + векторный поиск (возможно, задействуют и repowiki)
- несколько моментов про long-term memory, про что мы и поговорим подробнее
Система памяти похожа на Cursor:
*
* скоуп - проект
* есть тюнинг скоупа правил: manual / agent decides / glob pattern matching files / always
* есть система памяти: memory
▶️ Агент автоматически хранит структурированную информацию о проекте:
* персональные предпочтения (Personal Preferences): стиль кода, подходы к разработке (test-forst development), пользовательские правила;
* извлечённый опыт (!!!): решения для повторяющихся ошибок, общие шаги для решения проблем, инстуркции по сборке и развёртыванию проекта (build/deploy), извлечённые уроки из проведённых рефакторингов и исправления багов (lessons learned)
* база знаний проекта : архитектура/структура, техстек, api/subsystems integration
▶️ Агент использует следующие источники для информации:
- чаты с пользователем: извлекаем явные указания и неявные паттерны
- логи работы агента: анализируем итоги работы для понимания что работает и что не работает;
- структура проекта и документация: извлечение семантической карты проекта
▶️ Для поддержания памяти в актуальном состоянии, агент производит оценку всех записанных фактов по следующим критериям (критерии весьма интересны, кмк):
- насколько релевантны записи для будущих задач
- точность и актуальность информации
- влияние на выполнение задач
Оценка производится после выполнения любой задачи, заметки которые имеют низку оценку помечаются к удалению из актуальной памяти.
▶️ Помимо этого, агент регулярно производит "ревизию" системы памяти:
- дедупликация: объединение дублирующейся/пересекающейся информации
- устранение конфликтов: устраняются выявленные противоречия в записях
- механизм "забывания": убираем нерелевантную или устаревшую информацию, основываясь на частоте использования и актуальности
🟢 Таким образом, агент используют следующий цикл в работе с памятью:
- извлечение: поиск в памяти необходимых фактов для контекста задачи
- использование: выполнение задачи с использованием сформированного контекста
- анализ: извлечение инсайтов/итогов выполнения задачи
- оценка: качества и полезности новых "воспоминаний"
- ревизия: цикл "обслуживания" памяти, рассмотрели чуть выше.
Написано в блогах крайне интересно, что уже очень здорово - идеи реально инновационные и ранее не встречавшиеся в готовых продуктах. Как работает с реальными проектами - пока не понятно, надо пробовать.
Почитать подробнее:
* блог - https://qoder.com/blog
* документация, rules: https://docs.qoder.com/user-guide/rules
* memory: https://docs.qoder.com/user-guide/chat/memory
#post
@deksden_notes
Закончим обзор китайскими инструментами - там тоже есть достойные варианты!
... Trae и Quoder.
6️⃣ Trae
Интересен инновационным режимом SOLO, но сегодня мы про систему памяти, которая очень базовая:
* скоуп - правила пользователя (settings - rules - user rules)
* правила проекта:
.trae/rules/, пользовательские md файлы* frontmatter не применяется, настройки скоупа нет;
в целом - это все что можно сказать. Довольно скудно! прочитать тут: https://docs.trae.ai/ide/rules-for-ai?_lang=en
6️⃣ Qoder
‼️ Один из самых интересных релизов последнего времени. Релиз упакован рядом иновационных и интересных фишек:
- repoWiki : огромный подробный автоматически создаваемый/обновляемый wiki по проекту,
- quest mode : их тейк про spec-driven development,
- быстрый code search : graph + векторный поиск (возможно, задействуют и repowiki)
- несколько моментов про long-term memory, про что мы и поговорим подробнее
Система памяти похожа на Cursor:
*
.qoder/rules папки для правил* скоуп - проект
* есть тюнинг скоупа правил: manual / agent decides / glob pattern matching files / always
* есть система памяти: memory
▶️ Агент автоматически хранит структурированную информацию о проекте:
* персональные предпочтения (Personal Preferences): стиль кода, подходы к разработке (test-forst development), пользовательские правила;
* извлечённый опыт (!!!): решения для повторяющихся ошибок, общие шаги для решения проблем, инстуркции по сборке и развёртыванию проекта (build/deploy), извлечённые уроки из проведённых рефакторингов и исправления багов (lessons learned)
* база знаний проекта : архитектура/структура, техстек, api/subsystems integration
▶️ Агент использует следующие источники для информации:
- чаты с пользователем: извлекаем явные указания и неявные паттерны
- логи работы агента: анализируем итоги работы для понимания что работает и что не работает;
- структура проекта и документация: извлечение семантической карты проекта
▶️ Для поддержания памяти в актуальном состоянии, агент производит оценку всех записанных фактов по следующим критериям (критерии весьма интересны, кмк):
- насколько релевантны записи для будущих задач
- точность и актуальность информации
- влияние на выполнение задач
Оценка производится после выполнения любой задачи, заметки которые имеют низку оценку помечаются к удалению из актуальной памяти.
▶️ Помимо этого, агент регулярно производит "ревизию" системы памяти:
- дедупликация: объединение дублирующейся/пересекающейся информации
- устранение конфликтов: устраняются выявленные противоречия в записях
- механизм "забывания": убираем нерелевантную или устаревшую информацию, основываясь на частоте использования и актуальности
🟢 Таким образом, агент используют следующий цикл в работе с памятью:
- извлечение: поиск в памяти необходимых фактов для контекста задачи
- использование: выполнение задачи с использованием сформированного контекста
- анализ: извлечение инсайтов/итогов выполнения задачи
- оценка: качества и полезности новых "воспоминаний"
- ревизия: цикл "обслуживания" памяти, рассмотрели чуть выше.
Написано в блогах крайне интересно, что уже очень здорово - идеи реально инновационные и ранее не встречавшиеся в готовых продуктах. Как работает с реальными проектами - пока не понятно, надо пробовать.
Почитать подробнее:
* блог - https://qoder.com/blog
* документация, rules: https://docs.qoder.com/user-guide/rules
* memory: https://docs.qoder.com/user-guide/chat/memory
#post
@deksden_notes
Qoder
Qoder - The Agentic Coding Platform
Qoder is an agentic coding platform for real software, think deeper, build better.
🔥9👍4
⚒️ Codex : небольшие ремарки
На данный момент мой основной рабочий инструмент, который работает 24/7 (ну - не совсем, но все таки), и в пару потоков - это СС.
Но я всегда смотрю альтернативные инструмены.
🟢 После выхода GPT-5 таким инструментом стал Codex CLI. Мало того, что он довольно бодро развивается, так ещё и модель, которая работает в нем - очень умная. GPT-5-Medium / High Thinking отлично справляется с вопросам, на мой взгляд, заметно превосходя Opus 4.1.
Но тулинг вокруг модели пока довольно сырой! Мало того что не хватает почти всего, что есть в СС: сессии - да, продолжить чат нельзя, нет субагентов, нет /memory команды, нет /context, нет statusline / ccusage. В общем - как жить - хз.
⚠️ Неожиданно возникли определённые вопросы с агентским поведением модели: упорно "тупит" при запуске моего оркестратора, запуская его в синхронном режиме, и ожидая ответа. Где то - умная, но тут - почему не в фоне? Как вы понимаете, "переключить" как в СС в фоновый режим через Ctrl+B в кодексе нельзя, такой фишки нету! Проблемы, как мне кажется, в недостаточно отладенных системных промптах кодекса и описании тулов. Клод тут с начала года "полирует" тему регулярно. Например, чтобы избежать подобных кейсов в СС запуск bash сопровождается таймаутом в 2 минуты, так что через 2 минуты процесс продолжится. Сколько процесс может висеть в кодексе - я не проверял, но точно больше 2 минут!
▶️ На мой взгляд - кодекс штука интересная, но в данный момент выглядит как нишевая, для решения "сложных" задач или отдельных тем. Например, пускать кодекс как MCP сервер с Cc, для генерации "второго мнения". Я её попробую к ещё к фронтэнду подпустить - посмотрим как там оно, ещё и с playwright MCP работать будет.
В общем, текущая премиум подписка остаётся за клодом.
#post
@deksden_notes
На данный момент мой основной рабочий инструмент, который работает 24/7 (ну - не совсем, но все таки), и в пару потоков - это СС.
Но я всегда смотрю альтернативные инструмены.
🟢 После выхода GPT-5 таким инструментом стал Codex CLI. Мало того, что он довольно бодро развивается, так ещё и модель, которая работает в нем - очень умная. GPT-5-Medium / High Thinking отлично справляется с вопросам, на мой взгляд, заметно превосходя Opus 4.1.
Но тулинг вокруг модели пока довольно сырой! Мало того что не хватает почти всего, что есть в СС: сессии - да, продолжить чат нельзя, нет субагентов, нет /memory команды, нет /context, нет statusline / ccusage. В общем - как жить - хз.
⚠️ Неожиданно возникли определённые вопросы с агентским поведением модели: упорно "тупит" при запуске моего оркестратора, запуская его в синхронном режиме, и ожидая ответа. Где то - умная, но тут - почему не в фоне? Как вы понимаете, "переключить" как в СС в фоновый режим через Ctrl+B в кодексе нельзя, такой фишки нету! Проблемы, как мне кажется, в недостаточно отладенных системных промптах кодекса и описании тулов. Клод тут с начала года "полирует" тему регулярно. Например, чтобы избежать подобных кейсов в СС запуск bash сопровождается таймаутом в 2 минуты, так что через 2 минуты процесс продолжится. Сколько процесс может висеть в кодексе - я не проверял, но точно больше 2 минут!
▶️ На мой взгляд - кодекс штука интересная, но в данный момент выглядит как нишевая, для решения "сложных" задач или отдельных тем. Например, пускать кодекс как MCP сервер с Cc, для генерации "второго мнения". Я её попробую к ещё к фронтэнду подпустить - посмотрим как там оно, ещё и с playwright MCP работать будет.
В общем, текущая премиум подписка остаётся за клодом.
#post
@deksden_notes
👍1🔥1