Агент и чат: чем отличается и почему это меняет работу

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

Полезнее начать с одного структурного различия. Оно объясняет и выигрыш, и все характерные способы проиграть.

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

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

Одна модель, два контура

Чат: человек как провод

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

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

Из этого следует и главное ограничение, и главная защита чата:

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

Агент: петлю замыкает обвязка

У агента между моделью и репозиторием стоит программа — назовём её обвязкой (в англоязычной документации обычно harness, «упряжь»). Обвязка принимает от модели структурированный запрос вида «прочитай файл X», «выполни команду Y», исполняет его в вашей среде и кладёт результат — содержимое файла, stdout, код возврата — обратно в контекст следующего запроса к модели.

Круг замкнулся без вас. Именно это, и ничего больше, делает агента агентом.

Формально это тот же цикл «рассуждение — действие — наблюдение», который описан в статье ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022) и разобран в главе Агенты и ReAct трека ai-engineering. Разница между исследовательским прототипом 2022 года и сегодняшним CLI — в качестве модели, в наборе инструментов и в количестве инженерии вокруг, но не в идее.

Вот как выглядят оба контура на одном ходе работы:

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

Что чем является: короткая таблица

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

Не бинарность, а лестница автономии

Деление «чат против агента» удобно для объяснения, но в работе вы выбираете не из двух вариантов, а из точки на шкале. Ступени различаются одним параметром — что обвязке разрешено делать без вашего подтверждения.

Ступень 0 стоит держать отдельно от остальных: построчное автодополнение — это не агент и не чат, это другой инструмент с другой эргономикой. Оно не рассуждает о задаче и не наблюдает последствий; оно продолжает текст. Путаница здесь мешает обсуждать и то, и другое.

Практическое правило выбора ступени простое: берите самую низкую, на которой задача решается. Ступень 4 на задаче, которой хватило бы ступени 2, — это не «прогресс», а лишний дифф, который вам же читать. И обратное верно: если вы держите агента на ступени 3 и вручную применяете каждый его патч на механической задаче, вы просто вернулись в чат, оплатив агентские токены.

Что реально меняется

1. Обратная связь замыкается без человека

Это единственное преимущество агента, из которого растут все остальные. Модель видит не ваше «тесты падают», а полный трейс: имя теста, ожидание, факт, номер строки. Она видит вывод компилятора, а не его краткое изложение. Она может сама прочитать соседний файл, чтобы уточнить сигнатуру, вместо того чтобы догадываться.

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

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

2. Появляется состояние во внешнем мире

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

Отсюда правило, которое стоит принять до первой серьёзной сессии: агента запускают в среде, потерю которой вы готовы пережить. Чистая ветка, зафиксированные изменения, отдельный worktree или контейнер. Это не паранойя про «взбесившийся ИИ» — это обычная гигиена работы с процессом, который пишет в файлы по не полностью предсказуемым правилам.

3. Цена растёт нелинейно

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

def суммарный_вход(шагов: int, старт: int, прирост: int) -> int:
    """Сколько входных токенов будет отправлено за всю агентную сессию.

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

    Модель упрощённая: без кэширования префикса и без компакции.
    Время O(n), память O(1).
    """
    итого = 0
    контекст = старт
    for _ in range(шагов):
        итого += контекст      # весь контекст уезжает на вход заново
        контекст += прирост    # наблюдение остаётся в истории
    return итого


# Десять шагов дороже одного не в десять раз, а примерно в двадцать семь;
# сорок шагов — не в сорок, а более чем в триста тридцать.
print(суммарный_вход(1, 4000, 1500))    # 4000
print(суммарный_вход(10, 4000, 1500))   # 107500
print(суммарный_вход(40, 4000, 1500))   # 1330000

Сумма арифметической прогрессии растёт как O(n²) по числу шагов. Это грубая верхняя оценка: реальные системы сбивают её кэшированием неизменного префикса и компакцией истории (об этом — Контекст: окно, компакция и что можно терять без ущерба). Но порядок величины она передаёт честно, и вывод из неё практический:

