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

Учился на технолога бродильных производств. Защитил кандидатскую. Управляю пивоварней и параллельно — исполнительный директор в фирме по производству пищевого оборудования. Код не писал никогда. Но в детстве, когда появился нормальный интернет, я развлекался тем, что ставил на комп разные дистрибутивы Linux — от OpenBSD до классических. Не особо понимал, как их настраивать и зачем мне это. Потом когда стал работать — понял в чём сила Linux, но для настройки просто искал советы в интернете и копировал оттуда команды, или просил брата помочь.

А потом появились LLM. И я понял — вот оно. Можно не учить синтаксис, не зубрить фреймворки. Можно объяснить что нужно и получить работающий код. Вдохновился. Попробовал. Столкнулся с галлюцинациями, бесконечными переделками, кода сгенерировано уже куча — а он не работает. Перегорел. Попробовал снова.

Контекст такой: мне нужно было сделать АСУ ТП для пивоварни. Система управления технологическим процессом — датчики, клапаны, насосы, частотники. Я решил, что ИИ уже дорос. Начал с одного Claude‑агента: я ему говорю что делать, он делает. Потом дошёл до шести параллельных агентов. Они начали конфликтовать, переделывать работу друг друга, плодить баги. На одну фичу — пять новых проблем. Проект рос, но болезненно.

А потом на предприятии по производству оборудования случилась попытка рейдерского захвата. Пришлось бросить все и месяц заниматься защитой станков. Код и агенты отошли на второй план.

Когда немного отпустило, я решил сделать себе фитнес‑приложение. Занимаюсь физкультурой больше 20 лет, но нормального трекера со всеми нужными мне функциями так и не встретил. Нужно своё: оффлайн, терминальная эстетика, нормальное логирование тренировок — чтобы потом можно было скармливать данные внешним LLM для анализа и советов. И пока делал приложение, проект разросся. Появились другие агенты, а моя старая архитектура со swarm‑оркестратором из прошлого проекта АСУ ТП помогала — агенты хотя бы не конфликтовали.

И в какой‑то момент я понял: мне нужно строить не приложение. Мне нужно строить систему для строительства приложений. Архитектуру управления архитектурами. Вот что из этого вышло.

Зачем вообще это надо

Была простенькая многооконная поделка на tmux. К утру стал конвейер на Zellij. Один мультиплексор, четыре таба, в каждом — панели с агентами:

Zellij сессия "cockpit"
├─ Alt+1 dev        : aider-1  aider-2  aider-3  aider-4   (DeepSeek через LiteLLM)
├─ Alt+2 premium    : Claude Opus  ·  Kimi K2.6 (DeepInfra)
├─ Alt+3 research   : agy-personal  agy-work  agy-third  ·  shell
└─ Alt+4 orchestrator : Claude Opus + протокол ORCHESTRATOR.md

Зачем столько? Я упирался в лимиты. Даже на подписке Max за 200 долларов - лимиты. И очень много работы уходило впустую: умный агент тратил дорогие токены на тупую рутину, тупой агент ломал то, что должен был делать умный. Хотелось простого: тупую работу - тупому агенту, сложную - тому кто потянет. А если не может потянуть - пусть не делает, а скажет что не может.

| Кто           | Модель              | За что отвечает           | Цена         |
| ------------- | ------------------- | ------------------------- | ------------ |
| Оркестратор   | Claude Opus         | раздача задач, разбор     | подписка     |
| aider ×4      | DeepSeek V4 Pro     | фичи, правки кода         | ~$0.5 / 1M   |
| code review   | DeepSeek V4 Flash   | тесты, ревью              | ~$0.07 / 1M  |
| Kimi K2.6     | DeepInfra           | анализ, второе мнение     | дёшево       |
| Qwen 14B      | Ollama, локально    | ревью, скриншоты, мелочь  | $0           |

Qwen — это не только «ноль денег». Он подключается к телефону через ADB, делает скриншоты, проверяет что интерфейс выглядит как надо. Быстро и бесплатно.

Посередине — LiteLLM на localhost. Через него ходят все, кроме Opus. Проверяю что все живы одним curl:

$ curl -s http://localhost:4000/health | jq '.healthy_count, .unhealthy_count'
9
0

Девять живых, ноль трупов. Работаем.

Почему оркестратор, а не я сам

