Mga Uri ng AI Agent: Simple Reflex, Learning at Iba Pa

Ano ang mga uri ng AI agent

Ang mga uri ng AI agent ay nagmumula sa isang taxonomy: simple reflex, model-based reflex, goal-based, utility-based, at learning agent. Inilalarawan ng bawat pangalan ang isang bagay: kung gaano karami ang naaalala ng agent at kung gaano kalayo ang pagpaplanong ginagawa nito bago kumilos. Ang dalawa pang termino na multi-agent at hierarchical ay naglalarawan kung paano pinagkakabit ang ilang agent, hindi kung paano nagpapasya ang alinmang indibidwal na agent.

Mas luma ang listahang iyon kaysa sa alinmang model na ginamit mo. Nagmula ito sa standard na textbook tungkol sa AI. Nananatili itong kapaki-pakinabang matapos dumating ang large language models dahil itinatanong nito ang tanong na patuloy na nagpapasya sa iyong design: ano ang kailangang malaman ng bagay na ito bago ito kumilos? Kung sinusubukan mo pa ring tukuyin kung saan nagtatapos ang isang agent at nagsisimula ang isang chat assistant, basahin muna ang pagkakaiba ng AI agent at LLM na pinapatakbo nito. Nagsisimula ang page na ito pagkatapos ng puntong iyon.

Mga simpleng reflex agent: isang kondisyon, isang aksyon

Iniuugnay ng isang simpleng reflex agent ang kasalukuyang input sa isang aksyon at wala itong memorya ng anumang naunang pangyayari. Kung lampas 25 ang temperatura, i-on ang fan. Iyon ang buong mekanismo.

Halos tiyak na nakagamit ka na ng ganito. Ang webhook na nagti-trigger ng isang n8n workflow, nagbabasa ng form submission, at nagsusulat ng row sa database ay isang simpleng reflex agent. Mananatili itong ganoon kahit may language model sa pagitan na pumipili ng category para sa row na iyon. Kapag tinanong mo ito kung ano ang ginawa nito isang oras ang nakalipas, hindi nito masasabi, dahil walang nag-save ng sagot.

Mas madalas na tama ang ganitong uri kaysa sa inaasahan ng mga tao. Mura itong patakbuhin, at malinaw ang failure nito: tumugma ang kondisyon, o hindi. Kapag ang tunay na trabaho ay “kapag dumating ang X, gawin ang Y,” nagdaragdag ang memorya ng mga posibleng pagkakamali nang walang pakinabang. Ang n8n agent na na-trigger ng webhook ay ganitong bahagi ng taxonomy na may user interface sa ibabaw.

Bumabagsak ito sa sandaling nakadepende sa history ang tamang aksyon. Kokontra sa sarili nito sa ikatlong mensahe ang isang reply bot na walang thread state, dahil hindi kailanman naging bahagi ng input nito ang unang dalawang mensahe.

Mga model-based reflex agent: pagpapanatili ng state sa pagitan ng mga event

Ang model-based reflex agent ay may internal na larawan ng environment nito at ina-update ang larawang iyon kapag may bagong input. Ang ibig sabihin ng “model” dito ay model ng mundo, hindi neural network. Mas nauna ang terminong ito nang humigit-kumulang forty years kaysa sa kasalukuyang kahulugan nito, kaya nakalilito ito sa halos lahat sa unang pagbasa.

Model-based ang isang home automation rule na nag-o-off ng mga ilaw kapag walang motion sa loob ng twenty minutes. Kailangan talaga itong model-based. Pareho ang input na “walang motion ngayon” at “walang motion mula 21:40” para sa isang simpleng reflex agent, kaya stored state lamang ang makapaghihiwalay sa dalawang ito.

Sa bersiyong LLM, ito ay anumang agent na may memory store sa likod nito: isang rolling conversation summary, o isang plain markdown file na binabasa ng agent sa simula ng bawat run. Ang local memory service para sa isang agent ay isang naka-package na bersiyon ng ideyang ito. Hindi nagbabago ang mekanismo. Nananatili ang larawan ng agent tungkol sa mundo kahit tapos na ang event na lumikha rito.

May kapalit ang state. Mas masahol ang lumang fact kaysa sa walang fact, dahil kumikilos ang agent batay rito nang buong kumpiyansa at walang warning. Anumang ise-save mo ay kailangang may paraan para mag-expire o ma-check muli. Kung wala, patuloy na mangangatwiran ang agent tungkol sa server na dinecommission mo noong March.

