Как применить open-source модель №1 для фронтенда: руководство по harness для Kimi K3

Оригинал опубликован Mr. Buzzoni в X. Перевод полной X Article.

Prompt, context, loop и graph engineering оказались частями одной и той же машины. Harness — место, где они наконец живут вместе.

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

Затем пришёл context engineering, когда стало очевидно: предложение значит меньше, чем всё, что загружено вокруг него. Этим летом настала очередь loops, а через несколько недель — graphs.

Теперь распространяется название harness engineering, и это первое название, которое объясняет все остальные.

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

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

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

1/ Семь engineerings, одна машина

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

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

2/ Анатомия harness

Самая полезная привычка, которую я приобрёл, — записывать весь harness как один config file, чтобы ничего важного не оставалось implicit:

# harness.yaml
model:        kimi-k3          # one line. everything below survives a swap
tools:        [browser, fs, shell, search]
permissions:
  write:      [./10-returns, ./20-graph, ./40-runs]
  ask_first:  [send, publish, pay, delete]
context:
  always:     [SKILL.md, CONSTRAINTS.md, SCHEMA.md]
  per_agent:  return_schema
runner:
  trigger:    cron "0 2 * * *"   # nightly, while you sleep
  stop:       40 verified nodes OR 3 passes with nothing new
  budget:     { agents: 300, minutes: 45, retries: 2 }
memory:
  graph:      ./20-graph
  aliases:    ./aliases.csv
verify:
  - script:   checks/schema.py
  - agent:    reviewer, fresh context
hooks:
  pre_tool:   hooks/pre_tool.sh
  post_run:   append 40-runs/

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

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

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

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

На диске harness — это одна папка, и у каждого engineering из таблицы есть собственный адрес внутри неё.

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

Первая строка важнее, чем кажется. Почти каждый самодельный harness в какой-то момент выращивает hand-built orchestrator, и обычно это самый хрупкий файл в папке. Со swarm fan-out становится budget line — agents: 300, а harness должен только обработать то, что вернётся.

Вторая строка важна, потому что harness — это в основном код, который модель пишет для вас: hook scripts, schema checks, небольшой dashboard, читающий 40-runs. Engine, лидирующий во frontend arena, гораздо чаще делает это правильно с первой попытки.

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

4/ Hooks: рефлексы

Hook — короткий скрипт, который harness запускает в фиксированный момент, независимо от того, что решит сделать модель. Hooks — это место, где harness перестаёт быть раскладкой папок и начинает вести себя как safety system.

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

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

Один только on_fail hook меняет экономику loop. Retry, который несёт причину провала прошлой попытки, — это correction. Без этой причины loop платит за ту же ошибку второй раз.

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

Если собрать все части вместе, harness ведёт себя как ночная смена, которая следует правилам. В 02:00 срабатывает trigger, и launch query выбирает каждый node, которому нужна работа. Swarm расходится веером: один agent на node.

Returns, не попавшие в schema, отклоняются post_tool до того, как попадут в graph, и каждый rejected node повторяется один раз с приложенной failure reason. Когда агент пытается писать вне своей папки, pre_tool останавливает его, не будя никого.

Merged nodes и typed edges попадают в 20-graph. Drafted email доходит до pre_send и ждёт. post_run добавляет record, и loop останавливается по собственному condition, спокойно укладываясь в 45-minute budget из config.

В 07:30 вы читаете один файл и принимаете два решения. Это вся утренняя стоимость запуска loop engineering и graph engineering таким образом, и в этом весь смысл harness: всё, что могло работать без вас, сработало, а немногое, что требовало вас, ждёт в одном месте.

6/ Swap Test

Самый быстрый аудит любой agent setup: поменяйте строку модели и запустите снова. Всё, что сломалось, было harness, живущим не там.

Setup, проходящий swap test, portable, а portable — это то, что стоит денег.

Что это стоит и что приносит

Компании вкладывают целые кварталы во внутренние agent platforms. Рабочий harness — это одна папка, один config file и пять коротких scripts, и он работает на подписке Kimi. В этом разрыве и есть opportunity.

Второй канал — тот, который я бы строил первым. Каждый major release перетасовывает leaderboard, один только K3 поднялся на семнадцать мест за одно обновление, и каждой команде с harness нужен человек, чья работа — запускать swap test в день релиза.

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

Prompt, context, tool, loop, graph и eval engineering оказываются компонентами одной машины, а harness engineering — это решение, где каждый из них живёт.

Поставьте модель за одну строку, permissions перед tools, а verifier вне агента. Тогда следующий скачок в leaderboard станет изменением config, а не rebuild.

И если это было полезно:

• Сохраните статью в закладки. Links меняются, новые repos появляются еженедельно, и она понадобится как reference.
• Для еженедельных deep dives в AI architecture, quant trading и agent economy следите за мной: @polydao.
• Присоединяйтесь к TG Channel: Buzzoni Notes — там я делюсь raw prompts, custom skills и alpha, которой ещё слишком рано для X.