Агенты против демонов

"Агент" и "демон" описывают два структурно различных типа ИИ-процессов:

• Агенты запускаются человеком. Вы даёте агенту prompt, он выполняет задачу, возвращает результат и останавливается. Разработка функциональности, исправление багов, поставка кода.
• Демоны запускаются сами. Они наблюдают за окружением, замечают расхождения и действуют без явных указаний. Поддержание PR'ов готовыми к слиянию, документации - точной, issue - актуальными, а зависимостей - обновлёнными.

Charlie Labs ввели это явное разделение в маркетинге своего продукта с лозунгом "Agents create work. Daemons maintain it." ("Агенты создают работу. Демоны её поддерживают"), но сама концепция шире любого конкретного инструмента.

В чём смысл разделения

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

Управление. Агентам каждый раз нужны указания. Задача номер 500 требует от человека столько же внимания, сколько и задача номер 1. Демонам указания нужны один раз (когда вы пишете файл), а со временем всё меньше, по мере того как они осваивают кодовую базу и правила команды.

Триггер. Агенты ждут prompt'ов. Демоны подписываются на события (новый PR, новый issue, новая ошибка) и просыпаются по ним, иногда в сочетании с периодическим обходом по расписанию.

Единица работы. Агенты выполняют задачи - ограниченные, с чётким критерием готовности. Демоны выполняют роли - непрерывные обязанности без финальной точки.

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

Тезис об операционном долге

Позиция Charlie Labs заключается в том, что главной проблемой после первой волны агентов становятся не сами агенты, а то, что они после себя оставляют. Каждый агент, выпускающий новую функциональность, плодит PR'ы, требующие понятных описаний, тесты, нуждающиеся в поддержке, устаревающую документацию, отстающие зависимости и горы issue. Чем быстрее команды выпускают код с помощью агентов, тем быстрее растёт этот операционный долг. Демоны - ответ на этот вызов: узкие специализированные фоновые процессы, чья единственная цель - этот долг гасить.

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

Декларативные спецификации демонов

Интересное инженерное решение в charlie-daemons - шаблон "демон как Markdown-файл":

---
name: issue-labeler
purpose: Ensures every Linear issue has correct labels from type and touchpoint groups.
watch:
  - when a Linear issue is created
routines:
  - add missing labels to a new Linear issue
deny:
  - remove labels from issues
  - change issue status, priority, assignee, or any field other than labels
schedule: "0 2 * * *"
---

## Policy
- Only add labels. Never remove, replace, or overwrite existing labels.
...

Frontmatter задаёт контракт роли: для чего нужен демон, что его запускает, что ему разрешено и запрещено. Тело документа - это политика: как принимать решения в неоднозначных ситуациях. Важно, что секция deny декларативна и выделена в явный параметр, а не спрятана в системный prompt. Это делает границы возможностей доступными для аудита.

Структура повторяет навыки claude-code и манифесты инструментов MCP: небольшие файлы YAML/Markdown, описывающие права процесса на базе LLM, где сам формат служит частью контракта.

Переносимые паттерны проектирования

Независимо от того, используете ли вы продукт Charlie, ряд архитектурных решений можно обобщить:

Определяйте роль, а не задачу. Формулируйте спецификацию как "за что этот агент отвечает бессрочно", а не "что нужно сделать за этот запуск". Роли можно комбинировать друг с другом, задачи - нет.

Гибридный запуск. Реакция на события плюс обход по расписанию закрывают пробелы от возможных простоев без дублирования обработки. Демон, отслеживающий новые issue, раз в день дополнительно сканирует систему, подхватывая всё, что было пропущено во время сбоев.

Только добавление и ограничение частоты. Пример с issue-labeler может только добавлять метки, но не снимать их, и обрабатывает не более 20 issue за один запуск. Семантика "только добавление" ограничивает радиус поражения при ошибках, а лимиты частоты не дают перегрузить людей уведомлениями.

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

Пересечения с другими подходами

Демоны пересекаются с несколькими известными паттернами, но не сводятся к ним:

• GitHub Actions / боты. Похожая модель запуска (по событиям и расписанию), однако боты обычно ориентированы на задачи, а не на роли, и не принимают контекстных решений. Запуск Dependabot звучит как "вот PR'ы для устаревших зависимостей"; задача демона - "я отвечаю за свежесть зависимостей и сам решаю, как действовать".
• Непрерывный мониторинг. Демоны ведут наблюдение, но в отличие от алертов Prometheus они должны действовать, а не просто присылать уведомления.
• Реактивное программирование и деревья поведения. Та же идея (автономные процессы, реагирующие на события), но демоны работают с семантическими сущностями (PR, issue) через рассуждения LLM, а не через детерминированную логику игрового состояния.

Ограничения концепции

• Бессрочная работа нужна не всегда. Для разовых миграций или точечного поиска багов агент в формате разовой задачи подходит лучше. Демоны предназначены для регулярной гигиены проекта, а не для команды "закрой эти 50 тикетов в Jira до пятницы".
• Слово "демон" отчасти маркетинг. Любой достаточно продуманный cron-скрипт с вызовом LLM подходит под это определение. Практический интерес представляют декларативная спецификация и правила deny, а не сам термин.
• Доверие нужно заслуживать отдельно каждому демону. Даже строго ограниченный демон может ошибиться, если состояние кодовой базы под ним изменится (переименовали метки, переместили репозитории, объявили API устаревшими). Модель "файл как контракт" помогает, но не отменяет необходимость проверки человеком.

Связанные страницы

• charlie-daemons - конкретная реализация, из которой выросла эта концепция
• behavior-tree - другой подход к автономному принятию решений
• mcp-vs-skills - похожий паттерн декларативного описания инструментов для ИИ в файлах
• sandboxing-ai-agents - демонам тоже нужна песочница, возможно, даже сильнее, чем разовым агентам
• agent-memory-decay - актуально для демонов, накапливающих контекст месяцами
• ai-assisted-workflow - паттерн работы с человеком в контуре (human-in-the-loop) для агентов; демоны находятся на противоположном конце спектра автономности