Harness-інженерія: що це таке і як вона працює

Що таке інженерія harness

Інженерія harness — це робота зі створення harness для інструмента ШІ, тобто всіх частин інструмента, крім моделі ШІ.

Модель — це система ШІ, навчена на великих обсягах тексту, щоб уміти читати й писати тексти природною мовою. Приклади моделей ШІ — GPT від OpenAI, Claude від Anthropic або Gemini від Google.

Сама по собі модель може лише приймати текст (а іноді зображення чи аудіо) і писати текст у відповідь. Вона не пам’ятає попередніх розмов, не може шукати актуальну інформацію чи запускати код. Тому їй потрібен harness, який керує тим, яку інформацію отримує модель, якими застосунками вона може користуватися, що їй дозволено робити і як перевіряється її робота.

Навіть простому чат-асистенту потрібен harness. Модель забуває кожен обмін репліками, щойно відповість, тому harness зберігає запис розмови. Якщо хтось запитує про Париж, а потім уточнює: «Яке його населення?», harness надсилає моделі обидва запитання разом. Саме так модель розуміє, що «його» означає Париж.

Інженерія harness — одна з причин, чому два інструменти на основі тієї самої моделі можуть працювати настільки по-різному. Наприклад, в одному незалежному тесті дослідники залишили ту саму модель (GPT5) і змінили лише harness, а результат моделі в тесті з програмування змінився аж на 11%.

Розробники моделей ШІ, як-от Anthropic і OpenAI, створюють harness для власних продуктів ШІ, таких як Claude Code і Codex. А компанії, що створюють продукти ШІ, проєктують harness для базових моделей, які вони обирають. Частину harness формують і люди, які користуються інструментами ШІ. Багато інструментів дають змогу додавати постійні інструкції, підключати застосунки й вибирати, які дії потребують їхнього схвалення, перш ніж інструмент їх виконає.

Інженерія harness для агентів ШІ

Кожен інструмент ШІ має harness, але інженерія harness стає особливо важливою під час роботи з агентами ШІ. Агенти самостійно виконують багатокрокові завдання, як-от дослідження конкурентів і внесення результатів у таблицю, а harness виконує кожен крок. Тож якщо harness помилиться, наприклад візьме торішні ціни, це вплине й на решту кроків.

Більшість harness для агентів мають шість основних частин:

1. Цикл агента

Розгорнути

Цикл агента — це код у harness, який крок за кроком просуває завдання вперед.

Модель ШІ визначає наступний крок, потрібний для виконання завдання, і пише виклик інструмента: короткий запит, у якому вказано інструмент у harness, наприклад вебпошук, і що цей інструмент має зробити.

Harness помічає запит, виконує пошук і додає результати до того, що бачить модель. Модель читає їх і вирішує, що робити далі.

2. Керування контекстом

Модель здобуває загальні знання під час навчання, але ці знання обмежені датою його завершення. Вони не містять нічого, що стосується конкретного завдання, як-от файлів компанії, сьогоднішніх новин чи того, що було сказано раніше в розмові.

Для всього цього модель покладається на своє контекстне вікно — текст, який harness передає їй перед кожною відповіддю: її інструкції, запит, розмову до цього моменту й результати пошуку.

Вікно вміщує лише обмежений обсяг тексту. І навіть до того, як вікно заповниться, моделі іноді пропускають інформацію, заховану посередині довгих вхідних даних.

Тому harness бере на себе керування контекстом і відбирає лише ту інформацію, яка потрібна на кожному кроці. Наприклад, якщо завдання — порівняти ціни п’яти конкурентів, harness може додати сторінку з цінами кожної компанії, а не весь її вебсайт. У довгих завданнях harness також може замінити детальний запис попередніх кроків коротким підсумком, щоб модель пам’ятала, що вже зроблено, а ця історія не заповнювала вікно.

3. Інструменти

Інструменти — це код, який виконує дії, про які просить модель. Кожен інструмент відповідає за один тип дій, як-от пошук в інтернеті, відкриття й читання вебсторінки, запуск коду чи редагування файлу. Коли модель пише виклик інструмента, harness передає його потрібному інструменту й повертає результат.