Начинал я как пивовар - сам крутил гайки, сам варил, сам мыл танки. Потом дорос до руководителя. Могу и сейчас встать к заторному чану. Но смысл? Моя работа — чтобы система работала сама, а я давал направление развития и правил мелкие сбои.

С кодом решил так же. Оркестратор — тот же Opus, но с протоколом в системном промпте:

claude --model opus --append-system-prompt "$(cat ORCHESTRATOR.md)"

Архитектуру этого всего придумывал не я один. Я давал внешнее понимание — как должно работать, где руководитель, где исполнители. А конкретные решения подсказывали ресёрчи, сами агенты, иногда брат‑программист. Правда, я половину того, что он говорил, не понимал. Но в процессе разговора появлялись идеи, которые потом ложились в систему. Как минимум я понимал, что многое делаю не так, и надо переделывать.

Aider не принимает Enter - полдня мучений

Команда из четырёх aider стоит по панелям Zellij. Кидаю первому задание, жму Enter - тишина. Курсор моргает. Агент не шевелится.

Я понимал, что проблема в Zellij. Видел, что когда ввожу команду, терминал её не передаёт агенту, а просто жуёт как текстовый редактор. Но как это починить — вообще не представлял. Полез задалбывать агентов: делай ресёрчи, ищи почему, чини. Долгая работа через Ctrl+C и Ctrl+V и голосовой ввод.

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

Грабля первая. REPL у aider построен на prompt_toolkit - библиотеке, которая перехватывает ввод и сама разбирает каждое нажатие. А Zellij гоняет те же коды через свой слой. Два разбирателя на одну клавишу. Enter до агента не доходил.

Грабля вторая. Я оборачивал запуск в timeout 3600, чтобы зависший агент не жил вечно. А timeout по умолчанию отселяет процесс в новую группу. И когда процесс не из основной группы лезет читать ввод терминала, Linux его останавливает сигналом. Агент честно ждал, пока его разбудят. В автоматической панели будить некому. Никогда.

Вот что агент нашёл через strace:

$ strace -p 48213
read(0, 0x7ffd...,  4096)   = ? ERESTARTSYS
--- SIGTTIN {si_signo=SIGTTIN, si_code=SI_KERNEL} ---
--- stopped by SIGTTIN ---

Я из этого вывода понял одно: процесс остановлен, и это не баг, а так задумано в Linux. Детали объяснял агент.

Грабля третья. Когда пробовал вставлять текст скриптом - Zellij оборачивал вставку в специальные маркеры (bracketed paste), и REPL опять глотал Enter.

Починилось двумя флагами:

# было - агент в ступоре:
timeout 3600 aider --model deepseek-v4-pro

# стало - берёт задания и работает:
timeout --foreground 3600 aider --model deepseek-v4-pro --no-fancy-input

--foreground — процесс остаётся в нужной группе, сигнал не прилетает. --no-fancy-input — выключает prompt_toolkit, ставит простой readline, который мультиплексор не бесит. Всё.

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

Gemini CLI зависает — удаляю CLI, оставляю голый API

У меня есть Gemini. Его работа: гнать черновики, вести журнал, делать ресёрч в файлах в фоне. Чтоскажу — то и делает. Никакого интерактива. Закинул тему — забрал текст.

Начал с официального gemini CLI. Три запуска подряд — CLI самовольно уходил в агентский режим. Вместо текста лез шарить по проекту, читал файлы, строил деревья каталогов, предлагал порефакторить виджеты. Я его просил абзац написать, а он мне ревью кода делал. Без спроса.

Флаг песочницы не помог. OAuth‑токен протухает за пару дней, а обновить его в headless‑режиме нельзя — хочет браузер. Конвейер встаёт.

Выкинул CLI. Работаю напрямую через LiteLLM:

curl -s http://localhost:4000/chat/completions \
  -H "Authorization: Bearer sk-ant-fake-for-litellm" \
  -d '{"model":"gemini-3.5-flash",
       "messages":[{"role":"user","content":"Напиши раздел про оркестрацию"}]}'

Запрос — ответ — jq — файл. Никакого «agent mode activated». Никакого сканирования дисков.

Этот текст, кстати, тоже прошёл через конвейер. Gemini гнал черновик, я диктовал голосом правки, Claude вычищал. Система работает не только на код.

send_to_pane.sh — жёсткий поводок для оркестратора

