AI Knowledge Base

003. 2026-04-16 - Harness Engineering - Your AI Isnt Stupid - Lychee Blog

Ваш ИИ не «глупый» — ему нужен более надёжный харнес (Harness)

Оригинал статьи: Your AI Isn’t “Stupid” — It Just Needs a Better Harness

Краткий обзор

Главная мысль автора: многие сбои агента связаны не только с моделью, но и с окружающей системой. Хороший харнес ограничивает действия, выносит состояние наружу, проверяет результаты и помогает восстановиться после ошибки.

1. Проблема: Коллапс на 10-м шаге

Представьте агента для исследования рынка. Шаги 1–3 проходят идеально: план, поиск, экстракция. Но к 7-му шагу он начинает галлюцинировать цифрами (потому что контекст переполнился), а к 10-му выдает сломанный JSON. Это «агентный коллапс». Проблема здесь не в «лошади» (модели), а в «поводьях» (системе управления).

2. Первопричина: Смена парадигмы в AI-инжиниринге

Мы переходим из эры Prompt Engineering (как просить) в эру Harness Engineering (как строить систему вокруг модели). Агент — это не просто LLM, это LLM, встроенная в строгий каркас кода, управления состоянием и рабочих процессов восстановления.

ЭраФокусОграничение
Prompt EngineeringИнструкцииХрупкость; нет персистентности.
Context EngineeringИнформация (RAG)Отсутствие состояния (stateless); нет контроля выполнения.
Harness EngineeringДизайн системыУправляет рисками длительного выполнения.

3. Принципы дизайна хорошего Harness

  1. Подкрепляй инструкции ограничениями. Промпт «всегда отвечай в JSON» может не сработать; валидатор схемы обнаружит часть ошибок формата, но не гарантирует смысловую корректность.
  2. Экстернализируй состояние. Если информация важна для задачи — она должна быть вне контекстного окна (на диске).
  3. Делай каждый шаг верифицируемым. Если вы не можете проверить шаг программой, вы не можете ему доверять.
  4. Падай локально, а не глобально. Ошибка в одном инструменте должна вызывать ретрай этого шага, а не перезапуск всей системы.

4. Стек «Узды» (The 7-Layer Harness Stack)

1. Cognition (Когнитивный слой)

Фундаментальный слой, который ограничивает операционные границы модели.

  • Суть: Вместо того чтобы скармливать агенту массивный системный промпт-энциклопедию, Harness выдает ему «локальную карту» его текущей роли, критериев успеха и жестких негативных ограничений (что НЕ делать).
  • На практике: Это структурированные системные промпты или файлы ролей (напр. agents.md), динамически генерируемые под конкретный шаг задачи.

2. Tools (Инструменты)

Промежуточный слой (middleware), который ограничивает и нормализует данные внешних инструментов. Харнес выполняет:

  • Ranking: Ранжирование результатов (BM25 или эмбеддинги), чтобы показать только самое важное.
  • Deduplication: Удаление повторяющейся информации до того, как она съест токены.
  • Token Budget Truncation: Жесткая обрезка (truncation) вывода инструментов. Это предотвращает критическую ошибку, когда огромный ответ от поиска молча «выталкивает» инструкции из контекста.

3. Contracts & Interfaces (Контракты)

Самый пропускаемый слой, вызывающий загадочные сбои в продакшене.

  • Суть: Модель говорит вероятностями, а Harness должен говорить типами данных. Каждая граница (LLM ↔ Tool) должна иметь строгий контракт: JSON-схему, типизированную сигнатуру функции или версию API.
  • Зачем: Это предотвращает «дрейф схемы» (когда модель выдает цену строкой "100$" вместо числа 100.0), блокируя некорректные данные до того, как они испортят систему.

4. Orchestration (Оркестрация)

Без этого слоя LLM склонна к бесконечным циклам или преждевременной «победе».

  • Суть: Harness навязывает структуру воркфлоу (DAG или State Machine), определяющую легальные переходы: План → Сбор данных → Черновик → Верификация.
  • Логика: Модель лишь предлагает действие, а Harness решает, допустимо ли оно по регламенту системы.

