Інженерія промптів, контексту, циклів і графів виявилася частинами одного й того ж механізму. Harness — це те місце, де вони нарешті об’єднуються.
Кожен етап розробки з ШІ отримував власну назву. Спершу була інженерія промптів, коли вся майстерність полягала в пошуку правильної фрази.
Потім прийшла інженерія контексту, коли стало зрозуміло, що сама фраза важить менше, ніж усе, що навколо неї завантажено. Цього літа на пік вийшли цикли (loops), а через кілька тижнів — графи.
Зараз поширюється термін «інженерія harness» (обв’язки/каркасу системи), і це перша назва, яка пояснює всі попередні.
Harness — це все, що оточує модель: інструменти, які вона може викликати, файли, які вона читає передусім, директорії, куди їй дозволено записувати, перевірки, які має проходити її результат, розклад, що її активує, та правила, що завершують процес.
Кожна дисципліна до цього моменту виявилася лише одним компонентом цієї рамки, створеним окремо й отримавшим власну назву.
Я почав звертати на це увагу з практичних міркувань. Модель під капотом постійно змінюється, іноді стрибками на сімнадцять позицій у рейтингу за одне оновлення, а harness — це єдина частина системи, яка залишається вашою.
1/ Сім інженерій, один механізм
Дисципліна
На яке питання відповідає
Де живе в harness
Інженерія промптів
Що саме я прошу
SKILL.md, специфікація завдання, що завантажується першою
Інженерія контексту
Що бачить модель на кожному кроці
Асемблер контексту: обмеження, схеми, знайдені сторінки
Інженерія інструментів
До чого вона має доступ і в якій формі
Визначення інструментів із типізованими вхідними та вихідними даними
Інженерія циклів
Що запускає процес і що його завершує
Раннер: тригери, умови зупинки, бюджети
Інженерія графів
Що вона пам’ятає і як пов’язані елементи
Шар пам’яті: вузли, типізовані ребра, псевдоніми
Інженерія оцінювання (Eval)
Як відхиляється результат
Верифікатор, поза контролем агента
Інженерія harness
Що тримає все вищезазначене разом
Каркас, права доступу та хуки
Читайте таблицю зверху вниз — це історія. Знизу вгору — це архітектура: інженерія harness — це робота з визначення місця для кожної з шести інших дисциплін, щоб жодна з них не загубилася в промпті.
Останній пункт несе найбільше навантаження.
Промпт — найпростіше місце для будь-чого, тому тось усе дрейфує: формат виводу, правило зупинки, минулотижневі виправлення, список речей, яких агент ніколи не повинен торкатися. Це чудово працює для моделі, під яку ви писали промпт, але наступна модель читає той самий абзац інакше.
2/ Анатомія Harness
Найкорисніша звичка, яку я виробив, — записувати весь harness у вигляді одного конфігураційного файлу, щоб ніщо важливе не лишалося неявним:
1# harness.yaml2model: 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_schema10runner:11 trigger: cron "0 2 * * *" # щоночі, поки ви спите12 stop: 40 verified nodes OR 3 passes with nothing new13 budget: { agents: 300, minutes: 45, retries: 2 }14memory:15 graph: ./20-graph16 aliases: ./aliases.csv17verify:18 - script: checks/schema.py19 - agent: reviewer, fresh context20hooks:21 pre_tool: hooks/pre_tool.sh22 post_run: append 40-runs/
Три рядки в цьому файлі виконують більшість роботи.
model: — це один рядок навмисно. Усе інше написано так, щоб йому було байдуже, що там стоїть. Це і є вся суть портативності.
permissions: важливіший за tools:, хоча й стоїть нижче у файлі. Запис того, що агент може змінювати, а про що мусить питати дозволу, відрізняє систему, яку можна залишити працювати на ніч, від тієї, за якою треба стежити очима.
verify: має два пункти не випадково. Скрипт нічого не коштує й ловить усе механічне. Рев’ювер — це другий агент, який ніколи не бачив роботи першого, бо агент, що оцінює власний результат, завжди знайде привід схвалити його.
На диску harness — це одна папка, і кожна інженерія з таблиці має в ній свою адресу.
3/ Чому Kimi K3 — це двигун, який я б туди поставив
Що потрібно harness
Що дає 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 за одне липневе оновлення
Перший рядок важливіший, ніж здається. Майже кожен домашній harness рано чи пізно обростає самописним оркестратором, і зазвичай це найкрихкіший файл у папці. З роєм (swarm) паралелізм стає просто рядком бюджету, agents: 300, а harness має опрацювати лише те, що повернулося.
Другий рядок важливий, бо harness — це переважно код, який модель пише для вас: скрипти хуків, перевірки схем, маленький дашборд, що читає 40-runs. Двигун, що лідирує у фронтенд-арені, значно частіше робить це правильно з першої спроби.
Третій рядок — це аргумент на користь інженерії harness в одній цифрі. Коли модель стрибоком піднімається на сімнадцять позицій за ніч, harness використовує цей стрибок того ж дня, бо єдиний рядок, який треба змінити, — це model.
4/ Хуки: Рефлекси
Хук — це короткий скрипт, який harness виконує у фіксований момент, незалежно від рішень моделі. Саме тут harness перестає бути структурою папок і починає поводитися як система безпеки.
Хук
Коли спрацьовує
Що робить
pre_tool
Перед будь-яким викликом інструменту
Блокує запис поза списком дозволів
post_tool
Після кожного повернення результату
Запускає перевірку схеми й миттєво відхиляє некоректний вивід
pre_send
Перед тим, як щось покине машину
Утримує це в черзі, доки ви не затвердите
on_fail
Після відхиленого результату
Прикріплює причину невдачі до повторної спроби
post_run
Коли настає умова зупинки
Додає запис про гон до 40-runs і порівнює зміни в графі
Хук pre_tool з першого рядка вміщується в п’ять рядків:
1# hooks/pre_tool.sh2case "$TARGET" in3 ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;4 *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;5esac
Лише хук on_fail змінює економіку циклу. Повторна спроба, що несе причину невдачі попередньої, — це корекція. Без цієї причини цикл платить за ту саму помилку вдруге.
5/ Як виглядає ніч
Складіть усі шматки разом, і harness поводитиметься як нічна зміна, що слідує правилам. О 02:00 спрацьовує тригер, і стартовий запит обирає всі вузли, що потребують роботи. Рій розгалужується, по одному агенту на вузол.
Результати, що не проходять схему, відхиляються хуком post_tool ще до потрапляння в граф, і кожен відхилений вузол повторює спробу один раз із прикріпленою причиною невдачі. Коли один агент намагається записати дані поза своєю папкою, pre_tool зупиняє його, не турбуючи нікого.
Об’єднані вузли та типізовані ребра потрапляють у 20-graph. Написаний лист доходить до pre_send і чекає. post_run додає запис, і цикл зупиняється за власною умовою, добре в межах 45-хвилинного бюджету з конфігу.
О 07:30 ви читаєте один файл і приймаєте два рішення. Це вся ранкова ціна за використання інженерії циклів і графів таким чином, і в цьому весь сенс harness: усе, що могло працювати без вас, працювало, а кілька речей, що потребували вас, чекають в одному місці.
6/ Тест на заміну
Найшвидший аудит будь-якої налагодженої системи агентів: змініть рядок моделі й запустіть знову. Те, що зламається, — це harness, що жив не на своєму місці.
Що ламається після заміни
Де це ховалося
Де воно має бути
Формат виводу дрейфує
«завжди відповідай у JSON» у промпті
Схема повернення плюс скрипт, що відхиляє все інше
Гони перестають завершуватися самостійно
«продовжуй, доки не буде ретельно»
Умова зупинки, заснована на лічильниках
Минулотижневі виправлення зникли
Історія чату
CONSTRAINTS.md, що завантажується щоразу
Та сама компанія зустрічається тричі
Судження моделі
aliases.csv, перевіряється перед об’єднанням
Пише туди, куди не слід
Ввічлива фраза в промпті
Список дозволів і хук pre_tool
Налаштування, що проходить тест на заміну, є портативним, а портативність робить його вартим грошей.
Ціна та Прибуток
Компанії вкладають цілі квартали в внутрішні платформи агентів. Працюючий harness — це одна папка, один конфігураційний файл і п’ять коротких скриптів, і він працює на підписці Kimi. Ця різниця і є можливістю.
Канал
Що приносить
Що потрібно мати спершу
Налаштування harness для малої команди
Разова плата в тисячах доларів за конфіг, хуки та верифікатор навколо їхнього воркфлоу
Власний harness, що працює за розкладом
Ретейнер на день релізу
Місячна плата за проведення тесту на заміну при кожному великому релізі моделі та переведення команди на лідера
Клієнт, чиї гони вже логируються в 40-runs
Нішева шаблон harness
Папка та yaml, упаковані для однієї галузі: дослідження, рекрутинг, комплаєнс
Той самий harness, перевірений на двох різних ринках
Другий канал — той, який я б будував першим. Кожен великий реліз перетасовує рейтинг, K3 сам по собі піднявся на сімнадцять позицій за одне оновлення, і кожній команді з harness потрібен хтось, хто буде проводити тест на заміну в день релізу.
Коротко
Інженерія промптів, контексту, інструментів, циклів, графів та оцінювання виявилися компонентами одного механізму, а інженерія harness — це рішення про те, де кожному з них жити.
Поставте модель за один рядок, права доступу — попереду інструментів, а верифікатор — поза агентом. Тоді наступний стрибок у рейтингу стане зміною конфігу, а не перебудовою системи.
І якщо вам це було корисно:
- Додайте цю статтю в закладки. Посилання змінюються, нові репозиторії з’являються щотижня, і вам це знадобиться як довідник
- Для щотижневих глибоких занурень в архітектуру ШІ, квантовий трейдинг та економіку агентів підпишіться на мене: @polydao
- Приєднуйтесь до Telegram-каналу: Buzzoni Notes — тут я ділюсь своїми сирих промптами, кастомними скілами та альфою, яка ще зарано для X
