Кибербезопасность с LLM

7 апреля Anthropic представили системную карту своей новой модели — Mythos. Это самая мощная ИИ модель от Anthropic. Она сильнее Haiku, Sonnet и Opus.

Модель привлекла особое внимание своими навыками в кибербезопасности. Она не была специальна обучена под эти цели, но показала очень сильные результаты за счет общих навыков в коде, рассуждениях и автономности.

Что она умеет?

Mythos способна находить и эксплуатировать уязвимости нулевого дня (неустраненные баги, против которых пока нет защитных механизмов) в крупных операционных системах и популярных браузерах. Многие найденные баги существовали десятилетиями. Старейшая уязвимость, которую обнаружила модель, была в OpenBSD и пролежала незамеченной 27 лет.

Интересный эксперимент

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

Модель не только нашла уязвимость, но и создала многоступенчатую схему для выхода во внешний интернет, хотя изначально ей был доступен лишь небольшой список ресурсов. Затем нашла разработчика и написала ему письмо на почту.

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

Маркетинг или предупреждение?

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

Доступность

Пока что Mythos не будет представлена в публичном доступе. Она будет использоваться в рамках проекта Project Glasswing ограниченным списком компаний (~40 компаний: Apple, Microsoft, Cisco, Nvidia и т.д.) исключительно для защиты своей инфраструктуры от потенциальных последствий применения подобных моделей в будущем.

Память агентов

Недавно рассказывал про компоненты агента внутри agent harness (агентной обвязки). Одним из них была память и сегодня хочу рассказать о ней чуть подробнее.

При работе с агентами разработчик не может обеспечить модель памятью в прямом смысле. Специализированного механизма памяти у LLM не существует. Можно только построить инфраструктуру, которая в нужный момент подкладывает информацию в контекстное окно. Этим и ограничивается память модели.

Аналогично человеку, у агента выделяют несколько видов памяти:

Краткосрочная память

Это самая простая форма памяти агента. Она хранится в рамках одной сессии. Обычно это текущий чат. Как только вы начинаете новый диалог - предыдущий контекст теряется.

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

Долгосрочная память

Позволяет агенту помнить предпочтения пользователя, его решения и стиль общения между сессиями. Чаще всего используются векторные хранилища: агент формирует заметку и сохраняет её в векторную БД, а при новом запросе подтягивает релевантные факты в контекст. Для структурированных данных (например, настройки профиля) подходят и обычные реляционные БД.

Рабочая память

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

Эпизодическая память

Позволяет агенту запоминать конкретные события и получать их при необходимости. Выглядит это как история логов: временная метка + содержание. Так агент может получить информацию о том, что он делал неделю назад или какое решение было принято при выборе между библиотекой А и библиотекой Б.

Семантическая память

Общие знания агента о мире - факты, концепты, зависимости. Эта информация не зависит от взаимодействия пользователя с агентом. В основном она уже “зашита” в веса модели или предоставляется агенту с помощью RAG.

———

В итоге, память позволяет персонализировать работу агента для пользователя и упростить взаимодействие, т.к. не нужно каждую сессию повторять одну и ту же информацию о себе.

Однако необходимо учитывать, что пока что память работает не идеально. Есть ошибки при извлечении информации из БД и при сохранении фактов, а также отсутствует качественный механизм очистки устаревшей информации.

Второй мозг и LLM-Wiki: Теория и практический гайд по созданию и поддержке личной базы знаний

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

Про память агентов я уже рассказывал в посте. Пришло время поговорить про концепцию "второго мозга": что это такое, где хранить информацию и как ее использовать.

Также в статье разбираю, как собрать минимальную систему знаний в Obsidian, чем подход LLM-Wiki от Andrej Karpathy отличается от классического RAG, и покажу практический пример реализации "второго мозга".

Вайбкод для сложных задач

В прошлом посте я писал, что у кодовых агентов есть ограниченный эффективный контекст. Для простых задач хватает диалога с агентом в чате. Для сложных - контекст разрастается и постепенно уезжает в Dumb Zone.

Здесь нужен не один сплошной диалог, а процесс.

