Буду честен: я пишу это, потому что устал объяснять одно и то же, и, похоже, не существует ни одного «ресурса», который нормально объяснял бы, что вообще такое harness (обвязка).
К концу этой статьи ты будешь знать всё, что когда-либо понадобится знать о том, что такое harness и как он работает.
Люди используют интерфейсы
Вообще говоря, люди не работают с компьютерами, написав код. Они используют интерфейс в той или иной форме — будь то терминал, сайт или приложение.
Теоретически человек мог бы писать уникальный код на Python или JS для каждой задачи, которую хочет решить. Но вместо того чтобы заставлять его это делать, мы даём ему доступ к этому коду через кнопки, горячие клавиши, команды и так далее.
Примеры интерфейсов: Chrome, Claude Code, приложение ChatGPT (ранее Codex)
Также стоит отметить, что люди обычно... не видят код под капотом. Человек видит только интерфейс.
LLM используют harness
По умолчанию всё, что умеет LLM, — генерировать текст. Чтобы языковая модель могла делать что-то большее, ей нужны инструменты. Большинство LLM сейчас обучены работать с такими инструментами, как "read_file" (для доступа к файлам на твоём компьютере), "edit_file" (для изменения этих файлов), "bash" (для запуска команд) и "search" (для поиска данных в интернете).
Но LLM по-прежнему отправляет только текст! Она не может нажать кнопку, как человек. Поэтому нам нужен специальный текстовый формат, который LLM будет использовать, чтобы сказать: «здесь нужно выполнить код». Допустим, мы даём LLM формат для вызова инструментов, например такой:
<read_file name="README.md">
Теперь LLM знает, что может отвечать в этом формате. Но это всё ещё просто текст, сам по себе он ничего не делает! Это как печатать на клавиатуре или двигать мышкой при выключенном компьютере.
Нужно что-то, что интерпретирует эти ответы, а затем запустит нужный код в зависимости от того, что ответила LLM.
Чтобы LLM реально что-то делала, ей нужны:
- Инструменты, которые умеют выполнять действия (read_file, edit_file, bash, search и т. д.)
- Специальный синтаксис для вызова этих инструментов через текст
- Система, которая парсит сообщение, распознаёт этот синтаксис и запускает код
- Способ передать ответ от инструмента обратно в LLM
- Список доступных инструментов с описанием того, как их использовать
Всё это и есть harness.
«Разве Claude Code — это не harness?»
В каком-то смысле да.
У Claude Code есть 2 части: интерфейс и harness.
Когда ты запускаешь "claude" в терминале, открывается TUI-интерфейс Claude. Когда переходишь на вкладку "code" в десктопном приложении Claude, открывается GUI-версия Claude Code. Ни то, ни другое не является harness.
Под капотом Claude Code использует Anthropic Agent SDK для взаимодействия с агентом. ChatGPT делает то же самое: приложение ChatGPT/Codex взаимодействует с Codex App Server (встроенным в CLI).
Я понимаю, почему люди путаются: и Claude Code, и Codex встраивают harness прямо в свои приложения.
Но тот же самый harness можно встроить и в другие приложения! Вот несколько примеров:
- Harness от Cursor используется в Grok Bot
- Anthropic Agents SDK и Codex App Server используются в T3 Code
- Pi используется в OpenClaw
Harness — это отдельный компонент, который почти никогда не показывается людям, использующим приложения.
Кому принадлежат инструменты?
Давай представим, что harness — это кухня.
На кухне много разных инструментов: кастрюли, сковородки, ножи, лопатки, блендеры и так далее.
Ни на одной кухне нет всего, что нужно каждому шеф-повару.
Хорошие harness строятся именно с этим допущением, позволяя пользователям приносить свои собственные инструменты.
Сразу уточню: большинство важных инструментов предоставляются самим harness. И Codex, и Claude Code включают множество инструментов, тогда как другие harness, например Pi, гораздо более минималистичны.
Здесь всё начинает немного запутываться, поэтому давай я нарисую ещё одну схему.
Оранжевый блок означает «то, что входит в состав Claude Code» (если точнее — agents sdk).
Можно добавить кучу кастомных инструментов: например, плагин TypeScript, чтобы дать LLM инструменты для проверки твоего кода, или плагин CUA, чтобы агенты могли управлять твоим компьютером.
Обрати внимание на границу между «плоскостью инструментов» и слоем человека/LLM. Ни человек, ни LLM не могут видеть инструменты или трогать их. Мы никак не можем узнать, существуют ли они вообще. Именно harness открывает к ним доступ — и для LLM, и для интерфейса (через который их видим мы).
MCP делает всё чуть сложнее
MCP (Model Context Protocol) — это стандарт, который упрощает доступ harness к внешним штукам. Если совсем просто: инструменты — это «выполни код здесь, чтобы сделать что-то», а MCP — это «сделай API-запрос куда-то ещё, чтобы сделать что-то».
Инструменты предоставляют код напрямую. MCP позволяют коду жить где-то в другом месте, но LLM всё равно может отправлять запросы, чтобы выполнять действия через MCP.
Самый частый сценарий использования MCP — предоставление данных твоим LLM. Хочешь, чтобы ChatGRT искал информацию в твоих письмах? MCP. Хочешь, чтобы Claude проанализировал метрики твоего сайта? MCP.
Расширения Chrome чем-то похожи на инструменты. Они могут менять работу сайта, и делают это, выполняя код на твоём компьютере внутри Chrome.
MCP больше похожи на сайты. Тебе не нужно ничего устанавливать, достаточно знать URL. Как только он у тебя есть, ты (должен) получить всю информацию, необходимую для работы :)
Если собрать всё вместе, получится примерно так:
...подожди, а что тут делает T3 Code? Сейчас объясню.
T3 Code предоставляет LLM кастомные возможности, чтобы делать то, чего harness сами по себе не умеют. Например, мы позволяем тредам в Claude Code порождать субагентов в Codex. Другие инструменты тоже так делают — посмотри Herdr, Orca и Superset в качестве примеров.
Так почему это реализовано как MCP? Неужели это просто дешёвый трюк, чтобы не делать свой собственный harness?
Вспомни цитату из начала статьи:
Инструменты предоставляют код напрямую. MCP позволяют коду жить где-то в другом месте, но LLM всё равно может отправлять запросы, чтобы выполнять действия через MCP.
В T3 Code много кода, который обеспечивает крутые фичи вроде субагентов, работающих сразу в нескольких harness. Технически мы могли бы пересобрать все самые классные функции T3 Code в виде набора плагинов для Claude Code, Codex, Antigravity, Pi, Cursor, Muse...
Или мы могли оставить весь код внутри самого T3 Code и просто выставить наружу лёгкий MCP-сервер, которым будут пользоваться LLM :)
Если вернуться к примеру с кухней, MCP — это почти как рецепты. Это способ что-то сделать, но не сама вещь.
T3 Code приносит на кухню книгу рецептов. Это вообще не меняет то, как кухня работает. Если шеф-повара решат заглянуть в нашу книгу — отлично! А могут полностью её проигнорировать, и ничего не изменится.
...так что же такое агент?
Ты представляешь, как я горжусь тем, что дошёл до этого места, не повторяя слово «агент» без определения? Это было непросто, лол.
tl;dr — агент появляется, когда ты объединяешь harness и LLM.
LLM просто генерируют текст, они ничего не делают. Harness — это просто кухни, они ничего не готовят. Сочетание LLM и harness создаёт «агента».
Разные «агенты» часто представляют собой просто разные конфигурации harness: кастомные инструменты, инструкции, MCP-серверы и так далее.
Является ли T3 Code harness?
Нет. T3 Code не будет работать, если ты не принесёшь с собой harness.
Вернёмся к примеру с кухней:
- Шеф-повар = LLM
- Кухня = harness
- T3 Code = ресторан
T3 Code — это ресторан, в который можно прийти с любой кухней, какую захочешь. У нас есть любимые рецепты, и мы даём эту книгу рецептов каждой кухне, но шеф-повар не откроет её, пока ты ему не скажешь :)
Для тех, кто хочет копнуть глубже...
Если тебе нравятся такие разборы от и до, скажи своему боссу, чтобы он оплатил курс Mega.dev, который я выпускаю на следующей неделе. Там я разбираю всё это намного глубже :)
А ещё загляни в T3 Code. Он с открытым исходным кодом, так что можешь попросить своего агента объяснить, как он работает, — и уйти в детали с головой.
