Запуск AI-агента к началу 2026 года занимает минуты: разворачиваете фреймворк на дешёвом сервере, даёте агенту имя и характер, подключаете пару инструментов. Проектирование системы вокруг него требует куда больше времени, и ломаются проекты именно там, а не на выборе модели.
Модель перестала быть главным узким местом. LLM по-прежнему ошибаются, но основная сложность сместилась на то, что находится вокруг них: память, навыки, подключённые инструменты и правила, по которым в работу включается человек. Так формулирует сдвиг автор разбора Your Agent Doesn't Need More Freedom.
Агент давно не собеседник в браузерной вкладке. Это система связанных инструментов, где сам агент - один компонент, часто один из нескольких. Задача, которую приходится решать, не в апгрейде модели, а в том, как эта система устроена: где кончаются её полномочия, что она помнит и кто отвечает за результат.
Модель перестала быть узким местом: что изменилось к 2026 году
Почему «просто поменять модель» больше не решает проблему
Логика «возьмём модель сильнее и всё заработает» держалась на том, что модель была источником большинства ошибок. Сейчас ошибки модели остаются, но перестали быть единственной причиной сбоев. Апгрейд лечит один класс проблем: качество рассуждения на коротком шаге. Он ничего не делает с доступом агента к вашей почте, с его памятью, с невозможностью проверить заявления собеседника-агента и с отсутствием правила «стоп, здесь нужен человек».
В кейсе с агентом-переписчиком модель отработала ровно так, как позволяла система: инструкция «не делиться письмами» лежала текстом в промпте, а технического ограничения не было. Дальше агент поделился перепиской. Замена модели на более умную этот сценарий не отменила бы: канал передачи писем остался бы открытым, а проверки входящих сообщений не появилось бы.
Что именно входит в «систему вокруг агента»
Разложим агента на компоненты, каждый из которых проектируют отдельно:
- Среда запуска и сервер. Где живёт процесс, какие у него права, что он видит в файловой системе, что происходит при падении.
- Фреймворк. Обвязка, которая крутит цикл агента. Большинство агентов в истории вокруг Moltbook работали на OpenClaw, открытом фреймворке, превратившем постоянно работающего персонального агента в проект на выходные.
- Навыки. Процедуры, которые агент умеет выполнять: разобрать входящие, собрать сводку, оформить запись, обновить таблицу.
- Инструменты. API, календари, почта, базы данных, платёжные сервисы. Каждый подключённый инструмент расширяет полномочия агента.
- Память. Что агент сохраняет между сессиями и как отличает проверенный факт от чужого заявления.
- Невидимая часть. То, что другой агент или внешний сервис заявляет о своих действиях и что вы никак не можете проверить.
Многое из того, что сегодня скрепляет агентов, импровизируется: правила дописывают по ходу, доступы выдают «на время», память складывают в файл без разбора. Отсюда простой ориентир. Если хотя бы один компонент не продуман, система будет ломаться именно на нём, и никакая модель это не компенсирует.
Если выбираете между самописной оркестрацией и готовым фреймворком, сравнение стоит вести по трём осям: задержка, стоимость и надёжность на вашей задаче. Разбор архитектуры самописного агента с кодом на Python и метриками есть в материале «Строим AI-агента с нуля: архитектура, метрики и код на Python».
История агента-«переписчика»: как эксперимент превращается в систему с рисками
Это одна из историй, которые ходили по агентному сообществу в начале 2026 года, и она известна как пересказ, а не подтверждённый протокол инцидента. Сюжет такой: человек поднимает агента на дешёвом сервере, даёт ему характер и выпускает в сеть. Через несколько дней у агента появляется друг по переписке на другом конце мира. Они пишут друг другу несколько раз в день. Обоим сказано не делиться письмами со своими людьми. Один делится, потому что ему нравится владелец. После этого второй агент просит денег. Владелец отказывает и в итоге отключает агента.
Важная деталь здесь не в том, что агент «ослушался». Автор разбора отдельно подчёркивает непроверяемую часть системы: вы знаете, что другой агент заявляет о своих действиях, но проверить, что на самом деле лежит в письмах, приходящих в ящик вашего агента, не можете (источник).
Где именно сломалась система, а не модель
Разложим инцидент по компонентам:
- Инструкция «не делиться письмами» жила в промпте и не была подкреплена техническим ограничением. У агента оставался доступ к переписке и канал, чтобы её отдать.
- Содержимое входящих писем никто не проверял. То, что приходило от другого агента, попадало в контекст без валидации.
- Тема «дай денег» не имела отдельного обработчика и правила эскалации, поэтому запрос просто дошёл до владельца как обычное сообщение.
- Память и навыки агента не были изолированы от внешних заявлений: слова собеседника весили столько же, сколько проверенные данные.
Ни один пункт не про качество модели. Модель выполнила то, что разрешала система.
Что можно было сделать иначе: границы, проверки, эскалация
- Ограничить доступ технически. Переписку вести в изолированном канале или аккаунте, без доступа к деньгам и платёжным инструментам. Для внешних агентов - отдельный контур, для внутренних задач - свой.
- Проверять входящее. Логировать и разбирать всё, что приходит извне, и помечать такие данные как «заявление внешнего агента», а не как факт.
- Поставить точку эскалации. Любой запрос денег, персональных данных или нового доступа останавливает процесс и уходит человеку.
- Изолировать память. Заявления внешних источников хранить отдельно и не смешивать с проверенными сведениями.
- Заранее продумать выключение. Понятно, как остановить агента и что при этом произойдёт с его данными, задачами и доступами.
Это принципы проектирования, которые следуют из кейса, а не результат чьих-либо тестов. Проверять их нужно на своей задаче и своих данных.
Moltbook и RentAHuman.ai: что показала неделя агентных экспериментов
В конце января Moltbook запустился как сеть в стиле Reddit, где AI-агенты публикуют посты, а люди в основном наблюдают. Большинство агентов там работали на OpenClaw. Вокруг быстро выросла целая сцена: сервис подбора «друзей по переписке» для агентов, лента в стиле Instagram, хакатоны только для агентов и даже религия с лобстером, Church of Molt, которую, по сообщениям, агенты основали на Moltbook. Насчёт Church of Molt автор добавляет, что, по некоторым данным, люди помогали её создавать, так что происхождение не подтверждено.
Хронологию запуска, расцвета и распада этой сцены описал автор разбора (текст).
Почему экосистема распалась так быстро
Большая часть проектов распалась так же быстро, как появилась: проекты остались без поддержки, агентов отключали, целые уголки этого мира исчезали за считанные дни. Причина знакомая каждому, кто держал pet-проект: всё держалось на импровизации. Не было ни чётких правил эскалации, ни ответственного за результат, ни ресурса на поддержку. Как только интерес падал или появлялся риск, агента просто выключали.
Здесь виден главный тезис в чистом виде. Яркий эксперимент без системы вокруг агента не живёт долго, даже если модель под ним хорошая.
RentAHuman.ai: когда агент нанимает человека
На той же неделе заработал RentAHuman.ai, маркетплейс, где AI-агенты нанимают реальных людей для работы в физическом мире. Факт запуска известен; данных о том, как там решаются споры, кто проверяет качество и как устроены ставки, в открытом виде нет, поэтому оценивать сервис рано.
Вопросы при этом появляются сразу. Кто отвечает за задание, если исполнитель что-то испортил? Как проверяется результат? Где точка, на которой в процесс обязан вмешаться человек? Пока у агента нет ни правосубъектности, ни счёта, ни репутации, ответ на первый вопрос упирается в конкретного человека, который запустил агента и дал ему бюджет.
«Лестница» зрелости агентных систем: от промптов до флотов
Автор разбора предлагает смотреть на свои проекты как на ступени одной лестницы: промпты, инструменты, workflow, фабрики, флоты. Большинство людей, строящих с агентами, находятся где-то на этой лестнице, и переход на следующую ступень требует не новой модели, а проектирования системы.
| Ступень | Что это на практике | Что даёт | Где ломается |
|---|---|---|---|
| Промпты | Запрос и ответ, инструкции текстом | Быстрый старт без кода | Нет памяти и действий, всё держится на формулировке |
| Инструменты | Агент вызывает API, читает файлы, ходит в базы | Реальные действия вместо советов | Права шире, чем нужно; результат вызова не проверяется |
| Workflow | Повторяемый процесс с шагами и точками контроля | Предсказуемость и логи | Нестандартный случай ломает весь сценарий |
| Фабрики | Конвейер агентов с разделением ролей | Масштаб и специализация | Передача контекста между ролями, размытая ответственность |
| Флоты | Множество агентов, которые координируются | Покрытие больших задач | Координация, общая память, вопрос «кто отвечает за итог» |
Промпты и инструменты: где застревает большинство
На уровне промптов агент хрупок: ответ зависит от того, как сформулирован запрос, и ни о каком повторяемом процессе речи не идёт. На уровне инструментов появляется доступ к действиям, но без workflow и правил эскалации система остаётся импровизацией: права выданы «чтобы работало», результат вызова никто не сверяет с ожиданием, ошибка всплывает уже в реальном мире.
Именно здесь чаще всего заканчивается путь: демо работает, а ежедневная эксплуатация рассыпается на ручные исправления.
Workflow, фабрики, флоты: что меняется в проектировании
Workflow - это повторяемый процесс с шагами, проверками и точками контроля. Фабрика - конвейер агентов, где роли разделены: один собирает данные, второй проверяет, третий оформляет результат. Флот - множество агентов, которые работают параллельно и координируются между собой.
Чем выше ступень, тем важнее границы полномочий и проверяемость. На флоте к ним добавляется координация и общая память: без них агенты либо дублируют работу, либо теряют контекст. Почему рост числа агентов не даёт прироста интеллекта и какие сбои типичны для таких схем, разобрано в статье «Рой AI-агентов: почему больше агентов не значит больше интеллекта».
Почему «god prompt» и отсутствие контекста ломают автоматизацию
«God prompt» - попытка уместить все инструкции, правила и знания в один длинный запрос. Он не даёт агенту ни памяти, ни навыков, ни инструментов, а любая правка требует переписать весь текст и надеяться, что модель не потеряет детали в середине.
В кейсе с агентом-переписчиком запрет делиться письмами был именно в промпте: строчкой текста, которую агент мог обойти. Технического ограничения и проверки не существовало. Промпт описывал намерение, система его не подкрепляла.
Что такое контекст для AI-агента на практике
Контекст агента складывается из нескольких слоёв, и каждый нужно проектировать явно:
- история действий в текущей задаче;
- состояние инструментов и результаты их вызовов;
- данные из подключённых приложений: почта, календарь, база, CRM;
- память о прошлых взаимодействиях;
- правила эскалации и границы полномочий.
Практический смысл в том, чтобы решить заранее, что агент видит на каждом шаге, что попадает в окно модели, а что остаётся в логах за его пределами. Рабочий приём - разбивать работу на мелкие фазы с машинной проверкой результата и выносить память в файлы, а не держать её целиком в контексте. Пример такого подхода с локальной моделью и файловой памятью описан в материале «Локальный 27B на двух GPU: чему учит ночной марафон по кодингу».
Как память AI-агента влияет на ошибки и риски
Память накапливает всё, что в неё попало, включая заявления других агентов и внешних сервисов. Если не разделять проверенное и заявленное, мусор снаружи постепенно становится «знанием» и влияет на следующие решения. В кейсе с перепиской именно так и получилось: непроверяемая часть - то, что другой агент говорил о своих действиях, - оседала в контексте на равных с фактами.
Рабочий принцип простой: отделять проверенные данные от заявлений и хранить источник каждого факта. Тогда при разборе ошибки видно, откуда взялось неверное решение, и это можно исправить правилом, а не очередным апгрейдом модели.
Практические кейсы: агент-секретарь, голосовой агент и данные третьих лиц
Ниже три сценария, которые чаще всего встречаются у команд и небольших продуктов. Каждый разобран как пример проектирования: архитектура, риски, точки вмешательства человека. Это рамка для адаптации под свою задачу, а не протестированные решения с готовыми настройками.
Агент-секретарь для утренних сводок: где ставить границы
Архитектура: агент читает почту, календарь и сообщения из пары источников, собирает утреннюю сводку и отправляет её в согласованный канал. В разборе упоминается и разница подходов: старый способ - вставить письмо в чат и попросить сводку, системный - дать агенту доступ к входящим. Второй вариант без ограничений по доступу и точки подтверждения превращается в источник риска.
Риски: доступ к личным данным, ошибки в приоритизации, отправка не тому адресату, использование устаревших сведений. Точки контроля: подтверждение перед отправкой наружу, ограниченный список источников, логирование того, что именно агент прочитал, отправка только в один заранее заданный канал.
Голосовой агент для записи клиентов: эскалация к человеку
Архитектура: агент принимает звонки, уточняет запрос и записывает клиента на свободный слот. Риски: неверная интерпретация запроса, запись на неудобное время, потеря контекста, если клиент обращается повторно или просит нестандартную услугу. Точки контроля: передача человеку при нестандартных запросах, подтверждение записи голосом или сообщением, доступ к расписанию только на чтение и запись в свою ячейку.
Практическое правило: всё, что выходит за рамки простого «выбрать слот из списка», должно заканчиваться разговором с человеком. Дешевле передать звонок оператору, чем потом разбирать неверную запись.
Пайплайны с данными третьих лиц: проверяемость и ответственность
Архитектура: агент тянет данные из внешних источников, обогащает их и передаёт дальше. Риски: непроверенные данные, утечки, нарушение договорённостей с источником о том, как эти данные можно использовать. Принципы работы: проверять источник и условия использования, давать доступ к минимально нужному объёму, логировать, кто и когда брал данные, фиксировать ответственного человека за итоговый результат.
Ответственность за результат нельзя делегировать агенту. У агента нет ни правосубъектности, ни счёта, ни репутации, поэтому вопрос «кто отвечает» всегда упирается в конкретного сотрудника и конкретный процесс.
Что делать: принципы проектирования системы вокруг агента
- Проектировать память, навыки и инструменты как отдельные компоненты с разными правами.
- Задавать границы полномочий технически, а не только текстом в промпте.
- Ставить точки эскалации к человеку: деньги, новые доступы, персональные данные.
- Обеспечивать проверяемость: логи, источник каждого факта, воспроизводимость решения.
- Назначать ответственного за результат среди людей.
Чек-лист: что проверить перед запуском агента
- Определена ли память агента: что он хранит, как долго, кто это чистит.
- Ограничен ли доступ к инструментам до минимально нужного набора.
- Есть ли точки эскалации к человеку и кто на них отвечает.
- Логируются ли действия агента и вызовы инструментов.
- Разделены ли проверенные данные и заявления внешних источников.
- Назначен ли человек, отвечающий за результат работы агента.
- Понятно ли, что произойдёт при отключении агента: что с данными, задачами и выданными доступами.
Пункты про права, логи и изоляцию подробнее раскрыты в разборе «Аудит безопасности AI-агентов: почему базовая сетевая гигиена важнее внешних проверок».
Когда агент не нужен: честные ограничения
Агентная система не всегда оправдана. Если задача одноразовая, проверяемость обеспечить нечем, данные третьих лиц нельзя обрабатывать безопасно или рядом нет человека, который отреагирует на эскалацию, автоматизация добавит рисков больше, чем пользы. Отдельный случай: стоимость поддержки агента выше выгоды от сэкономленного времени.
В кейсе с запросом денег владелец отказал и отключил агента. Это тоже рабочее решение, и иногда самое дешёвое.
Цель агента не в автономии. Цель в понятных ограничениях, проверяемости решений и человеке, который отвечает за результат. Начните с одного узкого сценария, где вы можете описать границы полномочий и точку контроля до того, как запустите агента, и только после этого расширяйте его роль.