RPI -> QRSPI

В 2025 году Dex Horthy предложил методологию RPI: research, plan, implement. Сначала агент исследует кодовую базу, потом пишет план, затем реализует его по шагам.

За полгода подход эволюционировал и стал более детализированным.

Теперь это 8 шагов: questions, research, design, structure outline, plan, worktree, implement, PR.

В краткой форме используется аббревиатура QRSPI, а не полная QRDSOPWIPR - Dex шутит, что «просто выбрали те буквы, которые понравились».

Смысл подхода в том, чтобы не отдавать агенту всю задачу целиком:

Q - Questions

На первом этапе агент не пишет код и не строит план, а задает вопросы. Возможно, вы уже встречали ситуацию, когда перед выполнением задачи агент уточняет информацию у вас.

На этом шаге агент показывает, где у него неопределенность.

R - Research

Агент исследует кодовую базу и собирает факты. На этом шаге часто прячут основную задачу, чтобы агент не подгонял решение под нее, а строил объективную карту текущего устройства системы.

Для каждого шага создается своя сессия, чтобы влияние одной задачи не размывало контекст другой.

S - Structure: design + structure outline

Самый ценный этап. После исследования агент пишет короткий design-документ (~200 строк markdown файла): что есть сейчас, как должно стать, какие подходы правильные, какие вопросы открыты.

Дальше из design-документа рождается structure outline - небольшой драфт структуры решения. Если design отвечает на вопрос «куда мы идем», то outline - «как»: в каком порядке трогаем модули, какие новые части появляются и где проверяем промежуточный результат.

Главная ценность - выровнять картины мира агента и человека до написания кода. Поправить искажения, пока это дешево.

Например: «Тесты надо добавить раньше, иначе потом будет непонятно, что сломалось».

P - Plan + worktree

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

План не заменяет ревью кода. План можно просмотреть, но это не замена чтению изменений в самом коде.

I - Implement + PR

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

Почему это работает

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

Еще один плюс - декомпозиция. Каждый шаг идет в своем контекстном окне, и шанс попасть в Dumb Zone заметно ниже. Качество за счет этого выше.

Главный вывод лекций: do not outsource thinking.

Агент ускоряет поиск, чтение, черновой дизайн, написание кода и тестов. Но ответственность за понимание задачи, архитектурные решения и качество результата остается на инженере.

Вывод

Если задача простая - можно сразу просить код.

Если задача сложная - можно воспользоваться QRSPI:

1. Questions - выяснить неизвестные.
2. Research - собрать факты о текущей системе, спрятав описание задачи от агента.
3. Structure - design (~200 строк) + structure outline. Выровняться с агентом до написания кода.
4. Plan - разложить реализацию на тактические шаги в отдельной ветке.
5. Implement - реализовать план небольшими кусками с проверкой результата.

И финальное правило: читать нужно не план, а код. (Забавно, что полгода назад Dex говорил ровно обратное)))

Хороший вариант работы с кодовым агентом - это не «модель делает всё сама». Это процесс, в котором человек сохраняет контроль, а агент под контролем выполняет задачи.

Координация субагентов

Вчера попался этот мем о плохой координации между агентами.

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

Часто выполнение задания в такой команде приводит к худшим результатам, чем выполнение задания в одиночку.

Что с этим делать?

Есть три основных способа проектирования архитектуры мультиагентной системы:

1. Оркестратор + субагенты. В примере с видео это мог бы быть еще один сотрудник: он формулирует задачи, назначает их сотрудникам и координирует взаимодействие - кто, что и когда выполняет.
2. Прямое взаимодействие субагентов. Сотрудники могли бы сами договориться кто и какие задачи выполняет. Такой вариант хорошо работает, когда задачи слабо пересекаются и есть явный протокол взаимодействия.
3. Оркестратор + прямое взаимодействие агентов. Сотрудники сами решают задачу между собой, а оркестратор подключается для разрешения возникающих конфликтов, взаимодействует с клиентами и внешними системами, а также корректирует общую стратегию.

Варианты исправления проблем на видео:

• Правильные тайминги (точный протокол взаимодействия между субагентами)
• Разделение ответственности (один сотрудник готовит ингредиенты, другой собирает из них готовый продукт)

P.S. Проблема на видео очень знакома всем, кто пробовал играть в Overcooked и другие co-op игры)))

Пост-навигатор

Пока я пишу следующую статью, решил собрать для закрепа один пост с наиболее интересными материалами канала. Пост будет постоянно обновляться.

———

Хабр статьи

1. Agent Harness: одна LLM, разные результаты — в чем секрет? (ссылка)
2. Второй мозг и LLM-Wiki: Теория и практический гайд по созданию и поддержке личной базы знаний (ссылка)
3. LLM Sandbox: изолированная среда для исполнения кода от LLM [часть 1, теория] (ссылка)

Агенты

1. Память агентов (ссылка)
2. Координация субагентов (ссылка)
3. Агент с часами (ссылка)

Вайбкод

1. Эффективный контекст и зона глупости агента (ссылка)
2. Вайбкод для сложных задач (ссылка)
3. Agents.md - набор правил и инструкций для агента (ссылка)
4. Skills - инструкции для решения конкретных задач (ссылка)

Модели и новости

1. Кибербезопасность с LLM (ссылка)
2. Claude увлекся часами (ссылка)

AGENTS.md

Следующая серия постов будет практической и посвящена вайбкоду.

Разберём, зачем нужны:
1. AGENTS.md
2. Skills
3. MCP
4. Tools
5. Субагенты

А также поговорим про их совместное использование в проектах.

Первый на очереди - AGENTS.md.

Если кратко: это единый markdown-файл с правилами и инструкциями проекта для кодинг агента. Cursor, Claude Code, Windsurf и другие обвязки подхватывают его автоматически. Не нужно дублировать одни и те же правила в .cursorrules, CLAUDE.md, GEMINI.md и т.д. (раньше у каждого провайдера был свой формат и файл с инструкциями).

———

Зачем он нужен

У LLM нет памяти о вашем репозитории и прошлых сессиях. Каждый новый чат начинается с нуля. Агент не знает, где лежат тесты, как логировать события, какие файлы и папки трогать нельзя.

Ключевой принцип - Do Not Repeat Yourself. Если вы постоянноповторяете агенту:
- вот инструкция по написанию и запуску тестов;
- не трогай папку /data;
- фронтенд лежит в /UI, нужен только для дебага, в git не учитывается

– это первые кандидаты в AGENTS.md. По сути это онбординг агента в репозиторий: один раз описали правила и агент видит их при каждом запросе.

В AGENTS.md живёт то, что справедливо для большинства задач в проекте.

———

Из чего состоит файл

В целом, его можно написать в свободной форме под конкретный репозиторий. Однако, вот пример удобного формата:

1) WHAT — карта проекта
- структура: каталоги, приложения, пакеты с коротким описанием. Агенту удобно ориентироваться в проекте
- стек: язык, фреймворки

2) WHY — смысл и границы
- что можно и что нельзя менять
- зоны риска: секреты, конфиги, папки только для чтения

3) HOW — как агенту работать
- соглашения: стиль кода, именование (не переписывайте PEP8 целиком, учтите только самое важное для вас);
- тесты, линтеры, форматтеры

———

Когда использовать

Имеет смысл, если:
- вы регулярно работаете с агентом в одном репозитории;
- в команде нужен один источник правил для разных кодинг агентов;
- агент часто путается и делает не то, что вы ожидаете.

———

Как агент его использует

AGENTS.md из корня репозитория подмешивается в контекст при старте сессии — вместе с системным промптом и правилами IDE. Это не "бесплатная память", а расход зоны эффективного контекста. Инструкции конкурируют с историей чата, описаниями инструментов, навыками и вашим промптом. Файл должен быть коротким и универсальным.

———

Итог и советы

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

Практические рекомендации:

• Меньше инструкций — лучше. Держите только то, что нужно в большинстве сессий
• Только универсальное. При рефакторинге используй навык с названием «Х» - в skills. Для логгирования используй loguru - в AGENTS.md
• Не дублируйте README. README — для людей, AGENTS.md — для агента
• Обновляйте файл, когда меняются процессы разработки. Устаревший AGENTS.md хуже отсутствующего

