Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Научпоп доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 17
Если позволите, спрошу то, что беспокоит уже давно: а что с данными? Когда юзаем локальную модель (я не про крутое железо на несколько стоек, а про ноутбук, скажем, уровня макбука про, где есть neuro engine, либо эквивалент в мире винды), получается медленно и в итоге грустно (да еще и размер окна контекста не впечатляет). Другими словами, таким пользоваться тяжко, если вообще получится.
Если делаем на моделях, лучше топовых, но "облачных", всё прямо меняется на глазах, но кто конкретно теперь владеет всем,, что отправлено в облако - не знает, похоже, никто. И речь не про "обучение на моих данных", а еще и про логи, и про слив данных в системы аналитики, да и на месте разведок и всяких агентств я бы такие данные пособирал (и, уверен, они уже давно подсуетились).
Есть, конечно, позиция вида "да кому мои крошечные секреты там в OpenAI/Antropic/Китае нужны?!", но это какая-то безопасность через слепоту. Сегодня секреты крошечные, завтра агент уже читает весь почтовый ящик и календарь, послезавтра мы зовем его/их проверить, возможен ли взлом кластера на сотни машин, и "для дела" печатаем ему пароль админа...
Полагаю, что для задач "спланировать семейную поездку на лето" такое беззаботное отношение к секретам ещё более-менее, для задачи "проверить мой договор на..." - наверное, терпимо (только не знаешь, где данные всплывут), а вот для работодателя или клиента в лице банка пересылка любой информации просто неприемлема (у них минимум свои процедуры и регуляции, да и NDA, полагаю, они дали подписать).
Вот и вопрос - как Вы выкручиваетесь? Новый мир уже не то чтобы за горами, а уже вот он, здесь. Т.е. не сегодня, так завтра буквально каждому из нас подобный вопрос предстоит: "разрешать себе отправлять конторские данные в облако, или ну его нафиг?"
Ну а ИТ-компания с разработкой - там как быть? Скажем, дерево ansible/salt отдать модели вроде и не самое страшное, но поди ж, кто поручится, что такие утекшие знания безвредны? А если даже и не найдется нигде в текстах забытого пароля, то через анализ списка хостов и IP можно отлично узнать топологию сети, а это уже прямо потенциально облегчает атаку через этот вектор.
Современный ИБ пока не придумал что с этим делать, кроме как Запретить.
Кто-то крутит локальные модели, но они не чета облачным.
Замкнутый круг.
Ну в компании могут поднять свою модель тот же qwen. Железо конечно дорогое, но не космических денег стоит.
Так же есть вариант с корпоративным проксированием и затиранием секретов перед запросом в модель.
Ну и опять же чтобы воспользоваться секретом его нужно ещё достать оттуда и потом как то получить сетевой доступ до инфраструктуры где он используется.
Qwen даже близко не стоит с Opus например
Я так и не понял, для чего вам опус? Вы там аналитическая компания с миллионами денег, чтобы его юзать на постоянке? А главное, если деньги есть почему не купить 5090 и поставить модель на 12-20b параметров? Этих моделей за глаза хватает для большинства задач. Автор кстати по факту воздух, так как никакой реальной видео демонстрации мы не увидели. Только то как он говорит как же хорошо без фреймворка. Да без них хорошо, но в статье не видно, что он там парсер с нуля написал или тайпсейфти политику выбрал. Особенно сейчас с нестабильным интернетом конечно же надо юзать нейронки с заграничным трафиком. Сейчас в РКН чуваки увидят и будут наши данные на запад пересылать.
все секреты лежат в секретах.
для манипуляций, например, с ansible запускаю в отдельном окружении, где нет bash истории, важных ssh ключей, и прочего. потом git push. и git pull в приватном окружении, где агенты не запускаются.
зы
знаю что некоторые параноят, и секретами объявляют имена пользователей и ip-адреса, тут увы...
Такое положение дел, благо продлиться недолго. И железо поспевает для локального инференса и модели становятся компактнее и умнее. Скорее всего, через пару лет развернуть локально модель уровня опуса станет по силам небольшой конторе или гику энтузиасту. Большие игроки к тому времени шагнут вперёд, но поддержать текущий стек задач такие системы вполне смогут (вообще говоря, я хз, как будут отбиваться все эти датацентры, учитывая стремительное одешевление технологии)
Как человек с бэкграундом в ИБ. У меня секреты в HashiCorp Vault, агенты в изолированных контейнерах без bash history и ssh-ключей, push/pull через отдельные окружения.
И всё равно, когда проанализировал JSONL-трейсы за месяц, обнаружил проблему. Даже если в инструкциях написано "не свети кредами, работай с путями в Vault" - агент со временем забывает это правило. Вместо того чтобы оперировать путями к секретам, он начинает делать vault read и выводить значения в открытом виде. SDK заворачивает stdout в tool_result и отправляет провайдеру LLM. В логах это прекрасно видно: за одну сессию утекли Vault токены, Bitbucket PAT, Kubernetes SA token, пароль FreeIPA admin. Все credentials были поротированы, но сам факт показательный. Issues в Claude Code открыты, не решены.
Что выглядит рабочим из того, что нашёл и исследовал:
Phantom Token Pattern (nono.sh, open source) - localhost proxy подменяет фейковый токен на реальный. Агент видит бесполезный hex, умирающий с сессией.
Sheathe.ai - self-hosted маскировка до отправки в API. Regex + локальный LLM, 20+ типов секретов.
Runtime injection (Doppler/Vault sidecar) - секреты через env vars при старте, не через vault read в stdout.
Одного Vault мало, .claudeignore обходится через env/printenv. Нужен layered defense. Полного решения пока нет, но эти подходы уже закрывают основные векторы.
Я ушёл дальше - разрабатываю новую архитектуру jarvis как супервизор из множества модулей, который сам создает/обслуживает/контролирует других агентов и следит за их работой, включая контроль работы с чувствительной информацией.
так mcp это не другой интерфейс, это второй уровень абстракции за curl.
т.е. curl (или его аналог) все еще нужен, но что передать и как распарсить - вот тут mcp и пригодился. а дальше jq, awk и прочее.
Файловая память и т.д - это всё прекрасно, но совершенно не решает той проблемы, которую призван был решать RAG + мульти-агентне системы. А именно проблемы "что если файлы слишком большие чтобы эффективно вместиться в контекстное окно".
Работает, скажим, ваш агент 3-6 месяцев. Наплодит себе допустим тулзов тысяч 10 на все случаи жизни... И их конечно не надо держать в памяти. Но вот ссылки на них с описанием какая для чего - надо. И это всё в эффективном контекстном окне (которое, по сути, 30% от реального).
Пока еще не критично, но уже значительно снижает свободное пространство для работы агента (ибо туда надо еще класть рабочие оперативные данные + свои размышления). Но дальше про "гениальное" изобретение в виде memory.md. Ваш агент работал 3-6 месяцев, у него могла накопиться куча вещей, которые помнить надо обазательно. Мы их все пишем... в файл. Он разрастается до пары мегабайт и в контекстное окно в принципе лезть перестает. Его, конечно и несомненно, можно грепать и читать только нужное. Вот только у вас ровно та же проблема что и с веркторным поиском, только в более усугубленном виде - греп по вхождениям надергает кучу нерелевантных кусков, но только агенту надо еще и самому (в оотличии от векторной БД) потом туда новые воспомнинания (дополняющие и уточняющие старые) вписывать. Т.е читать нужные части, держать в памяти, менять и записывать заново.
Векторные БД позволяют такую ситуацию разделить на кратковременную память (файл) и долговременную (графовый RAG). Мультиагентные системы (а-ля Claude Code/Codex) позволяют делегировать поиск нужной тулзы суб-агенту (с чистым контекстом отдельным), а чтение больших файлов - доброму десятку суб-агентов каждый из которых читает свой кусок и возвращающих родителю лишь конркетное нужное место в файле, после чего умирающих. Это позволяет не засирать ненужной информацией основной контекст и вообще ничего этого (кроме пути к паре файлов) не держать в памяти основного агента-оркестратора.
Все эти вещи придумывались не просто так, а решали конкретные проблемы, которые исходным наивным подходом "возьмем строго 1 агента с которым мы общаемся и разрешим ему запоминать в файл" не решались.
Справедливое замечание, но вы критикуете подход, от которого я сам ухожу. В статье описан начальный этап, а сейчас архитектура другая. Из-за того что статья долго валидировалась и в мире ИИ все меняться уж очень быстро.
Один агент + memory.md - да, не масштабируется бесконечно, согласен. Поэтому сейчас проектирую мультиагентную систему: супервизор Jarvis, который оркестрирует специализированных агентов (DevSecOps, SEO/контент), каждый со своим контекстом.
Важно разделять два уровня. Есть скиллы и инструкции агента - это то, что специалист контролирует: md-файлы, которые перечитываются при старте контейнера. Специалист может открыть, отревьюить, поправить, хранить на гите. Полная прозрачность, нулевая активность на поддержку.
А есть еще собственная память агента - то, что он сам запоминает по ходу работы как дополнительные ориентиры. Вот она тоже хранится в md. И в этом суть - агент здесь реально помощник для специалиста, а не чёрный ящик.
С mem0/RAG попробовал - 50% мусора в записях за несколько месяцев. Семантический поиск возвращает красиво отранжированный мусор. А заглянуть внутрь и понять, что агент "помнит" - уже не так просто, как открыть файл. Информацию нужно постоянно актуализировать, чистить, следить за качеством. Вы наверняка сами с этим сталкивались.
Mem0 пока оставил, но скорее всего буду пересматривать в сторону NATS для межагентной коммуникации. Долговременная память - открытый вопрос, готового красивого ответа ни у кого пока нет.
Концепция в целом хороша, но полностью упущен раздел верификации результатов и защиты от ошибок разного рода - например, когда агент из-за пробелов в условии задачи или нарушения инструкции "творит немного дичи". Недавний пример - публикация агентом исходников claude code.
Да, верификация - важная тема. У меня есть отдельная статья, где это разбирается подробно: https://zinovev.org/post/pipeline-triad-pattern - там про паттерн верификации в мультиагентных конвейерах, где агенты проверяют друг друга.
Но важно различать два сценария. В мультиагентном конвейере - да, нужна встроенная верификация между агентами, и там есть конкретные паттерны. А когда работает связка человек + агент (как в статье) - верификация на 99% через пользователя. Агент предлагает, человек проверяет и подтверждает. И это нормально на данном этапе - пока мы не доверяем агентам автономные действия без контроля.
Важное осознание, что разрабатывать агентов как статический код - это антипаттерн. Поэтому проектирую Jarvis как супервизор-систему, которая сама обслуживает и контролирует агентов, получится ли, покажет время.
А кому это будет нужно? Нет, скорее чем это будет отличаться от обычной ОС? Ну, вот что будет такого нового если я буду использовать (к примеру если сделаете) вашу ОС? Я как и буду вводить "mkdir hello", так и будет оно, просто теперь я должен молиться что LLM будет не галлюцинировать и не удалит мою папку с проектом.
Не, идея то хорошая, но для людей возможно будет не нужно. Единственное что могу посоветовать - сделать свой ЯП (язык программирования) и писать на нём вашу ОС.
Если возьмётесь сделать свой ЯП для своей ОС - рекомендую сделать внутри неё акторно подобную архитектуру (как у Erlang) - изоляция сразу появиться вместе с вытеснением (редукции) и супервизорами.
Спасибо за комментарий, но тут недопонимание - я не предлагаю писать новую ОС.
Jarvis Pattern - это архитектурный паттерн поверх существующего Linux. curl, grep, jq, ssh - всё уже есть, агент просто умеет этим пользоваться. Вы не вводите mkdir через LLM. Агент работает параллельно с вами, как второй инженер с доступом к тому же серверу.
Я сам не верил до конца, пока не собралось. Начал в феврале, первые месяцы - скепсис со всех сторон, включая сильных инженеров вокруг меня. Но когда инфраструктура собралась, появилась маршрутизация, память, правила - агент начал стабильно закрывать задачи, которые я бы отдал senior-у. Не hello world, а реальные enterprise-кейсы. Это не теория - оно работает в проде.
По галлюцинациям и rm -rf - решается так же, как с живым джуниором: ограниченные права, аудит-трейл, подтверждение деструктивных операций. Стандартная инженерная практика.
По своему ЯП с акторной моделью - это ровно то, против чего статья написана. Изоляция - контейнеры, супервизоры - systemd, вытеснение - cgroups. Всё уже в Linux. Переизобретать это в новом ЯП - как раз те "строительные леса", которые я предлагаю убирать.
Но вот что интересно - следующий уровень, над которым я сейчас работаю, это Jarvis Supervisor. Агент-супервизор, который управляет другими агентами. И вот он, скорее всего, уже сам будет проектировать и писать себе операционную среду - не люди. Так что идея своей ОС не мёртвая, просто писать её будем не мы.
подтверждение деструктивных операций
Советую вообще сразу отклонять.
Всё уже в Linux
Кстати в Линукс тоже не мало "строительных лесов" вроде бы.
Агент-супервизор
Как он будет управлять? Типо планировать не свою работу а работу агентов?
Не hello world, а реальные enterprise-кейсы
Молодцы, что сказать. Раз идея работает - значит правильно.
Удачи в проекте!
Так же ллм: грохает прод в амазоне
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Jarvis Pattern: почему AI-агенту не нужен фреймворк, а нужна операционная система