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

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

Агенты терпят неудачу не из-за слабости моделей, а из-за неопределенности систем. Хорошая «узда» (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), который гарантирует, что модель не «захлебнется» данными от внешних инструментов. Harness выполняет:

  • 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

Вид графа

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