Багато harness також містять конектори — інструменти, що пов’язують агента з певним застосунком, як-от електронною поштою, календарем чи спільним диском, використовуючи доступ, який надала людина. Наприклад, завдяки конектору календаря агент може перевірити, чи вільна людина, перш ніж запропонувати час зустрічі.

4. Пам’ять

Пам’ять — це збережена інформація, яка переноситься з одного сеансу в наступний. Під час сеансу harness зберігає короткі нотатки, наприклад про вподобання людини чи стан проєкту. На початку наступного сеансу harness додає ці нотатки до контекстного вікна, тож модель читає їх, перш ніж прочитати новий запит. Саме так агент може, наприклад, продовжити щотижневий звіт з того місця, де зупинився, а не починати все спочатку.

5. Дозволи

Дозволи — це правила про те, до чого агент має доступ і що він може робити. Правила доступу визначають, які файли, застосунки чи вебсайти він може відкривати. Правила схвалення визначають, які дії мають чекати на підтвердження людини, як-от надсилання повідомлення чи здійснення покупки.

Компанія, що створює агента, задає частину цих правил у коді harness. Потім адміністратори організації можуть додати власні, а окремі користувачі — вибрати, наприклад, які облікові записи підключити.

6. Перевірка

Перевірка — це код, який перевіряє роботу агента, перш ніж вона потрапить до людини. Для цього використовуються два типи перевірок:

• Фіксовані правила — конкретні тести, результат яких (пройдено чи не пройдено) щоразу однаковий, наприклад перевірка того, що кожна цифра у звіті трапляється в документі, який агент справді прочитав.
• Рецензія від іншої моделі ШІ, яка читає роботу й оцінює її. Така модель може виявити проблеми, які важко перетворити на правило, як-от підсумок, у якому пропущено важливий момент.

Жодна окрема перевірка не виявляє всього, тому в harness зазвичай поєднують обидва типи. Коли перевірка знаходить проблему, harness додає її опис до контекстного вікна моделі й відправляє завдання назад у цикл агента. Модель виправляє проблему й пробує знову, тож багато помилок виправляються ще до того, як користувач побачить результат.

Приклади інженерії harness

Підготовка до зустрічі з клієнтом

Завдання: менеджер з роботи з клієнтами просить агента підготувати до завтрашньої зустрічі з клієнтом довідку з відкритими питаннями та чернеткою порядку денного.

Що робить harness:

• Через конектор електронної пошти агент шукає в поштовій скриньці менеджера листування з цим клієнтом.
• Дозволи дають йому змогу читати листи, але не надсилати їх.
• Керування контекстом передає моделі лише листування з цим клієнтом за останні три місяці, а не всю поштову скриньку.
• Цикл агента проходить кілька раундів пошуку й читання, а модель групує знайдене за відкритими питаннями.
• Потім перевірка підтверджує, що кожне питання в довідці посилається на справжній лист.

Можливий результат: менеджер отримує односторінкову довідку, у якій кожен пункт можна простежити до листа-джерела.

Оновлення щомісячного звіту про продажі

Завдання: керівник операційного відділу просить агента оновити щомісячний звіт про продажі, додавши цифри за цей місяць.

Що робить harness:

• Пам’ять завантажує нотатки із сеансу минулого місяця, зокрема формат звіту й прохання керівника округлювати цифри до тисяч.
• Інструмент для роботи з файлами відкриває таблицю продажів на спільному диску команди.
• Дозволи дають агентові змогу редагувати чернетку звіту, але не вихідну таблицю, тож початкові цифри неможливо випадково змінити.
• Перевірка підтверджує, що підсумкові суми у звіті збігаються з таблицею.

Можливий результат: звіт надходить у тому самому форматі, що й минулого місяця, і користувачеві не доводиться пояснювати його знову.

Сортування спільної поштової скриньки

Завдання: команда підтримки просить агента відсортувати ранкові вхідні запити за темами й підготувати чернетки відповідей на типові з них.

Що робить harness:

