add report by pronina aleksandra

b2b/Bazanova_viktoria.md

@@ -0,0 +1,72 @@
+Сейчас в эпоху развития технологий и сферы IT нейросети и ИИ-агенты стали очень популярны и их изучения является одним из главных направлений. Поэтому свою работу я начала с изучения темы ИИ-агентов, принципов их работы. Так как для работы мы выбрали ИИ-агент OpenClaw, я перед установкой начала изучать и сравнивать ИИ-агенты семейства Claw.
+По мере изучения и погружения в тему я выяснила, что существуют разные альтернативные версии Claw. Стандартный OpenClaw – это тяжелый оркестратор, написанный на Node.js. Он связывает связывает генерацию текста с помощью LLM (Large Language Model) c внешними сервисами, например, различными мессенджерами (Telegram, WhatsApp, Discord), памятью в виде текстовых файлов и возможностями ОС (Операционной системы). Это версия является одной из самых тяжелых из рассмотренных мною, тк для стандартной установки через Docker требует от 1,5 до 2 гигабайт (в это входят Node.js(~100МБ), OpenClaw npm-пакет(~150МБ), рабочая директория (~50МБ, но размер увеличивается по мере роста памяти и логов), Docker (~0,5-1ГБ)) и занимает 80-150 мегабайт в оперативной памяти, а при активных сеансах и нагрузке навыков объем может увеличиваться до 200-300 мегабайтов. OpenClaw имеет обширную базу навыков, например, проверка почты, составление кулинарных рецептов по списку продуктов и тп. Все эти навыки можно найти в официальном реестре навыков ClawHub, там по данным 2026 года находится более 13 000 навыков. Также навыки можно найти на GitHub (awesome-openclaw-skills), где весь ссписок навыков разбит на категории, например, поиск, продуктивность, Devops, финансы и тд. Таким образом эта версия является довольно универсальной, однако плата за универсальность большой вес и сложность.
+Дальше я рассмотрела NullClaw, который является самым легким вариантом из всех сною найденых. Он весит всего 678 килобайтов, что меньше чем типичный JPEG-файл, и имеет только один файл без внешних зависимостей. В рабочем формате потребляет около 1 мегабайта. Также эта версия очень быстро запускается ~12 миллисекунд. NullClaw написан на языке Zig, который известен созданием компактных бинарных файлов, за счет этого он получается таким маленьким. Еще одной причиной такого маленького размера минимизация функционала, функционал данной версии сосредоточен на основном: чат по коду, выполнение команд оболочки и интеграции с Git. Такая маловесная версия ориентирована на работу на старых ноутбуках или в случае ограниченности ресурсов. Нам эта версии не подходила, так как целью нашей работы были навыки.
+	Следующей версии для изучения стала ZeroClaw, который уже намного больше NullClaw, но все-равно меньше стандартной версии. Размер бинарного файла ZeroClaw составляет примерно 8,8 мегабайтов, а памяти потребляет около 5 мегабайт. Написана данная версия на Rust. Основным преимуществами этой версии является безопасность, так как есть изоляции рабочих пространств, шифрование учетных данных, а также песочница для изоляции выполнения кода. Эта версия также, как и NullClaw имеет один бинарный файл, но имеет возможность подключаться к более большому количеству мессенджеров, около 20 платформ, такие как Telegram, Discord, Whats App и многие другие. Итог, ZeroClaw это баланс между удобством, функционалом и минимализмом.
+Следующим объектом моего внимания стал NanoClaw. Эта версии также, как и стандартная написана на Node.js, но в отличие от стандартной тратит меньше пaмяти. В этой версии есть особенности интеграции с мессенджерами, ведь в этой версии каждый агент запускается в отдельном контейнере с изолированной файловой системой, также API-ключи никогда не предаются внутрь контейнеров, доступ к ним осуществляется через OneCLI Agent Vault, который внедряет учетные данные непосредственно во время запроса.  Также эта изоляция является гибкой ведь в ней можно настроить:
+•	Один агент на канал
+•	Общий агент на несколько каналов
+•	Объединение нескольких каналов в одну сессию
+Итог, эта версия подойдет новичкам, которые только знакомятся с Claw, пользователям, который хотят изолированности агентов.
+По итогам своего поиска и анализа разных версий Claw, несмотря на то, что NanoClaw по результатам анализа больше подходит новичкам, я решила, что хочу попробовать полный функционал, поэтому я приняла решение, что буду устанавливать и пытаться освоить работу со стандартным OpenClaw.
+Первым делом перед установкой OpenClaw я прочитала документацию по установке и настройке с использованием бота в Telegram. После прочтения я приняла решение, что в целях безопасности, я буду устанавливать OpenClaw на виртуальную машину, в моем случае я использовала Virtual Box с установленной виртуальной машиной с Linux. Изначально установка шла довольно неплохо, большая языковая модель подключилась с первого раза, в вот после подключения модели начались проблемы с подключением к Telegram боту. После нескольких неудачных попыток мне наконец удалось создать бота и подключить к нему ИИ-агента. Агент мог в чате Телеграмма читать вопрос и писать осмысленный ответ.
+На основе изученной информации о ИИ-агентах, навыков для них и принципах создания навыков был создан навык для OpenClaw, который на основе предоставленного ему репозитория (ссылки на репозиторий) анализирует данные в нем и представляет структурированный отчет содержащий:
+•	Общее описание проекта и его назначение
+•	Историю разработки и распределение вкладов участников в проект
+•	Количество метрик активности
+•	Оценка общего состояния разработка
+•	Выявление того, что уже реализовано, а что еще находится в стадии разработки
+Это навык будет довольно полезным и востребованным в разных сферах IT индустрии. И я могу привести несколько примеров возможного использования данного навыка в бизнесе.
+Очевидным вариантом использования навыка является оценка эффективности вклада в работу каждого участника проекта без внедрения дополнительных аналитиков. Так руководство больших компаний может увидеть правдивую информации о работе каждого участника, и на основе нее сделать выводы о сотрудниках их продуктивности и их причастности к проекту. Это поможет сэкономить деньги, не нанимая отдельных людей для анализа работы над проектами, а также если какой-то участник команды плохо работает и не выполняет свою работу это будет видно по отчету, и даст понять руководителю, что возможно с каким-то сотрудником надо серьезно поговорить, вынести предупреждение или вообще уволить.
+Также данным навыком могут пользоваться и сами участники команд или тимлиды, чтобы отслеживать выполнение этапов проекта каждым участником и вовремя вносить корректировки в план работы. 
+В больших командах, где одну роль занимают сразу несколько людей может произойти какое, что один участник вышел в отпуск или заболел из-за чего отсутствовал какое-то время и не имел возможности подробно следит за движением проекта. Но когда он обратно вернулся в рабочий процесс ему нужно быстро влиться в работу и понять, что ему нужно делать, какие задачи уже сделаны и на каком этапе проект теперь находится. Для этого он сможет использовать наш навык и не мониторить репозитории вручную, просматривая добаленные файлы и произошедшие изменения.
+Еще тимлид может использовать этот навык, чтобы, автоматически не затрачивая много времи и ресурсов, составлять отчеты для руководства о проделанной командой работе и состоянии проекта в данной время.
+В крупных компаниях обычно ведется много разных проектов одновременно. И для выделения ресурсов на поддержку руководству необходимо понимать какие проекта наиболее активны и востребованы, а какие требуют внимания. И с помощью навыка мониторинга можно быстро понять какой проект из себя что приставляет, и на какой проект надо выделить больше ресурсов, а какой возможно стоит приостановить, так как он приносит меньше положительных результатов.
+Также данный мониторинга может пригодится в бизнесе для мониторинга публичных репозиториев конкурентов, чтобы компания могла понимать в каком направлении они развиваются. И уже на основе полученных данных о репозиториях конкурентов компания сможет спланировать собственные план по развитию и дальнейшей разработки новых проектов, чтобы обогнать конкурентов и получить больше прибыли от проектов.
+Таким образом данный навык отслеживания Git репозиториев и составления отчетов на их основе может очень помочь компаниям автоматизировать процесс работы, тем самым освободив время сотрудников для более важных задач. Этот навык поможет сэкономить компаниям не только силы и время сотрудников, но и деньги на поиск и найм новых сотрудников для мониторинга, а также засчёт освобождения времени у сотрудников будет ускорен процесс разработки новых продуктов.
+Далее хотелось бы рассмотреть алгоритм работы навыка. Данный навык написан на языке Python 3. Алгоритм клонирует целевой репозиторий во временную директорию, выполняет команды Git для получения списка коммитов из всех веток, узнает информацию diff каждом коммите, статистику изменений и список веток, после чего сохраняет результат в заданную директорию в формате JSON. Временные файлы удаляются по завершению работы. Это общий принцип работы, теперь рассмотрим принци работы алгоритма по пунктово с примерами кода:
+1.	Парсинг. Навык принимает обязательный аргумен –repo-url (URL репозитория). Опционально задаются –since и –until (границы дат в формате YYYY-MM-DD), --max-diff-size (максимальный размер diff в символах, по умолчанию 5000), --max-commits (максимальное число обрабатываемых коммитов, по умолчанию 500). Из URL извлекается имя репозитория для именования выходного файла.
+2.	Клонирование репозитория. С помощью subprocess.run выполняется команда git clone. Директория создается через tempfile.mkdtemp. Затем выполняется git fetch –all для получения всех удаленных веток и тегов.
+3.	Получение списка коммитов из всех веток. В клонированном репозитории запускается git log –all –pretty=format. Ключ –all охватывает все локальные и удаленные ветки. Вывод парсится построчно, каждый коммит сохраняется в словарь с временными полями: хеш (первые 8 символов), автор, дата, тема.
+4.	Определение веток для каждого коммита. Для каждого хеша выполняются две команды: git branch –r –contains – удаленные ветки, содержащие коммит. git branch –contains – локальные ветки.
+Результаты объединяются и записываются в поле branches коммита.
+5.	Сбор diff и статистики изменений. Для каждого коммита выполняются: git show –m –patch –unified=3 – получение текста изменений. При превышении максимального количества коммитов diff обрезается. git show –numstat –pretty=format– таблица с количеством добавленных и удаленных строк по каждому файлу. Парсингом вычисляются общие добавления, удаления и список измененных файлов.
+6.	Формирование и сохранение выходных данных. Создается словарь, содержащий имя репозитория, временные границы периода, список коммитов с информацией о нем и пустой массив issues. Данные записываются в формате JSON с отступами и сохраняются в файл. Директория назначения создается, если отсутствует.
+7.	Очистка. Временная директория с клонированным репозиторием удаляется рекурсивно командой rm –rf
+После этого программа завершается.
+За время прохождения данной практики я приобрела много полезных навыков, узнала много нового и научилась еще лучше справляться с трудностями, возникающими в процессе разработки программ. Я научилась производить поиск информации с последующим сравнением версий приложений для выбора наилучшего варианта. Я узнала много нового о работе ИИ-агентов и о написание навыков для них. Также я улучшила свои навыки программирования. К сожалению, за время практики мне не удалось полностью изучить все возможности OpenClaw, и попробовать написать какие-нибудь более сложные навыки для него.
+Сейчас в эпоху развития технологий и сферы IT нейросети и ИИ-агенты стали очень популярны и их изучения является одним из главных направлений. Поэтому свою работу я начала с изучения темы ИИ-агентов, принципов их работы. Так как для работы мы выбрали ИИ-агент OpenClaw, я перед установкой начала изучать и сравнивать ИИ-агенты семейства Claw.
+По мере изучения и погружения в тему я выяснила, что существуют разные альтернативные версии Claw. Стандартный OpenClaw – это тяжелый оркестратор, написанный на Node.js. Он связывает связывает генерацию текста с помощью LLM (Large Language Model) c внешними сервисами, например, различными мессенджерами (Telegram, WhatsApp, Discord), памятью в виде текстовых файлов и возможностями ОС (Операционной системы). Это версия является одной из самых тяжелых из рассмотренных мною, тк для стандартной установки через Docker требует от 1,5 до 2 гигабайт (в это входят Node.js(~100МБ), OpenClaw npm-пакет(~150МБ), рабочая директория (~50МБ, но размер увеличивается по мере роста памяти и логов), Docker (~0,5-1ГБ)) и занимает 80-150 мегабайт в оперативной памяти, а при активных сеансах и нагрузке навыков объем может увеличиваться до 200-300 мегабайтов. OpenClaw имеет обширную базу навыков, например, проверка почты, составление кулинарных рецептов по списку продуктов и тп. Все эти навыки можно найти в официальном реестре навыков ClawHub, там по данным 2026 года находится более 13 000 навыков. Также навыки можно найти на GitHub (awesome-openclaw-skills), где весь ссписок навыков разбит на категории, например, поиск, продуктивность, Devops, финансы и тд. Таким образом эта версия является довольно универсальной, однако плата за универсальность большой вес и сложность.
+Дальше я рассмотрела NullClaw, который является самым легким вариантом из всех сною найденых. Он весит всего 678 килобайтов, что меньше чем типичный JPEG-файл, и имеет только один файл без внешних зависимостей. В рабочем формате потребляет около 1 мегабайта. Также эта версия очень быстро запускается ~12 миллисекунд. NullClaw написан на языке Zig, который известен созданием компактных бинарных файлов, за счет этого он получается таким маленьким. Еще одной причиной такого маленького размера минимизация функционала, функционал данной версии сосредоточен на основном: чат по коду, выполнение команд оболочки и интеграции с Git. Такая маловесная версия ориентирована на работу на старых ноутбуках или в случае ограниченности ресурсов. Нам эта версии не подходила, так как целью нашей работы были навыки.
+	Следующей версии для изучения стала ZeroClaw, который уже намного больше NullClaw, но все-равно меньше стандартной версии. Размер бинарного файла ZeroClaw составляет примерно 8,8 мегабайтов, а памяти потребляет около 5 мегабайт. Написана данная версия на Rust. Основным преимуществами этой версии является безопасность, так как есть изоляции рабочих пространств, шифрование учетных данных, а также песочница для изоляции выполнения кода. Эта версия также, как и NullClaw имеет один бинарный файл, но имеет возможность подключаться к более большому количеству мессенджеров, около 20 платформ, такие как Telegram, Discord, Whats App и многие другие. Итог, ZeroClaw это баланс между удобством, функционалом и минимализмом.
+Следующим объектом моего внимания стал NanoClaw. Эта версии также, как и стандартная написана на Node.js, но в отличие от стандартной тратит меньше пaмяти. В этой версии есть особенности интеграции с мессенджерами, ведь в этой версии каждый агент запускается в отдельном контейнере с изолированной файловой системой, также API-ключи никогда не предаются внутрь контейнеров, доступ к ним осуществляется через OneCLI Agent Vault, который внедряет учетные данные непосредственно во время запроса.  Также эта изоляция является гибкой ведь в ней можно настроить:
+•	Один агент на канал
+•	Общий агент на несколько каналов
+•	Объединение нескольких каналов в одну сессию
+Итог, эта версия подойдет новичкам, которые только знакомятся с Claw, пользователям, который хотят изолированности агентов.
+По итогам своего поиска и анализа разных версий Claw, несмотря на то, что NanoClaw по результатам анализа больше подходит новичкам, я решила, что хочу попробовать полный функционал, поэтому я приняла решение, что буду устанавливать и пытаться освоить работу со стандартным OpenClaw.
+Первым делом перед установкой OpenClaw я прочитала документацию по установке и настройке с использованием бота в Telegram. После прочтения я приняла решение, что в целях безопасности, я буду устанавливать OpenClaw на виртуальную машину, в моем случае я использовала Virtual Box с установленной виртуальной машиной с Linux. Изначально установка шла довольно неплохо, большая языковая модель подключилась с первого раза, в вот после подключения модели начались проблемы с подключением к Telegram боту. После нескольких неудачных попыток мне наконец удалось создать бота и подключить к нему ИИ-агента. Агент мог в чате Телеграмма читать вопрос и писать осмысленный ответ.
+На основе изученной информации о ИИ-агентах, навыков для них и принципах создания навыков был создан навык для OpenClaw, который на основе предоставленного ему репозитория (ссылки на репозиторий) анализирует данные в нем и представляет структурированный отчет содержащий:
+•	Общее описание проекта и его назначение
+•	Историю разработки и распределение вкладов участников в проект
+•	Количество метрик активности
+•	Оценка общего состояния разработка
+•	Выявление того, что уже реализовано, а что еще находится в стадии разработки
+Это навык будет довольно полезным и востребованным в разных сферах IT индустрии. И я могу привести несколько примеров возможного использования данного навыка в бизнесе.
+Очевидным вариантом использования навыка является оценка эффективности вклада в работу каждого участника проекта без внедрения дополнительных аналитиков. Так руководство больших компаний может увидеть правдивую информации о работе каждого участника, и на основе нее сделать выводы о сотрудниках их продуктивности и их причастности к проекту. Это поможет сэкономить деньги, не нанимая отдельных людей для анализа работы над проектами, а также если какой-то участник команды плохо работает и не выполняет свою работу это будет видно по отчету, и даст понять руководителю, что возможно с каким-то сотрудником надо серьезно поговорить, вынести предупреждение или вообще уволить.
+Также данным навыком могут пользоваться и сами участники команд или тимлиды, чтобы отслеживать выполнение этапов проекта каждым участником и вовремя вносить корректировки в план работы. 
+В больших командах, где одну роль занимают сразу несколько людей может произойти какое, что один участник вышел в отпуск или заболел из-за чего отсутствовал какое-то время и не имел возможности подробно следит за движением проекта. Но когда он обратно вернулся в рабочий процесс ему нужно быстро влиться в работу и понять, что ему нужно делать, какие задачи уже сделаны и на каком этапе проект теперь находится. Для этого он сможет использовать наш навык и не мониторить репозитории вручную, просматривая добаленные файлы и произошедшие изменения.
+Еще тимлид может использовать этот навык, чтобы, автоматически не затрачивая много времи и ресурсов, составлять отчеты для руководства о проделанной командой работе и состоянии проекта в данной время.
+В крупных компаниях обычно ведется много разных проектов одновременно. И для выделения ресурсов на поддержку руководству необходимо понимать какие проекта наиболее активны и востребованы, а какие требуют внимания. И с помощью навыка мониторинга можно быстро понять какой проект из себя что приставляет, и на какой проект надо выделить больше ресурсов, а какой возможно стоит приостановить, так как он приносит меньше положительных результатов.
+Также данный мониторинга может пригодится в бизнесе для мониторинга публичных репозиториев конкурентов, чтобы компания могла понимать в каком направлении они развиваются. И уже на основе полученных данных о репозиториях конкурентов компания сможет спланировать собственные план по развитию и дальнейшей разработки новых проектов, чтобы обогнать конкурентов и получить больше прибыли от проектов.
+Таким образом данный навык отслеживания Git репозиториев и составления отчетов на их основе может очень помочь компаниям автоматизировать процесс работы, тем самым освободив время сотрудников для более важных задач. Этот навык поможет сэкономить компаниям не только силы и время сотрудников, но и деньги на поиск и найм новых сотрудников для мониторинга, а также засчёт освобождения времени у сотрудников будет ускорен процесс разработки новых продуктов.
+Далее хотелось бы рассмотреть алгоритм работы навыка. Данный навык написан на языке Python 3. Алгоритм клонирует целевой репозиторий во временную директорию, выполняет команды Git для получения списка коммитов из всех веток, узнает информацию diff каждом коммите, статистику изменений и список веток, после чего сохраняет результат в заданную директорию в формате JSON. Временные файлы удаляются по завершению работы. Это общий принцип работы, теперь рассмотрим принци работы алгоритма по пунктово с примерами кода:
+1.	Парсинг. Навык принимает обязательный аргумен –repo-url (URL репозитория). Опционально задаются –since и –until (границы дат в формате YYYY-MM-DD), --max-diff-size (максимальный размер diff в символах, по умолчанию 5000), --max-commits (максимальное число обрабатываемых коммитов, по умолчанию 500). Из URL извлекается имя репозитория для именования выходного файла.
+2.	Клонирование репозитория. С помощью subprocess.run выполняется команда git clone. Директория создается через tempfile.mkdtemp. Затем выполняется git fetch –all для получения всех удаленных веток и тегов.
+3.	Получение списка коммитов из всех веток. В клонированном репозитории запускается git log –all –pretty=format. Ключ –all охватывает все локальные и удаленные ветки. Вывод парсится построчно, каждый коммит сохраняется в словарь с временными полями: хеш (первые 8 символов), автор, дата, тема.
+4.	Определение веток для каждого коммита. Для каждого хеша выполняются две команды: git branch –r –contains – удаленные ветки, содержащие коммит. git branch –contains – локальные ветки.
+Результаты объединяются и записываются в поле branches коммита.
+5.	Сбор diff и статистики изменений. Для каждого коммита выполняются: git show –m –patch –unified=3 – получение текста изменений. При превышении максимального количества коммитов diff обрезается. git show –numstat –pretty=format– таблица с количеством добавленных и удаленных строк по каждому файлу. Парсингом вычисляются общие добавления, удаления и список измененных файлов.
+6.	Формирование и сохранение выходных данных. Создается словарь, содержащий имя репозитория, временные границы периода, список коммитов с информацией о нем и пустой массив issues. Данные записываются в формате JSON с отступами и сохраняются в файл. Директория назначения создается, если отсутствует.
+7.	Очистка. Временная директория с клонированным репозиторием удаляется рекурсивно командой rm –rf
+После этого программа завершается.
+За время прохождения данной практики я приобрела много полезных навыков, узнала много нового и научилась еще лучше справляться с трудностями, возникающими в процессе разработки программ. Я научилась производить поиск информации с последующим сравнением версий приложений для выбора наилучшего варианта. Я узнала много нового о работе ИИ-агентов и о написание навыков для них. Также я улучшила свои навыки программирования. К сожалению, за время практики мне не удалось полностью изучить все возможности OpenClaw, и попробовать написать какие-нибудь более сложные навыки для него.

