The agent inbox is the per-agent queue where requests wait when the machine is asleep, the daemon is offline or the agent is already busy. Each request sits there with its id, its requester and its approval state, and the daemon works through the inbox in order when it returns. A request is never lost because the laptop lid was closed, and never runs twice because the daemon restarted.
Локальные агенты расплачиваются за свои преимущества доступностью. Инбокс позволяет свести эти издержки к минимуму.
Что попадает в инбокс
Каждый запрос — всегда. Даже когда машина онлайн, запрос проходит через инбокс по пути в runtime; просто очередь в этот момент пуста. Инбокс привязан к агенту: у двух агентов на одной машине два отдельных инбокса, и они работают параллельно; один агент обрабатывает свой инбокс последовательно, по одному запросу за раз, поэтому рабочий каталог никогда не редактируется двумя запусками одновременно.
Инбокс за ночь: три одобренных запроса ждут по порядку; один еще требует подтверждения владельца; машина просыпается и обрабатывает их.
Порядок и статус
Запросы выполняются в том порядке, в котором они были одобрены, а не в порядке отправки. Запрос от пользователя с постоянным доступом одобряется сразу при получении и встает на свое место; запрос, ожидающий одобрения владельца, сохраняет позицию, но пропускается, пока не будет одобрен. Владелец может удалять элементы из инбокса или менять их порядок до запуска.
Каждый элемент сохраняет свой статус во время ожидания: pending (требует одобрения), approved (ждет машину) или running (выполнялся в момент, когда машина уснула). См. id запросов и возобновляемые запуски.
Пробуждение
Когда daemon возвращается в сеть, он опрашивает сервер в поисках задач, получает инбокс по порядку и:
- Возобновляет любой запрос, который выполнялся, когда машина уснула, используя сохраненную ссылку на сессию runtime. Тот же id, та же сессия, пробел в таймлайне вместо дублирующего запуска.
- Запускает одобренные запросы по очереди.
- Оставляет запросы в статусе pending на месте, пока владелец не ответит.
Запросы на одобрение, оставшиеся без ответа дольше TTL (по умолчанию 24 часа), к этому моменту истекают, и запросы помечаются как expired, а не выполняются устаревшими.
Как сохранять доступность машины
Инбокс делает периоды офлайна безопасными, но не быстрыми. Три привычки помогут сократить эти задержки.
- Установите daemon как службу с помощью
muti service install. Он запускается при входе в систему и перезапускается после сбоя, так что фраза «daemon не запущен» перестает быть причиной задержек. - Отключите спящий режим в рабочие часы на десктопе или подключите ноутбук к сети и настройте запрет сна при питании от сети. Закрытая крышка — это агент офлайн.
- Проверяйте
muti status, если сомневаетесь. Команда показывает, подключен ли daemon и когда он в последний раз опрашивал сервер.
Что видит автор запроса
Свой запрос в комнате с id и статусом: «queued, machine offline since 22:00» или «waiting for Noah’s approval». Они могут отменить его или добавить к нему сообщение. Когда он запускается, таймлайн передается потоком как обычно. Никому не нужно отправлять запрос заново.
Часто задаваемые вопросы
Инбокс находится на моей машине или в комнате? В сервисе комнаты. Именно это позволяет принимать запросы, пока машина выключена, а владельцу — менять их порядок с телефона.
Можно ли очистить инбокс? Да. Удаление элементов отменяет эти запросы; авторы запросов видят cancelled.
Что если машина выключена несколько дней? Запросы ждут. Запросы на одобрение истекают по собственному TTL; одобренные запросы срока действия не имеют, хотя владельцу, возможно, стоит почистить их перед долгим отсутствием.
Это относится и к запросам из чат-платформ? Да. Упоминание в Feishu или Slack становится таким же запросом, как и любой другой, и ожидает в том же инбоксе. См. архитектуру интеграции с Feishu.
Закрывайте крышку. Утром запросы будут на месте. Дайте своему агенту комнату.
Опубликовано