Мини-агенты и оркестратор для фермы: автоматизация на MQTT

К этому моменту в серии у вас уже могут быть отдельные куски: датчики и MQTT, полив, вентиляция, камера с нейросетью, текстовый консультант, мост со сводками. Хаос начинается не от нехватки ИИ, а от десятка cron-скриптов, которые не знают друг о друге. Оркестратор — тонкий слой дисциплины: кто говорит, кто предлагает, кто имеет право нажать на кнопку — и когда обязательно спросить человека.

«Агент» здесь — не фантастика из кино. Это небольшой постоянный процесс (скрипт / systemd-сервис) с одной обязанностью. Как в бригаде: один смотрит датчики, другой смотрит фото, третий предлагает план работ, четвёртый крутит реле — но только если бригадир (оркестратор + вы) разрешил.

Финал серии из плана. Цель — автоматизация рутины без передачи фермы «на автопилот».

Четыре мини-агента и бригадир

• Наблюдатель — читает датчики, пишет сводки, шлёт мягкие алерты («влажность падает», «ночь холодная»).
• Диагност — гоняет модель по фото с ESP32-CAM, возвращает класс и уверенность.
• Планировщик — предлагает полив/проветривание/осмотр с учётом почвы, прогноза и алертов; может спросить LLM по сводке.
• Исполнитель — публикует MQTT-команды на реле и серво только после политики оркестратора.

Над ними — оркестратор: подписки на топики, очередь решений, эскалация человеку, таймауты «нет ответа — безопасный default».

Топики MQTT: общий язык бригады

farm/teplica2/sensors/raw
farm/teplica2/alerts
farm/teplica2/vision/result
farm/teplica2/plan/propose
farm/teplica2/actuators/cmd
farm/teplica2/human/confirm
farm/teplica2/advice/llm

Сырые датчики не должны напрямую дёргать исполнителя «в обход». Исключение — заранее прописанные аварии: перегрев, протечка. Их можно закрыть коротким локальным правилом (как предохранитель), без LLM и без ожидания чата.

Политика безопасности: сердце системы

Без политики агенты превратятся в шумный базар. С политикой — в спокойную бригаду.

1. Аварии (critical): T выше порога, протечка, опасное давление — исполнитель может действовать по жёстким правилам без LLM. Потом уведомление человеку.
2. Рекомендации модели зрения и LLM — только propose, никогда сразу cmd.
3. Рискованные действия (ночной полив большим объёмом, любое опрыскивание, отключение отопления в холод) — всегда human/confirm в боте.
4. Таймаут: нет ответа 20–30 минут на рискованный план → безопасный default (обычно «не лить / не прыскать»).
5. СЗР: оркестратор не имеет сценария «автоопрыскивание по классу болезни». Максимум — «создать задачу осмотра» и чек-лист.

Запомните фразу: propose freely, act carefully. Предлагать можно часто. Действовать на железо — редко и с правом.

def on_alert(msg):
    if msg["severity"] == "critical":
        executor.safe_action(msg)
        notify(msg)
        return
    plan = planner.propose(context=msg)
    if plan.needs_confirm:
        ask_human(plan)
    else:
        executor.run(plan)  # только белые списки безрисковых действий

def on_human_confirm(plan_id, ok):
    if ok:
        executor.run(plans[plan_id])
    else:
        log_rejected(plan_id)

Рабочий сценарий «день из жизни»

07:10. Наблюдатель видит, что ночной минимум был на грани. Шлёт soft-alert. Планировщик предлагает: «проверить укрытие / не открывать форточки слишком рано». Оркестратор шлёт вам текст. Вы жмёте «ок, учту» — до железа дело не дошло.

11:40. Диагност по CAM-3: late_blight 0.84. Планировщик (опционально через LLM по сводке) предлагает осмотр ряда 3 и список проверок без химии. Оркестратор эскалирует вам. Вы идёте смотреть. Опрыскиватель молчит, пока вы сами не решите по регламенту.

15:00. Почва суше порога, прогноз без дождя. Планировщик предлагает короткий полив. Если у вас это действие в «белом списке» дневных малых доз — оркестратор может разрешить исполнителю. Если доза большая или ночь — снова confirm.

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

Ложные тревоги на уровне агентов

Каждый агент может ошибаться по-своему:

• Наблюдатель — от плохого датчика в колее (сначала монтаж, см. влажность).
• Диагност — от блика и чужого сорта (порог уверенности, false_positive, дообучение).
• Планировщик/LLM — от самоуверенного текста (запрет СЗР, только чек-листы).
• Исполнитель — от кривой команды (белые списки топиков и диапазонов: открыть форточку не больше 40% за раз).

Антиспам оркестратора:

• дедупликация одинаковых propose;
• ночное молчание по не-critical;
• лимит действий на клапан в час;
• журнал «предложили → подтвердили → сделали → что вышло».

