Pare-pareho ang karaniwang ginagamit ng mga AI team na naghahangad ng mas mahusay na performance ng agent: mas malalaking context window, mas maraming dokumento, at mas matatalinong prompt. Ipinapaliwanag ng artikulong ito kung bakit lubos na mali ang instinct na iyon. Hindi mas maraming impormasyon ang nawawalang sangkap. Kontrol iyon. Mahusay na idinisenyong control layer ang naghihiwalay sa agent na gumagana sa demo at sa agent na gumagana sa production.
Hindi nagiging mas matalino ang AI agent kapag binigyan ng mas malaking memory, mas maraming dokumento, o mas mahabang context window—nagiging mas mabagal at mas mahal lang ito. Nagmumula ang tunay na paghusay sa pagtuturo sa agent na piliin ang kailangan nito sa oras na kailangan iyon, sa halip na gamitin ang lahat nang sabay-sabay.
Sa loop nagmumula ang pagiging maaasahan, hindi sa modelo. Ang kaibahan ng agent na kahanga-hanga sa demo at ng agent na maaasahan sa production ay hindi ang kalidad ng AI—kundi kung sinusuri ng sistema ang sarili nitong gawa. Nahuhuli ng mga agent na nagpaplano, kumikilos, nag-oobserba, at nagbeberipika sa bawat hakbang ang sarili nilang pagkakamali sa halip na magkamali nang buong kumpiyansa.
Karamihan ng mga AI agent ngayon ay mga chatbot lang na may mga dagdag na hakbang—wala silang mekanismo para malaman kung nasa tamang direksiyon sila, kung kailan hihinto, o kung kailan susubok ng ibang paraan. Ang pagdaragdag ng wastong control layer—malinaw na pamantayan ng tagumpay, structured state, at mga validation check—ang nagpapabago sa isang bagay na hugis-agent tungo sa isang bagay na talagang mapagkakatiwalaan.
Ano ang kinain mo sa tanghalian kahapon?
Malamang ay hindi mo binalikan ang bawat alaala mo hanggang matagpuan ang “kahapon + tanghalian.” Dumiretso ka sa bahagi ng karanasan mo kung saan nakaugnay ang mga konseptong iyon. Kapaki-pakinabang itong mental model sa pagbuo ng mga agent:
Hindi memory ang napakalaking context window.
Hindi pag-unawa ang bunton ng mga nakuhang dokumento.
Hindi pagiging maaasahan ang mahabang chain-of-thought.
Mga sangkap lang ang mga iyon. Ngunit ang nagpaparamdam na tunay na agent ang isang agent ay siya ring dahilan kung bakit hindi sinusuri ng utak mo ang buong kasaysayan ng buhay mo sa brute-force na paraan: kontrol.
Mahusay na ibinuod (at pinangalanan) ng isang bagong survey—Agentic Reasoning for Large Language Models—ang pagbabagong nararamdaman ng marami sa atin habang bumubuo: mula sa pangangatwiran sa loob ng modelo tungo sa pangangatwiran sa pamamagitan ng interaksiyon. Hindi buod ng paper na iyon ang post na ito. Isa itong pagtatangkang isalin ang pagbabagong iyon sa praktikal na disenyo ng sistema:
Kung bubuo ka ng mga agent na parang mga chatbot na may tool, patuloy kang makakakuha ng mga failure mode ng chatbot—pero mas mahal ang mga pagkakamali.
Sa loob ng ilang panahon, ganito ang karaniwan nating playbook para “gawing mas matalino ang modelo”: mas mahuhusay na prompt, chain-of-thought, self-consistency / sampling-based na pagpapahusay, at marahil ilang search.
Mahalagang yugto ang ReAct dahil ginawa nitong natural ang “isip → kilos → obserbasyon.” Ngunit pansinin ang di-hayag na limitasyon: nauuwi pa rin ang marami rito sa “one-shot inference, pero mas maraming token.” Mas malinaw ang paglalarawan ng survey: binibigyang-diin ng agentic na pangangatwiran ang pag-scale ng interaksiyon sa test time—ginagawang paulit-ulit na proseso ang inference kung saan nananatiling bahagi ng loop ang modelo, memory, at environment.
Para ito sa iyo kung nakabuo (o nakagamit) ka na ng mga agent na kahanga-hanga sa demo ngunit madaling pumalya sa mga tunay na workflow.
Ilalarawan ko ang isang pattern na madalas kong makita (at tiyak na nakagawa rin ako ng mga bersiyon nito):
Kumuha ng mahusay na chat model
Magdagdag ng ilang tool (search, DB query, at marahil code execution)
Magdagdag ng RAG
Magdagdag ng system prompt na “you are an autonomous agent”
Ilagay ang lahat sa while-loop hanggang huminto o mag-timeout ito
Binabati kita, mayroon ka nang bagay na hugis-agent. Ngunit karaniwang pumapalya ito sa mga paraang madaling hulaan:
Paglobo ng context: idinaragdag ang bawat obserbasyon; nagiging tila mga patong ng arkeolohiya ang mga prompt.
Walang direksiyong paggamit ng tool: nagiging default na failure mode ang “maling tool pero buong kumpiyansa.”
Walang kondisyon sa paghinto: nagpapatuloy ito dahil kaya nito, hindi dahil dapat.
Walang disiplina sa grounding: hindi nito napapansing mali ito maliban kung pipilitin mo.
Memory = chat history: para ka lang gumagawa ng mga log at tinatawag iyong pagkatuto.
Ito ang dahilan kung bakit madalas magmukhang mahiwaga ang mga “agent” sa demo ngunit magulo sa production. Makikita rin ito sa karanasan namin sa pag-deploy ng mga agentic system sa production: kapag sistema na at hindi lang modelo ang sinusuri mo, kabilang na sa mga failure mode ang navigation, maayos na paggamit ng tool, context pruning, at disenyo ng evaluation—hindi lang “tama ba ang sagot ng modelo.”
Kaya ang tanong ay: ano ang sadyang idinisenyong agent?
Para hindi ito masyadong abstrak, narito ang isang simpleng workflow na madaling mailarawan ng karamihan: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Ganito karaniwang gumagana ang isang implementasyong “hugis-agent”:
Agad itong kumukuha ng maraming dokumento tungkol sa mga patakaran ng airline / paglalakbay (kahit wala pang kailangan).
Tumatawag ito ng search tool, naglalagay ng mahabang listahan ng mga resulta sa prompt, at “pumipili ng isa.”
Nagmamadali itong mag-book nang hindi bineberipika ang mga limitasyon (oras ng pagdating / bagahe / upuan / patakaran).
Kapag pumalya ito, sumusubok itong muli sa bahagyang ibang paraan—pero walang malinaw na ideya kung ano ang nagbago o natutuhan nito.
Hindi ang kawalan ng kakayahan ng modelo na mangatwiran ang failure mode—kundi ang kawalan ng kontrol ng sistema sa workflow.
Itinuturing ng mas agentic na bersyon ang gawain bilang interaktibong proseso na may malinaw na state at mga pagsusuri:
MAGPLANO: ulitin ang mga limitasyon + ilista ang kulang na impormasyon (hal., “which airport preference?” / “is 1 stop ok?”).
KUMILOS: tawagin ang flight search gamit ang structured query (saklaw ng petsa, limitasyon sa oras ng pagdating, budget).
MAG-OBSERBA: itago ang mga resulta sa isang maikling state object (nangungunang 5 kandidato kasama ang presyo/pagdating/mga layover), hindi sa napakalaking kinopyang bloke.
MAG-UPDATE: pinuhin ang query kung hindi natutugunan ang mga limitasyon (hal., “arrival before 6pm is too strict—widen time window or raise budget?”).
MAGBERIPIKA: patakbuhin ang mga validator (“arrival < 18:00,” “price ≤ £900,” “policy compliant,” “seat selection available”).
HUMINTO: kapag nagbalik na ng kumpirmasyon ang booking API at pumasa na ang lahat ng validator.
Banayad ngunit mapagpasya ang nagbago. May kondisyon ang retrieval (hindi awtomatikong reaksiyon), pinamamahalaan ang context (structured ang state, hindi basta iniipon), at kasama sa loop ang beripikasyon (hindi ipinauubaya sa user). Palitan ang “pag-book ng flight” ng “paggawa ng purchase order,” “pag-isyu ng refund,” “pagbabago ng production config,” o “pag-ship ng PR,” at pareho pa rin ang punto: kapag kaya nang kumilos ng agent, mas mahalaga ang loop kaysa sa prompt.
Hinahati ng nabanggit na survey ang agentic na pangangatwiran sa tatlong antas: foundational (pagpaplano/paggamit ng tool/search), self-evolving (feedback + memory), at collective (koordinasyon ng maraming agent).
Ngunit ito ang mas malalim na ideya: ang pangangatwiran ang nagiging batayan ng pagpaplano, pagdedesisyon, at beripikasyon—hindi lang ng pagbuo ng kapani-paniwalang chain-of-thought. Mukhang abstrakto iyan hanggang itugma mo ito sa mga pagbabago sa iyong architecture. May tatlong pangunahing puntong dapat tandaan:
Hindi dapat ituring ng mahusay na agent ang retrieval bilang “laging gawin.” Desisyon ang retrieval, hindi awtomatikong reaksiyon.
Narito ang isang praktikal na heuristic:
Kung kumukuha ng impormasyon ang sistema mo sa bawat turn, hindi retrieval ang ginawa mo—kundi context tax.
Lagi itong nakikita sa aktuwal na trabaho. Kapag nagde-debug ng production incident, hindi mo ibinubuhos sa context ang lahat ng log; pinipili mo ang susunod na metrics/logs na kukunin batay sa kasalukuyan mong hypothesis. Iyan ang “agentic retrieval.” Narito ang mas kongkretong pattern:
Magpasya kung kailangan mo ng retrieval
Kung oo: bumuo ng query, kumuha, mabilis na suriin, at kunin ang mahalaga
Kung nagkakasalungatan ang ebidensiya: kumuha muli
Saka lamang pagsama-samahin ang impormasyon
Dito rin nagsisimulang maiba ang “agentic RAG” sa tradisyonal na RAG: nagiging sinadyang hakbang sa pangangatwiran ang retrieval, hindi default na yugto ng pipeline.
Sa sandaling tumigil kang suriin ang “isang modelo” at nagsimulang suriin ang “isang sistema,” nagiging mahalaga ang pagsubaybay at pag-trace sa state.
Isang bagay na mas malinaw nang kinikilala ng industriya ngayon ang observability para sa mga workflow ng agent. Halimbawa, may built-in tracing at Traces dashboard ang Agents SDK ng OpenAI na nagtatala ng mga pagtakbo ng agent (mga generation, tool call, handoff, guardrail, at custom event), para ma-debug at ma-audit mo nang sunod-sunod ang nangyari.
Hindi lang iyan “magandang mayroon.” Iyan ang kaibahan ng sistemang kaya mong i-debug sa sistemang kutob lang ang maipantsek mo.
Para sa akin, ang pinakanapapakinabangang bahagi ng survey ay ang tuwiran nitong pagtalakay sa feedback. Hinahati nito ang feedback sa tatlong paraan: reflective feedback (bumuo → pumuna → magrebisa), parametric adaptation (matuto sa fine-tuning / RL), at validator-driven feedback (subukan muli hanggang pumasa sa validator).
Dapat magsimula ang karamihan ng mga team sa validator-driven feedback dahil simple ngunit epektibo ito. Kung makagagawa ka ng anumang validator na nagsasagawa ng unit test, sumusuri sa schema, nagpapatupad ng mga patakaran / limitasyon ng negosyo (“no refunds above X without escalation”), o nagtitiyak ng katotohanan (“citations required”), magagawa mong gawing tunay na mapagkakatiwalaan ang non-deterministic na output ng modelo.
Simple ang isa sa mga pagbabagong hindi natin alam na hindi natin alam: sa mundo ng agent, kadalasang mas nagmumula ang pagiging maaasahan sa loop kaysa sa modelo.
Ito ang pinakasimpleng disiplinang pang-loop na nakita kong maaasahang nagpapahusay ng kilos nang walang training:
Gawin nang sunod-sunod: Magplano → Kumilos → Mag-obserba → Mag-update,
Pagkatapos ng bawat Pagkilos, ibuod ang Obserbasyon sa 1–3 bullet,
Huminto kapag natugunan ang pamantayan ng tagumpay o naabot ang budget; ibalik ang pinakamainam na resultang nalalaman + mga natitirang kawalan ng katiyakan.
Hindi ito tungkol sa pagpapahaba ng sagot ng modelo. Tungkol ito sa paggawa ng sistemang madaling maunawaan at sa pagpilit ditong “humarap sa realidad” sa bawat hakbang. Isang halimbawang madaling makaugnayan ng mga engineer ang CI-style na closed-loop grounding:
Magplano: magmungkahi ng listahan ng mga pagbabago
Kumilos: patakbuhin ang mga test / lint
Mag-obserba: suriin ang mga failure
Mag-update: mag-patch at subukang muli
Ilang tanong na karaniwang naglalantad ng mga di-sinasadyang disenyo ng agent:
“Ang agent ko ba ang nagpapasya kung ano ang kukunin, o lagi akong kumukuha?”
Kung walang kondisyon ang retrieval, magbabayad ka sa anyo ng latency, gastos, paglabo ng context, at mas mataas na panganib ng garbage-in / garbage-out.
“Napapansin ba ng agent ko kapag mali ito?”
Kung ang tanging feedback signal ng agent mo ay “naiinis ang user,” nagsasagawa ka ng RL gamit ang paghihirap ng tao. Ang validator-driven retry loop ang pinakamalinis na paraan para maipaharap ito sa realidad.
“Nasusulatan ba ang memory, at gumagaling ba ito sa paglipas ng panahon?”
Kung nagdaragdag lang ng chat history ang iyong “memory,” para ka lang gumagawa ng mga log. Mahalaga ang paglalarawan ng survey sa memory: nagiging context itong patuloy at dinamikong lumalawak, na pinapahusay ng mga agent sa paglipas ng panahon—hindi lang transcript.
Sinasabi ng mga log kung ano ang nangyari; sinasabi naman ng memory kung ano ang gagawin sa susunod. Transcript ang chat history. Ang memory ay patuloy na umuunlad na patakaran tungkol sa kung ano ang mahalagang dalhin sa hinaharap.
Isang praktikal na panimula ang maliit na talahanayan ng “mga natutuhang aral,” na nakaayos ayon sa uri ng gawain, tool, at failure mode, at naglalaman ng kung ano ang gumana at dapat iwasan. Hindi layunin ang bumuo ng perpektong knowledge graph. Ang layunin ay lumikha ng pag-uugaling patuloy na humuhusay: binabago ng memory + feedback ang mga agent mula sa “mga helper na walang state” tungo sa mga sistemang gumagaling sa paglipas ng panahon.
Nakatutuksong magdagdag ng mas maraming agent sa problema, ngunit madalas nitong paramihin ang kailangang koordinasyon. Isang mahusay na pattern ng “minimum viable team”:
Coordinator: naghahati-hati + nagtatalaga
Executor: nagsasagawa ng mga tool call / pagbabago
Critic/evaluator: sumusuri sa kawastuhan/panganib
Tagapangasiwa ng memory: nagsusulat/nagpapanatili ng mga aral
Kung hindi mo maipaliwanag ang saklaw ng pananagutan ng bawat agent, malamang ay hindi mo pa kailangan ng maraming agent.
Kung talagang tanggap natin ang pagbabago ng paradigm, malamang ay titigil tayong isiksik ang lahat sa mga prompt, ituring ang mga failure bilang pinal na output, at suriin ang mga agent na parang mga chatbot. At sisimulan nating ituring ang mga agent ayon sa tunay nilang katangian: mga software system kung saan wika ang control plane—at nagmumula sa loop ang pagiging maaasahan.
Bago magdagdag ng isa pang modelo, magdagdag muna ng isa pang evaluation loop. Bago kunin ang lahat, lagyan muna ng kondisyon ang retrieval. Mag-ship muna ng isang validator bago mag-ship ng sampu. Ituring ang memory na parang mga desisyon sa patakaran, hindi database. At kapag lumilipat sa multi-agent, magsimula sa dalawang agent, hindi dalawampu. Hindi mga tuntunin ang mga ito; sila ang mga pattern na napatunayang gumagana sa production.