Вам не нужен ещё один Claude Code: зачем Pi оставляет сборку агента пользователю

Когда мы обсуждаем агентов для программирования, разговор быстро сводится к моделям. Какая модель Claude лучше пишет код, а какая версия GPT увереннее чинит ошибки, как Gemini работает с большим репозиторием. Но между моделью и рабочим деревом Git находится ещё один слой, от которого зависит, что агент вообще сможет сделать.

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

Интересный проект, который изменил традиционное устройство моделей — Pi. Это терминальный агент, который строит свой harness с нуля, а не надстраивается над готовым. Его автор, Mario Zechner, сознательно ограничил набор встроенных механизмов работы. Вместо попытки заранее предусмотреть все сценарии Pi предлагает основной инструментарий, который можно приспособить под себя. Oh My Pi вырос из этой основы, но выбрал другое направление: собрать больше решений в одном готовом агенте.

На примере этой пары удобно разобрать вопрос, который возникает почти у любого разработчика инструментария: сколько решений оставить пользователю, а сколько должен принять автор продукта?

Что находится между моделью и вашим кодом

Допустим, вы просите Claude Code или Codex исправить падающий тест. Модель выбирает действие: запустить тесты, прочитать файл, найти вызовы функции или изменить код. Само действие выполняет программа вокруг модели. Она проверяет разрешения, запускает инструмент и возвращает результат в контекст. Модель выбирает следующий шаг, и цикл повторяется.

В Claude Code или Codex вокруг этого цикла уже собран рабочий процесс. Есть режим планирования, в котором агент изучает проект без изменения исходников, или дочерние агенты с отдельным контекстом, или режимы разрешений, сохранение сессий и автоматическое сжатие истории, когда контекст заполняется.

Это удобно: не нужно сначала проектировать своего помощника. Но вместе с удобством вы получаете конкретные решения Anthropic или Open AI о том, как устроены планирование, делегирование и работа с контекстом, не говоря об условном вендор локе, который не позволяет эффективно использовать других вендоров. Эти харнесы позволяют настраивать поведение через инструкции, навыки, обработчики событий и внешние инструменты. 

Но что делать, если нам не нужен весь инструментарий, и мы хотим решать определенный набор задач максимально точно? Тут на сцену выходит Марио Цехнер и его разработка — PI.

Откуда появился Pi

В 2025 году Марио Цехнер уже вовсю пользовался Claude Code, но его бесило, во что тот превращался. Инструмент обрастал функциями, большая часть которых Цехнеру была не нужна. С обновлениями менялись системные инструкции и инструменты, а вместе с ними — поведение модели. Привычные рабочие процессы ломались, и при этом было сложно увидеть, что именно агент отправляет в контекст. 

Цехнер хотел инструмент с понятным устройством сессий, доступом к внутренним механизмам и возможностью построить другой интерфейс поверх того же агента. Так появился Pi, опубликованный в репозитории pi-mono.

Pi с самого начала был не только командой в терминале, но и набором компонентов:

• pi-ai предоставляет единый интерфейс к разным провайдерам языковых моделей;

• pi-agent-core отвечает за выполнение агента, вызовы инструментов и состояние;

• pi-coding-agent собирает из этих частей помощника для работы с кодом;

• pi-tui предоставляет компоненты терминального интерфейса

Упрощённо их связь представлена на схеме. Стрелки показывают, из чего собирается агент, а не направление сетевых запросов.

Собственное приложение не обязано использовать все эти компоненты. Готового агента можно встроить через SDK — набор средств для разработки приложений — или управлять им из другого процесса через RPC. Если его устройство не подходит, можно взять pi-agent-core и самостоятельно определить интерфейс и правила работы.

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

Как Pi возвращает контроль над агентом

Pi отделяет базовые механизмы агента от организации работы. В стандартной поставке сознательно нет встроенных дочерних агентов, режима планирования, списка задач и запросов на разрешение действий. Эти возможности предлагается добавлять под конкретный сценарий.

Например, за одной функцией «дочерние агенты» могут скрываться совершенно разные требования. Одному пользователю нужны параллельные исследователи с отдельными контекстами, другому — связка «исполнитель и проверяющий», третьему — агенты в отдельных рабочих деревьях Git с контролируемым переносом изменений. Встроенная реализация неизбежно отдаёт предпочтение какому-то из этих вариантов.

