Dynamo, pyRevit, C#-плагин или MCP: чем автоматизировать Revit

Инструмент выбирают под задачу, а не по силе

Спор о том, что лучше — Dynamo, pyRevit, C#-плагин или AI-агент, обычно не приводит к решению, потому что сравниваются разные категории. Визуальное программирование, скриптовый слой, полноценный аддон и оркестрация через естественный язык решают разные задачи и требуют разных затрат на поддержку.

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

Ниже — честное сравнение без выдуманных замеров. Цифры производительности здесь не приводятся намеренно: они зависят от модели, версии, железа и характера задачи, а не от того, какой инструмент «быстрее вообще». Любой, кто называет точный процент ускорения без описания методики замера, скорее всего продаёт курс.

Ещё одно замечание перед разбором: все четыре подхода работают с одним и тем же API Revit. Различается не доступ к модели, а способ его выразить, скорость итерации, способ поставки и цена поддержки.

Dynamo: визуальное программирование

Dynamo — среда визуального программирования: узлы и связи описывают поток данных от чтения модели к записи. Сильная сторона — скорость входа и наглядность. Инженер без опыта разработки собирает параметрический сценарий за вечер и видит логику происходящего на схеме, а не в исходном коде.

Область применения: параметризация, обработка данных, генеративные расчёты, выгрузки и разовые преобразования, где важна логика потока, а не пользовательский интерфейс. Здесь Dynamo выигрывает: изменить один входной параметр и увидеть перестройку результата проще, чем перекомпилировать плагин.

Ограничения выявляются при попытке сделать из графа продукт. Графы плохо переносят сложные ветвления и циклы, их трудно версионировать и ревьюить построчно, а поведение инструмента завязано на версию пакетов и порядок узлов. Раздать граф команде можно, но он остаётся скриптом: пользователь видит схему, а не окно с понятными полями и кнопками. Для инструмента с предсказуемым интерфейсом, обновлениями и поддержкой Dynamo подходит хуже.

Практический вывод: Dynamo — отличный инструмент исследования и параметрики, но плохая основа для продукта, которым пользуется отдел каждый день.

pyRevit: Python и короткий цикл правки

pyRevit добавляет в Revit слой на Python: кнопки, панели, скрипты, выполняемые прямо внутри приложения. Главное преимущество — короткий цикл: изменили файл, нажали кнопку, увидели результат. Порог входа ниже, чем у C#, а доступа к API достаточно для большого класса задач.

Хорошо работает там, где нужна быстрая автоматизация конкретного рабочего места: инструмент для своего отдела, проверка, обмен данными, вспомогательные утилиты. Python-код легко читать и править, поэтому решение продолжает жить, даже если его автор перешёл на другой проект.

Ограничения связаны с распространением и версиями. Развёртывание опирается на внешнюю среду — установленный хост, набор пакетов, интерпретатор; на разных версиях Revit набор доступных библиотек различается, а ветка .NET меняется вместе с версией приложения. Тонкие места: контроль версий у конечных пользователей, поставка зависимостей и производительность на больших объёмах. Тяжёлые операции на Python внутри Revit требуют осторожности, потому что API однопоточный и обращение к документу идёт на потоке приложения.

Практический вывод: pyRevit — лучший выбор для быстрых личных и внутрикомандных утилит, когда важна скорость появления решения, а не формальная поставка.

C#-плагин: полный доступ к API

Аддон на C# — родной для Revit формат: сборка загружается приложением, регистрирует команды в ленте и работает с API напрямую. Это даёт полный доступ к возможностям платформы, предсказуемую производительность и настоящий интерфейс — окна, панели, поля, диалоги, состояния.

Такой инструмент можно распространять как продукт: установщик, версия, обновление, поддержка, обратная связь. Именно поэтому серьёзные инструменты для проектных отделов пишут на C#, а не собирают из графов и скриптов.

Цена — более высокий порог входа. Нужна среда разработки, понимание типов, сборки и работы с потоком Revit. Изменения модели выполняются в транзакциях: без открытой транзакции операция не применится, и ошибка в этом месте выглядит как «ничего не произошло». API однопоточный: обращение к документу идёт с того же потока, а обмен с внешним процессом строится через очередь, а не напрямую из сетевого потока.

Версии требуют отдельного внимания. Revit 2022–2024 работают на .NET Framework 4.8, Revit 2025 и новее — на .NET 8, а поддержка заявлена для релизов 2022–2027. Это значит, что сборку нужно вести под несколько целевых платформ, а не под одну, и проверять на каждой версии, которую вы обещаете поддерживать.

Практический вывод: настройка дороже, зато результат — компонент, который можно версионировать, тестировать и передавать команде как продукт, а не как папку со скриптами.

MCP и AI-агент: оркестрация естественным языком

Подход с MCP строится иначе. Плагин публикует набор инструментов по протоколу Model Context Protocol, а AI-клиент вызывает их, ориентируясь на текстовый запрос. Пользователь формулирует задачу словами, а не собирает граф и не выбирает кнопку в панели.

Сильная сторона — ad-hoc задачи и чтение. Агенту не нужен заранее написанный сценарий под конкретную проверку: можно спросить «найди помещения без номера и сгруппируй по уровню» и получить список. Для разовых вопросов к модели это заметно быстрее, чем собирать отдельный инструмент.