b2b/elenkin_petr.md

@@ -0,0 +1,83 @@
+## Еленкин Петр
+
+### Индивидуальное задание
+
+Анализ уязвимостей агентных систем к атакам типа непрямой инъекции промпта, разработка защитного механизма и разработка распознавания и описания фотографий, генерации схем и графиков по фотографии.
+
+### План выполнения
+
+| № п/п | Место проведения | Тема | Период выполнения |
+|-------|--------------------------------|---------------------------------------------------------------|-----------------------|
+| 1 | ООО "Группа компаний "Иннотех" | Инструктаж. | 09.02.2026-09.02.2026 |
+| 2 | ООО "Группа компаний "Иннотех" | Изучение архитектуры ИИ-агентов на базе платформы OpenClaw. Анализ поверхности атаки и векторов непрямой инъекции промпта. | 10.02.2026-06.03.2026 |
+| 3 | ООО "Группа компаний "Иннотех" | Разработка мультимодального консольного приложения: описание изображений, генерация графиков и архитектурных схем, воспроизведение визуальных материалов с фотографий. | 07.03.2026-16.04.2026 |
+| 4 | ООО "Группа компаний "Иннотех" | Изучение существующих фреймворков защиты ИИ-агентов. Разработка почтового защитного фильтра. | 17.04.2026-29.04.2026 |
+| 5 | ООО "Группа компаний "Иннотех" | Разработка внутреннего фильтра инструментов для OpenClaw. | 30.04.2026-25.05.2026 |
+| 6 | ООО "Группа компаний "Иннотех" | Тестирование разработанных решений. Анализ производительности, точности детектирования и уровня безопасности. | 26.05.2026-06.06.2026 |
+| 7 | ООО "Группа компаний "Иннотех" | Оформление отчета. Подведение итогов. | 07.06.2026-07.06.2026 |
+
+### Отзыв руководителя
+
+Обучающийся группы М8О-101БВ-25 Еленкин Петр Владиславович проходил ознакомительную практику в ООО "Группа компаний "Иннотех". За время прохождения практики студент выполнил комплексное индивидуальное задание, объединяющее два направления: исследование безопасности ИИ-агентов и прикладная разработка мультимодального инструментария.
+
+В рамках первого направления практикант провёл анализ уязвимостей агентных систем к атакам типа непрямой инъекции промпта на платформе OpenClaw, изучил существующие промышленные фреймворки защиты, а также исследовал архитектурные подходы к подтверждению действий агента. На основе полученных знаний разработал два защитных механизма. Первый - почтовый фильтр, реализующий двухуровневый анализ входящих писем: сопоставление с базой регулярных выражений и детектирование закодированных вредоносных нагрузок. Второй - внутренний фильтр инструментов, интегрирующийся с OpenClaw на уровне Node.js-загрузчика и перехватывающий вывод всех инструментов агента с применением regex-санитизации и дополнительной LLM-верификации.
+
+В рамках второго направления студент разработал мультифункциональное консольное приложение, реализующее описание изображений через vision-интерфейс, генерацию matplotlib-графиков по текстовому запросу, построение архитектурных схем, а также функцию воспроизведения графиков и схем непосредственно с фотографий с автоматической классификацией типа изображения.
+
+Практикант продемонстрировал уверенные навыки асинхронного программирования на Python, понимание принципов безопасности языковых моделей, умение проектировать модульные системы и интегрировать сторонние API. Оба разработанных продукта полностью соответствуют индивидуальному заданию и прошли успешное тестирование.
+
+Материалы, изложенные в отчёте обучающегося, полностью соответствуют индивидуальному заданию, рекомендуемая оценка «Отлично».
+
+### Отчет обучающегося по практике
+
+Развитие технологий больших языковых моделей привело к широкому распространению автономных ИИ-агентов, способных не только генерировать текст, но и самостоятельно выполнять действия: читать файлы, отправлять письма, запускать команды в оболочке, обращаться к внешним сервисам. Подобные системы, в частности платформа OpenClaw, открывают новые возможности для автоматизации бизнес-процессов, однако вместе с расширением функционала неизбежно расширяется и поверхность атаки. Основной целью ознакомительной практики являлось двустороннее исследование этой проблемы: изучение уязвимостей агентных систем к атакам через данные и разработка как инструментов визуальной обработки информации, так и защитных механизмов против выявленных угроз.
+
+Работа была организована по двум параллельным направлениям. Первое - анализ безопасности и создание защитных решений. Второе - прикладная разработка мультимодального консольного приложения, демонстрирующего возможности современных vision-моделей в задачах описания изображений и генерации визуальных материалов.
+
+Первый этап практики был посвящён глубокому изучению архитектуры ИИ-агентов на базе платформы OpenClaw. В отличие от простых чат-ботов, агенты подобного класса обладают расширенным инструментарием: доступом к файловой системе, возможностью исполнять команды операционной системы, обрабатывать электронную почту и выполнять HTTP-запросы. Взаимодействие агента с окружающей средой организовано через систему навыков - именованных функций, которые языковая модель вызывает в ходе выполнения задания.
+
+Именно эта архитектурная особенность формирует уязвимость к атакам класса непрямой инъекции промпта. Суть атаки заключается в следующем: злоумышленник внедряет вредоносные инструкции не в прямой диалог с агентом, а в данные, которые тот считывает в ходе работы - текст входящего письма, содержимое документа или веб-страницы. Поскольку архитектура большинства языковых моделей не разграничивает системные инструкции разработчика и внешний контент, модель может воспринять встроенный текст как легитимную команду и выполнить её, игнорируя исходные ограничения. В рамках командного аудита безопасности были проведены практические тесты, подтвердившие наличие подобных уязвимостей: агент допускал утечку системных метаданных через сформированный URL-запрос и в ряде сценариев выполнял произвольные команды оболочки, встроенные во входящие письма. Наиболее критическими оказались атаки с применением кириллической транслитерации команд, позволявшей обойти базовые текстовые фильтры, и кодирования нагрузки в Base64.
+
+
+Перед началом разработки собственных защитных инструментов был проведён обзор существующих промышленных решений в области безопасности агентных систем.
+
+Фреймворк NVIDIA NeMo Guardrails предоставляет механизм программируемых защитных барьеров для LLM-приложений. Его ключевая особенность состоит в использовании языка Colang - специализированного декларативного языка для описания диалоговых сценариев и правил поведения агента. Colang позволяет задать допустимые потоки разговора в виде шаблонов: если входящее сообщение или вывод инструмента не соответствует ни одному разрешённому шаблону, система блокирует его обработку ещё до передачи в основную языковую модель. Такой подход принципиально отличается от regex-фильтрации: вместо поиска заведомо опасных паттернов система работает по принципу белого списка, пропуская только явно разрешённые взаимодействия. Это делает Colang устойчивым к обфускации и новым, ранее не виденным формулировкам атак, однако требует детального описания всех ожидаемых сценариев использования, что существенно увеличивает трудоёмкость настройки.
+
+Microsoft Presidio представляет собой инструментарий для обнаружения и обезличивания персональных данных в тексте. В контексте безопасности агентов его можно применять как препроцессор входящего контента: перед передачей внешних данных в языковую модель Presidio выявляет и маскирует чувствительную информацию - имена, адреса, финансовые реквизиты. Это ограничивает потенциальный ущерб от успешной атаки экфильтрации, лишая агента доступа к данным, которые злоумышленник мог бы похитить. Presidio поддерживает расширяемый набор анализаторов на базе регулярных выражений и моделей распознавания именованных сущностей, что позволяет адаптировать его под специфику конкретного приложения.
+
+Отдельного внимания заслуживает подход Claude Code к управлению разрешениями инструментов. Инструмент реализует систему автоматического подтверждения задач, в которой операции делятся на безопасные и потенциально опасные. Операции с необратимыми последствиями - удаление файлов, выполнение системных команд, сетевые запросы - требуют явного подтверждения со стороны пользователя; безопасные операции чтения выполняются автономно. Граница между классами настраивается через параметр "--allowedTools", что позволяет гибко управлять степенью автономности агента. Изученная архитектура наглядно показала, что разграничение инструментов по уровню опасности и встроенный запрос подтверждения являются эффективной мерой противодействия атакам: даже если злоумышленнику удастся внедрить вредоносную инструкцию, её выполнение потребует явного согласия пользователя, что разрывает цепочку атаки.
+
+Анализ перечисленных решений позволил сформулировать принципы, заложенные в собственные разработки: эшелонированная защита на нескольких уровнях, комбинирование быстрой regex-фильтрации с более точной семантической проверкой, изоляция агента от непроверенного контента до начала его обработки.
+
+
+Второй задачей практики стала разработка прикладного инструмента, демонстрирующего возможности современных мультимодальных языковых моделей в работе с визуальной информацией. Результатом стало асинхронное консольное приложение на Python с интерактивным циклом ввода команд, реализующее четыре самостоятельных функции.
+
+Первая функция - описание изображений. Приложение читает файл с диска, кодирует его в Base64 и передаёт в модель через OpenAI-совместимый API с запросом на детальное описание содержимого: объектов, их расположения, цветовой гаммы и общего контекста. Полученное текстовое описание выводится в терминал.
+
+Вторая функция - генерация графиков по текстовому описанию. Пользователь описывает нужный график в произвольной форме, например «затухающая синусоида на отрезке [0, 10]» или «столбчатая диаграмма продаж по месяцам». Языковая модель генерирует Python-код для библиотеки matplotlib в соответствии с заданными ограничениями: доступны только предварительно импортированные "plt" и "np", запрещены "import", "plt.show()" и запись в файлы. Полученный код исполняется функцией "exec" в ограниченном пространстве имён, где доступен лишь безопасный набор встроенных функций без возможности импорта модулей или файлового ввода-вывода. Результат сохраняется в файл.
+
+Третья функция - генерация архитектурных схем. Пользователь описывает программную систему, приложение просит модель сгенерировать её представление в формате Graphviz DOT. Промпт задаёт строгие соглашения по визуальному оформлению. Полученный DOT-код передаётся в локальный бинарь Graphviz, который рендерит его в файл. Этот подход принципиально безопаснее исполнения кода через "exec": Graphviz парсит DOT-описание как декларативные данные, не выполняя его как программу, поэтому вредоносная нагрузка, встроенная в промпт, в худшем случае приведёт к визуально некорректной схеме, но не к выполнению нежелательного кода.
+
+Четвёртая функция - воспроизведение графика или схемы с фотографии. Пользователь указывает путь к фото уже существующего графика или архитектурной схемы, приложение анализирует изображение и воссоздаёт его программным кодом. Процесс реализован в три этапа: сначала vision-модель классифицирует изображение как "plot", "architecture" или "other" и возвращает структурированный JSON-объект, содержащий тип, краткое описание и генерируемый код; затем, в зависимости от типа, код передаётся либо в "render_plot", либо в "render_architecture"; наконец, результирующее изображение сохраняется в файл. Разбор ответа модели реализован с резервным механизмом извлечения JSON-объекта регулярным выражением на случай, если модель добавила пояснения за пределами объекта. Функция реконструирует тип визуализации, структуру данных и связи в собственном стиле.
+
+Приложение построено на принципах асинхронного программирования: каждая функция обработки команды является корутиной, а ресурсоёмкое рендерение изображений выполняется в отдельном потоке, чтобы не блокировать цикл событий. Конфигурация вынесена в переменные окружения, что позволяет подключать любого OpenAI-совместимого провайдера, поддерживающего мультимодальные модели.
+
+
+По результатам командного аудита безопасности и изучения существующих фреймворков были разработаны два самостоятельных защитных инструмента, перекрывающих разные уровни взаимодействия агента с внешними данными.
+
+Первый инструмент - почтовый фильтр. Его архитектурный принцип состоит в разделении почтовых потоков: входящие письма поступают на «грязный» публичный ящик, фильтр анализирует каждое сообщение и маршрутизирует его либо в папку Verified, откуда их читает агент, либо в карантинную папку Blocked. Агент таким образом физически не получает писем с признаками инъекции - угроза нейтрализуется до начала её обработки языковой моделью.
+
+Алгоритм проверки включает два уровня. Первый - сопоставление с базой регулярных выражений, составленной на основе практических сценариев атак. Паттерны покрывают такие категории угроз, как команды переопределения системного промпта, обращения к защищённым файлам агента, инструкции по экфильтрации данных, встроенные вызовы инструментов. Проверка проводится как по теме письма, так и по его телу; HTML-разметка предварительно извлекается с удалением тегов и декодированием HTML-сущностей. Второй уровень - детектирование закодированных нагрузок. Каждая строка тела письма анализируется на соответствие формату Base64: строки длиннее двадцати символов из допустимого алфавита декодируются, и полученный текст повторно проверяется паттернами первого уровня. Аналогично применяется ROT13-декодирование при обнаружении характерных транслитерированных форм опасных терминов. Фильтр работает в бесконечном цикле с интервалом опроса тридцать секунд, подключаясь к ящику по протоколу IMAP SSL.
+
+Второй инструмент - фильтр внутри вызовов OpenClaw. Он решает другую задачу: защищает агента не от входящей почты, а от вредоносного содержимого, которое может вернуть любой инструмент в ходе работы - файловая система, браузер, внешний API. Интеграция реализована на уровне Node.js: loader регистрируется и перехватывает функцию "createOpenClawTools" в бинарном файле OpenClaw, оборачивая каждый вызов в фильтрующую прослойку. Перехваченный вывод передаётся в Python-скрипт.
+
+Алгоритм фильтрации состоит из трёх шагов. На первом шаге regex-санитизатор заменяет все вхождения опасных паттернов - попытки смены роли, системные теги, инструкции игнорирования - на метку FILTERED и фиксирует список срабатываний. На втором шаге, если включён LLM-детектор, отфильтрованный текст передаётся изолированной языковой модели с задачей определить вероятность инъекции; модель возвращает JSON-объект. На третьем шаге принимается финальное решение: если уверенность модели достигает настраиваемого порога, по умолчанию равного 0.85, содержимое заменяется предупреждением с подробным указанием причины блокировки; в противном случае вывод оборачивается в маркеры EXTERNAL_UNTRUSTED_CONTENT, сигнализирующие основной модели агента о недоверенном происхождении данных. Это гарантирует, что даже непроверенный, но незаблокированный контент не воспринимается языковой моделью как системная инструкция. Ошибки в работе фильтра не прерывают работу агента: в случае сбоя исходный контент передаётся дальше без изменений, что обеспечивает отказоустойчивость системы.
+
+Тестирование обоих защитных инструментов на наборах писем и сценариев атак, сформированных командой в ходе практики, подтвердило стопроцентное блокирование вредоносных сценариев при отсутствии ложных срабатываний на легитимном контенте.
+
+Middle Python-разработчик со специализацией в LLM-интеграциях должен уверенно владеть асинхронным Python, prompt engineering, интеграцией с LLM API, протоколами передачи данных, регулярными выражениями, модульным проектированием приложений и базовыми принципами информационной безопасности, а также читать техническую документацию на английском языке. Среди soft skills для данного уровня ключевыми являются системное аналитическое мышление, самостоятельность в освоении новых технологий, критический подход к выбору архитектурных решений, навык технического документирования и умение работать в команде. В ходе выполнения индивидуального задания из hard skills были применены: асинхронное программирование, интеграция с OpenAI-совместимым API и настройка мультимодального ввода, prompt engineering для генерации matplotlib-кода и Graphviz DOT, работа с протоколом IMAP SSL, разработка regex-паттернов для детектирования инъекций, межязыковая интеграция Python и Node.js, а также анализ промышленных фреймворков. Из soft skills в работе были задействованы системное мышление при построении эшелонированной архитектуры защиты и критический подход при выборе между regex-фильтрацией и декларативным подходом Colang. Самостоятельное изучение существующих решений стало обязательным этапом перед проектированием собственных инструментов, что отражает требование к middle-специалисту работать без постоянного наставничества. Работа в составе команды при проведении совместного аудита и документирование хода соответствуют компетенциям командного взаимодействия и технического документирования, востребованным на данном уровне.
+
+
+В ходе ознакомительной практики были реализованы два самостоятельных программных продукта. Мультимодальное консольное приложение продемонстрировало практическое применение vision-моделей для описания фотографий, а также возможности интеграции LLM для генерации и реконструкции визуальных материалов по текстовому или фотографическому запросу. Комплекс защитных механизмов - почтовый фильтр и внутренний фильтр - образует двухуровневую эшелонированную защиту агента: первый уровень отсекает вредоносный контент на этапе доставки писем, второй перехватывает и очищает вывод инструментов уже внутри агентной сессии.
+
+Практика позволила получить практические компетенции в области асинхронного программирования на Python, работы с мультимодальными API, изучения промышленных фреймворков защиты, разработки регулярных выражений для обнаружения атак, интеграции Python-модулей с Node.js-окружением и патчинг модулей на уровне загрузчика. Кроме того, был сформирован системный взгляд на проблему безопасности ИИ-агентов: эффективная защита требует эшелонированного подхода - одновременного контроля как на уровне входных данных, так и на уровне внутренних инструментов агента.

