Как работает AI-агент: модель, agent loop и harness простыми словами

Короткая формула:

AI-агент = LLM + harness/runtime + tools + context + feedback loop + safety controls

Если сказать проще, LLM отвечает за рассуждение и выбор следующего шага. Agent harness, или обвязка агента, собирает задачу, инструкции, контекст и список доступных инструментов в рабочий контур. Runtime, или среда выполнения, обращается к файлам, API, браузеру, поиску, базе данных или shell и возвращает результат обратно в контекст. После этого модель делает следующий шаг, и цикл повторяется до финального ответа, остановки или проверки человеком.

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

Что такое AI-агент простыми словами

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

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

Агентный контур добавляет к модели рабочую среду. Например, агент может прочитать документ, найти данные через web search или API, вызвать MCP-инструмент, открыть браузерную страницу, запустить проверку, увидеть ошибку, предложить исправление или остановиться и попросить подтверждение человека.

Но все это делает не "магическая модель сама по себе". Модель выбирает или запрашивает действие, а выполнение проходит через harness/runtime и заданные правила.

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

Почему LLM сама по себе не агент

LLM, или большая языковая модель, предсказывает следующий фрагмент ответа на основе входного контекста. Она может рассуждать, сравнивать варианты, писать код, объяснять архитектуру и предложить команду. Но без внешнего контура она не выполняет эту команду.

Модель сама по себе:

• не читает файлы из репозитория;
• не запускает shell;
• не ходит в интернет;
• не знает, какие API доступны в конкретной среде;
• не применяет права доступа;
• не проверяет результат тестом или readback;
• не хранит долговременные правила проекта вне переданного контекста.

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

Поэтому точнее говорить не "модель сделала действие", а "агентный контур дал модели возможность запросить действие, выполнил его через инструмент и вернул observation обратно в контекст".

Что такое agent loop

Agent loop, или агентный цикл, — это повторяющаяся последовательность:

1. 1. Пользователь ставит задачу.
2. 2. Harness собирает инструкции, доступные tools, контекст и историю.
3. 3. Модель получает вход и выбирает следующий шаг.
4. 4. Если нужен инструмент, модель запрашивает tool call.
5. 5. Runtime выполняет инструмент в разрешенной среде.
6. 6. Результат инструмента возвращается как observation.
7. 7. Контекст обновляется.
8. 8. Модель решает: продолжать, запросить еще один инструмент, спросить человека или дать финальный ответ.

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

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

Схема: цикл работы AI-агента

Цикл работы AI-агента

Harness собирает контекст, показывает модели доступные инструменты и управляет выполнением. Модель выбирает ответ или tool call, а runtime выполняет инструмент в ограниченной среде и возвращает observation в контекст.

Что делает agent harness

Agent harness — это обвязка, которая превращает модель в часть рабочей системы. Он не "думает вместо модели", а организует среду, в которой модель может безопасно и полезно выбирать действия.

Обычно harness отвечает за несколько вещей:

• собирает системные инструкции, пользовательскую задачу и историю;
• подмешивает проектный контекст и долговременные правила;
• показывает модели список доступных tool surfaces;
• принимает tool call от модели;
• передает вызов в runtime;
• возвращает observation обратно в контекст;
• применяет лимиты, sandbox, approval и human-in-the-loop;
• ведет журнал шагов, ошибок и проверок;
• решает, когда продолжать loop, а когда остановиться.

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

Model vs harness vs runtime

Эти роли полезно разделять уже на этапе проектирования. Если все назвать "агентом", легко потерять место, где реально принимается решение, где выполняется действие и где должна стоять проверка.

Что такое tools и tool surface

Tools — это инструменты, через которые агентный контур может получить данные или выполнить действие. Tool surface — это не просто список названий, а поверхность возможностей: какие операции доступны, какие аргументы принимает инструмент, какие ограничения действуют и какой результат возвращается обратно модели.

Примеры tool surfaces:

• shell для команд, тестов и сборки;
• файловая система для чтения и изменения проекта;
• web search для свежих источников;
• браузер для проверки интерфейса;
• API внешних систем;
• базы данных;
• MCP-серверы;
• внутренние runbook-инструменты;
• системы публикации, CRM или helpdesk.

MCP, или Model Context Protocol, полезен как способ стандартизировать доступ к внешним инструментам и данным. Подробнее про этот слой можно смотреть в материале MCP сервер: что это и зачем он нужен AI-агенту.

Хороший tool surface описывает не только "что можно вызвать", но и "когда это можно вызывать". Например, чтение публичной страницы, запуск локального теста и изменение production-записи должны проходить через разные уровни контроля.

Контекст, AGENTS.md и долговременные правила

Контекст — это все, что модель видит в момент выбора следующего шага: задача пользователя, системные инструкции, история диалога, результаты инструментов, фрагменты файлов, документы, правила проекта и ограничения.

Для coding agents часть таких правил часто хранится в файлах вроде AGENTS.md. Это удобный способ дать агенту устойчивые проектные инструкции: где читать архитектуру, какие команды считать безопасными, что нельзя трогать, как оформлять изменения и какие проверки обязательны перед завершением.

Но AGENTS.md не заменяет архитектурную документацию, тесты, права доступа и review. Это слой guidance, а не гарантия корректности. Если правило важно для безопасности или бизнес-логики, оно должно быть поддержано политикой runtime, тестом, approval, мониторингом или процессом проверки.

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

Sandbox, approval и human-in-the-loop

Sandbox — это ограниченная среда, в которой выполняются действия агента. Она может ограничивать файловую систему, сеть, команды, внешние записи, секреты или доступ к production-системам. Но sandbox не защищает все одинаково. Его смысл зависит от конкретной реализации, политики и того, какие инструменты подключены.

Approval — это явное подтверждение действия человеком или системой правил. Он нужен там, где ошибка может стоить денег, данных, репутации или доступности сервиса. Например, одно дело — прочитать локальный файл, другое — удалить запись, отправить письмо клиенту или изменить опубликованную страницу.

Human-in-the-loop не делает агента "менее умным". Наоборот, он позволяет использовать модель там, где автоматизация полезна, но окончательное решение должно оставаться проверяемым. Для проектирования таких границ пригоден чек-лист доступа и approval gates для ИИ-агента.

Где чаще ломается агент

Verification: как понять, что агент действительно сделал работу

Для агентных систем мало получить красивый финальный ответ. Нужно понять, чем он подтвержден.

Хороший контур различает:

• план: что агент собирается сделать;
• tool call: какой инструмент он запросил;
• observation: что инструмент вернул;
• interpretation: как модель поняла результат;
• write: что было изменено;
• readback: где изменение проверено;
• final answer: что сообщено пользователю.

Если агент пишет статью, меняет запись в CMS или обновляет конфигурацию, проверка должна идти через canonical surface: опубликованную страницу, API readback, тест, diff, лог пайплайна или другой источник истины. Финальный ответ модели сам по себе не является доказательством изменения.

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

Что дальше

Если смотреть на AI-агента как на инженерную систему, главный вопрос меняется. Вместо "какую модель выбрать" появляется более полезный набор вопросов:

• какой контекст нужен модели для решения задачи;
• какие tool surfaces действительно нужны;
• где должен выполняться tool call;
• какие действия требуют approval;
• как выглядит observation и readback;
• где агент должен остановиться;
• что увидит человек на review.

Для бизнес-картины начните со статьи ИИ-агент для бизнеса. Для интеграционного слоя посмотрите MCP server. Для границ доступа и проверок пригодится чек-лист approval gates. А если агент работает с кодом, полезен практический материал про Codex в репозитории.