Краткий обзор Oh‑My‑Pi (OMP) — многофункциональный консольный агент для терминала

Привет! Сегодня я познакомлю вас с консольным агентом oh‑my‑pi (OMP), который не так известен как cloude или opencode, но очень интересный в возможностях, например:

• advisor (модель‑рецензент, которая смотрит поверх каждого хода) в cloude это уже появилось, но только с платной моделью;

• создание субагентов со своими правилами, которыми можно гонять карусель ( agents loop) не выходя из OMP;

• гибкостью работы с подключаемыми LLM, которые можно назначать субагентам, организовав контроль за написанием кода, тестированием, планированием под ваш harness.

Буду рад, если эта статья читателю сэкономит время, для меня же это был «опыт, сын ошибок трудных»:)

Установка и запуск.

Установить omp (Oh My Pi) можно несколькими способами, выберите удобный для себя и ОС:

Linux / macOS: curl -fsSL https://omp.sh/install | sh

Windows, PowerShell: powershellirm https://omp.sh/install.ps1 | iex

или просто npm install -g @oh-my-pi/pi-coding-agent

Запуск с LiteLLM, Ollama, LM Studio или llama.cpp

Если вы используете локальные модели через прокси LiteLLM, запускайте так:

LITELLM_BASE_URL=“http://<ip:port>/v1” omp

Если прокси требует API‑ключ:

LITELLM_BASE_URL=“http://<ip:port>/v1/ ” \
LITELLM_API_KEY=“ваш-ключ” omp

Ollama:OLLAMA_BASE_URL="http://<ip:port>" omp

LM Studio: LM_STUDIO_BASE_URL="http://<ip:port>/v1" omp

llama.cpp:LLAMA_CPP_BASE_URL="http://<ip:port>" omp

Обратите внимание на формат адресов: для LM_STUDIO_BASE_URL указан /v1, а для Ollama и llama.cpp в этих переменных используется корневой адрес сервера. Замените адрес на IP и порт своего хоста. К API_KEY на примере провайдера LiteLLM допишите OLLAMA или другие, а так же значение ключа можно задать в /settings и при запуске он не нужен, но полезен при автоматизвции запуска. Учтите: адрес, явно заданный для провайдера в models.yml, имеет приоритет над LITELLM_BASE_URL.

Advisor: вторая модель, которая читает каждое ваше действие

Вот это, на мой взгляд, очень интересно, так как сбережет бюджет использования LLM. В OMP можно прикрепить к сессии advisor — отдельную модель‑советника, которая наблюдает за основным агентом в реальном времени. Как это работает:

• Advisor не утверждает действия и не лезет менять состояние основной сессии напрямую.

  

  Он читает вывод основного агента, может сам открыть файлы своими инструментами (read, grep, glob, а при желании и отредактировать edit, write, bash, eval), и вставляет краткий совет прямо в поток: тихое замечание, тревогу или жёсткий блокер. У него свой собственный контекст и своя модель, поэтому он ловит то, что исполнитель успел пропустить по спешке. Основной агент видит заметку, и, либо корректируется, либо объясняет, почему не стал.

  

  Модель для advisor включается \advisor и резолвится через систему ролей, а если не задать явно — OMP пойдёт по цепочке slow → встроенный priority‑chain, а не просто скопирует основную модель. И да, есть backup‑reviewer: если модель рецензента упала (авария, rate‑limit), advisor сам переключится на следующую в retry.fallbackChains. Это как round‑robin ключей, только для «мозгов»:

modelRoles: 
  advisor: deepseek/deepseek-v4-pro
retry: 
  fallbackChains:  
    advisor:  
      - anthropic/claude-sonnet-4-5:medium  
      - google-vertex/gemini-3-pro

Правила для advisor можно расписать подробно через WATCHDOG.yml, где для каждого советника можно дать почти что угодно, включая инструменты изменяющие файлы или состояние среды (edit, write, bash, eval). Они, впрочем, работают в изолированном ToolSession и всё равно подчиняются обычному режиму подтверждений. Я к роли advisor (советника) подключил deepseek‑v4-pro, а код писал локальной моделью. При промтах в 80–150 к токенов для локальной модели советник, анализируя, тратил 20–30 к токенов, давая дельные советы, которые залетали в локальную, принуждая править ранее написанный код, а если локальная начинала галлюцинировать, то советник ставил блок останавливая поток. По мне экономия на лицо, озадачить, под надзором советника, писать код локальную модель запущенную на домашнем gpu‑server‑е, которая за час обработает несколько миллионов входящих токенов, потребив лишь 0.3 киловатта в час... несколько рублей.

Субагенты

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

Суть в том, что задача (task) распределяется на изолированные воркеры: каждый работает со своей поверхностью инструментов (опционально в изолированном worktree), и итог возвращается не «простыней» текста, а валидированным по схеме объектом, который родитель читает напрямую. Никакого парсинга прозы на лету, никаких конфликтов слияния между задачами, никаких потерянных правок в чужих файлах. Создать субагента можно командой /agents.