Pi оставляет выбор расширениям, сторонним пакетам или внешнему запуску отдельных экземпляров агента. Аналогично план можно хранить в обычном файле либо реализовать для него специальный режим.

Для этого недостаточно возможности дописать несколько строк в системные инструкции. Расширения Pi позволяют добавлять инструменты, команды, обработчики событий и элементы интерфейса. Навыки и шаблоны запросов хранят повторно используемые инструкции, а пакеты позволяют распространять всё это вместе.

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

Такой порядок работы можно реализовать поверх Pi: определить доступные инструменты, правила подтверждений и проверок, решить, что передавать дочерним агентам в контекст и какой результат принимать обратно. Если расширений готового агента недостаточно, остаётся возможность перейти на уровень ядра.

Именно так Pi отвечает на проблемы готовых харнесов: даёт доступ к механизмам, от которых зависит поведение агента, и позволяет менять их под свои задачи. Это не гарантирует одинаковых ответов модели и не избавляет от изменений при обновлениях. Но у пользователя появляется больше возможностей понять причину изменения поведения и вмешаться в неё.

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

Есть проблема: не каждый хочет собирать инструмент

Разработчику, которому нужен агент для работы над репозиторием, может быть совершенно неинтересно, например, выбирать архитектуру дочерних агентов. Ему хочется поручить задачу нескольким исполнителям и получить результат. Для переименования символа нужен инструмент, который учитывает структуру кода, а для поиска причины падения — доступ к отладчику без необходимости каждый раз объяснять агенту, как его запустить.

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

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

Именно такой вариант предлагает Oh My Pi.

Oh My Pi: готовый агент, устройство которого можно менять

Джан Бёлюк взял Pi за основу и создал Oh My Pi — форк с более широким набором встроенных инструментов для разработки. OMP сохраняет разделение на компоненты для работы с моделями, выполнения агента и терминального интерфейса, но больше решений об их совместной работе принимает внутри самого проекта.

Пользователь получает поддержку языковых серверов через LSP, управление отладчиком, выполнение Python и JavaScript, дочерних агентов и собственные инструменты поиска и редактирования. Их не нужно сначала собирать из независимых расширений, хотя языковые серверы, отладчики и окружение проекта по-прежнему могут требовать настройки.

Возникает закономерный вопрос: если нужен готовый агент, почему не остаться на Claude Code?

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

Также OMP имеет свои механизмы и принципы работы с кодом, которые превосходят традиционные харнесы — рассмотрим их далее.

Кто принимает решение

Сравнение Pi и OMP легко превратить в таблицу: здесь нет LSP, там есть; здесь дочерние агенты через расширения, там встроенные. Но такая таблица почти ничего не объясняет о причинах различий.

Полезнее изучить, кто принимает проектные решения в каждом подходе: пользователь или вендор.

Делегирование задач

В подходе Pi пользователь или автор расширения определяет, как устроены дочерние агенты. OMP предоставляет собственный инструмент task для делегирования, включая параллельную работу и возможность изоляции рабочих пространств. Для наблюдения за исполнителями и управления ими предусмотрен Agent Hub.

OMP уже набор связанных решений: как запускать исполнителя, как показывать его состояние, как вмешиваться в работу и как возвращать результат. Пользователю не нужно проектировать весь этот протокол самостоятельно.

Работа со структурой кода

Pi как и любой харнес даёт  доступ к командной оболочке, которая позволяет вызывать языковой сервер(LSP) или воспользоваться внешней утилитой. Но возможность запустить команду ещё не означает, что семантические операции встроены в его повседневную работу.

OMP предоставляет LSP-инструменты для диагностики, навигации, переименований и применения исправлений, которые предлагает языковой сервер. Эти операции становятся частью обычной работы агента с кодом.

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

Исполнение и отладка

Похожая разница возникает с выполнением кода. OMP предоставляет постоянные Python- и JavaScript-сессии, причём из исполняемого кода можно обращаться к инструментам самого агента. JavaScript-часть использует Bun.

Отладчик подключён через DAP — протокол взаимодействия с отладчиками. Агенту доступны операции с точками остановки, пошаговым исполнением, стеком и переменными.

