Дякую вам за відповіді!
Бачу, що багато у нас ✨і це прекрасно :)

Тепер щодо різниці в результатах.
Найчастіше вона повʼязана лише з однією річчю – context engineering.
Контекст – це все, що модель має в своїй памʼяті.
Памʼять моделі простягається всього лише на її контексте вікно, а сама модель stateless.
Вона насправді не памʼятає, що було в минулій сесії.

"Але як так? Мій чат гопоти памʼятає моє імʼя, ким я працюю, та що роблю!" – можете справедливо обуритись ви.

Щоб модель це памʼятала, існує система memory – тобто памʼяті – яка при запуску нового чату або сесії завантажує в контексте вікно моделі важливу інформацію.

Крім памʼяті, існують ще скіли, тули, guardrails, feedback loops та купа всього, що дозволяє вам досягти справді класних результатів з тими самими моделями, з якими хтось з людей заледве може зробити простий звіт.

І все це разом і називається harness.

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

І в цій аналогії модель – це сильна тварина, яка тягне вашу роботу (плуга або воза), а ви нею керуєте за допомогою збруї. Основна мета збруї – зробити керування простішим та застосовувати силу до задачі правильно.

Ви вже точно бачили різні AI harness, зокрема Codex, Claude Code та OpenClaw (памʼятаєте такий ще?). Але з коробки ви отримуєте їх недоналаштованими.

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

Всім привіт, продовжую тему AI harness.

Вона робить 5 важливих речей:
1. Дозволяє моделі працювати циклічно до досягнення бажаної цілі замість перепитувати про наступний крок після виконання попереднього (agent loop)
2. Дає моделям інструменти для перегляду та створення файлів, пошуку інформації та запуску коду (tools)
3. Управляє памʼятью завдяки якій модель в довгому циклі знає, що відбулось на його початку (memory).
4. Задає правила роботи для моделі щоб вона точно знала, які дії може робити самостійно, а які має затвердити з користувачем (guardrails).
5. Покращує роботу моделі за рахунок зворотнього звʼязку (feedback loop).

Чому зараз тема AI harness летить?
По-перше, harness не залежить від моделі і може працювати з ЛЛМками різних компаній, включно з опен сорсними.
По-друге, ви можете брати гроші за виконану роботу. Створення AI harness вимагає доменних знань та розуміння принципів роботи сучасних моделей. Це не той скілсет, який можна здобути за пару місяців на курсах.
По-третє, harness практично гарантує результат в часто повторюваних задачах. Це і є та сама економія часу на агентах, про яку ми мріємо.
І по-четверте, що дуже важливо – лаби не будуть створювати harness для кожної на світі задачі. Тож зробивши свою нішеву розробку для чогось дуже конкретного та чітко визначеного або освоївши навичку створювати harness для компаній під їхні задачі, ви будете в сильній позиції відносно подальшого розвитку АІ.
Бо з кожною новою генерацією моделей ваш harness буде тільки крутішим.

І наостанок: ринок величезний, бо, як я вже казала вище, ви можете брати гроші за результат – сформований звіт, заповнений документ, створений артефакт, тощо. Потенційно йдеться про трильйони доларів США. Мати навіть малесенький шматочок від цього – ідея чудова.

Всім привіт! Сьогодні поговоримо про основні елементи AI harness в аналогії зі збруєю для більшої наглядності (це востаннє, обіцяю). Зараз буде багато повідомлень, по одному на кожен елемент щоб вже закрити цю тему. І на цьому з нудними теоретичними штуками закінчимо – будемо переходити до практики.

Звісно ж картинка для більшої наглядності!

Instructions (the bit)

Для чого це: щоб задати моделі роль і межі дозволеного перед першим запитом.

Чому важливо: це фундамент всієї системи — розмита інструкція призводить до нечіткої та непослідовної поведінки, хоч би яка крута була модель.

Як створити: попросіть вашого агента вивести свою системну інструкцію. Якщо показати нема чого — значить, вам ще треба її написати.

Як підтримувати: перевіряйте інструкцію щоразу, коли міняєте модель — інструкція, підігнана під одну версію, може бути неактуальною для іншої. Зокрема, при випуску пʼятої генерації моделей Anthropic обрізав дуже частину системної інструкції (можете порівняти тут).

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

Context (the blinders)

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

Чому важливо: модель з неповною або неправильною інформацією відповідає впевнено і неправильно. Зазвичай саме це, а не "тупість моделі", і є справжньою причиною поганих відповідей.

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

Як підтримувати: періодично перевіряйте, чи інформація, з якою агент працює, все ще актуальна. Також повідомте моделі про те, де її training cut-off – дані до якого моменту є в тренувальній вибірці (ця інформації є в картці моделі та й самі моделі це знають). Переконайтесь, що ваша інструкція має пункт про примусовий пошук недавньої інформації.

Основна проблема: ви згодовуєте моделі все підряд замість релевантних даних, і не відстежуєте, звідки конкретна відповідь взялась.

Tools (the collar and hames)

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

Чому важливо: це різниця між чатом і агентом — автоматизація.

Як створити: для кожної дії, яку хочете доручити моделі, спитайте себе чи має модель для цього підходящі інструменти. Також подумайте про наслідки неправильного виконання цієї дії або про повторне виконання. Якщо наслідки або повторне випадкове виконання є руйнівними (видалення файлу без можливості відновлення або надсилання потенційно стрьомного листа клієнтові) – подумайте, чи воно вам справді треба х) Іноді автоматизації достатньо створити драфт.

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

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

