Автономность начинается с границ
Бизнесу редко нужен агент, который «может всё». Ему нужен управляемый исполнитель для конкретного процесса: разобрать входящие обращения, проверить документы, обновить CRM, собрать отчёт или подготовить публикацию. Чем шире полномочия одного промпта, тем сложнее понять, почему система ошиблась и какое действие надо отменить.
В проектах 4BOS мы рассматриваем агента как программный контур с явными входами, состояниями и разрешёнными действиями. Языковая модель отвечает за интерпретацию и выбор следующего шага. Доступ к данным, записи и внешним каналам остаётся у обычного кода, который проверяет аргументы и фиксирует результат. Такая граница превращает удачный демо-сценарий в систему, которую можно сопровождать.
Из каких слоёв состоит рабочая система
Практический стек удобно делить на пять слоёв.
- Приём событий. Webhook, сообщение, письмо или изменение записи приводятся к единому формату. На этом этапе проверяются подпись источника, обязательные поля и ключ идемпотентности.
- Оркестрация. Оркестратор определяет тип задачи, выбирает исполнителя и задаёт критерий готовности. Он не должен сам выполнять все операции.
- Состояние. Очередь и журнал хранят статус каждого шага, исходные идентификаторы, контрольные суммы и уже выполненные действия.
- Инструменты. CRM, база, файловое хранилище и API подключаются через узкие типизированные функции. Для чтения и записи используются разные разрешения.
- Проверка результата. Независимый контур сверяет не слова агента, а resulting state: строку в базе, содержимое файла, HTTP-ответ или идентификатор внешней публикации.
Эта схема не требует сложной платформы на старте. Для первого процесса достаточно очереди задач, PostgreSQL или SQLite, нескольких адаптеров и одного воркера. Важно, чтобы границы были заложены до подключения дополнительных моделей и каналов.
Паттерн Orchestrator-Workers
Оркестратор получает бизнес-цель и раскладывает её на короткие задания. Например, обработка заявки может состоять из проверки дубля, извлечения контакта, классификации запроса, создания лида и уведомления менеджера. Каждый воркер получает только нужный контекст и минимальный набор инструментов.
Такое разделение даёт три преимущества. Во-первых, ошибку проще локализовать: видно, на каком шаге расходятся вход и результат. Во-вторых, отдельного воркера можно заменить без переписывания всего процесса. В-третьих, опасные права не приходится выдавать каждому участнику. Аналитик читает данные, CRM-воркер меняет карточку, а издатель получает право на публикацию только после QA.
Оркестратор не должен бесконечно пересобирать план. Для каждого задания задаются максимальное число попыток, дедлайн и условие no-progress. Если две итерации не меняют проверяемый результат, задача останавливается и поднимается оператору вместе с последним доказанным состоянием.
Состояние важнее истории диалога
Контекст модели удобен для рассуждения, но непригоден как единственный журнал процесса. После рестарта или переключения провайдера часть истории может исчезнуть. Поэтому рабочее состояние хранится отдельно.
Минимальная запись включает task_id, тип операции, входной идентификатор, текущий этап, число попыток и хэш результата. Для действия записи нужен ключ идемпотентности. Повторный запуск с тем же ключом обязан вернуть существующий receipt, а не создать второй лид, счёт или пост.
Долгая память тоже отделяется от очереди. Инструкции и справочные материалы можно искать через полнотекстовый или векторный индекс, но найденный фрагмент остаётся источником, а не командой. Перед действием агент сверяет актуальное состояние в CRM или базе. Это защищает от старых регламентов и случайных инструкций внутри документов.
Инструменты и контроль записи
Каждый инструмент описывает входные поля, допустимые значения и ожидаемый ответ. Функция create_lead не должна принимать произвольный JSON. Она получает имя, телефон, источник и ключ идемпотентности, проверяет формат, выполняет запись и возвращает ID созданной сущности.
Чтение можно разрешать шире, если оно не раскрывает чувствительные данные. Запись проходит через отдельный gate. Перед ней система формирует evidence pack: какие данные использованы, что проверено, какой объект будет изменён и как его восстановить. Для финансов, договоров и массовых отправок добавляется подтверждение человека.
После записи выполняется read-back. Успешный HTTP 200 от API ещё не доказывает, что нужная карточка появилась с правильными полями. Воркер повторно читает объект и сравнивает бизнес-значимые значения. Только затем шаг получает PASS.
Откат и Self-Healing
Self-Healing не означает бесконечный автоматический повтор. Полезное самовосстановление начинается с классификации сбоя.
- Временная ошибка сети допускает повтор с увеличивающейся задержкой.
- Ошибка валидации возвращает задачу на исправление входных данных.
- Несовпадение хэша или неожиданное содержимое блокирует запись.
- Частично выполненная операция запускает проверенный сценарий восстановления.
Для файловой публикации до замены страницы сохраняется резервная копия и её SHA-256. Для базы используется транзакция или компенсирующая операция. Для внешнего канала хранится message_id, чтобы повтор не отправил дубль. Журнал отката создаётся до мутации, а после восстановления система снова читает целевой объект и подтверждает исходный хэш.
Watchdog следит за зависшими задачами, но не подменяет бизнес-логику. Он может вернуть потерянную задачу в очередь, освободить просроченную блокировку или переключить модель. Он не должен объявлять результат готовым только потому, что процесс завершился без исключения.
Что измерять в эксплуатации
Количество вызовов модели почти ничего не говорит о пользе автоматизации. Для процесса нужны прикладные метрики:
- доля задач, дошедших до проверенного результата;
- число ручных исправлений после PASS;
- частота дублей и блокировок идемпотентности;
- время от события до результата;
- стоимость одной успешно завершённой операции;
- доля откатов и причины их запуска.
Отдельно полезно видеть этапы очереди. Если большинство задач застревает на валидации источника, смена модели не решит проблему. Если растёт время внешнего API, нужен другой retry-профиль. Если QA часто отклоняет один тип результата, надо менять контракт инструмента или инструкцию конкретного воркера.
Порядок внедрения без большого риска
Первым выбирают процесс с понятным входом и проверяемым выходом. Хорошие кандидаты: классификация обращений, подготовка черновика ответа, сверка полей, перенос данных между двумя системами. Процессы с оплатами и необратимыми внешними действиями лучше подключать после того, как очередь, журнал и read-back уже проверены на простых задачах.
Запуск проходит в четыре этапа. Сначала агент работает в shadow-режиме и только предлагает действие. Затем оператор подтверждает каждый шаг записи. После накопления статистики автоматизируются операции с низким риском. Последними включаются внешние отправки, для которых уже есть дедупликация, откат и наблюдение.
Команда 4BOS при проектировании начинает не с выбора модели, а с карты процесса: источники, владельцы данных, точки записи, допустимые ошибки и критерий готовности. Модель в этой схеме остаётся заменяемым компонентом. Ценность создаёт связка из узких ролей, проверяемого состояния и безопасных инструментов.
Чек-лист перед запуском
Перед production-запуском проверьте:
- У задачи есть однозначный вход и машинно проверяемый результат.
- Оркестратор и воркеры имеют разные обязанности и наборы прав.
- Все операции записи используют ключ идемпотентности.
- PASS выдаётся после read-back целевой системы.
- Журнал не содержит секретов, но хранит ID, хэши и receipts.
- Для каждой мутации существует проверенный откат.
- Повторы ограничены по времени и числу попыток.
- Оператор получает один понятный blocker, если система не может продолжать безопасно.
Архитектура автономных AI-агентов — это дисциплина исполнения, а не размер промпта. Когда состояние, права и доказательства вынесены в код, агент может брать больше рутинной работы без потери управляемости.