← Университет

Основы агентов: LLM-агент с нуля — модель + инструменты + цикл

Аналитический документ для курса Лучиана. Тема: что такое LLM-агент, tool use, чем агент отличается от чат-бота, анатомия одного агента.

1. Зачем вообще формальное определение

В индустрии царит терминологическая инфляция: DevRev отмечает, что из тысяч продуктов, называющих себя «AI-агент», архитектурно агентными по строгим критериям являются лишь около 130 (fundamentals-agents.md). Anthropic в собственном блоге признаётся, что писала программную статью «Building Effective Agents» именно потому, что «мы заходим на встречи с клиентами, и все называют одну и ту же вещь разными терминами» (Barry, applied AI team, транскрипт LP5OCa20Zpg.txt). Для Лучиана это не абстрактная лингвистика: он уже построил систему из 16+ докер-сервисов, где есть код, который называется orchestrator.mjs, но выключен, есть память (memory-bank), есть циклы генерации с ретраями — вопрос в том, что из этого уже «агент», а что — просто последовательный скрипт (workflow), который выглядит умным, потому что вызывает LLM несколько раз подряд.

Официальное определение Anthropic: «AI-агент — это система, где LLM динамически направляет свои собственные процессы и использование инструментов, сохраняя контроль над тем, как выполняет задачи». Ключевое слово — «динамически». Модель сама решает, сколько шагов сделать и в каком порядке, а не идёт по зашитому в код маршруту.

2. Три уровня использования LLM (не два)

Anthropic различает не «агент vs. workflow», а три слоя, и путаница обычно возникает из-за того, что люди перепрыгивают через средний:

  1. Augmented LLM — модель с доступом к поиску/памяти/одному инструменту, но без цикла. Это, например, единичный вызов claude -p в стадии stage_visual_rules фабрики Лучиана — модель один раз пишет режиссуру для чанка сцен и не возвращается к этому решению.
  2. Workflow — код заранее фиксирует последовательность LLM-вызовов, каждый со своим узким промптом; между ними — программные «врата» (gate) для проверки. Это ровно то, чем сейчас является конвейер ⓪→⑨ на заводе Лучиана: stage_script → stage_script_qc → stage_voice → stage_visual_rules → stage_prompts → stage_images → stage_timeline → stage_render → stage_capcut — жёсткая, предсказуемая цепочка с известным числом шагов, обёрнутая двумя человеческими гейтами (EDIT_PENDING, APPROVAL_PENDING). Это НЕ агент в строгом смысле — это отлично спроектированный workflow, и в этом нет ничего плохого: Anthropic прямо пишет, что workflows предпочтительны, когда задача хорошо определена и повторяема, потому что дают предсказуемость и низкую стоимость ошибки.
  3. Agent — LLM сама решает, сколько раз пройти цикл, какие инструменты вызвать и когда остановиться. Пример из его же экосистемы — cracker (Щелкунчик): сервис реверс-инжинирит референс-видео с «трёхзначным QC-вердиктом, win-demotion, exploration 20%» — это уже ближе к настоящему агентному циклу с самокоррекцией, а не к линейному конвейеру.

Практический вывод для его цели №1 (строитель приложений: план→код→критика→тест→визуальная проверка→доработка ночью) — это по определению агент, а не workflow, потому что заранее неизвестно, сколько итераций критики потребуется до прохождения тестов. Именно здесь нужен настоящий agentic loop, а не жёсткая цепочка стадий как в photo/omni-генераторах.

3. Anatomy of the loop: из чего состоит один ход агента

ReAct-фреймворк (Reasoning + Acting), на который прямо или косвенно опирается большинство систем, формализует итерацию как Thought → Action → Observation → Thought → .... Лилиан Вэнг (Lilian Weng) в классическом посте про автономных агентов подчёркивает необходимость самокритики: «агент может заниматься самокритикой и самоанализом своих прошлых действий, учиться на ошибках и совершенствоваться». Один проход этого кольца называют turn (ход). На каждом ходу агент:

  1. анализирует текущее состояние (что уже сделано, что вернули инструменты);
  2. выбирает один или несколько инструментов;
  3. получает результат выполнения (observation);
  4. решает: закончена задача или нужен ещё ход.

