Как Harness Engineering помогает решить проблему "гарантий исполнения" в критических миссиях (mission-critical)?

Краткий тезис

Harness Engineering — это подход к проектированию агентных систем, который вводит детерминированный рантайм (deterministic runtime), формальные контракты для инструментов и координационную инженерию (coordination engineering). Эти элементы позволяют гарантировать, что агент выполнит задачу в заданных рамках, не выйдет за границы допустимого поведения и обеспечит атомарность (all-or-nothing) транзакций. В mission-critical сценариях (медицина, финансы, промышленность) обычный цикл агента|цикл агента|agent loop (цикл «наблюдение → решение → действие») неприемлем из-за риска неоткатимых ошибок, и Harness Engineering предлагает механизмы для явного управления гарантиями.

1. Термин: Harness Engineering (инженерия упряжи)

Harness Engineering — это методология построения безопасных, предсказуемых и воспроизводимых агентных систем. Название происходит от метафоры «упряжи» (harness), которая направляет движение агента, не давая ему отклониться от критического пути. В контексте RAG|agentic RAG (RAG|агентный RAG) это означает жёсткую регламентацию того, какие инструменты может вызывать агент, в каком порядке и с какими гарантиями.

Противопоставление: обычный ReAct-агент (Reasoning + Acting) действует в свободном цикле: LLM генерирует мысль, вызывает инструмент, получает результат, снова думает. Такой цикл не даёт формальных гарантий завершения, может зациклиться или выполнить необратимое действие без возможности отката.

2. Почему обычный agent loop не подходит для mission-critical?

Mission-critical (критически важные миссии) — задачи, где ошибка приводит к катастрофическим последствиям: потеря жизни, финансовый ущерб, нарушение инфраструктуры. Примеры: медицинские рекомендации, управление промышленным роботом, автоматические торговые операции.

Проблемы стандартного agent loop:

Harness Engineering решает эти проблемы через три ключевых компонента: Coordination Engineering, Deterministic Runtime и Формальные контракты.

3. Компонент 1: Coordination Engineering (координационная инженерия)

Это подход к организации нескольких агентов или действий как конечного автомата (state machine) с явно заданными ролями и переходами. Вместо одного LLM, который решает всё, система разбивается на специализированные модули:

• Planner — строит план, используя формальную модель задачи.
• Executor — выполняет шаги плана, вызывает инструменты только из разрешённого набора.
• Monitor — проверяет результаты на соответствие контрактам.
• Coordinator — управляет переходами между состояниями, отвечает за атомарность.

Пример: система медицинской диагностики. Планировщик на основе симптомов генерирует последовательность тестов (анализ крови, МРТ). Исполнитель запускает анализ крови через API лаборатории, получает результат. Монитор проверяет, что результат находится в допустимом диапазоне. Если тест не пройден (ошибка связи) — координатор откатывает транзакцию (отменяет заказ МРТ, уведомляет врача).

Ключевые понятия:

• Ролевая модель (role‑based decomposition) — каждый модуль отвечает за свою часть гарантий.
• Явные переходы (explicit transitions) — поведение описывается как диаграмма состояний, а не неявная цепочка мыслей LLM.

4. Компонент 2: Deterministic Runtime (детерминированный рантайм)

Deterministic runtime — среда исполнения, в которой один и тот же вход (состояние агента, запрос, входные данные) всегда приводит к одному и тому же выходу (действиям, состоянию). Достигается за счёт:

• Фиксации порядка выполнения (execution order) — агент не может пропустить шаг или выбрать другой путь.
• Идемпотентности инструментов (idempotent tools) — многократный вызов одного и того же инструмента с одинаковыми параметрами даёт одинаковый результат без побочных эффектов.
• Отсутствия неявной стохастики — LLM используется только в строго контролируемых точках (например, для генерации текста ответа при известных фактах).

Пример: в системе управления производственным роботом рантайм гарантирует, что сначала проверяется датчик безопасности, затем подаётся команда на движение. Если датчик не отвечает — выполнение останавливается, а не продолжается по «усмотрению» агента.

Преимущество: возможность формальной верификации (model checking, доказательство корректности) для mission‑critical приложений.

5. Компонент 3: Формальные контракты для инструментов (Formal Contracts)

Каждый инструмент (API, функция, внешний сервис) должен иметь спецификацию в стиле Design by Contract (контрактное программирование):

• Pre‑conditions (предусловия) — что должно быть истинно перед вызовом (например, «сумма перевода > 0», «пользователь авторизован»).
• Post‑conditions (постусловия) — что гарантируется после успешного выполнения (например, «баланс отправителя уменьшился на сумму», «баланс получателя увеличился»).
• Invariants (инварианты) — что остаётся неизменным (например, «общая сумма денег в системе сохраняется»).
• Исключительные ситуации (exceptions) — что происходит при сбое (например, «если сервер недоступен, транзакция откатывается»).

Эти контракты могут быть описаны формально (например, на языке TLA+ или Dafny) и проверены статически. В runtime они проверяются монитором (runtime verification).

Пример контракта для инструмента transfer_money(from, to, amount):

# Псевдокод контракта
contract TransferMoney:
    pre:
        from.balance >= amount
        amount > 0
        from != to
    post:
        from.balance == old(from.balance) - amount
        to.balance == old(to.balance) + amount
    invariant:
        total_supply == old(total_supply)

Если агент пытается вызвать инструмент с нарушением pre‑condition — рантайм блокирует вызов и возвращает ошибку, не допуская неконсистентного состояния.

6. Как эти компоненты вместе дают «гарантию исполнения»?

Гарантия исполнения (execution guarantee) — это свойство системы, что заданная задача будет либо полностью выполнена с корректным результатом, либо система останется в безопасном состоянии без побочных эффектов (атомарность).

Схема работы:

1. Planner получает задачу и строит формальный план: последовательность шагов с контрактами.
2. Координатор запускает план в детерминированном рантайме.
3. На каждом шаге Монитор проверяет предусловия инструмента. Если они выполнены — инструмент вызывается, возвращается результат, проверяются постусловия.
4. Если какой‑то шаг не удался (нарушено предусловие, инструмент вернул ошибку), координатор запускает процедуру отката (rollback) для уже выполненных шагов (если они имеют компенсирующие действия).
5. В результате система либо достигает успешного конечного состояния, либо возвращается в исходное.

Таким образом, гарнитура исполнения (execution harness) превращает вероятностное поведение LLM‑агента в детерминированный рабочий процесс (workflow) с гарантиями.

7. Отличие от традиционной RAG и Agentic RAG

8. Пример реализации на Python с использованием формального планировщика

Покажем упрощённый прототип, как может выглядеть harness для транзакции перевода денег.

from dataclasses import [dataclass](/wiki/dataclass)
from typing import Dict, Any, Callable
import [inspect](/wiki/inspect)

# Формальный контракт инструмента
@[dataclass](/wiki/dataclass)
class Contract:
    name: str
    pre_check: Callable751

---


## Навигация
- Предыдущий: [751](/answers/751)
- Следующий: [753](/answers/753)
- Индекс: [00. Индекс разборов](/answers)