🔧 Агентская память : реализации
Давайте поговорим как все устроено в этой агентской памяти. Запоминать и извлекать сведения определённо можно совершенно по-разному.
Принципиальные варианты реализации:
- 👈 контекст сохраняет/извлекает система ИИ агента - "обвязка" модели, не сама модель;
- 👉 агент "самостоятельно" рулит сохранением/извлечением информации из памяти
Посмотрим - какие готовые механизмы памяти есть в существующих ИИ системах.
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
🎁 Jules опять немного обновился
Теперь картинки можно отправлять прямо со стартовой задачей, а значит, например, легче ставить задачи на дороботку фронта и в целом любые UI вопросы.
Полезная мелочь, но не могу не отметить уверенный темп развития продукта
https://jules.google/docs/changelog/
#news
@deksden_notes
Теперь картинки можно отправлять прямо со стартовой задачей, а значит, например, легче ставить задачи на дороботку фронта и в целом любые UI вопросы.
Полезная мелочь, но не могу не отметить уверенный темп развития продукта
https://jules.google/docs/changelog/
#news
@deksden_notes
❤3👍1
☝️ ХоЗАЯке на заметку
простите за каламбур, просто пост про ЗАЮ: z.ai
Как подключить модель GLM в Клод Код и получить (по бенчам) модель на уровне Соннет 4 с ценой $3/$15 в месяц с приличными лимитами! Даже без акции это будет $30. Весьма интересно, чтобы попробовать - я вот собираюсь затестить попозже.
* про модельки тут: https://z.ai/model-api
* про подписку тут: https://docs.z.ai/devpack/overview
* про использование с СС тут: https://docs.z.ai/devpack/tool/claude
Пишите в чат, кто попробует - любопытно же!
#post
@deksden_notes
простите за каламбур, просто пост про ЗАЮ: z.ai
Как подключить модель GLM в Клод Код и получить (по бенчам) модель на уровне Соннет 4 с ценой $3/$15 в месяц с приличными лимитами! Даже без акции это будет $30. Весьма интересно, чтобы попробовать - я вот собираюсь затестить попозже.
* про модельки тут: https://z.ai/model-api
* про подписку тут: https://docs.z.ai/devpack/overview
* про использование с СС тут: https://docs.z.ai/devpack/tool/claude
Пишите в чат, кто попробует - любопытно же!
#post
@deksden_notes
😁3🔥2
Хабр: Claude Code - субагенты
Не прошло и недели, как хабр расчехлился с модерацией статьи!
Сабж тут:
https://habr.com/ru/articles/946748/
Примерно то же самое что было в канале, но немножко причесано
#post
@deksden_notes
Не прошло и недели, как хабр расчехлился с модерацией статьи!
Сабж тут:
https://habr.com/ru/articles/946748/
Примерно то же самое что было в канале, но немножко причесано
#post
@deksden_notes
🔥7❤4👍3
👉 Вайбкодинг сессии
1/2
Да, мы все с вами понимаем, что Spec-Driven Development это топ, и в целом видимо в тех краях будущее AI-driven разработки.
Но регулярно возникает необходимость оперативно внести изменения в код проекта, для которого ещё не выстроен полноценный AI SWE Pipeline на спеках и агентах.
Тогда у нас начинается "вайбкодинг" - относительно интерактивные сессии работы с системой. Что я бы посоветовал и что применяю сам в таких случаях:
‼️ Контекст должен быть чистым/достаточно свободным. Всегда начинайте новый вопрос с чистого контекста, идеально - /clear для старта новой сессии;
Иногда это невозможно: допустим, если вы в процессе чата поняли необходимость внесения изменений в код. Тут важно понять: достаочно ли у вас контекста для обсуждения изменений. Вы же используете ccstatusline? смотрите сколько токенов сейчас в контексте. Прикидывайте сколько вы потратите на обсуждения вашего рефакторинга. Если есть опасения что не хватит - делайте команду "/compact {инструкции}", а в качестве инструкции описывайте максимально те сведения, которые вам надо оставить в контексте - тогда компактификация чуть лучше сохранит вам контекст.
‼️ Используем plan mode. Идеально если у вас есть max план и доступен opus. тогда вы можете поставить модель "opusplan" (через команду /model), и тогда при переключении в режим планирования включится гораздо более эрудированный опус, что поможет. А когда вы завершите планирование, для кодинга по сформированному плану у вас будет достаточно быстрый соннет.
❓Зачем использовать "plan mode" если у вас нету opus на тарифе, и есть только соннет? Потому что это удобная возможность не писать в промптах "не делай пока код, давай обсудим". Агент будет обсуждать с вами планы, не "срываясь" фальшстартами в кодинг.
‼️ Включите стиль "Explanatory" - он значительно разбавит сухой лаконичный стиль общения СС, что важно в обсуждениях при планировании. Используйте команду "/output-style"
‼️ Прежде чем задавать свой вопрос попросите агента подготовится. Пишите "Подготовься, собери необходимый контекст: будем обсуждать вопрос ...". СС пошуршит по вашему проекту, соберёт инфу. Тогда обсуждение сразу будет предметное.
‼️ Обсуждайте вопрос. Если вышла табличка с планом, жмите 3 (отвергнуть план, продолжить обсуждение) - и пишите дальнейшие вопросы для проработки.
‼️ Когда вы получили нужное вам решение, то перед реализацией советую сделать следующие пункты:
▶️ Первым пунктом плана необходимо запланировать создание подробного плана работы в файле маркдаун с чек-листом, где указать что будем делать, где, ПОЧЕМУ именно так, какие сведения используем, на какую документацию опираемся, каким стандартам кодирования следуем, что в части интеграции отслеживаем. План разместить в папке
▶️ Вторым пунктом плана: изучить меморибанк, изучить его структуру, понять какие документы используются в документировании изменяющихся модулей системы, и прописать изменения в документацию. Принцип - docs first, мы прописываем изменения ДО их внесения.
▶️ Последним пунктом плана необходимо прописать: читаем файл маркдаун из пункта один, и систематически сверям каждый изменённый файл коди и документации с планом. Далее необходимо запланировать внесение изменений по выявленным недоработкам и недостаткам.
❓ Зачем файлик в маркдауне? Этот файл позволит вам в полном объёме сохранить ваш обсуждённый план, с проработанными деталями. Плюс вы можете сами изучить не краткое резюме плана от агента, а подробный перечень действий, и скорректировать при необходимости (что, впрочем, довольно редко).
❓ почему файл плана первым пунктом? Потому что после старта изменений агент все постепенно забудет, а вам нужно сохранить полный качественный план! Если вы этого не сделаете сразу - считайте что половину качества планирования вы слили.
Продолжение тут: https://t.me/deksden_notes/90
1/2
Да, мы все с вами понимаем, что Spec-Driven Development это топ, и в целом видимо в тех краях будущее AI-driven разработки.
Но регулярно возникает необходимость оперативно внести изменения в код проекта, для которого ещё не выстроен полноценный AI SWE Pipeline на спеках и агентах.
Тогда у нас начинается "вайбкодинг" - относительно интерактивные сессии работы с системой. Что я бы посоветовал и что применяю сам в таких случаях:
‼️ Контекст должен быть чистым/достаточно свободным. Всегда начинайте новый вопрос с чистого контекста, идеально - /clear для старта новой сессии;
Иногда это невозможно: допустим, если вы в процессе чата поняли необходимость внесения изменений в код. Тут важно понять: достаочно ли у вас контекста для обсуждения изменений. Вы же используете ccstatusline? смотрите сколько токенов сейчас в контексте. Прикидывайте сколько вы потратите на обсуждения вашего рефакторинга. Если есть опасения что не хватит - делайте команду "/compact {инструкции}", а в качестве инструкции описывайте максимально те сведения, которые вам надо оставить в контексте - тогда компактификация чуть лучше сохранит вам контекст.
‼️ Используем plan mode. Идеально если у вас есть max план и доступен opus. тогда вы можете поставить модель "opusplan" (через команду /model), и тогда при переключении в режим планирования включится гораздо более эрудированный опус, что поможет. А когда вы завершите планирование, для кодинга по сформированному плану у вас будет достаточно быстрый соннет.
❓Зачем использовать "plan mode" если у вас нету opus на тарифе, и есть только соннет? Потому что это удобная возможность не писать в промптах "не делай пока код, давай обсудим". Агент будет обсуждать с вами планы, не "срываясь" фальшстартами в кодинг.
‼️ Включите стиль "Explanatory" - он значительно разбавит сухой лаконичный стиль общения СС, что важно в обсуждениях при планировании. Используйте команду "/output-style"
‼️ Прежде чем задавать свой вопрос попросите агента подготовится. Пишите "Подготовься, собери необходимый контекст: будем обсуждать вопрос ...". СС пошуршит по вашему проекту, соберёт инфу. Тогда обсуждение сразу будет предметное.
‼️ Обсуждайте вопрос. Если вышла табличка с планом, жмите 3 (отвергнуть план, продолжить обсуждение) - и пишите дальнейшие вопросы для проработки.
‼️ Когда вы получили нужное вам решение, то перед реализацией советую сделать следующие пункты:
▶️ Первым пунктом плана необходимо запланировать создание подробного плана работы в файле маркдаун с чек-листом, где указать что будем делать, где, ПОЧЕМУ именно так, какие сведения используем, на какую документацию опираемся, каким стандартам кодирования следуем, что в части интеграции отслеживаем. План разместить в папке
.protocols/ в корневой папке проекта.▶️ Вторым пунктом плана: изучить меморибанк, изучить его структуру, понять какие документы используются в документировании изменяющихся модулей системы, и прописать изменения в документацию. Принцип - docs first, мы прописываем изменения ДО их внесения.
▶️ Последним пунктом плана необходимо прописать: читаем файл маркдаун из пункта один, и систематически сверям каждый изменённый файл коди и документации с планом. Далее необходимо запланировать внесение изменений по выявленным недоработкам и недостаткам.
❓ Зачем файлик в маркдауне? Этот файл позволит вам в полном объёме сохранить ваш обсуждённый план, с проработанными деталями. Плюс вы можете сами изучить не краткое резюме плана от агента, а подробный перечень действий, и скорректировать при необходимости (что, впрочем, довольно редко).
❓ почему файл плана первым пунктом? Потому что после старта изменений агент все постепенно забудет, а вам нужно сохранить полный качественный план! Если вы этого не сделаете сразу - считайте что половину качества планирования вы слили.
Продолжение тут: https://t.me/deksden_notes/90
Telegram
DEKSDEN notes
2/2
❓почему документация именно вторым пунктом а не после внесения изменений? По той же причине, что и создание плана первым пунктом. Только план вы используете сейчас, а документация - это то что останется для последующей работы. Это не менее важно, потому…
❓почему документация именно вторым пунктом а не после внесения изменений? По той же причине, что и создание плана первым пунктом. Только план вы используете сейчас, а документация - это то что останется для последующей работы. Это не менее важно, потому…
👍9🔥6❤3
👉 Вайбкодинг сессии
2/2
... (начало тут: https://t.me/deksden_notes/89)
❓почему документация именно вторым пунктом а не после внесения изменений? По той же причине, что и создание плана первым пунктом. Только план вы используете сейчас, а документация - это то что останется для последующей работы. Это не менее важно, потому приоритетно.
❓Зачем сверять в конце? Потому что агент "забывает" или "упускает" ряд моментов. Чем тщательнее на старте были прописаны детали вашего плана в файл, тем полнее будет реализация того. Даже не очень длинные воркфлоу на моей практике оборачивались доработками по чек-листу.
❓Что делать если настигла компактификация? Простой промпт "по ходу дела" помогает - "Прочитай файл {путь и имя файла с планом} для контекста, продолжай по плану". Засылайте такой промпт во время компактификации, тогда он его обработает сразу после возобновления работы, и забывание будет значительно скомпенсировано.
❓Есть же встроенный инструмент todo? Зачем дублировать в файл? Встроенный инструмент не содержит подробных сведений - только краткие пункты. Да, агент не забудет что надо сделать. Но может упустить проработанные вами при планировании детали - "как" именно все нужно было делать, ну и нюансы интеграции. Вы же проработали это при планировании, да?
ℹ️ Это базовый подход.
Что можно улучшать: сделать отдельные этапы на базе специализированных агентов. Если у вас есть агент, работающий с меморибанком, который в курсе про структуру хранени я информации и правила хранения данных, то документирование в меморибанк проводим через него.
Если у вас есть кодовые агенты, которые знают стиль кодирования, структуру системы, интеграции подсистем, где искать контракты подсистем, то код писать лучше через них.
Да, субагенты будут работать подольше - зато качество работы будет повыше и конекст оркестратора "целее", что позитивно для отслеживания общего плана.
Такие вот приёмы
#post
@deksden_notes
2/2
... (начало тут: https://t.me/deksden_notes/89)
❓почему документация именно вторым пунктом а не после внесения изменений? По той же причине, что и создание плана первым пунктом. Только план вы используете сейчас, а документация - это то что останется для последующей работы. Это не менее важно, потому приоритетно.
❓Зачем сверять в конце? Потому что агент "забывает" или "упускает" ряд моментов. Чем тщательнее на старте были прописаны детали вашего плана в файл, тем полнее будет реализация того. Даже не очень длинные воркфлоу на моей практике оборачивались доработками по чек-листу.
❓Что делать если настигла компактификация? Простой промпт "по ходу дела" помогает - "Прочитай файл {путь и имя файла с планом} для контекста, продолжай по плану". Засылайте такой промпт во время компактификации, тогда он его обработает сразу после возобновления работы, и забывание будет значительно скомпенсировано.
❓Есть же встроенный инструмент todo? Зачем дублировать в файл? Встроенный инструмент не содержит подробных сведений - только краткие пункты. Да, агент не забудет что надо сделать. Но может упустить проработанные вами при планировании детали - "как" именно все нужно было делать, ну и нюансы интеграции. Вы же проработали это при планировании, да?
ℹ️ Это базовый подход.
Что можно улучшать: сделать отдельные этапы на базе специализированных агентов. Если у вас есть агент, работающий с меморибанком, который в курсе про структуру хранени я информации и правила хранения данных, то документирование в меморибанк проводим через него.
Если у вас есть кодовые агенты, которые знают стиль кодирования, структуру системы, интеграции подсистем, где искать контракты подсистем, то код писать лучше через них.
Да, субагенты будут работать подольше - зато качество работы будет повыше и конекст оркестратора "целее", что позитивно для отслеживания общего плана.
Такие вот приёмы
#post
@deksden_notes
Telegram
DEKSDEN notes
👉 Вайбкодинг сессии
1/2
Да, мы все с вами понимаем, что Spec-Driven Development это топ, и в целом видимо в тех краях будущее AI-driven разработки.
Но регулярно возникает необходимость оперативно внести изменения в код проекта, для которого ещё не выстроен…
1/2
Да, мы все с вами понимаем, что Spec-Driven Development это топ, и в целом видимо в тех краях будущее AI-driven разработки.
Но регулярно возникает необходимость оперативно внести изменения в код проекта, для которого ещё не выстроен…
👍9🔥5❤2
⚒️ Новый релиз codex 0.36.0 и gpt-5-codex модель
Не даром аж 4 дня не обновляли кодекс! Готовился достаточно крупный релиз:
- новая специальная кодинговая модель
- codex resume : можно выбрать сессию которую восстанавливать, можно --last, можно по <id>
- и куча других мелких, но приятных новшеств, подробнее тут: https://github.com/openai/codex/releases/tag/rust-v0.36.0
Первые впечатления про codex-5-medium/high
Не хуже классического gpt-5-medium/high. Интерфейс теперь показывает кое-какие мысли. Думать может долго, но для простых задач может и быстро - не разобрался ещё что и как. Пока кажется что стало несколько задумчевее все!
Посмотрим как будет работать на крупном контексте. Gpt-5 на 75% контекста уже начинает путаться в ответах и чудить. Посмотрим как будет себя вести кодекс.
Upd: добавлю ссылочку где почитать про модель: https://openai.com/index/introducing-upgrades-to-codex/
- на простые вопросы отвечает действительно быстро. Видимо, это и есть обозначенная динамическая подстройка под сложность вопроса.
- местами задумывается без признаков жизни - только часики тикают. Но это просто думает.
- на большом контексте догнал 2 чата до 4% left, не чудил. Но есть ли или нету автокомпакта (который анонсировали) пока не пробовал, эти чаты было жалко, попробую потом на чем нибудь не важном
Upd2: спецэффекты к gpt-5-codex начинаются при приближении к 0% свободного конекста! не доводите, он прям деградирует по вниманию - путает сообщения при ответах, и все такое. Лучше уж компакт и восстановление контекста
Промпт для рефреша контекста в таком духе: "подготовлся с обсуждению вопроса {тематика}, читай код, документацию/меморибанк и подготовь контекст. Сами вопросы будут позже."
#post
@deksden_notes
Не даром аж 4 дня не обновляли кодекс! Готовился достаточно крупный релиз:
- новая специальная кодинговая модель
- codex resume : можно выбрать сессию которую восстанавливать, можно --last, можно по <id>
- и куча других мелких, но приятных новшеств, подробнее тут: https://github.com/openai/codex/releases/tag/rust-v0.36.0
Первые впечатления про codex-5-medium/high
Не хуже классического gpt-5-medium/high. Интерфейс теперь показывает кое-какие мысли. Думать может долго, но для простых задач может и быстро - не разобрался ещё что и как. Пока кажется что стало несколько задумчевее все!
Посмотрим как будет работать на крупном контексте. Gpt-5 на 75% контекста уже начинает путаться в ответах и чудить. Посмотрим как будет себя вести кодекс.
Upd: добавлю ссылочку где почитать про модель: https://openai.com/index/introducing-upgrades-to-codex/
- на простые вопросы отвечает действительно быстро. Видимо, это и есть обозначенная динамическая подстройка под сложность вопроса.
- местами задумывается без признаков жизни - только часики тикают. Но это просто думает.
- на большом контексте догнал 2 чата до 4% left, не чудил. Но есть ли или нету автокомпакта (который анонсировали) пока не пробовал, эти чаты было жалко, попробую потом на чем нибудь не важном
Upd2: спецэффекты к gpt-5-codex начинаются при приближении к 0% свободного конекста! не доводите, он прям деградирует по вниманию - путает сообщения при ответах, и все такое. Лучше уж компакт и восстановление контекста
Промпт для рефреша контекста в таком духе: "подготовлся с обсуждению вопроса {тематика}, читай код, документацию/меморибанк и подготовь контекст. Сами вопросы будут позже."
#post
@deksden_notes
GitHub
Release 0.36.0 · openai/codex
Breaking change: OPENAI_API_KEY is no longer read from the environment
API login is no longer implicit; we do not pick up OPENAI_API_KEY from the environment. To use an API key programmatically, ru...
API login is no longer implicit; we do not pick up OPENAI_API_KEY from the environment. To use an API key programmatically, ru...
2🔥6❤3👍2👎1
➡️ Небольшой практический пример параллельного запуска агентов
Приведу простой пример как можно организовать агентный процесс и использовать возможность СС запускать процессы параллельно.
Исходная задача: проект на TypeScript. Для него мы делаем typecheck и lint. Typecheck - это запусе typescript компилятора в режиме проверки кода (без генерации js бандла), lint - это запуск линтера, который используется в проекте. Часто это ESLint, для next.js это next lint, я последнее время для ts настраиваю biome.
➡️ Рассмотрим как тут можно кое-что ускорить за счёт параллельных задач. Первое: получить результаты компилирования и линтинга. Очевидно, что утилиты можно запустить параллельно, это мы пропишем "ручную".
Для запуска будем использовать специализированного агента, назовём "qa-agent". В контексте агента указываем:
- соберём из меморибанка сведения о тех стеке проекта, чтобы агент умел запускать утилиты,
- знал про конфиги и в случае чего мог поправить конфиг.
- знал какие папки нужно игнорировать (для ts это dist папки со сгенерированным компилятором js)
- определитесь - lint для тестов в проекте вы делаете? а компиляцию? и пропишем это в агенте;
- (на самом деле главная компетенция агента - умение запускать тесты, но чтобы не разводить слишком большую стаю агентов мы его и для компиляции с линтингом задействуем)
Итак, запуск агентов параллельно нужно сопроводить фразой: "запускай агенты
Суть магии этой фразы - добиться чтобы модель сделала "параллельный вызов" tools. Технически это происходит когда модель в одном своём ответе запрашивает вызов нескольких инструментов. СС поддерживает такую штуку и запустит агентов параллельно.
➡️ Дальше интереснее: получив результаты компилятора и линтера можно поручить модели спланировать параллельную обработку результатов - мы будем фиксить проблемы параллельными агентами.
❓ Какие есть возможности параллельной обработки проекта? принципиально их всего две:
- развести "области работы" и параллельно обрабатывать непересекающиеся части проекта; это самый простой и беспроблемный способ - если задача с понятной "зоной изменения", и мы знаем какие файлы будут изменяться, то можем поручить исправление разных файлов разным агентам. Этот способ позволяет избежать стадии решения конфликтов при "вливании" результатов работы в репозиторий.
- если зоны работы агентов пересекаются - необходимо использовать изоляцию на уровне Git: локально мы можем использовать worktree для каждого агента, или классические branch. Детали зависят от схемы работы с git в вашем проекте. Это может быть стандартные бранчи main -> develop -> (feature branch). По завершении работы мы мержим worktree/branch обратно в develop - конечно, все это делают агенты.
Для нашей задачи с исправлением ошибок компилятора / lint подходит первый вариант: ведь мы знаем списки проблемных файлов.
Мы инcтруктируем оркестратора сгруппировать проблемы с компиляцией и линтом по файлам, и распределить их между 5-7 агентами таким образом, чтобы файлы не пересекались и агенты не мешали друг другу.
Запускать агенты мы будем также, параллельно. Агент нужен будет для написания кода, "code-writer":
- знает структуру кода в проекте
- знает стандарты кодпирования
- знает как оформлять jsdoc, какие кросс-ссылки проставлять
Запускаем аналогично: даём инструкцию вызывать всех агентов в ОДНОМ сообщении оркестратора.
➡️ Итак - на верхнем уровне у оркестратора одна задача - запускать агентов, получать списки файлов и провести планирование работы так, чтобы разделить "зоны" между агентами, а в конце отчитаться о результатах. Все детали о запуске компилятора/линтера и требованиях к написанию кода будут внутри промптов субагентов.
🟢 Такая штука работает вполне надёжно и может быть запущена как отдельное агентское воркфлоу через claude code sdk/cli, можно даже по крону (ночью?).
#post
@deksden_notes
Приведу простой пример как можно организовать агентный процесс и использовать возможность СС запускать процессы параллельно.
Исходная задача: проект на TypeScript. Для него мы делаем typecheck и lint. Typecheck - это запусе typescript компилятора в режиме проверки кода (без генерации js бандла), lint - это запуск линтера, который используется в проекте. Часто это ESLint, для next.js это next lint, я последнее время для ts настраиваю biome.
➡️ Рассмотрим как тут можно кое-что ускорить за счёт параллельных задач. Первое: получить результаты компилирования и линтинга. Очевидно, что утилиты можно запустить параллельно, это мы пропишем "ручную".
Для запуска будем использовать специализированного агента, назовём "qa-agent". В контексте агента указываем:
- соберём из меморибанка сведения о тех стеке проекта, чтобы агент умел запускать утилиты,
- знал про конфиги и в случае чего мог поправить конфиг.
- знал какие папки нужно игнорировать (для ts это dist папки со сгенерированным компилятором js)
- определитесь - lint для тестов в проекте вы делаете? а компиляцию? и пропишем это в агенте;
- (на самом деле главная компетенция агента - умение запускать тесты, но чтобы не разводить слишком большую стаю агентов мы его и для компиляции с линтингом задействуем)
Итак, запуск агентов параллельно нужно сопроводить фразой: "запускай агенты
qa-agent для выполнения Typecheck и lint проекта параллельно, для этого вызывай команду запуска двух агента в ОДНОМ своём сообщении."Суть магии этой фразы - добиться чтобы модель сделала "параллельный вызов" tools. Технически это происходит когда модель в одном своём ответе запрашивает вызов нескольких инструментов. СС поддерживает такую штуку и запустит агентов параллельно.
➡️ Дальше интереснее: получив результаты компилятора и линтера можно поручить модели спланировать параллельную обработку результатов - мы будем фиксить проблемы параллельными агентами.
❓ Какие есть возможности параллельной обработки проекта? принципиально их всего две:
- развести "области работы" и параллельно обрабатывать непересекающиеся части проекта; это самый простой и беспроблемный способ - если задача с понятной "зоной изменения", и мы знаем какие файлы будут изменяться, то можем поручить исправление разных файлов разным агентам. Этот способ позволяет избежать стадии решения конфликтов при "вливании" результатов работы в репозиторий.
- если зоны работы агентов пересекаются - необходимо использовать изоляцию на уровне Git: локально мы можем использовать worktree для каждого агента, или классические branch. Детали зависят от схемы работы с git в вашем проекте. Это может быть стандартные бранчи main -> develop -> (feature branch). По завершении работы мы мержим worktree/branch обратно в develop - конечно, все это делают агенты.
Для нашей задачи с исправлением ошибок компилятора / lint подходит первый вариант: ведь мы знаем списки проблемных файлов.
Мы инcтруктируем оркестратора сгруппировать проблемы с компиляцией и линтом по файлам, и распределить их между 5-7 агентами таким образом, чтобы файлы не пересекались и агенты не мешали друг другу.
Запускать агенты мы будем также, параллельно. Агент нужен будет для написания кода, "code-writer":
- знает структуру кода в проекте
- знает стандарты кодпирования
- знает как оформлять jsdoc, какие кросс-ссылки проставлять
Запускаем аналогично: даём инструкцию вызывать всех агентов в ОДНОМ сообщении оркестратора.
➡️ Итак - на верхнем уровне у оркестратора одна задача - запускать агентов, получать списки файлов и провести планирование работы так, чтобы разделить "зоны" между агентами, а в конце отчитаться о результатах. Все детали о запуске компилятора/линтера и требованиях к написанию кода будут внутри промптов субагентов.
🟢 Такая штука работает вполне надёжно и может быть запущена как отдельное агентское воркфлоу через claude code sdk/cli, можно даже по крону (ночью?).
#post
@deksden_notes
🔥5❤2👍2
➡️ Параллельный запуск - итоги
❓ Короткий апдейт: в чем был смысл?
Посмотрите на скрин. Система работала итого чуть более 8 минут абсолютного времени. Но за это время сделано общей работы - более 25 минут! более 600к токенов.
В один поток это было бы 150к токенов максимум за такое время.
А это - все показатели реально выполненной работы и пользы. PROFIT? Очевидно - да, кмк.
▶️ Как можно улучшить?
Можно инструктировать оркестратора на генерацию yaml/json файла с итогами. Этот файл - машиночитаемый. Ваш раннер для скрипта может смотреть на этот файл, и если вас не устраивают показатели - делать повторный запуск.
Кто в курсе - у текущего клода есть ... не знаю как сказать, но пусть будет "особенность"! Он очень любит приукрашивать состояние дел, и при запуске тестов отчитываться об enterprise ready high quality system когда у вас 50% тестов валится красными.
Для борьбы с "особенностями" пригодится такой сгенерированный файл: если гонять агентов "до посинения" бездушным скриптом по крону "в ночь", то можно к утру каждый день получать "полностью зеленый" проект! Это касается и lint/typecheck, и тестов.
#post
@deksden_notes
❓ Короткий апдейт: в чем был смысл?
Посмотрите на скрин. Система работала итого чуть более 8 минут абсолютного времени. Но за это время сделано общей работы - более 25 минут! более 600к токенов.
В один поток это было бы 150к токенов максимум за такое время.
А это - все показатели реально выполненной работы и пользы. PROFIT? Очевидно - да, кмк.
▶️ Как можно улучшить?
Можно инструктировать оркестратора на генерацию yaml/json файла с итогами. Этот файл - машиночитаемый. Ваш раннер для скрипта может смотреть на этот файл, и если вас не устраивают показатели - делать повторный запуск.
Кто в курсе - у текущего клода есть ... не знаю как сказать, но пусть будет "особенность"! Он очень любит приукрашивать состояние дел, и при запуске тестов отчитываться об enterprise ready high quality system когда у вас 50% тестов валится красными.
Для борьбы с "особенностями" пригодится такой сгенерированный файл: если гонять агентов "до посинения" бездушным скриптом по крону "в ночь", то можно к утру каждый день получать "полностью зеленый" проект! Это касается и lint/typecheck, и тестов.
#post
@deksden_notes
👍8🔥2🥱1
🆕 Первые впечатления от Claude for Chrome
Утром получил письмо счастья от Антропиков, что мой лист ожидания сработал и у меня есть доступ к их новой фиче, клод в твоём браузере.
Ура!
Пойдём тестить.
Качаем расширение, логинимся в клод с Макс тарифом, одобряем подключение расширения и получаем аккуратную панель чата с клодом сбоку странички.
Ставим одобрение всего сразу - "нам нечего терять кроме наших цепей!"
Просим смотреть озон и искать товары. Заходит норм, антибот озона на него не срабатывает, что отлично. Поиском пользуется, навигацию по сайту делает.
Дальше начинаем тупить - при попытке открыть товар кликом по нему, на озоне он открывается в новой вкладке, чего клод не видит и тупит.
Потыкавшись немного в проблему с невозможностью зайти в товар, он придумывает сходить в гугл поиск. Далее получаем ошибку переполнения контекста.
Ну ок - что то работает, что то нет. Надо подумать над другими тестами
#post
@deksden_notes
Утром получил письмо счастья от Антропиков, что мой лист ожидания сработал и у меня есть доступ к их новой фиче, клод в твоём браузере.
Ура!
Пойдём тестить.
Качаем расширение, логинимся в клод с Макс тарифом, одобряем подключение расширения и получаем аккуратную панель чата с клодом сбоку странички.
Ставим одобрение всего сразу - "нам нечего терять кроме наших цепей!"
Просим смотреть озон и искать товары. Заходит норм, антибот озона на него не срабатывает, что отлично. Поиском пользуется, навигацию по сайту делает.
Дальше начинаем тупить - при попытке открыть товар кликом по нему, на озоне он открывается в новой вкладке, чего клод не видит и тупит.
Потыкавшись немного в проблему с невозможностью зайти в товар, он придумывает сходить в гугл поиск. Далее получаем ошибку переполнения контекста.
Ну ок - что то работает, что то нет. Надо подумать над другими тестами
#post
@deksden_notes
❤2🔥2👍1🤣1
🤔 Думать надо анимированно
Тут подоспел релиз СС с индексом 115 (на самом деле 117 уже)
И в нем реализовали визуальный фект для "магических" слов, которые заставляют Клод думать
Попробуйте!
Пишем в строке ввода в СС:
- think
- think hard, think deeply
- ultrathink
Эффект разный)) Не уверен что это прям нужно, но местами может быть даже полезно и забавно
Upd: коллеги уже постят мемы на тему
https://t.me/aiclubsweggs/73056
#post
@deksden_notes
Тут подоспел релиз СС с индексом 115 (на самом деле 117 уже)
И в нем реализовали визуальный фект для "магических" слов, которые заставляют Клод думать
Попробуйте!
Пишем в строке ввода в СС:
- think
- think hard, think deeply
- ultrathink
Эффект разный)) Не уверен что это прям нужно, но местами может быть даже полезно и забавно
Upd: коллеги уже постят мемы на тему
https://t.me/aiclubsweggs/73056
#post
@deksden_notes
👍1🔥1