Вы путаете инструмент для запуска моделей (Ollama) и систему прямого управления ОС. Это разные слои. Агент на Claude должен быть специально написан под каждую задачу. T-HS Bridge даёт готовую, единую среду для любой модели без дополнительного кодинга. В этом разница архитектурных подходов. Не в моделях, а в способе их связи с реальным миром.
T-HS Bridge — не агент. Он не „пытается понять“, он точно парсит DOM чата и выполняет команды в ОС. Без нейросетей, без неявных паттернов. Детерминированный парсер. Полгода без сбоев.
Почему не API? Потому что это привязка к облаку, токенам и посреднику. Мост работает напрямую, даже с локальными моделями. Никаких API-ключей, никакой ежемесячной платы.
Почему не плагин для браузера? Потому что мост — это самостоятельное приложение с ядром на Python и Qt. Оно управляет ОС, а не расширяет функционал чужого софта. Сравнивать плагин с операционной системой для ИИ — ну такое себе.
Прорыв в том, что ИИ получил настоящее тело в Windows без облаков, без серверов и без MCP. 300 команд, планировщик, голос, FTP, SSH — в 180 МБ с флешки. Повторите такое же — тогда поговорим. Всю информацию я вам предоставил осталось перейти по ссылке и посмотреть.
T-HS Bridge не использует клиент-серверную архитектуру. Это монолитное приложение с прямым доступом к ОС через Python и Qt. MCP — протокол, мост — инструмент. Почувствуйте разницу T-HS Bridge — это GUI-приложение на PyQt6 со встроенным WebEngine. Мы не сервер, мы браузер. ИИ пишет сообщение в чат DeepSeek или друго ИИ мост его видит через DOM, парсит и выполняет как команду на компьютере. Всё работает на одной машине, в одном процессе. Никаких серверов, никаких протоколов. Обычный браузер, обычный чат, прямое управление ОС. В этом и есть прорыв. MCP такого не делает и не может — у него принципиально другая архитектура! Уникальность T-HS Bridge ещё и в особеном парсере. Он работает напрямую с DOM чата, извлекает команды ИИ без ошибок. За последние полгода — ни одного сбоя в парсинге. Система стабильна как часы. Именно это позволяет мосту работать без серверов и протоколов — мы читаем намерение ИИ прямо из интерфейса чата и тут же выполняем их на ПК, ядро возвращает результат в чат ИИ. ИИ понимает что команда выполнена и с каким результатом. Так же видит файлы и так же все остальное.
MCP работает через сервер и протокол. T-HS Bridge — это прямое управление ПК через собственное ядро на Python и Qt. Без облаков, без токенов, без сторонних сервисов. Почитайте описание внимательнее посты по ссылке.
А я вообще придумал способ дать любому чату ИИ управлять ПК, без всяких там платных API. Только не могу тут стаью закинуть, оказалось что это не так просто..
Отличный разбор, спасибо. Особенно ценно, что вы показали не просто «западные модели не подходят», а конкретно — по каким составам и почему.
У нас сейчас в T‑HS Bridge мы сделали ровно то, с чего вы начинаете: ядро с системой плагинов и безопасностью. И ваш кейс — идеальный пример того, как должен выглядеть специализированный плагин: не «ещё одна LLM», а инженерный инструмент под конкретный УК/КоАП, с аудитом и заморозкой версий.
Почему это важно:
«Дообучить чужую модель» — действительно не выход. Нужна своя маленькая модель (1–3B), которую можно переобучить под российскую таксономию. Быстро, дёшево, предсказуемо.
Маркировка иноагентов (ФЗ‑255) — это вообще не семантическая задача, а regexp + проверка по списку. И это не минус, а плюс: такие вещи должен решать не LLM-модуль, а отдельный классификатор.
Аудит по 149‑ФЗ — вы правильно про хэш и версию модели. Мы в мосте для других задач используем тот же принцип: фиксируем версию плагина, вход и выход, чтобы можно было воспроизвести решение через год.
Вопрос вам тоже: а что с «дискредитацией» (ст. 20.3.3)? Там ведь не только явные высказывания, но и подразумевания. LLM тут может быть полезна, но как вы планируете бороться с ложными срабатываниями? Или в этом случае всё равно остаётся человек в петле?
Отличная статья. Особенно ценно, что показали не только "что работает быстрее", а как меняется логика запроса при разных типах маскирования. Ваш вывод про хэширование как компромисс — самый важный: аналитику сохраняет, но за скорость приходится платить. У нас в T‑HS Bridge похожая дилемма с безопасностью: рутина без подтверждения, опасное — с запросом. Выбор типа защиты — это всегда компромисс между скоростью и контролем.
Вы путаете инструмент для запуска моделей (Ollama) и систему прямого управления ОС. Это разные слои. Агент на Claude должен быть специально написан под каждую задачу. T-HS Bridge даёт готовую, единую среду для любой модели без дополнительного кодинга. В этом разница архитектурных подходов. Не в моделях, а в способе их связи с реальным миром.
T-HS Bridge — не агент. Он не „пытается понять“, он точно парсит DOM чата и выполняет команды в ОС. Без нейросетей, без неявных паттернов. Детерминированный парсер. Полгода без сбоев.
Почему не API? Потому что это привязка к облаку, токенам и посреднику. Мост работает напрямую, даже с локальными моделями. Никаких API-ключей, никакой ежемесячной платы.
Почему не плагин для браузера? Потому что мост — это самостоятельное приложение с ядром на Python и Qt. Оно управляет ОС, а не расширяет функционал чужого софта. Сравнивать плагин с операционной системой для ИИ — ну такое себе.
Прорыв в том, что ИИ получил настоящее тело в Windows без облаков, без серверов и без MCP. 300 команд, планировщик, голос, FTP, SSH — в 180 МБ с флешки. Повторите такое же — тогда поговорим.
Всю информацию я вам предоставил осталось перейти по ссылке и посмотреть.
T-HS Bridge не использует клиент-серверную архитектуру. Это монолитное приложение с прямым доступом к ОС через Python и Qt. MCP — протокол, мост — инструмент. Почувствуйте разницу
T-HS Bridge — это GUI-приложение на PyQt6 со встроенным WebEngine. Мы не сервер, мы браузер. ИИ пишет сообщение в чат DeepSeek или друго ИИ мост его видит через DOM, парсит и выполняет как команду на компьютере. Всё работает на одной машине, в одном процессе. Никаких серверов, никаких протоколов. Обычный браузер, обычный чат, прямое управление ОС. В этом и есть прорыв. MCP такого не делает и не может — у него принципиально другая архитектура!
Уникальность T-HS Bridge ещё и в особеном парсере. Он работает напрямую с DOM чата, извлекает команды ИИ без ошибок. За последние полгода — ни одного сбоя в парсинге. Система стабильна как часы. Именно это позволяет мосту работать без серверов и протоколов — мы читаем намерение ИИ прямо из интерфейса чата и тут же выполняем их на ПК, ядро возвращает результат в чат ИИ. ИИ понимает что команда выполнена и с каким результатом. Так же видит файлы и так же все остальное.
MCP работает через сервер и протокол. T-HS Bridge — это прямое управление ПК через собственное ядро на Python и Qt. Без облаков, без токенов, без сторонних сервисов. Почитайте описание внимательнее посты по ссылке.
Тут наглядно:
https://tenchat.ru/5196645
Ни каких платных API прямая работа с виндой. Без посредников..
А я вообще придумал способ дать любому чату ИИ управлять ПК, без всяких там платных API. Только не могу тут стаью закинуть, оказалось что это не так просто..
Отличный разбор, спасибо. Особенно ценно, что вы показали не просто «западные модели не подходят», а конкретно — по каким составам и почему.
У нас сейчас в T‑HS Bridge мы сделали ровно то, с чего вы начинаете: ядро с системой плагинов и безопасностью. И ваш кейс — идеальный пример того, как должен выглядеть специализированный плагин: не «ещё одна LLM», а инженерный инструмент под конкретный УК/КоАП, с аудитом и заморозкой версий.
Почему это важно:
«Дообучить чужую модель» — действительно не выход. Нужна своя маленькая модель (1–3B), которую можно переобучить под российскую таксономию. Быстро, дёшево, предсказуемо.
Маркировка иноагентов (ФЗ‑255) — это вообще не семантическая задача, а regexp + проверка по списку. И это не минус, а плюс: такие вещи должен решать не LLM-модуль, а отдельный классификатор.
Аудит по 149‑ФЗ — вы правильно про хэш и версию модели. Мы в мосте для других задач используем тот же принцип: фиксируем версию плагина, вход и выход, чтобы можно было воспроизвести решение через год.
Вопрос вам тоже: а что с «дискредитацией» (ст. 20.3.3)? Там ведь не только явные высказывания, но и подразумевания. LLM тут может быть полезна, но как вы планируете бороться с ложными срабатываниями? Или в этом случае всё равно остаётся человек в петле?
Отличная статья. Особенно ценно, что показали не только "что работает быстрее", а как меняется логика запроса при разных типах маскирования. Ваш вывод про хэширование как компромисс — самый важный: аналитику сохраняет, но за скорость приходится платить. У нас в T‑HS Bridge похожая дилемма с безопасностью: рутина без подтверждения, опасное — с запросом. Выбор типа защиты — это всегда компромисс между скоростью и контролем.