AI-агенты супраць традыцыйнага бэкэнду: паток кіравання, кошт і збоі

Інжынерыя бэкэнду ўжо давно павяржаюцца ў адну важлівую якосць – дэтэрмінізм. Як толькі напісаце эндпоінт, які прыме замовленне, пераканае стан залягання тавароў у PostgreSQL і здзейсніць платэж праз карцу за дапамогою Stripe, той самы алгорытм будзе выкананы ў кожны раз. З тымі ж вхіднымі данымі і тым жа станам базы дадзеных лінія 42 завжды выканаецца раней за лінію 43.

Тады галузь пачала называць агенты AI наступным этапам бэкэнд-сістэм. Лёгкаа ўсё гэта прыйміць за маркетынг, адколі агент таксама выглядае як служба ў кантэйнерэ, якая вызывае зовнішніе API і запісвае даныя ў базу дадзеных. Аднак у глыбі рэчаў логіка керавання зменілася. У класычным бэкэндзе распрацоўшчык загадзя выправляе кожны крок, варыянт і крайнія случаі. У агэнце распрацоўшчык задае мету і набор засобаў, а верагатычны модэль выбірае крокі, ўпорадкаванне і момент завершэння задання. Якшо ставіцеся да агэнца як да ўсё толькі ўжо аднаго мікрослужбы, вы станесцеся да серьёзных проблем з затрымкамі, надзеямасцю, тэставаннем і рахункамі за хмарныя сервісы.

Фіксаваны пайплайн проты ціклу разумовання

Стандартны бэкэнд обрабоцвае запыт праз спрамаваную ацыклічную графіку, якую програміст задае як жорсткі код:

[Request] ──> [Validate Input] ──> [Database Query] ──> [Transform Data] ──> [Response]
                     │
                     └── (Invalid) ──> [Return 400]

Кожны розгалужэнне, чыя бы то ні было if/else, switch чы try/catch, вылічваецца загадзя. Код не можа стварыць крок, які вы не напісалі. Неапэктыванный вхід спрычынае адказку чы загадзя заданыя захады.

Агент не следуе статычнай лініі. Ён функцыонуе ў цыкле часовай експаніяцыі, які часта будуецца на патэрне ReAct – скрацанні з Reason plus Act. Бэкенд перадае керуванне большаму мовнаму модэлю:

┌────────────────────────┐
                       ▼                        │
[Objective] ──> [LLM Evaluates State]           │
                       │                        │
             Does it need more info?            │
             ├── Yes ──> [Select Tool & Arguments]
             │                  │
             │           [Execute Tool] ────────┘
             │           (API, DB, Search)
             │
             └── No  ──> [Return Final Answer]

Адзін цыкл складаецца з чатырох частакоў:

• Модэлю дааецца цялё, кантэкст і дзеянні, якія былі выкананы ўжо.
• Ён спытаецца, чыяму ёсць достатнёк інфармацыі, чыму трэба зусільнае адзінство.
• Калі ёму трэбны даны, ён выдае структураваны запрос да адзінства, напрыклад, чытанне файла, вызов API або запуск запіту.
• Ваша сістэма выканання запускае адзінство, кладзе неасоблёваны выход у вікно кантэксту модэля і пачынае цыкл зноў.

Важны тое, што модэль дынамічна выбірае последоўнасць крокаў пад час выканання.

Прыклад: вярненне грошаў за запаздзелы адправленні

Рассмотрзіце внутраняе адзінство, якое вярнае грошы клёянцу, чыя адправка запаздалася.

Традыцыйны спосаб

У сервісе Express або FastAPI вы моглі бы напісаць працоўнік, які шукае замовленне, прыменяе строгія правіла, выдае вярненне грошаў і адправляе паведамленне:

// Traditional Backend: Strict, deterministic logic
async function handleRefund(orderId: string, customerReason: string) {
  const order = await db.orders.findById(orderId);
  if (!order) {
    throw new NotFoundError("Order not found");
  }

  // Strict business rule written by an engineer
  const isEligible = order.status === "DELAYED" && order.daysDelayed > 5;

  if (!isEligible) {
    return { status: "rejected", reason: "Delay does not meet refund criteria." };
  }

  const refund = await paymentGateway.refund(order.paymentIntentId);
  await db.orders.update(orderId, { status: "REFUNDED" });
  await emailService.sendRefundNotice(order.customerEmail);

  return { status: "success", refundId: refund.id };
}

Эты код выкананы за меней 100 мілісекунд, не купае практычна ніякіх зусіль на апрацоўку дадзеных і працюе аднакова кожны раз. Але ён таксама ўразлівы. Падазроўцуймо, кліент піша, што пакет прыбыў у час, але водзіль перэяхаў по поштовай скрынцы. Сістэма адхоўляе вярненне грошаў, таму што daysDelayed доравна нулю, адтак у ўсіх яе жорсткаях правілах нема можлівасці робіць выводы за межамі іх.

Метод агента

Агент сам выбірае, якія інструменты выкорыстаць, на адной з падстав — адказ кліента:

// Agent Loop: The model decides which tools to call
import { generateText, tool } from "ai";
import { z } from "zod";