• Цикл агента опрацьовує поштову скриньку лист за листом.
• Для кожного листа модель вибирає мітку теми, а harness застосовує її через конектор електронної пошти.
• На початку завдання harness додає до контекстного вікна затверджені командою шаблони відповідей як орієнтири, тож модель складає кожну чернетку на основі шаблону.
• Правило схвалення зберігає кожну відповідь як чернетку, доки хтось із команди не перегляне й не надішле її.

Можливий результат: команда починає день із відсортованими запитами та відповідями, що чекають на перегляд.

Виправлення помилки на вебсайті

Завдання: розробник просить агента для програмування виправити помилку, через яку не працює кнопка оформлення замовлення.

Що робить harness:

• Агент працює в пісочниці — ізольованій копії коду, де його зміни не можуть вплинути на робочий вебсайт.
• Інструмент для роботи з кодом дає моделі змогу читати й редагувати файли.
• Після кожної зміни перевірка запускає автоматизовані тести проєкту.
• Усі збої передаються моделі як нова інформація.

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

Інженерія harness, інженерія промптів та інженерія контексту: у чому різниця

Інженерія промптів — це робота зі створення й оптимізації окремого запиту. Інженерія контексту — це робота з керування всім, що бачить модель. Інженерія harness — це процес проєктування й удосконалення всієї системи, у межах якої працює модель.

Як користувачі можуть впливати на harness ШІ

Більшу частину harness агента створює компанія, що розробляє агента, але багато продуктів ШІ дають користувачам змогу налаштовувати його частину за допомогою таких параметрів, як власні інструкції, підключені застосунки та схвалення.

Користувачі можуть формувати harness агента й покращувати результати його роботи чотирма способами:

1. Постійні інструкції

Постійні інструкції — це нотатки, які людина пише один раз, щоб harness міг додавати їх до контекстного вікна на початку кожного завдання. Їх варто налаштувати для всього, що інакше довелося б повторювати в запиті за запитом: хто ця людина і чим вона займається, як їй подобається, щоб були написані тексти, чи які правила діють для регулярного завдання, як-от щомісячного звіту для клієнта.

Багато продуктів ШІ пропонують постійні інструкції на двох рівнях. Інструкції для всього облікового запису підходять для того, що стосується всієї роботи, як-от вподобань щодо правопису. Інструкції проєкту підходять для окремого клієнта чи робочого процесу, тож настанови для одного не переносяться на інший.

Постійні інструкції однаково працюють і в чат-асистентах, і в агентах, але агенти залежать від них більше. У чаті людина може виправити ШІ після кожної відповіді. Агент може виконати багато кроків, перш ніж хтось побачить його роботу, тому інструкції, надані заздалегідь, — один із небагатьох способів скеровувати його в процесі.

Як писати ефективні постійні інструкції

• Почніть із короткої інструкції, наприклад: «Я менеджер з маркетингу в компанії, що розробляє програмне забезпечення. Пиши простою англійською, обмежуй підсумки 200 словами й дотримуйся американського правопису».
• Доповнюйте їх, коли ШІ помиляється. Якщо ШІ постійно округлює цифри, які команді потрібні точними, додайте про це рядок.
• Робіть інструкції конкретними: «Наводь точні цифри, ніколи не округлюй» працює краще, ніж «Будь точним».
• Тримайте список коротким і видаляйте рядки, щойно вони стають непотрібними, адже кожен рядок займає місце в контекстному вікні.

2. Підключені застосунки

Підключені застосунки пов’язують продукт ШІ з інструментами, якими людина вже користується, як-от електронною поштою, календарем чи спільним диском. Щойно застосунок підключено, ШІ може працювати з власною інформацією людини, а не лише з тим, що вставлено в чат.

Підключення варто налаштовувати, коли завдання залежить від інформації, що зберігається в цих застосунках, як-от підготовка довідки до зустрічі на основі ланцюжків листів або підсумовування документів на спільному диску.

Як безпечно підключати застосунки

