REPL-loop (цикл агента)

REPL-loop (Read-Eval-Print Loop — цикл чтения, выполнения, вывода) — фундаментальный паттерн взаимодействия между человеком и AI-агентом, в котором агент итеративно получает задачу, выполняет действие, наблюдает результат и продолжает до завершения цели.

Термин пришёл из программирования, где REPL — это интерактивная оболочка (Python REPL, Node.js REPL), в которой каждая введённая команда немедленно выполняется и выводит результат. В контексте AI-агентов REPL-loop описывает тот же принцип, но на уровне агентного цикла: агент не генерирует ответ за один проход, а итерирует через действия и наблюдения.

---

Классический REPL в программировании

$ python
>>> x = [1, 2, 3]          ← Read (ввод)
>>> sum(x)                  ← Eval (выполнение)
6                           ← Print (вывод)
>>> x.append(4)             ← следующая итерация
>>> sum(x)
10

Ключевые свойства:

• Мгновенная обратная связь — результат виден сразу

• Итеративность — каждый шаг строится на предыдущем

• Стейтфулность — переменные сохраняются между шагами

---

REPL-loop в AI-агентах

AI-агент адаптирует тот же цикл, но вместо ввода — задача на естественном языке, вместо eval — вызов инструмента, вместо print — наблюдение за результатом:

┌─────────────────────────────────────────────┐
│                  REPL-LOOP                  │
│                                             │
│  Задача/инструкция (Read)                   │
│         ↓                                   │
│  Рассуждение: что делать дальше?            │
│         ↓                                   │
│  Вызов инструмента / действие (Eval)        │
│         ↓                                   │
│  Наблюдение результата (Print/Observe)      │
│         ↓                                   │
│  Достигнута цель? ──── Да ──→ Стоп          │
│         │                                   │
│         Нет                                 │
│         ↓                                   │
│  Следующая итерация ←────────────────────   │
└─────────────────────────────────────────────┘

Пример: агент пишет и запускает тест

Итерация 1
  Read:    "Напиши тест для функции calculate_discount()"
  Eval:    read_file("discount.py")
  Observe: [код функции с параметрами price, discount_pct]

Итерация 2
  Read:    [продолжение, знает сигнатуру функции]
  Eval:    write_file("test_discount.py", [тест-код])
  Observe: [файл создан успешно]

Итерация 3
  Eval:    run_command("pytest test_discount.py -v")
  Observe: FAILED - AssertionError: expected 90.0, got 9.0

Итерация 4
  [Агент видит ошибку, анализирует]
  Eval:    edit_file("test_discount.py", [исправление])
  Observe: [файл обновлён]

Итерация 5
  Eval:    run_command("pytest test_discount.py -v")
  Observe: PASSED - 3 tests in 0.12s

Стоп: цель достигнута

---

ReAct: Reasoning + Acting

Распространённая реализация REPL-loop в LLM-агентах — паттерн ReAct (Reasoning + Acting), предложенный в 2022 году. Агент явно чередует шаги размышления (Thought) и действия (Action):