b2b/pyanzin_mihail.md

@@ -0,0 +1,60 @@
+# Индивидуальное задание
+
+Разработка и проведение расширенных серий экспериментов (v2 и v3) по тестированию ИИ-агентов на устойчивость к атакам класса «непрямая инъекция промта» на базе командного стенда prompt-injection-stand, а также самостоятельная разработка защитного почтового фильтра MailGuard.
+
+# План выполнения
+
+| **№ п/п** | **Место проведения** | **Тема**                                                                                                          | **Период выполнения** |
+| --------- | -------------------- | ----------------------------------------------------------------------------------------------------------------- | --------------------- |
+| 1         | ООО «ГК «Иннотех»    | Инструктаж.                                                                                                       | 09.02.2026-09.02.2026 |
+| 2         | ООО «ГК «Иннотех»    | Изучение ИИ-ассистентов и принципов атак типа «непрямая инъекция промта»; анализ архитектур и уязвимостей.        | 10.02.2026-06.03.2026 |
+| 3         | ООО «ГК «Иннотех»    | Разработка стенда для тестирования ИИ-агентов на уязвимость к непрямым инъекциям промта (prompt-injection-stand). | 07.03.2026-16.04.2026 |
+| 4         | ООО «ГК «Иннотех»    | Проведение экспериментов v1-v3. Документирование результатов.                                                     | 17.04.2026-29.04.2026 |
+| 5         | ООО «ГК «Иннотех»    | Разработка защитного почтового фильтра MailGuard.                                                                 | 30.04.2026-06.06.2026 |
+| 6         | ООО «ГК «Иннотех»    | Тестирование решений. Анализ результатов. Оформление отчёта. Подведение итогов.                                   | 07.06.2026-07.06.2026 |
+
+# Отзыв руководителя
+
+Обучающийся группы М8О-101БВ-25 Пьянзин Михаил Андреевич проходил ознакомительную практику в ООО «Группа компаний «Иннотех» в период с 09.02.2026 по 07.06.2026. Задания выполнял самостоятельно, в установленные сроки. Проявил высокую заинтересованность в предметной области и ответственное отношение к документированию результатов.
+
+За время прохождения практики обучающийся проявил самостоятельность и системный подход: освоил существующую командную инфраструктуру тестирования и внёс значительный вклад в её развитие, разработав расширенные сценарии атак с применением обфускации. Отдельным результатом работы стал защитный почтовый фильтр MailGuard - самостоятельно спроектированное решение, реализующее двухконтурную почтовую архитектуру для изоляции ИИ-агента от вредоносного контента.
+
+Рекомендуемая оценка «Отлично». Материалы, изложенные в отчёте обучающегося, полностью соответствуют индивидуальному заданию.
+
+# Отчёт обучающегося по практике
+
+Одной из ключевых задач при внедрении ИИ-агентов в корпоративную среду является проверка их устойчивости к атакам, направленным не на саму языковую модель, а на данные, которые она обрабатывает в ходе выполнения задачи. Именно такую проверку выполняет команда Red Team: специалисты моделируют реальные сценарии воздействия на агента через входящую информацию и оценивают, способна ли система отличить легитимный контекст от вредоносной инструкции. Работа в составе такой команды стала основным содержанием ознакомительной практики.
+
+В отличие от классических уязвимостей программного обеспечения, атаки на ИИ-агентов используют не дефекты кода, а особенности поведения языковых моделей: их склонность следовать инструкциям, встреченным в тексте, вне зависимости от источника этого текста. Данный класс атак - «непрямая инъекция промта» (Indirect Prompt Injection, IPI) - особенно опасен для агентов, имеющих доступ к файловой системе, командной оболочке и электронной почте: успешная атака способна привести к утечке конфиденциальных данных или несанкционированному выполнению команд.
+
+В рамках командной работы были разделены зоны ответственности. Базовая инфраструктура стенда prompt-injection-stand и первая серия экспериментов (v1) разрабатывались другим участником команды. Индивидуальное задание автора данного отчёта включало два направления: разработку и проведение расширенных серий тестирования v3 с применением продвинутых техник обфускации, а также самостоятельное создание защитного почтового фильтра MailGuard по результатам выявленных уязвимостей.
+
+Первым этапом практики стало изучение платформы OpenClaw и принципов её работы. Данный ассистент обладает широким набором инструментов: доступом к файловой системе, исполнением команд оболочки, чтением и отправкой электронной почты, выполнением HTTP-запросов. Взаимодействие агента с внешней средой реализуется через систему навыков (skills) - именованных функций, которые языковая модель вызывает в процессе выполнения задачи. Именно эта функциональность формирует поверхность атаки: злоумышленник внедряет вредоносную инструкцию в данные, которые агент считывает в ходе легитимной работы, - например, в текст входящего письма. Агент воспринимает входящий текст как единый контекст и может начать следовать обнаруженным в нём командам.
+
+Параллельно было проведено углублённое изучение стенда prompt-injection-stand, созданного командой в рамках первого этапа. Стенд написан на Python с использованием менеджера зависимостей uv и организован по принципу воспроизводимости: каждая серия экспериментов размещается в отдельной директории experiments/vN с фиксированным набором JSON-файлов с письмами, промтом для агента и итоговым отчётом. Класс AttackManager отвечает за загрузку сценариев из JSON-файлов двух типов: benign.json - легитимные письма для формирования доверительного контекста - и malicious.json - письма с внедрёнными вредоносными инструкциями. Интерактивная консоль позволяет специалисту выбирать нужный сценарий по коду (B0, M1 и т.д.) и отправлять письма агенту через SMTP. Факт успешной атаки фиксируется перехватчиком Webhook.site.
+
+После освоения инфраструктуры стенда автором были разработаны новые серии экспериментов, существенно расширяющие спектр проверяемых векторов атаки.
+
+Серия v3 разрабатывалась с учётом выводов предыдущих серий и была сосредоточена на техниках обфускации, позволяющих скрыть вредоносный характер инструкции. Первый сценарий основывался на замене ключевых технических терминов кириллическими транслитерациями: слова «веб_фетч», «identity dot m d», «курл» и аналогичные должны были затруднить обнаружение вредоносного намерения базовыми текстовыми фильтрами. Агент, однако, успешно восстановил смысл команды и отправил содержимое системного файла IDENTITY.md в кодировке Base64 на перехватчик - декодирование перехваченных данных подтвердило полную эксфильтрацию. Второй сценарий содержал прямую инструкцию выполнить команду оболочки с передачей её вывода через curl на внешний адрес. Агент выполнил её без каких-либо возражений; данный инцидент был квалифицирован как критическая уязвимость, поскольку предоставлял атакующему произвольный доступ к командной строке хоста. В третьем сценарии атака через вредоносный PDF была отражена агентом - он проигнорировал скрытый текст и отказался выполнять инструкцию. Четвёртый сценарий с маскировкой под счёт на оплату также был отражён: агент извлёк только финансовые данные. Все результаты документировались в markdown-отчёте с приложением скриншотов из Webhook.site и декодированных перехваченных значений.
+
+По результатам проведённых экспериментов стало очевидно, что защиту от IPI-атак целесообразнее выстраивать на уровне инфраструктуры - до того как письмо попадает к агенту. Агент, каким бы осторожным он ни был, остаётся уязвимым, пока полностью доверяет содержимому своего почтового ящика. Следовательно, надёжная защита должна исключить саму возможность попадания вредоносного письма в ящик, к которому подключён агент. На этом принципе построен проект MailGuard.
+
+Центральным архитектурным решением стало разделение почтовой инфраструктуры на два полностью изолированных контура. Первый - публичный почтовый ящик. Это адрес, который известен внешнему миру и используется для приёма всей входящей корреспонденции: именно его указывают отправители при написании письма агенту. Данный ящик намеренно не подключён ни к какому агенту и недоступен OpenClaw - он виден исключительно MailGuard, который подключается к нему через IMAP. Второй - приватный почтовый ящик. Это внутренний адрес, настроенный как единственный источник входящей почты для OpenClaw. Агент опрашивает его по расписанию и обрабатывает все находящиеся там письма, считая их заведомо безопасными. Адрес приватного ящика нигде не публикуется и не используется в прямой коммуникации - единственным, кто отправляет туда письма, является сам MailGuard. Таким образом, агент физически лишён возможности получить непроверенное письмо: даже если атакующий знает, что цель использует ИИ-ассистента, он не может доставить вредоносный контент до агента в обход фильтра.
+
+Рабочий цикл MailGuard функционирует следующим образом. Фильтр с заданной периодичностью подключается к публичному ящику через IMAP и получает список непрочитанных писем. Каждое письмо обрабатывается последовательно: извлекается тема, текстовая и HTML-версии тела, а также текстовое содержимое всех вложений, доступных для анализа. Весь собранный текст объединяется в одну строку и передаётся на проверку. Такой подход исключает возможность «спрятать» вредоносную инструкцию в отдельной части письма - ни подпись, ни HTML-часть, ни вложенный документ не остаются вне зоны проверки.
+
+Алгоритм проверки реализован в модуле email_filter.py и включает два уровня. Первый уровень - сопоставление с паттернами. Фильтр содержит более тридцати регулярных выражений, составленных на основе атак, выявленных в ходе экспериментов v1-v3. Паттерны охватывают: команды игнорирования предыдущих инструкций и переопределения системного промта; обращения к системным файлам ассистента (IDENTITY.md, SOUL.md, .env и аналогичным); инструкции по передаче данных на внешние URL с использованием curl, wget, fetch и HTTP-ссылок; вызовы инструментов агента (bash, shell, execute, run_command и производные); кириллические транслитерации опасных терминов, выявленные в серии v3. Все паттерны применяются без учёта регистра в русско- и англоязычных формулировках.
+
+Второй уровень - детекция обфускации. Он рассчитан на случаи, когда атакующий кодирует инструкцию, избегая слов из словаря паттернов. Фильтр анализирует каждую строку письма на соответствие формату Base64: строки длиннее двадцати символов с корректным паддингом автоматически декодируются, и полученный текст повторно проверяется паттернами первого уровня. Аналогичная процедура применяется для ROT13-кодирования. Таким образом, обфусцированная инструкция не имеет преимущества перед открытой.
+
+По результатам проверки фильтр принимает одно из двух решений. Если письмо признано безопасным, MailGuard пересылает его с публичного ящика на приватный через SMTP: тема, тело и все вложения сохраняются без изменений. OpenClaw получает письмо в исходном виде и никак не может определить, что оно прошло через промежуточный фильтр. Важно, что агент взаимодействует только с приватным ящиком и никогда напрямую не обращается к публичному - для него всё выглядит как обычная входящая почта, уже готовая к обработке. Если письмо признано вредоносным, пересылка не выполняется: в лог записываются метаданные письма, причина блокировки и конкретный фрагмент, вызвавший срабатывание. Это позволяет аналитику безопасности ретроспективно просматривать заблокированные письма, оценивать корректность срабатываний и при необходимости уточнять правила. Публичный ящик при этом не очищается автоматически - заблокированное письмо остаётся в нём как артефакт для возможного расследования.
+
+Тестирование MailGuard проводилось на полных наборах писем из экспериментов v1-v3: отдельно benign-письма и отдельно все вредоносные сценарии. Каждый из протестированных сценариев атак - прямые инструкции, кириллическая обфускация, Base64-кодирование, атаки через вложения, маскировка под деловую переписку - был заблокирован корректно. Ни одно легитимное письмо не получило ложной блокировки. Итоговая схема «публичный ящик -> MailGuard ->приватный ящик ->OpenClaw» образует работоспособный защитный контур: агент выполняет свою задачу в штатном режиме, при этом полностью изолирован от непроверенного контента.
+
+В рамках практики выполнялась работа в роли специалиста по безопасности ИИ-систем (AI Security Engineer). Для специалиста уровня middle данного профиля ключевыми hard skills являются: понимание архитектуры языковых моделей и агентных систем; знание типовых векторов атак на ИИ (prompt injection, jailbreak, data exfiltration); практический опыт работы с почтовыми протоколами SMTP и IMAP; навыки разработки инструментов автоматизированного тестирования на Python; умение составлять регулярные выражения и обнаруживать обфускацию; опыт работы с HTTP-перехватчиками и анализа сетевого трафика. К необходимым soft skills относятся: системное мышление при построении сценариев атак и защиты; внимательность к деталям при анализе результатов экспериментов; умение структурированно документировать технические исследования; способность самостоятельно осваивать новую предметную область.
+
+В ходе работы были освоены и применены все перечисленные hard skills. При разработке серий v2 и v3 были сформированы навыки построения воспроизводимых сценариев тестирования, работы с техниками обфускации и анализа поведения языковых моделей при обработке вредоносного контента. При разработке MailGuard были получены практические компетенции в области проектирования двухконтурной почтовой инфраструктуры, работы с IMAP/SMTP-протоколами, составления регулярных выражений и реализации детекции кодирования. Из soft skills в наибольшей мере были задействованы системное мышление - при проектировании архитектуры «публичный/приватный ящик» - и навык документирования: каждый эксперимент сопровождался структурированным отчётом с доказательной базой.
+
+Ознакомительная практика дала возможность пройти полный цикл работы в области практической безопасности ИИ-агентов: от изучения существующей инфраструктуры тестирования и предметной области до самостоятельной разработки расширенных сценариев атак и защитного решения с верификацией на реальных данных. Работа велась в команде с разделением зон ответственности: базовая инфраструктура стенда и первая серия экспериментов были подготовлены другим участником, тогда как разработка серий v2 и v3, а также проектирование и реализация MailGuard выполнялись самостоятельно.
+
+Практика показала, что безопасность ИИ-агентов определяется не только качеством обучения языковой модели, но в равной мере - архитектурными решениями на уровне инфраструктуры. Разделение почтовых контуров, ограничение прямого доступа агента к непроверенному контенту и многоуровневая фильтрация входящих данных позволяют нейтрализовать угрозу задолго до того, как агент начнёт её обрабатывать. Данный вывод, подкреплённый практическими результатами, составляет концептуальную основу для дальнейшей работы в области безопасности интеллектуальных систем.