Формально полный agent loop раскладывается на 6 этапов: инициализация → рассуждение и планирование → выбор инструментов → получение обратной связи из окружения → оценка прогресса → итерация/завершение.

Критически важная деталь, которую часто упускают: обратная связь должна приходить из окружения, а не быть самовнушением модели. Anthropic на вопрос «что дальше в ограничивающих факторах coding-агентов» отвечает прямо: «модель может конвергировать к правильному ответу, только если получает сигнал каждый раз, когда проходит цикл» (тесты проходят/не проходят); «без механизма обратной связи вы не добавляете сигнал — вы просто добавляете шум» (Eric, LP5OCa20Zpg.txt). Это прямо касается фабрики Лучиана: стадия ⑨ LEARNING сейчас холостая — метрики с YouTube не текут обратно в memory-bank автоматически, оркестратор выключен. Формально это значит, что даже там, где есть цикл (например, петля обучения thumbnail-studio R1/R2), система не замкнута до полноценного агентного самообучения — обратная связь из реального окружения (просмотры, retention) не долетает до следующего хода.

4. Tool use / function calling: как модель превращается в «работника»

Function calling (tool calling) — механизм, которым LLM запрашивает выполнение конкретной функции вместо генерации свободного текста. Именно это превращает LLM из генератора текста в «функционального цифрового работника». Стандартный 5-шаговый цикл:

  1. приложение отправляет запрос модели вместе с JSON-схемами доступных инструментов;
  2. модель анализирует задачу и генерирует вызов инструмента с параметрами;
  3. приложение выполняет функцию на своей стороне (не модель!);
  4. результат возвращается модели;
  5. модель либо даёт финальный ответ, либо вызывает следующий инструмент.

Anthropic формулирует пять принципов дизайна хороших инструментов (fundamentals-agents.md): стратегический выбор (не оборачивать каждый API-эндпоинт, консолидировать связанные операции), чёткие namespace-префиксы, «информация с высоким сигналом» вместо криптичных UUID, оптимизация по токенам (пагинация, фильтрация, обрезка по умолчанию), и подробные описания — «пишите так, будто объясняете новому члену команды». Один из инженеров Anthropic честно признаётся: «люди тратят кучу сил на красивые промпты, а инструменты, которые дают модели, — голые, без документации, с параметрами названными A и B... инженер бы не смог работать с такой функцией — как вы ждёте, что Клод сможет?» (LP5OCa20Zpg.txt). Это прямое замечание к архитектуре завода: если Лучиан хочет строить настоящих агентов поверх channel-hq/resource-governor, каждый внутренний API этих сервисов должен документироваться как публичный tool-контракт для модели, а не просто как REST-эндпоинт для людей.

Второй слой — «tool calling 2.0», о котором говорится в разборе новых возможностей Anthropic (3wglqgskzjQ.txt): классический tool calling требует, чтобы модель регенерировала все промежуточные параметры сама (например, чтобы прочитать 10 писем, она должна 10 раз вызвать read_email и каждый раз пропустить результат через себя) — это дорого по токенам и недетерминированно. Новый подход — позволить агенту писать код, который сам оркестрирует несколько вызовов инструментов (Anthropic Skills / «code execution as the universal interface»). Это прямо резонирует с болью Лучиана из его профиля: раздувание контекста до ~1M токенов на многошаговых задачах. Механический код (grep, скрипты, цикл for email in emails) не требует, чтобы LLM «видела» каждый промежуточный результат — LLM пишет программу один раз, программа выполняется детерминированно. Его собственное правило «скрипт вместо ИИ где можно» — это, по сути, независимо выведенная версия того же принципа, который Anthropic формализовала как架构ный сдвиг индустрии.

5. Skills vs Agents: важный поворот 2026 года