Требуется серверная часть. Нужен C#-плагин, который поднимает MCP-сервер и описывает каталог инструментов: без него агенту нечего вызывать. Возможности ограничены каталогом — чего нет в списке инструментов, того агент не сделает, сколько бы убедительно ни звучал запрос.

Неопределённость — встроенное свойство подхода. Один и тот же запрос может привести к разным вызовам, а модель способна уверенно сообщить неверный вывод. Поэтому запись выполняется под надзором: сначала план с количеством затронутых элементов и идентификаторами, затем подтверждение человеком, затем применение в транзакции. Изменения модели в любом случае идут через транзакции Revit — на это правило не влияет ни инструмент, ни агент.

Границы применимости честнее обозначить прямо: ad-hoc и задачи чтения — да; массовые детерминированные преобразования — лучше кодом или плагином; чувствительные данные — только по решению организации, потому что AI-клиент передаёт запрос и ответ выбранному провайдеру.

Где находится продукт RevitAiTools

Важно понимать место продукта в этой картине. Репозиторий RevitAiTools — это C#-аддон, который дополнительно поднимает MCP-сервер. То есть продукт не является ни надстройкой над Dynamo, ни скриптовым слоем: он сам и есть C#-плагин, к которому добавлен слой инструментов для AI-клиента.

Практический вывод для команды: разбор архитектуры плагина, транзакций и обмена с AI-клиентом применим и к обычной разработке аддонов. Если вы делаете инструмент для отдела, вы всё равно будете решать те же задачи — контракт инструмента, очередь на потоке Revit, целевые платформы и версии .NET.

Доступ к репозиторию устроен как снимок. Первоначальный платёж открывает приватный GitHub-репозиторий, и полученный снимок кода остаётся у покупателя. Это не открытый исходный код, и он не публикуется. Доступ к актуальной версии, обновлениям и сообществу действует 30 дней. Условия и актуальная цена — на главной странице.

Сравнение по сильным сторонам и ограничениям

Таблица решений: задача — инструмент — почему

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

Что выбрать для команды

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

• Стабильная повторяемая функция для отдела — C#-плагин. Её пишут один раз, поддерживают и обновляют.
• Быстрые личные утилиты и эксперименты — pyRevit. Здесь важна скорость появления решения, а не формальная поставка.
• Параметрика и работа с данными — Dynamo, когда нужно видеть логику потока и перебирать варианты.
• Вопросы и чтение по запросу — MCP и AI-агент поверх сервера инструментов, когда сценарий заранее неизвестен.

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

Отдельно про компетенции. Навык Python и навык работы с Dynamo не заменяют понимания API, но заметно снижают цену входа. C#-плагин требует больше времени, зато навык переносится на любую версию: меняется целевая платформа .NET, но структура плагина, работа с транзакциями и однопоточность API остаются теми же.

Ещё один критерий — кто отвечает за поддержку. Скрипт на Python и граф Dynamo живут ровно до тех пор, пока их автор в отделе; если человек уходит, решение обычно умирает вместе с ним. Плагин требует более дорогой разработки, но его можно передать другому разработчику: структура проекта, сборка и целевые версии описаны явно. Поэтому для функций, которыми отдел будет пользоваться годами, выбирайте формат с владельцем, а не тот, который быстрее собрать сегодня.

И последнее: не смешивайте выбор инструмента с выбором модели. Инструмент определяет, как решение живёт и обновляется, а модель определяет, насколько точно агент формулирует вызовы. Можно заменить провайдера, не переписывая плагин, и нельзя заменить плагин, не переписав граф. Разделяйте эти решения, чтобы каждое можно было пересмотреть отдельно, без переделки всего контура автоматизации.

Общие ошибки и ограничения

• Автоматизировать неустоявшийся процесс. Инструмент закрепляет беспорядок и делает его обязательным для всех.
• Тащить всё в один инструмент. Граф для продукта, скрипт для тяжёлых операций, плагин для разовой задачи — типовой набор неверных решений.
• Игнорировать версии. Сборка под .NET Framework 4.8 не подхватится на .NET 8, а поддержка заявлена для релизов 2022–2027; проверять нужно каждую обещанную версию.
• Обращаться к документу из фонового потока. API однопоточный, обращения ставятся в очередь на поток Revit; обход этого правила даёт нестабильность.
• Менять модель без транзакции. Операция просто не применится, и это будет выглядеть как молчаливый отказ.
• Ожидать от агента детерминизма. Для повторяемых операций нужен код, а не формулировка на естественном языке.
• Верить процентам без методики. Замер без описания условий ничего не доказывает, а решение, принятое по такой цифре, обычно разочаровывает.

Как начать

Сформулируйте задачу, срок жизни решения и владельца поддержки. Разовая задача — Dynamo или pyRevit. Повторяемый инструмент отдела — C#-плагин. Вопрос к модели — MCP и AI-агент. Дальше выберите ближайший материал по вашей ситуации.

Устройство связки агента и модели разобрано в материале «MCP для Revit», базовая работа с платформой — в «Revit API для начинающих», состав инструментов — в каталоге RevitAiTools.

Практические шаги и разборы входят в доступ к приватному репозиторию RevitAiTools и курсу. Первоначальный платёж открывает приватный GitHub-репозиторий, и полученный снимок кода остаётся у покупателя; это не открытый исходный код. Доступ к актуальной версии, обновлениям и сообществу действует 30 дней. Условия и актуальная цена — на главной странице.