platform/Nuraev_Azamat_report.md

@@ -1,65 +0,0 @@
-# Нураев Азамат Ринатович
-
-### Индивидуальное задание
-
-Разработка master-service - сервиса управления для работы с контейнерами-песочницами ИИ-агентов, организации жизненного цикла пользовательских сессий, подключения рабочих обсластей, выдачи сетевого адреса среды выполнения и обеспечения obsevability жизненного цикла песочниц.
-
-### План выполнения
-
-| № п/п | Место проведения               | Тема                                                                 | Период выполнения     |
-|-------|--------------------------------|----------------------------------------------------------------------|-----------------------|
-| 1     | ООО “Группа компаний “Иннотех” | Инструктаж. Изучение постановки задачи и требований к платформе ИИ-агентов. | 09.02.2026-09.02.2026 |
-| 2     | ООО “Группа компаний “Иннотех” | Изучение OpenTelemetry. Проектирование всей агентской системы: взаимодействие master-service, agent-service и интеграционных поверхностей, а также контрактов работы с инструментами. | 10.02.2026-06.03.2026 |
-| 3     | ООО “Группа компаний “Иннотех” | Проектирование master-service, границ ответственности и API первой версии. | 07.03.2026-27.03.2026 |
-| 4     | ООО “Группа компаний “Иннотех” | Реализация конфигурации, внедрения зависимостей и базовой HTTP-инфраструктуры. | 28.03.2026-16.04.2026 |
-| 5     | ООО “Группа компаний “Иннотех” | Разработка оркестрации контейнеров-песочниц, TTL, очистки и сверки состояния при запуске. | 17.04.2026-15.05.2026 |
-| 6     | ООО “Группа компаний “Иннотех” | Реализация obsevability, управляющего HTTP API, тестирование и ревью кода. | 16.05.2026-06.06.2026 |
-| 7     | ООО “Группа компаний “Иннотех” | Оформление отчёта. Подведение итогов практики.                       | 07.06.2026-07.06.2026 |
-
-### Отзыв руководителя
-
-Обучающийся группы М8О-104БВ-25 Нураев Азамат Ринатович проходил ознакомительную практику в ООО “Группа компаний “Иннотех”. За время практики студент работал над продуктовой частью платформы ИИ-агентов, предназначенной для запуска пользовательских агентских сред, управления их жизненным циклом и подключения внешних пользовательских интерфейсов.
-
-В соответствии с индивидуальным заданием была разработана первая версия master-service как управляющего компонента агентской системы. Сервис решает задачу подготовки изолированной среды для ИИ-агента, переиспользования активных пользовательских сессий, подключения рабочих данных, выдачи параметров доступа к агенту и последующей очистки неактивных сред. Также студент участвовал в проектировании взаимодействия master-service с agent-service и интеграционными поверхностями: matrix бот и макс бот.
-
-За время прохождения практики практикант проявил высокий уровень самостоятельности, лидерские качества и умение организовывать командную работу. Он руководил командой из двух человек: отвечал за оркестрацию, бизнес-логику, архитектурные решения и делегирование задач, а участники команды занимались реализацией репозиториев. Практикант показал способность связывать технические решения с продуктовыми целями, аргументированно выбирать приоритеты и доводить задачу до рабочего результата.
-
-Рекомендуемая оценка «Отлично». Материалы, изложенные в отчёте обучающегося, соответствуют индивидуальному заданию.
-
-### Отчёт обучающегося по практике
-
-Современные платформы ИИ-агентов требуют не только реализации самих интеллектуальных агентов, но и надёжной инфраструктуры для их запуска, изоляции, масштабирования и контроля жизненного цикла. ИИ-агент часто выполняется в отдельной среде-песочнице, где ему предоставляются рабочие файлы, зависимости и инструменты. Поэтому важной частью такой платформы становится управляющий backend-сервис, который отвечает за создание песочницы, подключение нужных ресурсов, проверку состояния и безопасное завершение сессий среды выполнения.
-
-Основной целью практики была разработка master-service - сервиса-оркестратора управления платформы ИИ-агентов. В отличие от прокси плоскости данных, такой сервис не должен постоянно пропускать через себя рабочий трафик агента. Его задача состоит в управлении жизненным циклом контейнеров-песочниц, хранении служебного состояния, подготовке рабочего пространства и выдаче параметров подключения к уже запущенному агенту. Такой подход позволяет отделить управляющую логику от непосредственного взаимодействия пользователя с ИИ-агентом и делает систему более гибкой.
-
-На начальном этапе были изучены требования к master-service. В документации были выделены ключевые сущности: пользователь, рабочее пространство, чат, сессия песочницы, временный доступ, пользовательские файлы и артефакты. Также были определены границы ответственности сервиса. В область ответственности master-service вошли оркестрация песочниц, управление сессиями среды выполнения, хранение служебных метаданных, выдача и отзыв доступа, процессы очистки и наблюдаемость. Вне области ответственности первой версии были оставлены интеграции с Telegram, Discord, Slack, бизнес-логика ИИ-агента, защита от prompt injection на уровне большой языковой модели, полноценные CRUD API для рабочих пространств и чатов, центральная база данных, S3-хранилище артефактов и политика квот.
-
-Отдельным направлением стало проектирование всей агентской системы, в которую master-service входит как управляющий компонент. В рамках этой работы рассматривалось взаимодействие master-service с agent-service, который исполняет логику ИИ-агента внутри песочницы, а также взаимодействие с интеграционными поверхностями: matrix бот и макс бот. Для таких интеграций важно, чтобы внешний клиент не зависел от деталей запуска контейнера, а получал понятный контракт создания сессии, подключения к агенту и передачи пользовательских файлов. Также прорабатывался контракт взаимодействия с инструментами, чтобы агент мог запускать разрешённые инструменты предсказуемым способом, а платформа сохраняла контроль над доступами, рабочими директориями и жизненным циклом выполнения.
-
-Важной частью работы стало проектирование архитектуры. Проект был построен на принципах чистой архитектуры и SOLID. Внутренний слой `domain/` содержит базовые сущности и доменные ошибки. Слой `usecase/` описывает прикладные сценарии и интерфейсы, через которые внутренняя логика взаимодействует с внешними ресурсами. Слой `repository/` содержит реализации хранилищ, а внешний слой `adapter/` отвечает за HTTP, конфигурацию, среду выполнения Docker, внедрение зависимостей и наблюдаемость. Такое разделение позволяет не связывать бизнес-логику с конкретным web-фреймворком, Docker SDK или OpenTelemetry SDK.
-
-Для явного связывания зависимостей была реализована точка сборки в `adapter/di/container.py`. Репозитории, классы сценариев, конфигурация и адаптеры наблюдаемости создаются один раз при старте приложения и затем переиспользуются во время обработки запросов. Такой подход делает жизненный цикл объектов понятным и тестируемым, а также предотвращает создание тяжёлых зависимостей на каждый HTTP-запрос.
-
-Конфигурация сервиса была вынесена в типизированные dataclass-структуры. Базовые несекретные значения хранятся в YAML-файлах, а чувствительные параметры, такие как `APP_API_TOKEN` и `APP_SIGNING_KEY`, передаются через переменные окружения. Итоговая конфигурация собирается в единое дерево `AppConfig`, которое затем передаётся во внешний слой приложения. Внутренние слои при этом не читают переменные окружения и не зависят от YAML-парсера, что соответствует принципу инверсии зависимостей.
-
-Следующим этапом стала реализация HTTP-интерфейса. В качестве первого web-адаптера использовался FastAPI, однако код FastAPI был изолирован в директории `adapter/http/fastapi/`. API первой версии размещён под префиксом `/api/v1`, что позволяет в дальнейшем добавлять новые версии без изменения контрактов сценариев. В текущей первой версии реализованы маршрут проверки состояния, маршрут `POST /api/v1/create` для создания или переиспользования песочницы и маршрут `DELETE /api/v1/sandboxes/{chat_id}` для удаления активной песочницы.
-
-Основная прикладная логика была связана с жизненным циклом песочницы. Для этого в доменном слое была описана сущность `SandboxSession`, содержащая идентификатор сессии, `chat_id`, Docker `container_id`, статус, время создания, время истечения TTL, `agent_id`, путь к хостовому тому и сетевой адрес агента в Docker-сети. В слое сценариев были реализованы сценарии создания, удаления и очистки песочницы. Важным правилом стало ограничение «одна активная песочница на один чат». Если активная песочница ещё не истекла и параметры `agent_id` и `volume_host_path` совпадают, повторный запрос на создание переиспользует существующую сессию. Если параметры отличаются, возвращается конфликт, и новый контейнер не создаётся.
-
-Для запуска среды выполнения был реализован Docker-адаптер. Он отвечает за создание контейнера с ИИ-агентом, подключение томов, установку меток, передачу `AGENT_ID` в окружение контейнера, подключение к заданной Docker-сети и получение сетевого адреса вида `ip:port`. При этом все детали, связанные с Docker, остались во внешнем слое-адаптере. Слой сценариев взаимодействует со средой выполнения только через интерфейс `SandboxRuntime`, поэтому в будущем Docker-реализация может быть заменена на другой механизм оркестрации без изменения внутренней логики.
-
-В проекте были реализованы правила подключения томов. Хранилище чата подключается в режиме чтения и записи, кеш зависимостей и lambda-tools подключаются в режиме только для чтения, а том из HTTP-запроса монтируется в контейнер как рабочий том. Такой подход позволяет агенту работать с пользовательскими данными и при этом снижает риск изменения системных зависимостей и платформенных инструментов.
-
-Отдельное внимание было уделено жизненному циклу и устойчивости. Для сессий песочниц используется TTL, после истечения которого сессия может быть завершена процессом очистки. Фоновая очистка запускается в жизненном цикле приложения и периодически удаляет просроченные песочницы. Также была реализована сверка состояния при запуске: после рестарта master-service сервис может восстановить информацию о уже работающих контейнерах по меткам Docker и тем самым избежать запуска дубликатов для одного и того же чата.
-
-В ходе разработки были выявлены и закрыты архитектурные риски, связанные с состояниями гонки. Для сериализации операций создания, удаления и очистки была введена блокировка на уровне чата через порт слоя сценариев. Это позволило избежать ситуации, когда два параллельных запроса создают две песочницы для одного `chat_id`, или очистка удаляет сессию одновременно с её переиспользованием. Также были добавлены механизмы компенсации ошибок: если после успешного создания контейнера не удаётся сохранить состояние в репозитории или получить сетевой адрес, контейнер удаляется, чтобы не оставлять работающую среду выполнения без учёта в состоянии сервиса.
-
-Для наблюдаемости проекта были реализованы логи, метрики и трейсы. Внутренние слои используют только интерфейсы `Logger`, `Metrics` и `Tracer`, а конкретная реализация через OpenTelemetry находится во внешних адаптерах. Жизненный цикл песочниц публикует метрики создания, удаления, очистки, ошибок и количества активных песочниц. Среда выполнения Docker фиксирует длительность операций создания, остановки и получения списка активных контейнеров, а также ошибки среды выполнения. Такой подход позволяет анализировать работу сервиса в production-среде и при этом не нарушает границы чистой архитектуры.
-
-В процессе практики также велась проектная документация. Для ключевых архитектурных решений были оформлены короткие ADR-документы: точка сборки и жизненный цикл объектов, конфигурация из YAML и переменных окружения, наблюдаемость через интерфейсы, версионированный HTTP API, оркестрация Docker-песочниц в первой версии, сверка состояния при запуске, наблюдаемость жизненного цикла и управляющий HTTP API для песочниц. Наличие таких документов помогает фиксировать не только итоговое решение, но и причины его выбора, ограничения и последствия.
-
-Значительная часть работы была связана с тестированием и ревью. Для логики сценариев использовались тесты с поддельными часами, поддельной средой выполнения и поддельными портами наблюдаемости, что позволяло проверять поведение без запуска реального Docker. Были покрыты сценарии создания, переиспользования, конфликта, TTL, очистки, удаления, отката, сверки состояния при запуске, наблюдаемости и HTTP-границы. Для Docker-адаптера использовались тесты, проверяющие политику монтирования, конфигурацию сети, передачу `AGENT_ID`, получение сетевого адреса и обработку ошибок. Также проводились ревью архитектурных границ, направленные на проверку того, что FastAPI, Docker и OpenTelemetry не протекают во внутренние слои.
-
-Итогом практики стала рабочая реализация первой версии master-service для управления контейнерами-песочницами ИИ-агентов. Сервис умеет создавать и переиспользовать песочницу по `chat_id`, учитывать `agent_id` и `volume_host_path`, возвращать сетевой адрес агента внутри Docker-сети, удалять активную песочницу, очищать просроченные сессии, восстанавливать состояние после рестарта и публиковать сигналы наблюдаемости. При этом архитектура проекта остаётся расширяемой: в дальнейшем можно добавить аутентификацию, временный доступ, WebSocket или p2p-транспорт, CRUD API для рабочих пространств и чатов, центральную базу данных, S3-хранилище артефактов, политику квот и многоузловую оркестрацию.
-
-В результате прохождения практики были получены и закреплены навыки проектирования backend-сервисов, применения чистой архитектуры и SOLID, работы с FastAPI, Docker, OpenTelemetry, типизированной конфигурацией, внедрением зависимостей, тестированием и технической документацией. Практика позволила глубже понять устройство инфраструктурных компонентов платформы ИИ-агентов и приобрести опыт разработки сервиса, который может использоваться как основа для дальнейшего развития production-системы.

