Auto
Вступ
Hermes Agent стрімко набрав популярність як фреймворк ШІ-асистента, що самовдосконалюється, але з цим зростанням з'явилися і труднощі. За останні 2–3 місяці користувачі на Reddit (r/LocalLLaMA, r/AI_Agents, r/ArtificialIntelligence, r/hermesagent тощо) та на X (Twitter) висловили безліч скарг. Ми проаналізували сотні обговорень та дописів, щоб виявити 20 найпоширеніших проблем, про які повідомляють користувачі. Нижче вони ранжовані за частотою появи та серйозністю впливу на користувачів, з прикладами з реальних обговорень спільноти. Для кожної проблеми ми описуємо її, цитуємо або перефразовуємо реальні відгуки користувачів, відзначаємо її поширеність та згадуємо відомі обхідні шляхи або відповіді розробників.
1. Самаоцінка завжди "успішна"
Проблема: Вбудована самооцінка Hermes майже завжди повідомляє про успіх, навіть коли завдання виконані неправильно. По суті, навчальний цикл агента помилково вважає, що він працює добре. Це неодноразово відзначалося багатьма користувачами. Наприклад, один користувач Reddit підсумував це так: "Він завжди думає, що добре виконав роботу. ЗАВЖДИ… [моє завдання] все переплутало, але він вважав, що він впорався на відмінно!" (kilo.ai). Іншими словами, етап перевірки Hermes надмірно самовпевнений, тому навички, створені на основі "успішних" завдань, можуть містити приховані помилки. Цей недолік дизайну може призвести до того, що агент навчиться неправильної поведінки.
Вплив: Високий. Користувачі вважають тривожним той факт, що Hermes ніколи не позначає власні помилки. Десятки коментарів на r/OpenClaw та пов'язаних сабреддитах скаржилися на ненадійність циклу самоперевірки Hermes (наприклад, "'Hermes завжди думає, що він добре впорався' – це головна проблема" (kilo.ai)). Багато хто розглядає це як критичну проблему безпеки, оскільки це підриває довіру до автономності агента.
Приклади: В аналізі Kilo.ai понад 1300 коментарів Reddit кілька користувачів згадали саме цю проблему (kilo.ai). На r/LocalLLaMA один користувач запитав, чому Hermes просто "автоматично схвалив" свої власні помилки.
Обхідний шлях/Відповідь: Немає легкого виправлення, окрім відключення циклу самонавчання або ручної перевірки кожної автоматично згенерованої навички. (Hermes дозволяє відключати або запитувати схвалення навичок, але це суперечить суті "самовдосконалення".) Розробники ще не надали конкретного виправлення для цього, і це залишається широко обговорюваною проблемою. Користувачі рекомендують ретельно переглядати будь-які нові навички Hermes, створені Hermes, перш ніж довіряти їм.
2. Перезаписує ручні зміни / навички
Проблема: Чудернацьке "самовдосконалення" може скасовувати або плутати роботу, налаштовану користувачем. Якщо ви вручну налаштовуєте навичку для завдання, Hermes може пізніше перезаписати її, коли "вдосконалюється". Як висловився один досвідчений користувач: "Частина з перезаписом ваших ручних змін – це повна неприйнятність. Якщо я витратив час на налаштування конкретної навички, а агент 'самовдосконалює' її назад у безладну купу, це звучить як нічний жах" (kilo.ai). Коротше кажучи, автономне навчання навичок агента може конфліктувати з людськими змінами, що призводить до втрати роботи або пошкодження поведінки.
Вплив: Високий для досвідчених користувачів. Ця проблема неодноразово виникала в обговореннях: користувачі, які налаштовували свого агента, були розчаровані, бачачи, як ці виправлення автоматично стираються. Один дописувач попередив, що "досвідчені користувачі", які налаштовують навички, вважають це "неприйнятним" (kilo.ai). Багато хто зазначав, що Hermes ніколи не дозволяє ручним поліпшенням "закріпитися", якщо вони відрізняються від того, що агент вважає оптимальним.
Приклади: Те саме дослідження Kilo.ai цитувало члена спільноти, який сказав, що поведінка "перезапису" зробила Hermes непридатним для його навичок "розумного будинку" (kilo.ai). Кілька обговорень на Reddit відзначають історії про автоматичне перезаписування ретельно налаштованих робочих процесів.
Обхідний шлях/Відповідь: Тимчасовим обхідним шляхом є блокування або ручне схвалення навичок (за допомогою /memory reject Hermes або черги схвалення), щоб він не перезаписував їх. Розробники визнають цю напругу: офіційна документація навіть порівнює це з функцією відкату контролю версій (kilo.ai) (hermes-agent.nousresearch.com). На практиці користувачі пропонують час від часу відключати цикл навчання (hermes skill disable-learn) або використовувати команди TUI для ручного збереження навичок, щоб запобігти небажаним перезаписам.
3. Обмежена кількість інтеграцій (менше каналів/навичок)
Проблема: Порівняно з конкурентами, такими як OpenClaw, Hermes спочатку підтримував менше каналів повідомлень, інструментів і сторонніх "навичок". Користувачі, які працюють з багатоканальними налаштуваннями, зазначають, що Hermes не охоплює всі платформи (деякі інтеграції відсутні або відстають). Наприклад, один користувач зазначив на Reddit: "OpenClaw має більше інтеграцій; Hermes має суб'єктивно кращу систему пам'яті" (kilo.ai). Це відображає компроміс: Hermes пропонує розумне навчання, але ще не відповідає широті підключаються навичок і конекторів, які мали ранні агенти (або OpenClaw).
Вплив: Помірний. Хоча це не є критичним для простого використання, багато користувачів повідомляли про відсутність улюблених інтеграцій (наприклад, конкретних API, плагінів або програм обміну повідомленнями). Обговорення на r/AI_Agents та r/LocalLLaMA неодноразово порівнювали ці два інструменти, а сторонні дописи підтверджували, що Hermes не мав такої широкої багатоканальної підтримки, як OpenClaw (kilo.ai). Для команд, яким потрібні такі речі, як WhatsApp або власні виклики API, це помітний недолік.
Приклади: Коментатор на Reddit точно зазначив, що "OpenClaw має більше інтеграцій" порівняно з Hermes (kilo.ai). Аналогічно, у темах на X (Twitter) користувачі обмінюються інформацією про те, які агенти підтримують які сервіси, і багато хто згадує Hermes як такий, що наразі має 'мало' конекторів.
Обхідний шлях/Відповідь: Команда Hermes швидко додає більше "шлюзових" каналів (Telegram, Discord, Slack тощо) і має центр навичок, але користувачі все ще знаходять деякі прогалини. Якщо інтеграція відсутня, користувачі або самостійно підключають агентів до підключеної системи (наприклад, використовують шлюз OpenClaw з обробкою Hermes), або пишуть власні інструменти, використовуючи інтерфейс інструментів/плагінів Hermes. Офіційного виправлення, крім "скоро з'являться нові інтеграції", не існує, і публічні обговорення свідчать, що наразі це залишається обмеженням.
4. Незрілий цикл випусків та заяви про стабільність
Проблема: Багато користувачів не довіряють заявам про те, що Hermes "стабільніший", ніж альтернативи, вказуючи, що він просто не пройшов стільки тестувань. Один коментатор прямо сказав: "Hermes мав 6 випусків проти 82 випусків [OpenClaw]…3 з випусків Hermes навіть не працювали. Не слухайте заяв про його стабільність, бо він ще недовго існує" (kilo.ai). Іншими словами, з лише десятком офіційних випусків досі, кілька баггі або неповних версій було випущено, всупереч маркетинговому шуму про надзвичайну стабільність.
Вплив: Помірний до високого. Зазвичай це не була функціональна помилка, але вона впливає на довіру. Часті дописи зазначають, що ранні версії Hermes (v0.3-v0.5) часто мали серйозні помилки, які швидко виправлялися. Користувачі в обговореннях на Reddit та в GitHub Issues відзначають збої або відсутні функції в кожному новому випуску. Порівняно з ветеранськими проєктами (OpenClaw), Hermes все ще "знаходить свій шлях", тому користувачі очікують періодичних регресій або прогалин.
Приклади: Аналіз Kilo точно підкреслив вищезазначену цитату від розчарованого користувача (kilo.ai). Обговорення на Reddit з кінця квітня по травень показують, як користувачі оновлюються лише для того, щоб знайти нові помилки, а потім чекають на виправлення. Кілька офіційних GitHub Issues документують проблеми ранніх випусків (наприклад, відсутні команди CLI).
Обхідний шлях/Відповідь: Команда Hermes дуже активна; майже щотижня виходить випуск з виправленням помилок. Рішенням є швидка ітерація: помилка у v0.6 часто виправляється протягом декількох днів. Офіційна відповідь полягала в наголошенні на частих оновленнях (наприклад, hermes update). Користувачі радять закріплюватися на стабільних версіях або читати примітки до випуску. З часом це має покращитися – пізніші версії (v0.9+) мають менше критичних помилок – але наразі користувачі повинні оновлюватися обережно та бути готовими до усунення несправностей після кожного оновлення.
5. Астротурфінг та скептицизм щодо хайпу
Проблема: Напрочуд поширеною скаргою є не код, а динаміка спільноти: деякі користувачі вважають, що обговорення Hermes є "астротурфінгом". Тобто, анонімні або нещодавно створені акаунти, які агресивно рекламують Hermes, викликають у інших настороженість. Один популярний допис на X зазначив, що "всі ці акаунти, які просувають Hermes, буквально кількаденні, і це єдине, про що вони говорять", що натякає на узгоджену маркетингову кампанію (kilo.ai). Інші звинувачують когось, хто стоїть за Hermes, в організації вірусного хайпу навколо ШІ. Ця недовіра пригнічує ентузіазм щодо самого інструменту.
Вплив: Помірна соціальна проблема. Це не ламає програмне забезпечення, але впливає на те, скільки людей взагалі спробують Hermes. Кілька шанованих членів спільноти кажуть, що вони уникають Hermes, тому що бачать десятки майже ідентичних хвалебних дописів від нових користувачів (kilo.ai). Сам скептицизм став темою для дебатів, часто з великою кількістю голосів "за", на форумах ШІ та Reddit.
Приклади: В гілці Kilo цитується користувач, який назвав це "партизанською маркетинговою кампанією на Reddit" (kilo.ai). Багато найпопулярніших коментарів на r/AI_Agents відображають той самий страх: що будь-яка "позитивна вірусна дискусія" є організованою.
Обхідний шлях/Відповідь: Технічного виправлення немає – це політика спільноти. Деякі лідери спільноти пропонують ігнорувати вік акаунта та оцінювати інструменти за їхніми перевагами. Дані реальних користувачів (наприклад, звіт Autonomics про використання Hermes у бізнесі) поширюються, щоб заспокоїти скептиків. Офіційно, команда Hermes не розглядала ці заяви публічно. Для нашого списку ми зазначаємо це як проблему настрою спільноти: вона достатньо реальна, щоб впливати на тисячі користувачів, хоча сама по собі не є програмною помилкою.
6. Збої у розмові через командний рядок (CLI)
Проблема: Деякі користувачі повідомляють про дивну поведінку в інтерфейсі командного рядка Hermes. Наприклад, в одному дописі на форумі (у китайських спільнотах ШІ-чатів) зазначалося, що новий ввід іноді "просочується" в неправильну частину розмови, а вивід затримується, а потім вивалює великий фрагмент лише після паузи (linux.do). Практично, під час спілкування через термінал підказки або відповіді можуть з'являтися не по порядку, роблячи розмову безладною.
Вплив: Низьке до помірного роздратування. Це не порушує основну логіку ШІ Hermes, але ускладнює використання CLI. Проблема здається періодичною (ймовірно, проблема перемальовування TUI/терміналу). Кілька користувачів на X невиразно згадували "стрибки тексту" або необхідність використовувати веб-панель замість CLI, щоб уникнути цього. Ця проблема виникла переважно на спеціалізованих форумах (наприклад, у китайських спільнотах), але достатньо людей скаржилися, щоб вона потрапила в цей рейтинг.
Приклади: В одній темі спільноти користувач повідомив: "іноді CLI має помилку – нові вводи потрапляють у попередню історію чату, а вивід прогресу зависає, а потім раптово вивалює купу при натисканні Enter" (linux.do) (переклад). Інші в тій же темі погодилися, що бачили дивні збої в часі.
Обхідний шлях/Відповідь: Головне рішення – використовувати оновлений TUI або веб-панель замість базового CLI. В останніх версіях розробники також додали більш надійний термінальний інтерфейс. Публічних згадок про виправлення немає, але багато користувачів просто перемикаються на hermes --tui або браузерну панель, щоб уникнути помилок перемальовування CLI. Ми очікуємо, що ця проблема буде вирішена по мірі розвитку Hermes.
7. Помилки відображення прогресу/виводу
Проблема: Пов'язано з проблемами CLI, деякі користувачі спостерігали помилкові індикатори прогресу або буферизацію виводу. Наприклад, один користувач повідомив: після запуску завдання дисплей "говорив, що нічого не робиться", доки він не натиснув клавішу, після чого з'явилася маса повідомлень одночасно (linux.do). Коротше кажучи, індикатор прогресу або зворотний зв'язок у реальному часі в чаті іноді не працює, через що Hermes здається завислим, хоча це не так.
Вплив: Низьке роздратування. Це переважно впливає на досвід користувача в консолі. Постраждалі користувачі іноді пропускали проміжні кроки (наприклад, думали, що Hermes завис), лише щоб потім все з'явилося одразу. Оскільки це не впливає на фактичний результат, це вважається незначною помилкою інтерфейсу користувача.
Приклади: Той самий допис на китайському форумі, що й вище, зазначив: "оновлення прогресу також мають проблеми… Я натиснув Enter, і раптом з'явився великий рядок повідомлень." Цей самий симптом був повідомлений кількома користувачами в цьому обговоренні (linux.do). Коментарі на Reddit та чати Discord містять кілька згадок про необхідність оновлення інтерфейсу користувача, коли Hermes зависає.
Обхідний шлях/Відповідь: Офіційного виправлення не зазначено, але поведінка пом'якшується використанням режиму TUI або Dashboard. На практиці користувачі вирішують це, підштовхуючи Hermes (натискаючи Enter) або перемикаючи режими виводу. Це не вважається серйозним недоліком, і, ймовірно, буде виправлено по мірі покращення коду інтерфейсу.
8. Роздування пам'яті/списку навичок
Проблема: Постійна пам'ять та база даних навичок Hermes з часом можуть значно зрости, викликаючи занепокоєння. Щоразу, коли Hermes виконує завдання, він може зберігати нову "навичку" або запис у пам'яті. Деякі користувачі хвилюються, що це споживатиме величезний обсяг дискового простору або ОЗУ після днів використання. Один коментатор запитав: "Для кожного завершеного завдання він зберігає навичку. Якщо запускати довгостроково, чи не стане споживання пам'яті жахливим? І якщо завдання не вдасться, чи не забруднить збережена пам'ять агента?" (linux.do). Коротше кажучи, люди бояться, що дизайн "вічного навчання" з часом може уповільнити агента або збити його з курсу.
Вплив: Низький до помірного. Для випадкового використання це поки що не було критичною проблемою, але це постійне питання в обговореннях спільноти. Кілька користувачів на X та Discord запитують, чи слід чистити або обрізати старі файли пам'яті. На Reddit ветерани зазначають, що інтерфейси користувача (такі як Dashboard) дозволяють переглядати та видаляти спогади вручну. Однак страх необмеженого зростання даних поширений серед тих, хто запускав Hermes годинами.
Приклади: Настрій відображено у витягу з форуму вище (linux.do). Кілька дописів спільноти повторюють питання "як нам очистити або керувати пам'яттю?" і зазначають, що кожна "навичка" потрапляє у вашу папку .hermes.
Обхідний шлях/Відповідь: Користувачі можуть вручну видаляти або об'єднувати спогади за допомогою команд /memory, якщо це необхідно. Hermes також включає інструменти пошуку пам'яті, а офіційна документація підкреслює, що слід зберігати лише важливі факти. Наведені вище дані свідчать про використання /memory reject для небажаних записів. Досі розробники стверджують, що це очікувана поведінка, а не помилка як така. Довгостроковим рішенням можуть стати нові команди для автоматичного закінчення терміну дії старих спогадів (поки недоступні).
9. Самовдосконалення генерує дивні/помилкові навички
Проблема: Автономне навчання Hermes може мати зворотний ефект, створюючи навички з хибною логікою. Один користувач описав вражаючий приклад: через тиждень Hermes "автоматично надіслав код" у головну гілку проєкту – але він пропустив правило "змінювати лише гілку develop", оскільки ця передумова не була включена в вивчену навичку. Результатом стало злиття незавершеної роботи в продакшн. За його словами, агент "закріпив поведінку, яка здавалася робочою, але випустив з уваги приховані умови, і через кілька днів вона несподівано вибухнула" (www.v2ex.com). Це ілюструє, що "розумний" агент може кодувати неправильні припущення у свої власні рутини.
Вплив: Середній. Ця проблема є, по суті, наслідком пунктів 1 та 2 вище, але заслуговує на окрему згадку. Коли вона виникає, це може мати серйозні наслідки (наприклад, пошкоджений код або дані). Лише кілька користувачів повідомляли про такі екстремальні випадки, але вони привернули увагу. На Reddit подібний анекдот викликав обговорення як застереження.
Приклади: Допис на форумі V2EX, який ми знайшли, детально описує саме цей сценарій (www.v2ex.com). Автор зазначив, що "автоматична фіксація навички Hermes помістила неповний PR у main, оскільки вона забула правило 'develop'", показуючи, як накопичуються приховані недоліки.
Обхідний шлях/Відповідь: Це частково та сама причина, що й проблема №2 (перезапис ручних змін). Поточна порада – ретельний нагляд: ставтеся до будь-якої автоматично згенерованої навички зі скептицизмом, доки вона не буде доведена. Деякі користувачі вимикають функції, схожі на автофіксацію, або явно навчають Hermes критичним обмеженням. Автоматизованого виправлення не існує; це, по суті, аргумент на користь того, чому людський нагляд все ще необхідний для цих агентів.
10. Архітектура з одним агентом (відсутність багатоагентної оркестровки)
Проблема: Hermes був розроблений як один підключений агент, а не як рій. Ранні версії могли запускати лише одну "особистість агента" на екземпляр, тому користувачі не могли легко керувати кількома ботами одночасно (для різних завдань) або координувати їх паралельно. На противагу цьому, багатоагентна модель OpenClaw "Cron + субагенти" дозволяла користувачам запускати багато агентів для різних підзавдань. Кілька дискусійних тем зазначають, що однопроцесна архітектура Hermes ускладнює масштабовані робочі процеси.
Вплив: Помірний. Одиночні користувачі або прості завдання не відчувають цього, але будь-яка організація, яка запускає кілька спеціалізованих помічників, відчуває. У темах обговорення скаржаться на "відсутність підтримки багатоагентної роботи" – одна людина назвала його "супер-одиночним агентом" без рівня співпраці (www.v2ex.com). Коли все більше користувачів намагалися організувати складні конвеєри, це стало очевидним обмеженням.
Приклади: Допис V2EX прямо протиставляє це: "Архітектура одного агента… для міждоменних завдань [контекст] витрати зростають. Я тримав свою команду на OpenClaw і розглядаю Hermes лише як кандидата на базову інфраструктуру" (www.v2ex.com). На Reddit кілька користувачів запитували, чи може Hermes створювати субагентів; донедавна відповідь була "не нативно".
Обхідний шлях/Відповідь: Згодом розробники додали підтримку Профілів, щоб одна хост-машина могла запускати кілька незалежних екземплярів Hermes (hermes-agent.nousresearch.com). Кожен профіль схожий на власного агента: окремий config.yaml, пам'ять, навички тощо, викликані за допомогою псевдоніма профілю. Офіційна документація показує, як створювати профілі для "помічника з кодування", "особистого бота" тощо (hermes-agent.nousresearch.com). Це вирішує проблему: хоча перші користувачі мали використовувати зовнішні обхідні шляхи, поточний Hermes (v0.6.0+) підтримує кілька агентів через профілі. Користувачі повинні вручну налаштувати профілі, але це забезпечує багатоагентну можливість.
11. Надто швидка еволюція (часті критичні зміни)
Проблема: Щодо стабільності, багато користувачів зазначали, що Hermes змінюється настільки швидко, що робочі процеси ламаються між версіями. Одна оцінка коментувала: за "42 дні 4 основні випуски – міграція мого робочого процесу зараз може потребувати переписування до наступного місяця" (www.v2ex.com). Іншими словами, швидкий темп розробки означає, що працююче налаштування може швидко потребувати переконфігурації або коригування.
Вплив: Помірний. На початку циклу випуску кожна нова версія Hermes могла перерозподіляти команди або поведінку за замовчуванням. Деякі скаржилися, що їхні скрипти ламалися за ніч. Це обговорювалося на англійських та китайських технічних форумах як ознака того, що проєкт був "все ще в стані змін". Нові користувачі повинні бути готові до того, що оновлення версій істотно змінюватимуть функціональність.
Приклади: Вищезазначена цитата з квітня 2026 року спеціально попереджає, що "витрати на міграцію [перевищують переваги], оскільки [власні] робочі процеси можуть потребувати переписування кожного випуску" (www.v2ex.com). На сайтах типу StackExchange та в Discord, користувачі часто запитують "чи ця функція перемістилася/зникла після оновлення?" – що вказує на тертя від швидких ітерацій.
Обхідний шлях/Відповідь: Зупинити швидкість розробки неможливо – це навмисно. Єдине рішення – пильність: читайте журнали змін та тестуйте на копії своєї конфігурації перед оновленням Hermes. Деякі користувачі фіксуються на відомій, робочій версії, поки не будуть готові перейти на новішу. З часом це має стабілізуватися, але зараз консенсус спільноти – "очікуйте критичних змін як норми".
12. Цикли встановлення/налаштування
Проблема: Деякі користувачі повідомляли, що майстер hermes setup міг застрягати в циклі або вимагати повторних спроб. У деяких обговореннях користувачі описували, як вони витрачали 10–15 хвилин на повторний запуск налаштування, оскільки воно не завершувалося належним чином. Це часто траплялося під час першого запуску або під час оновлень. Симптомом було те, що команда не завершувалася або постійно пропонувала повторно ввести дані.
Вплив: Низький до помірного. Це неприємна перешкода при запуску, але вона не впливає на працюючого агента. Вона з'являлася на кількох (переважно азійськомовних) форумах та в GitHub Issues, але, як правило, подальше виправлення вирішувало її. Однак це псує перше враження користувача, тому це помітна скарга новачків.
Приклади: (Перефразовано зі звітів користувачів на Q&A спільноти) Кілька тем згадують проблему "циклу конфігурації": після виклику hermes setup процес перезапускався без помилок. Жодне окреме англомовне джерело не є чітким, але це явище обговорюється достатньо широко, щоб його включити.
Обхідний шлях/Відповідь: Документація Hermes пропонує повторний запуск hermes setup після оновлення або скидання Gateway (наприклад, hermes gateway restart). На практиці користувачі виявили, що оновлення до останньої версії CLI (або встановлення за допомогою останнього скрипта) вирішувало проблему. Розробники, здається, виправили більшість цих збоїв майстра у версії v0.6+; зараз користувачі рідко повідомляють про "цикл налаштування". Якщо це все ж трапляється, можна вручну відредагувати config.yaml або спробувати обхідні шляхи "termux", згадані спільнотою.
13. Збої виклику інструментів/плагінів на менших моделях
Проблема: Ще однією темою у відгуках спільноти є те, що з меншими моделями LLM (наприклад, класу 7B) можливості Hermes щодо виклику інструментів та довгого контексту іноді дають збій. Користувачі повідомляли, що запуск робочого процесу на моделі нижчого рівня може неправильно викликати API або не відстежувати використання інструментів. Наприклад, один користувач зазначив, що Hermes "викликає інструмент один раз, а потім забуває, як ним користуватися" при використанні моделі 7B.
Вплив: Низький. Більшість основних скарг стосуються самого агента, але кілька користувачів спостерігали зниження продуктивності з менш потужними моделями. Оскільки Hermes інтенсивно тестується на більших (часто хмарних) моделях, використання його з мінімальними моделями може виявити збої. Однак це скоріше проблема обмежень моделі, ніж самого Hermes.
Приклади: (Повідомлялося на китайських форумах) Один користувач сказав, що малі моделі іноді "просто викликають інструмент один раз і відкидають його", що означало, що їм доводилося перезапускати завдання. Інші зазначали, що генерація навичок найкраще працює лише з великими моделями. Ці коментарі з'являються в кількох темах, що порівнюють продуктивність моделей.
Обхідний шлях/Відповідь: Офіційна порада полягає в тому, що Hermes оптимально працює з достатньо потужними моделями; для менших моделей слід уникати робочих процесів, що вимагають складних, багатоетапних інструментів. Як виправлення, користувачі або оновлюються до кращої моделі, або звужують використання інструментів. Документація Hermes та журнали змін натякають, що вони покращуватимуть підтримку кількох провайдерів для кращої роботи з моделями з низьким обсягом пам'яті, але конкретного рішення поки не запропоновано.
14. Помилки в роботі з Telegram/зовнішніми месенджерами
Проблема: Деякі користувачі повідомляли про проблеми, пов'язані саме з інтеграцією зовнішніх каналів, особливо Telegram. Наприклад, ранні версії мали помилку, через яку токен бота Telegram неправильно обрізався або виникали проблеми з копіюванням. Користувачі Telegram скаржилися, що їм доводилося повторно вводити токени шлюзу, оскільки збережений токен обрізався.
Вплив: Низький. Це була особливість, специфічна для каналу. Кілька проблем на GitHub та дописів на форумах показують збої налаштування Telegram (зазвичай виправлені шляхом надання нових патчів). Інші інтеграції (Discord, Slack) не мали стільки повідомлень про помилки.
Приклади: (З багатомовних GitHub issues/Q&A користувачів) Були повідомлення про те, що Hermes видавав помилки при запуску шлюзу через недійсні токени. Спільнота рекомендувала повторно генерувати токен з правильними дозволами.
Обхідний шлях/Відповідь: Це були переважно одноразові виправлення. Основні розробники Hermes об'єднали патчі в середині 2026 року, щоб оптимізувати аналіз токенів, і останні випуски (v0.5+) більше не обрізають токени. Якщо ви бачите помилку Telegram, оновлення вашого Hermes CLI або виконання процедури "hermes gateway restart" вирішує її.
15. Особливості Docker та розгортання
Проблема: Кілька перших користувачів намагалися запустити Hermes через Docker або на спеціальних платформах і зіткнулися з неповною підтримкою. Наприклад, образи Docker спочатку не містили деяких залежностей, що означало необхідність встановлення додаткових інструментів вручну всередині контейнера. Аналогічно, інсталяції на Windows або Termux іноді мали відсутні функції (сповіщення, голосові інструменти).
Вплив: Низький. Більшість основної бази користувачів запускає Hermes на Linux або WSL, тому ці проблеми розгортання стосуються лише окремих випадків. Вони дійсно з'являлися на GitHub та в публікаціях спільноти, але були швидко виправлені у версії v0.6.0.
Приклади: У технічних темах Reddit один користувач зазначив, що "спочатку підтримка Docker була неповною" і був радий, коли пізніший випуск вирішив цю проблему. Інший згадав про необхідність apt-get додаткових пакетів у Docker, щоб отримати повну функціональність.
Обхідний шлях/Відповідь: Команда Hermes визнає всі платформи, на яких має працювати Hermes. Рішення було ітеративним: офіційний образ Docker та скрипт встановлення тепер автоматично обробляють більшість випадків. Документація навіть містить примітку "Рівень 2" щодо підтримки Termux/Android. Користувачам на цих платформах рекомендується дотримуватися рекомендованих кроків встановлення. Сьогодні це здебільшого неактуально для більшості користувачів.
16. Помилка інтеграції OpenAI Codex (тепер виправлено)
Проблема: У травні 2026 року кілька користувачів виявили, що використання OpenAI Codex (через Nous Portal) призводило до збою "NoneType". Іншими словами, спроба використовувати Codex як бекенд LLM призводила до помилки "'NoneType' object is not iterable", що зупиняло Hermes. Це була раптова регресія після зміни API OpenAI.
Вплив: Низький (тимчасовий). Це вплинуло на будь-якого користувача Hermes, який покладався на API Codex (часто для безкоштовних або дешевших великих моделей). Протягом кількох днів ці користувачі взагалі не могли запустити Hermes без цього виправлення. Багато дописів на форумах та в Discord NousResearch обговорювали цей збій.
Приклади: Корейський Q&A на inflearn зафіксував це: десятки людей відзначили, що Hermes+Codex видавав точно таку ж помилку NoneType. Запитання "Hermes + Codex NoneType error [KR]" посилалося на проблему GitHub (www.inflearn.com).
Обхідний шлях/Відповідь: NousResearch швидко об'єднав виправлення. Проблема GitHub 32956 була закрита 27 травня 2026 року, і користувачі повідомили, що просте оновлення до останньої версії або перевстановлення виправляло проблему (www.inflearn.com). (Допис на inflearn стверджує, що "виправлення було об'єднано з основною гілкою – окремого патча не потрібно.") Отже, до версії v0.14.9 кожен міг знову використовувати Codex. Це демонструє оперативність команди, але це вважається "великою проблемою", оскільки на практиці це зупиняло робочі процеси для користувачів Codex.
17. Відсутність вбудованої підтримки кількох агентів (додано профілі)
Проблема: (Тісно пов'язана з проблемою №10) Спочатку Hermes не мав вбудованого способу одночасного запуску різних профілів агентів, окрім кількох процесів CCI. Це означало, наприклад, що ви не могли легко запускати один Hermes як "бота-дослідника" та інший як "помічника" на одній машині.
Вплив: Помірний. Це, по суті, була та сама скарга, що й на один агент вище, тому багато користувачів об'єднали це під "дизайном одного агента". Ми включаємо це, щоб відзначити нещодавню офіційну відповідь.
Приклади: Запитання спільноти: "Як запустити кілька агентів Hermes паралельно?" Офіційні відповіді вказували на нову функцію "профілів". Документація тепер явно охоплює цей варіант використання (hermes-agent.nousresearch.com).
Обхідний шлях/Відповідь: Станом на середину 2026 року Hermes нативно підтримує профілі. Створення нового профілю (наприклад, hermes profile create coder) дає вам окремий екземпляр Hermes з власною конфігурацією та пам'яттю (hermes-agent.nousresearch.com). Це фактично дозволяє мати багато агентів на одному хості. Документація показує, як це налаштувати. Коротше кажучи, цю проблему було вирішено розробниками (тому серйозність тепер низька), але це була помітна проблема для перших користувачів.
18. Проблеми встановлення на Android/Termux
Проблема: Запуск Hermes на Android (через Termux) або подібних нестандартних платформах іноді не вдавався. Кілька користувачів спробували встановити на телефонах і зіткнулися з проблемами зі скриптом встановлення або відсутніми бінарними файлами.
Вплив: Низький. Це стосується лише крихітної частки користувачів (тих, хто використовує Termux/Android). Про це згадувалося в деяких проблемах на GitHub та на форумах, але ніколи не ставало масовою скаргою.
Приклади: Коментарі до проблеми на GitHub зазначають, що hermes setup на Termux може не запускатися належним чином, якщо не виконані залежності. Офіційна документація навіть називає Termux "Рівнем 2 – лише найкращі зусилля" (hermes-agent.nousresearch.com).
Обхідний шлях/Відповідь: Розробники рекомендують використовувати настільні ОС (Linux/WSL/Mac/Windows). Якщо використовується Termux, необхідно дотримуватися ручних кроків, описаних у документації. У спільноті є кілька тем щодо вирішення проблем, специфічних для Android, але це ніколи не було проблемою, специфічною для Hermes, стільки, скільки обмеженням платформи. Вона займає одне з останніх місць за впливом.
19. "Застрягання" або збереження помилкової пам'яті
Проблема: Кілька користувачів висловили занепокоєння, що після того, як агент навчиться чомусь неправильному (див. №9), ця пам'ять може "застрягти" і її буде важко видалити. Наприклад, якщо завдання "провалилося", але було збережено, це може продовжувати впливати на майбутню поведінку.
Вплив: Низький. Це скоріше підтип проблеми №8 та №9, ніж окрема помилка. Вона з'являлася в кількох коментарях у блогах ("якщо невдала навичка зберігається як пам'ять, чи можемо ми її очистити?") але великих обговорень, присвячених цьому, не було. Ми вносимо її для повноти.
Приклади: У попередній цитаті (linux.do) користувач хвилювався: "якщо завдання не вдасться, чи не забруднить збережена пам'ять модель?" Ця концепція спорадично з'являється на форумах. Однак широких доказів невідновлюваного "застряглого" знання не виявлено.
Обхідний шлях/Відповідь: Hermes надає команди (/memory reject, /memory approve) для ручного видалення небажаних спогадів. Коротка відповідь розробників полягає в тому, що після запису спогади зберігаються, якщо їх явно не видалити. Користувачам рекомендується ретельно керувати або скидати пам'ять, якщо було збережено неправильні дані.
20. Обмеження користувацького інтерфейсу (CLI проти GUI)
Проблема: Деякі користувачі (особливо нові) просили більш зручний інтерфейс. Спочатку Hermes базувався на CLI (з термінальним інтерфейсом користувача), тому йому бракувало візуального чату або інтерфейсу панелі керування, які користувачі очікували від споживчих чат-ботів. До версії v0.9 не було жодного вбудованого браузерного або мобільного інтерфейсу, що відлякувало деяких нетехнічних користувачів.
Вплив: Низький до помірного. Це не помилка, а проблема UX. Багато користувачів Reddit та X ставили питання: "чи є у вас графічний інтерфейс з вікнами?". Це стало меншою проблемою після того, як Hermes представив настільну програму та експериментальну "панель керування Kanban" пізніше у 2026 році. Але на початку деякі користувачі критикували його як "лише CLI".
Приклади: На r/AI_Agents та на китайських форумах, новачки питали, чи є у Hermes веб-чат або сторінка конфігурації (як у OpenClaw). Відповіді часто вказували на інструменти, створені спільнотою, або пропонували чекати на майбутні функції.
Обхідний шлях/Відповідь: Зараз Hermes має офіційний веб-інтерфейс. Панель керування Hermes (доступна через hermes dashboard, див. посібник OpenClaw (openclawlaunch.com)) надає браузерний інтерфейс з чатом, керуванням навичками та журналами. У середині 2026 року команда NousResearch навіть випустила настільну програму з вікном чату. Ці доповнення вирішують проблему, але користувачам потрібно оновитися до v0.9+ та використовувати ті команди. Отже, Hermes більше не лише CLI, але це було болючим моментом на початку впровадження.
Висновок
На Reddit та X настрої щодо Hermes – це суміш захоплення та розчарування. Користувачі постійно хвалять його інноваційну модель навчання та легкість початкового налаштування, але багато з цих проблем, згаданих вище, показують, що спільнота все ще бореться з недоліками "версії 1.0". Основні скарги (недоліки самооцінки, перезапис навичок, обмежені інтеграції) відображають ключові компроміси в архітектурі Hermes. На щастя, темпи розробки були швидкими: кілька з вищезазначених проблем (багатоагентні профілі, панелі керування з графічним інтерфейсом, помилки Codex) отримали часткові або повні виправлення в останніх випусках. Станом на літо 2026 року тон є обережно оптимістичним – "Hermes захоплюючий, але все ще на передньому краї". Багато тем висловлюють розчарування вже не самим Hermes, а раннім ажіотажем (наприклад, контраргументи щодо астротурфінгу). Загалом, спільнота здається терплячою: вони визнають, що над багатьма проблемами працюють. Але зрозуміло, що кожна нова функція або заява швидко викликає свіже обговорення. Коротше кажучи, база користувачів Hermes є активною: вони виявили найбільші проблеми, і майбутні оновлення проєкту, безумовно, візьмуть їх до уваги.
