ПостКак Hope учится на собственных ошибках? (2/3)

Как Hope учится на собственных ошибках? (2/3) В предыдущих сериях мы обсуждали ourobors и то, как дать возможность агенту переписывать собственное ядро так, чтобы ничего критичного не сломалось. Теперь давайте разберёмся откуда вообще берутся идеи для изменений. У системы есть два режима эволюции. В первом, который называется free evolution, режиме агенту буквально ставят задачу улучшить себя: он инспектирует текущую реализацию, выбирает проблему, пишет изменение и после успешного review может запустить следующий такой цикл. При этом идеи могут браться из весов самой модели (которую кстати ouroboros может решить сменить на недавно вышедший флагман), из свежих статьей/интернета (опять же, ouroboros ничего не мешает написать для себя тул для похода на arxiv или reddit, даже если это не было предусмотренно изначально). Но есть и более интересный режим — experience-driven evolution, где поводом для изменения становится обычная работа. В процессе выполнения задач модель наталкивается на какие-то проблемы с harness, будь то программные ошибки или работа инструментов не согласно ожиданиям. Сообщения о проблемах могут приходить и от пользователей. Хороший пример — deep self-review. В какой-то момент такие задачи начали падать с ошибкой, похожей на недоступность модели. Вместо того чтобы добавить очередной retry, агент докопался до реальной причины: переполнялось контекстное окно. В итоге сборка контекста была заменена на bounded connectivity-aware context atlas: размер контекста под ревью ограничивается заранее, файлы ранжируются по centrality в import graph, а бюджет считается с учётом стоимости токена у текущего конкретного провайдера. В результате наиболее часто используемые и важные core-файлы с большей вероятностью переживают обрезание контекста. Этот fix после процесса review, который мы обсуждали в прошлом посте стал частью harness’а и начал использоваться во всех следующих задачах. Другой пример: Hope периодически отправлял один и тот же ответ дважды. После фидбека от пользователей агент нашёл проблему и исправил её. Здесь исходным сигналом была жалоба человека, но дальше она прошла тот же путь: fault —> root cause —> structural change —> reviewed commit. Похожим образом улучшался и benchmark harness. Аудиты вскрыли reward hacking в Terminal-Bench, leakage reference solutions в SWE-bench Pro, неправильную filesystem isolation в GAIA и remote-state drift в OSWorld. После рефлексии и самоисправления результаты, как мы знаем, превзошли все ожидания. Кажется, что всё прекрасно, можно к любому репо и продукту прикручивать, ловить фидбек из поддержки и улучшаться в космос, но к сожалению всё не так просто. Ставьте побольше реакций и в следующем посте обсудим будет ли это вообще работать в долгосроке и что, по мнению современной науки, нужно сделать, чтобы работало. Источник: https://arxiv.org/abs/2608.08311v2