А вы-то сами можете "детерминированно генерировать код"? Не на уровне "Hello, World!" или "ToDo List", а на уровне приложения хотя бы на пару тысяч LOC? Каковы ваши собственные пределы детерминированности?
Я когда-то, в первой половине 90-х, изучал ассемблер и писал на нём работающие программы. Не то, чтобы я читал с листа машкоды, но разбирался с помощью справочника, что именно там написано. А потом мне как-то стало плевать на сохранность этого навыка и я ушёл в сторону ЯП высокого уровня - сначала C/Pascal, потом C++, потом Java, а потом вообще PHP и JS.
Буквально вчера вечером я попросил агента исправить одноразовое приложение на JS, которое такой же агент создавал 10 месяцев назад для мониторинга сайта объявлений и которое проработало несколько недель, пока не перестало быть нужным. Теперь надо было мониторить другую категорию объявлений с другой структурой. В этом приложении есть веб-сервер для регистрации пользователей на получение push-уведомлений и сервис, который опрашивает сервер объявлений на предмет появления новых, после чего отправляет push-уведомление всем зарегистрированным пользователям. Я ж говорю, чисто одноразовое приложение под текущую задачу.
Так вот, я полез читать код, который там нагенерён - не помню я через 10 месяцев, что там вообще. Потом плюнул и просто спросил агента - что это и как оно работает. Через минут 5 у меня в памяти была восстановлена картина в общих чертах. Ещё минут 10 мы с агентом переключались на новую категорию объявлений и обновляли библиотеки, после чего я минут 20 восстанавливал окружение, которое я снёс за ненадобностью - веб-сервер, DNS, systemd, ... Сейчас это приложение уже крутится и мониторит новую категорию.
В код я так больше и не заглядывал. Не пригодилось.
Я в курсе, что не во всех сферах человеческой деятельности такой подход применим. Я даже могу согласиться, что во многих сферах традиционного программирования такой подход не применим. Но такой подход открывает ниши, где неприменим уже традиционный подход "с чтением кода и написанием его вручную".
Кстати, буквально вчера стучал рекрутёр с вопросом, а могу ли я всё ещё работать с Lotus Notes? А я уже лет 15-20, как с ним не работаю никак. Не сохранил я этот навык, как и множество других, когда-то полезных - умение администрировать машины с MS-DOS и Windows for Workgroups, NT4, XP, Win2K, OS/2 Warp, Novell Netware, Solaris, Slackware, RedHat/Fedora, писать проги под MS Office и Lotus Notes/Domino, сервлеты под Tomcat, утратил навыки программирования портлетов для Liferay и их интеграции с Intalio BPMS, я больше не программирую на Clarion / C / LotusScript / VisualBasic / Java и почти уже не программирую на PHP и начал забывать Magento. У меня много утраченных навыков и много приобретённых. Одним больше, одним меньше...
Да, у вас такая сфера деятельности, где нужны работающие и проверенные практикой подходы. Вангую, что к вам ИИ-кодинг придёт позже других и в уже достаточно стабильном виде :) Ну а эксперименты с ИИ будут проводиться в других сферах.
То что работает у вас, не факт что сработает в другой сфере, не только моей.
Ладно, давайте расширять. Вот JS-код. Во всех исходниках всего пакета (./src/) нет ни одного статического import'а. А там порядка 20 файлов. Тем не менее, пакет рабочий и используется в составе других пакетов (например, github-flows-app).
Это называется "late binding". В таком виде (без статических импортов) JS-код становится изоморфным - может работать и в браузере, и на бэке без изменений. Юнит-тестирование такого кода становится детской игрой, так как можно подменить моком любую зависимость, вплоть до node-библиотек.
Этот подход пришёл из того самого "энтерпрайза", который вы пренебрежительно называете "Ынтырпрайз". В кодовой базе Magento Open Source 2.4.x свыше 2 млн. строк на PHP, а ещё под 0.5 млн - на JavaScript (не TypeScript!). В базовом наборе платформы порядка 200+ модулей, а сторонние разработчик дают возможность доставить в базу ещё свыше 2К модулей и одному Богу известно, сколько там строк кода. И весь этот "зоопарк" способен крутиться согласованно и на фронте, и на бэке, благодаря технологиям "Ынтырпрайза", в том числе и позднему связыванию.
И тот же WebStorm использует TypeScript Language Server для валидации типов
WebStorm появился в 2010 году - за два года до TypeScript'а. В нём есть отдельно настройки для JavaScript и для TypeScript. Да, для валидации типов в TypeScript IDEA может использовать TS Language Server. Но его можно отключить и писать на чистом JS.
В IDEA JS можно использовать без TS
Это означает: больший размер бандла (нет минификации и удаления неиспользуемого кода),
Минификации JSDoc не мешает - можно выкинуть все JSDoc'и и код остаётся рабочим. А неиспользуемого кода здесь нет в принципе - связывание идёт в runtime.
Да, для TS есть своя ниша - "галеры". Создаётся ощущение контроля за ситуацией. Типа, мы "натянули типы" на JS. Но - нет, не натянули. Их там как не было, та и нет. Откройте DevTools в браузере по F12 и убедитесь сами. Типы есть только в вашем IDE и лишь до транспиляции.
Я пять лет назад уже публично пояснил, почему я предпочитаю JS. С тех пор не особо что изменилось. Вернее, поводов использовать TS становится всё меньше. А ИИ-агенты - так это вообще повод TS не использовать. Им-то зачем лишний раз код транспилить при рефакторинге? Экономия токенов идёт от понимания моделью контекста задачи, а не от количества символов, и JSDoc здесь как раз к месту.
А если пользователь находит баг, который стоит миллионы для компании?
Это значит, что остальные способы проверки работоспособности продукта не сработали и баг попал в прод.
Нет, это значит остальные способы проверки работоспособности оказались недостаточными.
А разве “оказались недостаточными” по факту не означает “не сработали”? IMHO, как раз именно это и означает.
Нет, не означает. Одно дело если вы это тестировали и баг просочился именно там, где должен был отловить тест (ложно положительный результат), и другое дело когда это даже не проверяли.
ОК, я вполне могу принять вашу точку зрения (если “ложно положительный” - то “не сработали”, если “не проверяли” - то “недостаточные”). Но у меня картина мира попроще: баг на проде - облажались при тестировании. Ну так мне и не нужно в куче бумажек расписывать откуда-куда-что. В e-commerce как-то всё попроще, чем на ж/д.
Это значит, что остальные способы проверки работоспособности продукта не сработали и баг попал в прод. Что лишь подтверждает тезис, что самое надёжная проверка - на конечных пользователях.
"бест" - это "лучший". А я писал про "надёжный". Это "рилайэбл".
И если вы немного пораскинете мозгами, то тоже придёте к такому выводу: "самый надёжный метод проверки работоспособности продукта - на конечных пользователях".
Мы, наверное, разное вкладываем в понятие SDD. Я, например, вкладываю в это понятие то, что при хорошо написанной документации, код можно доверять (пере)генерировать агенту. Но "спеки" в этом случае должны описывать не только продукт с точки зрения бизнеса, но и используемые технологии, платформы, проектные соглашения и т.п.
Но поскольку эксплуатировать дальше продукт без чтения кода нельзя
Можно. И вы сами это делаете. У ИТ-сообщества богатый опыт использования сторонних библиотек (те же .dll в windows и .so в linux). Сборщики типа maven, composer, npm - это из этой же оперы. Вам необязательно лезть в код, чтобы использовать продукт. Достаточно контракта.
Есть много других способов. Самый надёжный из которых - конечные пользователи. Я долгое время работал с Magento, строил на её базе магазины и интегрировал в них различные расширения сторонних производителей. Очень любопытный опыт, я вам скажу. Так вот, "Magento way" - это тестирование продукта на конечных пользователях. Ну, это я так его назвал - Magento way. Потому что как интегратор я видел, что типовые сценарии работают как часики, а вот шаг влево или вправо - болото. И тикетов в Magento висела гора, я сам поставил не один десяток. И висели тикеты годами, даже те, к которым PRы были с решениями на две строчки. А платформа, тем не менее жила и процветала, одно время была вообще самой популярной в e-commerce.
Так вот, Magento way - и есть самый надёжный способ проверки работоспособности продукта. Остальные лишь помогают минимизировать возможный ущерб от "проверки пользователем". Включая ваши варианты с тестами и анализом кода через ИИ.
Согласен с @rg_software SDD - это то, как должна выглядеть разработка в идеале. И не важно, кто там "под капотом" - "кожаные" или "силиконовые".
"План эксперимента", так-то, тоже можно считать своего рода спецификацией. А удачные бизнес-приложения сейчас вообще никогда писать не заканчивают (тот же Youtube, Facebook, Amazon, ...). Так что картинка "написал спеку, а по ней просто код пишешь" - это всего лишь маленький фрагмент жизненного цикла приложения.
И это... я сейчас так и делаю - пишу документацию (спецификации), а по ним агент код генерит. Потом меняю документацию и агент меняет код. Ну и т.д.
Народ пока ещё не привык к тому, что код можно не читать. Вообще. Работоспособность продукта можно и нужно проверять не чтением кода. Но это знают product owner'ы, а не девелоперы. Вот поэтому первых станет больше, а вторых - меньше.
А для чего вам нужен TS? Вот всё то же самое делает JS, только без транспиляции и source maps. Вы, когда в консоли браузера код для исполнения вбиваете, вы JS'ом пользуетесь. Ну и зачем вам транспилятор, который в конце-концов переведёт ваш код в JS?
И чем TS лучше Java в этом случае? Я несколько лет кодил на GWT (Java-to-JS). Java вообще очень красивый, инженерный язык. Смысл мне кодить на TS, если я больше десяти лет кодил на Java? Мне можно уже сразу на JS кодить. Без посредников.
А так-то можно и для brainfuck'а свой транспилятор написать, чтобы в JavaScript перекодировалось.
вот только harness(пояс) может быть пеньковой веревкой, а может быть тактическим ремнем.
Но если у тебя в руках АК-74, то на поясе должны висеть магазины с патронами 5,45-мм и не важно - тактический это ремень или пеньковая верёвка :)
все остальное задача машины: спросить, что хочешь, предложить варианты, сопроводив их комментариями об эффективности и ограничениях, оформить и сохранить постановку задачи. При этом не забыв про Liskov Substitution и декларативный код. :)
Я имел в виду, что задача человека - научить машину вот этому "всему остальному" :) А так - да, в идеале машина должна мочь вытащить ТЗ и из Эллочки-людоедки.
Лично я пошёл по самому простому пути - делегирование. За написание кода у меня полностью отвечает агент. Код получается ужасный. Но... он работает.
На мой взгляд, дело не в полномочиях агента, не в разрешениях. Дело в минимизации ущерба, когда он возникнет. В общем, я думаю, примерно с такими же проблемами сейчас сталкиваются руководители софтварных "галер" на несколько десятков команд, работающих одновременно над несколькими проектами, иногда даже конкурирующих друг с другом заказчиков. И у них уже есть решения. Просто разработчики вращаются в другой среде и этих решений не знают.
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. Как руки дойдут, доработаю. А нет, ну и нет.
А вы-то сами можете "детерминированно генерировать код"? Не на уровне "Hello, World!" или "ToDo List", а на уровне приложения хотя бы на пару тысяч LOC? Каковы ваши собственные пределы детерминированности?
Я когда-то, в первой половине 90-х, изучал ассемблер и писал на нём работающие программы. Не то, чтобы я читал с листа машкоды, но разбирался с помощью справочника, что именно там написано. А потом мне как-то стало плевать на сохранность этого навыка и я ушёл в сторону ЯП высокого уровня - сначала C/Pascal, потом C++, потом Java, а потом вообще PHP и JS.
Буквально вчера вечером я попросил агента исправить одноразовое приложение на JS, которое такой же агент создавал 10 месяцев назад для мониторинга сайта объявлений и которое проработало несколько недель, пока не перестало быть нужным. Теперь надо было мониторить другую категорию объявлений с другой структурой. В этом приложении есть веб-сервер для регистрации пользователей на получение push-уведомлений и сервис, который опрашивает сервер объявлений на предмет появления новых, после чего отправляет push-уведомление всем зарегистрированным пользователям. Я ж говорю, чисто одноразовое приложение под текущую задачу.
Так вот, я полез читать код, который там нагенерён - не помню я через 10 месяцев, что там вообще. Потом плюнул и просто спросил агента - что это и как оно работает. Через минут 5 у меня в памяти была восстановлена картина в общих чертах. Ещё минут 10 мы с агентом переключались на новую категорию объявлений и обновляли библиотеки, после чего я минут 20 восстанавливал окружение, которое я снёс за ненадобностью - веб-сервер, DNS, systemd, ... Сейчас это приложение уже крутится и мониторит новую категорию.
В код я так больше и не заглядывал. Не пригодилось.
Я в курсе, что не во всех сферах человеческой деятельности такой подход применим. Я даже могу согласиться, что во многих сферах традиционного программирования такой подход не применим. Но такой подход открывает ниши, где неприменим уже традиционный подход "с чтением кода и написанием его вручную".
Кстати, буквально вчера стучал рекрутёр с вопросом, а могу ли я всё ещё работать с Lotus Notes? А я уже лет 15-20, как с ним не работаю никак. Не сохранил я этот навык, как и множество других, когда-то полезных - умение администрировать машины с MS-DOS и Windows for Workgroups, NT4, XP, Win2K, OS/2 Warp, Novell Netware, Solaris, Slackware, RedHat/Fedora, писать проги под MS Office и Lotus Notes/Domino, сервлеты под Tomcat, утратил навыки программирования портлетов для Liferay и их интеграции с Intalio BPMS, я больше не программирую на Clarion / C / LotusScript / VisualBasic / Java и почти уже не программирую на PHP и начал забывать Magento. У меня много утраченных навыков и много приобретённых. Одним больше, одним меньше...
Да, у вас такая сфера деятельности, где нужны работающие и проверенные практикой подходы. Вангую, что к вам ИИ-кодинг придёт позже других и в уже достаточно стабильном виде :) Ну а эксперименты с ИИ будут проводиться в других сферах.
Полностью согласен.
Ладно, давайте расширять. Вот JS-код. Во всех исходниках всего пакета (./src/) нет ни одного статического import'а. А там порядка 20 файлов. Тем не менее, пакет рабочий и используется в составе других пакетов (например, github-flows-app).
Это называется "late binding". В таком виде (без статических импортов) JS-код становится изоморфным - может работать и в браузере, и на бэке без изменений. Юнит-тестирование такого кода становится детской игрой, так как можно подменить моком любую зависимость, вплоть до node-библиотек.
Этот подход пришёл из того самого "энтерпрайза", который вы пренебрежительно называете "Ынтырпрайз". В кодовой базе Magento Open Source 2.4.x свыше 2 млн. строк на PHP, а ещё под 0.5 млн - на JavaScript (не TypeScript!). В базовом наборе платформы порядка 200+ модулей, а сторонние разработчик дают возможность доставить в базу ещё свыше 2К модулей и одному Богу известно, сколько там строк кода. И весь этот "зоопарк" способен крутиться согласованно и на фронте, и на бэке, благодаря технологиям "Ынтырпрайза", в том числе и позднему связыванию.
WebStorm появился в 2010 году - за два года до TypeScript'а. В нём есть отдельно настройки для JavaScript и для TypeScript. Да, для валидации типов в TypeScript IDEA может использовать TS Language Server. Но его можно отключить и писать на чистом JS.
Минификации JSDoc не мешает - можно выкинуть все JSDoc'и и код остаётся рабочим. А неиспользуемого кода здесь нет в принципе - связывание идёт в runtime.
Да, для TS есть своя ниша - "галеры". Создаётся ощущение контроля за ситуацией. Типа, мы "натянули типы" на JS. Но - нет, не натянули. Их там как не было, та и нет. Откройте DevTools в браузере по F12 и убедитесь сами. Типы есть только в вашем IDE и лишь до транспиляции.
Я пять лет назад уже публично пояснил, почему я предпочитаю JS. С тех пор не особо что изменилось. Вернее, поводов использовать TS становится всё меньше. А ИИ-агенты - так это вообще повод TS не использовать. Им-то зачем лишний раз код транспилить при рефакторинге? Экономия токенов идёт от понимания моделью контекста задачи, а не от количества символов, и JSDoc здесь как раз к месту.
JSDoc появился в 1999-м, TS - в 2012-м.
Не вижу смысла дискутировать. У нас с вами очень разные картины мира. Мне будет неуютно в вашей, а вам - в моей. Останемся при своих.
ОК, я вполне могу принять вашу точку зрения (если “ложно положительный” - то “не сработали”, если “не проверяли” - то “недостаточные”). Но у меня картина мира попроще: баг на проде - облажались при тестировании. Ну так мне и не нужно в куче бумажек расписывать откуда-куда-что. В e-commerce как-то всё попроще, чем на ж/д.
А разве "оказались недостаточными" по факту не означает "не сработали"? IMHO, как раз именно это и означает.
Да, опытная эксплуатация - как раз об этом. О проверке пользователями.
Специальными пользователями!
Это значит, что остальные способы проверки работоспособности продукта не сработали и баг попал в прод. Что лишь подтверждает тезис, что самое надёжная проверка - на конечных пользователях.
P.S.
bug bounty hunting - пример такого тестирования
"бест" - это "лучший". А я писал про "надёжный". Это "рилайэбл".
И если вы немного пораскинете мозгами, то тоже придёте к такому выводу: "самый надёжный метод проверки работоспособности продукта - на конечных пользователях".
Мы, наверное, разное вкладываем в понятие SDD. Я, например, вкладываю в это понятие то, что при хорошо написанной документации, код можно доверять (пере)генерировать агенту. Но "спеки" в этом случае должны описывать не только продукт с точки зрения бизнеса, но и используемые технологии, платформы, проектные соглашения и т.п.
Можно. И вы сами это делаете. У ИТ-сообщества богатый опыт использования сторонних библиотек (те же .dll в windows и .so в linux). Сборщики типа maven, composer, npm - это из этой же оперы. Вам необязательно лезть в код, чтобы использовать продукт. Достаточно контракта.
Есть много других способов. Самый надёжный из которых - конечные пользователи. Я долгое время работал с Magento, строил на её базе магазины и интегрировал в них различные расширения сторонних производителей. Очень любопытный опыт, я вам скажу. Так вот, "Magento way" - это тестирование продукта на конечных пользователях. Ну, это я так его назвал - Magento way. Потому что как интегратор я видел, что типовые сценарии работают как часики, а вот шаг влево или вправо - болото. И тикетов в Magento висела гора, я сам поставил не один десяток. И висели тикеты годами, даже те, к которым PRы были с решениями на две строчки. А платформа, тем не менее жила и процветала, одно время была вообще самой популярной в e-commerce.
Так вот, Magento way - и есть самый надёжный способ проверки работоспособности продукта. Остальные лишь помогают минимизировать возможный ущерб от "проверки пользователем". Включая ваши варианты с тестами и анализом кода через ИИ.
Нет. Нет.
"Жизнь такова, какова она есть, и более никакова" (с)
Если изначально не сделали и не развили, значит не можно было.
Согласен с @rg_software SDD - это то, как должна выглядеть разработка в идеале. И не важно, кто там "под капотом" - "кожаные" или "силиконовые".
"План эксперимента", так-то, тоже можно считать своего рода спецификацией. А удачные бизнес-приложения сейчас вообще никогда писать не заканчивают (тот же Youtube, Facebook, Amazon, ...). Так что картинка "написал спеку, а по ней просто код пишешь" - это всего лишь маленький фрагмент жизненного цикла приложения.
И это... я сейчас так и делаю - пишу документацию (спецификации), а по ним агент код генерит. Потом меняю документацию и агент меняет код. Ну и т.д.
Народ пока ещё не привык к тому, что код можно не читать. Вообще. Работоспособность продукта можно и нужно проверять не чтением кода. Но это знают product owner'ы, а не девелоперы. Вот поэтому первых станет больше, а вторых - меньше.
А для чего вам нужен TS? Вот всё то же самое делает JS, только без транспиляции и source maps. Вы, когда в консоли браузера код для исполнения вбиваете, вы JS'ом пользуетесь. Ну и зачем вам транспилятор, который в конце-концов переведёт ваш код в JS?
И чем TS лучше Java в этом случае? Я несколько лет кодил на GWT (Java-to-JS). Java вообще очень красивый, инженерный язык. Смысл мне кодить на TS, если я больше десяти лет кодил на Java? Мне можно уже сразу на JS кодить. Без посредников.
А так-то можно и для brainfuck'а свой транспилятор написать, чтобы в JavaScript перекодировалось.
Но если у тебя в руках АК-74, то на поясе должны висеть магазины с патронами 5,45-мм и не важно - тактический это ремень или пеньковая верёвка :)
Я имел в виду, что задача человека - научить машину вот этому "всему остальному" :) А так - да, в идеале машина должна мочь вытащить ТЗ и из Эллочки-людоедки.
Лично я пошёл по самому простому пути - делегирование. За написание кода у меня полностью отвечает агент. Код получается ужасный. Но... он работает.
На мой взгляд, дело не в полномочиях агента, не в разрешениях. Дело в минимизации ущерба, когда он возникнет. В общем, я думаю, примерно с такими же проблемами сейчас сталкиваются руководители софтварных "галер" на несколько десятков команд, работающих одновременно над несколькими проектами, иногда даже конкурирующих друг с другом заказчиков. И у них уже есть решения. Просто разработчики вращаются в другой среде и этих решений не знают.
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-агентом (подробнее).