Длинная агентная сессия дороже короткой сильно нелинейно. Пять сессий по восемь шагов почти всегда дешевле одной сессии на сорок — и лучше по качеству, потому что в короткой сессии меньше мусора в контексте.

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

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

Третий компонент, самый недооценённый, — ваше внимание на ревью. О нём ниже отдельно.

4. Ошибка перестаёт быть безобидной

Сравните два сценария с одной и той же ошибкой модели — она перепутала имя поля в структуре.

• Чат. Вы вставляете код, IDE подчёркивает поле красным, вы правите за пять секунд. Инцидента не было.
• Агент. Модель пишет патч, компилятор ругается, модель видит ошибку и «чинит» — например, добавляет поле в структуру. Тесты проходят. В диффе на ревью появляется лишнее поле в модели данных, и объяснение к нему звучит убедительно.

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

Типология таких отказов — тема главы Где агенты врут. Пока достаточно запомнить сам механизм: петля усиливает и легитимизирует ошибку, а не отсеивает её.

5. Роль человека смещается с исполнения на приёмку

В чате вы — узкое место по пропускной способности. У агента вы — узкое место по проверке. Объём кода, который приезжает на ревью, растёт, а ваша способность внимательно читать код — нет.

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

Есть и измеренная сторона вопроса. В рандомизированном исследовании METR Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity шестнадцать опытных разработчиков решали задачи в собственных больших репозиториях — с разрешением использовать ИИ-инструменты и без. С инструментами они выполняли задачи в среднем медленнее на 19 %, при этом ожидали ускорения примерно на 24 % и после эксперимента считали, что ускорились. Читать этот результат надо аккуратно: небольшая выборка, зрелые проекты, которые участники знают досконально, и инструменты начала 2025 года. Это не приговор агентам и не универсальный закон. Но два вывода из него устойчивы и полезны:

1. Субъективное ощущение ускорения — плохой измеритель. Оно росло даже там, где скорость падала.
2. Выигрыш зависит от знакомства с кодовой базой. Чем лучше вы знаете код, тем меньше агент добавляет и тем больше отнимает на верификацию.

Что не меняется совсем

Это самый важный раздел главы, и он же тот, который чаще всего пропускают.

Модель осталась той же. Инструменты не улучшают её знания о вашем проекте, не устраняют склонность достраивать правдоподобное на месте пробела и не добавляют способности «понимать» замысел. Всё, что было верно про модель в чате — верно и про агента.

Способность проверить не равна проверке. Агент может запустить тест. Это не значит, что он его запустил, что запустил именно тот, что дождался конца, что прочитал вывод целиком и что интерпретировал его без натяжки. Между «инструмент доступен» и «инструмент применён по делу» лежит вся практика этого трека.

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

Три типовых расхождения между отчётом и реальностью, которые видно почти в каждой длинной сессии:

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

Жизненный цикл одного шага и точки, где всё ломается

Три состояния на этой схеме заслуживают отдельного внимания, потому что ими агент отличается от чата не в лучшую сторону.

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

Залипание. Цикл без прогресса: та же правка, тот же провал, новая формулировка того же подхода. В чате вы замечаете это на второй итерации, потому что итерации проходят через вас. В агентной сессии восемь бесплодных кругов проходят за минуту и стоят токенов. Практический приём — договориться заранее: два неудачных подхода к одной ошибке — стоп и доклад.

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

Единственное правило, которое стоит унести из этой главы

Утверждение агента о поведении кода — это гипотеза, пока вы не увидели прогон. Не отчёт о прогоне, а прогон: команду и её код возврата.

Формулировка звучит банально ровно до момента, когда вы начнёте её применять. На практике она означает вот что.

# Плохая приёмка: вы прочитали в отчёте «тесты проходят» и поверили.

# Хорошая приёмка: вы выполнили это сами, в своей оболочке, после агента.
git diff --stat                 # что вообще изменилось
git status --porcelain          # не появилось ли лишних файлов
pytest -q                       # полный прогон, не выборочный
echo "exit=$?"                  # код возврата — единственное, что не пересказать

Четыре команды, около двадцати секунд. Они закрывают все три расхождения из таблицы выше: git diff --stat ловит подмену области, полный прогон ловит выборочный, код возврата ловит намерение вместо результата.

