Опишите её в двух-трёх предложениях. Я отвечу, что проверить первым и нужен ли здесь ИИ.
Несколько сильных агентов создают новую работу по координации. ORCH хранит состояние, изолирует задачи, повторяет сбои и возвращает человеку контроль.
ORCH превращает несколько ИИ-агентов в управляемую команду. Он берёт на себя работу, которая появляется между ними: распределение задач, хранение состояния, изоляцию изменений, повтор после сбоя и проверку результата.
Именно эта работа обычно возвращается к человеку.
Представьте три открытых терминала. В одном агент меняет серверную часть, во втором пишет интерфейс, в третьем запускает тесты. Вы переносите контекст из окна в окно, напоминаете о зависимостях и следите, чтобы два агента не полезли в один файл. Один из них остановился, но сообщил об этом невнятно. Другой закончил задачу, хотя половина критериев осталась невыполненной.
Формально агенты работали параллельно. Фактически у вас появилась должность диспетчера.
Один агент помещается в диалог. Можно дать ему задачу, дождаться ответа и поправить результат. С пятью агентами эта модель рассыпается. Появляются вопросы, на которые сама языковая модель ответить не может.
Кому принадлежит задача? Какая работа уже завершена? Что зависит от неё? Можно ли повторить упавший шаг? Кто имеет право принять результат? Что произошло во время ночного запуска?
Чем сильнее становятся агенты, тем заметнее этот организационный слой. Интеллекта уже хватает для большой части работы. Предсказуемости процесса всё ещё не хватает.
Я начал собирать ORCH именно из этого разрыва. Мне был нужен локальный оркестратор, который обращается с агентами как с исполнителями внутри процесса. У каждого есть роль, участок работы, состояние и понятный результат. Владелец проекта видит ход работы и вмешивается там, где решение действительно требует человека.
На 31 июля 2026 года публичный репозиторий ORCH получил 125 звёзд и 13 форков. В основной ветке накопилось 580 коммитов, а на GitHub опубликовано 33 релиза. Актуальной версией на момент среза была v1.0.33.
Эти числа не доказывают качество продукта сами по себе. Они показывают темп работы. Репозиторий появился 10 марта 2026 года, поэтому сотни изменений накопились меньше чем за пять месяцев.
В основе ORCH лежит простая модель. Цель раскладывается на задачи, задачи назначаются агентам, а каждая из них проходит через явные состояния.
todo → in_progress → review → done
Такая строка выглядит скромно. На практике она убирает большую часть догадок.
Задача в todo ещё никем не взята. in_progress означает, что есть активный исполнитель. review требует проверки результата. done фиксирует принятый артефакт. Для ошибок и повторов существуют отдельные ветки состояния.
ORCH следит за переходами и хранит историю. Агент может отправить сообщение другому агенту, поделиться контекстом или вернуть задачу с объяснением. Руководитель команды видит общую цель и распределяет работу по участникам. У процесса появляется память, которая живёт дольше отдельного диалога.
Это меняет роль промпта. Он остаётся важным, но перестаёт быть единственным носителем управления. Часть правил переезжает в сам процесс: кто выполняет шаг, что считается завершением, какой результат проверяется и куда идёт работа дальше.
В разработке самая дорогая ошибка параллельности часто выглядит буднично. Два агента одновременно меняют одни файлы. Один переименовал интерфейс, второй строит код на старом контракте. Оба отчёта звучат уверенно, а репозиторий уже находится в противоречивом состоянии.
ORCH выдаёт агентам изолированные git worktree и отдельные ветки. Каждый работает со своей копией состояния проекта. Изменения превращаются в самостоятельный артефакт, который можно посмотреть, проверить и только затем объединить с остальной работой.
Изоляция не отменяет конфликты проектных решений. Она делает их видимыми до того, как один агент затрёт работу другого.
Для задач вне разработки работает тот же принцип. Исполнителю нужен ограниченный участок, определённый вход и проверяемый выход. Исследователь возвращает заметку со ссылками. Аналитик отдаёт расчёт и исходные данные. Редактор создаёт версию текста. Проверяющий принимает результат по заранее записанным критериям.
Команда начинает работать лучше, когда её артефакты можно осмотреть отдельно от рассказа исполнителя о проделанной работе.
Языковые модели нестабильны по определению. Агент может упереться в лимит, зависнуть на инструменте, неверно понять задачу или завершить её слишком рано. В ручном режиме человек замечает сбой, открывает терминал и запускает работу снова.
ORCH рассматривает такой исход как штатное состояние системы. Он отслеживает выполнение, поддерживает таймауты и политики повторов, сохраняет причину ошибки. Если автоматический повтор исчерпан, проблема остаётся видимой.
Это важный сдвиг. Надёжная мультиагентная система строится с ожиданием отказа. Хороший сценарий определяет дальнейшее действие заранее.
Для недорогого и обратимого шага уместен автоматический повтор. Изменение платежей, доступов или продуктивной инфраструктуры требует человеческого подтверждения. Между этими полюсами можно настроить собственные правила.
Автономность здесь становится инженерной характеристикой. Её можно увеличивать по мере того, как процесс доказывает свою устойчивость.
Разговоры об автономных компаниях часто начинаются с количества агентов. Я считаю полезнее начать с точек принятия решений.
Человек задаёт цель, ограничения и критерии приёмки. ORCH помогает провести работу через исполнителей и вернуть результат на проверку. Этап review существует для того, чтобы важный артефакт не становился частью проекта только потому, что агент объявил задачу завершённой.
Такой подход особенно полезен на первых запусках. Вы видите, где агенты задают одинаковые вопросы, какие задачи требуют слишком много контекста и на каких шагах чаще происходят повторы. После этого правила можно уточнить, а часть проверок автоматизировать.
Владелец процесса постепенно перестаёт маршрутизировать каждое сообщение. Его внимание остаётся у решений с высокой ценой ошибки.
ORCH хранит состояние локально в YAML, JSON и JSONL внутри каталога .orchestry. Для старта не нужны отдельная база данных, облачный аккаунт или Docker.
Это практический выбор. Состояние можно открыть обычным редактором, включить в резервное копирование, проверить после сбоя и разобрать без доступа к внешней панели. Оркестратор работает поверх проекта, а данные о задачах остаются рядом с ним.
Локальная модель особенно удобна для разработчиков и небольших команд. Она сокращает стоимость первого эксперимента. Можно установить пакет, описать команду и проверить процесс на реальной задаче без отдельного инфраструктурного проекта.
Для длительных запусков есть daemon-режим. Для автоматизированных контуров предусмотрен однократный режим, который подходит для CI/CD. Логи остаются структурированными, поэтому работу можно наблюдать внешними инструментами.
ORCH не привязан к одной модели или одному интерфейсу. Адаптеры подключают Claude, Codex, Cursor, OpenCode и другие среды. Через Shell участником команды может стать любой терминальный инструмент.
Это расширяет само понятие агента. Один участник пишет код, второй запускает тесты, третий выполняет сканер безопасности, четвёртый собирает отчёт. Им не обязательно быть одинаковыми. Им нужна общая модель задач, сообщений и результатов.
Тот же подход переносится за пределы разработки. Редакционный процесс может включать исследование, черновик, проверку фактов и выпуск. Операционный процесс может собирать данные, применять правила, готовить решение и отправлять его на согласование.
Здесь важна проверяемость результата. Если работу нельзя разложить на понятные входы, выходы и критерии, добавление агентов создаст больше шума.
Оркестратор не исправляет расплывчатую цель. Он быстро и аккуратно распределит расплывчатость по всей команде.
Если задача сформулирована как «сделать продукт лучше», агентам не за что зацепиться. Если два задания зависят от архитектурного решения, которое ещё никто не принял, параллельный запуск размножит несовместимые варианты. Если критерии приёмки отсутствуют, этап review превратится в формальность.
ORCH усиливает декомпозицию. Хорошую декомпозицию он превращает в воспроизводимый процесс. Плохую делает заметной раньше.
Поэтому я начинаю не с большой виртуальной организации. Я выбираю один повторяемый участок, где уже трачу время на передачу контекста и проверку состояния. Затем описываю ожидаемый артефакт, цену ошибки и точку человеческого решения.
После первого прогона видно, какая часть сложности принадлежала самой работе, а какая возникала из ручной координации.
Для первой проверки достаточно двух агентов и одного процесса. Например, один готовит изменение, второй проверяет его тестами и критериями. Такой контур уже показывает, умеет ли система сохранять состояние, передавать результат и корректно реагировать на сбой.
ORCH устанавливается как npm-пакет. После инициализации проекта можно выбрать готовую организацию или описать собственную, поставить цель и запустить участников.
Исходный код открыт на GitHub, пакет доступен в npm.
При оценке первого запуска я бы смотрел на три вещи: сколько ручных передач контекста исчезло, сколько сбоев стало видно без проверки терминалов и сколько результатов дошло до review в форме, пригодной для решения.
Количество агентов само по себе ничего не доказывает. Полезная система возвращает человеку внимание и при этом сохраняет контроль над результатом.
Для этого я и сделал ORCH.