const tools = {
  fetchOrder: tool({
    description: "Fetch order details and shipping history",
    parameters: z.object({ orderId: z.string() }),
    execute: async ({ orderId }) => db.orders.findById(orderId),
  }),
  issueRefund: tool({
    description: "Issue a monetary refund to the customer",
    parameters: z.object({
      paymentIntentId: z.string(),
      amount: z.number(),
      reason: z.string()
    }),
    execute: async (args) => paymentGateway.refund(args.paymentIntentId, args.amount),
  }),
  escalateToHuman: tool({
    description: "Escalate edge cases or physical damage to a support manager",
    parameters: z.object({ ticketSummary: z.string() }),
    execute: async ({ ticketSummary }) => supportDesk.createEscalation(ticketSummary),
  })
};

// The execution is governed by an evaluation loop
const response = await generateText({
  model: yourConfiguredLLM,
  tools,
  maxSteps: 5, // Prevents infinite execution loops
  prompt: `Customer Issue: "The package arrived on time, but the driver ran over my mailbox. Order #1234."
           Evaluate policy guidelines and take appropriate action.`,
});

Хутчэй мадэль чытае працоўню, запрашвае замовленне, бачыць, што проблема — гэта падбіянне майна, а не логістыка даставкі, прахоўвае звычную пераканальню ў вярненне грошаў і вызывае escalateToHuman. Такая гнучкасць мае свой кост. Для выкаання патрэбна была трохі аперацый з LLM, спалоўваўся каля калькі сэнтав токенаў, і ўсё гэта займала 4 секунды, тады калі аператару хватала 50 мілісэкунд.

Як яны параганяюцца

Працоўныя прыпускі практычна ўсе зміняюцца, калі пераходзіш ад дэтэрміністычнага бэкенда да агентскай сістэмы.

• Тэкст керавання: у аднам случае код візначае этапы, тады калі ў іншам LLM выбірае іх у рамках ціклу.
• Шлях выкаання: у варыянцы з бэкендам відомы ў момент компіляцыі, тады калі ў агентскай сістэме — выкрываецца пад час рантайму.
• Затрымка: у бэкендзе яна становіць ад 10 да 200 мс і ўможна прыкладзіць, тады калі ў агентскай сістэме — ад 2 да 30 секунд чы і больш, і яна змінюецца залежна ад колькасці ітэрацый.

Білі моменты невдач: сінтаксічні помілкі, некеровані віняткі і значэння null для бэкендыв, а таксама неправільні аргументы, нескінчэнні цыклі і недотрымання обмежэнь для агентаў.

Тэстування: модульні, інтэграційні і повні перэвіркі з вікорыстанням LLM як судды, крытэрыі оцінкі і семантычні перэвіркі.

Стан: транзакційні даныя SQL чы NoSQL проты історыі розмов, обмежэнь вікна кантэксту і працюючоі памяці.

Вітраты: вікорыстання CPU і памяці, які ёсць стабільнімі і недорогімі, проты колькасці вхідніх і віхідніх токенів на кожну ітэрацію цыклу, якая можа швідко зростаты.

Вікно кантэксту як працююча памяць

Бэкенд зберагае стан у вялічыні, ключох Redis або рэканах базы дадзеных, а функцыя чытае толькі тыя поля, якія ёй патрэбны. Для агента вікна кантэксту ўособлівае ся калякатковай памятчукою. Калі запускаецца інструмент, яго выход серыяваны ў тэкст, зазвычай у фармаце JSON, і дадаўся да історыі запітоў. Тыповы цыкл развіваецца так:

• Шаг 1: запіт корыстніка, адпаведна 50 токэнаў.
• Шаг 2: запрос мадэлі да інструмента, адпаведна 40 токэнаў.
• Шаг 3: рэзультат інструмента, які дадае прыблізна 500 токэнаў.
• Шаг 4: мадэль аналізуе большы запіт і выканае другі вызов, дадаючы ўсьмо 80 токэнаў.
• Шаг 5: прыходзіць другі рэзультат, які дадае прыблізна 1 200 токэнаў.

З кожным цыклам запіт становіцца большым. Паколькі і цена, і час адпаведзення залежаць ад размеру вхідных дадзеных, пяты шаг ўсьмо медленней і дорожэ, чым першы.

Частая памылка ў працэсе стварэння — вярненне цэлых радоў базы дадзенаў або вельмі большых пакетаў даных API да агента. Калі інструмент searchUsers() выкарыстоўвае 50 цэлых профіляў у кантэкст, то ўскора будзе выкарана эфектывае вікно для рашэння мадэлі. Дзяржаць інструменты агентаў падобна да публічных API: трэба скорачваць і чыставаць выходныя даны, каб у яных былі толькі тые поля, якія мадэлі неабходны для наступнага рашэння.

Чаму агенты важкая працаваць

Праблемы з бэкендам даюць васу стэк-трэйс. Вы запускаеце той самы пакет даных локальна, пераглядаеце зменныя і вылечваеце баг. Агенты ж працуюць з павышэнным рызыкам неудачы.