Как это выглядит на живом примере

Задача была: починить падающий тест на разбор дат. Отчёт агента в конце сессии:

Нашёл причину: парсер не учитывал часовой пояс без двоеточия в смещении. Поправил parse_offset, добавил тест на формат +0300. Тесты проходят.

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

$ git diff --stat
 src/dates.py            | 14 ++++++++------
 src/config.py           |  3 +++
 tests/test_dates.py     | 12 ++++++++++++
 3 files changed, 26 insertions(+), 3 deletions(-)

Вопрос первый: почему в диффе config.py, если чинили парсер? Такая строка — не обвинение, а повод открыть три строки изменений и понять, что это. Часто там окажется безобидное, иногда — «попутно поправил», которого вы не просили. Пункт CODE-14 из пакета шаблонов («одно изменение — одно намерение») существует ровно из-за этого.

$ pytest -q
........................F.......                                   [100%]
1 failed, 31 passed in 2.41s
$ echo "exit=$?"
exit=1

Вопрос второй: агент писал «тесты проходят», а прогон красный. Три обычных объяснения, и ни одно не про злой умысел:

• он прогнал pytest tests/test_dates.py, а не всю сюиту, и утверждение верно ровно про этот файл;
• он видел зелёный прогон до последней правки, а после неё не перепроверял;
• падение действительно было и до его работы, но в отчёте про это не сказано.

Разница между этими вариантами существенна для решения, что делать дальше, — и выясняется она одной командой git stash && pytest -q, а не уточняющим вопросом агенту. Модель не помнит состояние мира; она пересказывает свой же контекст, и в нём вполне может лежать зелёный прогон получасовой давности.

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

Тот же принцип, оформленный как правила для самого агента, есть в нашем пакете шаблонов памяти — products/workbench/templates/memory/ в этом же репозитории портала. Там он разложен на проверяемые пункты: утверждение об API считается подтверждённым только с путём и строкой, командой и её выводом или датированной ссылкой (RSN-02); «тесты проходят» требует команды и кода возврата (RSN-14, CODE-11); поставленное в очередь, начатое и «должно работать» — не результаты (RSN-13); каждый отчёт заканчивается списком того, что осталось непроверенным (RSN-15). Ценность такого пакета не в том, что он мешает модели ошибаться — он не мешает, и в README это сказано прямо. Ценность в том, что нарушение становится видимым в диффе или в отчёте, то есть его можно поймать. Подробно про то, что стоит хранить в памяти агента, а что вредно, — в главе Память агента.

Когда чат лучше агента, а когда — руками

Агент — не апгрейд чата, а другой инструмент с другим профилем издержек. Полезно держать в голове две оси: насколько дёшево проверить результат и сколько контекста из репозитория нужно задаче.

Расположение точек — оценочное и зависит от вашего проекта; ценность схемы в осях, а не в координатах. Разбор по квадрантам:

• Правая верхняя — где агент действительно окупается. Много чтения кода, механическая работа, автоматический критерий приёмки. Массовое переименование, приведение к новому интерфейсу, починка красного теста, разбор упавшего CI.
• Правая нижняя — где быстрее руками. Задача на одну строку, которую вы точно знаете. Пока вы формулируете постановку, вы бы её уже сделали. Честно писать «дешевле руками» — часть инженерной культуры, а не признание в отсталости.
• Левая нижняя — чат или голова. Объяснения, обсуждение подходов, разбор незнакомой библиотеки. Здесь ценен диалог, а не изменение файлов; давать право записи незачем.
• Левая верхняя — самая опасная зона. Много контекста, дорогая проверка: архитектурные решения, работа с деньгами и правами, необратимые операции. Агент здесь применим как читатель и составитель черновиков, но не как исполнитель; и на этом квадранте держится глава Безопасность.

Простое дерево решений, которое можно прогонять в голове за пять секунд:

Обратите внимание на ветку E -- да --> G. Это не бюрократия, а самый надёжный способ сделать агента полезным: сначала создайте измеримый критерий, потом отдавайте задачу. Падающий тест, воспроизводящий баг, стоит десяти абзацев объяснений в промпте — он превращает расплывчатую задачу в задачу с сигналом. Тема развёрнута в главе Проверяемость.

