diff --git a/src/pages/ai/index.md b/src/pages/ai/index.md index 11f1008..b9d5b64 100644 --- a/src/pages/ai/index.md +++ b/src/pages/ai/index.md @@ -1094,16 +1094,34 @@ CORS-конфигурацию или проглотить ошибку авто **Короткий ответ** -Chatbot в основном отвечает текстом в диалоге. Agent может планировать шаги, использовать tools, читать контекст, -изменять файлы, запускать проверки и возвращаться к задаче после результата инструмента. +Chatbot в основном формирует ответ на сообщение. Agent работает циклом «цель → действие → результат → следующий шаг»: +может использовать tools, менять состояние внешней системы и продолжать работу после результата инструмента. **Полный ответ** -Chatbot в основном отвечает текстом в диалоге. Agent может планировать шаги, использовать tools, читать контекст, -изменять файлы, запускать проверки и возвращаться к задаче после результата инструмента. +Chatbot обычно оптимизирован для диалога: получает контекст и возвращает текст, код или структурированный ответ. Agent +добавляет к модели управляющий цикл и инструменты, поэтому может не только советовать, но и выполнять последовательность +действий до достижения цели. -Граница не всегда жесткая: современные chat-продукты тоже умеют tools. Но инженерно agent отличается тем, что его -результат часто является действием в системе, а не только сообщением. +Упрощенный agent loop выглядит так: + +1. Получить цель, ограничения и критерии завершения. +2. Изучить доступный контекст. +3. Выбрать следующий шаг или tool. +4. Получить результат действия и обновить рабочее состояние. +5. Проверить, достигнута ли цель, и при необходимости повторить цикл. +6. Остановиться по success condition, ошибке, лимиту или запросу approval. + +Например, чат-бот может объяснить причину ошибки TypeScript. Coding agent способен найти файл, изменить код, запустить +тест, увидеть новое падение, скорректировать patch и показать итоговый diff. Это уже работа с состоянием проекта, а не +один текстовый ответ. + +Граница между понятиями не абсолютна: современные chat-продукты тоже вызывают tools, а agent может работать всего один +шаг. Практическое отличие - уровень автономности, длительность цикла и возможность совершать действия с последствиями. +Чем больше автономность и blast radius, тем важнее sandbox, permissions, approvals, stop conditions и audit trail. + +На интервью полезно описывать agent не как «более умный chatbot», а как систему из модели, контекста, tools и цикла +управления, где host контролирует реальные действия. @@ -1115,16 +1133,34 @@ Chatbot в основном отвечает текстом в диалоге. A **Короткий ответ** -Tool calling - это механизм, при котором модель не только пишет текст, но и просит вызвать заранее описанный инструмент -с конкретными параметрами. Например: прочитать файл, найти issue, запросить API, открыть браузер или запустить тест. +Tool calling - это механизм, при котором модель формирует структурированный запрос на заранее описанный инструмент, а +host валидирует аргументы, выполняет действие и возвращает результат модели для следующего шага. **Полный ответ** -Tool calling - это механизм, при котором модель не только пишет текст, но и просит вызвать заранее описанный инструмент -с конкретными параметрами. Например: прочитать файл, найти issue, запросить API, открыть браузер или запустить тест. +Модель сама не выполняет функцию, HTTP-запрос или shell-команду. Host предоставляет ей описание доступных tools: имя, +назначение и schema параметров. Когда модель решает использовать инструмент, она формирует структурированный вызов, а +приложение решает, разрешать ли его и как именно исполнить. + +Типичный цикл: -Модель выбирает tool и аргументы, host выполняет вызов, а результат возвращается модели для следующего шага. Поэтому -важны schema параметров, описания tools, permissions и обработка ошибок. +1. Host передает модели список доступных tools и их schemas. +2. Модель выбирает tool и формирует аргументы. +3. Host валидирует schema, permissions и policy. +4. Для рискованного действия может потребоваться approval пользователя. +5. Tool выполняется, а результат или ошибка возвращаются модели. +6. Модель использует результат для ответа или следующего tool call. + +Например, модель может запросить `readFile({path: "src/app.ts"})`. Host обязан проверить путь и права до чтения файла. +Для `deleteDeployment(...)` одной корректной schema недостаточно: нужны authorization, подтверждение и защита от +повторного выполнения. + +Качественный tool должен иметь узкую ответственность, строгую schema, понятные ошибки и предсказуемый результат. Для +операций с side effects важны idempotency, timeout, retry policy и audit log. Опасный анти-паттерн - универсальный tool +вроде `runAnything(command)`, который переносит почти всю security-политику на вероятностное решение модели. + +На интервью сильный ответ разделяет три роли: модель предлагает вызов, host применяет policy, tool выполняет действие. +Именно host, а не prompt, является надежной границей для permissions и validation. @@ -1136,16 +1172,34 @@ Tool calling - это механизм, при котором модель не **Короткий ответ** -Context window - это объем информации, который модель может учитывать в одном запросе: prompt, история диалога, файлы, -результаты tools и ответ модели. +Context window - это ограниченный объем активного контекста модели: инструкции, история, файлы, tool results и будущий +ответ. Большое окно не равно идеальной памяти: важны релевантность, структура и управление контекстом. **Полный ответ** -Context window - это объем информации, который модель может учитывать в одном запросе: prompt, история диалога, файлы, -результаты tools и ответ модели. +Context window определяет, сколько информации модель может учитывать в одном рабочем контексте. В бюджет попадают не +только сообщения пользователя, но и system/developer instructions, история диалога, содержимое файлов, результаты tools +и место, необходимое для ответа модели. + +Для coding agent это важно по нескольким причинам: + +- большой репозиторий физически нельзя постоянно держать целиком в активном контексте; +- длинные логи и tool results могут вытеснять более полезную информацию; +- старые сообщения могут быть сжаты, суммаризированы или отброшены системой; +- наличие факта в контексте не гарантирует, что модель правильно оценит его важность; +- лишний контекст увеличивает стоимость и может ухудшать сигнал относительно шума. -Если контекста слишком много, часть деталей может быть сжата или вытеснена. Поэтому важно давать модели релевантные -файлы, короткие правила, понятную цель и не перегружать запрос большим количеством второстепенных данных. +Поэтому хороший agent не загружает «весь проект на всякий случай». Он сначала ищет релевантные файлы, читает нужные +фрагменты, хранит устойчивые правила отдельно и периодически сжимает рабочее состояние: что уже проверено, какие решения +приняты, какие ограничения остаются. + +Например, вместо передачи тысяч строк CI-лога полезнее найти failing step и дать модели несколько десятков строк вокруг +ошибки. Аналогично архитектурное правило лучше держать в коротком `AGENTS.md` и подтверждать тестом или lint rule, чем +надеяться, что модель найдет его в длинной истории. + +Context window не следует путать с долговременной памятью продукта или внешним knowledge store. На интервью полезно +подчеркнуть: размер окна - это емкость активного рабочего контекста, а качество агента зависит еще и от retrieval, +компактации, приоритизации и проверок. @@ -1157,21 +1211,39 @@ Context window - это объем информации, который моде **Короткий ответ** -Причины обычно практические: +Чаще это не буквальное «забывание»: ограничение может потеряться при compaction, оказаться слишком далеко, конфликтовать +с более свежей инструкцией или утонуть в tool results. Критичные правила нужно закреплять проверками вне модели. **Полный ответ** -Причины обычно практические: +Agent работает с ограниченным и постоянно меняющимся контекстом. По мере исследования добавляются файлы, логи, ответы +API и промежуточные решения. Даже правильное правило из начала задачи может перестать достаточно влиять на следующий +шаг. + +Типичные причины: + +- ранняя часть истории была суммаризирована или вытеснена; +- правило сформулировано слишком общо и допускает разные трактовки; +- новая инструкция выглядит более конкретной или более свежей; +- tool result добавил много шума и сместил локальный фокус; +- длинная задача распалась на подзадачи, где исходное ограничение не повторилось; +- несколько instruction-файлов или источников содержат противоречивые правила. + +Например, в начале задачи можно написать «не меняй публичный API», а через двадцать шагов агент ради упрощения теста +переименует exported method. Исправлять это только еще одной фразой в prompt недостаточно. -- ограничение было далеко в истории диалога; -- контекст переполнен; -- правило конфликтует с более свежей инструкцией; -- оно было сформулировано слишком общо; -- агент сфокусировался на локальной подзадаче; -- tool result добавил много шума. +Надежный процесс переносит важные ограничения из памяти модели в проверяемые границы: -Важные ограничения лучше держать рядом с задачей, в `AGENTS.md`, skill или проверяемом checklist. Для критичных правил -нужны автоматические проверки, а не только надежда на память модели. +- acceptance tests и type tests для контрактов; +- lint, architecture rules и CI checks; +- allowlist файлов и tools; +- sandbox и permissions; +- approvals перед рискованными действиями; +- короткий checklist перед commit; +- повторное формулирование инвариантов при переходе к новой фазе задачи. + +На интервью сильный ответ звучит так: prompt помогает направлять модель, но критичный invariant должен быть обеспечен +кодом, policy или автоматической проверкой там, где это возможно. @@ -1183,22 +1255,36 @@ Context window - это объем информации, который моде **Короткий ответ** -Хороший workflow похож на дисциплинированную инженерную задачу: +Надежный workflow строится как короткий проверяемый цикл: понять цель, исследовать код, согласовать рискованные решения, +сделать минимальное изменение, запустить проверки, прочитать diff и остановиться по явному критерию завершения. **Полный ответ** -Хороший workflow похож на дисциплинированную инженерную задачу: +Agent workflow стоит проектировать не вокруг максимальной автономности, а вокруг дешевой обратной связи и ограниченного +blast radius. У каждого этапа должны быть понятные входы, выходы и условия, при которых агент продолжает работу или +останавливается. + +Практичная схема: + +1. **Define:** зафиксировать цель, scope, acceptance criteria, запрещенные изменения и команды проверки. +2. **Inspect:** найти релевантные файлы, воспроизвести проблему и проверить предположения. +3. **Plan:** выбрать минимальный путь и отметить решения, которые требуют человека. +4. **Act:** выполнить один небольшой шаг с минимально необходимыми permissions. +5. **Verify:** запустить тесты, typecheck, lint, build или другой наблюдаемый oracle. +6. **Recover:** при ошибке изучить причину, а не бесконечно наслаивать новые workarounds. +7. **Review:** прочитать итоговый diff, проверить scope, безопасность и остаточные риски. +8. **Stop:** завершить работу по success condition, лимиту попыток, бюджету или необходимости approval. + +Например, при исправлении бага агент сначала воспроизводит его тестом, затем меняет минимальный участок кода и повторно +запускает тест. Если для исправления внезапно требуется миграция базы или новая dependency, workflow должен остановиться +на approval point, а не автоматически расширить область задачи. -1. Понять требование. -2. Найти релевантный код. -3. Сформулировать план. -4. Добавить или обновить тест. -5. Сделать минимальное изменение. -6. Запустить проверки. -7. Показать diff и остаточные риски. +Для production-grade агента также важны timeout, лимит итераций, idempotency для повторяемых действий, audit trail и +понятное состояние после частичного сбоя. Иначе система может зациклиться, повторить side effect или оставить проект в +неопределенном состоянии. -Для рискованных задач добавляют approval points: перед архитектурным изменением, установкой зависимостей, миграцией -данных, изменением security-sensitive кода или запуском destructive команд. +На интервью полезно подчеркнуть: хороший agent workflow - это управляемый state machine с проверками и stop conditions, +а не prompt «работай, пока все не будет готово».