Pag-engineer ng AI Agents na Bumubuo at Nagde-deploy ng Tunay na Software: Sa Loob ng Arkitektura ng Jobbit

Karamihan sa mga "AI agent" ay humihinto sa usapan lang. Sumasagot sila, at saka ang tao na ang gumagawa ng trabaho. Ang kawili-wili — at talagang mahirap — na engineering problem ay ang pagbuo ng mga agent na gumagawa ng trabaho: nagsusulat ng full-stack na aplikasyon, pinapatakbo ito, inaayos ang sariling mga pagkakamali, at idine-deploy ito sa production. Iyan ang problemang pinagtutuunan ng engineering team sa Jobbit at ng R&D division nito, ang Jobbit Labs (jobbitlabs.com), araw-araw.

Ang post na ito ay isang engineering deep-dive sa mga pattern sa likod ng AI agents na bumubuo at nagde-deploy ng software — ang arkitektura, ang mga failure mode, at ang mga aral. Sadyang praktikal ito at hindi nakatali sa iisang provider: ikaw man ay nagbubuo sa LLMs, multi-agent orchestration, tool calling, o RAG, naililipat ang mga prinsipyong ito.

Sumasagot lang ang chatbot; kumikilos ang agent

Ang paglipat mula chatbot patungong agent ay paglipat mula sa pagbuo ng teksto patungo sa pagkilos sa totoong mundo. Kailangang magplano ang isang agent ng multi-step na gawain, tumawag ng mga tool, basahin ang mga resulta, at magpasya kung ano ang susunod na gagawin — at saka uulitin hanggang matupad ang layunin. Ang loop na iyon, na madalas tawaging agentic loop (o reason–act loop), ang puso ng sistema.

Ang hamon sa engineering ay puwedeng mabigo ang bawat hakbang. Maaaring mag-hallucinate ang model ng function na wala naman, magsulat ng code na hindi nagko-compile, magkamali sa pagbasa ng output ng isang tool, o tahimik na maligaw sa gawain. Ang chatbot na mali ay gumagawa ng masamang pangungusap; ang agent na mali ay gumagawa ng sirang deploy. Ang reliability, hindi ang puro kakayahan, ang tunay na engineering work.

Ang arkitektura: planner, executor, tools

Ang matibay na agent platform ay pinaghihiwalay ang planning sa execution. Hinihiwalay ng planning layer ang isang layunin ("bumuo ng booking app na may payments") sa konkretong mga hakbang; isinasagawa naman ng execution layer ang bawat hakbang gamit ang mga tool. Ang paghihiwalay ng mga responsibilidad na ito ay nagpapadali sa pag-debug: maaari mong suriin ang plano nang hiwalay sa kung paano tumakbo ang bawat hakbang.

Ang tool use ang nagbibigay sa agent ng kamay nito. Ang mga tool ay malinaw na tinukoy na function na puwedeng tawagin ng model — magbasa ng file, magsulat ng code, magpatakbo ng build, mag-query ng database, mag-deploy. Ang disiplina sa engineering dito ay interface design: kailangan ng bawat tool ng masinsin at malinaw na schema, na-validate na mga input, at structured na output na maaasahang ma-parse ng model. Ang maluluwag na tool interface ay isa sa pangunahing sanhi ng agent failures; ang masinsin ay ang pinakamurang panalo sa reliability na puwede mong makuha.

Para sa kumplikadong trabaho, madalas na nagiging multi-agent orchestration ang dating iisang agent — mga espesyalistang agent na nagpaplano, nagsusulat ng code, nagre-review, at nagve-verify, na pinag-uugnay ng isang orchestrator. Ang decomposition ay nagbibigay sa iyo ng focus (makitid ang trabaho at konteksto ng bawat agent) at parallelism (sabay-sabay na tumatakbo ang mga independiyenteng subtask). Ang trade-off ay ang coordination overhead, kaya kailangang deterministiko ang orchestration layer kung saan kaya, at matatag kung saan hindi.

Ligtas na pagpapatakbo at pag-deploy ng tunay na code

