Интерактивная отладка и управление многоагентными системами искусственного интеллекта: каждый сброс шлюза

Интерактивную отладку и управление многоагентными системами ИИ не следует рассматривать как редактирование стенограммы. При безопасном сбросе создается новая ветвь со своим собственным происхождением, доказательствами восстановленного состояния, авторитетной записью и квитанцией о результатах. Если браузер, рабочая область, очередь, учетные данные или внешний пункт назначения не могут быть восстановлены или согласованы, правильное состояние является неопределенным, а не «готовым». Это практический урок, который можно извлечь изИнтерактивная отладка и управление многоагентными системами искусственного интеллекта, документ CHI 2025, лежащий в основе Microsoft с открытым исходным кодом.AGDebugger. Исследование позволяет использовать функцию перемотки и редактирования для многоагентной отладки. Для оперативного развертывания требуется еще одна граница: сброс может воссоздать внутреннее состояние достаточно точно, чтобы проверить гипотезу, но он не может автоматически отменить электронное письмо, отменить заявку, отменить публикацию страницы или доказать, что новая ветвь выполнила задачу пользователя. Разумным по умолчанию является управляющая квитанция с шестью воротами: 1. родительский элемент и ветвь имеют разные личности; 2. контрольная точка охватывает каждый необходимый агент и ключ состояния инструмента; 3. эффекты после контрольной точки отменяются или согласовываются; 4. оператор имеет право на вмешательство; 5. конфигурация агента закрепляется за новой веткой; 6. возобновленный филиал получает новую квитанцию ​​о результатах. Только первые пять делают ветку готовой к возобновлению . Шестой делает его подтвержденным . Сброс — это ветвь, а не перемотка назад. Статья AGDebugger начинается с конкретной проблемы. Пять разработчиков агентов рассказали о трудностях с локализацией ошибок в длительных разговорах, отсутствии интерактивных элементов управления отладкой и медленной итерации конфигураций агента. Авторы создали систему, которая позволяет разработчику просматривать сообщения, возвращаться к более ранней точке, редактировать предыдущее сообщение и сравнивать полученные ветки диалога. Затем в исследовании, состоящем из двух частей, с участием 14 участников были изучены методы диагностики и стратегии управления. Это более сильное взаимодействие, чем поиск в журналах. На границе сбоя разработчик может задать два фальсифицируемых вопроса: что произойдет, если то же состояние запустится снова, и что произойдет, если изменится конкретное сообщение? В документе сообщается о трех распространенных формах управления в ходе исследования: добавление деталей, упрощение задачи и изменение плана. Но детали реализации имеют большее значение, чем возможности редактирования. AGDebugger проверяет состояние агента перед обработкой сообщения. При сбросе он восстанавливает соответствующую контрольную точку и создает новый сеанс. Сообщения и контрольные точки до форка остаются общими; новые сообщения и контрольные точки принадлежат ветке. Это Lineage, даже если интерфейс выглядит как перемотка назад. Рассматривая операцию как ветвь, оператор получает три полезных инварианта: исходный неудачный запуск остается доступным для проверки; точная точка разветвления неизменна; редактирование и каждый последующий эффект относятся к новому сеансу. Без этих инвариантов отредактированная стенограмма может переписать доказательства, использованные для диагностики инцидента. Результат «успешного запуска» может быть невозможно воспроизвести, поскольку никто не может сказать, какая история, подсказка, схема инструмента или конфигурация модели его создали. Запись ветки не требует содержимого сообщения: Идентификаторов хэшей и классов грубого редактирования достаточно для отслеживания доказательств. Не экспортируйте подсказки, аргументы инструментов, секреты или пользовательские данные только для того, чтобы доказать существование форка. Восстановите покрытие штата, прежде чем менять план Удаление сообщений из расшифровки не является восстановлением состояния. В документе говорится, что агенты AGDebugger реализуют методы сохранения и загрузки состояния. Состояние веб агента может включать URL адрес и позицию области просмотра; другим агентам может потребоваться другое состояние. Он также описывает политику контрольных точек как «достаточно хорошую», поскольку полное восстановление JavaScript браузера и состояния удаленного приложения может быть непрактичным или невозможным. Это ограничение должно находиться рядом с кнопкой сброса, а не при вскрытии. Перед началом выполнения определите ключи состояния, необходимые для рабочего процесса. Для небольшой исследовательско издательской группы это могут быть: Эта контрольная точка является неполной, поскольку очередь утверждения отсутствует. Воспроизведение стенограммы может привести к тому, что ветка запросит еще раз, пропустит существующее решение или будет действовать так, как будто полномочия передаются. Оператор должен видеть restore uncertain , а не зеленый элемент управления возобновлением. Покрытие необходимо, но недостаточно. Для каждого ключа состояния запишите отпечаток ревизии или отсутствия содержимого и результат восстановления: Государственный ключ Доказательства перед сбросом Требуется тест восстановления Память агента хеш ревизии и контрольной точки загруженная ревизия соответствует вилке Браузер источник, хеш маршрута и класс локального сеанса ожидаемый маршрут достижим и класс сеанса действителен Рабочая область фиксация репозитория и дайджест грязного состояния точная доработка плюс намеренные локальные изменения Реестр инструментов хэш схемы и количество возможностей текущие совпадения реестра или отклонения подтверждены Очередь одобрения идентификаторы и статус получения решения незавершенные и принятые решения сохраняются Действующая удаленная система могла переместиться после контрольной точки. Это не всегда неудача. Это повод обозначить доказательства. Если браузер может вернуться к записанной странице, но базовая запись страницы изменилась, точность снимка является частичной. Оператор по прежнему может запускать диагностическую ветвь, но не должен представлять ее как точное воспроизведение. Конфигурация является частью состояния. Закрепите роли агентов, идентификаторы моделей, набор инструментов, системные подсказки и правила маршрутизации, используемые филиалом. В противном случае успешное редактирование доказывает лишь то, что какая то неизвестная комбинация сработала. Сохраняйте исходную конфигурацию неизменной и записывайте намеренную разницу. Согласуйте эффекты перед воспроизведением вызова инструмента Контрольная точка восстанавливает состояние под контролем отладчика. Это не меняет внешний мир. Предположим, что родительская ветвь создала заявку после контрольной точки, а затем не смогла предоставить обещанный публичный отчет. Сброс перед вызовом инструмента и воспроизведение могут создать второй билет. Отсутствие ответа не является свидетельством того, что первый звонок не возымел никакого эффекта. Прежде чем продолжить, перечислите каждую операцию после контрольной точки с внешним эффектом и классифицируйте ее: reverted : исходный эффект был благополучно отменен; reconciled : эффект сохраняется, и новая ветка будет использовать его повторно или пропустит; pending : доказательства пункта назначения отсутствуют; irreversible : эффект невозможно отменить и требует нового человеческого решения. Что либо pending или irreversible блокирует автоматическое воспроизведение на этой границе. Используйте ключи стабильной работы, если пункт назначения их поддерживает. Для операции публикации запросите место назначения по неизменяемому идентификатору черновика, прежде чем создавать другой. Для электронного письма сохраните идентификатор сообщения поставщика без тела сообщения. При изменении репозитория сравните ожидаемую фиксацию или хэш дерева. Для билета получите билет по ключу идемпотентности запроса. Вмешательство оператора также нуждается в границах полномочий. Редактирование плана сопряжено с низким риском, если ветка ограничена локальным устройством. Существенно отличается ситуация, когда редактирование меняет получателей, бюджет, разрешения, производственные цели или деструктивные действия. Направьте эти изменения авторизованному владельцу и сохраните ветку в тайне. needs approval пока не придет квитанция о решении. Ожидание этого решения не заставит себя ждать. Неоднократное возобновление работы, когда центр управления или состояние назначения неизвестны, является сбоем. Запустите рулевую квитанцию ​​на случай неудобных случаев Сопутствующий артефакт представляет собой бессодержательное приспособление и детерминированный классификатор. Он не запускает AGDebugger и не утверждает, что воспроизводит его пользовательское исследование. Он проверяет оперативное решение, связанное с сбросом. Запустите его локально: Приспособление содержит восемь ветвей. Классификатор выдал: Тест добавляет девятое утверждение: ветвь, идентификатор которой равен родительскому, отклоняется как invalid lineage . Приоритет является намеренным. Отсутствие блоков состояний влияет на интерпретацию, поскольку оператор не может установить начальную точку ветвления. Несогласованные эффекты блокируют возобновление до рассмотрения утверждения. Утверждение и закрепленная конфигурация делают ветку готовой, а не работоспособной. После возобновления ожидаемый результат по прежнему нуждается в детерминированном верификаторе. Измените одно поле, и результат должен измениться предсказуемо. Добавьте недостающий ключ очереди утверждения к частичному восстановлению, и оно сможет продолжиться. Отметьте, что ожидающий эффект билета согласован, и филиал сможет добраться до ворот доступа. Набор outcomeVerified на ложь после беглого окончательного ответа, и результат остается false success . Это дает важное функциональное различие: «Готов к возобновлению» означает, что граница вмешательства контролируется. «Проверено» означает, что новый филиал выполнил запланированную работу. Не объединяйте эти штаты в один зеленый значок. Чего не доказывает эксперимент Артефакт проверяет правило принятия решения, а не точность моментального снимка. Он не может доказать, что браузер был точно восстановлен, что LLM пойдет по тому же пути или что недокументированный побочный эффект никогда не возникал. Реальная интеграция требует адаптеров состояния и запросов назначения, специфичных для среды выполнения. Исследование AGDebugger также имеет ограниченный объем: пять формирующих интервью, 14 участников исследования, две учебные задачи и исследовательский прототип, построенный на AutoGen. Результаты исследования подтверждают модель взаимодействия; они не устанавливают снижение частоты инцидентов для каждой многоагентной архитектуры. В самой статье обозначены открытые проблемы, включая отделение управления от реализации агента и определение того, имело ли редактирование эффект. Эти ограничения усиливают действующее правило. Используйте интерактивный сброс, чтобы изолировать гипотезу, а не создавать уверенность. Сохраняйте родительский элемент, явно разветвляйте, восстанавливайте то, что можно доказать, маркируйте то, что невозможно, согласовывайте внешние эффекты, требуйте авторитетности и проверяйте новый результат в пункте назначения. Sidewisp сейчас находится на этапе закрытого предварительного доступа.Адаптеры производственного мониторинга и программа восстановления обычно не поставляются. Здесь используется проверенный образец работы, а не утверждение, что Sidewisp уже контролирует контрольно пропускные пункты или управляет командами живых агентов. В рамках продуктового направления Sidewisp авторитет человека, доказательства и проверка результатов играют центральную роль в безопасном восстановлении. Если вы сегодня эксплуатируете многоагентные системы, начните с одного рабочего процесса, подверженного сбоям. Определите ключи состояния и реестр внешних эффектов до следующего инцидента. Первая полезная контрольная точка — это не та, которая может воспроизвести большую часть истории; именно он может точно объяснить, что было восстановлено, что осталось измененным, кто авторизовал ветку и как был проверен окончательный результат.