Лично я пошёл по самому простому пути - делегирование. За написание кода у меня полностью отвечает агент. Код получается ужасный. Но... он работает.
На мой взгляд, дело не в полномочиях агента, не в разрешениях. Дело в минимизации ущерба, когда он возникнет. В общем, я думаю, примерно с такими же проблемами сейчас сталкиваются руководители софтварных "галер" на несколько десятков команд, работающих одновременно над несколькими проектами, иногда даже конкурирующих друг с другом заказчиков. И у них уже есть решения. Просто разработчики вращаются в другой среде и этих решений не знают.
IMHO, любой агент - обвязка для вызова LLM по итогу. Можно на агента (обвязку для LLM) навесить свою обвязку (только сегодня мне Чатик выдал термин external harness на мой продукт github-flows-app). Так вот, моё мнение, в external harness памятью может быть что угодно - база, файлы, оперативка, аудио-записи, картинки, видео, ... Но в Модель (LLM) агент передаёт (и получает из неё) только текст. Другие типы моделей могут работать со звуком, изображением и видео в другом формате, но языковые модели (которые генерируют код - текст) работают с текстом.
Поэтому любая память так или иначе должна быть преобразована в текст, для того, чтобы стать доступной Модели. И тут уже возникают вопросы к "обвязке" - к агенту, к тому, кто готовит для агента данные (если они есть). Как она (обвязка) эти данные преобразует в текст, чтобы LLM могла их "понять" (использовать в инференсе).
На мой взгляд, пока что самым оптимальным является иерархическая организация md-файлов с текущим состоянием проекта. Агенту не надо знать историю и причины тех или иных решений. Агенту нужно знать текущее состояние, направление движения и рамки (чего делать, и чего не делать). Остальное - задача человека. Таким образом, в моменте я разделяю все свои md-файлы на две части: документация проекта и документация инструментария. Первое - уникальное для каждого проекта и лежит в проекте, второе - оформляется скиллами и подключается по мере необходимости.
Это на мой взгляд, повторяюсь. В конце-концов, вы же сами просили "поделитесь в комментариях своим опытом и тем, что вы сами называете памятью агента" 🤗
Текст представляет спор о памяти для AI‑агентов не как спор между конкретными технологиями, а как попытку развести понятия и понять, какие задачи памяти выполняют разные формы хранения. Автор разделяет концепцию памяти на четыре моделируемых слоя: (1) память как документация, где данные лежат рядом с кодом и облекают проект в AGENTS.md, MEMORY.md и т.п.; (2) память как поиск, где роль играют индексы и семантический поиск, позволяющие вытягивать релевантные фрагменты из большого массива материалов без перегрузки контекстом; (3) память как состояние работы, которая фиксирует текущее состояние проекта, гипотезы, статусы и чекпоинты, чтобы вернуться к задаче без повторной археологической экспедиции по репозиторию; (4) память как опыт, где сохраняются причины решений, компромиссы, цены ошибок и уроки, чтобы не повторять старые ошибки и сохранять контекст принятия решений. В тексте подробно анализируются преимущества и ограничения каждого слоя, приводятся примеры артефактов (markdown‑файлы, базы данных, Obsidian, knowledge graph), а также роль автоматизации и структуры данных в управлении контекстом и актуальностью информации. Далее исследуется, как смешение подходов обуславливает реальную рабочую память проекта: чем крупнее проект, тем важнее корректное сочетание поиска, структуры и состояния; задача не в том, чтобы выбрать один инструмент как универсальный ответ, а в том, чтобы понять, как разные инструменты взаимодействуют: хранение, индексация, выбор фрагментов и передача контекста к агенту. Автор делает акцент на границе между хранением и использованием, на различии между стабильной документацией и динамическим рабочим состоянием, а также на необходимости отбора и объяснения причин решений, чтобы не превратить память в бесконечный чердак. В финале подчеркивается, что спор начинается с того, какую задачу должен решать каждый инструмент: markdown, SQLite, Obsidian, поиск и т. п. — и что универсально правильного решения нет. ПС напоминает читателю, что речь идёт именно о задачах каждого инструмента, а приглашение к обмену опытом подчёркивает открытость темы.
В общем, инструмент, на мой взгляд, получился неплохой и вполне рабочий, но в массы не зашёл. Поэтому я его с тех пор и не дорабатывал (весь код агенты писали, так-то). Работает себе автономно и кушает себе по пять-десять баксов в месяц на OpenAI API. Как руки дойдут, доработаю. А нет, ну и нет.
TypeScript, VSCode и GitHub - это всё продукты Microsoft. Вот поэтому с JS/JSdoc так неудобно работать в VSCode. Я этого в IDEA вообще не чувствовал. А в VSCode - да, там надо писать types.d.ts в проектах, чтобы JSDoc заработал.
"Talk is cheap. Show me the code." (c) Linus Torvalds
Я вам свой код показал. Вот ещё ИИ-код с DI. Покажите свой продукт.
Да и по производительности кодогенерации видно.
Важна не производительность, а управляемость. А то, как говорила одна секретарша из анекдота: "Я могу печатать со скоростью 1000 знаков в минуту. Но такая ерунда получается".
DI очень популярен в таких языках, как Java и C#, на которых строят совсем не персональные веб-странички. DI используется в Magento обеих версий. Во второй версии как раз и есть несколько миллионов строк на PHP и это только в ядре, без учёта сторонних расширений.
Если вы считаете, что статическое связывание JS-кода на этапе компиляции через импорты - хорошее решение, то ознакомьтесь с причинами появления архитектурного шаблона Inversion of Control. А если вы считаете, что true IoC - это Ambient Context, а DI - лажа, то вы явный сектант. Авторы книги "Dependency Injection" Steven van Deursen и Mark Seemann прямо называют Ambient Context антипаттерном в IoC и формулируют причины.
Чтобы экономились токены как раз и нужна декомпозиция и позднее связывание. В npm-реестре свыше 4 млн. пакетов, а строк кода - сотни миллиардов. Тем не менее, и человек, и ИИ-агент спокойно могут выдернуть любой пакет из этой кодовой базы и использовать в своём приложении.
"Кожаные" уже всё придумали, "силиконовым" осталось только использовать.
Если спросить у разных Ai построить архитектуру Ai first приложения и какие антипаттерны лучше не использовать то все ai вам скажут что di это зло.
Это я не проверял, но уверенно предположу, что это ложь. DI десятилетиями (!!) использовалась "кожанными" в разных ЯП, особенно в "кровавом энтерпрайзе". Это проверенный временем и практикой архитектурный шаблон, на котором, кстати, модели сами учились программировать.
Да, и вообще, ваша LLM ответит вам то, что вы хотите услышать. Они те ещё манипуляторы! Мой GPT-чат от DI в JS в восторге. Вот пример кода, полностью написанного ИИ (Codex-агент), и там DI ¯\_(ツ)_/¯
Правда, тут JSDoc вместо "строгой типизации", но для навигации по коду этого хватает, а в runtime JSDoc не используется точно так же, как и "строгая типизация" TypeScript. Зато одинаково хорошо работает и для фронта, и для бэка.
На этом фоне у традиционных DI-решений есть три пути, и все три — тупиковые
Есть ещё масса нетрадиционных тупиковых путей. Надо только покопать.
Я, кстати, у себя вообще отказался от container.registerXXX , оставил только для тестового режима. Всё остальное "на магии", как вы говорите - через настройку маппинга пространства имён на пути в файловой системе (калька с Java с их classpath и PHP с PSR-4).
Зато такой подход даёт возможность вообще отказаться от статических импортов (они есть только в Composition Root) и добавить в приложения такие экзотические для JavaScript вещи, как interface.
То, что это, кроме меня, нафиг никому не надо в JS - это отдельный вопрос. Но у меня есть :)
Если взять фрагмент размером 67К токенов (это примерно 29 глав романа "Анна Каренина") и попросить любую модель произвести замену "Степан Аркадьевич" на "Павел Петрович" с учётом падежей, то результирующий текст с правильными заменами и будет представлять собой практический предел возможностей данной модели.
На момент написания статьи GPT-5 через веб-интерфейс даёт максимальный выходной результат примерно в 4К токенов (12.5К кириллических символов), а веб-интерфейс для Gemini 2.5 Pro - 12К токенов (37К кириллических символов). При этом модели ведут себя по-разному: GPT-5 просто дополняет результат необработанным текстом после 4К (без замены Степана на Павла), а Gemini перестаёт выдавать результат в браузер и рапортует о потере подключения к интернету, стирая при этом уже полученный результат.
Производители этих моделей заявляют о теоретических пределах в 128К токенов для GPT-5 и 64К токенов для Gemini 2.5 Pro, но через веб-интерфейс такие пределы на практике недостижимы.
Я проводил такой простой эксперимент, чтобы узнать реальные возможности Моделей, а не заявленный маркетинговый булшит производителя. Думаю, модели и сейчас ещё не вышли за 67К токенов повторяемого результата. Это чертовски энергетически затратно - экспоненциальное развитие ИИ требует экспоненциальных энергетических затрат, а у нас за околицей углеводороды дорожают...
Ну так это так и есть - агенты могут обновлять кодовую базу по тикетам пользователей и выкатываться на прод. В ограниченных мной пределах. Что не так-то? Где тут заявка на полный доступ? Вы можете предоставить по такой схеме доступ к своему сайту и установить свои пределы. На свой страх и риск. Welcome, как говорится.
Ну, я не универсальный проблем солвер. У меня есть ответы лишь на определённый класс вопросов. Да и не то, чтобы есть, я их всё ещё ищу. Но спасибо, что поделились своим мнением :)
Я имею опыт взаимодействия именно с кодексом. С Copilot'ом как-то не сложилось. Плюс, я могу агента менять, на того же Клода, например. А вместо гитхаб взять гитлаб. Ну, могу думать в эту сторону. А решение от Майкрософта - это вендор-лок.
Лично я пошёл по самому простому пути - делегирование. За написание кода у меня полностью отвечает агент. Код получается ужасный. Но... он работает.
На мой взгляд, дело не в полномочиях агента, не в разрешениях. Дело в минимизации ущерба, когда он возникнет. В общем, я думаю, примерно с такими же проблемами сейчас сталкиваются руководители софтварных "галер" на несколько десятков команд, работающих одновременно над несколькими проектами, иногда даже конкурирующих друг с другом заказчиков. И у них уже есть решения. Просто разработчики вращаются в другой среде и этих решений не знают.
IMHO, любой агент - обвязка для вызова LLM по итогу. Можно на агента (обвязку для LLM) навесить свою обвязку (только сегодня мне Чатик выдал термин external harness на мой продукт github-flows-app). Так вот, моё мнение, в external harness памятью может быть что угодно - база, файлы, оперативка, аудио-записи, картинки, видео, ... Но в Модель (LLM) агент передаёт (и получает из неё) только текст. Другие типы моделей могут работать со звуком, изображением и видео в другом формате, но языковые модели (которые генерируют код - текст) работают с текстом.
Поэтому любая память так или иначе должна быть преобразована в текст, для того, чтобы стать доступной Модели. И тут уже возникают вопросы к "обвязке" - к агенту, к тому, кто готовит для агента данные (если они есть). Как она (обвязка) эти данные преобразует в текст, чтобы LLM могла их "понять" (использовать в инференсе).
На мой взгляд, пока что самым оптимальным является иерархическая организация md-файлов с текущим состоянием проекта. Агенту не надо знать историю и причины тех или иных решений. Агенту нужно знать текущее состояние, направление движения и рамки (чего делать, и чего не делать). Остальное - задача человека. Таким образом, в моменте я разделяю все свои md-файлы на две части: документация проекта и документация инструментария. Первое - уникальное для каждого проекта и лежит в проекте, второе - оформляется скиллами и подключается по мере необходимости.
Это на мой взгляд, повторяюсь. В конце-концов, вы же сами просили "поделитесь в комментариях своим опытом и тем, что вы сами называете памятью агента" 🤗
Статья интересная, но я после двух третей текста спрыгнул на свой проект - https://mindstream.app.wiredgeese.com/ Нашёл поиском по ключу "почему мы" эту статью и прочитал вот эту LLM-выжимку:
LLM-выжимка LLM-текста
Текст представляет спор о памяти для AI‑агентов не как спор между конкретными технологиями, а как попытку развести понятия и понять, какие задачи памяти выполняют разные формы хранения. Автор разделяет концепцию памяти на четыре моделируемых слоя: (1) память как документация, где данные лежат рядом с кодом и облекают проект в AGENTS.md, MEMORY.md и т.п.; (2) память как поиск, где роль играют индексы и семантический поиск, позволяющие вытягивать релевантные фрагменты из большого массива материалов без перегрузки контекстом; (3) память как состояние работы, которая фиксирует текущее состояние проекта, гипотезы, статусы и чекпоинты, чтобы вернуться к задаче без повторной археологической экспедиции по репозиторию; (4) память как опыт, где сохраняются причины решений, компромиссы, цены ошибок и уроки, чтобы не повторять старые ошибки и сохранять контекст принятия решений. В тексте подробно анализируются преимущества и ограничения каждого слоя, приводятся примеры артефактов (markdown‑файлы, базы данных, Obsidian, knowledge graph), а также роль автоматизации и структуры данных в управлении контекстом и актуальностью информации. Далее исследуется, как смешение подходов обуславливает реальную рабочую память проекта: чем крупнее проект, тем важнее корректное сочетание поиска, структуры и состояния; задача не в том, чтобы выбрать один инструмент как универсальный ответ, а в том, чтобы понять, как разные инструменты взаимодействуют: хранение, индексация, выбор фрагментов и передача контекста к агенту. Автор делает акцент на границе между хранением и использованием, на различии между стабильной документацией и динамическим рабочим состоянием, а также на необходимости отбора и объяснения причин решений, чтобы не превратить память в бесконечный чердак. В финале подчеркивается, что спор начинается с того, какую задачу должен решать каждый инструмент: markdown, SQLite, Obsidian, поиск и т. п. — и что универсально правильного решения нет. ПС напоминает читателю, что речь идёт именно о задачах каждого инструмента, а приглашение к обмену опытом подчёркивает открытость темы.
В общем, инструмент, на мой взгляд, получился неплохой и вполне рабочий, но в массы не зашёл. Поэтому я его с тех пор и не дорабатывал (весь код агенты писали, так-то). Работает себе автономно и кушает себе по пять-десять баксов в месяц на OpenAI API. Как руки дойдут, доработаю. А нет, ну и нет.
Мне кажется, что нынешние агенты такие детские болезни уже переросли. Нужно что-то посерьёзнее. Вот этот тикет обработан codex-агентом (подробнее).
TypeScript, VSCode и GitHub - это всё продукты Microsoft. Вот поэтому с JS/JSdoc так неудобно работать в VSCode. Я этого в IDEA вообще не чувствовал. А в VSCode - да, там надо писать types.d.ts в проектах, чтобы JSDoc заработал.
А так-то статистика разная бывает - https://innovationgraph.github.com/global-metrics/programming-languages
Talk is cheap. Show me the code.
"Talk is cheap. Show me the code." (c) Linus Torvalds
Я вам свой код показал. Вот ещё ИИ-код с DI. Покажите свой продукт.
Важна не производительность, а управляемость. А то, как говорила одна секретарша из анекдота: "Я могу печатать со скоростью 1000 знаков в минуту. Но такая ерунда получается".
DI очень популярен в таких языках, как Java и C#, на которых строят совсем не персональные веб-странички. DI используется в Magento обеих версий. Во второй версии как раз и есть несколько миллионов строк на PHP и это только в ядре, без учёта сторонних расширений.
Если вы считаете, что статическое связывание JS-кода на этапе компиляции через импорты - хорошее решение, то ознакомьтесь с причинами появления архитектурного шаблона Inversion of Control. А если вы считаете, что true IoC - это Ambient Context, а DI - лажа, то вы явный сектант. Авторы книги "Dependency Injection" Steven van Deursen и Mark Seemann прямо называют Ambient Context антипаттерном в IoC и формулируют причины.
Чтобы экономились токены как раз и нужна декомпозиция и позднее связывание. В npm-реестре свыше 4 млн. пакетов, а строк кода - сотни миллиардов. Тем не менее, и человек, и ИИ-агент спокойно могут выдернуть любой пакет из этой кодовой базы и использовать в своём приложении.
"Кожаные" уже всё придумали, "силиконовым" осталось только использовать.
Тут согласен.
Это я не проверял, но уверенно предположу, что это ложь. DI десятилетиями (!!) использовалась "кожанными" в разных ЯП, особенно в "кровавом энтерпрайзе". Это проверенный временем и практикой архитектурный шаблон, на котором, кстати, модели сами учились программировать.
Да, и вообще, ваша LLM ответит вам то, что вы хотите услышать. Они те ещё манипуляторы! Мой GPT-чат от DI в JS в восторге. Вот пример кода, полностью написанного ИИ (Codex-агент), и там DI ¯\_(ツ)_/¯
Положительно отношусь. Даже запилил свой DI-контейнер под чистый JS - https://github.com/teqfw/di
Правда, тут JSDoc вместо "строгой типизации", но для навигации по коду этого хватает, а в runtime JSDoc не используется точно так же, как и "строгая типизация" TypeScript. Зато одинаково хорошо работает и для фронта, и для бэка.
Есть ещё масса нетрадиционных тупиковых путей. Надо только покопать.
Я, кстати, у себя вообще отказался от
container.registerXXX, оставил только для тестового режима. Всё остальное "на магии", как вы говорите - через настройку маппинга пространства имён на пути в файловой системе (калька с Java с их classpath и PHP с PSR-4).Зато такой подход даёт возможность вообще отказаться от статических импортов (они есть только в Composition Root) и добавить в приложения такие экзотические для JavaScript вещи, как
interface.То, что это, кроме меня, нафиг никому не надо в JS - это отдельный вопрос. Но у меня есть :)
А вот это - зря. Ложная скромность. Как говорят критики произведений Булгакова, "Сами предложат и сами всё дадут" работает только с "люлЯми".
Вот канал - https://telegram.me/tassadarai
https://habr.com/ru/articles/948282/
Я проводил такой простой эксперимент, чтобы узнать реальные возможности Моделей, а не заявленный маркетинговый булшит производителя. Думаю, модели и сейчас ещё не вышли за 67К токенов повторяемого результата. Это чертовски энергетически затратно - экспоненциальное развитие ИИ требует экспоненциальных энергетических затрат, а у нас за околицей углеводороды дорожают...
Спасибо. Не надо откатывать, пусть остаётся как есть. Не будем повышать энтропию :)
Ну так это так и есть - агенты могут обновлять кодовую базу по тикетам пользователей и выкатываться на прод. В ограниченных мной пределах. Что не так-то? Где тут заявка на полный доступ? Вы можете предоставить по такой схеме доступ к своему сайту и установить свои пределы. На свой страх и риск. Welcome, как говорится.
Ну, я не универсальный проблем солвер. У меня есть ответы лишь на определённый класс вопросов. Да и не то, чтобы есть, я их всё ещё ищу. Но спасибо, что поделились своим мнением :)
И в каком месте автор "говорил о полном доступе"? Вы очень странный для айтишника.
Да, конечно. Вот промпты и весь workflow - http://cms.teqfw.com/output.zip
Можно и посерьезнее, но, конечно, не через доступ всем, кому ни попадая.
Никогда. Теперь уже никогда. Привыкайте.
Я имею опыт взаимодействия именно с кодексом. С Copilot'ом как-то не сложилось. Плюс, я могу агента менять, на того же Клода, например. А вместо гитхаб взять гитлаб. Ну, могу думать в эту сторону. А решение от Майкрософта - это вендор-лок.