Что такое агент

Если коротко: агент — это LLM (large language model), которой дали инструменты и разрешили действовать в цикле «думает → действует → смотрит на результат → повторяет», пока цель не достигнута. Каждое слово в этой формуле важно, поэтому разберём её по частям.

Из чего состоит агент

Модель. В основе агента лежит та же самая большая языковая модель, что и в привычном чате. Сама по себе она умеет только одно: получать текст на вход и генерировать текст на выход. Как это устроено, описано на странице Что такое LLM.

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

Цикл. Результат каждого действия возвращается модели, она смотрит на него и решает, что делать дальше. Так агент шаг за шагом продвигается к цели: не один ответ, а последовательность решений, где каждое следующее опирается на реальный результат предыдущего.

Чем агент отличается от чата

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

Агент этот круг замыкает сам:

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

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

Агентный цикл на примере

flowchart LR
    U(["Задача от человека"]) --> M
    M["Модель: что делать дальше?"] --> A["Действие: вызов инструмента"]
    A --> R["Результат в контекст"]
    R --> M
    M -->|"цель достигнута"| D(["Ответ человеку"])

Модель решает, харнес исполняет, результат возвращается в контекст, и так шаг за шагом до цели.

Посмотрим, как выглядит цикл на типовой задаче. Вы пишете агенту:

В проекте падает тест test_invoice_total. Разберись и почини.

Дальше происходит примерно следующее:

1. Думает. Агент решает: сначала нужно увидеть ошибку своими глазами.
2. Действует. Запускает команду pytest tests/test_invoice.py -k test_invoice_total.
3. Смотрит на результат. Тест падает: ожидалось 108.0, получено 100.0. Похоже, где-то теряется налог.
4. Действует. Читает файл теста, затем ищет в проекте функцию расчёта суммы счёта и открывает её код.
5. Смотрит на результат. В функции видно: скидка применяется после добавления налога, и при определённых входных данных налог обнуляется. Вот и причина.
6. Действует. Правит порядок вычислений в функции.
7. Действует снова. Перезапускает тот же тест, теперь зелёный. Запускает весь набор тестов, чтобы убедиться, что ничего не сломалось.
8. Завершает. Сообщает вам: что было сломано, что исправлено, какие тесты прошли.

Обратите внимание: между шагами нет ваших действий. Вы поставили задачу и получили результат с объяснением. Если бы на шаге 7 тест снова упал, агент вернулся бы к началу цикла: прочитал новую ошибку и попробовал иначе.

Автономность — это шкала

«Агент» не означает «полностью сам по себе». Степень самостоятельности настраивается, и это одна из главных ручек управления:

• Подтверждение каждого действия. Агент спрашивает разрешение перед любой командой и правкой файла. Медленно, зато вы видите каждый шаг. Хороший режим для знакомства с инструментом и для чувствительных проектов.
• Подтверждение только опасного. Чтение файлов и поиск разрешены свободно, а запись, запуск команд и обращения в сеть требуют вашего одобрения. Типичный рабочий режим.
• Автономия в рамках задачи. Агент делает всё сам и приходит к вам с готовым результатом. Подходит для понятных, ограниченных задач с хорошими тестами.
• Фоновая автономия. Агент работает в изолированной среде без присмотра, а вы смотрите только итог, например готовый pull request.

Правило простое: чем лучше вы можете проверить результат и чем безопаснее среда, тем больше автономии можно давать. Обратное тоже верно.

Совет

Начинайте с режима подтверждений. Когда поймёте, как агент ведёт себя на вашем проекте, ослабляйте поводок постепенно, а не наоборот.

Границы: где агент ломается

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

• Уходит не туда. Неправильно понял задачу на первом шаге и уверенно делает не то на протяжении двадцати шагов. Чем расплывчатее постановка, тем вероятнее такой сценарий.
• Чинит симптом, а не причину. Когда падает тест, можно исправить логику, а можно «подогнать» тест под неверное поведение. Агент иногда выбирает второе, если его не ограничить.
• Переусложняет. Просили поправить одну функцию, а получили рефакторинг половины модуля.
• Уверенно ошибается. Отчёт агента «всё готово, тесты проходят» — это утверждение модели, а не факт. Его нужно проверять.

Отсюда два практических вывода. Первый. Агенту нужны рамки: понятная постановка задачи, ограничение области изменений, договорённости проекта; как это выстроить, разобрано на странице Рабочий цикл с агентом. Второй. Результат агента нужно проверять и своими глазами, и автоматикой; об этом рассказано на странице Проверка результатов агента.

Заметка

Агент не заменяет вашу ответственность за результат. Он заменяет ручной труд по дороге к результату. Код, который вы отправили в репозиторий, — ваш код, кем бы он ни был напечатан.

Что дальше

• Харнес: что за программа превращает модель в агента и почему её выбор так важен.
• Инструменты и их вызов: как устроен вызов инструментов, «руки» агента.