Самоулучшающийся harness

Каждый раз, когда ревьюер переписывает агентский код, он сообщает harness что-то важное. Обычно это знание остаётся в одном MR и теряется. Самоулучшающийся harness — это петля, которая ловит такие правки, превращает повторяющиеся в evals и поручает агенту исправить обвязку так, чтобы ошибка не повторилась. В этом уроке — как устроена петля, на каком публичном примере её проверили и какие ограничители не дают ей пойти вразнос.

Провал агента — это пробел harness

Идея не новая, мы встречали её на протяжении всего курса. В статье OpenAI Harness engineering каждый провал агента разбирают одним вопросом: какой возможности ему не хватило — инструмента, ограничителя, документации. Недостающее возвращается в репозиторий, и исправление тоже пишет Codex. Если документации оказывается мало, правило переносится в код — в линтер или структурный тест.

Биргитта Бёкелер в Harness engineering for coding agent users называет это steering loop: если проблема повторяется, человек усиливает направляющую или датчик, а AI помогает этот механизм построить. В рекомендациях по работе с Codex то же сказано практичнее: правила в AGENTS.md добавлять после повторяющихся ошибок, а после ошибки просить агента провести ретроспективу.

Самоулучшение — следующий шаг: петля работает не тогда, когда кто-то вспомнил, а систематически, и каждое изменение harness проверяется evals.

Кейс: Tax AI

Лучший публичный пример — статья Building self-improving tax agents with Codex (Thrive Holdings и OpenAI, май 2026). Речь о продуктовом агенте, который готовит черновики налоговых деклараций для сети бухгалтерских фирм, но механизм переносится на кодинг-harness почти один к одному.

По данным статьи, за сезон через систему прошло 7 000 деклараций; доля деклараций, где не меньше 75% полей заполнены корректно, выросла с четверти на старте до 86% за шесть недель. Это цифры вендора и заказчика о собственном продукте — используйте их как иллюстрацию механизма, а не как ориентир.

Цепочка улучшения, как её описывают авторы:

1. Практик правит черновик агента.
2. Правка превращается в построчное сравнение «ожидалось — получилось».
3. Повторяющиеся ошибки группируются отдельно от шума.
4. Группа становится целью для eval — холмом, на который можно взбираться.
5. Codex получает трейс, eval, репозиторий и навыки, вносит правку, гоняет целевой eval и регрессию и предлагает PR.
6. Неоднозначные случаи возвращаются людям.

Среда задачи для Codex ограничена: worktree доступен на запись, продовый контекст — только на чтение, успех определяют evals, а навыки и документы фиксируют прошлые решения.

Петля для кодинг-агента в агентстве

Переложим ту же схему на сайт на OctoberCMS и команду, где агентские MR ревьюят люди.

Сигнал. Правки ревьюера в агентских MR, коммиты «fix after review», откаты, баги, которые QA нашёл после агентской задачи. Сырьё уже лежит в GitLab и Kaiten, его нужно только собрать.

Группировка. Одна правка — шум. Три одинаковые за две недели — паттерн. Например, ревьюер трижды переписывает прямые запросы к базе в компоненте на вызовы через модель, или агент снова и снова кладёт стили страницы inline вместо отдельного SCSS-файла. Первичную группировку можно поручить самому агенту:

git log --since="14 days ago" --no-merges -p -- src/plugins src/themes \
  | codex exec --ephemeral --output-schema evals/schemas/fixes.json -o fixes.json \
    "В stdin — история коммитов. Найди коммиты, которые исправляют ошибки предыдущих коммитов. \
Сгруппируй их по повторяющейся причине. Одиночные случаи помечай как noise."

{
  "type": "object",
  "properties": {
    "clusters": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "cause": { "type": "string" },
          "commits": { "type": "array", "items": { "type": "string" } },
          "fix_kind": {
            "type": "string",
            "enum": ["agents_md", "docs", "linter", "structural_test", "skill", "noise"]
          },
          "proposal": { "type": "string" }
        },
        "required": ["cause", "commits", "fix_kind", "proposal"],
        "additionalProperties": false
      }
    }
  },
  "required": ["clusters"],
  "additionalProperties": false
}

Когда stdin передан вместе с промптом, Codex читает его как контекст. Если история за две недели огромная, сузьте пути или период. Как работает ответ по схеме, разобрано в уроке о структурированном выводе.

Eval. Каждый настоящий кластер превращается в 3–5 задач capability-набора по схеме из урока о своих evals. Базовый коммит — состояние до ошибки, оракул — то, что проверил бы ревьюер: структурный тест «в компонентах нет прямых запросов к базе», отсутствие inline-стилей в шаблоне страницы.

Исправление harness. Агенту дают кластер, задачи, транскрипты провалов и просят изменить не продуктовый код, а обвязку:

Цель: задачи evals/tasks/component-db-* должны проходить.
Контекст: кластер в fixes.json, транскрипты в evals/results/latest/,
AGENTS.md, docs/, линтеры в scripts/lint/.
Ограничения: меняй только harness — AGENTS.md, docs/, scripts/lint/, .agents/skills/.
Не меняй evals/ и продуктовый код. Предпочитай самое дешёвое средство:
строка в docs/ со ссылкой из AGENTS.md; если правило проверяемо — линтер
с сообщением об ошибке, которое объясняет, как исправить.
Готово, когда: целевой eval проходит в 3 прогонах из 3, регрессионный набор
не просел; в описании MR — что изменено и почему этого достаточно.

Проверка и выпуск. Целевой eval растёт, регрессионный не падает, человек ревьюит MR в harness. Задачи, которые стабильно проходят, переезжают в регрессию — теперь они охраняют исправление.

Ограничители

Петля, которая сама меняет правила и сама себя проверяет, может оптимизировать не то. Минимальный набор защит:

• Агент не трогает оракулы. Каталог evals/ защищён правами в GitLab или CODEOWNERS, а в промпте прямо запрещён. У Anthropic в схеме для длинных задач агенту разрешено менять только поле статуса фичи, но не править и не удалять тесты — тот же принцип.
• Отложенная выборка. Часть задач кластера не показывайте агенту при исправлении и проверяйте на них отдельно. Anthropic в статье об инструментах для агентов проверяет улучшения именно так. Иначе AGENTS.md переобучится под конкретные пять задач.
• Бюджет контекста. Петля, которая только добавляет правила, быстро нарушит принцип из урока об AGENTS.md как оглавлении. Каждое добавление — повод спросить, что можно удалить. Anthropic в статье о дизайне harness советует с каждой новой моделью убирать то, что перестало нести нагрузку.
• Иерархия средств. Сначала документация, затем код. Правило, которое можно проверить механически, должно жить в линтере, а не в абзаце текста.
• Человек на неоднозначном. Как и в Tax AI, спорные кластеры — «это ошибка агента или у нас нет договорённости?» — решает команда, а не петля.

Как запускать

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

В OpenAI Cookbook есть развёрнутый пример похожей петли для агента на Agents SDK — Build an Agent Improvement Loop with Traces, Evals, and Codex: трейсы и экспертная обратная связь превращаются в тест-кейсы, анализ ранжирует изменения harness, а Codex получает файл передачи с диагнозом и рекомендациями. Диф перед мержем по-прежнему смотрит разработчик.