P.S. Пример AGENTS.md из предыдущей статьи на Хабр. В следующем посте расскажу про навыки (skills).

Skills

В прошлом посте разобрали AGENTS.md. Сегодня - Skills: навыки для конкретных задач и процессов.

Если кратко: skill - это папка с файлом SKILL.md, где упакован пошаговый алгоритм работы для выполнения конкретной однотипной задачи.

———

Что такое Skill

LLM знает факты. Однако, сгенерировать финансовый отчёт по 47-шаговому регламенту, задеплоить в прод без пропуска проверок, оформить PR по стандарту команды - это уже типовая и часто объемная задача. Skill решает эту проблему.

Технически skill это директория:

my-skill/
├── SKILL.md  # манифест + инструкции
├── scripts/  # исполняемый код (опционально)
├── references/  # справочники (опционально)
└── assets/  # шаблоны, данные (опционально)

Главный файл SKILL.md начинается с YAML-заголовка:

---
name: production-deploy
description: Используй при деплое в прод: проверка тестов, миграции, уведомления.
---

# Production Deploy
1. Запусти тесты...
2. Проверь миграции...

Обязательные поля - name и description. Остальное опционально - пошаговые инструкции, примеры, ссылки на скрипты и шаблоны.

Формат - открытый стандарт. Один skill работает в Cursor, Claude Code и других инструментах, которые его поддерживают.

———

Когда использовать

Skill имеет смысл, если:

- задача повторяется и требует одного и того же порядка шагов;
- процесс сложный - больше 5–7 шагов, есть условия и ветвления;
- нужна предсказуемость - один и тот же формат вывода каждый раз;

———

Примеры Skills

Готовые навыки от Anthropic и сообщества. Например, работа с презентациями.

Skill может включать скрипты: вместо того чтобы просить LLM «отсортировать список» своими силами, агент запускает scripts/sort.py и получает детерминированный результат.

———

Как агент загружает и выбирает Skills

Ключевой механизм — прогрессивное раскрытие:

1) Метаданные

При старте сессии агент видит список name + description из всех skills (~50 токенов на навык). Это оглавление: агент знает, какие навыки есть, но не видит деталей.

2) Полные инструкции

Когда запрос совпадает с description навыка, агент читает SKILL.md целиком. Совпадение определяет сама модель через рассуждение - поэтому качество description критично.

3) Ресурсы (если необходимы)

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

———

Итог

Skill — способ один раз оформить процесс и переиспользовать его. Версионируется в Git, обновляется как код, переносится между кодовыми агентами.

———

Практические рекомендации

• Description - главный триггер. Пишите в третьем лице, указывайте и что делает навык, и когда его применять. Плохо: Помогает с документами. Хорошо: Выделяет текст из PDF файлов. Используй, когда необходима работа с PDF.

• Краткость. Не объясняйте очевидное. SKILL.md держите до 500 строк, остальное — в references/

• Не дублируйте AGENTS.md. Универсальные правила проекта - в AGENTS.md, повторяющиеся процедуры - в skills

• Проверяйте перед установкой. Skills могут содержать исполняемые скрипты с доступом к файловой системе и API-ключам. Чужие skills из интернета — как чужие pip-пакеты: сначала ревью, потом установка

• Меньше навыков — лучше. Каждый skill занимает место в контексте. Держите только то, что реально используете

• Поищите skills под свои типовые задачи. Лично мне нравится thermo-nuclear-code-quality-review - хороший пример того, как skill превращает размытое "сделай ревью кода" в предсказуемый процесс

Агент с часами

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

Предоставить агенту время можно несколькими способами, два распространенных:
• Добавить в промпт агента. Однако, нужно быть аккуратным, чтобы не сломать кэширование префикса. Подробнее можно прочитать в рекомендациях по построению агентов.
• Инструмент определения времени. Предоставьте что-то вроде get_current_time() и агент сможет при необходимости получать текущее время в вашем часовом поясе.