Разработчик на r/openclaw описывает смену своей ментальной модели при работе с мульти-агентными командами в OpenClaw. Изначальное отношение к суб-агентам как к младшим сотрудникам с именами, историями и ожиданием наличия памяти привело к неделям путаницы и сломанных рабочих процессов.

Аналогия с функцией

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

• Суб-агенты — это вызовы функций без состояния, а не постоянные члены команды
• Это специализированные инструменты, а не младшие версии разработчика
• Они работают по принципу чистый ввод → вывод, не запоминая контекст
• Они возвращают значения вызывающей стороне, а не общаются друг с другом

В источнике приведены примеры кода, противопоставляющие неправильный и правильный подходы:

# НЕПРАВИЛЬНО: Отношение к суб-агенту как к постоянному объекту
frank = Agent("Frank")
frank.build_feature()
frank.fix_it() # Предполагается, что Фрэнк помнит

ПРАВИЛЬНО: Отношение к суб-агенту как к вызову функции
result = frank_task(
  instructions="Создать страницу входа",
  context={"requirements": reqs, "design": mockup}
)
frank_task выполняется, возвращает вывод, завершается

Практические последствия

Эта смена ментальной модели имеет несколько конкретных последствий:

1. SOUL.md как строка документации функции: Вместо профилей личности SOUL.md становится спецификацией:

# frank_task()
Назначение: Создание функций Next.js
Входные данные: требования (dict), дизайн (опционально)
Выходные данные: {код, тесты, заметки}
Ограничения: Без внешних вызовов API без одобрения

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

# НЕПРАВИЛЬНО
frank_fix("исправить баг") # создание, попытка, завершение
frank_fix("все еще сломан") # новое создание, нет контекста

ПРАВИЛЬНО
result = frank_fix({
  "code": previous_output,
  "issues": ["сбой валидации входа", "сломан CSS для мобильных"],
  "test_cases": failing_tests
}) # Полный контекст в параметрах

3. Координатор как основная программа: Разработчик становится функцией-оркестратором, а не менеджером команды:

def build_feature(spec):

Вызов функций по порядку
  code = frank_build(spec)
  tests = quinn_audit(code)
  if tests["passed"]:
    return deploy(code)
  else:
    # Итерация с явным контекстом
    fixed = frank_fix({
      "code": code,
      "failures": tests["failures"]
    })
    return deploy(fixed)

Параллели с дизайном ПО

Этот подход соответствует устоявшимся принципам проектирования ПО:

• Единственная ответственность: Каждый суб-агент делает одно дело
• Чистые функции: Одинаковый ввод → одинаковый вывод
• Модульное тестирование: Тестировать вывод каждого суб-агента независимо
• Композируемость: Соединять суб-агенты как quinn_test(frank_code(spec))
• Отсутствие состояния: Нет скрытых зависимостей

Разработчик отмечает, что ценность не в «больше агентов = умнее», а в «специализированные функции = чище архитектура».

Результаты после смены

После принятия этой модели разработчик создал:

• Базу данных из 11 249 тренажерных залов за 2 недели
• 5 специализированных агентов (а не 5 универсалов)
• CRM с рабочими процессами андеррайтинга
• Ежедневное взаимодействие с Moltbook

Все с использованием суб-агентов без состояния и координатора, который поддерживает контекст.