Как передать задачу от одного AI-агента другому и не потерять контекст

Начать задачу с одним агентом, а продолжить с другим кажется простым делом. Можно скопировать последнее сообщение и отправить его новому агенту. Но в последнем ответе не обязательно есть цель задачи, принятые решения и список файлов, с которыми уже работали. Эти сведения остались в переписке, которую второй агент не видит.
В agent-hub я добавил для этого команду /handoff. Приложение запускает агентов на компьютере и позволяет работать с ними через темы Telegram-группы. Команда просит текущего агента составить сводку, показывает ее пользователю и после подтверждения запускает другого агента в новой теме.
На этот раз расскажу про передачу задачи: почему я остановился на сводке, что именно получает новый агент и какие проблемы возникли с подтверждением и созданием темы.
Почему не перенести всю сессию
У разных агентов разные протоколы и способы хранения истории. Кроме текста сообщений в сессии могут быть вызовы инструментов, их результаты и служебные данные. Взять файл истории одного агента и передать его другому как готовую сессию не получится: получатель не обязан понимать этот формат.
В хабе уже есть команды /save и /restore, но они решают другую задачу. Снимок позволяет сохранить и восстановить сессию того же агента. При этом он не переносит файлы проекта и данные входа. Для работы с другим агентом нужна новая сессия и текст, с которого он сможет начать.
Можно пересказать все вручную, но тогда перед каждой передачей придется собирать информацию из длинной переписки. Поэтому я решил попросить исходного агента подготовить короткую сводку из уже известной ему истории. Перед отправкой ее можно проверить и исправить.
Что должно попасть в сводку
Хаб просит исходного агента указать:
цель задачи;
что уже сделано;
какие решения приняты;
какие файлы затронуты;
что осталось сделать.
В запросе есть и ограничения: использовать только известную историю, не придумывать недостающие факты, не продолжать задачу и не вызывать инструменты. Если каких-то сведений нет, агенту предлагается прямо об этом сказать.
Например, сводка может выглядеть так:
Цель: добавить повторную отправку результата после сбоя связи.
Сделано: сохранение ответа и постановка в очередь.
Решения: повторять отправку с первой неподтвержденной части.
Файлы: src/outbox.rs, src/results.rs.
Дальше: проверить восстановление после перезапуска.
Это условный пример, а не результат реальной передачи. Даже такая сводка не дает второму агенту всей истории: он не узнает, какие варианты обсуждались и от чего отказались, если это не попало в текст. Зато у него есть отправная точка, а файлы проекта он может изучить сам.
Сводка ограничена 3000 единицами UTF-16. Если она пустая или не помещается в лимит, хаб ее отклоняет. Обрезать текст автоматически я не стал: вместе с концом можно потерять следующие шаги или важное ограничение.
От команды до новой темы
Передача начинается в теме с существующей сессией. Можно отправить /handoff и выбрать получателя кнопкой или сразу указать агента, например /handoff codex.
Дальше порядок такой:
Нажать «Сформировать сводку».
Дождаться ответа текущего агента и проверить текст.
При необходимости нажать «Исправить» и прислать полный исправленный вариант.
Нажать «Передать и продолжить».
Только после последнего шага хаб создает новую тему Telegram, сохраняет ее привязку и запускает получателя. Исходная тема при этом остается на месте. Боту нужно право управления темами.
Генерация сводки - отдельный ход исходного агента. Он может потратить лимит или оплачиваемые токены и остается в истории исходной сессии. При этом сводка не заменяет последний ответ, доступный через /last.
Передача запускается с новой сессией и настройками получателя. Он получает проверенный текст и просьбу продолжить задачу. История и разрешения исходного агента к нему не переходят. Это важно: сводка может сказать «команда уже согласована», но сама по себе не дает новому агенту права выполнить ее без предусмотренного его настройками подтверждения.
Зачем здесь проверка человеком
Сводку составляет модель, а значит, она может упустить деталь или неверно описать принятое решение. Поэтому хаб не отправляет ее следующему агенту сразу после генерации. Сначала появляется предпросмотр с кнопками «Исправить», «Передать и продолжить» и «Отмена».
Если выбрать исправление, хаб попросит ответить полным текстом сводки и затем покажет новый предпросмотр. Именно подтвержденный вариант уйдет получателю. Подтвердить передачу может тот, кто ее начал.
У черновика есть срок действия - 15 минут с открытия /handoff. Новый ход в исходной сессии, восстановление снимка, изменение контекста или настроек и перезапуск приложения делают сводку недействительной. Причина простая: после изменений старый текст уже может не описывать текущее состояние задачи. В таком случае передачу нужно начать заново.
Старые кнопки и ответы на запрос исправления не должны запускать новую задачу. Для этого хаб связывает действия с черновиком, его ревизией, пользователем и исходным контекстом. Повторное нажатие подтверждения не должно создать вторую тему.
Сводка без продолжения работы
Когда пользователь просит только подготовить передачу, неожиданный запуск команд был бы неприятным сюрпризом. Поэтому в служебном запросе агенту указано не читать и не менять файлы, не запускать команды и не задавать вопросы.
Кроме инструкции хаб использует отдельный канал для этого хода. Если агент обращается через него за разрешением, задает вопрос или пытается отправить файл, канал отвечает отказом и отменяет подготовку сводки. Однако это не отдельная песочница: если сам CLI автоматически разрешает инструмент и выполняет его без обращения к хабу, один этот канал не гарантирует изоляцию. Поэтому настройки разрешений агента по-прежнему имеют значение.
На генерацию отведено до трех минут, одновременно могут готовиться две сводки. Во время обычного хода или операции со снимком начать подготовку нельзя. Отменить ее можно кнопкой «Отмена» или командой /stop; новая задача в исходной сессии станет доступна после остановки служебного хода.
Что происходит с файлами проекта
Новый агент начинает работу в том же каталоге, что и исходный. Ему не передается архив проекта: оба агента работают с одними и теми же файлами на диске.
Это удобно, потому что получатель может сам посмотреть код и проверить сводку. Но у такого подхода есть ограничение: исходная тема остается доступной, и два агента могут одновременно менять один проект. Изоляции файлов или автоматического разрешения конфликтов здесь нет. Если продолжать работу в обеих темах, за пересекающимися изменениями нужно следить.
Кроме того, файлы могут измениться между генерацией сводки и началом работы получателя. Сводка передает то, что было известно исходному агенту, а не гарантирует актуальность состояния диска. Получателю стоит проверять файлы перед изменениями.
Ошибки при создании темы
В передаче несколько шагов, и каждый может завершиться ошибкой: исходный агент не составил сводку, Telegram не создал тему, хаб не сохранил привязку или получатель не запустился. Исходная сессия при этом остается доступной - можно вернуться к ней и разобраться, что произошло.
С созданием темы есть знакомая проблема сетевых запросов: Telegram мог создать тему, но ответ об этом потерялся. Если сразу повторить запрос, можно получить две темы. Поэтому хаб не делает автоматический повтор создания. При потере ответа в группе может остаться пустая тема; перед новой попыткой стоит проверить список тем.
Когда ответ Telegram получен, хаб сначала сохраняет привязку новой темы, а затем запускает агента. Так получатель не начинает работу в теме, о которой приложение еще не успело сохранить сведения.
Как проверял
Сценарий покрыт автоматическими тестами с подменой агентов и Telegram. Проверялись подтверждение и исправление сводки, отмена, устаревшие кнопки, ошибки создания темы и запуска, а также сохранность исходной сессии. Есть проверка, что получатель начинает новую сессию и получает именно подтвержденный текст.
На этапе реализации полный набор проверок прошел на Linux. После этого я проверил передачу вручную с реальными агентами через Telegram: задача передается, а новая тема создается сразу с выбранным агентом.
Итого
Для передачи задачи другому агенту я сохранил исходную сессию и добавил промежуточный шаг - проверяемую сводку. Новый агент начинает собственную сессию в новой теме, получает подтвержденный текст и работает с теми же файлами проекта.
Сводка не переносит всю историю и может упустить важные детали. Поэтому ее можно исправить до отправки, а новый агент не наследует разрешения исходного. При этом общий каталог остается общим: если оба агента работают одновременно, их изменения могут пересечься.
Код открыт под MIT: github.com/aprazdnikov/agent-hub-rs.
А как вы передаете контекст между агентами, если нужно продолжить задачу в другой сессии?
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.