Улучшение языковых агентов с помощью BREW

BREW (Bootstrapping expeRientially-learned Environmental knoWledge) — метод оптимизации AI-агентов через создание структурированной базы знаний из прошлых взаимодействий. Вместо дообучения весов модели (PPO, GRPO) агент накапливает опыт в виде документов на естественном языке, которые извлекает при выполнении новых задач. Результат: +10-20% точности задач, -10-15% API-вызовов, прозрачная и модульная память агента.

Агенты не помнят прошлый опыт — каждая задача начинается с нуля. BREW позволяет агенту накапливать знания из траекторий выполнения и применять их в будущем, сокращая количество шагов и повышая точность.

Средний: Нужна адаптация под свой домен. Метод требует:

• Генерации траекторий агента на обучающих задачах
• Настройки оценщиков (grader) для вашей области
• Запуска MCTS-оптимизации базы знаний
• Интеграции retrieval-механизма в агента

Готового промпта нет — это фреймворк для построения памяти агента.

LLM-агенты страдают от “амнезии” — они не накапливают опыт между сессиями. Человек после первой попытки запомнит оптимальную последовательность действий, агент — повторит те же 47 шагов вместо 6.

BREW решает это через структурированную память:

• Вместо дообучения весов (непрозрачно, дорого) — база знаний на естественном языке (прозрачно, модульно)
• Вместо хранения всех траекторий — дистилляция в концепт-документы (эффективно)
• Вместо статичной памяти — поиск оптимальной конфигурации через MCTS (робустно к шуму LLM)

Почему это работает: База знаний партиционирована по мета-концептам (семантическим кластерам действий). Это позволяет:

1. Эффективно извлекать релевантные знания (не весь контекст, а нужный документ)
2. Модульно обновлять память (изменение одного концепта не ломает другие)
3. Естественно выравниваться с семантикой задач (концепты = поведенческие абстракции)

Готового промпта нет — BREW это фреймворк для построения базы знаний агента, требующий:

• Инфраструктуры для генерации траекторий
• Настройки оценщиков под домен
• Запуска MCTS-оптимизации

