Пока вокруг AI все в основном обсуждают модели, бенчмарки и очередных «автономных агентов», параллельно растёт более прикладная часть экосистемы — готовые skills под конкретные задачи. И Hermes Skill Hub здесь особенно интересен.

Когда открываешь такой хаб, быстро становится понятно, что агенты уже живут не только на уровне «вот модель, вот чат, вот промпт». Поверх этого слоя появляется следующий: готовые блоки действий, готовые workflow, готовые куски автоматизации, из которых можно собирать собственные процессы. По сути, skill здесь — это уже не просто текстовая подсказка, а оформленный способ решать повторяемую задачу, строить собственные пайплайны.

Я пользуюсь Hermes Agent уже месяц. Всё это время работал через командную строку (WSL) потому что на windows версии не было, Конечно, уже это довольно ощутимое ограничение, так как Hermes не имел полный выход к файлам в Windows, за это время свыкся с терминалом запускал через hermes chat. недавно вышла версия v0.15.2, и вместе с ней десктопный установщик на Electron. Windows, macOS, Linux.

Скачал, поставил, пошёл по настройкам. Оказалось, что в GUI тринадцать разделов, и каждый из них что-то решает. Ниже — гайд по тому, как можно оптимизировать настройки под себя.

На днях я заметил, что квота Ollama Cloud Pro тратится быстрее обычного. Значительно быстрее. За семь дней я сжёг 603 миллиона токенов и не понимал, куда они уходили.

Я открыл логи Hermes Agent и нашёл то, о чём не знал: блок auxiliary: с двенадцатью фоновыми задачами. Сжатие контекста, извлечение из веба, vision, поиск по сессиям, подбор навыков — всё это молча запускалось при каждом моём сообщении. Каждая задача стояла на provider: auto. И поскольку у меня не было ключей для цепочки fallback, каждая молча откатывалась на kimi-k2.6, мою основную модель на триллион параметров.

Я понятия не имел, что это происходит. Пока я печатал одно сообщение, агент отправлял одиннадцать других в фоне — через ту же модель, из того же квоты, не показывая мне промпты. Только сжатие контекста срабатывало 10–20 раз за длинную сессию, каждый раз отправляя всю историю.

Построил pipeline публикации контента на 8 платформах. Время распространения статьи сократилось с 50 минут до 90 секунд. Рассказываю, почему waterfall обходит parallel, какие API-ловушки встретились, и почему без человека в цикле нельзя.

В августе 2019 года, за несколько недель до выборов в Московскую городскую думу, Пьерик Годри из исследовательского института INRIA опубликовал результаты анализа кода московской системы дистанционного электронного голосования. Вывод был однозначным: параметры шифрования слабы настолько, что расшифровать голоса избирателей в режиме реального времени можно было за двадцать минут на стандартном ноутбуке с помощью общедоступного программного обеспечения Gaudry, Golovnev, 2019. Не взломал — математически решил задачу, которую разработчики системы, судя по всему, считали нерешаемой за разумное время. Ключ шифрования был построен на 256-битных параметрах ElGamal: при таком размере задача дискретного логарифма решается за минуты на обычном ноутбуке.

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

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

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

Цена этой проблемы измеримa. Согласно отчёту IBM Cost of a Data Breach 2023, средняя стоимость утечки данных в здравоохранении составляет $10,93 млн — почти вдвое больше, чем в финансовом секторе ($5,9 млн) IBM Security, 2023. Но финансовые потери — лишь следствие. Причина глубже: базовая архитектура большинства медицинских информационных систем воспроизводит подходы 1990-х годов: централизованные реляционные базы данных, закрытые проприетарные форматы, точечная интеграция через HL7 или FHIR-адаптеры (HL7 FHIR — международный стандарт обмена медицинскими данными; FHIR, Fast Healthcare Interoperability Resources — его актуальная версия).

Важно: стандарты обмена данными типа FHIR решают проблему формата, но не проблему доверия. Они не гарантируют, что переданные данные не были изменены. Они не дают пациенту контроль над тем, кто читает его карту. И они не позволяют двум конкурирующим страховщикам верифицировать один и тот же факт, не открывая друг другу свои базы данных. Именно здесь классические архитектуры достигают структурного предела.

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

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