Мини-протокол сессии

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

1. Чистое дерево на входе. git status пуст, работа идёт в отдельной ветке. Тогда git diff — полный и честный отчёт о том, что сделал агент, а откат стоит одну команду.
2. Постановка с критерием приёмки. Не «почини авторизацию», а «после правки pytest tests/auth -q проходит целиком, публичные сигнатуры в auth/api.py не меняются». Промпт как спецификация — тема главы Промпт как спецификация.
3. Явные границы и точки стопа. Что нельзя трогать; после чего нужно остановиться и спросить; что делать при двух неудачных попытках подряд. Границы, заданные заранее, работают; замечания постфактум — нет.
4. Приёмка своими руками. Дифф глазами, полный прогон, код возврата. Отчёт агента читается как заявка на приёмку, а не как её результат.

Что стоит записать в файл контракта проекта (CLAUDE.md, AGENTS.md или аналог в вашем инструменте), а не повторять в каждой сессии: команды сборки и прогона тестов, запретные каталоги, требования к оформлению коммитов, правило «два провала — стоп и доклад». Это тот же самый принцип, что и в шаблонах из products/workbench/templates/memory/: короткий блок в контракте, подробные правила — отдельным справочником, к которому обращаются при споре.

Типичные ошибки при переходе с чата на агента

• Считать агента «умнее». Он не умнее; у него больше информации о вашем коде и право действовать. Задачу, где модель ошибалась в чате из-за нехватки знаний о предметной области, агент решит так же неверно, только с коммитом.
• Давать задачу без критерия готовности. Без сигнала цикл вырождается в генерацию правдоподобного текста и правок, стоимость которых вы оплатите вниманием на ревью.
• Открывать одну длинную сессию на весь день. Контекст засоряется отменёнными подходами и старыми выводами команд, качество падает, цена растёт квадратично. Разбивайте на короткие сессии с ясной целью.
• Читать отчёт вместо диффа. Отчёт — самый убедительный и наименее достоверный артефакт сессии.
• Верить утверждениям о внешних системах. Версии библиотек, флаги CLI, поля API — то, что модель «помнит», является непроверенным по определению. Проверяется чтением установленного исходника или датированной документацией.
• Копировать чужие настройки целиком. Наборы правил и инструментов сильно зависят от кодовой базы и версий; версионность оговорок здесь принципиальна, а сравнение инструментов вынесено в главу Инструменты и практика.
• Запускать агента на грязном дереве. Тогда git diff смешивает ваши изменения с его, и отделить одно от другого стоит дороже, чем вся сэкономленная работа.

Мини-итог

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

Источники

• ReAct: Synergizing Reasoning and Acting in Language Models — Yao et al., 2022; исходная формулировка цикла «рассуждение — действие — наблюдение».
• Building Effective Agents — инженерный разбор от Anthropic, декабрь 2024; отдельно про то, когда агент избыточен и хватает простого пайплайна.
• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR, июль 2025; рандомизированное исследование, где ощущение ускорения разошлось с измеренным результатом.
• SWE-bench — Jimenez et al., 2023; бенчмарк на реальных issue из GitHub. Конкретные проценты решённых задач здесь не приводятся: они меняются от версии модели к версии и от обвязки к обвязке, так что имеют смысл только с точной датой и конфигурацией.
• Документация Claude Code, документация Cursor, репозиторий OpenAI Codex CLI — первоисточники по конкретным обвязкам; всё, что касается флагов и режимов, устаревает быстро, сверяйтесь с текущей версией.
• Model Context Protocol — открытый протокол подключения инструментов, к которому вернёмся в главе про инструменты и MCP.
• The lethal trifecta for AI agents — Simon Willison, июнь 2025; почему сочетание «доступ к приватным данным + чтение недоверенного контента + возможность отправить наружу» опасно само по себе.
• products/workbench/templates/memory/ — наш собственный пакет правил рассуждения, памяти и выверенного кода: маркировка утверждений, требования к доказательствам, шаблон опровержения.

Что дальше

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

Модель исполнения: контекст, инструменты, цикл наблюдение-действие