Хватит лечить тупость LLM промптами: Google показал, как должны развиваться AI-агенты

Google Research выкатили репозиторий фреймворка Harness² . Веса модели остаются замороженными. Вместо изменения весов система на лету рекурсивно переписывает и оптимизирует собственную «обвязку» (harness) — тулы, системные промпты, guardrails, скиллы и пайплайны. Без подглядывания в правильные ответы и без участия человека. Результат: до +11.8% на юридическом бенчмарке LAB и до +11.5% на WorkBuddy-Bench чисто за счет софта вокруг замороженной модели.

Что вообще такое харнесс? Это каркас вокруг LLM: системный промпт, память, инструменты, guardrails, оркестрация. Большинство разработчиков до сих пор действуют примитивно: наваливают в system_prompt простыню текста на 10 тысяч токенов в надежде, что модель «проникнется». Не проникнется.

В репозитории инженеры разложили харнесс на 8 модулей (от промпта до middleware-хуков и Python-хелперов) и зафиксировали подход:

🔵 Always-on промпты — это дорогое зло Каждое лишнее слово в системном промпте сидит в контексте на каждом шаге агента и напрямую жрет бюджет генерации. Главная причина провала агентов на длинных рабочих задачах банальна: модель сожгла лимит токенов на рассуждения о собственных правилах и тупо не успела записать итоговый файл. Поэтому приоритет такой: если знание можно убрать из постоянного промпта в on-demand навык (skill), который подгружается только по триггеру — выкидывайте его из промпта немедленно.

🔵 Детерминированный код бьет генерацию Если агент на прогонах регулярно лажает в расчете сложной таблицы или парсинге специфичного формата, правильный шаг — не писать капсом «СЧИТАЙ ВНИМАТЕЛЬНЕЕ». Правильный шаг — автоматически нагенерировать вспомогательный скрипт scripts/calculate.py и положить в репозиторий, заставив модель дергать его через Bash. Детерминированный скрипт всегда надежнее стохастического попугая.

🔵 Хуки внутри тул-лупа Модель можно сто раз попросить в промпте: «перед завершением открой файл и проверь, что он не пустой». Она проигнорирует. Единственный рабочий способ заставить агента проверять результат — перехватить событие на уровне рантайма (через плагины или hooks.json), физически распарсить сгенерированный xlsx/docx независимым ридером и вернуть модели ошибку в execution loop, если там мусор.

Архитектура проекта построена на двух контурах адаптации:

1️⃣ Task-level recursion (контур задачи) Когда агент получает сложный таск, запускается цикл Propose–Probe–Compose: 🔘 Базовый агент делает несколько прогонов. 🔘 Модель-импрувер анализирует полные трейсы (траектории) и выдвигает гипотезы: отдельно по процедуре работы (инвариантная часть) и отдельно по предметной области (доменная часть). 🔘 Кандидаты прогоняются в среде, проверяются на регрессии. 🔘 Компоновщик собирает финальный harness из контрастов поведения. Причем выбор финального решения идет вслепую — валидатор сравнивает артефакты работы кандидатов, не видя эталонных ответов и тестов.

2️⃣ Harnessing-level recursion (контур опыта) Если harness для задачи оказался удачным, запускается рефлексия: система формулирует transferable lesson (паттерн ситуации, выученный урок и доказательство из трейса) и сохраняет его в библиотеку домена.

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

↗️ Авторы прогнали подход на связках с OpenCode и Codex CLI на бенчмарках JobBench, Harvey LAB (юриспруденция) и WorkBuddy-Bench. Gemini 3.5 Flash и GLM-5 из коробки получают до +11.8% к all-pass рейту в legal-задачах и до +11.5 пунктов в офисных сценариях.

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

Ссылка на репозиторий: github.com/google-research/harness2