Thought: Мне нужно проверить, что функция правильно обрабатывает граничный случай — скидку 100%
Action: run_tool({"tool": "bash", "cmd": "python -c 'from discount import calculate_discount; print(calculate_discount(100, 100))'"}
Observation: 0.0

Thought: Функция возвращает 0 при скидке 100% — это корректно. Теперь проверю отрицательную скидку
Action: run_tool({"tool": "bash", "cmd": "python -c 'from discount import calculate_discount; print(calculate_discount(100, -10))'"}
Observation: 110.0

Thought: При отрицательной скидке цена увеличивается — нужно проверить, предусмотрена ли валидация в требованиях
Action: read_file("requirements/discount_spec.md")
...

Явный Thought-шаг делает рассуждение агента прозрачным и помогает избежать прыжков к неверным действиям.

---

Виды REPL-loop в зависимости от инструментов

1. Code execution loop

Агент пишет код → запускает → видит ошибку → исправляет → повторяет:

write(code) → run(code) → observe(error/output) → fix → run → ...

Используется в: Claude Code, Cursor Agent, Devin, GitHub Copilot Workspace

2. Browser loop

Агент взаимодействует с браузером итеративно:

navigate(url) → screenshot() → analyze() → click/type → screenshot() → ...

Используется в: Claude Computer Use, browser-use, Playwright MCP

3. File system loop

Агент читает → анализирует → редактирует → верифицирует:

read_files() → analyze() → edit() → run_tests() → observe() → ...

4. Multi-agent loop

Несколько агентов взаимодействуют в цикле — оркестратор и специализированные субагенты:

Orchestrator:  "Нужен тест для auth-модуля"
  → Agent-Reader:   читает auth-код
  → Agent-Writer:   пишет тесты
  → Agent-Runner:   запускает тесты
  → Agent-Fixer:    исправляет падения
Orchestrator:  [получает финальный результат]

---

Параметры качества REPL-loop

Глубина цикла (loop depth)

Сколько итераций делает агент, прежде чем достичь цели:

• 1-3 итерации — простые задачи (прочитать файл, добавить строку)

• 5-15 итераций — средние задачи (написать функцию с тестами)

• 20+ итераций — сложные задачи (реализовать фичу с нуля, провести исследовательское тестирование)

Слишком длинный цикл — признак плохого планирования или неподходящей задачи.

Детерминизм (determinism)

Один и тот же запрос должен давать схожий результат при повторном запуске. На практике LLM-агенты недетерминированы — важно при CI/CD-интеграции.

Стоп-критерий (stopping condition)

Агент должен знать, когда остановиться:

• Явный: задача выполнена по чёткому критерию (тесты зелёные)

• Неявный: агент решает сам («задача выглядит выполненной»)

• По лимиту: принудительная остановка после N итераций

Без чёткого стоп-критерия агент может уйти в бесконечный цикл или остановиться преждевременно.

---

REPL-loop в тестировании

Исследовательское тестирование через REPL

Задача: "Найди баги в модуле оплаты"

Итерация 1: Читает код payment_service.py
Итерация 2: Идентифицирует потенциально опасные участки
Итерация 3: Пишет тест для race condition в concurrent payments
Итерация 4: Запускает тест — нашёл реальный баг
Итерация 5: Документирует баг, пишет шаги воспроизведения
Итерация 6: Проверяет смежный модуль refund_service.py
...

Автоматическое исправление тестов

CI сломан: 3 теста падают

Итерация 1: Читает лог падения
Итерация 2: Находит изменения в API (сигнатура изменилась)
Итерация 3: Обновляет тест 1 — запускает — зелёный
Итерация 4: Обновляет тест 2 — запускает — зелёный
Итерация 5: Обновляет тест 3 — запускает — зелёный
Итерация 6: Запускает весь suite — все зелёные

Генерация тест-данных

Задача: "Подготовь 100 сценариев для нагрузочного теста"

Агент итеративно:
→ Читает структуру БД
→ Генерирует первые 10 записей
→ Проверяет валидность через API
→ Исправляет формат по ошибкам валидации
→ Генерирует следующую партию
→ Повторяет до 100

---

Управление REPL-loop: советы для QA

Давайте чёткие стоп-критерии:

Плохо:  "Протестируй форму"
Хорошо: "Протестируй форму. Стоп-критерий: покрыты позитивный путь, пустые поля, невалидные форматы, SQL-инъекция. Итог — список найденных дефектов."

Ограничивайте scope:

Плохо:  "Найди все баги в проекте"
Хорошо: "Найди баги в payment_service.py, только в методах charge() и refund()"

Задавайте формат наблюдений:

"После каждого шага пиши краткий итог: что сделано, что обнаружено"

Используйте Human-in-the-Loop на ключевых точках:

"Перед тем как создать баг-репорт, покажи мне найденные дефекты для проверки"

---

Ограничения

Накопление ошибок — ошибка на раннем шаге может привести к цепочке неверных действий в последующих итерациях (error propagation).

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

Галлюцинации действий — агент может «выдумать» результат инструмента вместо реального вызова, если инструмент недоступен.

Зависание в локальном оптимуме — агент может зациклиться на одном подходе, не пробуя альтернативы.

---

Связанные материалы

• Agentic Development

• Human-in-the-Loop

• Claude Code

• MCP серверы для тестирования