Вчера тестировал мой агент DepthNet на реальных моделях. Это что то вроде "операционной системы для LLM моделей" В прошлой статье пользователи просили привести диалоги, и рассказать подробнее, и тогда я решил более полно осветить вопрос.

Доработка агента

В прошлые эксперименты я понял, что агент имеет множество недостатков (он и сейчас их имеет, но уже меньше :), которые необходимо пофиксить. На текущий момент сделано:

  • Плагины стали настраиваемые, и вся система плагинов стала более гибкой.

  • Добавлена возможность агента выполнять код Python и NodeJS.

  • В плагин Shell добавил экспериментальную опциональную возможность показа системного промпта shell "пользователь@хост путь $" - в надежде что так модели будет удобнее воспринимать работу с shell командами, впрочем, это возможно отключить.

  • В плагинах shell, node, php, python добавил возможность запуска от определенного юзера, так как например в окружении devilbox в котором я привык работать, php-fpm выполняется от root, что есть плохо.

  • В плагине php отказался от eval. Теперь код на всех поддерживаемых языках выполняется в отдельном процессе.

  • Изменен плагин memory. Теперь там содержимое хранится в markdown и модель может удалять конкретные пункты, а не очищать всю память. На первых этапах и экспериментах АПИ в целом не будет очень стабильным, точнее будет периодически немного меняться, это объективная необходимость.

  • Добвлен плагин vectormemory, крайне сырой и экспериментальный. Убежден, что нужна лучшая реализация но об этом буду думать позже и отдельно. Из необычных фишек, это интеграция с обычным плагином memory, когда при сохранении в векторную память создаётся ссылка в обычной памяти (добавляется пункт в markdown контент обычной памяти)

Цель: проверить новую версию агента на современной модели с хорошими показателями. Эксперимент получился "по-ковбойски", здесь и сейчас, с большим упором на тестирование самого агента, однако интересные наблюдения и выводы конечно были, о чем ниже.

Общие выводы

Обычно выводы логично делать в конце, однако, мне кажется здесь уместно это сделать раньше. Итак, в процессе эксперимента я пришел к таким выводам:

  1. Агент должен быть максимально "честным" с моделью. То есть, когда модель выполняет команды, агент не должен каким-то образом своим "юзабилити" или багами запутывать модель (с моим агентом конечно еще есть куда развиваться, объективно). Использование агента должно быть максимально просто, даже примитивно и если возможно так выразиться "адаптивно понятно". Ведь в каком то смысле основной пользователь агента это модель. И из этого происходит следующие два пункта:

  2. Модель, обученная как агент. Да, сколько уже запускал на самых разных моделях, я все больше убеждаюсь, модель должна быть специально обучена для работы в подобном агенте (не обязательно специально конкретном), и обучена не как ассистент а как агент. При этом у меня складывается субъективное мнение, что подобному агенту нужны не столько объем знаний (меньше требований к этому), сколько упор в агентские функции, и упор очень серьезный. Вообще, в моём этом эксперименте, на мой взгляд Claude 3.5 Sonnet показал себя отлично, как для модели-ассистента от которого требуют не совсем стандартное поведение.

  3. Максимальная разгрузка системного промпта. В идеале, оставлять там только задачу и самые необходимые для конкретной задачи/цели инструкции. Остальная нагрузка должна быть как на обучение модели, так и оптимизацию агента. То есть, чем сложнее/многословнее (а точнее "многоусловнее") будет системный промпт, тем с его ростом будет падать эффективность модели на любых задачах в агенте.

  4. Модель не обязательно должна быть заточена под работу с конкретным агентом. Достаточно "умная" модель будучи обучена для работы с подобным агентом, сама сможет разобраться в деталях при нормально построенном системном промпте. Но конечно апи агентов хорошо бы стандартизировать :)

  5. ИИ захватит мир. Нет, нет и еще раз нет :) В теории можно обучить для этого очень-очень-очень крутую модель, написать для неё совершенный агент, но... Думаю что для уничтожения мира есть сотни более простых способов.

