Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 34
Долго не мог решиться и выбрать какой-нибудь инструмент для "правильной" работы с контекстом. Но увидел gbrain от создателя gstack и мой выбор остановился на нем.
Это также стало поводом для установки Hermes Agent -- имхо как личный ассистент работает в разы круче чем Claude или Codex, хотя под капотом у меня используется Codex. Все-таки очень крутой харнесс они сделали, всем советуют проинвестировать свое время и разобраться.
Память делал для агентов как раз для этого (не заменяет базы знаний, а дополняет). Отлично ложится на герпеса и других опенклавов https://github.com/holetron/hindsight-mempalace
а ты до gbrain не имел в обсидиане wiki, которую агент также сам улучшает по завету Карпатого? какая главная фича grain по сравнению с этим? более продвинутый поиск? или я неправильно понял?
я, конечно же, хранил все локально в markdown файлах. Просто в какой-то момент их становится слишком много, а выкидывать или выносить части не хотелось -- ради полноты картины.
Я понимаю, что при большом числа документов лучше использовать RAG для поиска. В GBrain поиск объединяет результаты из разных видов поиска (почитай Readme, там хорошо написано).
Также мне нравятся фичи синтеза новых знаний и более умная раскладка файлов в волте (в gbrain терминологии это называется source). Я понимаю, что большие файлы хорошо бы пилить на маленькие, это все тоже делается автоматически.
RAG на эмбеддингах если не сделан под конкретную структуру данных ручками обычно работает отвратительно, поэтому я с большим недоверием отношусь к проектам, где он по умолчанию как-то используется, типа потому что будет работать хорошо) я просто свою wiki сразу хранил как репозиторий и скрипты к нему рядом для openclaw или codex'а не важно
Только начинаю вникать в подробности, спасибо, что пишете для чайников )
Спасибо! Осталось уробороса уговорить, а то он в MD продолжает всё хранить)
Нужен слой ещё для сбора и каталогизации данных, так как они бывают очень разного формата (текст, аудио, видео, картинки и т.п.) и из различных источников
Да пора на самом деле в репозиториях в компании завести папочки .codex, .claude которые команой будут поддерживаться, набор скиллов общий для работы с продуктом, AGENTS.md в каждой папке. Одна фигня все с ними сидят, просто не признается никто, потому что позиция руководства "будет утечка кода, так что нельзя, но ставить вам задачи с нереальными сроками мы все равно будем".
Вместо того чтобы рандомный девопс случайно положит инфраструктуру когда захочет что то "по быстрому" и "лёгкое" сделать, проблему решает единый инфровый скилл в котором расписано как все должно и не должно работать. Делается один раз больно и тяжело, а потом развивается потихоньку и агент вполне себе живёт нормально в рамках, понимая что можно, а что нельзя сделать.
И учетка специальная чисто для агента, которой можно делать определенные вещи. А хочешь что то в пайпе поменять - вайбкодь на здоровье, но убедись что все соответствует стандартам и дождись ревью.
Короче все настраивается, будь желание.
Теперь стоит вопрос - могут ли нейронки писать код дешево. 😆
Конечно могут) все заливается венчурными деньгами очень сильно, так что сбросы лимитов и бесплатные токены раздаются направо и налево
Ну на корпоративной подписке Клода расход токенов сонетом где-то 1$ в минуту, опус 3$ в минуту. Одно хорошо, что агент пишет код 5 минут и потом я 2 часа правлю. Или проверяю, что все работает
Звучит так, что у вас тратится контекст куда-то не туда. Изучите, какие файлы и каких размеров читает агент каждый раз перед выполнением работы, возможно, там есть файлик на много тясяч строк, который забивает весь контекст, оставляя под полезную деятельность очень мало места.
Вот этот скилл может помочь в этом:
https://github.com/cursor/plugins/blob/3347cbab5b54136f6fba0994c3a01a56f7fb7fca/cursor-team-kit/skills/thermo-nuclear-code-quality-review/SKILL.md
Тоже пришел к этой проблеме, но у меня свое видение решения этого вопроса: репозиторий спецификаций с версионированием. Буду писать сервис под свою команду.
Проблема не в том что нет правил. А втом что ии может в любой момент времени игнорировать их. Например у нас сразу указано правило 0 запрет на демтруктивные действия и они даже описаны. Но регулярно с талаиваюсь стем что ии удаляет volume проектов. Поэтому на прод их не пускаю
У меня прямо вот каких-то знаний в проекте обычно нет, кроме как архитектуры и истории принятия решений. И под свой флоу я создал продукт Work Graph и выложил в оупенсорс. Для соло и пет-проектов очень удобно.
Юзер флоу такой: В архитектуру добавляем домены (верхний уровень архитектуры).
Далее: Анализ вопроса > Выбор решения > Создание эпика/задач > Выполнение > Тестирование > Сохранение
Получился навигатор для AI-разработки.
Как будет время, напишу статью, пока руки не дошли.
Круто! Рекоментую изучить проект paperclip - немного напомнило ваш сетап.
Если коротко, то Work Graph пытается решить фундаментальную проблему AI-разработки: разрыв между намерением человека и исполнением машины.
Paperclip управляет агентами как сотрудниками, но не проверяет качество их работы.
Work Graph создаёт слой смысла (BVC-атом), связывает его с кодом, а затем может автоматически верифицировать, что код действительно реализует задуманный смысл.
Это делает Work Graph не просто трекером задач и не просто оркестратором, а инструментом формальной верификации соответствия кода намерению. И граф здесь — это не только связи между задачами, но и связи между атомами смысла (BVC) и конкретными строками кода.
Как вы собираетесь проверять код клтрый пишет агент? Тоже с помощью ИИ? Люди говорят о проблеме, которую вы или игнорируете или не понимаете. Ваша задача продать компании инструмент. Поэтому вы всегда будете искать оправдание что виновен не ИИ… На написание кода всегда уходило минимум времени. Это никогда не было узким местом. А вот проверка 100 или 1000 строк, решение конфликтов слияния в командной репе, поиск месиа где баг возник анализ кода… Вот это да, узкое место. Поэтому люди и говорят что оно не работает! LLM в соеднем ошибается в 30% в том, что знает идеально. Это очень высокий уровень ошибки! Вы агентами просто упростили и без того простое, и это усложнило и без того сложное. Вот и итог, работа стала медленее ибо узки места остались… Вы не решаете проблему ИИ агентами, вы создаёте новую!.. Хоть расшаривай, хоть нет, от этого архитектура LLM лучше ге станет!..
решение конфликтов слияния в командной репе
Решается правильной организацией процесса разработки.
Часто это сигнал что проблемы в архитектуре приложения и/или межкомандом взаимодействии (Conway’s Law в действии, типа конфликты слияния - такое отражение проблем в коммуникациях внутри организации).
В частности, сейчас это решается цепочкой из агентов, где каждый выполняет свою задачу:
идея -> спека -> план -> разработка через goal -> тестирование локально -> PR -> ревью другими агентами с нуля -> фиксы и деплой.
Но а в конце нужен человек, кто возьмет ответственность за результат. Пока что хе-хе
Судя по моему опыту, ИИ всегда по началу делает ошибки. Но с каждой итерацией результаты становятся лучше, если научить агента запоминать и учиться на ошибках.
А выстраивать ИИ процессы так, чтобы агенты перестали ошибаться, это современный и очень востребованный навык. Как в низкоуровневую разработку непросто влиться без опыта, так и с ИИ: не получится просто закинуть промпт и сразу получить правильное решение, хотя и OpenAI, и Anthopic подходят к решению этой задачи все ближе и ближе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Claude Code и Codex не ускоряют команду: у компании нет общей памяти