Когда агент пишет систему, а когда агент и есть система

Представьте, что вы купили оркестратор, а потом попросили его написать вам ещё один оркестратор.

Звучит как начало анекдота. Но именно это происходит всякий раз, когда agent harness — систему, которая уже умеет планировать, вызывать инструменты, работать по расписанию, делать повторные попытки и решать, что делать дальше, — используют только для того, чтобы она сгенерировала код другой системы, которая будет делать всё то же самое. Только теперь — внутри приложения, которое придётся поддерживать вам.

Эта статья не о том, какой инструмент лучше. Она о том, что под одним словом «agent harness» скрываются как минимум две принципиально разные архитектурные роли, и что выбор между ними — это, возможно, самый важный архитектурный вопрос следующего года.

Внешне одинаковые

Возьмите Codex, Claude Code, Hermes и OpenClaw. Внешне они выглядят одинаково, потому что все реализуют одну и ту же петлю:

LLM получает задачу > вызывает инструменты > смотрит результат > продолжает работу

Пока мы описываем эти системы на уровне «агент что-то делает с инструментами», между ними нет разницы. Разница появляется, когда мы задаём вопрос, который на поверхностном уровне кажется странным:

Над чем работает этот агент?

Точнее: работает ли агент над системой — или сама система работает внутри агента?

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

Задача: Trend Pipeline

Чтобы не рассуждать абстрактно, возьмём конкретную задачу. Назовём её Trend Pipeline — выявление тем, в инфопространстве, вызывающих растущий интерес аудитории. Она выглядит так:

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

Задача достаточно простая, чтобы её можно было описать в одном абзаце, и достаточно сложная, чтобы внутри неё спрятались обе архитектуры.

Подход первый: агент строит систему

Классический вариант выглядит так:

Человек > Codex / Claude Code > Пишет приложение > Trend Pipeline:- collectors
- scheduler
- workflow- database
- LLM integration
- retries
- notifications
- state machine

Coding-агент получает репозиторий, пишет Python или TypeScript код, создаёт миграции, Docker Compose, тесты, чинит ошибки. Вы как разработчик ставите задачу — «добавь коллектор для RSS», «поправь обработку дат», «напиши тест на дедупликацию» — а агент превращает эти задачи в код.

Через какое-то время возникает самостоятельная программа — Trend Pipeline. Она собирает источники по cron, пишет документы в базу, гоняет пайплайн, уведомляет. И вот здесь происходит важный момент:

Codex или Claude Code могут уйти, они сделали свою работу и больше ненужны.

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

Здесь harness — это строитель системы. Он работает над программными артефактами — кодом, конфигами и т.п. Для Codex и Claude Code это естественная модель, и она отлично работает.

Подход второй: агент и есть система

Теперь соберём тот же Trend Pipeline иначе — на базе Hermes или OpenClaw.

Hermes / Open Claw являются Agentic Control Plane

Здесь нет отдельного «приложения», которое нужно написать. Hermes сам:

запускается по расписанию;
вызывает сборщиков данных;
вызывает LLM;
выбирает следующий шаг;
сохраняет данные в БД;
создаёт субагентов — одного анализировать, другого оценивать;
смотрит на результаты;
делает retry, если что-то упало;
пишет состояние;
вызывает внешние API;
отправляет уведомления;
решает, продолжать ли workflow.

Специализированный код остаётся только там, где он действительно нужен:

yt-dlp collector
RSS parser
SQL
embeddings utility
browser/search
notification tool

Заметьте разницу. Мы не попросили агента написать программу Trend Pipeline. Мы сделали Trend Pipeline из самого агента.

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

Проблема: два runtime там, где хватило бы одного

Теперь вернёмся к сценарию, с которого начали. Что происходит, когда универсальный agent harness используют только как инструмент разработки отдельной agentic-системы?

Agent Runtime №1 Hermes > создаёт > Agent Runtime №2 Trend Pipeline

Возникает неудобный вопрос: если Hermes уже умеет планировать, выполнять инструменты, работать по расписанию, создавать агентов, повторять операции и принимать решения — зачем реализовывать всё это ещё раз внутри приложения?

Это знакомая ситуация из истории инфраструктуры. Когда-то каждая команда писала свой message broker, свой scheduler, свой job queue. Потом выяснилось, что RabbitMQ, Kubernetes и Airflow делают это лучше, и самодельные слои стали техническим долгом. То же самое сейчас происходит с agentic runtime: мы рискуем закопать внутрь каждого приложения второй control plane, который хуже того, что уже запущен снаружи.

Важно не перегнуть. Я не утверждаю, что второй подход всегда лучше. Я утверждаю, что вопрос «а не дублируем ли мы runtime?» нужно задавать до того, как писать код, а не после.

Граница: что детерминировано, а что — нет?

Если агент и есть система, то возникает следующий вопрос: а что тогда вообще остаётся в виде кода и данных, и где проходит граница?

Trend Pipeline содержит вещи двух типов, и их важно не смешивать.

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

источники (sources)
документы (docs)
сигналы (signal)
темы (topics)
состояние тем (topic snapshot)
и т.п.

И вместе с ними — ограничения, история, мгновенные снимки, идемпотентность, уникальность, транзакции, API, схемы, метки времени, происхождение. Всё это — не «память агента». Это база данных и правила, которые её защищают. Скажем это прямо: LLM — плохая замена базе данных. Если агент держит состояние в разговоре, то при перезапуске оно исчезает; если он «помнит» через свободный текст — оно не индексируемо и ненадёжно. Иммутабельные снимки (snapshots), уникальные ключи и транзакции существуют именно потому, что нам нужно точное состояние, а не «примерно помню».