Ang agent na nagsusulat ng software ay kailangang patakbuhin ang software na iyon — at ang pagpapatakbo ng code na ginawa ng model ay isang security problem bago pa ito maging anuman. Ang sagot ay sandboxed code execution: tumatakbo ang untrusted code sa isang nakahiwalay na environment na may limitadong resource, walang access sa secrets, at masisikip na network boundary. Ang sandbox ang nagpapahintulot sa agent na mag-iterate — mag-compile, mag-test, basahin ang error, ayusin — nang hindi inilalagay sa panganib ang platform o ang ibang user.

Ang deployment ang hakbang na nagpapalit sa ginawang app tungong produkto. Ang tunay na AI app builder ay may-ari ng landas mula code patungo sa live na URL: mag-build, magbigay ng hosting, ikabit ang domain, mag-terminate ng TLS. Ang mahusay na engineering nito ay ang paggawa sa mga deploy na paulit-ulit at maibabalik — ang parehong input ay gumagawa ng parehong resulta, at ang masamang deploy ay maaaring ma-rollback. Hindi maganda pakinggan ang idempotency at malinis na rollback, ngunit iyan ang nagpapagawa sa autonomous deployment na mapagkakatiwalaan.

Context, memory, at retrieval

May hangganan ang context ng LLMs, at hindi kasya rito ang totoong mga proyekto. Kaya ang seryosong agent system ay namumuhunan nang husto sa context engineering: ang pagpapasya kung ano ang nakikita ng model sa bawat hakbang. Ang pagsiksik ng lahat sa prompt ay parehong magastos at kontraproduktibo — ang sobrang dami ng walang kaugnayang konteksto ay nagpapababa sa reasoning.

Dito kumikita ng lugar ang RAG (retrieval-augmented generation) at ang vector databases. Sa halip na ibuhos ang buong codebase sa konteksto, kinukuha ng sistema ang ilang file, symbol, o doc na may kaugnayan sa kasalukuyang hakbang. Pinagsama sa structured na memory — isang tala ng mga desisyon, ang umuunlad na spec, at kung ano na ang nasubukan — pinananatili ng retrieval na nakaangkla ang agent sa mahabang gawain nang hindi sumasabog ang context window. Madalas na mas malaking lever ang mahusay na retrieval kaysa sa mas malaking model.

Reliability: evals, verification, at guardrails

Kung may isang ideyang naghihiwalay sa production agent engineering sa mga demo, ito iyon: hindi mo maipapadala ang hindi mo masusukat. Stochastic ang mga agentic system, kaya ang reliability ay binubuo sa pamamagitan ng evals — mga automated test suite na nagbibigay-marka sa agent sa mga representatibong gawain at nahuhuli ang mga regression bago pa ito mahuli ng mga user. Ang pagbabagong "pakiramdam ay mas maganda" ngunit bumabagsak sa iyong eval scores ay pagbabagong hindi mo ipapadala.

Sa ibabaw ng evals ay nakaupo ang runtime na guardrails at verification. Ang pinakaepektibong pattern ay ang adversarial self-checking: matapos gumawa ng resulta ang isang agent — isang piraso ng code, isang plano, isang ayos — isang hiwalay na verification pass ang sumusubok na pabulaanan ito. Nagko-compile ba ang code? Pumapasa ba ang mga test? Tumutugma ba ang output sa schema? Ang pagtuturing sa verification bilang isang hiwalay at mapag-alinlangang hakbang ay nahuhuli ang malaking bahagi ng mga failure na palalagpasin ng iisang mapagkumpiyansang pass. Ang mga retry na may backoff, circuit breakers, at human escalation ang humahawak sa natitira.

Observability na kaya mong i-debug

Kapag ang isang autonomous system ay gumagawa ng dose-dosenang desisyon kada gawain, kailangan mong makita ang mga ito. Ang observability — structured na pag-trace ng bawat prompt, tool call, at resulta — ay hindi napag-uusapan pa. Kapag nagkamali ang isang agent, ang trace ang paraan para makita mo ang eksaktong hakbang na naligaw, i-reproduce ito, at ayusin ang ugat ng dahilan. Ang mga engineering team na tumuturing sa agent traces bilang first-class telemetry ay nagde-debug sa loob ng minuto; ang mga hindi gumagawa nito ay nagde-debug sa loob ng araw.

Ang edge at elastic scale