5. Memory & State (Память и Состояние)

Явное управление состоянием для предотвращения «амнезии». Стек делит память на два уровня:

  • Working Memory (Краткосрочная): Текущее окно контекста для выполнения шага.
  • Persistent State (Долгосрочная): Структурированный файл (напр. state.json), который отслеживает, какие подзадачи выполнены, а какие в очереди. Эта память выживает даже при сбросе контекста или падении сессии.

6. Evaluation & Observation (Эвалюация)

Система не может полагаться только на «еще один промпт» для проверки. Эвалюация должна быть гетерогенной:

  • Rule-based: Проверка JSON-схем или длины строк.
  • Tool-based: Запуск сгенерированного кода в компиляторе или физическая проверка интерфейса через Playwright.
  • LLM-as-judge: Резервируется только для субъективных вещей (тон, связность), где детерминированные проверки невозможны.

7. Constraints & Recovery (Восстановление)

Слой, превращающий хрупкое демо в надежный продукт.

  • Суть: Обеспечение идемпотентности. Если API инструмента отвалилось по таймауту, Harness перехватывает ошибку и пробует повторить именно этот шаг с экспоненциальной задержкой.
  • Результат: Blast radius (радиус поражения) любой ошибки ограничен одним шагом, а не всей системой.

5. Пример: Один полный прогон агента (One Full Agent Run)

sequence diagram

  1. Шаг 1 — Запрос: «Сравни цены Конкурента А и Конкурента Б».
  2. Шаг 2 — Оркестрация: Планировщик создает DAG. В state.json пишется: “Конкурент А — IN_PROGRESS”.
  3. Шаг 3 — Инструменты: Поиск выдает 50 результатов. Harness фильтрует их и возвращает топ-3000 токенов. Контракт валидирует выход.
  4. Шаг 4 — Эвалюация: Модель генерирует данные. Evaluation ловит отсутствие поля currency в JSON.
  5. Шаг 5 — Восстановление: Harness перехватывает ошибку и отправляет её модели на локальный ретрай (retry).
  6. Шаг 6 — Стейт: Данные прошли проверку. state.json фиксирует: “Конкурент А — COMPLETED”.
  7. Шаг 7 — Сбой: Сайт Конкурента Б лежит. Harness видит пустой payload и запускает Fallback (запасной поиск).
  8. Шаг 8 — Финиш: Запасной поиск сработал. Стейт обновлен на завершение задачи.

6. Продвинутые ловушки: уроки с передовой

Ловушка 1: “Context Anxiety” (Тревога контекста)

При заполнении окна на 70%+, модель начинает «торопиться», пропускать шаги или преждевременно завершать задачу. Решение: Context Reset. Сохраняем стейт на диск → Убиваем инстанс → Запускаем чистый инстанс.

Ловушка 2: Иллюзия самопроверки

Модель склонна одобрять свой посредственный код. Решение: Sprint Contract. Проверку делает независимый Эвалюатор на чистом контексте (он не видит логи рассуждений Исполнителя).

Ловушка 3: Оптимизация под «иллюзию правильности»

При агрессивных ошибках («Ты не прав!») модель перестает решать задачу и начинает имитировать правильность. Решение: Обратная связь должна быть строго объективной (только системные трейсы).

Ловушка 4: Цикл консолидации памяти

Логи со временем раздуваются и противоречат друг другу. Решение: Периодическая дефрагментация — фоновый процесс сжимает историю (напр. с 32k до 7k токенов), сохраняя только факты.

7. С чего начать: Minimum Viable Harness (MVH)

  1. state.json — файл статуса задач на диске.
  2. Retry wrapper — try/catch для каждого инструмента.
  3. Schema validator — проверка каждого выхода LLM.
  4. Tool truncation — жесткая обрезка вывода инструментов.

🔗 Связи

Теги: harnessengineering reliability agenticsystems architecture

Вид графа

Обратные ссылки