Сами протоколы и среды исполнения не гарантируют успешного исправления ошибки. Для конкретного языка всё ещё нужны подходящие зависимости и настройка. Но авторы OMP уже определили, как агент должен обращаться к этим возможностям и как результат будет представлен в сессии.

Поэтому различие между проектами точнее описывать через количество решений, уже принятых за пользователя. Pi оставляет больше решений на уровне расширений и пользовательской сборки. OMP включает больше согласованных решений в основной продукт. При этом Pi не лишён собственных нюнсов в базовой комплектации, а OMP не перестаёт быть расширяемым.

Когда у форка появляется собственная архитектура

Признаки расхождения видны не только в списке инструментов. В OMP есть пакет pi-natives, который подключает нативный код через N-API, и отдельные компоненты на Rust для командной оболочки, работы с синтаксическими деревьями, обхода файлов и изоляции рабочих пространств. Также проект содержит omp-stats, локальную панель статистики использования моделей.

Это существенно другой масштаб изменений, чем дополнительная инструкция для модели или команда в меню. Нативные компоненты участвуют в исполнении инструментов, а значит, требуют собственной сборки, тестирования и поддержки платформ.

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

Такое решение затрагивает сразу несколько механизмов: чтение файла, формат видимого модели текста, применение изменений и обработку ошибок. Его ценность зависит от того, насколько хорошо эти части согласованы.

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

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

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

Для чего выбирать Pi

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

При этом это не заготовка, которую сначала нужно довести до рабочего состояния. Pi уже включает терминального агента, базовые инструменты и управление сессиями.

Поэтому Pi можно использовать как готовый инструмент, но его главная ценность в том, что он служит программируемой основой для собственных агентов. Встроенный кодовый помощник показывает один из вариантов такого применения.

Для чего выбирать Oh My Pi

OMP ближе к Claude Code, Codex CLI и OpenCode: это готовый инструмент для ежедневной работы с кодом.

Он закрывает практические задачи без собственной интеграции: исследование репозитория, применение правок, делегирование, наблюдение за агентом, диагностика и отладка.

OMP построен на архитектуре Pi, но это не просто сборка, а форк с собственными архитектурными изменениями. Авторы уже приняли многие решения о работе основных функций. Пользователь получает больше возможностей сразу после установки, но меньше свободы в выборе базовых подходов.

Меньше функций — не значит хуже 

На бенчмарке Composio с DeepSeek V4 Flash Pi справился с 20 задачами из 30. Claude Code и Codex решили по 16, OpenCode — 14. Oh My Pi оказался между ними с результатом 17 из 30.[6]

Это результаты пяти участников из восьми. Все работали с DeepSeek V4 Flash, одним набором задач и внешними инструментами через MCP-маршрутизатор Composio. На каждую задачу отводилось 900 секунд. Успех проверялся программно по состоянию приложений: недостаточно было написать убедительный ответ, требовалось выполнить все действия и не задеть посторонние данные.

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

Но это не тест написания кода. Агенты работали со Slack, Google Sheets, календарями, GitHub и другими сервисами: искали записи, сверяли данные и выполняли цепочки действий. Кроме того, настройки не были полностью одинаковыми: у Pi был выбран уровень рассуждений high вместо max, а 24 из 30 его запусков шли через официальный API DeepSeek, а не OpenRouter.

Поэтому этот результат не доказывает, что Pi лучше пишет код или что весь отрыв обеспечил именно минимализм. Он показывает более узкую, но полезную вещь: в конкретном тесте с одной моделью Pi решил больше задач, чем Claude Code, Codex, OpenCode и собственный форк. Дополнительные возможности обвязки сами по себе ещё не гарантируют лучшего результата.

Где заканчивается harness

История Pi и Oh My Pi возвращает нас к более общему вопросу: какой должна быть основа агента — набором компонентов для собственных решений или готовым приложением?

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

Pi и OMP позволяют рассмотреть этот спор на общей технической основе. Первый оставляет больше решений об организации работы пользователям и авторам расширений. Второй берёт их внутрь и развивает как части одного продукта.

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

НЛО прилетело и оставило здесь промокод для читателей нашего блога:
-15% на заказ нового VDS — HABRFIRSTVDS.

Положение об акции