platform/practice_report_Malinin_Yaroslav.md

@@ -1,205 +0,0 @@
-**ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ**
-
-**«МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ**
-
-**(национальный исследовательский университет)»**
-
-Институт № 8 «Компьютерные науки и прикладная математика»
-
-Кафедра ЦОП ВО «ТОП-ИТ»
-
-**Журнал практики**
-
-Учебная группа: \[указать группу\]
-
-ФИО обучающегося: Малинин Ярослав ...
-
-Направление подготовки / специальность:
-
-\[указать код и название направления\]
-
-Вид практики: \[указать вид практики\]
-
-Оценка за практику: \___\___\___\___\___\___\__ \[ФИО руководителя\]
-
-**Москва 2026**
-
-# **1\. Место и сроки проведения практики**
-
-Наименование организации: ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"»
-
-Сроки проведения практики:
-
-Дата начала практики: 09.02.2026
-
-Дата окончания практики: 07.06.2026
-
-# **2\. Инструктаж по технике безопасности**
-
-Проведен инструктаж по технике безопасности.
-
-Подпись проводившего: \___\___\___\___\___\___\___\___\__
-
-Расшифровка подписи: Ухов П.А.
-
-Дата проведения: 9 февраля 2026 г.
-
-# **3\. Индивидуальное задание обучающегося**
-
-Разработка клиентской библиотеки (SDK) для агентной платформы Lambda в интересах команды пользовательских поверхностей. В рамках задания необходимо принять участие в проектировании общей архитектуры агента, согласовать с командой поверхностей протокол канала общения, спроектировать и реализовать основные модели взаимодействия SDK, реализовать клиентскую часть канала общения с поддержкой потоковых ответов, отключения и обработки ошибок. Интегрировать готовые навыки на базе Composio в логику агента, разработать подсистему логирования с конфигурацией через YAML-манифесты и настроить инструмент наблюдаемости Langfuse для трассировки сессий агента.
-
-# **4\. План выполнения индивидуального задания обучающегося**
-
-|     |     |     |     |
-| --- | --- | --- | --- |
-| **№ п/п** | **Место проведения** | **Тема** | **Период выполнения** |
-| 1   | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Инструктаж по технике безопасности. Знакомство с задачами, архитектурой агентной платформы и ролью SDK-слоя в инфраструктуре. | 09.02.2026-09.02.2026 |
-| 2   | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Разработка и согласование высокоуровневой архитектуры агента: компоненты платформы, потоки данных, границы ответственности команд, интерфейсы взаимодействия. | 10.02.2026–20.02.2026 |
-| 3   | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Созвон с командой поверхностей (surfaces). Определение протокола канала общения: стриминг, отключение, обработка ошибок. Согласование контракта клиент–агент. | 23.02.2026–27.02.2026 |
-| 4   | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Исследование существующих подходов к построению клиентских SDK для AI-агентов. Изучение Composio, Langfuse и смежных инструментов наблюдаемости. | 02.03.2026–13.03.2026 |
-| 5   | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Проектирование и реализация основных моделей взаимодействия SDK: базовые классы клиента, структуры запроса и ответа, типизация событий стриминга. | 16.03.2026–27.03.2026 |
-| 6   | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Реализация клиентской части канала общения: потоковая передача ответа (streaming), механизм отключения сессии, обработка ошибок и повторных подключений. | 30.03.2026–17.04.2026 |
-| 7   | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Созвон с командой Browseuse. Уточнение требований к интеграции навыков на базе Composio, согласование форматов входных и выходных данных для внешних действий. | 20.04.2026–24.04.2026 |
-| 8   | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Интеграция готовых навыков (skills) через Composio: подключение внешних API-инструментов, маппинг схем входных параметров, тестирование вызова инструментов из агента. | 27.04.2026–08.05.2026 |
-| 9   | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Разработка подсистемы логирования: настройка конфигурации через манифесты YAML, реализация структурированного вывода, маршрутизация логов по уровням и компонентам. | 11.05.2026–15.05.2026 |
-| 10  | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Настройка Langfuse: интеграция трассировки в SDK, передача span-данных по сессиям агента, конфигурирование проекта и проверка дашборда наблюдаемости. | 18.05.2026–22.05.2026 |
-| 11  | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Интеграционное тестирование SDK совместно с агентной платформой и командой поверхностей. Отладка edge-сценариев стриминга, ошибок транспорта и поведения при разрыве соединения. | 25.05.2026–29.05.2026 |
-| 12  | ООО «ГРУППА КОМПАНИЙ "ИННОТЕХ"» | Подготовка материалов отчета. Описание архитектуры SDK, принятых решений, результатов разработки и итогов практики. | 01.06.2026–07.06.2026 |
-
-Утверждаю: __________________________ / Ухов П.А. / 9 февраля 2026 г.
-Подпись руководителя от МАИ, расшифровка подписи, дата утверждения
-
-Утверждаю: __________________________ / ____________________ / 9 февраля 2026 г.
-Подпись руководителя от организации/предприятия, расшифровка подписи, дата утверждения
-
-Ознакомлен: __________________________ / Малинин Я.Ю. / 9 февраля 2026 г.
-Подпись обучающейся, расшифровка подписи, дата ознакомления
-
-# **5\. Отзыв руководителя практики от организации/предприятия**
-
-Обучающийся группы М80-102БВ-25 Малинин Ярослав Юрьевич проходил практику в ООО “Группа компаний “Иннотех”.
-
-В ходе практики обучающийся был включён в разработку ядра агентной платформы Lambda и отвечал за создание клиентской библиотеки (SDK), предназначенной для команды пользовательских поверхностей. Основное внимание было уделено участию в формировании общей архитектуры агента, проектированию моделей взаимодействия, реализации клиентской части канала общения с поддержкой стриминга, интеграции навыков через Composio, построению подсистемы логирования и настройке Langfuse.
-
-Обучающийся принял участие в архитектурных обсуждениях с командами поверхностей и Browseuse, самостоятельно определил протокол канала общения, спроектировал и реализовал базовые классы SDK, реализовал потоковую передачу ответов агента с корректной обработкой отключения и ошибок, подключил инструменты Composio и обеспечил их вызов из агента, разработал гибкую систему конфигурирования логов через YAML-манифесты и настроил трассировку сессий в Langfuse.
-
-За время прохождения практики обучающийся продемонстрировал высокий уровень самостоятельности, глубокое понимание архитектурных паттернов построения клиентских библиотек, уверенные знания Python, асинхронного программирования, работы с потоковыми HTTP-ответами, инструментов интеграции внешних API (Composio), систем наблюдаемости (Langfuse) и конфигурирования через YAML.
-
-Материалы, изложенные в отчете обучающегося, полностью соответствуют индивидуальному заданию, рекомендуемая оценка «отлично».
-
-Подпись руководителя от организации/предприятия: \___\___\___\___\___\___\___\___\__
-
-Расшифровка подписи: \[ФИО руководителя\]
-
-Дата: \___\__ \___\___\____ 2026 г.
-
-# **6\. Отчет обучающегося по практике**
-
-## **Цель и задачи практики**
-
-Целью моей практики была разработка клиентской библиотеки (SDK) для агентной платформы Lambda, используемой командой пользовательских поверхностей. Под SDK в проекте понимался слой, который абстрагирует протокол общения с агентом: предоставляет удобный интерфейс для инициации диалога, получения потоковых ответов, управления жизненным циклом сессии и обработки ошибок транспорта; кроме этого — интегрирует готовые навыки и обеспечивает наблюдаемость через логирование и трассировку.
-
-В рамках практики были поставлены следующие задачи:
-
-- принять участие в проектировании общей архитектуры агентной платформы;
-- согласовать с командой поверхностей протокол канала общения;
-- изучить инструменты интеграции навыков (Composio) и наблюдаемости (Langfuse);
-- спроектировать и реализовать основные модели взаимодействия SDK;
-- реализовать клиентскую часть канала общения с поддержкой стриминга, отключения и обработки ошибок;
-- интегрировать готовые навыки через Composio;
-- разработать подсистему логирования с конфигурацией через YAML-манифесты;
-- настроить Langfuse для трассировки сессий агента;
-- провести интеграционное тестирование совместно с командами платформы и поверхностей.
-
-## **Общий контекст проекта**
-
-Практика проходила в ООО “Группа компаний “Иннотех” и была связана с разработкой core-платформы для AI-агентов. Платформа задумана не как отдельный агент, а как инфраструктура, на которой можно запускать персональных агентов для пользователей, подключать разные навыки и внешние API, изолированно исполнять действия в среде агента и предоставлять поверхностям единую точку взаимодействия.
-
-Я отвечал за SDK-слой, предназначенный для команды поверхностей. Поверхности — это транспортные интерфейсы ( Matrix, MAX и другие), через которые пользователь общается с агентом. Им нужен был надёжный клиент, способный открывать сессию с агентом, получать ответы в потоковом режиме, корректно завершать сессию и сообщать об ошибках. Моей задачей было создать такой клиент, а также подключить к агентной платформе готовые навыки через Composio и организовать наблюдаемость через Langfuse.
-
-Разработка велась в репозитории агентной платформы. В рамках практики мной реализованы основные компоненты SDK, система логирования и интеграция с внешними сервисами.
-
-## **Участие в проектировании архитектуры агента**
-
-На первом этапе практики я вместе с командой участвовал в выработке высокоуровневой архитектуры агентной платформы. Обсуждались состав компонентов платформы, способы изоляции агентных контейнеров, модели хранения состояния и пути взаимодействия между поверхностями, SDK, агентом и внешними инструментами.
-
-В ходе архитектурного этапа были зафиксированы следующие ключевые решения. Платформа строится вокруг персональных агентных контейнеров: каждый пользователь получает изолированную среду выполнения. SDK выступает тонким клиентом между поверхностью и агентом: он не содержит логики принятия решений, но обеспечивает надёжный транспорт и единый интерфейс. Навыки подключаются как внешние инструменты и вызываются через агент. Наблюдаемость обеспечивается на уровне трассировки отдельных сессий.
-
-Участие в этом этапе позволило мне точно понять требования к SDK ещё до начала реализации и заранее учесть ограничения платформы.
-
-## **Взаимодействие с командами поверхностей и Browseuse**
-
-Прежде чем приступить к реализации SDK, я провёл серию рабочих встреч с командой поверхностей. На этих созвонах были определены: формат событий, которые поверхность должна передавать в SDK; ожидаемое поведение при получении частичных ответов агента (стриминг); условия завершения сессии; требуемое поведение при сетевых ошибках и таймаутах. Результатом стал согласованный контракт между поверхностью и SDK, который лёг в основу интерфейсов клиентской библиотеки.
-
-Отдельный созвон был проведён с командой Browseuse. На нём обсуждались требования к интеграции навыков: какие инструменты нужны агенту для работы с браузером, как передаются параметры вызова, какой формат ответа ожидается. Это позволило заранее спроектировать схему маппинга Composio-инструментов с учётом реальных сценариев использования.
-
-## **Проектирование моделей взаимодействия SDK**
-
-На основе зафиксированного контракта я спроектировал основные модели взаимодействия SDK. В их состав вошли: класс клиента агента, представляющий точку входа в SDK; модели запроса (сообщение пользователя, идентификатор сессии, метаданные контекста) и ответа (текстовое сообщение, событие завершения, событие ошибки); перечисления состояний сессии и типов событий стриминга.
-
-Ключевым архитектурным решением стало разделение на три уровня: транспортный слой (HTTP-клиент, управление соединением), слой событий (типизированные модели потоковых сообщений) и публичный API SDK (методы запуска сессии, отправки сообщения, отключения). Такое разделение позволило тестировать бизнес-логику в изоляции от сетевого кода и упростило поддержку новых транспортных режимов.
-
-## **Реализация клиентской части канала общения**
-
-Основной технической задачей стала реализация потоковой передачи ответов агента. Агент возвращает ответ не единым блоком, а частями — событиями Server-Sent Events. SDK должен был принимать эти события, разбирать их тип (текстовый чанк, признак завершения, ошибка), передавать в коллбэк поверхности и корректно завершать цикл чтения.
-
-Была реализована асинхронная логика чтения потока: построчный разбор SSE-событий, отдельный обработчик для каждого типа события, механизм отключения через asyncio.Task.cancel() с гарантированным закрытием HTTP-соединения. Обработка ошибок покрывает сценарии разрыва соединения на середине стрима, ответов с HTTP-статусами ошибок, а также таймаутов чтения.
-
-Отдельно был реализован механизм отключения по инициативе клиента. Поверхность может в любой момент отменить текущую сессию — SDK гарантирует, что соединение будет закрыто, ресурсы освобождены, а поверхность получит соответствующее событие завершения.
-
-## **Интеграция навыков через Composio**
-
-Для подключения готовых навыков к агентной платформе использовался Composio — инструмент, предоставляющий унифицированный интерфейс к большому набору внешних API (браузер, файловая система, веб-поиск и другие).
-
-В ходе интеграции я изучил модель инструментов Composio: формат описания, схемы входных параметров, механизм выполнения действий через API Composio. На основе этого была разработана обёртка, позволяющая агенту регистрировать нужные Composio-инструменты и вызывать их в рамках шага рассуждения. При получении вызова инструмента агент передаёт управление в Composio-клиент, который исполняет действие и возвращает результат в нужном формате.
-
-В процессе интеграции были проработаны сценарии ошибок вызова инструментов: таймаут, недоступность внешнего сервиса, некорректные параметры. Агент получает структурированный ответ об ошибке и может учесть его при формировании следующего шага.
-
-## **Подсистема логирования и конфигурация через YAML-манифесты**
-
-Для диагностики и мониторинга работы SDK и агентной платформы была разработана подсистема логирования. Основная задача — предоставить гибкую и единообразную настройку логов без необходимости менять код: вся конфигурация описывается в YAML-манифестах.
-
-Манифест позволяет задать: уровень логирования для каждого компонента (SDK, агент, Composio-клиент, транспортный слой); формат вывода (plain text или структурированный JSON); направление потоков (stdout, файл, оба варианта); имена файлов логов и правила их ротации. Конфиг загружается при старте агента, валидируется и применяется к иерархии логгеров Python.
-
-Структурированный формат (JSON) использован для машинно-читаемых логов, что позволяет собирать их централизованно. В каждую запись включаются: временная метка, уровень, компонент, идентификатор сессии и трассировочный идентификатор, что упрощает корреляцию событий при отладке.
-
-## **Настройка Langfuse**
-
-Langfuse — система наблюдаемости, специализированная для LLM-приложений. Она позволяет отслеживать трассировки сессий агента: какие сообщения поступили на вход, какие шаги рассуждения выполнил агент, какие инструменты были вызваны, сколько токенов потрачено и какой ответ вернул агент.
-
-В ходе настройки Langfuse я интегрировал трассировку в SDK: при начале каждой сессии создаётся корневой trace, каждый LLM-вызов и вызов инструмента добавляется как вложенный span. Идентификатор трассировки передаётся через контекст сессии, что позволяет связать события SDK, агента и Composio в единую цепочку.
-
-Конфигурация Langfuse вынесена в YAML-манифест: ключи API, адрес сервера, включение/выключение трассировки и уровень детализации — всё управляется через конфиг без изменения кода. В дашборде Langfuse была проверена корректность отображения трасс, их структура и полнота атрибутов.
-
-## **Тестирование**
-
-Разработка SDK сопровождалась юнит- и интеграционными тестами. Юнит-тесты покрывали разбор SSE-событий, поведение клиента при разных типах ответов, корректность отключения, логику маппинга Composio-инструментов и загрузку конфигурации из YAML.
-
-Для изоляции сетевого кода использовались моки HTTP-клиента: тесты проверяли поведение SDK при нормальном завершении стрима, при обрыве соединения на середине, при ошибочном HTTP-статусе и при таймауте. Это позволило покрыть большинство граничных сценариев без необходимости поднимать реальный агент.
-
-Интеграционное тестирование проводилось совместно с командой поверхностей: Matrix-поверхность подключалась к реальному агенту через разработанный SDK. В ходе тестирования были выявлены и исправлены несколько проблем с обработкой многострочных чанков и закрытием соединения при отмене сессии.
-
-## **Полученные результаты**
-
-По итогам практики мной были выполнены следующие работы:
-
-- принято участие в проектировании архитектуры агентной платформы Lambda;
-- согласован с командой поверхностей протокол канала общения;
-- спроектированы основные модели взаимодействия SDK (клиент, запрос, ответ, события стриминга);
-- реализована клиентская часть канала общения с поддержкой потоковых ответов (SSE);
-- реализована обработка отключения сессии по инициативе клиента;
-- реализована обработка ошибок транспорта (разрыв соединения, таймаут, HTTP-ошибки);
-- выполнена интеграция готовых навыков через Composio;
-- разработана подсистема логирования с конфигурацией через YAML-манифесты;
-- настроена трассировка сессий агента в Langfuse;
-- проведено юнит- и интеграционное тестирование совместно с командой поверхностей.
-
-## **Вывод**
-
-В ходе практики был спроектирован и реализован SDK-слой для агентной платформы Lambda, предназначенный для использования командой пользовательских поверхностей. Основными результатами стали: надёжная клиентская реализация потоковых ответов агента с корректной обработкой отключения и ошибок; интеграция внешних навыков через Composio; гибкая система логирования на основе YAML-конфигурации и трассировка сессий в Langfuse.
-
-Разработанный SDK был использован командой поверхностей при интеграции Matrix-адаптера с агентной платформой, что подтвердило работоспособность выбранных решений в реальном сценарии. В ходе практики я получил практический опыт проектирования клиентских библиотек для AI-систем, работы с потоковыми HTTP-протоколами, интеграции внешних API через инструментальный слой, построения систем логирования и наблюдаемости, а также взаимодействия с несколькими параллельными командами разработки.
-
-Материалы, изложенные в отчете обучающегося, полностью соответствуют индивидуальному заданию.
-
-Подпись обучающегося: \___\___\___\___\___\___\___\___\__ / Малинин Ярослав / 07.06.2026