Ang agent workloads ay biglaan at sensitibo sa latency, kaya likas na bagay dito ang edge computing. Ang pagpapatakbo malapit sa mga user — sa mga platform gaya ng Cloudflare Workers at edge data stores — ay nagbabawas ng round-trip latency at elastikong sumusukat ayon sa demand. Umaasa ang Jobbit Labs sa edge-first na pamamaraang ito para sa mga bahagi ng data at product infrastructure nito: pandaigdigang nakakalat, autoscaling, at pay-for-what-you-use, kaya ang kapasidad ay sumusunod sa load sa halip na nakatengga.

Ang human-in-the-loop na layer

Ang huling piraso ng arkitektura ay ang isang madalas na wala sa karamihan ng agent platform: isang human-in-the-loop na landas. Hinahawakan ng AI ang dami at bilis, ngunit ang ilang desisyon — security-sensitive na lohika, legal na pananalita, design judgment — ay nararapat sa isang tao. Ang engineering nito ay nangangahulugan ng pagbuo ng malilinis na handoff point kung saan maaaring pumasok ang isang na-vet na human expert, na may escrow na nagpoprotekta sa transaksyon. Ang agent at ang human network ay hindi magkalabang layer; sila ay dinisenyong fallback na nagpapaligtas sa buong sistema upang maaasahan.

Mga aral para sa mga engineer na bumubuo ng agents

Kung nagbubuo ka ng mga agentic system, may ilang prinsipyong nagbabalik ng puhunan nang maraming ulit.

Magdisenyo ng masinsing tool interface. Karamihan sa agent failures ay nag-uugat sa malabong tool. Ang mahigpit na schema at na-validate na I/O ang pinakamurang reliability na mabibili mo.

Mag-verify nang adversarial. Huwag pagkatiwalaan ang mapagkumpiyansang unang pass. Magdagdag ng hiwalay na hakbang na ang trabaho ay pabulaanan ang resulta.

Sukatin sa pamamagitan ng evals. Buuin ang eval harness bago mo palakihin ang agent. Hindi mo mapapahusay ang hindi mo masusukatan.

I-engineer ang konteksto, huwag ibuhos. Kunin ang may kaugnayan; tandaan ang mahalaga. Ang mas malalaking prompt ay hindi mas magagandang prompt.

I-sandbox ang lahat ng untrusted. Kung nagpapatakbo ng code ang isang agent, ang isolation ay isang kinakailangan, hindi isang feature.

Magpanatili ng landas para sa tao. Ang pinakaligtas na autonomous system ay ang isang nakakaalam kung kailan magtanong sa isang tao.

Mga madalas itanong

Ano ang pagkakaiba ng AI agent sa chatbot?

Ang chatbot ay gumagawa ng teksto; ang AI agent ay nagpaplano at kumikilos — tumatawag ng mga tool, nagpapatakbo ng code, at nag-iiterate patungo sa layunin. Ang hirap sa engineering ay ang reliability sa maraming hakbang, kung saan kahit isang error ay maaaring sumira sa kalalabasan.

Paano nyo pinapatakbo nang ligtas ang code na ginawa ng AI?

Sa pamamagitan ng sandboxed code execution: tumatakbo ang untrusted code sa nakahiwalay na environment na may limitadong resource, walang secret access, at limitadong networking, kaya makaka-compile, makaka-test, at makaka-ayos ang agent nang walang panganib sa platform.

Bakit napakahalaga ng evals para sa agent systems?

Dahil stochastic ang mga agent, kailangan mo ng automated na evals para masukat ang kalidad sa mga representatibong gawain at mahuli ang mga regression bago ipadala. Kung wala ang mga ito, ang "mga improvement" ay puro hula lang.

Ano ang ginagawa ng Jobbit Labs?

Ang Jobbit Labs (jobbitlabs.com) ang R&D at data division sa likod ng Jobbit, na nakatuon sa mas mabigat, data-intensive, at enterprise engineering — pananaliksik, data platforms, at ang mga pundasyong agent kung saan nakatayo ang produkto.

Interesado sa engineering sa likod ng mga agent na nagde-deploy ng software? Tuklasin ang jobbit.uk at jobbitlabs.com.