Mga agent na nakabatay sa goal: pagpaplano patungo sa state na maaari mong i-check

Tumatanggap ang agent na nakabatay sa goal ng target state at naghahanap ng sequence ng mga action na makararating dito. Gumagana ito nang paurong mula sa dapat nitong kalabasan, kaya hindi paunang isinusulat ang path.

Ang coding agent ang pinakamalinaw na halimbawang maaari mong patakbuhin mismo. Walang tinutukoy na file o hakbang ang “Make the failing test pass.” Binabasa ng agent ang test, bumubuo ng plan, nag-e-edit ng isang bagay, nagpapatakbo ng test, binabasa ang error, at sumusubok muli. Nagtatapos ang loop sa isang check na aktuwal nitong maisasagawa. Ito ang dahilan kung bakit gumagana ang instruction na iyon, samantalang hindi gumagana ang “improve this code.” Ang goal na kayang i-evaluate ng agent ay goal na kaya nitong maabot. Ang goal na hindi nito kayang i-evaluate ay nagiging walang katapusang loop na may kalakip na bill. Sa Pagpapatakbo ng coding agent sa sarili mong VPS, inilalagay ang loop na iyon sa lugar kung saan maaari itong patuloy na tumakbo nang hindi inaabala ang laptop mo.

Sa row na ito nakikita ang cost. Bawat planning step ay isa pang model call na may dalang history hanggang sa puntong iyon. Kaya ang ten-step task ay hindi basta ten times ang presyo ng isang step; mas mataas ito. Ang mahalagang engineering ay ang hugis ng loop at ang condition na magpapatigil dito. Ito ang paksa ng loop engineering.

Mga agent na nakabatay sa utility: pagpili sa ilang mahusay na sagot

Binary ang isang goal. Score ang utility. Humaharap ang isang utility-based agent sa ilang katanggap-tanggap na resulta at pinipili nito ang may pinakamataas na score ayon sa function na isinulat mo.

Utility problem ang isang backup job na kailangang matapos bago magsimula ang araw ng trabaho nang hindi naso-saturate ang uplink. Walang iisang tamang sagot; may trade-off lamang. Ganito rin ang sitwasyon sa isang router na nagpapasya kung aling model ang hahawak sa bawat request habang tinitimbang ang presyo laban sa kalidad ng sagot.

Hindi ang algorithm ang pinakamahirap na bahagi. Ang mahirap ay ang pagsulat ng tapat na utility function. Kung cost lang ang gagamitin sa pag-score, palaging pinakamurang model ang pipiliin sa bawat request, pati sa request na nangangailangan sana ng mas mahal na model. Eksaktong ino-optimize ng system ang sinukat mo. Nagiging problema ito kapag pinili ang sinusukat dahil madali itong sukatin.

Mga learning agent: ang uri na ipinapalagay ng karamihan na mayroon na sila

Binabago ng isang learning agent ang sarili nitong behavior batay sa feedback tungkol sa mga nakaraang resulta. Kailangan nito ng component na sumusuri sa outcome at ng component na nagbabago sa policy bilang tugon dito.

Napakakaunti ng self-hosted system ang pasok sa depinisyong ito. Ang agent na nagbabasa ng mga note na isinulat nito noong nakaraang linggo ay isang model-based agent na may memory file. Pareho pa rin ang weights nito. Pareho pa rin ang policy nito. Hindi learning ang retrieval, at praktikal ang pagkakaibang ito: inuulit ng memory-based system ang isang pagkakamali magpakailanman maliban kung may mag-edit sa memory, samantalang dapat tumigil sa pag-uulit ng pagkakamali ang learning system.

Kung kailangan mo ang learning half, unahin ang pagbuo ng evaluation. Ang scored test set, isang run ng pagbabago mo laban dito, at desisyong panatilihin o itapon ang pagbabago ay bumubuo ng closed loop kung saan ikaw ang learning component. Mas mabagal ito kaysa sa inaakala, at ito ang tanging bersyong gumagana ngayon gamit ang mga self-hosted na bahagi. Dito nagsisimula ang pag-self-host ng eval harness.

Mga multi-agent at hierarchical system: mga arrangement, hindi mga uri

Hindi ito pang-anim at pang-pitong uri. Inilalarawan ng mga ito kung paano inaayos ang mga agent.