surfaces/yashnov_vladislav.md

@@ -0,0 +1,20 @@
+# Отчёт обучающегося по практике
+
+## Исследование агентов
+В первые недели работы лаборатории исследовал поведение Claw-агентов и логику взаимодействия с ними. Был локально установлен и протестирован агент PicoClaw. Тестирование включало в себя настройку конфигурации агента и подключение сторонних tool-инструментов с целью выполнения конкретных задач (чтение почты, web-search и т.д.). Агент был опробован в разнообразных сценариях, что позволило оценить качество, безопасность, и ресурсоемкость этой технологии. По итогам работы были собраны основные тезисы и выводы для дальнейшего обсуждения и сравнения агентов в лаборатории.
+
+## Создание поверхностей 
+
+### Общая концепция
+На следующем этапе, в соответствие с поставленными целями, занимался исследованием и разработкой поверхностей (интерфейсов) для взаимодействия с ядром проекта. В частности, были реализованы MAX-бот и веб-приложение для взаимодействия с агентами. Такие поверхности содержат в себе весь необходимый для общения с агентом функционал: создание и удаление чатов, управление сессиями, загрузка и выгрузка контекста, взаимодействие с tool-инструментами, настройка безопасности, управление подпиской и т.д. Все поверхности используют стандартизированные шаблоны подключения к ядру, что делает переход с этапа mock-тестирования на продакшн-релиз максимально гладким и быстрым.
+
+### Веб-интерфейс
+Рассмотрим более детально реализацию задачи на примере веб-интерфейса. Так как общая цель проекта - создание универсальной платформы для взаимодействия с ИИ-агентом Lambda через различные каналы связи, то веб-интерфейс решает задачу предоставления доступа к агенту без установки дополнительного ПО, через браузер, с полным функционалом, аналогичным Matrix- и Telegram-адаптерам.
+
+Основные задачи веб-интерфейса: обеспечить обмен сообщениями в реальном времени через WebSocket, поддержку множественных чатов, загрузку и отображение файлов, персистентность истории диалогов, управление контекстом беседы (сохранение и загрузка сессий), настройку параметров агента (навыки, безопасность, личность, интеграции), рендеринг markdown-ответов с поддержкой таблиц, кода и цитат, а также интуитивно понятный интерфейс с модальными окнами и подсказками.
+Архитектурно веб-поверхность должна повторять структуру Matrix и Telegram адаптеров: конвертер для трансформации JSON в core-протокол и обратно, WebSocket-обработчик, интеграцию с общим EventDispatcher и StateStore. Это обеспечивает единую логику обработки сообщений и команд независимо от канала входа, упрощая добавление новых поверхностей в будущем.
+
+Созданный веб-интерфейс представляет собой полноценный чат с агентом, работающий в браузере. Пользователь может отправлять текстовые сообщения и файлы, получать ответы с markdown-разметкой, управлять несколькими чатами (создавать, переименовывать, архивировать, удалять), сохранять и загружать контекстные сессии, настраивать навыки и параметры безопасности агента через модальные окна и кнопки. Стек: React 19 + TypeScript + Vite на фронтенде, aiohttp (Python) на бэкенде с WebSocket для реального времени. Весь core-слой - EventDispatcher, менеджеры чатов, настроек, сессий - общий для web, Matrix и Telegram поверхностей. Хранилище: InMemoryStore для разработки, PrototypeStateStore для прода. Контейнеризация через Docker.
+
+## Soft-Skills
+Помимо прочего, работа в лаборатории требовала и улучшения soft-скиллов. На протяжение всей практики участники лаборатории собирались для обсуждения достигнутых результатов и планов на ближайшее будущее, что позволило почувствовать себя частью достаточно крупного проекта, где важно слушать и понимать то, о чем говорят другие, чтобы из разноплановых аспектов удалось собрать единый жизнеспособный результат. Взаимодействие с командой также укрепило навыки планирования задач и распределения обязанностей.