HarnessDev: LLM створюють власну інфраструктуру
ByteDance та група університетів запустили HarnessDev — фреймворк, який дозволяє великим мовним моделям (LLM) писати власні «операційні системи агентів», що називаються Agent Harnesses. Команда надає LLM невеликий стартовий набір, а далі дозволяє моделі самостійно розробляти решту, демонструючи, як ШІ може будувати рівень керування, що забезпечує роботу власних циклів використання інструментів, кроки верифікації та обробку помилок — без необхідності людині вводити кожен рядок вручну.
Чому самостійно побудована оболонка має значення
ШІ-агенти еволюціонували від асистентів з одним промптом до багатоетапних виконавців, які викликають API, роблять запити до баз даних і поєднують результати. Досі розробники вручну створювали код оркестрації, який вказує моделі, коли викликати інструмент пошуку, як зберігати проміжні стани та як перевіряти кінцеву відповідь. HarnessDev змінює цю модель: seed harness (початкова оболонка) надає лише необхідний каркас — базові функції для циклів, вибору інструментів і відстеження стану — а LLM розширює його до повноцінного середовища виконання (runtime).
У бенчмарку, наведеному в статті, модель створила 18 окремих оболонок, додавши понад 17 000 рядків коду до початкового набору. Кожна оболонка керувала повним життєвим циклом завдання: виконувала цикли, обирала потрібний інструмент, підтримувала контекст, відстежувала стан, перевіряла результати та відновлювалася після помилок.
Приховані витрати, виявлені дослідженням
Цифри виглядають вражаюче, але автори попереджають, що чиста реалізація не дорівнює практичному застосуванню.
- Невикористані компоненти — значна частина згенерованого коду ніколи не запускалася під час фактичного виконання завдань. LLM писала функції, які агент ніколи не викликав, що роздувало базу коду без створення реальної цінності.
- Прив'язка до моделі — оболонки мали тенденцію налаштовуватися під конкретну LLM, яка їх створила. Коли ту саму оболонку передавали іншій моделі, продуктивність помітно падала, що свідчить про те, що автозгенерована логіка керування вбирає в себе специфічні особливості конкретної моделі.
- Прогалини у верифікації — одна тестова оболонка показала рівень успішності 99% (99 із 100 запусків), але була правильною лише у 48% випадків. Без надійної верифікації агент може впевнено надавати неправильні відповіді.
- Надмірне споживання токенів — використання токенів (показник витрат на обчислення) суттєво різнилося. Одній оболонці знадобилося у сім разів більше токенів, ніж іншій, для досягнення того самого результату, що викликає занепокоєння щодо масштабованості в умовах реальної експлуатації.
Ці висновки підкреслюють необхідність дисциплінованого проєктування, навіть коли код створюється LLM.
Що варто враховувати розробникам
- Ставтеся до проєктування оболонки як до архітектури — не покладайтеся на те, що модель «просто працюватиме». Визначте чіткі модулі для керування циклами, вибору інструментів, обробки станів і верифікації перед тим, як дозволити LLM заповнювати їх.
- Створюйте надійну систему верифікації — впроваджуйте явні перевірки, які порівнюють твердження агента з еталонними даними (ground truth) або з іншою моделлю. Результат дослідження (48% точності при 99% самостійно заявленому рівні успішності) показує, що верифікація не може бути другорядною справою.
- Слідкуйте за бюджетом токенів — складніші оболонки можуть призвести до різкого зростання кількості токенів. Профілюйте різні варіанти оболонок на ранніх етапах, щоб уникнути прихованого вибуху витрат.
- Тестуйте на різних моделях — запускайте одну й ту саму оболонку з різними бекендами LLM. Якщо продуктивність різко падає, вам може знадобитися більш модельно-незалежний дизайн або окремі оболонки для кожної моделі.
Підсумок: HarnessDev доводить, що LLM можуть створювати власний код керування, подібний до операційної системи.