Откроется окно, в котором можно выбрать + New agents и вставить промт с правилами для создаваемого субагента. После обработки промта в папке .OMP репозитория проекта над которым работаете появляется MD с правилами нового субагента и он начинает вызываться при задачах. Очень широкие возможности для организации harnessa.

На этом скрине субагент создался со своим именем (не нашел, где при создании задать, возможно сразу в промте задавать рекомендуемое имя), и до настройте какую модель использовать + другие настройки.

Наблюдать за работай субагентов можно через Agent Hub — открывается по Alt+A(или Ctrl+S). Это интерактивный TUI для просмотра и управления субагентами текущей сессии. Там есть живая панель состояния агентов: статус (running, idle, parked, aborted), модель, стоимость, время, количество запросов и вызовов инструментов по каждому агенту. Можно открыть агента, почитать его транскрипт в реальном времени, отправить steering‑сообщение, реанимировать «припаркованный» воркер или убить застрявший — не прерывая сессию родителя. В шапке агрегируется статус и использование по всем агентам. На широком терминале справа появляется inspector: текущий инструмент и аргументы, последний интент, состояние retry, использование окна контекста, линейку parent/child, пути вывода и патчей, а также метаданные изолированного worktree‑бранча.

Управление с клавиатуры:

• j / k, ↑ / ↓, колесо — выбор агента

• Enter / клик — открыть агента

• t — переключить вид

• / — фильтр по id или имени

• 1 / 2 — переключить Agents / Activity

• r — реанимировать припаркованного агента

• x — прервать ход, затем убить и освободить агента

• Esc — очистить фильтр и закрыть inspector/Hub

Агентные циклы и другие возможности: как запустить OMP на самом себе

Теперь про запуск агентных циклов со своими правилами, OMP даёт для этого сразу несколько рычагов:

Модели‑роли.

Девять ролей маршрутизируют работу по намерению: default, smol (дешёвый fan‑out субагентов), slow (глубокий reasoning), plan, commit, а также vision, task, advisor, tiny. То есть для каждого типа задачи — своя модель. Можно задать свои модели под роли и гонять циклы, где, например, plan‑ роль составляет план, task раскладывает на субагентов, commit пишет changelog. Плюс можно создать свои роли и привязать модель, но свои правила на этом этапе к ним не привяжешь.

Vibe‑mode.

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

/vibe # войти в режим

/vibe fix the flaky test in packages/tui # войти и сразу дать первую задачу

/vibe # запустить снова — выйти из режима

Что происходит: верхняя интерактивная сессия перестаёт сама править файлы и гонять команды. Её набор инструментов режется до read, опционального todo (которым владеет только родитель) и пяти инструментов управления воркерами. А всю грязную работу — поиск, редактирование, запуск, сборку — делают фоновые воркеры. Оркестратора только проверяет их заявления: прочитал правленые файлы и сделал вывод. Пока vibe‑режим активен, нельзя стартовать, форкать, перемещать или передовать сессию. Статусная строка показывает индикатор Vibe, а её token‑rate агрегирует генерирующих воркеров даже когда оркестратора бездействует.

Vibe‑mode использует два воркера

Каждый воркер — это настоящий персистентный субагент со своим инструментарием и собственной транскриптом сессии. При создании выбирается уровень:

Важный нюанс: уровень всегда берёт встроенное определение sonic/task, а не одноимённый кастомный агент. Если у вас в конфиге заданы agentModelOverrides.sonic / .task, они перебьют дефолт; иначе роли резолвятся через modelRoles, а фолбэком выступает активная модель сессии.

Как реализована память агента

Теперь про то, как агент реально помнит проект между сессиями. В OMP это не магия, а конкретный pipeline с бэкендами, фазами и конфигами. Память по умолчанию выключена; включается через через /settings или в кофиге:

После включения local бэкенд при старте сессии, если для текущего проекта есть сводка или вручную захваченный урок, они добавляются в системный промпт как блок Memory Guidance. Если память меняет план — на неё нужно ссылаться, а перед действием подкрепить доказательствами из текущего репозитория.

Что можно читать напрямую

Агент читает артефакты памяти через URL с memory://:

• memory://root — компактная сводка, инжектится при старте

• memory://root/MEMORY.md — полный документ долгосрочной памяти memory://root/learned.md — уроки, захваченные инструментом learn

• memory://root/skills//SKILL.md — сгенерированная playbook‑навык

• memory:// — полная строка Mnemopi (только для mnemopi)

Две фазы того, как это работает под капотом

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

Фаза 2 — консолидация. Вторая модель читает все извлечения и пишет на диск три вещи: MEMORY.md (курируемый долгосрочный документ), memory_summary.md (компактный текст для старта) и папку skills/ с процедурными playbook. Всё это предварительно редактируется на общие паттерны секретов/токенов перед записью.

Уроки, которые агент запоминает сам

Чтобы инструмент learn стал доступен, включите в конфиге autolearn.enabled или в /settings:

С локальным бэкендом learn сохраняет уроки в learned.md: новые‑первые, дедуплицированные, с маской секретов, не более 100 записей, доюовляются к следующей сессии. Структурный поиск через recall/retain/reflect/memory_edit для локального бэкенда недоступен — это фишка удалённых бэкендов.

Hindsight: память в банке, а не на диске

Если нужен remote‑бэкенд — Hindsight требует доступный сервер (дефолт http://localhost:8888) включается в конфиге:

memory:  backend: hindsight
hindsight:  apiUrl: http://localhost:8888  apiToken: ${HINDSIGHT_API_TOKEN}

или в /setting. По умолчанию используется per-project-tagged scoping: запись в общий банк с тегом проекта, а recall включает тегированные и безтеговые глобальные памяти. Можно поставить per-project (каждый проект в своём банке) или global (один банк на всех). Проект называется так: берётся корень чеккаута репозитория, его имя приводится к нижнему регистру, например ~/code/General станет project:general. Первый ход модели сессии автоматически делает recall (hindsight.autoRecall: true), а каждые три пользовательских хода по умолчанию сохраняет в фоне.

Команды управления памятью

Через /memory:

/memory view            — показать текущий payload инжекта
/memory stats           — статистика бэкенда (если поддерживается)
/memory diagnose        — диагностика бэкенда
/memory queue           — отложенные дельты памяти
/memory sync            — запустить консолидацию сейчас
/memory clear / reset   — удалить активные данные бэкенда
/memory enqueue         — форсировать консолидацию

Важный момент для Hindsight: /memory clear сначала опустошает pending‑ретейны, а потом чистит только локальное состояние сессии и кэш recall — серверный банк он не удаляет. Удалить его нужно через UI/API Hindsight.

Остальные фишки из его репозитория агента — кратко, чтобы была картина

Коротко перечислю то, что сразу бросилось в глаза:

• Magic keywords. В промпт можно вставить слово — и получить скрытую инструкцию на ход:

  • ultrathink — тщательное многошаговое рассуждение;

  • orchestrate — контракт оркестрации: раздели задачу, делегируй независимую работу параллельно, проверь каждую фазу;

  • workflowz — детерминированный мультиагентный workflow на основе персистентного ядра eval;

  • jevify — классификация «пачками» (для аудита коммитов/PR, триаж логов).

• Свои правила через project inputs. При открытии репозитория OMP загружает его project inputs: settings, extensions, hooks, tools, commands, skills, rules и project MCP‑конфиг. Плюс есть импорт из восьми уже существующих форматов — Cursor MDC, Cline .clinerules, Codex AGENTS.md, Copilot applyTo и так далее. Так что конфиги, которые команда написала квартал назад, работают и сегодня без миграций.

• Managed skills. Агент может сам создавать/обновлять/удалять изолированные навыки через manage_skill, а learn — сохранять повторяемые уроки (вплоть до промута в управляемый skill). То есть цикл «выполнил → извлёк урок → сохранил как навык» замыкается сам.

• Code execution с tool‑calling. Персистентные Python и Bun‑воркеры могут звать инструменты агента обратно по loopback‑мосту — загрузил CSV через tool.read из Python, построил график из JS, не выходя из ячейки.

• LSP в каждой правке. Переименование идёт через workspace/willRenameFiles, поэтому re‑export, barrel‑файлы и алиасированные импорты обновляются до перемещения файла. «Всё, что знает ваша IDE — агент тоже».

• Настоящий отладчик (DAP). Агент цепляет lldb/dlv/debugpy, шагает по фреймам и стэку — не print«ами. C‑бинарь упал с segfault? Прицепился к ллбд, дошёл до плохого указателя, прочитал кадр.»

• Time‑traveling stream rules (TTSR). Правила спят, пока модель не сойдёт с курса; regex‑матч прерывает поток на токене, инжектит правило как системное напоминание и повторяет с той же точки — без налога на контекст.

• Hashline — правки по хэшу контента вместо перепечатывания строк (−61%).

• GitHub как ещё одна файловая система. PR и issue — это просто пути для read: read pr://1428 возвращает тот же формат, что и локальный файл.

• ACP — тот же агент внутри Zed; SDK для встройки в Node; RPC‑режим для управления по stdio. Четыре точки входа: интерактивная, one‑shot (omp -p), RPC и ACP.

• Web_search с двадцатью тремя провайдерами (Perplexity, Gemini, Anthropic, Exa, Jina, Kagi и так далее) — и сразу структурированный маркдаун со ссылками; arxiv PDF, GitHub, Stack Overflow приходят как markdown с якорями.

• /collab— совместная сессия через сервер-посредник. Пригласить второго участника можно по ссылке или QR-коду: для совместной работы либо только для просмотра. Данные шифруются на устройствах участников; сервер-посредник пересылает их, но не может прочитать содержимое.

• Браузер и десктоп. eval управляет Chromium/Electron (stealth по умолчанию) и даже самим хостом: окна, скриншоты, нативный ввод, AX‑дерево, буфер обмена.

Напоследок демонстрирую недавно созданный мем на эту тематику, материал из фильма «Чародеи» плюс мой опыт :)