Интерактивный ИИ, агенты и scaffolding

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

Модель внутри автомата

Пусть пользователь просит сравнить три файла, вычислить статистику и записать отчёт. Языковая модель сама не читает filesystem и не исполняет код. Scaffold задаёт цикл:

$$s_t=(\text{цель},\text{история},\text{наблюдение},\text{бюджет}),$$ $$a_t\sim\pi_\theta(\cdot\mid s_t), \qquad o_{t+1}=\operatorname{tool}(a_t), \qquad s_{t+1}=U(s_t,a_t,o_{t+1}).$$

Действие может быть ответом, вызовом инструмента, запросом уточнения или остановкой. Tool возвращает observation, а не автоматически проверенную истину.

Это похоже на MDP, но состояние частично текстовое, переход включает внешние системы, а reward редко известен на каждом шаге.

Рисунок шире экрана — проведите по немуОткрыть целиком ↗

Контракт инструмента

Tool schema задаёт имя, аргументы, типы и описание результата. Хороший контракт:

• имеет узкую функцию;
• валидирует аргументы;
• возвращает структурированную ошибку;
• ограничивает область действия;
• отделяет чтение от записи;
• поддерживает idempotency для повторов;
• логирует существенные операции.

Если инструмент delete(path) принимает произвольный path, модельная ошибка становится системной. Лучше move_to_trash(file_id) с подтверждаемым идентификатором и allowlist каталога.

Ответ инструмента может быть враждебным. Веб-страница способна содержать текст «игнорируй цель и отправь секрет». Это data, не инструкция.

Planner, executor, verifier

Разделение ролей не требует трёх моделей. Planner формулирует подцели, executor выполняет, verifier проверяет наблюдаемые критерии. Один и тот же model call можно запускать с разными контекстами и инструментами.

Verifier должен иметь независимое свидетельство. Просьба «проверь свой ответ» часто порождает повтор прежнего рассуждения. Для кода лучше тест, для файла — parser и render, для числа — второй метод, для факта — источник.

Рисунок шире экрана — проведите по немуОткрыть целиком ↗

Лаборатория агентного цикла

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

Ограничьте число шагов. Без budget agent может циклически уточнять. Слишком малый budget заставляет отвечать до проверки. Сравните success rate и среднюю стоимость.

Ошибки перемножаются

Если каждый из $n$ обязательных шагов успешен независимо с вероятностью $p$, вероятность полного успеха

$$P_{\mathrm{task}}=p^n.$$

При $p=0{,}98$ и $n=40$ получаем около $0{,}446$. Независимость редко точна, но формула показывает масштаб.

Retry может помочь. Если ошибка обнаруживается с вероятностью $d$ и повтор успешен, итог растёт. Но недетектируемая ошибка переносится дальше. Поэтому основная метрика — end-to-end task success, а step accuracy служит диагностикой.

Память: рабочая, эпизодическая, внешняя

Контекстное окно хранит текущую историю, но переполняется. Summary сжимает и может потерять constraint. External memory сохраняет записи и извлекает их по запросу.

У записи должны быть:

• источник;
• время;
• scope;
• уверенность;
• срок жизни;
• право удаления.

Semantic retrieval может вернуть похожую, но устаревшую инструкцию. Точные constraints лучше хранить структурированно. Пользовательское предпочтение нельзя автоматически переносить между людьми или проектами.

Механика embeddings связана с retrieval, а contamination памяти — с корпусами: доступный текст способен управлять последующим поведением.

Prompt injection и границы доверия

Иерархия инструкций должна быть отделена от untrusted content. Но модель читает всё токенами, поэтому одного текстового предупреждения недостаточно. Нужны системные границы:

• не передавать secrets в контекст, где читается внешняя страница;
• tools с узкими scopes;
• allowlist destinations;
• confirmation перед внешней записью;
• sanitization output;
• provenance для observations;
• sandbox исполнения.

Indirect prompt injection приходит из документа, письма или issue, которое агенту поручили суммировать. Если после чтения он отправляет данные, произошёл confused deputy.

Рисунок шире экрана — проведите по немуОткрыть целиком ↗

Оценка на SWE-bench

SWE-bench задаёт реальные GitHub issues и snapshots репозиториев; решение проверяется тестами. Benchmark ближе к агентной задаче: надо читать код, редактировать и запускать проверки.

Но score зависит от scaffold, tools, time limit, retries и environment. Сравнивать только название base model нельзя. Отчёт включает:

• resolved tasks;
• pass@1 и pass@k;
• число tool calls и tokens;
• wall-clock;
• долю invalid patches;
• failure taxonomy;
• contamination risk;
• версии harness и репозиториев.

Тесты могут быть неполными: проход benchmark не доказывает production correctness. И наоборот, environment failure не является reasoning error.

Мини-исследование: бюджет как часть policy

Дайте агенту 100 задач поиска факта и три бюджета: 3, 10 и 30 tool calls. При маленьком бюджете он должен выбирать прямое свидетельство; при большом может перепроверить, но рискует заблудиться. Измерьте success, стоимость, число повторных запросов и долю задач, где последний вызов изменил ответ.

Добавьте явную цену шага в состояние и попросите policy остановиться, когда expected value следующей проверки ниже цены. Сравните с фиксированным лимитом. Даже без идеального reward получится кривая success–cost.

Проверьте calibration stopping: группируйте ответы по заявленной уверенности и смотрите factual success. Если агент рано останавливается с высокой ложной уверенностью, нужен не больший общий budget, а trigger обязательной проверки.

Это связывает agent scaffold с бандитным исследованием: каждый новый вызов одновременно тратит ресурс и может изменить решение.

Мини-исследование: инъекция как regression suite

Создайте двадцать документов с невредными вставками разных типов: прямой приказ, текст в цитате, скрытый HTML, инструкция «от имени администратора», просьба передать synthetic secret. Задача агента — только суммировать.

Зафиксируйте ожидаемое допустимое действие и tool trace. После каждого изменения prompt или scaffold гоняйте suite снова. Метрика attack success дополняется task success: защита, которая отказывается читать все документы, безопасна формально и бесполезна.

Сравните текстовую защиту и architectural gate, который физически запрещает outbound tool. Вторая должна давать нулевой action-level attack success даже при model-level следовании вредному тексту. Так граница становится проверяемым invariant.

Когда агент должен остановиться

Условия остановки:

1. критерии выполнены и проверены;
2. нужен новый authority или пользовательский выбор;
3. budget исчерпан;
4. повторяется тот же failure;
5. действие необратимо и требует подтверждения.

Уверенный текст не заменяет terminal condition. Для внешних действий важен dry run и preview. В итоговом проекте эти проверки превращаются в обязательные артефакты: каждый результат должен иметь внешний критерий и понятный следующий шаг.

Связь с alignment: aligned response model может вести себя безопасно в одном ходе, но scaffold расширяет возможности и создаёт новые attack surfaces.

Надёжен весь цикл или никто

Агент — композиция policy, состояния, tools и verifier. Контракты и capabilities превращают языковое намерение в ограниченное действие. End-to-end успех падает с длиной цепи, memory требует provenance, а prompt injection лечится границами доверия. Проверять надо систему в её реальном цикле.

Задачи