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

Таа разлика е важна за бекенд тимовите. Четбот може да толерира повремен нејасен одговор. Агент што создава тикети за поддршка, усогласува фактури или менува податоци за клиенти не може. Намерното дејствување бара експлицитни граници, трајна состојба, набљудливо однесување и справување со неуспеси што е дизајнирано исто толку внимателно како и интеракцијата со моделот.

Почнете со ограничена задача, а не со цел за општа интелигенција

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

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

• Влезови: настанот, идентитетот на корисникот, контекстот на закупецот и дозволените изворни податоци.
• Излези: структуриран резултат, како што е нацрт, препорака или команда ставена во редица.
• Овластување: точните дејства дозволени за овој работен тек.
• Услови за излез: успех, ескалација, одбивање, истек на време или неуспех што може повторно да се проба.

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

Одделете го расудувањето од извршувањето

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

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

{
  "action": "request_refund",
  "order_id": "ord_4821",
  "reason": "duplicate_charge",
  "amount": 49.00,
  "currency": "USD"
}

Вашата апликација потоа треба да провери дали дејството е познато, дали нарачката му припаѓа на тековниот закупец, дали износот е валиден и дали актерот го има потребното овластување. Таа треба и да ги примени деловните правила што не припаѓаат во промпт, како што се роковите за рефундирање, статусот на плаќањето и праговите за одобрување.

Во PHP, ова често значи третирање на излезот од моделот како недоверлив влез. Парсирајте го во DTO, валидирајте го и насочете го низ апликациска услуга, наместо да дозволите кодот на агентот директно да пристапува до репозиториуми или надворешни клиенти.

$command = RefundRequest::fromArray($modelOutput);
$validator->validate($command);

if (!$policy->canRequestRefund($actor, $command)) {
    throw new AuthorizationException();
}

$refundService->request($command, $idempotencyKey);

Моделот може да помогне при изборот на патека; детерминистичкиот код останува одговорен за нејзиното спроведување.

Дизајнирајте ги алатките како јавни API-ја

Алатките се рацете на агентот. Секоја од нив заслужува иста грижа како API што го користи друг инженерски тим. Дајте им тесни имиња, типизирани параметри, предвидливи одговори и експлицитни кодови за грешки. Избегнувајте нејасна алатка како run_database_query кога наменски изработена find_open_invoices или create_invoice_draft е доволна.

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

Направете ги запишувањата идемпотентни

Агентите може повторно да се обидат по мрежни неуспеси, истеци на време кај добавувачот или рестартирања на процесот. Без идемпотентност, повторниот обид може да создаде дупликат тикети, да издаде дупликат рефундации или да испрати повторени известувања.

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

Состојбата е дел од производот

Самата историја на разговорот е лоша база на податоци. Таа е скапа, нецелосна, тешка за пребарување и склона да пренесува застарени претпоставки. Чувајте ја оперативната состојба во вашата база на податоци: статус на работниот тек, повици на алатки, одобрувања, идентификатори за корелација, повторни обиди и конечни исходи.

Практичен дизајн користи траен запис за работен тек заедно со додатна трага од настани. Записот за работниот тек одговара на прашањето: „Што се случува сега?“ Трагата од настани одговара на: „Како стигнавме овде?“ Заедно, тие поддржуваат опоравување, истраги за поддршка и насочени подобрувања.

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

Планирајте за неизвесност и неуспех

На агентот треба да му биде дозволено да каже, во системски термини, „Не можам безбедно да продолжам“. Тоа е карактеристика, а не слабост. Изградете експлицитни гранки за недостасувачки информации, класификации со ниска доверба, недостапни зависности, конфликти со политики и дејства што бараат одобрување.

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

За долготрајна работа, користете редица и worker наместо да држите HTTP барање отворено. Docker го прави ова раздвојување едноставно: извршувајте ги веб-процесот и worker-от како одделни услуги, дајте им на двата иста слика на апликацијата и конфигурирајте проверки на здравјето околу зависностите што навистина им се потребни. Worker-от може да продолжи со трајните задачи по рестартирање; агентот врзан за барање не може.

Набљудувајте ги дејствата, не само одговорите

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

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

Евалуацијата треба да се фокусира на оперативните исходи. Може ли агентот да ја избере точната алатка? Дали одбива забранети дејства? Дали се опоравува од дупликат испорака? Дали ескалира кога е потребно? Мал сет репрезентативни сценарија, вклучувајќи случаи на неуспех, е повреден од дотеран демо-разговор.

Градете агенти што постепено стекнуваат овластување

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

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