Как задействовать лучшую модель с открытым исходным кодом: Руководство по Harness для Kimi K3

Инжиниринг промптов, контекста, циклов и графов оказался лишь частями одного механизма. Харнес — это то место, где они наконец-то объединяются.

Каждый этап работы с ИИ получил свою должность. Сначала был инжиниринг промптов, когда всё мастерство сводилось к подбору нужной фразы.

Затем появился инжиниринг контекста, когда стало очевидно, что сама фраза менее важна, чем всё, что вокруг неё загружено. Этим летом в моду вошли циклы (loops), а через несколько недель — графы.

Сейчас набирает популярность термин «инжиниринг харнеса» (harness engineering), и это первое название, которое объясняет все остальные.

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

Каждая предыдущая дисциплина оказалась всего одним компонентом этой системы, созданным отдельно и получившим собственное имя.

Я начал обращать на это внимание по практической причине. Базовая модель постоянно меняется, иногда поднимаясь на семнадцать позиций в рейтинге за одно обновление, и харнес — единственная часть системы, которая остаётся вашей.

1/ Семь видов инжиниринга, один механизм

Дисциплина

На какой вопрос отвечает

Где находится в харнесе

Инжиниринг промптов

Что именно я прошу

SKILL.md, спецификация задачи, загружаемая первой

Инжиниринг контекста

Что видит модель на каждом шаге

Ассемблер контекста: ограничения, схемы, извлечённые страницы

Инжиниринг инструментов

К чему она имеет доступ и в каком формате

Определения инструментов с типизированными входными и выходными данными

Инжиниринг циклов

Что запускает процесс и что его завершает

Раннер: триггеры, условия остановки, бюджеты

Инжиниринг графов

Что она запоминает и как связаны элементы

Слой памяти: узлы, типизированные рёбра, алиасы

Инжиниринг оценки (eval)

Как отклоняется результат

Верификатор, вне контроля агента

Инжиниринг харнеса

Что связывает всё вышеперечисленное

Каркас, разрешения и хуки

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

Последний пункт наиболее важен.

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

2/ Анатомия харнеса

Самая полезная привычка, которую я перенял, — описывать весь харнес в одном конфигурационном файле, чтобы ничего важного не оставалось неявным:

1# harness.yaml
2model:        kimi-k3          # одна строка. всё ниже переживёт замену
3tools:        [browser, fs, shell, search]
4permissions:
5  write:      [./10-returns, ./20-graph, ./40-runs]
6  ask_first:  [send, publish, pay, delete]
7context:
8  always:     [SKILL.md, CONSTRAINTS.md, SCHEMA.md]
9  per_agent:  return_schema
10runner:
11  trigger:    cron "0 2 * * *"   # ночной запуск, пока вы спите
12  stop:       40 verified nodes OR 3 passes with nothing new
13  budget:     { agents: 300, minutes: 45, retries: 2 }
14memory:
15  graph:      ./20-graph
16  aliases:    ./aliases.csv
17verify:
18  - script:   checks/schema.py
19  - agent:    reviewer, fresh context
20hooks:
21  pre_tool:   hooks/pre_tool.sh
22  post_run:   append 40-runs/

Три строки в этом файле делают большую часть работы.

model: — это одна строка специально. Всё остальное написано так, чтобы ему было безразлично, что там стоит. В этом и есть вся суть переносимости.

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

verify: содержит две записи не случайно. Скрипт ничего не стоит и ловит любые механические ошибки. Ревьюер — это второй агент, который никогда не видел работу первого, потому что агент, оценивающий собственный вывод, найдёт любую причину одобрить его.

На диске харнес представляет собой одну папку, и каждый вид инжиниринга из таблицы получает в ней свой адрес.

3/ Почему Kimi K3 — это движок, который я бы туда поставил

Что нужно харнесу

Что даёт Kimi K3

Раннер, способный к массовому параллельному выполнению

Agent Swarm: до 300 агентов над одной задачей одновременно, без написания оркестратора

Код достаточно мощный, чтобы писать собственные проверки

#1 в Frontend Code Arena со счетом 1,679, опережая Fable 5 (1,631) и GPT-5.6 Sol (1,618), лидируя в 6 из 7 доменов

Движок, который улучшается под вами

С #18 до #1 за одно июльское обновление

Первая строка важнее, чем кажется. Почти каждый самодельный харнес со временем обрастает самописным оркестратором, и обычно это самый хрупкий файл в папке. Со swarm массовое выполнение становится просто строкой бюджета: agents: 300, и харнесу нужно только обработать возвращаемые результаты.

Вторая строка важна, потому что харнес — это в основном код, который модель пишет для вас: скрипты хуков, проверки схем, небольшая панель мониторинга, читающая 40-runs. Движок, лидирующий в frontend-арене, гораздо чаще делает это правильно с первой попытки.

