# 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](/qa_bible/ai-v-testirovanii/agentic-development.md)
* [Human-in-the-Loop](/qa_bible/ai-v-testirovanii/human-in-the-loop.md)
* [Claude Code](/qa_bible/ai-v-testirovanii/claude-code.md)
* [MCP серверы для тестирования](/qa_bible/ai-v-testirovanii/mcp-servery-dlya-testirovaniya.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://vladislaveremeev.gitbook.io/qa_bible/ai-v-testirovanii/repl-loop.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
