Ты когда-нибудь пытался вытянуть из GPT или Claude красивую блок-схему архитектуры микросервисов, а получал сухой ASCII-арт? Или таблицу, которую невозможно читать? Я — да, и это бесило. Пока я не наткнулся на простую, но грязную истину: LLM отлично генерируют HTML. А значит, и визуальные диаграммы — прямо в чате. Никаких плагинов, никаких mermaid-превью. Только промпт и немного наглости.
Почему Markdown — это тупик для диаграмм
Markdown удобен для текста, но для графики он — костыль. Mermaid? Работает только если клиент его поддерживает. А если бот в Telegram или в корпоративном веб-чате? Mermaid там просто нет. ASCII-графика выглядит как артефакт из 90-х. А таблицы с псевдографикой — ад для глаз.
HTML же рендерится почти везде. Даже если чат вырезает скрипты и стили, SVG остаётся. Браузеры, в которых открыт чат, умеют рисовать SVG без дополнительных библиотек. А LLM, особенно современные вроде Claude 4 или GPT-5 (по состоянию на май 2026), отлично генерируют корректный SVG-код.
Проблема: агенты не умеют рисовать по умолчанию
Большинство инструкций для LLM по умолчанию просят возвращать Markdown. Потому что это дешевле по токенам и проще для парсинга. Но когда нужно показать схему зависимости сервисов или граф вызовов, Markdown пасует.
Я перепробовал десятки подходов: от просьбы нарисовать Mermaid (ответ приходится конвертировать отдельным шагом) до генерации PlantUML (нужен сервер). Всё это — лишние движения. Агент сам может родить готовую картинку, если правильно попросить.
⚠️ Важно: не проси агента "нарисовать диаграмму" абстрактно. Он может вернуть ASCII или ссылку на сторонний сервис. Нужно чётко указать формат — HTML/SVG.
Решение: промпт, который заставляет генерировать HTML
Ключ — в явном указании структуры ответа. Вместо мягкого "нарисуй схему" мы даём жёсткий шаблон: "Верни результат в виде валидного HTML документа. Для графических элементов используй inline SVG. Не используй Markdown, только HTML."
Вот пример системного промпта для агента (я использую его в своих проектах, и он работает на Claude, GPT и Qwen):
Ты — AI-ассистент, который отвечает ТОЛЬКО на HTML. Никакого Markdown, никаких текстовых описаний. Если нужно что-то визуализировать — используй inline SVG внутри HTML. Оберни всё в <div> с базовыми стилями (цвета, отступы). Убедись, что SVG самодостаточен и не ссылается на внешние ресурсы. Минимизируй текстовые комментарии — всю суть показывай графически.После этого агент начинает генерировать ответы наподобие такого:
<div style="font-family: sans-serif;">
<h3>Архитектура микросервисов</h3>
<svg width="400" height="300">
<rect x="10" y="10" width="100" height="50" fill="#4A90D9" rx="8"/>
<text x="30" y="40" fill="white" font-size="14">API Gateway</text>
<rect x="150" y="10" width="100" height="50" fill="#50C878" rx="8"/>
<text x="165" y="40" fill="white" font-size="14">Auth Service</text>
<!-- ... линии связи, больше прямоугольников ... -->
</svg>
</div>Чат рендерит этот HTML, и пользователь видит настоящую диаграмму. Никаких костылей.
1 Настройка агента — добавь в системное сообщение правило HTML-only
Если ты используешь агентную архитектуру вроде Claude Code, просто добавь это правило в контекст. Оно переопределяет дефолтное поведение.
2 Убедись, что чат поддерживает HTML (хотя бы частично)
Большинство web-чатов (включая популярные дашборды для LLM вроде Open WebUI, ChatUI) поддерживают basic HTML. Если чат вырезает теги — используй альтернативные каналы: например, отправляй результат через Webhook в html-письмо. Но 90% случаев — работает из коробки.
3 Проверь SVG на валидность
LLM иногда генерируют SVG с синтаксическими ошибками (закрывающие теги не на месте, неправильные координаты). Лучше прогнать ответ через простой валидатор. Но на практике даже с мелкими ошибками браузер рендерит большую часть.
Типичные ошибки и как их избежать
Я наступил на все грабли, чтобы ты не наступал. Вот самые частые:
- Агент возвращает Markdown-код с HTML внутри — проблема в том, что LLM видит в своих тренировочных данных Markdown как обёртку. Решение: явно запретить Markdown и сказать "HTML — единственный разрешённый формат".
- Слишком много токенов — SVG может быть объёмным. Для сложных диаграмм с сотнями элементов расход токенов резко растёт. О том, как это влияет на стоимость, читай в статье "Токены под микроскопом".
- Чат вырезает SVG из соображений безопасности — некоторые корпоративные чаты блокируют SVG из-за риска XSS. Выход: использовать base64-encoded SVG как src data:image/svg+xml;base64,... в img-теге. Это безопаснее.
- Агент забывает про стили — если не задать явно цвета, шрифты, отступы, диаграмма будет серой и нечитаемой. Пропиши в промпте "используй цветовую гамму, понятную для цветовой слепоты" — поверь, это спасёт.
Когда этот метод бесполезен
Давай честно: есть кейсы, где HTML не поможет.
- Чат не рендерит HTML вообще — например, Telegram API принимает только text/plain. Тогда только картинки через generate_image tool.
- Агент работает в консоли — CLI-интерфейсы не отображают HTML. Тут только ASCII или эмодзи-схемы.
- Нужны интерактивные диаграммы — с дрилл-дауном, кликами. SVG — статичен. Для интерактива лучше генерировать код на React/Vue и отдавать как iframe, но это уже уровень выше.
Если твой юзкейс подходит — читай дальше про продвинутые трюки.
Продвинутые трюки: динамические данные и легенды
Можно пойти дальше и заставить агента генерировать диаграммы на основе переданных данных. Например, передать JSON с метриками и попросить нарисовать столбчатую диаграмму. Промпт выглядит так:
Тебе передан JSON с данными. Сгенерируй HTML+SVG, который визуализирует эти данные в виде столбчатой диаграммы. Подпиши оси, добавь легенду. Не используй Markdown.Модель справляется отлично — она умеет масштабировать значения, подбирать цвета и даже добавлять анимации через CSS. Это превращает агента в полноценный генератор отчётов.
Кстати, для организации таких сессий с агентами полезно прочитать "Контекст-инжиниринг для coding-агентов" — там описано, как не потерять контекст при длинных диалогах.
Безопасность: не дай агенту сломать чат
Главный страх — XSS. Если агент вставит в SVG скрипт, а чат не экранирует — беда. Поэтому:
- Добавь в промпт инструкцию: "Не используй теги <script>, <iframe>, <object>. Только статичный SVG".
- На стороне клиента можно прогнать ответ через DOMPurify или аналоги.
- Используй режим img с data URI, как упоминалось — браузер не выполнит скрипты внутри img.
💡 Совет: если чат поддерживает только text/html, но не SVG — можно конвертировать SVG в PNG через headless браузер (Puppeteer) и вставлять как обычное изображение. Это сложнее, но безопаснее.
Альтернативы: что ещё пробовали и почему это лучше
Я тестировал несколько подходов, прежде чем остановился на HTML+SVG:
- Mermaid через iframe — требует серверного рендеринга. Лишняя инфраструктура.
- PlantUML — ещё один сервис, который надо поднимать.
- ASCII-art — дешево, но нечитаемо для сложных схем.
- Генерация PNG через сторонние API — дорого и медленно.
HTML+SVG — это zero-infrastructure: ничего не надо поднимать, всё уже есть в браузере пользователя. Да и агенты пишут SVG гораздо качественнее, чем, скажем, LaTeX.
Что дальше: куда движется технология
Уже сейчас мультимодальные модели (GPT-5 Vision, Claude 4, Gemini 3) могут сами генерировать картинки, но они возвращают ссылки или base64, что не всегда удобно. Встраивание SVG прямо в ответ — более гибкий путь. Я предсказываю, что через год-два LLM по умолчанию будут использовать HTML для визуализации, а Markdown останется только для простых текстов.
Если хочешь глубже погрузиться в управление агентами и их визуальным выводом — посмотри обзор Grapheteria и других опенсорсных GUI. Там как раз поднимается тема визуализации работы агентов.
А пока — бери этот хак и используй. Твой следующий агент сможет не только писать код, но и рисовать архитектуру. И это буквально меняет правила игры.