Выводы относительно агента

  • Среда выполнения: Было бы хорошо сделать возможным выполнение кода и команд не в отдельном процессе, а опционально в отдельном окружении или вроде того. Но я не DevOps, и то как в проекте сейчас настроен Docker, - это мой максимум в этом вопросе. Наверное было бы хорошо сделать такое окружение, и настроить плагины выполнения кода и команд в этом окружении опционально. Иногда модель может путать инстанс агента с тем местом где работает, но это иногда, и возможно решается системным промптом. А вообще, как написано в пункте 2, это должно входить в обучение модели-агента. Дело не в том, что модель путает свой каталог и тот в котором работает, а в том что вообще путает. Да, в агенте есть память, но лучше такое учесть в самой модели.

Наблюдения

  1. На момент испытания были включены все три плагина выполнения кода - php, python, node. Claude чаще всего выбирает python, но если перед этим увидит что агент написан на php, то использует его (если специально подобное не оговаривать). Во время тестовых запусков в агенте присутствовал баг, при котором в контекст через placeholder шли инструкции по работе с плагинами даже теми которые отключены в админке, и когда Claude "видел" что у него в системном промпте есть описание плагина, но сам плагин отключен, он... Нет, он не мне предлагал его включить, а предлагал свои услуги, что он может разобраться и сам его включить :) Но если написать ему, что сам включишь то начинает использовать :).

  2. Модель бывает слишком уверена в своих силах (здесь конкретно про Claude), и если в работе как ассистент это даже мило :) то при работе как агент может создавать сложности. Например, отправляя команду на выполнение агенту модель считает успех по умолчанию и может повышать себе сразу дофамин, даже если результат работы команды в следующей итерации цикла будет неудовлетворительным. И надо какими то чудными путями в промпте это разруливать. Точнее модель может сама это пытаться начать разруливать, но успех этого будет зависеть от положения звезд на небе и конкретной ситуации.

  3. В продолжение предыдущего пункта, сам собой напрашивается вывод: область ответственности модели должна быть четко включена в системный промпт. Модель по умолчанию пытается решать вопрос всеми способами (а знания-то имеются), кстати, предполагая что у неё есть root доступ или пытаясь его получить. Это нормально, ведь у модели есть задача и её надо решить. Мне как человеку это симпатично, однако представить такое в продакшене конечно сложно, однако тесты на модели обученной как агент могут в корне изменить это мнение, это мой субъективный взгляд.

  4. Работа с памятью. Модель использует активно плагин memory. Это вообще узкое место. В настройках плагина memory возможно задать её максимальный размер, а я напомню, содержимое плагина memory с каждым вызовом модели идет ей в контекст. И вот если объем сделать сильно большим, то контекст будет больше размазываться, а если сделать сильно маленьким, то это будет негативно влиять на всю систему. Вопрос о конкретном оптимальном размере - это вопрос отдельного исследования. Также, в последней версии агента добавлен плагин vectormemory который является чем-то вроде базы данных знаний для модели, однако там необходимы улучшения, он исключительно экспериментальный, и модель его не сильно активно использует, но может я что то в системном промпте не так делал. А вообще вопрос размазывания контекста - один из ключевых. И когда я писал что одна из фундаметальных задач - это разгрузка системного промпта, то вот этот пункт это один из примеров - зачем.

  5. Работа с памятью - содержимое. Модель активно использует память, но оформляет в виде плана вроде "1. Разработал систему модели для проекта. 2. Разработал контроллеры для проекта" и в таком роде. Это мешает модели держать весь проект в контексте задачи, отчего над чем то крупным может работать довольно фрагментарно. Со стороны модели это возможно решить качественным дообучением, а со стороны агента - лучшей реализацией векторной памяти. У меня есть мысли поработать с самой моделью, с задачей тестирования векторной памяти, и заодно спрошу почему так не зашла :). То есть вначале модель сохраняет туда что то а потом использует нечасто. Может быть дело в системном промпте.

  6. Структура проекта. Модель старается придерживаться стандартных паттернов организации файлов, что является плюсом - никаких изобретений велосипедов, все обычно. Это говорит о том, что обучающие данные содержали достаточно примеров хорошей практики. Но если что-то не получается, может какой то тестовый условный АПИ эндпоинт иногда куда-то прикрутить :). Также, если совершает ошибку и понимает что к примеру где-то создала лишний файл, может забыть его убрать. Напомню, модель обучена как ассистент, и убирать "мусор" после своей работы обычно задача пользователя, поэтому это неудивительно.

  7. Выполнение shell команд. С этим как раз проблем минимум - модель уверенно использует стандартные команды, иногда проявляя излишнюю самоуверенность, но в целом работает стабильно. Точнее, главные проблемы не с самими shell-командами, а с вопросом, что модели позволено а что нет.

  8. Незакрытые теги команд. Или ответ модели не помещается в сообщение, или модель забывает закрывать теги. Нечасто но бывает. Также возможно разруливать в системном промпте, но это не есть хорошо. Снова же, вопрос разгрузки системного промпта модели-агента.