Ang multi-agent system ay sabay-sabay na nagpapatakbo ng ilang agent sa loob ng isang shared environment, gaya ng queue o git repository. Dahil shared ang environment, nagkakaroon ng conflict ang mga agent dito. Ang karaniwang failure ay kapag dalawang agent ang nag-e-edit ng iisang file. Ang solusyon ay lock o work queue. Walang prompt na makalulutas nito.

Ang hierarchical system ay naglalagay ng supervisor sa ibabaw ng mga worker. Hinahati ng supervisor ang task, ipinapamahagi ang mga bahagi, at pinagsasama ang mga resulta. Sikat ito dahil tugma ito sa paraan ng paghahati ng trabaho ng mga tao. Magastos ito dahil lumalaki ang context ng supervisor sa bawat report na binabasa nito. Ipinapakita ng multi-agent harness kung paano ito ikinakabit sa aktuwal na setup.

Mas mainam ang isang agent na maaasahang gumana kaysa apat na kadalasang gumagana.

Bawat handoff ay posibleng mapag-iwanan ng impormasyon. Magsimula sa isang loop. Hatiin lamang ito kapag matutukoy mo kung aling step ang bottleneck.

Bakit hybrid ang halos lahat ng totoong system

Isaalang-alang ang isang deployment agent na maaari mong patakbuhin nang ikaw mismo ang nag-manage. Sinisimulan ito ng isang webhook, kaya reflex-based ito. Binabasa nito ang kasalukuyang release state, kaya model-based ito. Pinaplano nito ang mga hakbang mula sa kasalukuyang version patungo sa target version, kaya goal-based ito. Pinipili nito ang rollout window batay sa kasalukuyang load, kaya utility-based ito. Hindi nito ine-edit ang sarili nitong policy, kaya hindi ito learning system.

Isang system ito na sabay na kabilang sa apat na row ng taxonomy. Nakakatulong ang taxonomy bilang design checklist, hindi bilang label para sa natapos na product. Kapag may maling behavior ang system, ang kapaki-pakinabang na tanong ay kung aling layer ang may problema. Magkakaibang bug ang trigger na nag-fire sa maling event, state na naging stale, goal check na hindi kailanman magpa-pass, at score na nagbibigay ng reward sa maling resulta. Magkakaiba rin ang mga fix para sa bawat isa.

Aling uri ang angkop sa bawat gawain

• Nakatakda ang trigger at tugon, at hindi kailangan ng history: simple reflex.
• Nakadepende ang tamang tugon sa mga naunang nangyari: model-based reflex.
• Mabe-verify ang end state, pero hindi pa alam nang maaga ang path: goal-based.
• May ilang katanggap-tanggap na resulta at may tunay na trade-off sa pagitan ng mga ito: utility-based.
• Kailangan mong bumuti ang mga resulta sa paglipas ng panahon: bumuo ng eval loop, at tanggapin na ikaw ang learning component.

Maaari mo bang i-host ang mga agent na ito sa sarili mong server, at magkano ang gastos?

Oo, at nahahati sa dalawang bahagi ang gastos. Mura ang orchestration. Karamihan ng oras ay naghihintay sa network calls ang isang n8n instance o isang agent loop sa Python, kaya sapat na rito ang 2 vCPU at 4 GB ng RAM. Ang model ang pangunahing pinanggagalingan ng gastos.

Kung tumatawag ang agent sa isang hosted API, halos walang kailangan ang server at nakabatay ang bill sa dami ng tokens. Para sa isang goal-based agent, nangangahulugan itong nakabatay ang gastos sa dami ng planning steps na pinapayagan mo, kaya lagyan ng limit ang loop.

Kung pinapatakbo mo ang model sa sarili mong hardware, RAM ang nagtatakda kung ano ang kaya mong patakbuhin. Ang mga figure sa ibaba ay karaniwang published file sizes para sa 4-bit quantised weights noong August 2026, kasama ang planning figure para sa kabuuang RAM, dahil kailangan ng context window at runtime ng karagdagang espasyo bukod sa weights.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

Ang isang 8B model na naka-4-bit ay may humigit-kumulang 4.9 GB na weights, at kayang patakbuhin ito ng isang machine na may 10 GB ng RAM nang walang swapping. Ang isang 70B model na may kaparehong quantisation ay may 43 GB na weights at nangangailangan ng humigit-kumulang 64 GB. Pansinin kung ano ang hindi kasama sa mga numerong iyon: speed. Sa isang VPS na walang GPU, ang isang 8B model na naka-4-bit ay nakakagawa ng single-digit tokens bawat segundo. Sapat ito para sa isang agent na nagpoproseso ng queue magdamag, pero mabagal para sa anumang hinihintay ng tao. Gamitin ang local inference para sa batch work, at gumamit ng GPU o API para sa interactive na bahagi. Sinasaklaw ng shortlist ng mga AI agent na puwedeng i-host sa sarili mong server kung aling mga proyekto ang sulit sa disk space, at sinasaklaw ng study path para sa mga agent sa 2026 kung ano ang dapat pag-aralan at kung anong pagkakasunod-sunod.

