Харнес (agent harness)

Когда вы работаете с Claude Code, Cursor или Codex, вы общаетесь не с моделью напрямую. Между вами и моделью стоит программа — харнес (agent harness), «обвязка» вокруг модели. Именно она превращает LLM, которая умеет только генерировать текст, в агента, который читает файлы, запускает команды и доводит задачу до конца.

Разделение ответственности: модель и харнес

Проще всего думать так: модель «думает», харнес даёт «руки» и правила.

flowchart LR
    You(["Вы"]) <--> H
    subgraph H ["Харнес"]
      direction TB
      SP["Системный промпт"]
      T["Инструменты"]
      C["Управление контекстом"]
      P["Разрешения"]
      I["Интерфейс"]
    end
    H -->|"контекст + запрос"| Mo["Модель"]
    Mo -->|"решение: вызов инструмента"| H

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

Модель решает, что делать: прочитать этот файл, запустить тот тест, исправить эту строку. Но сама она ничего исполнить не может: у неё нет доступа ни к диску, ни к терминалу, ни к сети. Всё исполнение берёт на себя харнес:

получает от модели запрос «выполни действие»;
проверяет, разрешено ли это действие;
реально выполняет его: читает файл, запускает процесс;
возвращает результат модели и ждёт следующего решения.

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

Из этого следует неочевидный вывод: одна и та же модель в разных харнесах работает по-разному. Дайте одной модели удобный поиск по коду, аккуратно собранный контекст и право запускать тесты, и она решит задачу. Посадите её в обвязку с плохими инструментами и захламлённым контекстом, и та же модель будет спотыкаться. Когда люди сравнивают «умность» агентов, они часто сравнивают не модели, а харнесы.

Из чего состоит харнес

У всех харнесов, при внешних различиях, похожая начинка.

Системный промпт

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

Инструменты

Набор действий, доступных модели: чтение и запись файлов, поиск по проекту, запуск команд, веб-поиск. Харнес описывает модели каждый инструмент и исполняет вызовы. Качество инструментов напрямую влияет на качество работы; подробнее на странице Инструменты и их вызов.

Управление контекстом

Контекстное окно (context window) модели ограничено, а за долгую сессию накапливаются десятки прочитанных файлов и результатов команд. Харнес решает, что держать в контексте, что сжать, что выбросить, когда подгрузить память проекта. Это одна из самых сложных и самых важных его функций: от неё зависит, «помнит» ли агент, что делал полчаса назад.

Разрешения

Правила о том, что агент может делать сам, а что только с вашего подтверждения. Какие команды запускать свободно, какие файлы не трогать, можно ли ходить в сеть. Хороший харнес позволяет настраивать это гибко: от «спрашивай обо всём» до «работай сам в этой папке».

Интерфейс

То, как вы взаимодействуете с агентом: терминал, панель в редакторе, веб-страница. И то, как агент показывает свою работу: diff изменений, вывод команд, план действий.

Форм-факторы харнесов

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

CLI-агенты (Claude Code, Codex CLI, OpenCode) работают в терминале. Вы пишете задачу текстом, агент действует в текущем каталоге. Сильные стороны: работает с любым редактором, легко встраивается в скрипты и CI, полный доступ к привычным инструментам командной строки.

IDE-агенты (Cursor, агентные режимы в VS Code и JetBrains) встроены в редактор. Агент видит открытые файлы, а вы видите его правки прямо в коде, как обычный diff. Удобно, когда вы хотите оставаться в редакторе и плотно контролировать каждое изменение.

Облачные и фоновые агенты работают на сервере, без вашего присмотра. Типичный сценарий: вы описываете задачу в трекере или чате, агент в изолированной среде клонирует репозиторий, делает работу и открывает pull request. Подходит для параллельной работы над несколькими задачами и для задач «на подумать в фоне».

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

Почему выбор харнеса важен не меньше выбора модели

Модели у лидеров рынка близки по возможностям, и разрыв сокращается с каждым релизом. А вот харнесы различаются заметно:

Качество инструментов и контекста. Насколько хорошо агент ищет по большому репозиторию, как переживает длинные сессии, сколько лишнего таскает в контексте.
Расширяемость. Поддержка памяти проекта, скилов, MCP-серверов, субагентов, хуков и остального, о чём рассказывают следующие страницы этого раздела.
Модель разрешений и безопасность. Насколько тонко можно ограничить агента и насколько безопасно давать ему автономию.
Привязка к модели. Одни харнесы работают только с моделями своего вендора, другие позволяют выбирать любую.
Встраивание в процессы. Работа в CI, code review, интеграция с трекером, то есть всё, что превращает личный инструмент в командный.

На практике это означает: столкнувшись с тем, что «агент тупит», не спешите винить модель. Возможно, дело в обвязке: в том, какой контекст она собрала и какие инструменты дала. Сравнение конкретных харнесов вы найдёте в разделе Обзор харнесов.

Что дальше

Инструменты и их вызов: как устроены «руки» агента, вызов инструментов и цикл вокруг него.
Обзор харнесов: сравнение конкретных харнесов.

Автор учебника — Шахматов Алексей