Как разнести процессы, чтобы падение одного не роняло всё

Каждый агент — отдельный systemd unit на Raspberry Pi. Упал диагност — полив по порогам жив. Упал планировщик — аварии всё равно закрываются. Оркестратор не должен быть единственной точкой, без которой теплица задыхается: critical-правила можно дублировать прямо на контроллере ESP32 (локальный watchdog температуры).

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

Стоимость пилота

• Если MQTT, Pi, полив и одна камера уже есть — оркестратор почти «бесплатен» по железу: это время на скрипты и политику.
• Заложите 1–2 спокойных выходных на каркас топиков + бот confirm.
• Облачная LLM — по желанию, редко, через сводки (консультант, мост).
• Не покупайте «платформу агентов» ради модного слова. На старте хватает Python, MQTT и честных правил.

Постепенный rollout: за выходные и за месяц

1. День 1–2. Оставить аварийные пороги как есть. Оркестратор только слушает alerts уровня warning и пишет вам в бот — без команд.
2. Неделя 1. Подключить диагност на одну CAM. Propose осмотра, без автоматики.
3. Неделя 2. Планировщик шлёт текстовые предложения по поливу/вентиляции. Исполнитель выключен.
4. Неделя 3. Белый список безрисковых действий: например, открыть форточку на 20% днём при T>32. Всё остальное — confirm.
5. Месяц 2. Расширять белый список точечно. СЗР так и остаётся вне автоисполнения.

Не начинайте с «агентов», если нет стабильных датчиков и понятного полива. Сначала понимание инструмента, выбор типа сети, железо поля — потом бригада скриптов.

Белый и чёрный списки действий

Проще всего думать списками — как допуски для нового тракториста.

Белый список (можно автоматом после оркестратора, без confirm):

• открыть форточку на небольшой процент днём при ясном перегреве;
• включить циркуляционный вентилятор по порогу температуры;
• записать задачу «осмотреть ряд» в журнал;
• отправить вам сводку и чек-лист.

Серый список (только после confirm в боте):

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

Чёрный список (никогда автоматом в этой архитектуре):

• включение опрыскивателя / насоса СЗР по классу болезни;
• изменение доз удобрений «по совету LLM»;
• отключение критичных контуров безопасности;
• команды на устройства, которых нет в инвентаре топиков (защита от опечаток и чужих сообщений в брокере).

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

Как не превратить бот в тиранию уведомлений

Оркестратор должен уважать ваш сон и работу руками. Практичные правила общения:

• critical — сразу, коротко, с фактом и уже выполненным safe_action (если был);
• warning — пачкой утром или не чаще N раз в час на теплицу;
• advice от LLM — по запросу или раз в сутки, не на каждый чих датчика;
• кнопки ответа крупные: «подтвердить», «отклонить», «отложить на час».

Если вы три дня подряд только отклоняете один и тот же propose — оркестратор должен снизить частоту или поднять порог, а не «настаивать». Иначе вы выключите систему целиком, как надоедливого помощника.

Учебный полигон перед настоящей теплицей

Перед тем как дать исполнителю право на живые реле, прогоните «сухой» режим:

1. Исполнитель пишет команды в лог would_cmd, но не публикует в actuators.
2. Вы неделю сравниваете: согласились бы вы с этими командами?
3. Включаете публикацию только для одного безрискового действия на одной теплице.
4. Держите ручной выключатель питания реле (физический) — старый добрый рубильник побеждает любой скрипт.

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

Когда считать пилот успешным

Не по числу «агентов» и не по красивой схеме на бумаге. Смотрите на простые признаки:

• вы не отключили бот от раздражения;
• хотя бы раз critical-правило спасло ситуацию без LLM (перегрев, протечка);
• хотя бы раз propose по камере привёл к раннему осмотру с пользой;
• рискованные действия стабильно требуют confirm, и вы это чувствуете как норму, а не как помеху;
• падение одного сервиса не роняет полив по порогам.

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

Связь со всей серией

Коротко, как куски складываются:

• глаза — ESP32-CAM + модель на Pi / контур мониторинга;
• слова — LLM;
• осторожный выход в интернет — мост;
• общая дисциплина — этот оркестратор на MQTT.

Полный график и ссылки — снова в плане статей.

Главное

Мини-агенты на ферме — это не «ИИ сам всё полил». Это разделение труда между скриптами и жёсткая граница: кто предлагает, кто подтверждает, кто имеет право на железо. Аварии — локальными правилами. Болезни и СЗР — человеком. Облако — редким советчиком по сводке, без сырого потока и без прямого доступа к реле. Начните с propose + confirm на одной теплице. Когда доверие к контуру вырастет — расширяйте автономию медленно, как доверяете новому работнику: сначала смотреть, потом делать простые вещи, опасные — только вместе с вами.