Kung saan hindi na nakatutulong ang taxonomy

Wala itong sinasabi tungkol sa mga tool o permission. Nakikita at kumikilos ang mga agent sa textbook. Walang sumulat ng kabanatang iyon ang nag-alala kung may hawak na production API token ang isang agent. Nasa iisang row ng table ang isang goal-based agent na may shell access at isang goal-based agent na may isang read-only database connection, pero magkaiba nang malaki ang risk ng mga ito. Magpasya muna kung ano ang maaaring galawin ng isang agent bago magpasya kung gaano ito dapat maging mahusay, at basahin ang kung paano ilayo ang mga secret sa isang AI agent bago mo ito bigyan ng credential.

Wala rin itong sinasabi tungkol sa nangyayari kapag nag-fail ang isang step. Karamihan ng runtime ng mga tunay na agent ay ginugugol sa pag-handle ng mga error: rate limit, o tool na nagbalik ng resultang hindi inaasahan ng model. Ang code na iyon ang nagpapasya kung magagamit ang system, pero walang row sa taxonomy na naglalarawan nito.

FAQ

Ano ang limang uri ng AI agent?

Simple reflex, model-based reflex, goal-based, utility-based, at learning agents. Inaayos ang mga ito batay sa dami ng alam ng agent bago ito kumilos. Kasalukuyang input lamang ang nakikita ng simple reflex agent. Nagtatago ng state tungkol sa environment nito ang model-based agent. Nagpa-plano ang goal-based agent patungo sa target state. Tinataya ng utility-based agent ang ilang katanggap-tanggap na resulta at pinipili ang may pinakamataas na score. Binabago ng learning agent ang sarili nitong policy batay sa feedback, na halos walang self-hosted setup ang aktuwal na gumagawa.

Aling uri ng AI agent ang dapat kong gamitin para sa simpleng automation?

Simple reflex agent, na sa praktika ay isang webhook o schedule na nagti-trigger ng nakapirming sequence. Kung nakadepende lamang ang tamang response sa input na kakarating lang, nagdaragdag ang memory ng mga failure mode ngunit walang bagong capability. Lumipat sa model-based design kapag matutukoy mo na ang isang desisyong kailangang malaman kung ano ang nangyari dati.

Maaari ko bang patakbuhin ang sarili kong AI agents sa isang VPS?

Oo. Magaan ang orchestration layer, kaya kayang patakbuhin nang maayos ng 2 vCPU at 4 GB ng RAM ang isang workflow engine o agent loop. Ang tunay na desisyon ay kung saan tatakbo ang model. Pinananatiling maliit ng hosted API ang server at inililipat ang gastos sa tokens. Nangangailangan ang local model ng RAM na naaayon sa dami ng parameters nito. Kung walang GPU, nagge-generate ito ng single-digit tokens bawat segundo, kaya mas angkop ito sa naka-queue na batch work kaysa sa chat window.

AI agent na ba mismo ang isang large language model?

Hindi. Itinatapat ng model ang input text sa output text at pagkatapos ay humihinto. Nagiging agent ito kapag may wrapper na naglalagay dito sa isang loop na maaaring kumilos sa mundo at ibalik ang resulta sa loop. Kailangan nito ng mga tool na matatawag at condition na nagsasabi kung kailan dapat huminto ang loop. Ang wrapper ang agent. Isang component lamang sa loob nito ang model.

Kailangan ko ba ng multi-agent system?

Karaniwan, hindi. Kayang pangasiwaan ng isang loop na may ilang tool ang karamihan ng trabaho at mas madali itong i-debug. Nakakatulong ang maraming agent kapag tunay na independent ang mga bahagi ng task at maaaring tumakbo nang sabay, o kapag ibang model ang kailangan ng isang bahagi. Ang kapalit nito ay coordination: shared state at isang supervisor na lumalaki ang context sa bawat worker report na binabasa nito. Idagdag ang pangalawang agent kapag matutukoy mo na ang hakbang na mabagal.