В докладе Anthropic «Don't Build Agents, Build Skills Instead» (CEvIs9y1uog.txt) звучит тезис, прямо применимый к практике Лучиана: «агенты сегодня во многом похожи на Махеша — блестящие, но без экспертизы» (в противопоставление Барри — опытному налоговому специалисту). Agent skills определяются как «организованные коллекции файлов, упаковывающие композируемое процедурное знание для агентов» — по сути, просто папки с инструкциями, которые можно версионировать в git. Ключевая мысль доклада: «код — это не просто один из юзкейсов, а универсальный интерфейс к цифровому миру»; core scaffolding агента может быть таким же тонким, как bash + файловая система, а вся специализация переносится в skills. Это буквально формализует правило Лучиана «повторил дважды → оформи скиллом» — Anthropic превратила именно эту эвристику в официальную архитектуру. Практический вывод: строитель приложений и контент-фабрика Лучиана не должны обрастать десятками узкоспециализированных «агентов» — один универсальный код-агент (в духе Claude Code) + библиотека скиллов (faceless-script-skill, capcut-marker-builder и т.п., которые уже частично существуют в его экосистеме навыков) масштабируется дешевле и предсказуемее, чем зоопарк агентов.

6. Агент vs. чат-бот — не про «умнее», а про архитектуру ответственности

Разница не в интеллекте модели, а в контракте с окружением:

Критерий Чат-бот Агент
Режим реактивный, ждёт ввода проактивный, работает автономно
Решения по сценарию/правилам по цепочке рассуждений с учётом обратной связи
Действие советует выполняет (пишет файл, публикует видео, тратит бюджет)
Память с нуля в каждом диалоге персистентная история между сессиями
Resolution rate 10-20% (чат-боты/чистый RAG) 40-80%+ (истинные агенты)

Фраза-формула из материалов: «Chatbots respond. AI agents resolve» — чат-бот отвечает, агент решает проблему. Applied к заводу: channel-forge, который превращает нишу в 5 углов и profile.json — это уже не чат-бот (он действует: пишет файлы, вызывает следующий сервис), но пока и не полный агент, потому что число шагов фиксировано кодом, а не решается моделью на лету.