• Підключайте лише ті застосунки, які потрібні для завдання, адже кожне підключення створює ще одну можливість для помилок.
• Вибирайте доступ лише для читання, якщо така можливість є. Наприклад, агентові, який готує довідки до зустрічей, потрібно читати пошту, а не надсилати листи.
• Налаштовуйте підключення для кожного проєкту окремо, якщо продукт це дозволяє. Наприклад, у Perplexity можна вибрати, які конектори використовує кожен проєкт.
• Не забувайте відключати застосунки, якими більше не користуєтеся.

3. Налаштування схвалення

Налаштування схвалення визначають, які дії мають чекати на підтвердження людини, перш ніж ШІ їх виконає. Деякі схвалення вбудовані в продукт, а деякі продукти дають змогу вибрати, які ще дії потребують схвалення.

Як налаштувати правила схвалення

• Вимагайте схвалення для дій, які неможливо скасувати, як-от надсилання повідомлення, здійснення покупки чи видалення файлу.
• Тримайте список схвалень коротким. Якщо агент просить підтвердити кожен дрібний крок, люди починають схвалювати, не читаючи.

4. Стандарти та перевірки

Більшість продуктів на основі ШІ мають певні вбудовані стандарти. Наприклад, Perplexity додає до своїх відповідей цитати, щоб кожне твердження можна було перевірити. Стандарти, які встановлює користувач, доповнюють те, чого продукт не може знати сам, як-от бажаний формат звітів команди.

Як установити стандарти для роботи ШІ

• Надайте шаблон для регулярної роботи, щоб ШІ мав сталу структуру для заповнення.
• Поділіться прикладом попередньої роботи, яка сподобалася команді, щоб ШІ міг відтворити її тон і рівень деталізації.
• Просіть додавати посилання на джерело поруч із кожною цифрою.
• Уважно перевіряйте перші результати й перетворюйте будь-які повторювані прогалини на нову постійну інструкцію.

Як Perplexity підходить до harness для агентів

Perplexity Computer працює на harness, незалежному від моделей, який об’єднує понад 20 передових моделей в одній системі. Він розбиває кожне завдання на підзавдання, передає їх субагентам (окремим агентам, кожен з яких бере на себе одну частину) і спрямовує кожну частину роботи до моделі, яка найкраще для неї підходить.

Дізнайтеся, як налаштувати інструкції, файли й конектори, з посібника з проєктів Perplexity.

Поширені запитання

Хто такий harness-інженер?

Harness-інженер проєктує та підтримує систему, яка дає змогу моделі ШІ надійно виконувати роботу. Це може означати додавання нового інструмента для агента, з’ясування, чому агент раз у раз припускається тієї самої помилки, або посилення перевірок, які він виконує перед завершенням завдання. Це не стандартна назва посади, хоча з часом це може змінитися. Зазвичай таку роботу виконують інженери-програмісти в ШІ-компаніях або в командах, що створюють агентів. У виробництві ця сама назва посади (harness engineer) означає фахівця, який проєктує кабельні джгути — зібрані в пучки дроти всередині автомобілів і машин.

Що таке harness для агента?

Під harness для агента зазвичай розуміють усе в ШІ-агенті, крім самої моделі. Це, зокрема, код, який запускає цикл агента, керує контекстом, виконує виклики інструментів, зберігає пам’ять, забезпечує дотримання дозволів і перевіряє роботу агента, перш ніж вона потрапить до людини.

Чи кожен інструмент ШІ має harness?

Так. Навіть простий чат-асистент покладається на harness, щоб відстежувати розмову, адже модель сама по собі не пам’ятає попередніх повідомлень.

Розробники також можуть використовувати модель, надсилаючи їй запити з власного програмного забезпечення через API (з’єднання, яке дає змогу одній програмі надсилати запити до іншої). У такому разі роль harness виконує власний код розробника.

Чи стане harness непотрібним із появою кращих моделей?

Кращим моделям може знадобитися менше покрокових вказівок, тож частина того, що harness робить сьогодні, може скоротитися. Але модель сама по собі лише перетворює текст на текст. Вона не має підключення до інтернету й доступу до інших застосунків. Доступ до файлів, виконання дій і забезпечення дотримання правил схвалення відбуваються в програмному забезпеченні навколо моделі, тож ця робота, найімовірніше, залишиться за harness, хоч би якими потужними ставали моделі.