Третья строка — это аргумент в пользу инжиниринга харнеса в одной точке данных. Когда модель взлетает на семнадцать позиций за ночь, харнес позволяет использовать этот рост в тот же день, потому что единственная строка, которую нужно изменить, — это model.

4/ Хуки: Рефлексы

Хук — это короткий скрипт, который харнес выполняет в фиксированный момент, независимо от решений модели. Именно хуки превращают харнес из структуры папок в работающую систему безопасности.

Хук

Когда срабатывает

Что делает

pre_tool

Перед любым вызовом инструмента

Блокирует записи вне списка разрешений

post_tool

После каждого возврата

Запускает проверку схемы и немедленно отклоняет некорректный вывод

pre_send

Перед отправкой чего-либо наружу

Ставит в очередь, пока вы не подтвердите

on_fail

После отклонения результата

Прикрепляет причину отказа к повторной попытке

post_run

При достижении условия остановки

Добавляет запись о запуске в 40-runs и сравнивает изменения в графе

Хук pre_tool из первой строки помещается в пять строк кода:

1# hooks/pre_tool.sh
2case "$TARGET" in
3  ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;
4  *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;
5esac

Даже один хук on_fail меняет экономику цикла. Повторная попытка, содержащая причину предыдущего сбоя, — это исправление. Без этой причины цикл платит за ту же ошибку дважды.

5/ Как выглядит ночь

Соберите все части вместе, и харнес будет вести себя как ночная смена, соблюдающая правила. В 02:00 срабатывает триггер, и стартовый запрос выбирает все узлы, требующие обработки. Swarm распределяет задачи, по одному агенту на узел.

Возвраты, не соответствующие схеме, отклоняются хуком post_tool до попадания в граф, и каждый отклоненный узел повторяет попытку один раз с прикреплённой причиной отказа. Когда один агент пытается записать данные вне своей папки, pre_tool останавливает его, никого не будя.

Объединённые узлы и типизированные рёбра попадают в 20-graph. Черновик письма достигает pre_send и ожидает. post_run добавляет запись, и цикл останавливается по своему условию, укладываясь в бюджет 45 минут из конфига.

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

6/ Тест на замену

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

Что ломается после замены

Где это пряталось

Где этому место

Формат вывода плывёт

«всегда отвечай в JSON» в промпте

Схема возврата плюс скрипт, отклоняющий всё остальное

Циклы перестают останавливаться сами

«продолжай, пока не будет исчерпывающе»

Условие остановки, основанное на счётчиках

Правки прошлой недели исчезли

История чата

CONSTRAINTS.md, загружаемый при каждом запуске

Та же компания появляется трижды

Суждение модели

aliases.csv, проверяемый перед объединением

Пишет куда не надо

Вежливая фраза в промпте

Список разрешений и хук pre_tool

Настройка, проходящая тест на замену, является переносимой, а переносимость — это то, что делает её ценной.

Сколько это стоит и сколько приносит

Компании вкладывают целые кварталы во внутренние платформы агентов. Работающий харнес — это одна папка, один конфиг и пять коротких скриптов, и он работает на подписке Kimi. Эта разница и есть возможность.

Канал

Что приносит

Что нужно сначала

Настройка харнеса для небольшой команды

Разовая оплата в четыре цифры за конфиг, хуки и верификатор под их рабочий процесс

Свой харнес, работающий по расписанию

Абонемент на дни релизов

Ежемесячная плата за проведение теста на замену при каждом крупном релизе моделей и перевод команды на лидера рынка

Клиент, чьи запуски уже логируются в 40-runs

Нишевый шаблон харнеса

Папка и yaml, упакованные для одной отрасли: исследования, рекрутинг, комплаенс

Тот же харнес, проверенный на двух разных рынках

Второй канал — тот, который я бы построил первым. Каждый крупный релиз перетасовывает рейтинг, один только K3 поднялся на семнадцать мест за одно обновление, и каждой команде с харнесом нужен человек, чья работа — проводить тест на замену в день релиза.

Краткая версия

Инжиниринг промптов, контекста, инструментов, циклов, графов и оценки оказывается компонентами одного механизма, а инжиниринг харнеса — это решение о том, где каждому из них жить.

Поставьте модель за одну строку, разрешения выше инструментов и верификатор вне контроля агента. Тогда следующий скачок в рейтинге станет изменением конфига, а не полной перестройкой.

Если вам это было полезно:

• Сохраните эту статью в закладки. Ссылки меняются, новые репозитории появляются еженедельно, вам понадобится это как справочник
• Для еженедельных глубоких разборов архитектуры ИИ, квантовой торговли и экономики агентов следите за мной: @polydao
• Присоединяйтесь к TG Channel: Buzzoni Notes — здесь я делюсь своими сырыми промптами, кастомными скиллами и альфой, которая слишком ранняя для X