7. Типичные ошибки — и где Лучиан от них уже защищён, а где нет

  1. «Bazooka на муху» — строить агента там, где хватило бы workflow. Anthropic прямо предупреждает: «люди пытаются притащить агентов к любой проблеме, даже когда гораздо более простая система сработала бы» (LP5OCa20Zpg.txt). Его текущий выбор — workflow-конвейер для генерации видео с двумя гейтами — архитектурно правильный: задача повторяема, стоимость ошибки высокая (публичный аплоад), значит нужна предсказуемость, а не автономность модели на каждом шаге.
  2. Consumer-агенты переоценены — пример из интервью: полностью автоматическое бронирование отпуска почти так же трудозатратно описать агенту (все предпочтения), как сделать самому, а цена ошибки высока и верифицировать сложно (LP5OCa20Zpg.txt, Eric: «for a lot of consumer tasks it's almost as much work to fully specify preferences as to just do it yourself»). Урок для «разведчика возможностей» (opportunity scout) — не пытаться сразу дать ему право тратить деньги; сначала предложения с расчётом, человек решает.
  3. Нет верифицируемого сигнала → нет сходимости. Coding-агенты работают лучше других именно потому, что тесты проходят/не проходят — детерминированный сигнал. У Лучиана этот принцип уже частично реализован (QC-гейты в стадии ④, деterministic + семантический QC для обложек), но стадия ⑨ (learning) без реальных метрик — это как раз пример «цикла без сигнала», который выглядит как обучение, но им не является.
  4. Голые инструменты без документации — если он хочет открыть внутренние API channel-hq/memory-bank/resource-governor для будущего оркестратора-агента, они должны получить нормальные tool-схемы (имя, описание, параметры со смыслом) — иначе агент будет галлюцинировать вызовы, как предсказывает материал про частые ошибки инструментов.
  5. Игнорирование стоимости ошибки при выборе автономности. Sweet spot для агента: «задача ценная и сложная, но стоимость ошибки/мониторинга относительно низкая» (Eric). Публикация на YouTube — задача с высокой стоимостью ошибки (репутация канала, демонетизация), поэтому человеческий гейт APPROVAL_PENDING логичен и должен остаться даже при переходе к «полной ночной автономии» — «красная линия» тратить деньги без подтверждения — частный случай этого общего принципа, его стоит явно распространить и на публичные необратимые действия.

8. Пять паттернов оркестрации Anthropic — применительно к заводу

Помимо чистого «агента», Anthropic описывает пять промежуточных паттернов, которые часто путают с полноценными агентами, но по факту являются структурированными workflow с элементами делегирования. Разбор каждого на живом материале завода Лучиана полезен именно потому, что показывает: в его инфраструктуре УЖЕ реализованы почти все эти паттерны, просто без общего названия — курс должен дать ему словарь для того, что он построил интуитивно.

Вывод: у Лучиана уже есть работающие экземпляры четырёх из пяти паттернов Anthropic. Не хватает главного — настоящего Agent (шестой, самый сложный паттерн из их классификации): цикла, где число шагов и выбор инструментов решает сама модель, а не заранее зашитый в код маршрут. Это ровно то, что нужно для цели №1 (строитель приложений) и для будущего «мозгового» оркестратора, который должен САМ решать, сколько раз прогнать критику, а не идти по фиксированным восьми стадиям.

9. Анатомия одного агента — компонент за компонентом, на примере его завода

Раскладывая единичного агента на части (а не на весь конвейер), выделяются пять слоёв, которые стоит проектировать по отдельности, потому что у каждого свой набор ошибок:

  1. Восприятие (Perception). Что агент видит на входе хода: результат последнего инструмента, текущее состояние проекта, релевантные фрагменты памяти. Ошибка — присылать агенту «всё подряд» (весь лог завода) вместо отфильтрованного, релевантного среза; это прямой путь к раздуванию контекста, о котором Лучиан уже писал в своих требованиях к системе.
  2. Принятие решений (Decision-Making). Собственно LLM как «мозг» — здесь работает его лестница моделей (haiku на механику, sonnet на код, opus на архитектуру): не каждый ход агента должен идти через самую дорогую модель, большинство рутинных решений («вызвать инструмент X с параметром Y») — задача для дешёвой модели.
  3. Действие (Action). Вызов инструмента — реальное изменение состояния мира (записать файл, дёрнуть API channel-hq, потратить GPU-слот через resource-governor). Здесь принцип «read автоматически, write требует валидацию, delete требует одобрение человека» (из материалов о guardrails) — прямое обоснование того, почему APPROVAL_PENDING перед UPLOADING должен остаться даже в автономном режиме: аплоад на YouTube — необратимое публичное действие, а не «write» внутри своей БД.
  4. Память. Короткая (контекст хода — то, что агент реально видит прямо сейчас) и долгая (персистентное хранилище между ходами и сессиями). У Лучиана долгая память — это буквально memory-bank с тремя банками (global/per-channel/per-generator) плюс log.jsonl. Важно понимать: LLM не «помнит» в буквальном смысле — каждый вызов ей заново пересказывают нужный кусок истории; поэтому качество долгой памяти определяется не объёмом файла, а тем, насколько точно система выбирает, что именно «пересказать» агенту на этом ходу (это и есть RAG-слой поверх memory-bank, которого пока нет — банки читаются, но нет семантического retrieval).
  5. Обратная связь (Feedback Loop). Замыкает цикл: агент должен получать сигнал из реального окружения (прошёл тест / не прошёл, набрал просмотры / нет), а не из собственной уверенности. Это самое слабое место текущего завода — стадия ⑨ LEARNING работает вхолостую именно потому, что этот слой физически отключён (оркестратор выключен, метрики с YouTube не долетают до memory-bank автоматически).

10. Function Tools vs Custom Tools — деталь, которая экономит деньги

В материалах проводится различие, которое на практике редко объясняют, а оно прямо влияет на надёжность и стоимость: Function Tools используют строгие JSON-схемы (чёткие типы параметров) — они надёжнее для модели, потому что пространство возможных вызовов ограничено и предсказуемо; Custom Tools принимают свободный текстовый ввод и полезны там, где заранее нельзя описать структуру (например, произвольный bash-скрипт или SQL-запрос). Для завода это означает конкретный архитектурный выбор: там, где действие детерминировано и повторяемо (создать проект, одобрить пакет, запросить слот у resource-governor) — обязательно Function Tool со строгой схемой, а не «опиши словами что сделать». Там же, где агенту нужно исследовать неизвестную территорию (ресёрч ниши, анализ конкурента, произвольный код для строителя приложений) — уместен Custom Tool в духе «выполнить код». Смешивать эти два режима в одном инструменте — типичная причина, по которой агент то работает надёжно, то начинает «фантазировать» параметры.

11. Пример одного полного хода на конкретной задаче — трассировка

Чтобы анатомия не осталась абстракцией, полезно проследить один ход гипотетического agentic-оркестратора поверх завода на конкретной задаче: «канал Х теряет просмотры на shorts, разберись и предложи фикс».

  1. Инициализация. Оркестратор получает задачу от Лучиана (или от cron-триггера мониторинга метрик). Это единственный человеческий ввод — дальше цикл автономен.
  2. Рассуждение. Модель (уровень sonnet, задача аналитическая, не архитектурная) решает: сначала нужно посмотреть свежие метрики канала, потом — сравнить с историческими нормами в memory-bank.
  3. Выбор инструмента №1. Вызов Function Tool get_channel_metrics(channel_id, period) — строгая схема, детерминированный ответ.
  4. Observation. Получены цифры: retention упал на 15% на первых 3 секундах.
  5. Рассуждение (ход 2). Модель формулирует гипотезу — проблема в хуке/первых кадрах, а не в теме. Решает свериться с _STYLE_PLAYBOOK.md и последними изменениями stage_visual_rules.
  6. Выбор инструмента №2. Custom Tool — чтение файлов через bash/grep (mechanical-first, без LLM-аудита, по правилу Лучиана).
  7. Оценка прогресса. Модель находит: неделю назад менялся style_target в профиле канала — вероятная причина.
  8. Действие с последствиями. Здесь агент упирается в guardrail: изменение style_target — это write, требующее валидации, а не мгновенного отката. Агент готовит патч и уходит в EDIT_PENDING-эквивалент вместо того, чтобы применить его сам.
  9. Завершение хода. Отчёт человеку с диагнозом, гипотезой, предлагаемым патчем и оценкой уверенности — а не молчаливое действие.

Этот пример показывает главное отличие настоящего агента от текущего workflow завода: число ходов (2 инструмента, 2 раунда рассуждения) заранее не было известно — оно определилось по ходу расследования. Если бы это был workflow, число шагов и их порядок были бы зашиты в коде заранее, и система не смогла бы адаптироваться, если бы, например, метрики оказались в порядке и проблема была бы не в хуке, а в тайминге публикации.

12. Дополнительные типичные ошибки (расширенный список)

Помимо описанных в разделе 7, материалы выделяют ещё несколько системных ловушек, актуальных именно на этапе перехода Лучиана от workflow-завода к агентной системе:

13. Практические выводы для системы Лучиана

14. Резюме

Ключевая рамка для курса и для архитектурных решений Лучиана: агент — это не более умная модель и не больше инструментов, это система с замкнутым циклом (ход → инструмент → наблюдение → оценка → следующий ход), где число шагов заранее не известно и определяется самой моделью. Всё остальное — workflow, augmented LLM или чат-бот — вопрос не хуже, просто другой контракт с окружением, с другой ценой ошибки и другой предсказуемостью. Завод Лучиана уже реализует четыре из пяти промежуточных паттернов Anthropic (prompt chaining, routing, parallelization, evaluator-optimizer) на уровне отдельных сервисов; не хватает шестого — настоящего замкнутого агентного цикла с самостоятельным выбором числа шагов, работающего поверх уже готового orchestrator.mjs. Путь к целям года (строитель приложений, контент-фабрика на десятках каналов, консультант-фабрика MVP) лежит не через добавление ещё одного сервиса, а через включение недостающего слоя обратной связи (стадия ⑨ LEARNING) и превращение оркестратора из линейного workflow в настоящий agent loop — при сохранении гейтов там, где цена ошибки высока.

Источники (внутри mas-research)