Mahalagang pag-isipang mabuti kung paano at saan ginagawa ang mga pagpapasya sa iyong agentic system.
Kapag mas maraming pagpapasya ang ipinauubaya sa isang LLM, posibleng makayanan ng system ang mas maraming gawain, ngunit maaaring maapektuhan ang bilis, pagiging maaasahan, at katatagan nito.
Hangga't maaari, ilipat mula sa LLM patungo sa tahasang software code ang pinakamaraming bahagi ng proseso ng pagpapasya. Lalo itong mahalaga para sa mga workflow na mataas ang panganib at/o ginagamit sa production.
Kapag nagdidisenyo ng agentic system na nakabatay sa LLM, isa sa pinakamahalagang pagpapasya ang lawak ng prosesong ilalagay sa isang LLM na modelo kumpara sa tahasang software.
Para mas madaling maunawaan, maaari nating ituring ang pagpiling ito bilang isang spectrum sa pagitan ng mga sumusunod na pamamaraan:
Tahasang itinatakda ng mga arkitekturang nakabatay sa router ang pagkakasunod-sunod at lohika sa code. Dahil dito, masusubukan, mahuhulaan, at matatag ang mga ito para sa mga gawain sa limitadong domain (tinatawag din itong “mga workflow agent”).
Umaasa ang mga orchestrator agent sa malalaking modelo ng wika (mga LLM) upang dinamikong pagpasyahan ang daloy ng gawain gamit ang mga prompt sa natural na wika. Angkop ito sa mga bukas na interaksyon kung saan kulang o imposibleng gumamit ng paunang itinakdang lohika.
Para sa mga production workflow na mataas ang panganib, karaniwan naming inirerekomenda ang mas maraming feature na nakabatay sa router, at ang mga orchestrator ay inilalaan sa mga application na nangangailangan ng flexible at pangkalahatang pag-uusap.
Mga Arkitekturang Nakabatay sa Router
Ang mga router agentic system ay:
Tahasang nagtatakda sa daloy ng pagpapasya sa pamamagitan ng code/software at gumagamit ng LLM upang tukuyin kung aling ruta ang tatahakin ng software.
Mas kahawig ng mga tradisyonal na software system dahil may malinaw at mahuhulaang mga landas ang mga ito, kaya mas pare-pareho ang mga resulta.
Mainam para sa mga gawaing maaaring mahigpit na tukuyin.
Ang sumusunod ay isang payak na halimbawa ng agent para sa Airline Chatbot Booking na gumagamit ng “pamamaraang router.” Bagama't tumutulong ang LLM na uriin ang layunin ng tanong mula sa tatlong posibleng pagpipilian, ang software pa rin ang nag-uugnay sa layuning ito sa isang naka-template na tugon. Dahil mahigpit ang mga limitasyon sa LLM, mas pare-pareho ang mararanasang gawi ng user.
Mga Arkitekturang Orchestrator
Hindi tulad ng router system, ang mga orchestrator agentic system ay:
Nagtatakda ng mga daloy ng lohika sa pamamagitan ng mga prompt sa natural na wika sa halip na software. Tandaan: kumpara sa isang programming language, likas na malabo at flexible ang natural na wika—kapuwa positibo at negatibong katangian, gaya ng tatalakayin natin mamaya. Itinuturing namin itong “layunin sa halip na tagubilin.”
Nakapagbibigay ng maraming opsyon sa pagproseso, habang tinutukoy ng LLM ang pagkakasunod-sunod at paraan ng pagpapatupad.
Dinamikong nakagagawa ng mga bagong landas ng lohika na mahirap tahasang tukuyin sa software.
Maaaring magdulot ang kalabuan na ito ng hindi pare-parehong output, ngunit kapag gumana ito, maaari itong magmukhang “mahiwaga.”
Ginagamit ng sumusunod na halimbawa ang pamamaraang orchestrator sa parehong payak na problema sa airline. Sa halip na software ang magpasya kung anong tugon ang naaangkop, ipinauubaya ang pagpapasya sa layer ng LLM. Mayroon tayo ritong multi-agent system kung saan sinusuri ng isang “punong” orchestrator agent ang query ng user at ipinapasa ito sa isang agent na partikular na idinisenyo upang magpalit ng flight. Sa huli, ibinibigay nito ang tugon sa user.
Sa halimbawang ito, ginagampanan ng layer ng LLM ang papel ng classifier, router, at tagasulat ng tugon. Sa halimbawa ng Router, classifier lamang ang papel nito, habang software ang gumagawa ng iba pa.
Hangga't maaari, inirerekomenda namin ang paggamit ng pamamaraang nakabatay sa router dahil sa mga sumusunod na bentahe:
Bilis at kahusayan: Mas mabilis ang mga lokal na computation kaysa sa mga orchestrator na umaasa sa external API. Mas mura ring iproseso ang iyong lohikang “IF/ELSE” sa Python kaysa magbayad sa isang LLM provider upang patakbuhin ito sa modelo nitong may 400 bilyong parameter.
Kakayahang subukan at mahulaan: Mas madaling mag-debug, sumubok, at magpanatili gamit ang mga kinikilalang kasanayan sa software.
Transparency at pagiging maaasahan: Mas madaling mag-troubleshoot kapag mas kaunti ang pagkakaiba-iba ng gawi. Mas malaking bahagi ng daloy ng application ang naipapahayag din sa transparent at version-controlled na software, sa halip na sa malabo at hindi maipaliwanag na mga weight ng isang LLM.
Ang mga kahinaan ng pamamaraang router ay maaari itong maging mahigpit, hindi flexible, at mahirapang lutasin ang mas bukas na mga problema. Maaaring ituring ng mga user na nakababagot o hindi umuunlad ang chatbot na palaging eksaktong magkakapareho ang tugon.
May mahuhusay na kakayahan ang mga disenyong orchestrator:
Pagpaplano: Dinamiko nilang napaplano ang mga tugon.
Pagpili ng Tool/Pagpapasa sa Agent: Pumili ng mga naaangkop na tool o magtalaga ng mga gawain sa mga agent.
Paulit-ulit na Pagsasama ng mga Output: Malikhaing ulitin at muling pagsamahin ang mga output.
Pagtukoy sa Pagkakumpleto: Tukuyin kung sapat na ang nakalap na impormasyon upang tapusin ang isang tugon.
Pinadadali at pinabibilis ng mga framework gaya ng Pydantic-AI o Agents SDK ng OpenAI ang pagpapatupad ng orchestration. Dahil dito, mainam ito para sa mga demo o proof of concept.
Ang mga kahinaan ng pamamaraang ito ay:
Walang garantiya na magiging tama o naaangkop ang mga hakbang sa pagpaplano ng LLM at ang mga kasunod na pagkilos. May ganito ring isyu ang router system, ngunit mas mahuhulaan ang gawi nito dahil mas mahigpit ang mga limitasyon dito.
Para sa mga simple at malinaw na tinukoy na gawain, malamang na hindi natin kailangan ang buong kakayahan ng isang multi-agent system. Halimbawa, sa ating halimbawa ng Airline Agent, malamang na limitado lamang ang mga uri ng query na nais gawin ng isang taong nakikipag-ugnayan sa support system ng airline.
Dahil mas maraming lohika ang nasa LLM, mas madali itong i-jailbreak o pagsamantalahan ng mga masasamang-loob.
Inilalagay nito sa LLM ang proseso ng pagpapasya, kaya mas mahirap maunawaan ang iyong system—bagama't maaaring makatulong nang bahagya ang mga monitoring tool gaya ng Langfuse o Braintrust.
Tala sa mambabasa: bagama't mabilis na nagbabago ang kakayahan ng modelo, malamang na hindi magbabago sa malapit na hinaharap ang mga sumusunod.
Tukuyin ang saklaw ng iyong problema.
Madali mo bang mailalarawan sa isang diagram ang nais mong lohika ng pagpapasya?
Hindi mo ba matatanggap ang pagkabigo o hindi inaasahang gawi sa iyong application?
Kung “oo” ang sagot sa alinman sa dalawang tanong, mas angkop ang mga feature ng router.
Hangga't maaari, inirerekomenda naming gamitin muna ang mga pamamaraang router. Bilang pangkalahatang prinsipyo, kung maisusulat sa code ang isang bahagi ng iyong system, isulat ito sa code—ibig sabihin, huwag gumamit nang sobra ng mga LLM kung hindi naman kailangan.
Kapag naabot na ang mga limitasyon ng mga ito, maaaring tularan sa kontroladong paraan ang ilan sa mga bentahe ng bukas na orchestrator. Halimbawa:
Pagpili ng Tool/Pagpapasa sa Agent: Madaling ipatupad sa pamamagitan ng conditional branching o mga LLM classifier.
Pagtukoy sa Pagkakumpleto: Maaaring suriin ng mga simpleng LLM classifier kung kumpleto ang tugon bago ito ibalik sa user.
Gayunman, walang dudang mas mahirap makamit ang “Pagpaplano” at “Paulit-ulit na Pagsasama ng mga Output” sa isang mahigpit na router system. Kaya kapag kailangan ng isang gawain ang mga ito—ayon sa isang LLM classifier o iba pang lohika—iminumungkahi naming gumawa ng mas maluwag na orchestrator branch sa iyong system.
Ang pagpili mo sa pagitan ng mga arkitekturang router at orchestrator ay dapat umayon sa linaw, pagiging kumplikado, at estilo ng interaksyon ng iyong application. Sa kasalukuyan, nagbibigay ang mga pamamaraang nakabatay sa router ng pagiging maaasahan, kahusayan, at madaling pagsubok para sa malinaw na tinukoy na mga gawain. Nagbibigay ang mga orchestrator ng higit na flexibility para sa mas malawak at pang-usapang mga interaksyon.
Habang patuloy na umuunlad ang mga LLM, maaaring magbago ang balanse sa pagitan ng mga pamamaraang ito. Mas pinapaboran namin ang mga arkitekturang nakabatay sa router o hybrid para sa mga production workload, at inilalaan ang mga orchestrator sa mga bukas na problemang nangangailangan ng dinamiko at tila makataong pakikipag-ugnayan.