Агенту нужен не новый промпт, а среда для работы

Харнес задаёт агенту способ думать и действовать

Харнес - это программа, которая определяет, какими инструментами пользуется модель, в каком порядке она работает и как проверяется результат. В этом смысле многие кодовые агенты похожи сильнее, чем кажется по интерфейсу: модель читает задачу, меняет файлы, запускает команды, смотрит на ошибки, делает следующую попытку.

Проблема в том, что команды часто называют агентом саму модель. Это удобное упрощение, но оно скрывает главное. Модель не получает рабочий процесс автоматически. Ей нужно явно задать, где лежит контекст, как искать данные, когда запускать проверку и что считать завершённой задачей.

Хороший агент - это не разговорчивый исполнитель, а управляемый контур поиска и проверки.

Польза здесь практическая. Вместо бесконечных уточнений в чате команда получает повторяемый процесс: результат можно проверить, ошибку можно локализовать, а удачный ход можно оставить в среде для следующей задачи. Это экономит время на ручном контроле и уменьшает число уверенных, но бесполезных ответов.

Один сильный факт о задаче ценнее огромного перебора

Многоагентный поиск умеет производить массу вариантов. Но он легко сжигает токены на решения, которые снаружи выглядят правдоподобно, а в реальной системе ломаются. В разработке GPU-ядер это видно особенно жёстко: высокая позиция на отдельном бенчмарке ещё не означает, что решение стабильно работает в сквозной цепочке.

Скорость одного участка тоже не равна скорости всей системы. Первую операцию иногда выгодно замедлить, чтобы данные остались в кэше и следующая операция отработала быстрее. Изолированная оптимизация в такой ситуации делает хуже общий результат. То же происходит в агентных контурах: отдельный подагент может отлично выполнить локальную цель, но испортить общий процесс лишним контекстом, неверным форматом или непроверенным выводом.

Человек с предметной экспертизой здесь не лишний слой. Его задача - указать ограничения, задать инварианты и отличить полезную оптимизацию от взлома метрики. Один содержательный факт о предметной области способен заменить громадный поиск вслепую.

Внешний контекст освобождает модель от роли плохой памяти

RLM строится на простой идее: не держать весь большой контекст внутри окна модели. Данные и промежуточные результаты выносятся во внешнюю среду, например в файловую систему. Агент работает с ними через Python или Bash, пишет код, вызывает подпрограммы и при необходимости создаёт рекурсивных подагентов.

Так большая незнакомая задача превращается в набор локальных задач. Модель не обязана помнить всё сразу. Она может найти нужный файл, отфильтровать данные, сохранить вывод, передать подзадачу другому исполнителю и вернуться к общей цели.

Это важнее, чем просто работа с длинными документами. Центральное хранилище даёт программируемую композицию действий. Не нужно жёстко вести модель по маршруту A, затем B, затем C. Программа может решить, кому читать данные, кто валидирует результат и какой артефакт станет входом для следующего этапа.

Рой без системы быстро превращается в дорогой шум

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

У такой схемы быстро появляется узкое место - центральный руководитель. Если он получает сотни отчётов без единого формата, то либо теряет важное, либо тратит ресурсы на чтение мусора. Масштабирование без правил координации усиливает хаос.

Полезны 3 режима работы:

Не поручайте руководителю угадывать, что ценное. Заранее задайте формат отчёта, критерий отбора и условие остановки. Для длительных простых задач надёжность важнее эффектного рассуждения.

Малой команде выгоднее менять процесс, чем соревноваться ресурсами

Небольшой группе трудно побеждать передовые лаборатории количеством вычислений и данных. Поэтому разумная ставка - искать другой контур работы: необычное представление задачи, иной выход модели, специализированный быстрый классификатор, другую среду инструментов.

Большинство идей не доживает до результата. В исследовательском подходе из 10-15 гипотез слабыми оказывается большинство. Это нормальная цена поиска, если проверка короткая и дешёвая. Ошибка начинается там, где команда месяцами улучшает первую красивую идею, не проверив альтернативы.

Для прикладной команды это означает простое правило: сначала делайте маленький стенд с ясной проверкой, затем расширяйте то, что прошло проверку. Не стройте многоагентную платформу из желания иметь многоагентную платформу. Начните с одной долгой или дорогой ручной операции, где можно увидеть качество результата.

Организовать такой рабочий контур и интерфейс для команды можно через ATLAS PANEL.