AI-агент пред испраќање е-пошта: паузата мора да ја зачува состојбата

За AI-агент да не испрати е-пошта без човечка проверка, поставете задолжително одобрување пред алатката што ја испраќа пораката. Паузата треба да ја зачува точната верзија на нацртот и одлуката за неа. Одбивањето или истекувањето на рокот треба да ја затвори патеката кон испраќање.

Одобрувањето нека важи за конкретно дејство: определени примачи, наслов, текст и прилози. Ако агентот смени нешто од тоа по прегледот, изменетата верзија повторно оди на одобрување. Потребен е и посебен запис за испраќањето, бидејќи зачуваната пауза сама по себе не спречува повторен повик кон услугата за е-пошта.

Која состојба се зачувува пред проверката

Замислете условен тек во кој агентот подготвува одговор на барање од клиент. Пред проверката зачувајте ги идентификаторот на барањето и целосниот нацрт: примач, копии, наслов, тело и идентификатори на прилозите, ако ги има. Лицето што одобрува треба да ја види истата содржина што ќе ја добие клиентот.

Доделете му на нацртот верзија или контролна сума и врзете ја одлуката за неа. Запишете кој одлучил, кога одлучил, кој рок важел и дали исходот е одобрено, одбиено или истечено. При измена на текстот или примачот создајте нова верзија; старата дозвола повеќе не важи за испраќање.

Рокот е правило на вашиот работен тек. Кога ќе истече, не дозволувајте задоцнет клик да ја испрати пораката: затворете го обидот и, ако пораката сè уште е потребна, побарајте нов преглед. Проверете го рокот и непосредно пред повикот за испраќање, затоа што барањето можело да чека додека друг дел од текот бил во прекин.

Визуелна конфигурација во n8n

Упатството на n8n за Human review опишува пауза пред AI Agent да изврши избрана алатка: прегледувачот ги гледа нејзините параметри, а одобрениот повик се извршува со влезот што го предложил агентот. При одбивање, тој повик се откажува и агентот добива известување за одлуката. Затоа алатката за испраќање треба да биде поврзана со чекорот за проверка, без друга патека преку која агентот може да ја повика.

1. Нека агентот состави нацрт и зачува верзија со сите полиња потребни за конечната порака. Во барањето за одобрување прикажете ги целосниот примач, копиите, насловот, телото и прилозите, а не само општ опис на дејството.
2. Отворете го панелот Tools на AI Agent, додајте Human review, изберете канал за одобрување и поврзете ја алатката за испраќање со тој чекор. Одредете кој смее да одобри и поврзете го неговиот одговор со зачуваната верзија на нацртот.
3. По одобрувањето споредете ги параметрите на повикот со зачуваната верзија и проверете го рокот. Одбивање, истекување или несовпаѓање нека ја заврши таа патека без испраќање.

Ако Gmail служи како канал за барањето, разликувајте го известувањето до прегледувачот од конечната порака до клиентот. Описот на Gmail операциите во n8n наведува дека Send and Wait for Approval прво испраќа порака до наведениот примач, па го чека неговиот одговор пред текот да продолжи. Тој примач нека биде лицето што одобрува; по неговата одлука, одделен чекор ја испраќа одобрената порака до клиентот. Самото име на операцијата не ја проверува содржината на конечната порака.

Истата контрола во LangGraph

Во LangGraph поделете го текот на јазли за подготовка, човечка одлука и испраќање. Примерот со е-пошта во документацијата на LangGraph користи interrupt(), checkpointer и ист thread_id за зачувување на состојбата и подоцнежно продолжување. Кодот пред interrupt() во истиот јазол може повторно да се изврши при продолжувањето, па повикот за испраќање припаѓа во посебен јазол по одлуката.

Следниов псевдокод ги прикажува правилата за условниот тек. Складиштето за одлуките и записот за испраќање се делови што треба да ги изградите во сопствената имплементација:

1. prepare(state): состави нацрт, зачувај ја неговата верзија и запиши дека чека преглед; потоа насочи кон review.
2. review(state): повикај interrupt() со верзијата, примачите, насловот, телото, прилозите и рокот. По продолжувањето провери го идентитетот на прегледувачот, рокот и совпаѓањето на верзијата.
3. Ако одлуката е одбивање или рокот истекол, запиши го исходот и заврши. Ако прегледувачот изменил нешто, зачувај нова верзија и врати ја на преглед. Само непроменет, важечки одобрен нацрт насочи кон send.
4. send(state): провери го записот за обидот врзан за барањето и верзијата. Ако испраќањето е потврдено, заврши; ако исходот од претходен повик е непознат, задржи го обидот за проверка. Во спротивно испрати и зачувај го добиениот идентификатор на пораката.

Започнете го текот и продолжете го со истиот thread_id за checkpointer да ја пронајде соодветната состојба. За тек што мора да преживее рестартирање, користете трајно складирање наместо состојба само во меморија. Одобрувањето треба да биде дел од зачуваниот запис за нацртот, а не само од одговорот што моментално го обработува јазолот.

Што се случува ако испраќањето се прекине

Најтешкиот случај настанува кога услугата ја прифатила пораката, но текот се прекинал пред да го зачува резултатот. По продолжувањето локалниот запис може да изгледа како испраќањето допрва да треба да се случи. Повторен повик во таа состојба може да создаде втора порака иако човечката одлука била дадена само еднаш.

Чувајте посебен запис за обидот со идентификатор на барањето, верзија на нацртот, статус и идентификатор што го вратила услугата, кога е достапен. Дозволете само еден извршувач да го преземе истиот обид. Ако услугата поддржува соодветен механизам за спречување повторени барања, употребете го; проверката на локалниот статус сама по себе не го решава прекинот меѓу прифаќањето на пораката и запишувањето на резултатот.

Кога исходот е непознат, означете го обидот за проверка наместо веднаш повторно да испратите. Утврдете дали пораката е прифатена преку достапниот одговор од услугата или преку евиденцијата на испратени пораки. Записите за нацртот, човечката одлука, обидот и конечниот исход потоа овозможуваат да се види што точно било одобрено и дали тоа дејство веќе се случило.