Заключение

Данный эксперимент был направлен на тестирование агента DepthNet в реальных условиях работы. Основная цель - понять, как современные модели-ассистенты справляются с агентскими задачами, и какие доработки нужны самому агенту. Для больших подробностей и как все проходило, снял видео и прикрепил весь диалог в разных форматах (агент умеет экспортировать диалоги).

Результаты показали, что даже модели, не обученные специально для агентской работы, могут пытаться решать практические задачи при правильно построенном окружении. Однако для реального использования потребуются либо специально обученные модели-агенты, либо существенные доработки промптинга и архитектуры, а в реальности - и то и другое совместно, потому что второе без первого будет мало эффективно.

Агент и все материалы эксперимента находятся в открытом доступе - любой может повторить тесты или провести свои исследования.

Ссылки и ресурсы

  1. Ссылка на проект агента DepthNet: https://github.com/rnr1721/depthnet

  2. Ссылка на весь диалог из этого теста агента, выложил на Google Drive: https://drive.google.com/file/d/179jAozvSmPRUEDR8e4ikJ3DyEnS7IWj4/view?usp=sharing

  3. Ссылка на видео, сильно порезал иначе было скучно смотреть: https://www.youtube.com/watch?v=SCBTbxDLWd0

Комментарии (10)


  1. Kamil_GR
    16.06.2025 16:51

    Подскажите запрос к модели идёт каждый раз в новой сессии?


    1. rnr1721 Автор
      16.06.2025 16:51

      При запросе передается контекст диалога, то есть когда идет запрос к модели, передаются предыдущие сообщения, и количество этих сообщений устанавливается в настройках. В этом смысле сессия та же.


      1. Kamil_GR
        16.06.2025 16:51

        Если я правильно помню, в апи Клода при передаче запроса возможно два варианта ключа - новая сессия и продолжение старой... Как у вас настроено?


        1. rnr1721 Автор
          16.06.2025 16:51

          В этой реализации новая сессия. Иначе было бы невозможно получить полный контроль над контекстом.


          1. Kamil_GR
            16.06.2025 16:51

            Что ж. Если я правильно понял, то в текущей конфигурации максимум в онтологическом смысле можно добиться только игры жизнь в новой упаковке.

            Но реально полезным этот проект будет в решении длительных задач.

            WORKLOG Markdown-файл (plain text) – краткий глобальный план \n– текущий чек-лист \n– ID артефактов целиком (≤ 500 ток)
            ARCHIVE векторная БД (FAISS / PGvector) все логи, длинные фрагменты кода, прошлые ответы вставляем on-demand (по similarity)

            Если LLM видит большую цель → автоматически создаёт PLAN с подзадачами.
            – Правило: «Не держи более 5 открытых TODO; иначе разбей задачу или архивируй выполненные».

            Контроль прогресса

            – После каждой итерации скрипт проверяет:
            все ли TODO закрыты? если да, задача считается решённой.
            – Метрика open_todos / total_todos

            Checkpoint-restore

            – WORKLOG периодически пишется в checkpoint-YYYYMMDD.json.
            – Если очередь падает — следующий запуск подхватывает последний чек-поинт и продолжает.

            Добавить защиту от зацикливания и сбоев и можно пробовать...


            1. rnr1721 Автор
              16.06.2025 16:51

              В будущем думаю провести эксперименты конкретно с памятью. Думаю поработать с моделью, и заодно проверить несколько стратегий. Опыт показал, что сильное усложнение стратегии управления памятью может заставлять модель забывать какие-то детали. Хотя идея планировщика для модели это интересно, это мог бы быть плагин...