Испорченный телефон между агентами: как не терять контекст

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

Проблема не в глупости моделей. Она в архитектуре передачи: на каждом хопе агент видит не полный контекст, а сжатую выжимку от предыдущего, и добавляет собственную интерпретацию. Ошибки не компенсируют друг друга — они накапливаются.

Где именно рвётся цепочка

Потеря смысла в мультиагентной системе — это не один сбой, а сумма мелких протечек. Их стоит различать, потому что чинятся они по-разному.

• Сжатие с потерями. Агент-посредник пересказывает задачу своими словами, чтобы уложиться в контекстное окно или сэкономить токены. Детали, которые он счёл второстепенными, до следующего агента не доезжают.
• Домысливание. Получив неполную инструкцию, модель заполняет пробелы правдоподобными, но не запрошенными предположениями. Дальше по цепочке эти догадки едут как факты.
• Смена формата. Планировщик выдал структурированный JSON, исполнитель — свободный текст, ревьюер снова ждёт структуру. На стыках форматов теряются поля.
• Потеря источника истины. Никто в цепочке не хранит исходный запрос целиком, поэтому свериться с оригиналом уже не с чем.

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

Разделяйте передаваемое сообщение и общий контекст

Ключевая идея — перестать полагаться на цепочку пересказов. У сообщения между агентами две части, и их нельзя смешивать.

Иммутабельный контекст

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

Рабочий слой

Здесь агенты добавляют свои результаты: план, код, замечания ревьюера. Этот слой растёт, но не затирает предыдущие записи — он их дополняет. Так следующий агент видит и оригинал, и всю историю решений, а не только последний шаг.

{
  "immutable": {
    "user_request": "Добавить экспорт отчёта в CSV с фильтром по дате",
    "constraints": ["кодировка UTF-8", "разделитель — точка с запятой"]
  },
  "working": [
    {"agent": "planner", "output": "..."},
    {"agent": "coder", "output": "..."}
  ]
}

При такой схеме ревьюер сверяет код не с планом, а с полем immutable.user_request — то есть с тем, что реально просил человек. Точка с запятой как разделитель не потеряется, даже если планировщик про неё забыл упомянуть.

Валидация на стыках, а не только в конце

Дешевле отловить расхождение между шагами, чем переделывать всю цепочку. Три приёма, которые снижают накопление ошибок.

1. Схема на входе и выходе. Каждый агент принимает и отдаёт данные по фиксированной схеме (Pydantic, JSON Schema, TypeScript-типы — что ближе стеку). Если поле обязательное и его нет, вызов падает сразу, а не через два хопа.
2. Сверка с оригиналом. Перед финальной сборкой отдельный шаг проверяет: покрыт ли каждый пункт исходного запроса. Не «выглядит ли результат правдоподобно», а именно построчная сверка с immutable.
3. Явная передача неопределённости. Если агент был вынужден что-то домыслить, он помечает это флагом вместо того, чтобы выдавать догадку за факт. Следующий агент видит: здесь предположение, его стоит перепроверить.

Сколько агентов — вопрос цены

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

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

Что проверить в своей системе

• Хранится ли исходный запрос пользователя в неизменном виде и доступен ли он последнему агенту.
• Валидируются ли данные на каждом стыке, а не только на финале.
• Помечает ли агент свои домыслы явным флагом.
• Не растёт ли латентность и стоимость быстрее, чем польза от дробления ролей.
• Есть ли шаг сверки результата с оригиналом перед выдачей пользователю.

Испорченный телефон в мультиагентной системе лечится не более умной моделью, а более честной передачей. Отделите то, что нельзя менять, от того, что агенты дописывают, — и большинство протечек закроется само.