Бесканцэскія петлі. Падзейваець вызывае API і атрымлея незначныя памылкі паўтарання, такія як invalid_date_format. Ён прабуе знову, але з аднойчы не тым фарматам даты, а потым знову. Калі няма чыстае межы для колькасці прабоўкаў (maxSteps), ён можа запрацаваць сотні долераў на крэдытах API, спробаваўшы пераканаць прыстрой для паўтарання.

Вымышленыя параметры інструментаў. Схемы і працэсы паўтарання забезпечваюць стабільнасць тыпаў у звычным кодзе пад час выканання. LLM можа ствараць правільны JSON, які адпавядае вашай схеме 98% часоў, але часам дадае вымышлены параметр. Тое, чаго вы маглі бы чакаць:

// Expected:
{ "customerId": "cust_123", "amount": 50 }

Што іноды выдае мадэль пры высокай тэпературэ:

// What the model occasionally outputs under high temperature:
{ "user_id": "cust_123", "refund_value": "$50.00" }

Калі сістэма выканання не будзе прыменяць строгую парсацію схемы з адпамянанням такіх інструментоў, як Zod чысто Pydantic, пры выкананні рэальной функцыі, ваш бэкенд зламаецца.

Непрадбачальна маршрутацыя. Запіт, які вчора выкаанаваўся за два крокі, сёння можа выкаанавацца за чатыры, таму што корыстнік сформулюваў яго адносна інача. Чыраго чыну стае важка даваць гарантыі па часу адпаведзення.

Выбір правільнай архітэктуры

Агенты прывлекаюць так многа увагі, што распрацоўшчыкі прабуюць ствараць цэлыя сістэмы на ўсіх іх, што являецца дорогай памылкой.

Застаўцеся з звычным кодам бэкенду, калі:

• Бізнес-логіка ўжо вядома і стабільна, як у разе выставлення рахункоў, аўтэнтыфікацыі, операцый CRUD і расчытку каштыка.
• Неабходна нізкая затрэмленасць, як у працэсах платэжаў, автодаполненні пошуку і рэальным часам перадачы паведамленняў.
• Памылкі можу прынесці рызыкі для састаноў правілаў чысто фінансавага характару, як у разе ведачы бухгалтэрскіх дакументаў, медычных карт і прыменення прав на доступ.

Кошт за адзін запыт мае значэнне, калі працоўваецца з велікімі обсягамі дадзеных, напрыклад, пракроцаваннем мільйонав эвэнтаў за гадзіну.

Зверніцеся да агента, калі:

• Шлях да рашэння ёсць неясным, напрыклад, калі трэба знайсці рэйс з трычыстахвілінным перашчэпкам, вегетарыянскімі сталакамі і цэнай менш чым 800 долераў.
• Даныя ёсць неупорадкованымі і без структуры, напрыклад, розныя PDF-расчытанні, электранаўпысы у свабодным фармаце або адчуванні кляўэнтав пра багі.
• Сістэма должна коордынаваць розныя інструменты без спакульнае API, напрыклад, перэгляд зовнішняйх сайтаў, аналіз дакументацыі, якую ён знаходзіць па дарозе, або сортаванне проблем між калькама продуктаў.

Гібрыдны дызайн, які работае

У рэальных прыемленах найболей надзеяным дызайнам рэдка яўляецца чысты агент. Гэта дэтэрміністычны бэкенд з агентам, які знаходзіцца ў контролюемых межах:

[Incoming Request] ──> [Traditional API Gateway] ──> Authentication / Rate Limiting
                              │
                              ▼
                      [Standard Business Logic] ──> Fast DB Reads / Validation
                              │
                              ▼
                    [Targeted Agent Boundary]  ──> Handles unstructured task
                              │                    (Restricted to 3 safe tools)
                              ▼
                      [Standard Business Logic] ──> Validates agent output
                              │
                              ▼
[Final Response] <─── [Structured DB Write]

Зберагаеце механізмы направлення трафіку, автарызацыі, зберагачвання дадзейнаў і крытычнай перакананні ў правамернасці бізнес-працы ў дэтэрміністычным кодзе. Апыляйце агента толькі для падзадання, якое сапраўды выкарыстоўвае аналіз на кшталт чалавечага і свабодную організацыю інструментаў.

Усьмоўленне

Агент не ўлучшыць традыцыйны бэкенд. Гэта іншая парадыгма апрацоўкі дадзейнаў. Бэкенды прагтуюць прыведамасць, швальнасць і нізкія косты, выконваючы чыстае адказванне на інструкцыі, тады як агенты прагтуюць адлагоджанасць і рашэнне проблем, дазваляючы LLM выбіраць шлях выканання ў цыкле аналізу.

Таму, пры стварэнні наступной функцыяльнасці, не задавайцеся пытаннем, чы можа агент гэта зрабіць, калі ў яго ёсць достатнькі токены — верагодна, ён зможа. Задайцеся пытаннем, чы вядомы вам ужэ крокі, неабходныя для рашэння проблемы. Калі так, напісце код самі і застаўце агентыв для проблем з незаканчанымі рашэннямі, якія звычайны код ніколі не мог ўсталяць належна гнучка.