Agentic control plane. А вот эти решения естественно отдать harness:

какой источник исследовать дальше;
какие документы имеют смысл, а какие — шум;
являются ли два сигнала одной темой;
появилась ли новая тенденция;
есть ли смысловой пробел;
стоит ли запускать дополнительное исследование;
достаточно ли доказательств;
стоит ли уведомлять человека;
какую тему передать дальше, в Content Pipeline.

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

Получается знакомая архитектура:

Hermes / OpenClaw CONTROL PLANE  +  Trend Domain DATA PLANE + PostgreSQL

Control plane решает, data plane исполняет и хранит. Эта аналогия пришла из networking, где control plane прокладывает маршруты, а data plane гоняет пакеты. Здесь она работает так же: агент выбирает направление, домен фиксирует факты.

Почему Codex и Claude Code никуда не денутся?

Здесь легко сделать примитивный вывод: «Codex и Claude Code — старые и ограниченные, Hermes и OpenClaw — новые и правильные». Это неверно.

Специализация — это преимущество, а не недостаток. Coding harness знает про то, о чём универсальный personal agent не знает и не должен знать:

repository, git, diff, tests, build, compiler, dependencies, IDE, code review, worktree, source tree

Поэтому для задачи «переделай authentication module, добавь миграцию и не сломай тесты» Codex или Claude Code могут быть значительно естественнее универсального личного агента. У них уже есть весь контекст репозитория, вся цепочка сборки, все проверки — и всё это натренировано годами.

Более того, зрелая архитектура, скорее всего, выглядит так, что эти два мира не конкурируют, а складываются:

Hermes \ OpenClaw — понимает что требуется изменить в программном коде, как General Agent Harness.
- Codex \ Cloud code — понимает как наилучшим образом внести изменения, проверить и выкатить в продакшен.

Будущее, возможно, — не в выборе одного harness, а в иерархии harness, специализированных под разные типы деятельности. Генеральный агент понимает, что нужно сделать; специализированный — как сделать это лучше всего.

Второй пример: Content Pipeline

Полезно взглянуть на ещё один процесс — Content Pipeline, через который, собственно, пишется и статья, после того как понятна трендовая тематика выявленная Trend Pipeline.

IDEA
↓
BRIEF_READY
↓
RESEARCHED
↓
OUTLINED
↓
DRAFTED
↓
PUBLISHED

Классически это сделали бы как отдельное AI-приложение с собственным оркестратором, базой, веб-интерфейсом. Но посмотрите на эти стадии внимательнее: это не обязательно «приложение». Это могут быть:

skills — описание того, как выполнять каждую стадию;
инструкции — правила, что должно получиться на выходе;
файлы с текстами в разных стадиях — brief.md, research.md, outline.md, draft.md;
состояния — где сейчас находится процесс и что разрешено дальше.

А исследование, написание и публикацию выполняет сам Hermes.

Тогда Content Pipeline — это не отдельная программа с собственным runtime. Это набор правил и артефактов предметной области, исполняемых общим agent runtime. Agent-native рабочий процесс.

На его фоне разница с отдельным Trend Pipeline-приложением становится особенно наглядной: один и тот же паттерн — «собрать, понять, решить, произвести» — можно реализовать как приложение, а можно как поведение агента поверх данных.

Вывод шире, чем про продукты

Речь на самом деле не про Codex или Hermes. Речь про смену архитектурного мышления. Раньше автоматизация выглядела так:

идея
↓
разработчик
↓
код
↓
программа
↓
процесс

С agent runtime появляется другой вариант:

идея
↓
описание процесса
↓
skills + tools + domain state
↓
agent runtime
↓
процесс

Часть того, что раньше обязательно становилось программой, теперь может стать поведением агента. И из этого следует провокационный вопрос:

А всякий ли agentic workflow сегодня вообще нужно программировать?

И следующий, ещё неудобнее:

Не пишем ли мы иногда приложение только потому, что последние двадцать лет привыкли любую автоматизацию превращать в приложение?

Где обычное приложение всё-таки лучше?

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

Если у вас высокая нагрузка, строгая latency, критическая воспроизводимость, сложная транзакционность, regulatory requirements, требование строго детерминированного исполнения, тысячи параллельных операций, жёсткие SLA или необходимость масштабировать компоненты независимо — вам нужна обычная программа. LLM в контуре управления не гарантирует ни задержку, ни повторяемость, ни транзакционную целостность, и полагаться на него там, где это критично, — ошибка.

Можно предложить грубую, но полезную эвристику:

Если проблема в основном: «посчитать / сохранить / передать» → классическое приложение
Если проблема в основном: «понять / выбрать / исследовать / решить, что делать дальше» → agent harness
Если присутствует и то, и другое → гибридная архитектура

Это не строгий закон, а способ быстро проверить, куда вы закладываете сложность. В hybrid-архитектуре детерминированный домен остаётся приложением, а суждения о направлении — агентом. Собственно, ровно та самая схема control plane / data plane, с которой мы начали.

Итого

Мы привыкли обсуждать, какая LLM лучше пишет код. Следующий архитектурный вопрос гораздо интереснее:

Какую часть программного обеспечения вообще больше не нужно писать, если у нас уже есть agent runtime?

Когда-то мы перестали писать собственные базы данных, потом — собственные очереди и оркестраторы. Возможно, теперь настала очередь собственных agentic runtime’ов.

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

И если ответа пока нет — это не плохо. Это просто значит, что мы наконец задаём правильный вопрос.