Искусство. Код... ИИ?
前往频道在 Telegram
Канал о прекрасном и не очень, вокруг кода, искуственного интеллекта, и их безопасности. Навигация по каналу: https://t.me/art_code_ai/105
显示更多601
订阅者
无数据24 小时
无数据7 天
+2430 天
帖子存档
\"\nassert html(t\"\npip install -r requirements.txt\n\n🧘♀️ Каждый проект снабжен своим README.md, а там можно и сразу стартовать.\n\nЭтот репозиторий можно в чистом виде 🏖️ R&D-песочница, быстро тестировать разные стеки, паттерны взаимодействия агентов, интеграции MCP и реализацию RAG. Гении, как известно, воруют 👌\n\n#AI #LLM #RAG #LangChain #LlamaIndex #CrewAI #Agno #Memori #AIagents #opensource #MCP #Python #MachineLearning #GenerativeAI","datePublished":"2025-10-01T17:10:26Z","dateModified":"2025-10-01T17:10:26Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":201},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":5},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":2}],"sharedContent":{"@type":"SocialMediaPosting","datePublished":"2025-10-01T16:25:53Z"}}},{"@type":"ListItem","position":8,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/36","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/36","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/36","headline":"SymbolicAI — правильный подход к нейросимвольному программированию. Среди постоянно льющегося буллшита вокруг…","articleBody":"SymbolicAI — правильный подход к нейросимвольному программированию.\n\nСреди постоянно льющегося буллшита вокруг нейросимвольных технологий (которыми сейчас стали называть любые системы, в которых формальные методы выступают верификаторами ИИ-шных и наоборот) затерялась недооцененная жемчужина, здорово упрощающая жизнь ресерчерам и разработчикам ИИ-систем.\n\nSymbolicAI – это нейросимвольный фреймворк на Python, который позволяет объединить классическое программирование, возможности LLM, символьных решателей и множество вспомогательных средств. Он построен так, чтобы его пользователь не задумывался о вопросах интеграции и мог сосредоточиться на логике разрабатываемого им решения.\n\nСимволы (Symbol) – это базовые объекты данных, которым можно задавать операции как обычным Python-методам, а при необходимости переключаться в семантический режим для логических или лингвистических вычислений.\n\nfrom symai import Symbol\nS = Symbol(\"Cats are adorable\", semantic=True)\nprint(\"feline\" in S) # True — семантическая проверка «относится ли 'feline' к S»\n\nВозможности\n\n • Универсальные операции. Символы поддерживают перегруженные операторы: == для «приближённого» равенства, + для смыслового объединения и & для логического вывода. Все операции можно комбинировать в цепочки на одном объекте, чередуя «синтаксический» и «семантический» режимы. Фреймворк умеет переводить тексты, отвечать на запросы и выполнять обычные функции. \n\nНапример, перевод:\nfrom symai import Symbol\nS = Symbol(\"Welcome to our tutorial\")\nprint(S.translate('Russian')) # «Добро пожаловать на наш урок!»\n\nили лингвистические аналогии:\nS = Symbol(\"King - Man + Woman\").interpret()\nprint(S) # “Queen”\n\n • Контракты и проверка. Для надежности разработчики ввели механизм контрактов (Design by Contract, DbC) – позволяющий описывать входные/выходные модели и автоматически проверять или корректировать результаты LLM.\n\n • Интеграция с сервисами. SymbolicAI умеет работать не только с LLM, но и с WolframAlpha, OCR, поиском в интернете и мультимодальными источниками: изображениями, речью и т.п. Это позволяет использовать фреймворк для самых разных задач: от анализа текста и генерации вывода до поиска фактов и работы с данными.\n\nЕщё примеры\n\nСемантическая замена:\nfrom symai import Symbol\nitems = Symbol(['apple', 'banana', 'cherry', 'cat'])\nprint(items.map('replace fruits with vegetables'))\n# -> ['carrot', 'broccoli', 'spinach', 'cat']\n\nИспользование вызова инструментов:\nfrom symai.components import Function\n\ntools = [{\n \"type\": \"function\",\n \"function\": {\n \"name\": \"get_weather\",\n \"description\": \"Get current temperature for a location.\",\n \"parameters\": {\n \"type\": \"object\",\n \"properties\": {\n \"location\": {\"type\": \"string\"}\n },\n \"required\": [\"location\"]\n }\n }\n}]\n\nfn = Function(\n \"Choose and call the appropriate function\",\n tools=tools\n)\n\n# GPT-style tool call\nresp = fn(\"What's the temperature in Bogotá, Colombia?\", raw_output=True)\n# resp.choices[0].finish_reason == \"tool_calls\"\n# resp.choices[0].message.tool_calls[0].function.name == \"get_weather\"\n\nИспользование контрактов:\nfrom symai import Expression\nfrom symai.strategy import contract\nfrom symai.models import LLMDataModel\nfrom typing import Optional, List # For type hints in examples\n\n# Default retry parameters used if not overridden in the decorator call\nDEFAULT_RETRY_PARAMS = {\n \"tries\": 5, \"delay\": 0.5, \"max_delay\": 15,\n \"jitter\": 0.1, \"backoff\": 2, \"graceful\": False\n}\n\n@contract(\n pre_remedy: bool = False,\n post_remedy: bool = True,\n accumulate_errors: bool = False,\n verbose: bool = False,\n remedy_retry_params: dict = DEFAULT_RETRY_PARAMS # Uses defined defaults\n)\nclass MyContractedClass(Expression):\n # ... class implementation ...\n pass\n\nЕщё больше примеров есть в документации.\n\nКмк, классный инструмент для, как минимум, экспериментов ресерчеров в Jupyter-like ноутбуках (примеры). А продуманные средства DbC как бы намекают на пригодность использования и в серьезных продакшн-системах.\n\nMust have, короче.","datePublished":"2025-09-30T09:09:16Z","dateModified":"2025-09-30T09:09:16Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":178},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":4},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":2}]}},{"@type":"ListItem","position":9,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/35","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/35","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/35","headline":"Эстетика ИИ-агентов: и снова... Claude Code В догонку к предыдущему посту. На днях The Pragmatic Engineer опу…","articleBody":"Эстетика ИИ-агентов: и снова... Claude Code\n\nВ догонку к предыдущему посту. На днях The Pragmatic Engineer опубликовали статью «How Claude Code is built», которая однозначно заслуживает внимания. Тезисно:\n\n • От хакатона до бизнеса на $500 млн в год: идея началась как пробный скрипт в терминале, но когда модель стала сама «гулять» по импортам и читать кодовую базу, команда поняла, что это полноценный продукт — и решилась быстро вывести его наружу.\n\n • Минимум кода вокруг модели: разработчики сознательно удаляли вспомогательную логику, чтобы ИИ сам брал на себя максимум работы. Это риск — меньше контроля и привычных «страховок», но выигрыш в скорости развития.\n\n • Лёгкий, нестандартный стек: TypeScript + React (Ink) + Yoga для терминального UI, Bun для сборки. Решили не тянуть привычные тяжёлые фреймворки, чтобы обновления шли мгновенно.\n\n • Рекордный темп: до 100 внутренних релизов в день, десятки прототипов за пару суток. Такую скорость поддержали «короткие циклы доверия»: фичи выпускаются рано, чтобы сразу получать фидбек, а не шлифовать месяцами.\n\n • Дерзкий баланс свободы и безопасности: Claude Code может менять файлы и запускать команды, но каждое действие требует подтверждения. Разработчики сознательно дали модели широкие полномочия — с минимальным, но чётким контролем пользователя.\n\n • Sub-agents за 3 дня: идею «агентов внутри агента» оформили в продакшн после двух провальных попыток — показав, что команда готова быстро рисковать и отбрасывать неудачные решения.\n\nВ деталях:","datePublished":"2025-09-30T05:20:16Z","dateModified":"2025-09-30T05:20:16Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":156},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":9},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":1}]}},{"@type":"ListItem","position":10,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/34","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/34","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/34","headline":"Как разработчику быстро вкатиться в тему LLM? Часть 5 (заключительная) Часть 4 5. Мультиагентные системы и пр…","articleBody":"Как разработчику быстро вкатиться в тему LLM? Часть 5 (заключительная)\n\nЧасть 4\n\n5. Мультиагентные системы и протоколы взаимодействия\n\nРаботая над нетривиальном агентом, разработчик может столкнуться с ситуацией, когда реализуемая им логика перестает укладываться в концепцию агента-соло. Например, когда разделение ролей, параллелизм, изоляция рисков или масштабируемость дают измеримую выгоду по качеству, времени или стоимости. Иногда перестает хватать контекстного окна, или промпт оказывается переусложненным из-за разнородности задач, или возникает необходимость использовать несколько различных моделей. В таких случаях переходят от одноагентных систем к мультиагентным (MAS), где каждый из агентов решает часть общей задачи. В такой системе нет единого центра – координация происходит либо за счёт прямого общения агентов, либо через некоторую общую среду. Основные концепции MAS неплохо описаны в этой статье.\n\nВот лишь некоторые возможные паттерны ролей агентов в MAS:\n\n • Planner → Executors: планировщик дробит задачу, исполнители — узкоспециализированные агенты.\n\n • Critic/Verifier: независимая проверка фактов/ограничений, «красные команды», контрафактуальная проверка.\n\n • Tool-specialists: агенты-обёртки над конкретными инструментами (Bash, Snowflake, Jira).\n\n • Memory/RAG-агенты: отдельный агент управление знанием (индексация, извлечение, цитирование).\n\nО проектировании MAS неплохо написано тут.\n\nАгентам в MAS нужно как-то взаимодействовать с окружением и друг-другом. С этой целью были созданы протоколы A2A от Google, и MCP от Anthropic. Поверхностно ознакомиться с ними поможет эта статья. Вкратце:\n\n • MCP – представляет собой «универсальный разъём a-la USB» между LLM-агентом и внешними инструментами. Протокол вводит три роли участников: Host (основное приложение/интерфейс, где работает агент), Client (компонент-встроенный коннектор при модели) и Server (поставщик инструментов или данных). Фактически, Host координирует диалог и хранит общую память, Server предоставляет реализацию какого-то действия (например, доступ к базе знаний или вызов внешнего API), а Client-соединение позволяет модельному агенту запрашивать у Host доступные инструменты и вызывать их. За счёт этого агент может использовать произвольные инструменты через единый протокол, не требуя от разработчика писать для каждого API свой код обработки.\n\n • A2A же — протокол «агент-агент», дополняющий MCP: если MCP фокусируется на подключении инструментов, то A2A стандартизирует коммуникацию между независимыми агентами (каждый из которых может быть отдельным сервисом). Агент в A2A публикует свой «карточку» с описанием возможностей, а другие агенты могут посылать ему задания через HTTP. В сочетании, MCP и A2A покрывают разные уровни: MCP – подключение одного агента к инструментам и контексту, A2A – связь между разными агентами.\n\nДля начала работы с MCP неплохо также ознакомиться и с этой статьей.\n\nРазумеется, изобретать заново архитектуры MAS и реализовывать протоколы взаимодействия особой необходимости нет — существуют специализированные фреймворки, в которых «всё уже украдено до нас». Наиболее популярным из них является CrewAI: Python-фреймворк, упрощающий создание и оркестрацию группы агентов. В нём вводятся основные сущности – Agent (автономный агент с определённой ролью и целями), Task (задача для агента), Crew (группа агентов, объединённых общей целью), Tool (внешний инструмент, которым могут пользоваться агенты). Фреймворк берёт на себя маршрутизацию задач между агентами и сбор результатов. Стартовать с ним поможет эта статья.\n\nБолее подробный обзор доступных открытых решений для разработки ИИ-агентов представлен здесь.\n\nЗадачка на потренироваться:\n\nДоработать coding-агента из предыдущего задания, добавив к нему verifier-агента на базе другой reasoning-модели, верифицирующего полученные результаты.\n\n———\n\nНа этом, серия постов про вкатывание в разработку для LLM подошла к концу. Но не рубрика «LLM для разработчиков». Stay tuned, как говорится☺️","datePublished":"2025-09-28T18:41:50Z","dateModified":"2025-09-28T18:41:50Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":179},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":13},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":5}]}},{"@type":"ListItem","position":11,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/33","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/33","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/33","headline":"Два «питомца» для ИИ-пентеста: CAI и PentAGI Два годных проекта на случай, если захочется поиграться с ИИ-пен…","articleBody":"Два «питомца» для ИИ-пентеста: CAI и PentAGI\n\nДва годных проекта на случай, если захочется поиграться с ИИ-пентестированием веб-приложений.\n\nCAI\n\nОткрытый фреймворк, реализующий функциональность ассистента пентестера.\n\n • Сканы, поиск уязвимостей (SQLi, XSS, LFI) и базовая эксплуатация — всё в режиме автономного агента.\n\n • Дружит с 300+ LLM (от OpenAI до Ollama), логирует действия через Phoenix и ставит guardrails, чтобы бот не сломал сам себя.\n\n • В CTF-замерах оказался в среднем в 11 раз быстрее человека, а на отдельных задачах — в 3600 раз.\n\n • Уже отмечен в TryHackMe и Hack The Box: находит бреши, читает /etc/passwd, но пока далёк от идеала — цепочки атак увы ещё не особо осиливает. Кожаный мешок с соответствующей экспертизой где-то рядом всё же нужен — агент далеко не всегда безошибочен и не во всем автономен.\n\nPentAGI\n\nПо-настоящему автономный ИИ-пентестер со встроенными тулзами и собственной «долгой памятью»\n\n • Более 20 классических инструментов (nmap, Metasploit, sqlmap и т.п.) прямо из коробки.\n\n • Встроенный браузер и поиск (Google, DuckDuckGo, Tavily) для разведки.\n\n • Векторная база знаний (PostgreSQL + pgvector), чтобы помнить свои прошлые результаты и выстраивать сложные цепочки последовательных атак в рамках одного дерева.\n\n • Отчёты и метрики в Grafana/Prometheus, всё в Docker, разворачивается относительно легко.\n\n • Ориентирован на топовые облачные LLM и весьма прожорлив до токенов (но оно того стоит).\n\nПодытоживая: CAI — добротный инструмент для быстрой работы по низко-висящим фруктам, в то время, как PentAGI — тяжеловес, в хорошем смысле этого слова, для поиска полноценных деревьев атак. Оба проекта в целом хорошо показывают, куда идёт автоматизация вебсека, что не может не радовать...\n\n...или пугать, это уж как посмотреть 😬","datePublished":"2025-09-23T19:57:54Z","dateModified":"2025-09-23T19:57:54Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":259},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":7},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":7}]}},{"@type":"ListItem","position":12,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/32","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/32","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/32","headline":"Уязвимости в дата-репозиториях. Обзорно главное Репозитории для анализа данных и ML - зона повышенного риска…","articleBody":"Уязвимости в дата-репозиториях. Обзорно главное\n\nРепозитории для анализа данных и ML - зона повышенного риска ⚠️. Быстрое прототипирование, работа с чувствительными данными и специфичные инструменты создают уникальные векторы атак. \nВот ключевые из них:\n\n1. 🤫 Секреты в коде. \nСамая распространённая и критичная уязвимость. Хардкод API-ключей (например, к AWS S3, OpenAI, базам данных), токенов доступа и даже паролей прямо в Jupyter Notebook, конфигурационных файлах и скриптах. При попадании такого кода в публичный репозиторий злоумышленники получают прямой доступ к платным сервисам и данным.\n\nЛечение\n‘git grep’ + ‘truffleHog’, ротация ключей, менеджер секретов.\n\n2. 🧑💻 RCE через десериализацию\nБиблиотеки pickle и joblib - стандарты для сохранения ML-моделей в Python - небезопасны. Десериализация файла из ненадёжного источника может привести к выполению произвольного кода на машине.\n\nЛечение \nyaml.safe_load(), ONNX, sandbox.\n\n3. 💻 Открытые ноутбуки\nЮпитер ноутбуки, развёрнутые с настройками по умолчанию, часто остаются доступными для всех в сети (особенно в облаках). Пароли, токены и результаты запросов с конфиденциальными данными могут быть видны в интерфейсе.\n\nЛечениеты в коде. \n‘nbstripout’ аудит перед коммитом. Регулярно аудить права доступа (IAM) к S3-бакетам, базам данных и другим ресурсам. Принцип наименьших привилегий - база 🤭. \n \n4. 🙈\n\nDoS через загрузку моделей. \nЭндпоинт для загрузки моделей без проверки размера файла может быть атакован путём отправки огромного файла, что приводит к переполнению диска и отказу в обслуживании (Denial-of-Service).\n\nData Poisoning. Злонамеренное изменение обучающих данных для подрыва работы модели (например, добавление в выборку для классификации спама писем с определённым словом, помеченных как \"не спам\").\n\nAdversarial Attacks. Специально сконструированные входные данные, предназначенные для обмана модели (например, незаметные для человека изменения в изображении, заставляющие модель видеть не то, что есть на самом деле)\n\nЛечение\nPre-commit хуки, сканирование в CI/CD, обучение DS основам безопасности.Менеджеры секретов, безопасные форматы сериализации, инструменты для мониторинга (Evidently AI, WhyLabs). \n\n#DataSecurity #MLSecurity #PickleRCE #SecretsManagement #DevSecOps\n\n🔗 Полезные ссылки:\n1. TruffleHog— сканер секретов\n2. nbstripout — очистка ноутбуков\n3. OWASP Top 10 — главные уязвимости","datePublished":"2025-09-23T16:17:38Z","dateModified":"2025-09-23T16:17:38Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":225},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":3}],"sharedContent":{"@type":"SocialMediaPosting","datePublished":"2025-09-23T15:31:25Z"}}},{"@type":"ListItem","position":13,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/31","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/31","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/31","headline":"Новый выпуск — и он про безопасность! В нём эксперт по Application Security из Positive Technologies Владимир…","articleBody":"Новый выпуск — и он про безопасность!\n\nВ нём эксперт по Application Security из Positive Technologies Владимир Кочетков рассказывает:\n\n• что будет, если вообще забить на безопасность;\n• почему от уязвимостей бизнес-логики «никогда в жизни не защитит» даже самый крутой AF;\n• правда ли, что хакеры теперь умнее нас из-за ИИ;\n• как внедрить безопасность, чтобы тебя не возненавидели все разработчики.\n\nСлушать →\nна удобной площадке \nна YouTube\nна Яндекс Музыке\nв Вконтакте","datePublished":"2025-09-22T09:55:17Z","dateModified":"2025-09-22T09:55:17Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":182},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":13},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":2}],"sharedContent":{"@type":"SocialMediaPosting","datePublished":"2025-09-22T09:30:01Z"}}},{"@type":"ListItem","position":14,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/30","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/30","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/30","headline":"Принял участие в подкасте DevOps Deflope. Поболтали чуть за безопасную разработку и смежные с ней темы 😍","articleBody":"Принял участие в подкасте DevOps Deflope. Поболтали чуть за безопасную разработку и смежные с ней темы 😍","datePublished":"2025-09-22T09:55:17Z","dateModified":"2025-09-22T09:55:17Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":208}]}},{"@type":"ListItem","position":15,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/29","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/29","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/29","headline":"В разы быстрее, на порядок опаснее: исследование безопасности ИИ-разработки от Apiiro На фоне растущей тенден…","articleBody":"В разы быстрее, на порядок опаснее: исследование безопасности ИИ-разработки от Apiiro\n\nНа фоне растущей тенденции повсеместного и обязательного (а, в некоторых случаях, и принудительно-карательного) внедрения ИИ-решений в процессы разработки, компания Apiiro задалась вопросом о влиянии ИИ-ассистентов на безопасность кода. Исследование, к сожалению, получилось не воспроизводимое и аффилированное, поскольку сама компания является поставщиком ИИ-агентных решений AppSec. \n\nОднако, в общую картинку почему-то хочется верить. Даже если допустить, что выводы там существенно искажены в удобную компании сторону, упоминаемая ими тенденция размена ИИ-ассистентами простых багов на более опасные и трудноуловимые архитектурные и логические уязвимости, в целом — очень похожа на правду:\n\nAI assistants are good at catching the small stuff. Our analysis shows trivial syntax errors in AI-written code dropped by 76%, and logic bugs fell by more than 60%.\n\nBut the tradeoff is dangerous: those shallow gains are offset by a surge in deep architectural flaws. Privilege escalation paths jumped 322%, and architectural design flaws spiked 153%. These are the kinds of issues scanners miss and reviewers struggle to spot – broken auth flows, insecure designs, systemic weaknesses.\n\nЧудес не бывает. На чем LLM обучили, на том она и хороша. А в сети — тьма открытого кода с пока ещё не найденными уязвимостями этих и аналогичных им hardcase-классов 😕 С помощью ИИ-ассистентов можно получать хороший, стабильный и безопасный код. Но для этого его нужно уметь писать и без них, формулируя соответствующие требования на входе, и проводя ревью результатов на выходе. Ну, и иметь в качестве fallback'а за спиной выстроенные и работающие процессы тестирования и безопасной разработки.\n\nИ тут было бы уместно завершить пост красивой установкой, прозвучавшей в исследовании: «внедряете ИИ-кодеров, внедряйте и ИИ-аппсеков», если бы не одно но... \n\nНесмотря на ожидаемый в конце исследования призыв «покупайте наши решения», там почему-то отсутствуют такие же красивые диаграммы, показывающие влияние предлагаемых решений на общую картину. А ведь это напрашивается в такой публикации само собой.\n\nВидимо аргумент о «чудес не бывает» — пока ещё актуален по обе стороны баррикад 🤷♂️","datePublished":"2025-09-10T20:01:59Z","dateModified":"2025-09-10T20:01:59Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":314},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":7}]}},{"@type":"ListItem","position":16,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/28","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/28","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/28","headline":"Абстрактная интерпретация и символьное выполнение: в чем разница? В любой непонятной ситуации, когда станет с…","articleBody":"Абстрактная интерпретация и символьное выполнение: в чем разница?\n\nВ любой непонятной ситуации, когда станет совсем скучно — заводи спор о терминологии...\n\nПост родился по мотивам вчерашних обсуждений с собратьями по несчастью коллегами. Дело в том, что эти два подхода к анализу приложений здорово путают, а иногда считают одно подмножеством другого. На самом деле, все чуть сложнее)\n\nПри символьном выполнении код интерпретируется, или выполняется, в соответствии с подмножеством семантики целевого языка, заменой всех неизвестных значений (входных данных) символьными переменными и вычислением формул в модели памяти, вместо конкретных значений. Подмножеством — потому что, невычислимые и сложно-вычислимые конструкции (вроде циклов и рекурсии, инварианты которых включают символьные переменные) упрощаются различными способами, про которые в академическом мире пишут целые диссертации. В реальном же мире SAST, как правило, просто ограничиваются «прокруткой» таких конструкций фиксированное количество раз или охапкой эвристик.\n\nОсновной челлендж разработчиков SAST, работающих в парадигме символьного выполнения: приемлемая аппроксимация семантики языка и эффективное решение проблемы экспоненциального роста путей выполнения или множества значений. Короче, долго, «дорого» (в плане сложности реализации), но относительно точно.\n\nАбстрактная интерпретация же — это размен точности на скорость, при примерно той же «стоимости». Вместо неизвестных значений берутся их приближения: «переменная x в [0..10]», или «переменная y чётная», или (в продвинутых техниках) «переменная s определяется конечным автоматом [a-zA-Z]+». Это формирует т.н. домен интерпретации. И далее осуществляется интерпретация кода в соответствии с определенным доменом. Анализ завершается в куда более приемлемое время, и охватывает все пути, но ценой роста процента ложных срабатываний.\n\nПроще пояснить на примере вычисления цикла:\ndef g(x):\n while x < 100:\n x = x + 2\n return x\n\nСимвольное выполнение (один из подходов):\n\n– принимает число итераций за неизвестную переменную k;\n\n– выводит через интерпретацию уравнение x0 + 2k = 100 и ищет его решения;\n\n– находит, например, x0 = 0, k = 50;\n\n– крутит цикл k раз.\n\nОтносительно точно, но для сложных циклов всё же нужны инварианты (см. диссертацию выше), иначе анализ взорвётся по путям выполнения. На практике, в реальных приложениях, для подобного цикла — это произойдет задолго до приближения к 50-ой итерации.\n\nАбстрактная интерпретация (интервальный домен):\n\n– начнём с x ∈ [0..50];\n\n– каждую итерацию добавляем 2: [0..52] → [0..54] → …;\n\n– рост бесконечный, поэтому применяем widening («перепрыгиваем» через растущие приближения, чтобы гарантировать быстрое достижение фиксированной точки, пусть и грубым образом) и прыгаем к границе [0..+∞);\n\n– потом применяем narrowing (уточняем полученное приближение, чтобы вернуть часть точности, которую потеряли на шаге widening) и условие выхода из цикла уточняют результат до [100..+∞).\n\nИнтервалы говорят: «на выходе точно x ≥ 100», но теряют информацию о чётности.\n\nЕсли взять домен «чёт/нечет», анализ сохранит инвариант: x ≡ x0 (mod 2). Это уже лучше, чем только интервалы, но и дороже.\n\nТаким образом, эти два подхода действительно принадлежат одному семейству в том смысле, что осуществляют интерпретацию кода. Но символьное выполнение полагается в большей степени на упрощение семантики языка, в то время, как абстрактная интерпретация — на упрощение семантики данных, заданное на старте интерпретации.\n\nНо вообще, отвечая на вопрос, является ли одно подмножеством другого... если у абстрактной интерпретации отрезать все ограничения на входные данные, и основанные на них техники вычисления циклов и рекурсии, но пришить при этом упрощение семантики языка, то из дедушки возможно и получится бабушка🤷♂️","datePublished":"2025-09-10T09:22:25Z","dateModified":"2025-09-10T09:22:25Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":1,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":387},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":14},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":12},{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1}]}},{"@type":"ListItem","position":17,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/27","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/27","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/27","headline":"Эстетика ИИ-агентов: Claude Code Последнее время появляется всё больше и больше хвалебных статей и отзывов о…","articleBody":"Эстетика ИИ-агентов: Claude Code\n\nПоследнее время появляется всё больше и больше хвалебных статей и отзывов о Claude Code. В некоторых из них его даже называют образчиком правильного подхода к разработке agentic-решений. Почему так?\n\nОн прост, практичен, и вызывает минимум когнитивной нагрузки у своего пользователя 🤷♂️ Может и не блестяще, но весьма добротно решая при этом те задачи, под которые был разработан. Вот такой простой рецепт успешного успеха)\n\nНе вполне уверен насчёт прям образчика разработки agentic-решений (насмотренности не хватает), но примером следования KISS, до ощутимого удовольствия в органах эстетического восприятия, Claude Code совершенно точно является. И, как по мне, вполне себе тянет на решение, из которого совершенно не зазорно заимствовать принципы и подходы при разработке собственных ИИ-агентов.\n\nОтносительно поверхностно ознакомиться с особенностями реализации Claude Code можно в статье «What makes Claude Code so damn good (and how to recreate that magic in your agent)!?» Детальнейший же (и весьма немаленький) разбор архитектуры и реализации этого агента доступен в отчете «Claude Code: An analysis». И, поверьте, там есть на что посмотреть)\n\nНу и, на всякий случай, вот ещё awesome-подборка материалов по Claude Code, чтобы попробовать его в деле, задействуя максимум возможностей, если вдруг ещё не.","datePublished":"2025-09-08T20:59:09Z","dateModified":"2025-09-08T20:59:09Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":266},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":10},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":5}]}},{"@type":"ListItem","position":18,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/26","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/26","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/26","headline":"🧩 Принципы и паттерны безопасной разработки: SRP Хоть это и не вполне очевидно, но разработка безопасных прил…","articleBody":"🧩 Принципы и паттерны безопасной разработки: SRP\n\nХоть это и не вполне очевидно, но разработка безопасных приложений может (а, возможно, и должна) начинаться, отнюдь не с моделирования угроз, внедрения в код механизмов защиты, ревью безопасности, пентестов, внедрения SCA/SAST/DAST, или, тем более, чего-то, вроде хантовского «Hack Yourself First» ✝️ В лучших традициях Shift Left Security, начинать стоит с базовых принципов разработки, таких, как SOLID, YAGNI, DRY, KISS, чистый код с архитектурой и т.п. Именно они позволяют заложить в архитектуру и реализацию приложения правильный фундамент, на котором будет гораздо проще и дешевле реализовывать прочие решения и этапы внедрения DevSecOps.\n\nНачнём с принципа единственной ответственности (Single Responsibility Principle, SRP — первая буква в SOLID), утверждающему, что каждый класс или модуль должен иметь единственную ответственность (только одну причину для изменения). С точки зрения безопасности SRP способствует изолированности компонентов и чётким границам доверия в коде, что существенно облегчает последующую работу с моделью угроз. Когда компонент сконцентрирован на одной задаче, его легче проверять на уязвимости и логические ошибки. Это снижает риск скрытых багов, возникающих при смешении разных обязанностей (например, проверка прав доступа вперемешку с бизнес-логикой). Как отмечают эксперты, соблюдение SRP «ограничивает случайную эскалацию привилегий и упрощает поиск ошибок», а также уменьшает общую поверхность атаки за счёт уменьшения сложности компонентов.\n\nТривиальный пример: допустим, класс UserAuth одновременно проверяет пароль пользователя и создаёт сессию при входе. \n\nНарушение SRP может выглядеть так:\nclass UserAuth {\n public Session Authenticate(string username, string password) {\n // Фрагмент, работающий с новыми пользователями\n if (!PasswordChecker.IsStrong(password)) {\n throw new Exception(\"Weak password\");\n }\n\n var user = userRepository.CreateUser(username, password);\n return sessionManager.StartSession(user);\n }\n}\n\nВ этом коде смешаны проверки безопасности (надежность пароля) и бизнес-логика сессии. Если разработчик решит изменить логику создания сессии, есть риск ненароком ослабить или обойти шаг проверки пароля. Правильнее разделить эти обязанности на отдельные классы (например, PasswordChecker, UserRepository, SessionManager), а UserAuth сделать оркестратором. Тогда код станет понятнее и безопаснее: каждая часть легко проверяется и тестируется отдельно.\n\nЗабавно, что «живым» примером последствий нарушения SRP является одна из наиболее нашумевших уязвимостей в библиотеке логирования Apache Log4j 2 CVE-2021-44228, известная как Log4Shell. Логирование — это задача записи сообщений, но Log4j помимо этого выполнял ещё и роль интерпретатора/поисковика ресурсов (JNDILookup). Фактически, в библиотеку логирования «просочилась» функциональность, выходящая за рамки её единственной ответственности — она не только записывала логи, но и могла выполнять сетевые запросы и загружать код. Если бы Log4j ограничился исключительно записью логов, без вычисления каких-либо lookup-выражений, уязвимость бы не возникла. И действительно, исправление проблемы заключалось в отключении/удалении функции JNDI Lookup из Log4j.\n\nСоблюдение SRP помогает избежать многих CWE, связанных с логическими ошибками и неправильной проверкой условий, которые трудно выявить в нагромождённом коде. Например, SRP предотвращает появление скрытых дефектов управления доступом, из разряда CWE-732, CWE-862, возникающих, когда проверка прав смешана с другими функциями и может быть пропущена.\n\nВ целом, SRP укрепляет принцип «secure by design»: мелкие простые модули легче защитить и проверить.","datePublished":"2025-08-31T08:13:45Z","dateModified":"2025-08-31T08:13:45Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":2,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":2204},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":15},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":29},{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2}]}},{"@type":"ListItem","position":19,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/25","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/25","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/25","headline":"Как разработчику быстро вкатиться в тему LLM? Часть 4 Часть 3 4. Автономные ИИ-агенты Итак, промпты писать на…","articleBody":"Как разработчику быстро вкатиться в тему LLM? Часть 4\n\nЧасть 3\n\n4. Автономные ИИ-агенты\n\nИтак, промпты писать научились, обогащать контекст актуальными знаниями с помощью RAG — тоже, но кое-чего ещё не хватает. Большинство привычных ИИ-сервисов представляют собой множество модулей, каждый из которых решает какую-либо конкретную задачу, планируя решение с помощью LLM и заданных правил, и имея в распоряжении внешний инструментарий для взаимодействия со внешним миром: от поиска в сети, до генерации и выполнения кода в реальной среде. Такие модули называются ИИ-агентами. Наиболее близкой и понятной разработчикам аналогией агентов в классической разработке, пожалуй, являются микросервисы.\n\nВообще, есть годные курсы по ИИ-агентам от Microsoft и Hugging Face, гайд от OpenAI, и исчерпывающий AI Agents Handbook, полностью погружающие в эту (и следующую, btw) темы. Но мы же здесь говорим о быстром старте?\n\nAI-агенты — это автономные программы, способные самостоятельно планировать и выполнять задачи на основе целей пользователя. В основе агента обычно лежит LLM, далеко не всегда мощная, которая понимает запрос и формирует решение, и при необходимости использует инструменты — внешние функции, API или базы знаний. Проще говоря, вы даёте агенту задачу — он сам решает, что делать и как, действуя в цифровой среде подобно разумному ассистенту. Всю вводную информацию, необходимую для старта, можно подчерпнуть из статьи «AI-агенты на основе LLM и мультиагентные системы».\n\nРазличают два основных типа агентов: реактивные (мгновенно реагируют на входные данные) и проактивные (могут планировать шаги для долгосрочных целей). Как правило, агент состоит из нескольких ключевых компонентов, формирующих пайплайн решения задачи: восприятие, анализ, действие, память и т.п. Типам и структуре агента, организации взаимодействия между его компонентами, вместе с их базовой реализацией, посвящена статья «Agents 101: Как создать своего первого ИИ-агента за 30 минут».\n\nРазумеется, здесь никуда без паттернов. Аналогом GoF в мире агентов является «Agentic AI Handbook: Design Patterns», описывающая свыше сотни различных шаблонов проектирования и разработки агентов. Наиболее популярными из них являются:\n\nWorkflow паттерны:\n\n• Prompt Chaining — последовательный разбор задачи шаг за шагом (outline → проверка → генерация);\n\n• Routing/Handoff — выбор исполнителя (агента или модели) для подзадачи;\n\n• параллелизация — выполнение независимых шагов одновременно.\n\nAgentic паттерны:\n\n• Reflection — агент оценивает и улучшает свой ответ, устраняя ошибки и уточняя детали;\n\n• Tool Use — агент использовать внешние инструменты (API, поиск, код) в процессе;\n\n• ReAct (Reason + Act) — итеративный цикл: рассуждение → действие → наблюдение → повтор;\n\n• Planning — разбивка задачи, создание плана с подзадачами и последовательное выполнение;\n\n• Multi-Agent — распределение ролей между агентами, коллективное решение сложных задач (приведен для полноты картины, этой теме будет посвящена следующая часть).\n\nОзнакомиться с подходами к реализации этих и других популярных паттернов можно в статьях:\n\n«AI Agents Design Patterns Explained»\n«Building effective agents»\n«Zero to One: Learning Agentic Patterns»\n\nТакже, стоит упомянуть класс паттернов «Schema-Guided Reasoning» (SGR), позволяющий LLM создавать структурированные, понятные и предсказуемые результаты, удобные для дальнейшей обработки компонентами агента.\n\nВ качестве примеров готовых агентов и реализуемых ими кейсов можно смело брать на изучение проекты из репозитория «500 AI Agents Projects».\n\nЗадачка на потренироваться:\n\nПройти воркшоп «Build Your Own Coding Agent» и доработать получившийся проект, реализовав в нём функциональность поиска секретов в коде на основе связки сигнатурного поиска и оценки энтропии строковых литералов (или любой другой понятный вам кейс кодинга).","datePublished":"2025-08-28T08:57:22Z","dateModified":"2025-08-28T08:57:22Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":491},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":15},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":21}]}},{"@type":"ListItem","position":20,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/24","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/24","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/24","headline":"4 секрета Roboduck. Как Theori взяли AIxCC и бустанули хакеров х10 🚀🚀🚀 Что ты представляешь, когда слышишь о…","articleBody":"4 секрета Roboduck. Как Theori взяли AIxCC и бустанули хакеров х10 🚀🚀🚀\n\nЧто ты представляешь, когда слышишь о системе, которая способна обнаруживать уязвимости, создавать эксплоиты, а также сразу выпускать патчи, устраняющие дыры прошлого? Theori, команда участвовавшая в соревновании AI Cyber Challenge попыталась решить эту сложную задачу, представив автономную CRS(Cyber Reasoning System) - RoboDuck. В этой системе используются агенты, но не как аддон, а как основа. \n\nПочему система оказалась эффективной и почему получилось дополнить основу революции агентов в кибербезе?\n\n🧩Секрет № 1. Разбивайте задачу на части, как пазл.\n\nГлавная идея - не тащить все одним супер-агентом. Делим на подзадачи и даем разным агентам. Представьте лабиринт: чем он больше, тем больше тупиков, логично? А теперь, что вместо одного огромного лабиринта у вас есть серия маленьких? Шансы найти выход резко возрастают! \n\nДля генерации Proof of Vulnerability(PoV) команда выделила три подзадачи:\n\n1. Анализ fuzz-harness и написание кода для преобразования семантики в бинарщину.\n2. Ответы на точечные вопросы по коду.\n3. Отладка готового PoV, чтобы понять почему эксплоит не срабатывает.\n\nКаждую подзадачу вёл отдельный агент, а главный агент собирал результат в цельную картину.\n\n⚒️Секрет №2. «Не все инструменты сразу - только нужные»\n\nВ ходе разработки решения команда обнаружила, что если агенту дозволено делать абсолютно всё, начинается хаос:\n\n1. Агент может запустить прожорливую команду, которая съест все ресурсы (грепанём по всему коду в Линуксе 🙃)\n2. Контекст засоряется - фокус теряется.\n3. Простые задачи вдруг начинают требовать множества шагов 🤢..\n\nЧто сделали Theori ??? Они создали узкоспециализированные тулы: для поиска строки, для чтения фрагмента кода и для извлечения отдельных символов из кода. Плюс сами инструменты имели guardrails, которые могли сужать промпт в случае получения большого количества результатов.🤔\n\n⛓️Секрет №3. Структурированный вывод от эксперта.\n\nКак получить из агента не «простынь», а структурированный вывод/результат. Theori делится с нами двумя способами:\n\n- Сперва дайте агенту схему вывода в XML и прямо попросите, чтобы он оформлял ответ в XML тегах. Модели хорошо их понимают.\n\n- Далее создайте отдельный тул, который будет завершать работу агента, - своеобразная кнопка \"Готово\" с полями для заполнения😕. Когда параметры вызова совпадают с финальным результатом — агент аккуратно завершает работу без болтовни.\n\n🎚️Секрет №последний, 4: Подстраивайтесь под особенности моделей 😮\n\nИгнорирование факта что все LLM разные = неудача = ловить одни и те же фейлы. Команда обнаружила, что если агент делает одну и ту же ошибку, то лучше добавить в промпт запрещалку. Claude отлично следует этим запрещалкам 😎 - он любит когда ему что-то запрещают. Если агент застревает, то надо попросить его «подумать иначе» и сменить стратегию. \n\nВ соревновании это выстрелило, когда агент PoVProducer не смог создать пригодный эксплоит, но правила смогли дать нужный результат.\n\nКак пишут в Theori: \"Хотя ИИ ещё не заменит хакера, он уже делает его в 10 раз эффективнее\". \n\n🧨А с этими секретами го разрабатывать агентов для своих задач!😺","datePublished":"2025-08-27T13:17:40Z","dateModified":"2025-08-27T13:17:40Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":291},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":4},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":1}],"sharedContent":{"@type":"SocialMediaPosting","datePublished":"2025-08-27T09:53:42Z"}}}]}
{evil}
\") == \"<script>alert(1)</script>
\"\n\nОднако, как и говорится в описании изменений, t-строки — это лишь механизм обработки строк, а не панацея от инъекций, неправильное использование которого позволит прострелить себе конечность не менее лихо, чем в случае с f-строками:\n\n • Эффективность санитизации интерполяций — целиком зависит от правильного выбора или написания их обработчиков.\n\n • Все выражения внутри блоков {…} вычисляются сразу же в лексическом скоупе, интерполяцией же становится результат этого вычисления. Поэтому t\"{eval(request.get['a'])}\" — это всё ещё RCE, вне зависимости от обработчиков. Похожая история — и с попаданием в Template или Interpolation входных данных при создании объектов этих классов из конструкторов (вообще, стоит этого по-возможности избегать, и пользоваться предложенным синтаксическим сахаром t\"…\").\n\n • Конкатенация Template + Template разрешена. Это удобно, но может породить «вирусность» шаблонов и неочевидную логику сборки, если смешивать части, ожидающие разных политик экранирования.\n\n • Формат-спецификаторы внутри {…} вычисляются до format_spec, что может привести к потере грамматического контекста, когда придёт время обработчика.\n\n • Валидацию входных данных в соответствии с бизнес-логикой этот механизм не заменяет, и относится лишь ко второму эшелону эффективной обработки данных.\n\nВ общем, механизм годный, использовать стоит, но «думать всё равно придётся» (с) 😊","datePublished":"2025-10-08T17:06:52Z","dateModified":"2025-10-08T17:06:52Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":1757},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":3},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":20}]}},{"@type":"ListItem","position":6,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/38","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/38","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/38","headline":"Новый взгляд на «контекст» в ИИ: от prompt engineering к context engineering Команда Anthropic опубликовала с…","articleBody":"Новый взгляд на «контекст» в ИИ: от prompt engineering к context engineering\n\nКоманда Anthropic опубликовала статью «Effective Context Engineering for AI Agents», где утверждает, что в эпоху агентных систем привычное «написать правильный prompt» постепенно уступает место более широкому подходу — контекст-инженерии. Контекст — не просто текст промпта, а весь набор токенов, который модель «видит» в момент вывода.\n\nАвторы показывают, что по мере роста размеров контекста модели начинают терять фокус: не вся информация доходит до «внимания». В этом смысле контекст — ограниченный ресурс, и важно тщательно отбирать «высокосигнальные» куски данных.\n\nЧто составляет контекст-инженерию на практике?\n\n • Отказ от перегруженных инструкций и «жёстких» шаблонов в пользу сбалансированных, гибких указаний. \n\n • Динамическое подключение данных по принципу «just in time»: агент подгружает нужные фрагменты контекста в момент, когда они действительно важны.\n\n • Техники для задач с большой временной протяженностью: сжатие истории (основные факты сохраняются, лишнее — убирается), записи-заметки вне контекста, или распределённые структуры с субагентами. \n\nПо мнению авторов, context engineering — это не просто тренд, а фундаментальный сдвиг в проектировании ИИ-агентов. Даже по мере роста возможностей моделей, бережное управление вниманием остаётся ключом к стабильному и надёжному поведению.","datePublished":"2025-10-02T05:36:19Z","dateModified":"2025-10-02T05:36:19Z","author":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"publisher":{"@type":"Organization","name":"Искусство. Код... ИИ?","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai","image":"https://img.telemetr.io/c/2nULhu/5325780372576923876?ty=x"},"commentCount":0,"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":246},{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":3},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":2}]}},{"@type":"ListItem","position":7,"item":{"@type":"SocialMediaPosting","@id":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/37","url":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/37","mainEntityOfPage":"https://telemetr.io/ch/channels/2185649512-art_code_ai/posts/37","headline":"Awesome AI Apps - технический гид по созданию LLM-приложений 🦙 Репозиторий awesome-ai-apps - коллекция продак…","articleBody":"Awesome AI Apps - технический гид по созданию LLM-приложений\n\n🦙 Репозиторий awesome-ai-apps - коллекция продакшен-примеров для построения приложений на базе LLM. Внутри — проекты на LangChain, LlamaIndex + habr, CrewAI, Agno, Mastra, Nebius AI Studio, GibsonAI и много других полезных!..\n\nЧто можно найти:\n- минимальные прототипы на базе OpenAI SDK, LangGraph, Camel AI — идеальны для экспериментов,\n- готовые сценарии вроде финансового трекера, HITL-агента или бот для веб-автоматизации,\n- демонстрации работы с Model Context Protocol (MCP) для репозиториев, документов или бд. Это особенно актуально для стандартизации, взаимодействия между агентами и внешними сервисами. Ну и тем, кто оттягивает знакомство с MCP, еть уже готовые анализ GitHub-репо, QnA по документации, работа с Couchbase и GibsonAI DB. Не оттягивайте 🤪.\n- агенты с persistent memory (на Memori), которые позволяют строить более контекстно-зависимые системы (например, arXiv Researcher или Social Media Agent).\n- примеры Agentic RAG (они не устарели!!!) с использованием Qdrant, Exa, LlamaIndex. Поддержка работы с PDF, кодом и OCR (Gemma3).\n- комплексные пайплайны (например, Meeting Assistant, который конвертирует митинг в задачи и заметки, или Finance Service Agent на FastAPI)\n\nЧто под капотом (продублируем для удобства твоего гугл эдвэнсед, большинство ссылок выше) и ждет, когда затащишь себе?\n🫰 LangChain + LangGraph для оркестрации агентов.\n🫰 Agno как фреймворк для построения agentic workflows.\n🫰 CrewAI для мультиагентных исследований.\n🫰 LlamaIndex как основа RAG и документных ассистентов.\n🫰 Memori для хранения контекста и долгосрочной памяти.\n🫰 Nebius AI и Bright Data — как инфраструктурные провайдеры.\n\nУстановка (единый паттерн):\n\ngit clone https://github.com/Arindam200/awesome-ai-apps.git\ncd awesome-ai-apps/
UTCP: новая альтернатива MCP
Универсальный протокол вызова инструментов (Universal Tool Calling Protocol, UTCP) представляет собой смену парадигмы взаимодействия ИИ-агентов с внешними инструментами и сервисами. В отличие от традиционных подходов, требующих серверов-обёрток и прокси-слоёв, UTCP обеспечивает прямое взаимодействие между агентами ИИ и инструментами через их собственные эндпоинты.
Сегодня, чтобы подключить ИИ к внешним инструментам, разработчики вынуждены писать обёртки: агент → MCP-сервер → инструмент, и неизбежно сталкиваются с:
• лишними задержками и точками отказа;
• дублированием безопасности;
• необходимости в инфраструктуре ради вторичного посредника.
UTCP убирает необходимость в такой прослойке. В целом, сравнение UTCP и MCP можно свести к следующему: UTCP — это «мануал» (описание инструмента), а MCP — «посредник» (сервер, оборачивающий инструмент). UTCP предполагает архитектуру прямого взаимодействия «агент → инструмент», тогда как MCP — «агент → MCP-сервер → инструмент».
Отсюда вытекают и все преимущества UTCP:
• Инфраструктура: UTCP не требует новых сервисов (достаточно добавить endpoint в существующий API), MCP же нуждается в отдельном сервере(-ах) для каждого набора инструментов.
• Производительность: UTCP выполняет вызов за один шаг (агент сразу обращается к API инструмента), MCP добавляет “двойной прыжок” через посредника, увеличивая накладные задержки.
• Безопасность: UTCP использует нативную аутентификацию/авторизацию инструмента, MCP вынужден реализовывать и хранить учетные данные на своей стороне, что расширяет поверхность атаки.
• Поддержка протоколов: UTCP гибок (HTTP, WebSocket, CLI, gRPC и т.д. – вплоть до чтения локальных файлов), а MCP ограничен форматом JSON-RPC поверх единственного транспорта.
• Поддержка и масштабирование: UTCP-интеграции практически не требуют поддержки (статический JSON с описанием), масштабируются вместе с существующим сервисом; MCP-серверы же добавляют постоянные заботы (деплой, обновления, мониторинг, масштабирование отдельно от основного API).
Иначе говоря, UTCP выигрывает в простоте, скорости и универсальности, тогда как MCP может дать преимущества только в узких случаях, требующих централизации и унификации ценой дополнительных усилий.
🐍 Пример клиента:
import asyncio
from utcp.client import UtcpClient
from utcp.shared.provider import HttpProvider
async def main():
# Инициализируем UTCP-клиента
client = await UtcpClient.create()
# Определяем HTTP-провайдер (manual endpoint) для сервиса погоды
manual_provider = HttpProvider(
name="weather_service",
provider_type="http",
http_method="GET",
url="http://localhost:8000/utcp" # URL, возвращающий UTCP-описание (manual)
)
# Регистрируем инструменты из указанного manual (добавляем описание)
tools = await client.register_manual_provider(manual_provider)
print(f"Registered {len(tools)} tools")
# Вызов инструмента "get_weather" с параметром location
result = await client.call_tool(
"weather_service.get_weather",
arguments={"location": "San Francisco"}
)
print(f"Weather: {result['temperature']}°C, {result['conditions']}")UTCP: новая альтернатива MCP
Универсальный протокол вызова инструментов (Universal Tool Calling Protocol, UTCP) представляет собой смену парадигмы взаимодействия агентов ИИ с внешними инструментами и сервисами. В отличие от традиционных подходов, требующих серверов-обёрток и прокси-слоёв, UTCP обеспечивает прямое взаимодействие между агентами ИИ и инструментами через их собственные эндпоинты.
Проблема
Сегодня, чтобы подключить ИИ к внешним инструментам, разработчики вынуждены писать обёртки: агент → MCP-сервер → инструмент.
Это означает:
* лишние задержки и точки отказа;
* дублирование безопасности;
* инфраструктура ради посредника.
---
### 💡 Решение: UTCP
UTCP убирает прослойку.
Он работает как “manual” — инструкция, как вызывать инструмент напрямую по его нативному интерфейсу.
Если человек может вызвать ваш API, UTCP делает так, чтобы ИИ-агент мог сделать то же самое — с теми же правами, но без новых серверов.
---
### ⚙️ Пример на Python
import asyncio
from utcp.client import UtcpClient
from utcp.shared.provider import HttpProvider
async def main():
client = await UtcpClient.create()
manual_provider = HttpProvider(
name="weather_service",
provider_type="http",
http_method="GET",
url="http://localhost:8000/utcp" # ваш UTCP manual
)
tools = await client.register_manual_provider(manual_provider)
print(f"Registered {len(tools)} tools")
result = await client.call_tool(
"weather_service.get_weather",
arguments={"location": "San Francisco"}
)
print(result)
asyncio.run(main())/utcp, возвращающий UTCP-описание (совместимо с OpenAPI).
[ ] Опишите ваши инструменты (методы, параметры, аутентификацию).
[ ] Проверьте SDK (pip install utcp, npm i @utcp/core, go get utcp).
[ ] Зарегистрируйте manual в клиенте → вызовите инструмент напрямую.
[ ] (опционально) подключите мост utcp-mcp, если у вас старая MCP-инфраструктура.
---
### ⚡️ Почему стоит попробовать
* Без инфраструктурных затрат: достаточно одного JSON manual.
* Минимальная латентность: агент вызывает API напрямую.
* Нативная безопасность: используется ваш API-ключ или OAuth без дублирования.
* Гибкость: HTTP, CLI, gRPC, WebSocket — без ограничений.
* Масштабирование бесплатно: UTCP растёт вместе с вашим API.
---
### 🔗 Ресурсы
* Документация: [utcp.io](https://www.utcp.io)
* GitHub SDK: [github.com/universal-tool-calling-protocol](https://github.com/universal-tool-calling-protocol)
* Статья: *UTCP — прямая альтернатива MCP*
---
Вывод:
UTCP — это новый стандарт “интеграций без посредников”.
Добавив один endpoint, вы открываете вашим ИИ-инструментам прямой канал к API.
Меньше обёрток — больше пользы.
TL;DR:
UTCP (Universal Tool Calling Protocol) позволяет ИИ-агентам напрямую обращаться к вашим API и CLI-инструментам — без промежуточных серверов, JSON-RPC и кастомных «прокладок». Поддерживает HTTP, gRPC, WebSocket, CLI и стримы. Есть SDK для Python, Node.js, Go.Давно хотел поделиться этой диаграммой. Впервые появившись в серии публикаций «Six Pillars of DevSecOps», она прошла некоторые эволюционные этапы, один из которых присутствует у вашего покорного слуги в офисе, в качестве подаренного коллегами на ДР визуала на пол стены 🎨
Комментировать тут особо нечего. Идеальный Secure SDLC, к которому надо стремиться. Хотя, тут ещё есть что добавить, как минимум — в плане защиты от supply-chain атак, как по мне.
Каждому этапу разработки сопоставлены триггеры. Каждому триггеру — соответствующие действия или инструментарий, обеспечивающие безопасность на данном этапе.
Простая и наглядная иллюстрация, которая будет постоянно напоминать о том, почему у вас в проекте все плохо с безопасностью 😁
🧩 Принципы и паттерны безопасной разработки: OCP и fail-closed
(Open/Closed Principle) — классы и функции открыты для расширения, но закрыты для модификации. Говоря проще: проектируем приложение так, чтобы для новых фичей требовались минимальные изменения в уже существующем (протестированном и стабильном, ну... как правило) коде.
С точки зрения безопасности, это снижает риски сломать уже существующие защитные меры и получить на ровном месте регрессии вроде:
• CWE-840 — логическая уязвимость из-за изменения условий
• CWE-489 — ослабление проверки при модификации кода
... и охапки прочих, на правах их прямых последствий.
🐛 Жизненное
В Apache HTTPD (CVE-2021-41773) разработчики изменили ядро обработки путей — и открыли обход директорий
../. Если бы новую логику добавили отдельным модулем, а не правили существующую, старая проверка осталась бы нетронутой.
Та же история с Dirty Pipe (CVE-2022-0847) в Linux: неаккуратная «оптимизация» существующего кода pipe нарушила старые гарантии → повышение локальных привилегий.
💡 Пример: PEP-750, t-строки и шаблоны
По мотивам предыдущего поста: t"..." создаёт объект Template, а его части (Interpolation) форматируются по format_spec. Здесь напрашивается типичная ошибка — дописывать в обработчике if/elif для новых форматов (HTML, SQL, shell). Каждый раз приходится лезть в уже написанный код, и, тем самым, нарушать OCP.
Плохой пример:
def render(t):
for part in t:
if spec == "html":
out.append(html_escape(v))
elif spec == "sql":
out.append(sql_param(v))
else:
out.append(format(v))_handlers = []
def register(h): _handlers.append(h); return h
def render(t):
for it in t:
if isinstance(it, str): yield it
elif h := next((h for h in _handlers if h.supports(it)), None):
yield h.apply(it)
else:
raise ValueError(f"Unsupported spec: {it.format_spec}")
@register
class HtmlHandler:
def supports(self, it): return it.format_spec.startswith("html")
def apply(self, it): return html_escape(str(it.value))*️⃣ Fail-closed (безопасный отказ) — принцип проектирования, при котором система в случае ошибки или неопределённости выбирает безопасное поведение, даже если это мешает работе. Примеры: • парсер не знает формат входных данных → отклоняет запрос; • фильтр не смог проверить токен → доступ запрещён; • обработчик t-строк встретил неизвестный `format_spec` → бросает исключение вместо неэкранированного вывода. Такой подход предотвращает «тихие» обходы проверок и делает поведение системы предсказуемым даже при сбоях.⚠️ OCP — не догма «Модификация» в OCP не про рефакторинг, баги или уязвимости. Если в существующем коде нашли нашли проблему, то нужно править. Безопасность и здравый смысл приоритетнее. OCP всё же — не тотальный запрет на изменения, а гигиена расширяемости: добавление фичей, без изменения того, что уже защищено и протестировано. TL;DR: • Стоит разумно следовать OCP, чтобы не сломать защиту, добавляя фичи. • Расширять, а не модифицировать, если речь не идёт о рефакторинге, багах или уязвимостях. • Из-за нарушений OCP «увидели свет» многие, в том числе именитые, CVE.
О t-строках в Python 3.14
В юбилейной π-версии Python реализован новый подход к обработке строк, описанный в PEP-750, и уже вызвавший неоднозначную реакцию в сети. По сути, шаблонные строковые литералы, или t-строки (
t"…") — литералы, которые выглядят как f-строки, но не вычисляются сразу же в str. Вместо этого они возвращают объект Template с раздельным доступом к статичной части и вставкам в неё. Это даёт библиотекам шанс корректно экранировать/параметризовать значения под конкретный контекст (SQL, HTML, shell и т.д.) и, якобы, тем самым снизить риск инъекций.
Например, t"Hello {name}" создаёт string.templatelib.Template, в котором доступны части строки и интерполяции, как объекты Interpolation(value, expression, conversion, format_spec). У Template нет __str__, поэтому его невозможно «случайно» напечатать как готовую строку — нужно явно вызвать обработчик (например, html(template) или sql(template), в соответствии с грамматикой принимающей стороны).
На самом деле — очень здравая языковая фича, позволяющая строить эффективную обработку выходных данных за счет:
• Чёткого разделения данных и шаблона, позволяющих (при желании и умении) учитывать грамматический контекст, формат-спецификаторы/конверсии и т.п.
• Запрета «тихой» конкатенации со строками (сложение Template + str запрещено, разрешено только Template + Template.
• Явного рендера за счет отсутствия __str__, заставляющего разработчика осознанно походить к выбору обработчиков.
• Композиционности. Обработчики не обязательно должны возвращать строки, что позволяет объединять их в цепочки. Можно вкладывать шаблоны и обрабатывать по уровням контекста (например, атрибуты HTML как dict → безопасная строка атрибутов).
В psycopg, например, уже подсуетились и реализовали параметризацию SQL-запросов через t-строки в текущем dev своей библиотеки. Их обработчик можно подсмотреть в _trstrings.py.
Пример простого обработчика, санитизирующего данные в контексте HTML/Text:
from html import escape
from string.templatelib import Template, Interpolation
def html(tmpl: Template) -> str:
out = []
for part in tmpl:
if isinstance(part, Interpolation):
out.append(escape(str(part.value)))
else:
out.append(part)
return "".join(out)
evil = "<script>alert(1)</script>"
assert html(t"<p>{evil}</p>") == "<p><script>alert(1)</script></p>"{…} вычисляются сразу же в лексическом скоупе, интерполяцией же становится результат этого вычисления. Поэтому t"{eval(request.get['a'])}" — это всё ещё RCE, вне зависимости от обработчиков. Похожая история — и с попаданием в Template или Interpolation входных данных при создании объектов этих классов из конструкторов (вообще, стоит этого по-возможности избегать, и пользоваться предложенным синтаксическим сахаром t"…").
• Конкатенация Template + Template разрешена. Это удобно, но может породить «вирусность» шаблонов и неочевидную логику сборки, если смешивать части, ожидающие разных политик экранирования.
• Формат-спецификаторы внутри {…} вычисляются до format_spec, что может привести к потере грамматического контекста, когда придёт время обработчика.
• Валидацию входных данных в соответствии с бизнес-логикой этот механизм не заменяет, и относится лишь ко второму эшелону эффективной обработки данных.
В общем, механизм годный, использовать стоит, но «думать всё равно придётся» (с) 😊Новый взгляд на «контекст» в ИИ: от prompt engineering к context engineering
Команда Anthropic опубликовала статью «Effective Context Engineering for AI Agents», где утверждает, что в эпоху агентных систем привычное «написать правильный prompt» постепенно уступает место более широкому подходу — контекст-инженерии. Контекст — не просто текст промпта, а весь набор токенов, который модель «видит» в момент вывода.
Авторы показывают, что по мере роста размеров контекста модели начинают терять фокус: не вся информация доходит до «внимания». В этом смысле контекст — ограниченный ресурс, и важно тщательно отбирать «высокосигнальные» куски данных.
Что составляет контекст-инженерию на практике?
• Отказ от перегруженных инструкций и «жёстких» шаблонов в пользу сбалансированных, гибких указаний.
• Динамическое подключение данных по принципу «just in time»: агент подгружает нужные фрагменты контекста в момент, когда они действительно важны.
• Техники для задач с большой временной протяженностью: сжатие истории (основные факты сохраняются, лишнее — убирается), записи-заметки вне контекста, или распределённые структуры с субагентами.
По мнению авторов, context engineering — это не просто тренд, а фундаментальный сдвиг в проектировании ИИ-агентов. Даже по мере роста возможностей моделей, бережное управление вниманием остаётся ключом к стабильному и надёжному поведению.
Repost from OK ML
Awesome AI Apps - технический гид по созданию LLM-приложений
🦙 Репозиторий awesome-ai-apps - коллекция продакшен-примеров для построения приложений на базе LLM. Внутри — проекты на LangChain, LlamaIndex + habr, CrewAI, Agno, Mastra, Nebius AI Studio, GibsonAI и много других полезных!..
Что можно найти:
- минимальные прототипы на базе OpenAI SDK, LangGraph, Camel AI — идеальны для экспериментов,
- готовые сценарии вроде финансового трекера, HITL-агента или бот для веб-автоматизации,
- демонстрации работы с Model Context Protocol (MCP) для репозиториев, документов или бд. Это особенно актуально для стандартизации, взаимодействия между агентами и внешними сервисами. Ну и тем, кто оттягивает знакомство с MCP, еть уже готовые анализ GitHub-репо, QnA по документации, работа с Couchbase и GibsonAI DB. Не оттягивайте 🤪.
- агенты с persistent memory (на Memori), которые позволяют строить более контекстно-зависимые системы (например, arXiv Researcher или Social Media Agent).
- примеры Agentic RAG (они не устарели!!!) с использованием Qdrant, Exa, LlamaIndex. Поддержка работы с PDF, кодом и OCR (Gemma3).
- комплексные пайплайны (например, Meeting Assistant, который конвертирует митинг в задачи и заметки, или Finance Service Agent на FastAPI)
Что под капотом (продублируем для удобства твоего гугл эдвэнсед, большинство ссылок выше) и ждет, когда затащишь себе?
🫰 LangChain + LangGraph для оркестрации агентов.
🫰 Agno как фреймворк для построения agentic workflows.
🫰 CrewAI для мультиагентных исследований.
🫰 LlamaIndex как основа RAG и документных ассистентов.
🫰 Memori для хранения контекста и долгосрочной памяти.
🫰 Nebius AI и Bright Data — как инфраструктурные провайдеры.
Установка (единый паттерн):
git clone https://github.com/Arindam200/awesome-ai-apps.git
cd awesome-ai-apps/<project_name>
pip install -r requirements.txt
SymbolicAI — правильный подход к нейросимвольному программированию.
Среди постоянно льющегося буллшита вокруг нейросимвольных технологий (которыми сейчас стали называть любые системы, в которых формальные методы выступают верификаторами ИИ-шных и наоборот) затерялась недооцененная жемчужина, здорово упрощающая жизнь ресерчерам и разработчикам ИИ-систем.
SymbolicAI – это нейросимвольный фреймворк на Python, который позволяет объединить классическое программирование, возможности LLM, символьных решателей и множество вспомогательных средств. Он построен так, чтобы его пользователь не задумывался о вопросах интеграции и мог сосредоточиться на логике разрабатываемого им решения.
Символы (Symbol) – это базовые объекты данных, которым можно задавать операции как обычным Python-методам, а при необходимости переключаться в семантический режим для логических или лингвистических вычислений.
from symai import Symbol
S = Symbol("Cats are adorable", semantic=True)
print("feline" in S) # True — семантическая проверка «относится ли 'feline' к S»from symai import Symbol
S = Symbol("Welcome to our tutorial")
print(S.translate('Russian')) # «Добро пожаловать на наш урок!»S = Symbol("King - Man + Woman").interpret()
print(S) # “Queen”from symai import Symbol
items = Symbol(['apple', 'banana', 'cherry', 'cat'])
print(items.map('replace fruits with vegetables'))
# -> ['carrot', 'broccoli', 'spinach', 'cat']from symai.components import Function
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "Get current temperature for a location.",
"parameters": {
"type": "object",
"properties": {
"location": {"type": "string"}
},
"required": ["location"]
}
}
}]
fn = Function(
"Choose and call the appropriate function",
tools=tools
)
# GPT-style tool call
resp = fn("What's the temperature in Bogotá, Colombia?", raw_output=True)
# resp.choices[0].finish_reason == "tool_calls"
# resp.choices[0].message.tool_calls[0].function.name == "get_weather"from symai import Expression
from symai.strategy import contract
from symai.models import LLMDataModel
from typing import Optional, List # For type hints in examples
# Default retry parameters used if not overridden in the decorator call
DEFAULT_RETRY_PARAMS = {
"tries": 5, "delay": 0.5, "max_delay": 15,
"jitter": 0.1, "backoff": 2, "graceful": False
}
@contract(
pre_remedy: bool = False,
post_remedy: bool = True,
accumulate_errors: bool = False,
verbose: bool = False,
remedy_retry_params: dict = DEFAULT_RETRY_PARAMS # Uses defined defaults
)
class MyContractedClass(Expression):
# ... class implementation ...
passЭстетика ИИ-агентов: и снова... Claude Code
В догонку к предыдущему посту. На днях The Pragmatic Engineer опубликовали статью «How Claude Code is built», которая однозначно заслуживает внимания. Тезисно:
• От хакатона до бизнеса на $500 млн в год: идея началась как пробный скрипт в терминале, но когда модель стала сама «гулять» по импортам и читать кодовую базу, команда поняла, что это полноценный продукт — и решилась быстро вывести его наружу.
• Минимум кода вокруг модели: разработчики сознательно удаляли вспомогательную логику, чтобы ИИ сам брал на себя максимум работы. Это риск — меньше контроля и привычных «страховок», но выигрыш в скорости развития.
• Лёгкий, нестандартный стек: TypeScript + React (Ink) + Yoga для терминального UI, Bun для сборки. Решили не тянуть привычные тяжёлые фреймворки, чтобы обновления шли мгновенно.
• Рекордный темп: до 100 внутренних релизов в день, десятки прототипов за пару суток. Такую скорость поддержали «короткие циклы доверия»: фичи выпускаются рано, чтобы сразу получать фидбек, а не шлифовать месяцами.
• Дерзкий баланс свободы и безопасности: Claude Code может менять файлы и запускать команды, но каждое действие требует подтверждения. Разработчики сознательно дали модели широкие полномочия — с минимальным, но чётким контролем пользователя.
• Sub-agents за 3 дня: идею «агентов внутри агента» оформили в продакшн после двух провальных попыток — показав, что команда готова быстро рисковать и отбрасывать неудачные решения.
В деталях:
Как разработчику быстро вкатиться в тему LLM? Часть 5 (заключительная)
Часть 4
5. Мультиагентные системы и протоколы взаимодействия
Работая над нетривиальном агентом, разработчик может столкнуться с ситуацией, когда реализуемая им логика перестает укладываться в концепцию агента-соло. Например, когда разделение ролей, параллелизм, изоляция рисков или масштабируемость дают измеримую выгоду по качеству, времени или стоимости. Иногда перестает хватать контекстного окна, или промпт оказывается переусложненным из-за разнородности задач, или возникает необходимость использовать несколько различных моделей. В таких случаях переходят от одноагентных систем к мультиагентным (MAS), где каждый из агентов решает часть общей задачи. В такой системе нет единого центра – координация происходит либо за счёт прямого общения агентов, либо через некоторую общую среду. Основные концепции MAS неплохо описаны в этой статье.
Вот лишь некоторые возможные паттерны ролей агентов в MAS:
• Planner → Executors: планировщик дробит задачу, исполнители — узкоспециализированные агенты.
• Critic/Verifier: независимая проверка фактов/ограничений, «красные команды», контрафактуальная проверка.
• Tool-specialists: агенты-обёртки над конкретными инструментами (Bash, Snowflake, Jira).
• Memory/RAG-агенты: отдельный агент управление знанием (индексация, извлечение, цитирование).
О проектировании MAS неплохо написано тут.
Агентам в MAS нужно как-то взаимодействовать с окружением и друг-другом. С этой целью были созданы протоколы A2A от Google, и MCP от Anthropic. Поверхностно ознакомиться с ними поможет эта статья. Вкратце:
• MCP – представляет собой «универсальный разъём a-la USB» между LLM-агентом и внешними инструментами. Протокол вводит три роли участников: Host (основное приложение/интерфейс, где работает агент), Client (компонент-встроенный коннектор при модели) и Server (поставщик инструментов или данных). Фактически, Host координирует диалог и хранит общую память, Server предоставляет реализацию какого-то действия (например, доступ к базе знаний или вызов внешнего API), а Client-соединение позволяет модельному агенту запрашивать у Host доступные инструменты и вызывать их. За счёт этого агент может использовать произвольные инструменты через единый протокол, не требуя от разработчика писать для каждого API свой код обработки.
• A2A же — протокол «агент-агент», дополняющий MCP: если MCP фокусируется на подключении инструментов, то A2A стандартизирует коммуникацию между независимыми агентами (каждый из которых может быть отдельным сервисом). Агент в A2A публикует свой «карточку» с описанием возможностей, а другие агенты могут посылать ему задания через HTTP. В сочетании, MCP и A2A покрывают разные уровни: MCP – подключение одного агента к инструментам и контексту, A2A – связь между разными агентами.
Для начала работы с MCP неплохо также ознакомиться и с этой статьей.
Разумеется, изобретать заново архитектуры MAS и реализовывать протоколы взаимодействия особой необходимости нет — существуют специализированные фреймворки, в которых «всё уже украдено до нас». Наиболее популярным из них является CrewAI: Python-фреймворк, упрощающий создание и оркестрацию группы агентов. В нём вводятся основные сущности – Agent (автономный агент с определённой ролью и целями), Task (задача для агента), Crew (группа агентов, объединённых общей целью), Tool (внешний инструмент, которым могут пользоваться агенты). Фреймворк берёт на себя маршрутизацию задач между агентами и сбор результатов. Стартовать с ним поможет эта статья.
Более подробный обзор доступных открытых решений для разработки ИИ-агентов представлен здесь.
Задачка на потренироваться:
Доработать coding-агента из предыдущего задания, добавив к нему verifier-агента на базе другой reasoning-модели, верифицирующего полученные результаты.
———
На этом, серия постов про вкатывание в разработку для LLM подошла к концу. Но не рубрика «LLM для разработчиков». Stay tuned, как говорится☺️
Два «питомца» для ИИ-пентеста: CAI и PentAGI
Два годных проекта на случай, если захочется поиграться с ИИ-пентестированием веб-приложений.
CAI
Открытый фреймворк, реализующий функциональность ассистента пентестера.
• Сканы, поиск уязвимостей (SQLi, XSS, LFI) и базовая эксплуатация — всё в режиме автономного агента.
• Дружит с 300+ LLM (от OpenAI до Ollama), логирует действия через Phoenix и ставит guardrails, чтобы бот не сломал сам себя.
• В CTF-замерах оказался в среднем в 11 раз быстрее человека, а на отдельных задачах — в 3600 раз.
• Уже отмечен в TryHackMe и Hack The Box: находит бреши, читает /etc/passwd, но пока далёк от идеала — цепочки атак увы ещё не особо осиливает. Кожаный мешок с соответствующей экспертизой где-то рядом всё же нужен — агент далеко не всегда безошибочен и не во всем автономен.
PentAGI
По-настоящему автономный ИИ-пентестер со встроенными тулзами и собственной «долгой памятью»
• Более 20 классических инструментов (nmap, Metasploit, sqlmap и т.п.) прямо из коробки.
• Встроенный браузер и поиск (Google, DuckDuckGo, Tavily) для разведки.
• Векторная база знаний (PostgreSQL + pgvector), чтобы помнить свои прошлые результаты и выстраивать сложные цепочки последовательных атак в рамках одного дерева.
• Отчёты и метрики в Grafana/Prometheus, всё в Docker, разворачивается относительно легко.
• Ориентирован на топовые облачные LLM и весьма прожорлив до токенов (но оно того стоит).
Подытоживая: CAI — добротный инструмент для быстрой работы по низко-висящим фруктам, в то время, как PentAGI — тяжеловес, в хорошем смысле этого слова, для поиска полноценных деревьев атак. Оба проекта в целом хорошо показывают, куда идёт автоматизация вебсека, что не может не радовать...
...или пугать, это уж как посмотреть 😬
Repost from OK ML
Уязвимости в дата-репозиториях. Обзорно главное
Репозитории для анализа данных и ML - зона повышенного риска ⚠️. Быстрое прототипирование, работа с чувствительными данными и специфичные инструменты создают уникальные векторы атак.
Вот ключевые из них:
1. 🤫 Секреты в коде.
Самая распространённая и критичная уязвимость. Хардкод API-ключей (например, к AWS S3, OpenAI, базам данных), токенов доступа и даже паролей прямо в Jupyter Notebook, конфигурационных файлах и скриптах. При попадании такого кода в публичный репозиторий злоумышленники получают прямой доступ к платным сервисам и данным.
Лечение
‘git grep’ + ‘truffleHog’, ротация ключей, менеджер секретов.
2. 🧑💻 RCE через десериализацию
Библиотеки pickle и joblib - стандарты для сохранения ML-моделей в Python - небезопасны. Десериализация файла из ненадёжного источника может привести к выполению произвольного кода на машине.
Лечение
yaml.safe_load(), ONNX, sandbox.
3. 💻 Открытые ноутбуки
Юпитер ноутбуки, развёрнутые с настройками по умолчанию, часто остаются доступными для всех в сети (особенно в облаках). Пароли, токены и результаты запросов с конфиденциальными данными могут быть видны в интерфейсе.
Лечениеты в коде.
‘nbstripout’ аудит перед коммитом. Регулярно аудить права доступа (IAM) к S3-бакетам, базам данных и другим ресурсам. Принцип наименьших привилегий - база 🤭.
4. 🙈
DoS через загрузку моделей.
Эндпоинт для загрузки моделей без проверки размера файла может быть атакован путём отправки огромного файла, что приводит к переполнению диска и отказу в обслуживании (Denial-of-Service).
Data Poisoning. Злонамеренное изменение обучающих данных для подрыва работы модели (например, добавление в выборку для классификации спама писем с определённым словом, помеченных как "не спам").
Adversarial Attacks. Специально сконструированные входные данные, предназначенные для обмана модели (например, незаметные для человека изменения в изображении, заставляющие модель видеть не то, что есть на самом деле)
Лечение
Pre-commit хуки, сканирование в CI/CD, обучение DS основам безопасности.Менеджеры секретов, безопасные форматы сериализации, инструменты для мониторинга (Evidently AI, WhyLabs).
#DataSecurity #MLSecurity #PickleRCE #SecretsManagement #DevSecOps
🔗 Полезные ссылки:
1. TruffleHog— сканер секретов
2. nbstripout — очистка ноутбуков
3. OWASP Top 10 — главные уязвимостиRepost from DevOps Deflope News
Новый выпуск — и он про безопасность!
В нём эксперт по Application Security из Positive Technologies Владимир Кочетков рассказывает:
• что будет, если вообще забить на безопасность;
• почему от уязвимостей бизнес-логики «никогда в жизни не защитит» даже самый крутой AF;
• правда ли, что хакеры теперь умнее нас из-за ИИ;
• как внедрить безопасность, чтобы тебя не возненавидели все разработчики.
Слушать →
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте
Принял участие в подкасте DevOps Deflope. Поболтали чуть за безопасную разработку и смежные с ней темы 😍
В разы быстрее, на порядок опаснее: исследование безопасности ИИ-разработки от Apiiro
На фоне растущей тенденции повсеместного и обязательного (а, в некоторых случаях, и принудительно-карательного) внедрения ИИ-решений в процессы разработки, компания Apiiro задалась вопросом о влиянии ИИ-ассистентов на безопасность кода. Исследование, к сожалению, получилось не воспроизводимое и аффилированное, поскольку сама компания является поставщиком ИИ-агентных решений AppSec.
Однако, в общую картинку почему-то хочется верить. Даже если допустить, что выводы там существенно искажены в удобную компании сторону, упоминаемая ими тенденция размена ИИ-ассистентами простых багов на более опасные и трудноуловимые архитектурные и логические уязвимости, в целом — очень похожа на правду:
AI assistants are good at catching the small stuff. Our analysis shows trivial syntax errors in AI-written code dropped by 76%, and logic bugs fell by more than 60%. But the tradeoff is dangerous: those shallow gains are offset by a surge in deep architectural flaws. Privilege escalation paths jumped 322%, and architectural design flaws spiked 153%. These are the kinds of issues scanners miss and reviewers struggle to spot – broken auth flows, insecure designs, systemic weaknesses.Чудес не бывает. На чем LLM обучили, на том она и хороша. А в сети — тьма открытого кода с пока ещё не найденными уязвимостями этих и аналогичных им hardcase-классов 😕 С помощью ИИ-ассистентов можно получать хороший, стабильный и безопасный код. Но для этого его нужно уметь писать и без них, формулируя соответствующие требования на входе, и проводя ревью результатов на выходе. Ну, и иметь в качестве fallback'а за спиной выстроенные и работающие процессы тестирования и безопасной разработки. И тут было бы уместно завершить пост красивой установкой, прозвучавшей в исследовании: «внедряете ИИ-кодеров, внедряйте и ИИ-аппсеков», если бы не одно но... Несмотря на ожидаемый в конце исследования призыв «покупайте наши решения», там почему-то отсутствуют такие же красивые диаграммы, показывающие влияние предлагаемых решений на общую картину. А ведь это напрашивается в такой публикации само собой. Видимо аргумент о «чудес не бывает» — пока ещё актуален по обе стороны баррикад 🤷♂️
Абстрактная интерпретация и символьное выполнение: в чем разница?
собратьями по несчастью коллегами. Дело в том, что эти два подхода к анализу приложений здорово путают, а иногда считают одно подмножеством другого. На самом деле, все чуть сложнее)
При символьном выполнении код интерпретируется, или выполняется, в соответствии с подмножеством семантики целевого языка, заменой всех неизвестных значений (входных данных) символьными переменными и вычислением формул в модели памяти, вместо конкретных значений. Подмножеством — потому что, невычислимые и сложно-вычислимые конструкции (вроде циклов и рекурсии, инварианты которых включают символьные переменные) упрощаются различными способами, про которые в академическом мире пишут целые диссертации. В реальном же мире SAST, как правило, просто ограничиваются «прокруткой» таких конструкций фиксированное количество раз или охапкой эвристик.
Основной челлендж разработчиков SAST, работающих в парадигме символьного выполнения: приемлемая аппроксимация семантики языка и эффективное решение проблемы экспоненциального роста путей выполнения или множества значений. Короче, долго, «дорого» (в плане сложности реализации), но относительно точно.
Абстрактная интерпретация же — это размен точности на скорость, при примерно той же «стоимости». Вместо неизвестных значений берутся их приближения: «переменная
В любой непонятной ситуации, когда станет совсем скучно — заводи спор о терминологии...Пост родился по мотивам вчерашних обсуждений с
x в [0..10]», или «переменная y чётная», или (в продвинутых техниках) «переменная s определяется конечным автоматом [a-zA-Z]+». Это формирует т.н. домен интерпретации. И далее осуществляется интерпретация кода в соответствии с определенным доменом. Анализ завершается в куда более приемлемое время, и охватывает все пути, но ценой роста процента ложных срабатываний.
Проще пояснить на примере вычисления цикла:
def g(x):
while x < 100:
x = x + 2
return xk;
– выводит через интерпретацию уравнение x0 + 2k = 100 и ищет его решения;
– находит, например, x0 = 0, k = 50;
– крутит цикл k раз.
Относительно точно, но для сложных циклов всё же нужны инварианты (см. диссертацию выше), иначе анализ взорвётся по путям выполнения. На практике, в реальных приложениях, для подобного цикла — это произойдет задолго до приближения к 50-ой итерации.
Абстрактная интерпретация (интервальный домен):
– начнём с x ∈ [0..50];
– каждую итерацию добавляем 2: [0..52] → [0..54] → …;
– рост бесконечный, поэтому применяем widening («перепрыгиваем» через растущие приближения, чтобы гарантировать быстрое достижение фиксированной точки, пусть и грубым образом) и прыгаем к границе [0..+∞);
– потом применяем narrowing (уточняем полученное приближение, чтобы вернуть часть точности, которую потеряли на шаге widening) и условие выхода из цикла уточняют результат до [100..+∞).
Интервалы говорят: «на выходе точно x ≥ 100», но теряют информацию о чётности.
Если взять домен «чёт/нечет», анализ сохранит инвариант: x ≡ x0 (mod 2). Это уже лучше, чем только интервалы, но и дороже.
Таким образом, эти два подхода действительно принадлежат одному семейству в том смысле, что осуществляют интерпретацию кода. Но символьное выполнение полагается в большей степени на упрощение семантики языка, в то время, как абстрактная интерпретация — на упрощение семантики данных, заданное на старте интерпретации.
Но вообще, отвечая на вопрос, является ли одно подмножеством другого... если у абстрактной интерпретации отрезать все ограничения на входные данные, и основанные на них техники вычисления циклов и рекурсии, но пришить при этом упрощение семантики языка, то из дедушки возможно и получится бабушка🤷♂️Эстетика ИИ-агентов: Claude Code
Последнее время появляется всё больше и больше хвалебных статей и отзывов о Claude Code. В некоторых из них его даже называют образчиком правильного подхода к разработке agentic-решений. Почему так?
Он прост, практичен, и вызывает минимум когнитивной нагрузки у своего пользователя 🤷♂️ Может и не блестяще, но весьма добротно решая при этом те задачи, под которые был разработан. Вот такой простой рецепт успешного успеха)
Не вполне уверен насчёт прям образчика разработки agentic-решений (насмотренности не хватает), но примером следования KISS, до ощутимого удовольствия в органах эстетического восприятия, Claude Code совершенно точно является. И, как по мне, вполне себе тянет на решение, из которого совершенно не зазорно заимствовать принципы и подходы при разработке собственных ИИ-агентов.
Относительно поверхностно ознакомиться с особенностями реализации Claude Code можно в статье «What makes Claude Code so damn good (and how to recreate that magic in your agent)!?» Детальнейший же (и весьма немаленький) разбор архитектуры и реализации этого агента доступен в отчете «Claude Code: An analysis». И, поверьте, там есть на что посмотреть)
Ну и, на всякий случай, вот ещё awesome-подборка материалов по Claude Code, чтобы попробовать его в деле, задействуя максимум возможностей, если вдруг ещё не.
🧩 Принципы и паттерны безопасной разработки: SRP
Хоть это и не вполне очевидно, но разработка безопасных приложений может (а, возможно, и должна) начинаться, отнюдь не с моделирования угроз, внедрения в код механизмов защиты, ревью безопасности, пентестов, внедрения SCA/SAST/DAST, или, тем более, чего-то, вроде хантовского «Hack Yourself First» ✝️ В лучших традициях Shift Left Security, начинать стоит с базовых принципов разработки, таких, как SOLID, YAGNI, DRY, KISS, чистый код с архитектурой и т.п. Именно они позволяют заложить в архитектуру и реализацию приложения правильный фундамент, на котором будет гораздо проще и дешевле реализовывать прочие решения и этапы внедрения DevSecOps.
Начнём с принципа единственной ответственности (Single Responsibility Principle, SRP — первая буква в SOLID), утверждающему, что каждый класс или модуль должен иметь единственную ответственность (только одну причину для изменения). С точки зрения безопасности SRP способствует изолированности компонентов и чётким границам доверия в коде, что существенно облегчает последующую работу с моделью угроз. Когда компонент сконцентрирован на одной задаче, его легче проверять на уязвимости и логические ошибки. Это снижает риск скрытых багов, возникающих при смешении разных обязанностей (например, проверка прав доступа вперемешку с бизнес-логикой). Как отмечают эксперты, соблюдение SRP «ограничивает случайную эскалацию привилегий и упрощает поиск ошибок», а также уменьшает общую поверхность атаки за счёт уменьшения сложности компонентов.
Тривиальный пример: допустим, класс UserAuth одновременно проверяет пароль пользователя и создаёт сессию при входе.
Нарушение SRP может выглядеть так:
class UserAuth {
public Session Authenticate(string username, string password) {
// Фрагмент, работающий с новыми пользователями
if (!PasswordChecker.IsStrong(password)) {
throw new Exception("Weak password");
}
var user = userRepository.CreateUser(username, password);
return sessionManager.StartSession(user);
}
}PasswordChecker, UserRepository, SessionManager), а UserAuth сделать оркестратором. Тогда код станет понятнее и безопаснее: каждая часть легко проверяется и тестируется отдельно.
Забавно, что «живым» примером последствий нарушения SRP является одна из наиболее нашумевших уязвимостей в библиотеке логирования Apache Log4j 2 CVE-2021-44228, известная как Log4Shell. Логирование — это задача записи сообщений, но Log4j помимо этого выполнял ещё и роль интерпретатора/поисковика ресурсов (JNDILookup). Фактически, в библиотеку логирования «просочилась» функциональность, выходящая за рамки её единственной ответственности — она не только записывала логи, но и могла выполнять сетевые запросы и загружать код. Если бы Log4j ограничился исключительно записью логов, без вычисления каких-либо lookup-выражений, уязвимость бы не возникла. И действительно, исправление проблемы заключалось в отключении/удалении функции JNDI Lookup из Log4j.
Соблюдение SRP помогает избежать многих CWE, связанных с логическими ошибками и неправильной проверкой условий, которые трудно выявить в нагромождённом коде. Например, SRP предотвращает появление скрытых дефектов управления доступом, из разряда CWE-732, CWE-862, возникающих, когда проверка прав смешана с другими функциями и может быть пропущена.
В целом, SRP укрепляет принцип «secure by design»: мелкие простые модули легче защитить и проверить.Как разработчику быстро вкатиться в тему LLM? Часть 4
Часть 3
4. Автономные ИИ-агенты
Итак, промпты писать научились, обогащать контекст актуальными знаниями с помощью RAG — тоже, но кое-чего ещё не хватает. Большинство привычных ИИ-сервисов представляют собой множество модулей, каждый из которых решает какую-либо конкретную задачу, планируя решение с помощью LLM и заданных правил, и имея в распоряжении внешний инструментарий для взаимодействия со внешним миром: от поиска в сети, до генерации и выполнения кода в реальной среде. Такие модули называются ИИ-агентами. Наиболее близкой и понятной разработчикам аналогией агентов в классической разработке, пожалуй, являются микросервисы.
Вообще, есть годные курсы по ИИ-агентам от Microsoft и Hugging Face, гайд от OpenAI, и исчерпывающий AI Agents Handbook, полностью погружающие в эту (и следующую, btw) темы. Но мы же здесь говорим о быстром старте?
AI-агенты — это автономные программы, способные самостоятельно планировать и выполнять задачи на основе целей пользователя. В основе агента обычно лежит LLM, далеко не всегда мощная, которая понимает запрос и формирует решение, и при необходимости использует инструменты — внешние функции, API или базы знаний. Проще говоря, вы даёте агенту задачу — он сам решает, что делать и как, действуя в цифровой среде подобно разумному ассистенту. Всю вводную информацию, необходимую для старта, можно подчерпнуть из статьи «AI-агенты на основе LLM и мультиагентные системы».
Различают два основных типа агентов: реактивные (мгновенно реагируют на входные данные) и проактивные (могут планировать шаги для долгосрочных целей). Как правило, агент состоит из нескольких ключевых компонентов, формирующих пайплайн решения задачи: восприятие, анализ, действие, память и т.п. Типам и структуре агента, организации взаимодействия между его компонентами, вместе с их базовой реализацией, посвящена статья «Agents 101: Как создать своего первого ИИ-агента за 30 минут».
Разумеется, здесь никуда без паттернов. Аналогом GoF в мире агентов является «Agentic AI Handbook: Design Patterns», описывающая свыше сотни различных шаблонов проектирования и разработки агентов. Наиболее популярными из них являются:
Workflow паттерны:
• Prompt Chaining — последовательный разбор задачи шаг за шагом (outline → проверка → генерация);
• Routing/Handoff — выбор исполнителя (агента или модели) для подзадачи;
• параллелизация — выполнение независимых шагов одновременно.
Agentic паттерны:
• Reflection — агент оценивает и улучшает свой ответ, устраняя ошибки и уточняя детали;
• Tool Use — агент использовать внешние инструменты (API, поиск, код) в процессе;
• ReAct (Reason + Act) — итеративный цикл: рассуждение → действие → наблюдение → повтор;
• Planning — разбивка задачи, создание плана с подзадачами и последовательное выполнение;
• Multi-Agent — распределение ролей между агентами, коллективное решение сложных задач (приведен для полноты картины, этой теме будет посвящена следующая часть).
Ознакомиться с подходами к реализации этих и других популярных паттернов можно в статьях:
«AI Agents Design Patterns Explained»
«Building effective agents»
«Zero to One: Learning Agentic Patterns»
Также, стоит упомянуть класс паттернов «Schema-Guided Reasoning» (SGR), позволяющий LLM создавать структурированные, понятные и предсказуемые результаты, удобные для дальнейшей обработки компонентами агента.
В качестве примеров готовых агентов и реализуемых ими кейсов можно смело брать на изучение проекты из репозитория «500 AI Agents Projects».
Задачка на потренироваться:
Пройти воркшоп «Build Your Own Coding Agent» и доработать получившийся проект, реализовав в нём функциональность поиска секретов в коде на основе связки сигнатурного поиска и оценки энтропии строковых литералов (или любой другой понятный вам кейс кодинга).
Repost from OK ML
4 секрета Roboduck. Как Theori взяли AIxCC и бустанули хакеров х10 🚀🚀🚀
Что ты представляешь, когда слышишь о системе, которая способна обнаруживать уязвимости, создавать эксплоиты, а также сразу выпускать патчи, устраняющие дыры прошлого? Theori, команда участвовавшая в соревновании AI Cyber Challenge попыталась решить эту сложную задачу, представив автономную CRS(Cyber Reasoning System) - RoboDuck. В этой системе используются агенты, но не как аддон, а как основа.
Почему система оказалась эффективной и почему получилось дополнить основу революции агентов в кибербезе?
🧩Секрет № 1. Разбивайте задачу на части, как пазл.
Главная идея - не тащить все одним супер-агентом. Делим на подзадачи и даем разным агентам. Представьте лабиринт: чем он больше, тем больше тупиков, логично? А теперь, что вместо одного огромного лабиринта у вас есть серия маленьких? Шансы найти выход резко возрастают!
Для генерации Proof of Vulnerability(PoV) команда выделила три подзадачи:
1. Анализ fuzz-harness и написание кода для преобразования семантики в бинарщину.
2. Ответы на точечные вопросы по коду.
3. Отладка готового PoV, чтобы понять почему эксплоит не срабатывает.
Каждую подзадачу вёл отдельный агент, а главный агент собирал результат в цельную картину.
⚒️Секрет №2. «Не все инструменты сразу - только нужные»
В ходе разработки решения команда обнаружила, что если агенту дозволено делать абсолютно всё, начинается хаос:
1. Агент может запустить прожорливую команду, которая съест все ресурсы (грепанём по всему коду в Линуксе 🙃)
2. Контекст засоряется - фокус теряется.
3. Простые задачи вдруг начинают требовать множества шагов 🤢..
Что сделали Theori ??? Они создали узкоспециализированные тулы: для поиска строки, для чтения фрагмента кода и для извлечения отдельных символов из кода. Плюс сами инструменты имели guardrails, которые могли сужать промпт в случае получения большого количества результатов.🤔
⛓️Секрет №3. Структурированный вывод от эксперта.
Как получить из агента не «простынь», а структурированный вывод/результат. Theori делится с нами двумя способами:
- Сперва дайте агенту схему вывода в XML и прямо попросите, чтобы он оформлял ответ в XML тегах. Модели хорошо их понимают.
- Далее создайте отдельный тул, который будет завершать работу агента, - своеобразная кнопка "Готово" с полями для заполнения😕. Когда параметры вызова совпадают с финальным результатом — агент аккуратно завершает работу без болтовни.
🎚️Секрет №последний, 4: Подстраивайтесь под особенности моделей 😮
Игнорирование факта что все LLM разные = неудача = ловить одни и те же фейлы. Команда обнаружила, что если агент делает одну и ту же ошибку, то лучше добавить в промпт запрещалку. Claude отлично следует этим запрещалкам 😎 - он любит когда ему что-то запрещают. Если агент застревает, то надо попросить его «подумать иначе» и сменить стратегию.
В соревновании это выстрелило, когда агент PoVProducer не смог создать пригодный эксплоит, но правила смогли дать нужный результат.
Как пишут в Theori: "Хотя ИИ ещё не заменит хакера, он уже делает его в 10 раз эффективнее".
🧨А с этими секретами го разрабатывать агентов для своих задач!😺
