Многоагентная наблюдаемость: аудит топологии координации

Многоагентная наблюдаемость должна отвечать на более строгий вопрос, чем «завершился ли каждый записанный промежуток времени?» Он должен сообщить вам, соответствуют ли агенты, которые действительно участвовали, и маршруты, которые они фактически использовали, схеме координации, утвержденной для этого запуска. Практическое значение по умолчанию – это контракт с версионной топологией : небольшой манифест разрешенных агентов, разрешенных направленных ребер и ребер, ожидаемых на текущей фазе выполнения. Присоедините этот манифест к квитанциям о взаимодействии без содержания. Успешная трассировка может быть классифицирована как рабочая, ожидающая, неполная, небезопасная, неоднозначная или ложнозавершенная, вместо того, чтобы по умолчанию становиться зеленой. Это важно, потому что трассировка фиксирует то, что произошло. Он не может содержать диапазон для обязательного делегирования, которого никогда не было. Он также не может решить, что наблюдаемый прямой маршрут был запрещен, если вы не предоставите предполагаемый граф. То же различие присутствует и в текущем руководстве по архитектуре: Microsoft многоагентная эталонная архитектура называет потоки межагентских сообщений и шаблоны координации особыми сигналами наблюдения, в то время как Azure Architecture Center предупреждает, что многоагентная оркестровка добавляет накладные расходы на координацию и новые виды сбоев. Используйте наименьшую сложность, которая надежно удовлетворяет поставленной задаче; когда использование нескольких агентов оправдано, сделайте их топологию тестируемой. Трассировка не может доказать предполагаемую топологию. API трассировки OpenTelemetry предоставляет правильные примитивы корреляции: отслеживание и охват идентичности, происхождения, ссылок, событий, меток времени, атрибутов и статуса. Эти примитивы могут описывать наблюдаемое дерево вызовов или асинхронные отношения. Они не сообщают, какие агенты были разрешены, какая версия маршрута была активна или какой край должен был появиться, но не появился. Предположим, организатор делегирует исследование, исследователь передает доказательства проверяющему, а проверяющий выносит вердикт. Каждое наблюдаемое событие может иметь status: "ok" как минимум в пяти плохих ситуациях: при запуске использовалась вчерашняя политика маршрутизации; исследователь позвонил издателю напрямую, минуя проверку; в граф попал незарегистрированный агент; оркестратор дважды делегировал один и тот же принадлежащий маршрут; родитель объявил о завершении до того, как верификатор вернулся. Запрос «все события в порядке» не обнаруживает ошибок в этих записях. Вместо этого при аудите топологии сравниваются два набора: Оставьте этот слой свободным от содержимого. Для квитанции требуется стабильный запуск и идентификаторы агента, тип маршрута, версия топологии, идентификатор события, время наблюдения и локальный статус. Ему не нужны подсказки, ответы, секреты, аргументы инструментов или абсолютные пути к файлам. Контракт намеренно отделен от кворума завершения разветвления. Кворум спрашивает, вернулись ли необходимые ветки. График ожидания спрашивает, какая зависимость блокирует прогресс. В долговременной квитанции о передаче запрашивается вопрос, выдержала ли ответственность очередь или границу перезапуска. Соответствие топологии задает первоначальный вопрос: это вообще тот координационный график, который мы собирались запустить? Создание контракта на версионную координацию Начните с явных тождеств и направленных ребер. Не делайте вывод о разрешенном графике на основании того, что появилось в последней трассировке; это просто благословляет дрейф постфактум. Разрешенный набор не совпадает с ожидаемым набором. На этапе, посвященном только исследованиям, можно ожидать двух делегирований и отсутствия преимуществ издателя. Завершенный этап публикации может включать в себя передачу исследования, возврат проверяющего, делегирование издателя и возврат издателя. Закрепите этот набор для конкретной фазы в начале цикла. В противном случае необязательное ребро может незаметно стать обязательным в середине сбоя, или необходимое ребро может исчезнуть из определения прежде, чем кто либо заметит. Компактный классификатор может использовать этот приоритет: 1. просроченный контракт — версия события отличается от закрепленной версии; 2. неизвестный агент — любая конечная точка находится за пределами утвержденного набора идентификаторов; 3. запретный край — заданный маршрут и вид взаимодействия не допускаются; 4. неоднозначный маршрут — одно и то же принадлежащее преимущество появляется более одного раза без явного правила множественности; 5. ложное завершение — у терминального родителя отсутствует ожидаемое преимущество или подтвержденное получение результата; 6. ожидающий — ожидаемое ребро отсутствует, именованная зависимость явная, срок не прошёл; 7. неполный — ожидаемое преимущество все еще отсутствует после истечения срока его действия; 8. здоров или работаю — наблюдаемый набор соответствует текущему плану, при этом «здоровый» зарезервирован для проверенного конечного результата. Заказ важен. Если теневой агент использует запрещенный маршрут, а родительский маршрут тоже опаздывает, «неполный» слишком слаб: оператору сначала необходимо содержать неутвержденную топологию. И наоборот, объявленное ожидание до истечения крайнего срока не является задержкой. Это здоровое состояние зависимости, которое должно достичь правильного владельца, не вызывая деструктивного сброса. Динамическая маршрутизация является основным ограничением. Система может законно выбирать среди специализированных агентов во время выполнения. Представьте этот выбор в виде ограниченного класса ребер или создайте точный план выполнения перед отправкой. Подстановочный знак, например orchestrator прост в обслуживании, но теряет большую часть диагностической ценности. Изменения версий должны быть проверяемыми, и при прогоне никогда не следует молча принимать новую версию на полпути. Выборка – это еще одна граница. Тяжелые трассировки могут быть выбраны, но компактные квитанции топологии, используемые для принятия решений о работоспособности, не могут исчезнуть в соответствии с той же политикой. Если требуемая квитанция отсутствует, сообщите об этом. uncertain или incomplete ; не восстанавливайте зеленый цвет по частичному следу. Повторите дрейф, прежде чем доверять завершению Я переиграл девять дел без содержания против контракта, приведенного выше. Фиксация включала в себя работоспособное завершение, текущую работу, законное ожидание, пропущенное преимущество после крайнего срока, устаревшую топологию, запрещенный прямой маршрут, неизвестный агент, дублирующее владение маршрутом и родительский терминал без уведомления о возврате. Детерминированный аудит соответствовал всем девяти ожидаемым состояниям. Наивное правило: существует хотя бы одно событие, статус каждого локального события ok , и родительский элемент не потерпел неудачу — отмечен все девять ящиков зеленые . Только один был здоров. Шесть из этих девяти наивных зеленых были небезопасными, неполными, устаревшими, неоднозначными или ложнополными; остальные двое работали и ждали, состояния, которые не следует сворачивать в законченное здоровье. Случай Все записанные события в порядке? Топологический вердикт Значение оператора : Полный график плюс квитанция о результатах Да healthy Запланированный график и конечный результат проверяются Текущие запланированные края Да working Полезная работа может продолжаться; не вмешивайся Отсутствие возврата до истечения срока Да waiting Уведомить или наблюдать за именованной зависимостью Тот же возврат отсутствует после истечения крайнего срока Да incomplete Исследуйте первое отсутствующее ожидаемое преимущество Старая версия топологии Да stale contract Перестаньте сравнивать пробег с неправильным дизайном Неутвержденный прямой маршрут Да forbidden edge Содержать маршрут перед повторной попыткой работы Неизвестный участник Да unknown agent Подтвердите личность и полномочия Повторяющийся маршрут Да ambiguous route Согласование прав собственности и возможных дублирующих эффектов Родительский терминал, возврат отсутствует Да false complete Снова откройте прогон; завершение не имеет необходимых доказательств Вы можете воспроизвести решение с помощью небольшой функции над нормализованными краевыми клавишами: Запускайте проверки топологии перед оценкой прогресса, качества или результатов. Затем сохраните границы вердикта явными: соответствие топологии доказывает лишь то, что была соблюдена утвержденная форма координации; working требуются новые доказательства полезного движения, а не просто новые события; waiting требует именованной зависимости и крайнего срока; healthy для завершения требуется детерминированный пункт назначения или квитанция о доставке, если таковая имеется; неопределенные доказательства должны оставаться неопределенными; любое активное восстановление требует ограниченных полномочий, прозрачности и проверки после действия. Это дает оператору правило узкого принятия: не доверяйте многоагентному завершению до тех пор, пока закрепленная топология выполнения, текущая фаза и получение окончательного результата не согласуются. График соответствия является необходимым доказательством, а не доказательством того, что ответ правильный. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Его общедоступный сайт раннего доступа и интерактивная демонстрация доступны, но производственный адаптер многоагентного мониторинга, сборщик работоспособности и средство автоматического восстановления не поставляются. Предполагаемая роль Sidewisp — добавить уровень работоспособности вокруг существующих сред выполнения и упростить проверку доказательств, серьезности, неопределенности и наиболее безопасных следующих действий, а не заменять среду выполнения или действовать без разрешения человека.