Memory (the horse itself kinda)

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

Чому важливо: без памʼяті кожна розмова стартує з нуля. А з надлишком неактуальних "спогадів" стара і застаріла інформація починає паскудити нові відповіді.

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

Як підтримувати: періодично просіть модель показувати всі свої збережені файлики "спогадів" та не соромтесь їх редагувати.

Основна проблема: модель нічого не забуває допоки ви їй не скажете або не "зітрете спогади" вручну – тут у нас вайби людей в чорному, – тож стара та суперечлива інформація постійно вилазить назовні.

Filesystem / workspace (the cart and its load)

Для чого це: щоб агент міг зберігати проміжну роботу і результати окремо від самої розмови.

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

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

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

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

Sandbox / execution environment (the road versus the open field)

Для чого це: щоб визначити межі, в яких агентові дозволено реально діяти — жорстко контрольований простір (дорога – сендбокс) проти вільнішого (поле – вся файлова система або цілий проєкт).

Чому важливо: це і є ваш реальний контроль ризику. Чим вужчі межі, тим менше шкоди від потенційної помилки.

Як створити: спитайте себе напряму — якщо тут станеться помилка, що найгірше вона може зачепити? Ця відповідь покаже, де вам краще продовжувати роботу. За дефолтом деякі harness працюють саме в сендбоксі і вам їх треба буде "випускати в поле", а інші навпаки треба контейнувати за потреби.

Як підтримувати: переглядайте ці межі з ростом можливостей агента — permissions мають зазвичай тільки зростають та рідко звужуються назад.

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

Control loop (the reins)

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

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

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

Як підтримувати: стежте, скільки кроків у середньому займає задача — поступове зростання зазвичай означає, що щось працює не вірно. Це можна відслідковувати автоматично або запитуючи у агента щодо кількості кроків (під кроком зазвичай мається на увазі використання тулів та скілів).

Основна проблема: немає ліміту кроків на виконання задачі або задача поставлена абстрактно без чітких критеріїв виконання.

Guardrails / permissions (the breeching and check chain)

Для чого це: щоб жорстко обмежити те, що агент може робити. Напряму повʼязано з роботою "у відкритому полі" або "на дорозі".

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

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

Як підтримувати: регулярно переглядайте доступи та за потреби забирайте раніше надані — завжди фоловте модель надання найменшої можливої кількості пермішенів.

Основна проблема: доступ дають "про всяк випадок на майбутнє щоб агент на заєб@в" замість лише того, що потрібно для поточних задач.

І останнє, але менше з тим важливе:

Feedback loop / observability (the tracks in the road, and rein tension)

Для чого це: щоб дізнатись, що агент насправді зробив і де помилився — і в моменті, і постфактум.

Чому важливо: без цього ви дізнаєтесь про помилку запізно (в найгіршому випадку через цю помилку станеться щось незворотнє — скажімо, утече ваш АРІ ключ абощо).

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

Як підтримувати: створіть та постійно попвнюйте evals. Це найкращій шлях перевірки агента на відомих задачах. Якщо на таку фундаментальну роботу немає часу, то є варіант простіше: робіть постмортем знайдених помилок та затупів агента та просіть його покращити системну інструкцію, скіли, оновити памʼять на основі цього.

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

Знаю що вам було складно, але ми прорвались крізь всі основні елементи AI harness!
Оскільки у мене тут з вами час обмежений, я зможу розказати вам детальніше лише про три елементи зі списка (тут 9 елементів + є ще скіли, отже 10).

Тож в наступному пості голосування, де можливо обрати багато варіантів – голосуйте за те, що важливіше для вас!

We have our winners!
У нас є skills, agent loop та feedback loop.
Розкажу про них сьогодні пізніше, бо щось якось робота навалилась сьогодні, тож не перемикайтесь :)

Почну зі скілів. Скіл для АІ агента – це покроковий рецепт виконання певної задачі.
Без аналогій я не можу, тому тут знов у мене буде одна, яку ви вже могли зустрічати раніше: скіл схожий на рецепт з кулінарної книги.

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

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

Зокрема, у мене є плагін для роботи з ад хок запитами клієнтів. Він складається з наступних взаємоповʼязаних скілів:
1. client call processor – шукає в пошті нотатки Gemini після дзвінку, читає їх та сумаризує в короткий документ з основними поінтами, на які я маю звернути увагу як керівниця солюшен тіми.
2. integration research – шукає АРІ документацію та визначає складність інтеграції з тима сорсами даних, з якими у Coupler.io ще немає нативної інтеграції, за чітко визначеними критеріями.
3. dashboard mockup – на основі вимог клієнта створює ілюстративні мокапи дашбордів для узгодження з клієнтами.
4. service estimate – створює чернетки естімейтів для клієнтської роботи. Цей скіл жортско слідує фреймворку, який ми використовуємо для роботи з клієнтами.
5. estimate pdf – з чернетки створює красиву пдфку в нашому фірмовому стилі щоб надіслати клієнтові.
6. client docs – описує структуру та нюанси рішення, яке ми зробили для клієнта, та створює інтерактивний документ щоб клієнт міг сам підтримувати нашу розробку.

Це закриває повний цикл всієї роботи над проєктом, а проміжну комунікацію я здійснюю самостійно умисно (цей human touch ✨