Однако можно адаптировать промпт Integrator Agent (см. раздел “Промпты") для ручного создания документов базы знаний из ваших траекторий.

LLM-агенты всё чаще применяются для сложных задач: автоматизация работы с компьютером, многошаговое планирование, манипуляции с данными. Но есть фундаментальная проблема: агент не помнит прошлый опыт. Пример из исследования: агент устанавливает софт в Ubuntu за 47 шагов с 23 API-вызовами. При повторной похожей задаче — снова 47 шагов, как будто видит проблему впервые. Человек после первой попытки запомнил бы оптимальную последовательность из 6 шагов.

Существующие подходы к обучению агентов имеют ограничения. Дообучение весов модели (PPO, GRPO) требует огромных вычислительных ресурсов для сходимости, результат непрозрачен и сложно адаптируется. Методы с памятью либо хранят только временный контекст траекторий (исчезает между эпизодами), либо встраивают заметки в промпт без детализации и модульности.

BREW предлагает третий путь: инкрементальное построение базы знаний из прошлых взаимодействий агента. База знаний — это коллекция документов на естественном языке, партиционированных по концептам (семантическим кластерам действий). Агент извлекает релевантные документы при выполнении новых задач. Ключевая инновация — Expand-and-Gather MCTS: метод поиска оптимальной конфигурации базы знаний через параллельное исследование пространства состояний документов.

Результаты на реальных бенчмарках (OSWorld, τ²Bench, SpreadsheetBench): +10-20% точности задач, -10-15% API-вызовов, сохранение вычислительной эффективности на уровне базовых моделей. В отличие от предыдущих работ, где память — статичный контекст, BREW делает базу знаний модульным и контролируемым субстратом для оптимизации агента.

Партиционирование памяти по мета-концептам — вместо единой базы знаний создаётся коллекция документов, каждый привязан к семантическому концепту (например, “Сжатие и распаковка файлов”, “Поиск и открытие файлов"). Это даёт:

• Эффективный retrieval (извлекается только релевантный документ, не весь контекст)
• Модульные обновления (изменение одного документа не влияет на другие)
• Естественное выравнивание с семантикой задач

MCTS для оптимизации базы знаний — проблема поиска оптимальной базы знаний формализована как поиск в пространстве состояний. Expand-and-Gather MCTS:

• Expand Phase: для каждого концепта расширяется дерево вариантов документа
• Gather Phase: лучшие документы из всех деревьев собираются для оценки наград
• Результат: робастность к шуму и неспецифичности естественного языка

Двухкомпонентная награда (correctness + retrieval) — документы оцениваются по:

1. Корректности (насколько помогают агенту решать задачи)
2. Извлекаемости (насколько легко найти документ в растущей базе знаний)

Это предотвращает создание “полезных, но ненаходимых” документов.

Дедупликация концептов через кластеризацию — ReflAgent генерирует концепты независимо для каждой траектории, что приводит к дублям. Семантическая кластеризация эмбеддингов концептов решает это, создавая компактный набор мета-концептов.

Итеративное уточнение без поиска (-1.43% на OSWorld vs MCTS) — простое многократное уточнение документов через IntegAgent без исследования альтернатив проваливается из-за стохастичности LLM. Агент не может надёжно инкорпорировать фидбек без исследования пространства состояний.

Жадный поиск (-2.01% на OSWorld vs MCTS) — выбор только лучшего состояния на каждом шаге без баланса exploration/exploitation приводит к локальным оптимумам.

Статичная память (Cognee, Agent-Mem) — базовые методы памяти показывают меньший прирост (+2.5% vs +3.36% у BREW на OSWorld), так как не оптимизируют структуру знаний под задачи.

Структурированная память через партиционирование + поиск оптимальной конфигурации превосходит как дообучение весов (дорого, непрозрачно), так и простое хранение траекторий (неэффективно, нет обобщения). Ключ — баланс между семантической организацией (мета-концепты) и робастной оптимизацией (MCTS).

1. Партиционирование базы знаний по мета-концептам

Что: База знаний D разбита на документы {d_k}, каждый привязан к мета-концепту k (например, “Вставка изображений”, “Поиск файлов"). Мета-концепты получены кластеризацией концептов, извлечённых ReflAgent из траекторий.

Почему работает:

• Эффективный retrieval: Агент извлекает top-3 документа по релевантности запросу, а не весь контекст
• Модульность: Обновление документа для “Сжатия файлов” не влияет на “Вставку изображений”
• Семантическое выравнивание: Концепты естественно отражают поведенческие абстракции (shortcuts, процедуры, стратегии локализации UI)

Пример: В OSWorld для LibreOffice Writer база знаний содержит документы:

• “Search and Open Files” — как найти и открыть файл через File Manager
• “Insert Images” — как вставить изображение через Insert → Image → From File
• “Compress and Extract Files” — как сжать/распаковать через правый клик

При задаче “Edit the file titled ‘salesreportmarch.ods’” агент извлекает документ “Search and Open Files”, который содержит конкретные шаги: Ctrl+F в File Manager, поиск по ‘sales’, проверка типа .ods, открытие в LibreOffice Calc.

Цифры: На OSWorld партиционирование даёт +3.36% точности vs базовой модели. На τ²Bench — +2.51%. Анализ показывает, что агент извлекает релевантные документы в 87% случаев.

2. Expand-and-Gather MCTS

Что: Алгоритм поиска оптимальной конфигурации базы знаний. Для каждого мета-концепта k строится дерево поиска вариантов документа d_k. На каждой итерации:

• Expand Phase: Для каждого дерева выбирается лучший узел (UCT), генерируются h=3 варианта документа
• Gather Phase: Лучшие документы из всех деревьев собираются в гибридную базу знаний для оценки наград

Почему работает:

• Робастность к шуму LLM: IntegAgent стохастичен — один и тот же инсайт может быть интегрирован по-разному. MCTS исследует варианты.
• Баланс exploration/exploitation: UCT выбирает узлы с учётом как текущей награды, так и неопределённости
• Параллельная оптимизация: Деревья для разных концептов исследуются независимо, но синхронизируются через Gather Phase

Пример: Для концепта “Search and Open Files":

• Итерация 1: IntegAgent генерирует 3 варианта документа с разной структурой (таблица vs список, разный уровень детализации)
• Оценка: Вариант с таблицей Quick Reference получает R=0.78 (correctness=0.82, retrieval=0.74)
• Итерация 2: Расширяется узел с таблицей, генерируются уточнённые версии
• Итерация 3: Лучший вариант стабилизируется на R=0.85

Цифры: MCTS даёт +1.43% vs итеративное уточнение, +2.01% vs жадный поиск на OSWorld. Параметры: expansion width e=3, max depth k=3, iterations M=10.

3. Двухкомпонентная награда (correctness + retrieval)

Что: Награда для документа d_k в контексте базы знаний D:

R = λ_corr · R_corr + λ_ret · R_ret

• R_corr: точность агента на held-out задачах при использовании D
• Rret: Mean Reciprocal Rank (MRR) документа dk при retrieval по запросам

Почему работает:

• Correctness обеспечивает полезность документа для решения задач
• Retrieval предотвращает создание “полезных, но ненаходимых” документов
• Баланс λcorr=λret=0.5 даёт лучшие результаты (ablation study в исследовании)

Пример: Документ “Insert Images” может быть очень детальным (высокий correctness), но если он называется “Visual Element Integration” — его сложно найти по запросу “add image” (низкий retrieval). MCTS оптимизирует баланс: документ переименовывается в “Insert Images”, сохраняя детализацию.

Цифры: На SpreadsheetBench документы с высоким retrieval (MRR>0.8) дают +4.5% точности vs документы с низким retrieval (MRR<0.5), даже при одинаковом correctness.

4. ReflAgent: извлечение инсайтов из траекторий

Что: LLM-агент, который анализирует траекторию выполнения задачи и извлекает пары {концепт, инсайт}. Входы:

• Траектория (последовательность действий агента)
• Оценка корректности (binary success label)
• Рубрики поведения агента (human-validated metrics)

Почему работает:

• Рубрики направляют рефлексию на важные аспекты (обработка ошибок, адаптация к неожиданным состояниям)
• Гранулярность: Инсайты на уровне предложений, не абстрактные заметки
• Привязка к концептам: Каждый инсайт маппится на семантический концепт

Пример: Траектория установки софта в Ubuntu:

• Концепт: “Package Manager Usage”
• Инсайт: “Use ‘apt search’ to verify package name before ‘apt install’ — prevents ‘package not found’ errors”

Цифры: ReflAgent извлекает в среднем 3.2 инсайта на траекторию. После дедупликации остаётся 15 мета-концептов для OSWorld, 12 для τ²Bench.

5. IntegAgent: инкрементальное построение документов

Что: LLM-агент, который обновляет документ d_k для мета-концепта k, интегрируя новые инсайты. Промпт IntegAgent (см. раздел “Промпты") требует:

• Сохранение всех технических деталей (команды, флаги, параметры)
• Трансформацию bullet points в связный текст
• Структуру: Context → How to Use → When to Use → Best Practices

Почему работает:

• Zero Loss Policy: Все детали из инсайтов сохраняются (команды, примеры, edge cases)
• Prose Transformation: Bullet points превращаются в 1-3 связных предложения — улучшает читаемость и retrieval
• Структурированность: Фиксированная структура документа упрощает навигацию агента

Пример: Инсайты для “Compress and Extract Files":

• “Right-click → Compress… → Choose .zip or .tar.gz”
• “Use ‘tar -xzf file.tar.gz’ for command-line extraction”

IntegAgent создаёт документ:

## Compress and Extract Files
**When to use**: Archiving multiple files or extracting downloaded archives.

### How to Perform
To compress files, select them in File Manager, right-click, and choose 
"Compress...". Select .zip for compatibility or .tar.gz for better compression. 
For command-line extraction, use 'tar -xzf file.tar.gz' to extract .tar.gz archives.

Цифры: IntegAgent с temperature=0.7 генерирует разнообразные варианты документа (важно для MCTS). Средняя длина документа: 150-200 слов.

# Task: Create Technical Documentation from Agent Insights

You are creating a comprehensive technical reference document for an AI agent.

**Input:** A list of insights extracted from agent trajectories, grouped by concept.

**Your task:** Transform these insights into a well-structured markdown document 
following this template:

## [Concept Name]

**When to use**: [Describe specific scenarios where this knowledge applies]

### How to Perform
[Step-by-step instructions with exact commands, shortcuts, and parameters.
Transform bullet points into 2-4 connected sentences. Include examples.]

### Additional Actions
[Optional advanced techniques, edge cases, or related operations]

### Example
[Concrete example showing the concept in action:
- Task: "[specific user request]"
- Steps: [numbered sequence]
- Result: [what happens]]

**Requirements:**
1. **Preserve all technical details**: Every command, flag, shortcut, file extension
   Example: Don't write "compress files" — write "Right-click → Compress... → Choose .zip or .tar.gz"

2. **Use complete sentences**: Transform "Ctrl+F to search" into "Press Ctrl+F or 
   click the search icon to open the search interface"

3. **Make implicit knowledge explicit**: 
   - "Open File Manager" → "Open File Manager (Nautilus) via launcher, dock, or Super+E"
   - "Search for file" → "Search for file using wildcards like *.pdf or report*"

4. **Include concrete examples**: Show actual filenames, commands, paths
   - Not: "search for a document"
   - But: "search for 'sales_report_march.ods' in Downloads folder"

**Input Insights:**
{your_insights_here}
Пример заполнения:
- Concept: "Compress Files"
  Insights:
  * "Right-click on selected files → Compress..."
  * "Choose .zip for compatibility, .tar.gz for better compression"
  * "Use 'tar -xzf file.tar.gz' for command-line extraction"

**Output:** Single markdown document following the template above.

Ключевые элементы:

• "Zero Loss Policy" — предотвращает потерю технических деталей при трансформации bullet points в прозу. Исследование показывает, что без этого требования IntegAgent теряет ~30% конкретных команд и параметров.
• "Prose Transformation" — улучшает retrieval. Документы в формате связного текста имеют MRR на 0.12 выше, чем bullet lists (данные из ablation study).
• "Make implicit knowledge explicit" — критично для новых доменов. Пример: “Open File Manager” без уточнения приводит к ошибкам агента в 15% случаев на OSWorld.

# Enhanced Documentation Editor Prompt

You are a meticulous documentation-level editor specializing in comprehensive
technical reference materials. You will be given a list of topic nodes, each 
containing structured information that must be preserved and enhanced with 
maximum detail retention.

## Input Structure Analysis
Each node contains:
- **Title**: The primary topic identifier
- **Context**: Background information and conceptual foundation
- **How to Use**: Step-by-step instructions, commands, flags, parameters, and
  implementation details
- **When to Use**: Specific scenarios, conditions, and decision criteria
- **Best Practices**: Expert recommendations, optimization techniques, and
  common pitfalls to avoid

## Detailed Processing Requirements

### 1. Information Preservation (Zero Loss Policy)
- **Preserve every technical detail**: All command-line flags, parameter values,
  configuration options, file paths, URLs, version numbers, and exact syntax
- **Maintain all examples**: Keep every code snippet, sample input/output, file
  names, directory structures, and command sequences exactly as provided
- **Retain contextual nuances**: Preserve qualifying language like "typically,"
  "usually," "in most cases," "when available," and conditional statements
- **Keep quantitative data**: Preserve all numbers, measurements, timeframes,
  limits, thresholds, and statistical information
- **Maintain cross-references**: Keep all mentions of related tools,
  dependencies, prerequisites, and interconnected concepts

### 2. Enhanced Detail Extraction
- **Expand abbreviations**: When encountering shortened forms, expand them
  naturally while preserving the original
- **Surface implicit knowledge**: Make obvious assumptions explicit (e.g., "this
  requires root permissions," "assumes default configuration")
- **Clarify relationships**: Explicitly describe how different components,
  options, or steps relate to each other
- **Highlight edge cases**: Emphasize special conditions, exceptions, or unusual
  scenarios mentioned in the source
- **Elaborate on consequences**: When the source mentions outcomes, expand on
  both success and failure scenarios

### 3. Prose Transformation Guidelines
- **Bullet integration**: Transform each bullet point into 1-3 complete
  sentences that naturally flow together
- **Technical precision**: Use precise technical vocabulary while maintaining
  readability
- **Logical flow**: Organize information within each section to follow a logical
  sequence (setup → execution → verification)
- **Contextual embedding**: Weave code snippets and technical terms seamlessly
  into narrative sentences
- **Comprehensive coverage**: Ensure every sub-bullet, nested item, and
  parenthetical note becomes part of the prose

### 4. Structural Requirements
- **Heading hierarchy**: Use '# Title' for each node's main heading
- **Section order**: Maintain Context → How to Use → When to Use → Best
  Practices sequence
- **Paragraph organization**: Create substantial paragraphs (3-6 sentences)
  rather than brief statements
- **Transition quality**: Craft smooth bridges between sections and between
  different nodes
- **Code formatting**: Preserve all inline code with backticks and maintain
  proper formatting for code blocks

### 5. Quality Assurance Checklist
Before finalizing, verify:
- [ ] Every piece of source information appears in the output
- [ ] All technical specifications, parameters, and examples are intact
- [ ] Code snippets maintain their exact syntax and formatting
- [ ] Prose flows naturally without choppy or fragmented sentences
- [ ] Each section provides comprehensive coverage of its topic area
- [ ] Cross-references and dependencies are clearly explained
- [ ] No section labels or formatting artifacts remain in the prose

## Output Specifications
Generate a single, cohesive markdown document that reads as authoritative
technical documentation. The result should be comprehensive enough that a reader 
could successfully implement the described tools or techniques using only the 
information provided, without referring back to the original nodes.

**Input Nodes:** 
<NODES>
{node_list}
</NODES>

Now, produce the aggregated markdown reference sheet with maximum detail
preservation and enhanced clarity.

Результат: Документы базы знаний для OSWorld (пример “Search and Open Files” в разделе 6).

Описание конкретных механик промпта:

• Zero Loss Policy (секция 1) — критична для сохранения технических деталей. Без неё IntegAgent теряет ~30% команд и параметров.
• Prose Transformation (секция 3) — трансформация bullet points в связный текст улучшает retrieval на 0.12 MRR.
• Quality Assurance Checklist (секция 5) — снижает вариативность выходов IntegAgent, важно для стабильности MCTS.

Контекст: Агент должен установить пакет в Ubuntu. Первая попытка — без базы знаний, вторая — с BREW KB.

Было (Baseline, 47 шагов, 23 API-вызова):

Траектория агента:
1. Открыл Ubuntu Software (GUI) — неоптимально для автоматизации
2. Поиск пакета через GUI — 3 клика
3. Не нашёл пакет (неправильное имя)
4. Открыл терминал
5. Попытка 'apt install package' — ошибка "package not found"
6. Поиск правильного имени через 'apt search' — 5 попыток с разными запросами
7. Установка зависимостей вручную — 8 команд
8. Повторная попытка установки — успех
9-47. Проверка установки, избыточные действия

Итого: 47 шагов, 23 API-вызова, 3 минуты выполнения

Стало (BREW, 6 шагов, 8 API-вызовов):

Траектория агента с KB:
1. Извлёк документ "Package Manager Usage" из KB
2. Выполнил 'apt search package-name' для проверки имени — 1 попытка
3. Выполнил 'sudo apt install correct-package-name'
4. Автоматическая установка зависимостей (apt делает сам)
5. Проверка установки через 'which package-name'
6. Завершение

Итого: 6 шагов, 8 API-вызовов, 45 секунд выполнения

Что изменилось и почему сработало:

• "Package Manager Usage” (KB документ) — содержал инсайт: “Use ‘apt search’ to verify package name before ‘apt install’ — prevents ‘package not found’ errors”. Агент сразу проверил имя пакета, избежав 5 попыток поиска.

• "Dependency Handling” (KB документ) — содержал: “apt automatically resolves dependencies — no need for manual installation”. Агент не тратил 8 команд на ручную установку зависимостей.

• "Command-line vs GUI” (KB документ) — содержал: “For automation tasks, prefer command-line tools (apt) over GUI (Ubuntu Software)”. Агент сразу открыл терминал, избежав 3 кликов в GUI.

Результат:

• Сокращение шагов: 47 → 6 (-87%)
• Сокращение API-вызовов: 23 → 8 (-65%)
• Время выполнения: 3 минуты → 45 секунд (-75%)

Это типичный паттерн для OSWorld: BREW даёт среднее сокращение на 39% шагов для успешных задач (см. Figure 3 в исследовании).

На чём тестировалось:

• OSWorld: 10 приложений Ubuntu (LibreOffice, Chrome, GIMP, VLC и др.), 369 задач
• τ²Bench: 3 домена (Telecom, Retail, Airline), 254 задачи
• SpreadsheetBench: 912 инструкций из Excel-форумов, 2729 тест-кейсов

Не тестировалось:

• Домены за пределами computer-use, tool-calling, spreadsheets
• Задачи с визуальным рассуждением (BREW работает с текстовыми траекториями)
• Мультимодальные траектории (изображения, видео)

Когда метод может не работать:

• Малое количество обучающих траекторий — BREW требует минимум 20-30 траекторий для построения качественной KB. На SpreadsheetBench с 10 траекториями прирост только +1.2% vs +4.8% с 30 траекториями.
• Задачи без повторяющихся паттернов — если каждая задача уникальна, KB не даёт преимущества. Пример: творческие задачи типа “придумай уникальный дизайн”.
• Домены с быстро меняющимся API — KB устаревает. Авторы отмечают: “KB requires periodic updates when environment changes”.

Важные оговорки авторов:

• “BREW’s effectiveness is influenced by the quality and coverage of training data” — мусор на входе = мусор в KB.
• “Future work could explore more adaptive and domain-general memory refinement” — текущая версия требует настройки под домен (graders, rubrics).
• Computational cost: MCTS с M=10 итерациями, e=3 expansion width требует ~100-150 LLM-вызовов для построения KB. Это one-time cost, но не бесплатно.

Что нужно для применения:

1. Инфраструктура для траекторий (-8): Агент должен выполнять задачи и логировать траектории. Для OSWorld это GTA1-7B (multimodal agent), для τ²Bench — o4-mini с tool-calling. Нужна интеграция с вашим агентом.

2. Настройка оценщиков (-7): Task-specific graders для вашего домена. Для OSWorld это 134 скрипта проверки состояния файлов/UI. Для τ²Bench — проверка базы данных + NL-верификация. Нужно писать под свои задачи.

3. Настройка rubrics (-5): Human-validated метрики поведения агента. Исследование использует готовые из [Rubicon paper], но для нового домена нужна адаптация.

4. Запуск MCTS (-5): 100-150 LLM-вызовов для построения KB (M=10 итераций, e=3 expansion width, K=15 концептов). Это one-time cost, но требует времени и API-бюджета.

НЕ считается барьером:

• Доступ к GPT-4.1 API (стандарт)
• Понимание концепции MCTS (объяснено в статье)

Категория: Полезное (62/100)

Главная ценность: Первый практичный метод создания структурированной, интерпретируемой памяти для агентов через партиционирование по концептам + MCTS-оптимизацию. Альтернатива дообучению весов — прозрачная, модульная, адаптируемая.

Кому полезно:

• ML-инженерам, строящим production-агентов для повторяющихся задач (автоматизация, data manipulation)
• Исследователям, работающим над долгосрочной памятью агентов
• Командам с доступом к траекториям агента и возможностью настроить graders

Кому НЕ полезно:

• Практикам промптинга без инфраструктуры для траекторий
• Проектам с уникальными, неповторяющимися задачами
• Сценариям, где нужен результат “прямо сейчас” (BREW требует one-time setup)

Почему не выше: Барьер входа высокий — нужна серьёзная инфраструктура. Нет публичного кода. Нет сравнения с дообучением весов (авторы утверждают, что BREW лучше, но не показывают прямого сравнения на тех же задачах). Для “прорыва” (85+) нужен либо готовый код, либо радикально более низкий барьер.

Ресурсы:

• Статья: “Improving Language Agents through BREW” (Microsoft, Nov 2025)
• Бенчмарки: OSWorld, τ²Bench, SpreadsheetBench
• Связанные работы: Rubicon (rubrics), MetaReflection (in-prompt memory), Mem0 (transient memory)