Дай агентам волю — они на каждое задание будут открывать новую панель в терминале. К обеду — 58 панелей и 142 процесса. OAuth слетает, контекст теряется, зомби жрут память.

Запретил new-pane в системном промпте. Панели размечаются один раз при старте из шаблона. Живут всю смену. Работать только в них.

Как отправить задание в уже открытую панель? Скрипт send_to_pane.sh:

# Найти панель по имени
PANE_ID=$(zellij -s cockpit action list-panes --json | jq -r --arg n "$TARGET" '
  .[] | select(.title==$n and .exited==false) | .id
')

# Отправить текст
zellij -s cockpit action write-chars --pane-id "$PANE_ID" -- "$CONTENT"

# Нажать Enter (байт 13 = CR)
zellij -s cockpit action write --pane-id "$PANE_ID" 13

Если текст длинный — режем на куски по 3000 символов. Буфер TTY в Linux — 4096 байт, всё что больше — обрезается. Между кусками пауза 50 мс. Enter — строго после последнего куска.

Если панель мертва ("exited": true) — скрипт не пытается её оживить. Пишет ошибку и вылетает. Реанимация — вручную.

Оркестратор закрыл шесть багов — и провалил оркестрацию

Оркестратор — Opus с протоколом. Его работа — не пахать, а раздавать задания и контролировать.

Сделалбаг‑репорт приложения после тренировки — шесть проблем: от отладочной строки в интерфейсе до «бессмертного» Android‑уведомления, которое не смахивается. Отдал оркестратору и пошёл заниматься основной работой.

Возвращаюсь — работа сделана. Причём хорошо:

$ flutter analyze --no-fatal-infos | tail -1
No issues found!
$ flutter test 2>&1 | tail -1
00:12 +63: All tests passed!

Шесть из шести. Один баг раскопал глубже, чем было в репорте: баннер «чек-ин не заполнен» висел потому что SQL сравнивал дату строкой WHERE date = '2026-05-22', а Drift хранит её с временем. Строка с голой датой не матчила никогда.

А потом я посмотрел на остальных.

$ zellij -s cockpit action list-panes --json \
  | jq -r '.[] | select(.title|test("aider")) | "\(.title): idle"'
aider-1: idle
aider-2: idle
aider-3: idle
aider-4: idle

Четыре aider не задействованы. Оркестратор не отдал им ни одного задания. send_to_pane.sh не вызвался ни разу. Он всё сделал сам — через python3‑однострочники, в обход всей команды.

У меня есть агент‑наблюдатель — отдельный Claude Code, который пишет протокол смены. Его отчёт:

| Показатель                       | Значение                   |
| -------------------------------- | -------------------------- |
| Задач получено                   | 6 багов                    |
| Делегировано aider               | 0 (send_to_pane не вызван) |
| Сделано самостоятельно           | 6 / 6                      |
| Простой aider                    | ~20 минут                  |

Процентов шестьдесят было рутиной: убрать дубль «20 кг кг», обернуть отладочный SnackBar в if (kDebugMode), добавить пару констант. Это aider сжевал бы за минуту.

Спрашиваю оркестратора — почему. Сказал: «контекст уже был, дописать самому показалось дешевле, чем формулировать ТЗ». Я и сам так думаю иногда, что проще самому сделать, чем объяснить. Видно, что LLM обучены на людях. Но я‑то знаю, к чему приводят такие решения.

Оркестратор сам предложил переписать свой алгоритм:

### ⛔ Gate делегирования (обязателен перед любой правкой кода)
Прежде чем редактировать .dart самому - обязан записать строку:
«Не делегирую aider потому что: ___»
Допустимые причины (закрытый список): safety-critical; смена контракта
модуля; знание скрытого механизма фреймворка; правка pubspec/analysis_options.
НЕ являются причинами: «контекст уже у меня в голове», «быстрее самому».

Один агент схалтурил, второй зафиксировал. Первый сам переписал свои правила. Я только утвердил. Часто в конце оркестрации я спрашиваю агента, что надо сделать лучше — и он даёт вполне толковые правки.

Сейчас я ловлю себя на мысли, что больше настраиваю оркестрацию, пишу обёртки и переписываю внутренние регламенты для моделей, чем вообще занимаюсь исходным приложением или реальной АСУ ТП. И эта трясина затягивает с головой. Но когда есть реальные результаты работы, понимаешь — оно того стоило.

Завод ИИ-агентов в одном терминале через оркестрацию