Coding agents уже плохо помещаются в метафору чата. Когда оркестратор запускает субагентов, инструменты падают и повторяются, а человек отклоняет разрешение посреди выполнения, линейный лог сохраняет события, но прячет структуру. Rungraph предлагает вынести эту структуру на граф, и его стоит проверить сейчас, пока цена эксперимента ниже цены собственного интерфейса наблюдаемости.
Что именно показывает Rungraph
В Show HN автор Rungraph пишет, что инструмент сканирует локальные сессии Claude Code, Codex и Hermes Agent, запускает локальный сервер и открывает граф в браузере. Обёртки, хуки, предварительная настройка и телеметрия не нужны. Можно разобрать старую сессию с диска или смотреть текущую: граф растёт по мере работы агента через наблюдение за файлами.
Оркестратор, субагенты и инструменты становятся узлами. Связи запуска и возврата результатов становятся рёбрами. Вмешательства человека, включая отказ в разрешении, ответ на вопрос и прерывание, выделяются отдельно. На рёбрах указывается причина смены курса, например повтор после ошибки или действие после отказа.
Это уже больше, чем перекрашенный чат-лог. Параллельные агенты расходятся по отдельным дорожкам и возвращаются к ходу, который собирает их результаты. Узлы инструментов показывают не только название, но и конкретное действие: запуск тестов, редактирование файла или поиск строки. Последовательные вызовы одного инструмента сворачиваются в один узел, но по клику доступны входы, выходы, ошибки и длительность каждого вызова.
Rungraph также размечает узлы моделями, токенами и временем, считает итоги по запуску, связывает шаги с затронутыми файлами и выводит отдельную полосу сигналов. По заявлению автора, сигналы пересчитываются во время живого запуска, а клик подсвечивает связанные узлы, не скрывая остальную схему. Через MCP агенту можно задать вопрос о конкретном запуске, получить ответ в терминале и подсветить на графе шаги, на которых этот ответ основан.
Есть техническая оговорка: для чтения запусков Hermes нужен Node версии 22.13 или новее. На старых версиях такие сессии пропускаются с предупреждением, остальные продолжают работать.
Главный продукт здесь не граф
Сам по себе граф ничего не доказывает. Запутанный лог можно превратить в не менее запутанную паутину, добавить плавный zoom и получить observability-театр. Полезность Rungraph начинается только там, где он даёт новый диагностический ответ быстрее исходного транскрипта.
У продукта есть три шанса пройти эту проверку. Первый: ветвление должно сразу показывать, какой субагент ушёл в тупик и куда вернулся его результат. Второй: свёрнутые повторные вызовы должны выделять цикл вроде test-fix-test, не заставляя искать двенадцатый запуск команды по тысячам строк. Третий: сигналы и данные о токенах, длительности и ошибках должны локализовать дорогой или сломанный участок, а не просто украшать его красным маркером.
Пока подтверждение этому исходит из описания самого проекта. В пакете нет независимого сравнения с линейным логом, данных о времени разбора инцидентов или результатов использования командой. Поэтому покупать тезис о превосходстве графа рано. Но и ждать зрелой платформы необязательно: Rungraph работает с уже записанными локальными сессиями и не требует менять агентный харнесс. Для команды это редкий случай, когда спор об интерфейсе можно решить на собственных данных, а не на демо автора.
Категория уже начинает обрастать инструментами. В июне и июле на Hacker News появлялись локальный dashboard Noter, проект AgentsProof для трассировки и evals, Graph Context Engine и Git-репозиторий для общения coding agents. Обсуждения почти не было: у этих публикаций от нуля до одного комментария. Рынок пока не выбрал стандарт, поэтому привязывать разбор сбоев к очередному харнессу или строить свою панель сейчас особенно рискованно.
Как принять решение за несколько запусков
Возьмите несколько завершённых сессий, где причина сбоя уже известна: повторяющиеся тесты, неудачное редактирование, потерянный результат субагента, отказ в разрешении. Сначала найдите причину по обычному транскрипту, затем по Rungraph и запишите время и точность ответа. Отдельно проверьте, видны ли дорогие tool calls и шаги, затронувшие конкретный файл, включая работу субагентов.
Маркер простой: если граф стабильно приводит к правильному узлу быстрее лога и показывает циклы или ветки, которые приходилось восстанавливать вручную, его стоит оставить в отладочном контуре. Если команда всё равно открывает полный транскрипт и ищет ошибку там, Rungraph пока лишь рисует тот же лог в двух измерениях. За такую геометрию платить временем не нужно.