На тази страница
Да разгледаме илюстративна задача в браузър със сто стъпки. Да допуснем, че всяка успява в 99% от случаите, независимо от другите. Вероятността всички да успеят е 0.99^100, или около 36,6%.
Деветдесет и девет процента звучат отлично. Тридесет и шест процента не звучат така.
Обсъждането на транзакционна работа в браузър използва това изчисление за тесен извод: клиентът получава стойност, когато задачата приключи, а разходът и рискът от грешка се натрупват при всяка стъпка. Това е аритметика при дадено допускане, не публикуван процент на успеваемост за браузърен агент или синхронизация на Tajo. Реалните грешки може да зависят една от друга. Една изтекла сесия в системата може да провали няколко следващи действия наведнъж.
Затова полезният въпрос не е „Колко точно беше последното щракване на модела?“. Той е „Появи ли се състоянието, поискано от потребителя?“.
Важната единица е цялата операция
Представете си агент, който отваря застрахователен портал, намира документ, изтегля го и потвърждава, че принадлежи на правилния акаунт. Той може да премине правилно през 99 екрана и на стотния да изтегли грешен файл. Дневник, пълен с успешни щраквания, не поправя резултата.
Същата разлика важи и за интеграциите. Агентът може да открие API, да предложи съпоставяне на полета и да запази чернова. Нито едно от тези действия не означава, че контактът в целевата система вече има желаното състояние на съгласие. Работата е завършена едва когато одобрената операция е изпълнена и съответното крайно условие е проверено.
Това е разликата между дейност и завършване. Дейността се брои лесно. Завършването изисква определение.
За изтеглен файл определението може да е артефакт, чийто номер на акаунт съвпада със заявката. За синхронизация на контакт може да е запис в целевата система с правилен идентификатор, полета и разрешен статус за съобщения. Проверката трябва да прегледа това, което е било важно за потребителя. Зеленият отговор от предходното извикване доказва, че извикването е върнало отговор. Не е непременно доказателство, че целевата система се е променила както трябва.
Ръководството на Tajo за свързване на бизнес инструменти започва от работния процес и системата източник на истината за всеки обект. Тези решения дават смисъл на крайната проверка. Ако две системи едновременно претендират, че определят стойността на поле, дори безупречно изпълнен запис може да доведе до грешно дългосрочно състояние.
Цената на още едно решение
При същото хипотетично допускане за 99% десет независими решения дават около 90,4% успех на цялата верига. Петдесет дават около 60,5%. Сто дават около 36,6%.
Вероятност за успех на цялата верига (%)
Брой независими стъпки
- Допуснати 99% успех на стъпка
Преглед на изчислените стойности
| Стъпки | Успех на цялата верига (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
Кривата пада рязко, защото умножението не се впечатлява от добрата средна стойност. Всяко допълнително решение трябва да оправдае мястото си.
Това не означава, че всяко API извикване трябва да се слее в една огромна операция. Някои извиквания са детерминистични: изтегляне на страница с известен курсор, сравняване на идентификатор или запис на поле според одобрено съпоставяне. Не е нужно моделът отново да решава това за всеки запис. Други извиквания съдържат истинска неяснота: ново поле на доставчик, променено съобщение за грешка или заявка с неясен собственик. Там може да е нужна преценка.
Практичното разделение е преценката да проектира или поправи правило, а обикновеният код да прилага стабилното правило. Reverse ETL е полезен пример за повтарящо се преместване на данни: всяка рутинна операция върху ред трябва да се изпълнява от конвейера, не от разговор. Агент все пак може да помогне при решението какво трябва да прави конвейерът.
Това е граница, не лозунг. Ако доставчик промени значението на поле, детерминистично правило може безупречно да повтаря грешното действие. Системата се нуждае от начин да открие промяната в допусканията си и да върне случая за преглед.
Защо един голям инструмент не е отговорът
Справедливо възражение е: „Ако дългите вериги се провалят, сложете цялата задача зад едно извикване на инструмент“. Това помага, когато инструментът е добре определена операция с проверим резултат. Не помага, когато само скрива дълъг, несигурен процес.
Да допуснем, че syncCustomer() връща success: true след изпращане на актуализация. Ако целевата система обработва актуализациите по-късно, извикването още не може да докаже крайното състояние на контакта. Инструментът е намалил видимите стъпки. Не е намалил несигурността.
По-добрият интерфейс показва важните състояния: прието, приложено, проверено или неуспешно. Тези думи трябва да отговарят на доказателства. Приет запис може да е достатъчен за предварителен преглед с нисък риск. Аудитория на кампания или промяна на съгласието изисква проверка в целевата система, преди някой да обяви задачата за завършена.
В този предложен изглед на Tajo приетата заявка и приложената промяна са отделни от потвърденото състояние в целевата система. Последната проверка предстои. Това дава цел на следващото действие: да се види какво е записала целта. Още едно успешно извикване на инструмент би оставило първоначалния въпрос без отговор.
Извършеният запис все още се нуждае от доказателство
Приключи ли синхронизацията на клиентите?
Записът е приложен. Проверката предстои.
Състоянието в целевата система още не е проверено.
Активност на синхронизацията
- Заявката е приета
- Промяната е приложена
- Проверката в целевата система предстои
Примерно изпълнение · 14:32 UTC
Какво знаем
- Отговор от доставчика
- Приета
- Резултат от записа
- Приложен
- Прочитане от целевата система
- Предстои
Успешното извикване не доказва крайното състояние.
Предложен изглед, основан на активността в Tajo. Илюстрацията добавя състояние на проверка; тя не твърди, че повторното прочитане от целевата система вече е реализирано.
Това променя и измерването. Записвайте броя опити, ако помага да откриете разхода. Записвайте междинните грешки, ако насочват към повредена стъпка. Но оценявайте процеса по проверените завършени операции, като посочвате метода на проверка до числото. Екип, който съобщава „99% от извикванията успяха“, не е отговорил дали клиентите са свършили работата си.
Обяснението на MCP сървърите показва как инструментите позволяват на асистент да извиква друга система. Достъпът до инструменти е само началото. Договорът е състоянието, което остава след това.
Сто добри щраквания пак може да не оставят нищо. Бройте резултата.
Често Задавани Въпроси
Защо дълъг процес се проваля, когато отделните стъпки обикновено са правилни?
Ако всяка стъпка успява независимо с вероятност p, целият процес от n стъпки успява с вероятност p на степен n. При допуснати 99% на стъпка сто стъпки завършват в около 36,6% от случаите. Реалните грешки може да са свързани, затова изчислението е илюстрация, а не измерена честота за агенти.
По-малко извиквания на инструменти гарантират ли надеждност?
Не. По-малкият брой помага само ако общата операция запазва нужните проверки и точки за възстановяване. Едно непрозрачно извикване може да скрие неуспешен запис също толкова лесно, колкото дълга поредица може да загуби контекст.
Какво трябва да измерва екипът за процес с агент?
Измервайте провереното завършване на поисканата от потребителя операция, а не само успешните извиквания на модела. Определете артефакта или състоянието в целевата система, което доказва завършването, и следете колко често се получава след целия процес.