May-akda: Yanhua
Si Antonio Gullí ay ang direktor ng engineering sa Google. Isinulat niya ang isang libro na may 453 na pahina na naghihiwalay sa pagbuo ng AI Agent sa 21 mga disenyo pattern.
Ngunit hindi ito isang pagsusuri ng aklat. Ang aking motibasyon sa pagbabasa ng aklat ay espesipiko: Ipinagsulat ko ang Harness Engineering, ang mga aral mula sa Clawdbot, at ang artikulong “Ang AI Agents Ay Hindi Magic” na naglalahad ng pitong pagbabago mula sa pagbuburn ng Token hanggang sa pagiging totoong gamit. Pagkatapos ng bawat pagsusulat, may isang tanong na hindi pa lubos na naisip: Mayroon bang isang maaaring gamitin muli na pundamental na lohika sa likod ng lahat ng ito?
Binigyan ako ng sagot ang aklat na ito, at mas malalim kaysa sa aking inaasahan.
Maaaring hindi talaga ang isinulat mo ay Agent
Ang pinakamalakas na pagtataya sa libro ay nakatago sa prologo.
Ang karamihan sa mga tao ay gumagamit ng “AI” na Level 0: walang kasamang tool, walang memorya, at hindi kayang mag-act. Kapag tanong mo sa kanya kung ano ang pinakamahusay na pelikula sa Oscars noong 2025, susuhestyon lang niya. Malinaw ito sa aklat: ang mga bagay na Level 0 ay hindi Agent.
Tumataas ang tama na Agent:
Level 1: Gumagamit ng kasangkapan
Nagsisimula na ang agent na gamitin ang mga kasangkapan: paghahanap, API, database. Pero hindi ito kailangan lang na “makapag-call ng API,” kundi kailangan din na mag-isip nang sarili kung kailan dapat i-call, ano ang dapat i-call, at paano gamitin ang resulta. Mayroon ang libro ng isang tiyak na halimbawa: sinasabi ng user, “Ano ang mga bago ngayong palabas?” Naiintindihan ng agent na ang impormasyong ito ay hindi nasa training data, at aktibong nag-call ng search tool para maghanap, at pagkatapos ay isinama ang resulta. Ang mahalagang hakbang ay ang “sariling pagkakaroon ng pagkakaintindi.” Hindi ito sinabi ng tao na “Pumunta ka at maghanap,” kundi sariling nag-decide ang agent na kailangan maghanap. Ang kakayahang ito sa pagdedesisyon, ay ang hangganan ng Level 1.
Level 2: Mga Estratehikong Mipag-isip
Dalawang bagay pa: plano at Context Engineering. Ipinapaliwanag ng aklat ang Context Engineering: hindi pagpupuno ng impormasyon, kundi pagsusuri, pagpapaliit, at pagsasama ng konteksto. Magandang halimbawa: ang user ay naghahanap ng tindahan ng kape sa pagitan ng dalawang lugar. Una niyang tinatawag ang tool ng mapa para makakuha ng maraming data, tapos pinapasyahan niya na “ang susunod na kailangan ay ang mga pangalan ng kalye lamang,” kaya binawasan niya ang output ng mapa sa isang maikling lista, at ibinigay ito sa local search tool. Sa bawat hakbang, ginagawa ang pagbabawas ng ingay sa impormasyon.
May isang pangungusap sa aklat na muling binasa ko nang ilang beses: “Upang makamit ng AI ang pinakamataas na akurasyo, kailangan mong bigyan ito ng maikli, nakafokus, at makapanghihikayat na konteksto.” Ang Context Engineering ay ang paggawa nito.
Sa antas na ito, ang Agent ay kayang mag-isip nang kritikal. Pagkatapos gawin ang trabaho, sinusuri nito ang sarili nito at binabago ang mga problema nito. Iiwanan ko ang detalye para sa susunod.
Level 3: Maraming Agent na Pakikipagtulungan
Malinaw ang pananaw ng aklat: Huwag mag-isip ng isang nag-iisang super agent na makakagawa ng lahat. Ang totoong maaasahan ay tulad ng pagbuo ng isang koponan: Project Manager Agent + Researcher Agent + Designer Agent + Copywriter Agent. Ang halimbawa sa aklat ay ang paglunsad ng isang bagong produkto: ang isang “Project Manager Agent” ang nagpapatakbo at nagpapadala ng mga gawain sa “Market Research Agent,” “Product Design Agent,” at “Marketing Agent.” Ang susi ay ang komunikasyon: paano nagpapadala ng data ang mga agent, paano sinisync ang kanilang estado, at paano nila inaayos ang mga pagkakaibigan. Mayroong anim na uri ng komunikasyon topology na ipinakita sa kabanata, mula sa pinakasimpleng isang agent hanggang sa pinakamalayang custom hybrid, at may paliwanag kung anong sitwasyon ang bawat isa ay angkop.
Pagkatapos basahin ang apat na antas, biglang naiintindihan ko kung bakit maraming tao ang nagsasabi, “Hindi gumagana ang aking Agent.” Wala namang problema sa model, ang problema ay ginagamit mo ito bilang chatbot, at baka hindi pa ito nakarating sa Level 1.
Context Engineering: Ang pinakamababaw na konsepto sa aklat
Isinulat ko ang isang artikulo tungkol sa Harness Engineering, kung saan sinasabi na mas mahalaga ang disenyo ng track kaysa sa kapangyarihan ng engine. Pagkatapos basahin ang aklat na ito, naintindihan ko na ang Context Engineering ay ang pagkakapareho ng Harness Engineering sa antas ng prompt.
Ang tradisyonal na Prompt Engineering ay tumutok lamang sa “paano mo ito hihingi.” Ang Context Engineering sa aklat ay tumutok sa “ano ang nasa harap ng Agent bago mo ito hihingi.” Kasama nito ang apat na antas ng impormasyon:
Unang antas, system prompt. Tukuyin kung sino ang Agent, ano ang tono, at ano ang mga hangganan. Ang karamihan ay nag-isulat lang ng unang antas.
Ikalawang layer, eksternal na data. Mga dokumento na hinango ng RAG, mga return value mula sa pagtawag ng mga tool, at real-time API data. Ito ang lugar kung saan nakakapagod ang karamihan: alam nilang kailangan magbigay ng data, ngunit hindi alam kung paano magbigay nito nang hindi isasalot ang modelo.
Ikatlong antas, implictong data. Pagkakakilanlan ng user, kasaysayan ng interaksyon, estado ng kapaligiran. Ito ay mga bagay na hindi mo sinasabi ng diretso ngunit dapat alam ng Agent. Halimbawa, kung sabihin mo sa Agent, “Tulongan mo akong magpadala ng email kay John para i-confirm ang meeting bukas,” dapat alam nito kung ano ang meeting mo bukas sa iyong kalendaryo at ano ang ugnayan mo kay John.
Ikaapat na antas, loop ng feedback. Pagkatapos ng bawat output ng Agent, awtomatikong isasagawa ang pagtataya sa kalidad at i-aadjust ang susunod na estratehiya ng konteksto. Tinatawag ng aklat ito bilang “automated context optimization,” at ang Google’s Vertex AI Prompt Optimizer ay ang inhenyerya na implementasyon ng ideyang ito.
Nang mabasa ko ito, naisip ko ang nakaraang sinulat kong “Ang AI Agents Ay Hindi Magick,” kung saan may isang aral na “Kailangan ng iyong agent ng mga patakaran, at marami pa.” Ngayon, tingnan ko muli, ang mga patakaran na iyon ay本质上 ang kamay-pananaw na bersyon ng Context Engineering, at sinistematisa nito ang aklat.
Reflection: Talagang mas mabuti ang dalawang Agent kaysa isa
Ito ang pinakamalaking pattern sa buong aklat na may pinakamalaking praktikal na halaga para sa akin.
Ang core ng Reflection ay simpleng: pagkatapos gawin ng Agent ang trabaho, ito ay susuriin nito mismo at babaguhin nito ang mga problema na nakikita. Ngunit ang paraan ng pagsasagawa ay may kahalagahan. Malinaw na sinabi sa aklat: ang Producer at Critic ay dapat gumamit ng dalawang magkakaibang Agent, araw-araw na may iba’t ibang system prompt. Kung iisang persona ang susuri sa kanyang sariling gawa, mayroong mga blind spot. Kung ipapalabas mo ang iisang LLM upang muna sumulat ng code at pagkatapos ay suriin ang sariling code, malaki ang posibilidad na sasabihin nito, “Mabuti.”
Ang libro ay nagbibigay ng isang kumpletong halimbawa ng code.
Ang prompt ng producer ay “Ikaw ay isang Python developer, sumulat ng isang function na kalkulahin ang factorial, at tratuhin ang mga boundary condition at exception.”
Ang prompt ng Critic ay “Ikaw ay isang masusing senior engineer na sumusuri ng code sa bawat linya, nag-aaral ng Bug, istilo, nawawalang boundary conditions, at mga lugar na maaaring mapabuti. Kung perpekto, ilabas ang
CODE_IS_PERFECT, kung hindi, listahan ang lahat ng mga problema.”Pagkatapos ay isang for loop: Isusulat ng Producer ang code → Sinusuri ng Critic → Binabago ng Producer batay sa puna → Sinusuri muli ng Critic → Hanggang sa sabi ng Critic na
CODE_IS_PERFECTo matapos ang pinakamataas na bilang ng iterasyon.
Simpleng ganyan. Ngunit binabalaan ng aklat ng isang madalas na nakakalimutang gastos: bawat reflection cycle ay isang bagong LLM call, at mas maraming iterasyon, mas mataas ang gastos. Bukod dito, habang lumalaki ang kasaysayan ng usapan, ang context window ay nabubuo ng mga nakaraang bersyon at mga kritika, kaya bumababa ang praktikal na espasyo para sa pag-iisip. Kaya ang pinakamahusay na pamamaraan sa Reflection ay: itakda ang isang makatwirang maximum na bilang ng iterasyon (ginamit ng aklat ang 3), at itigil agad kapag natutuwa ang Critic—hindi dapat habulin ang perpektsyon.
Higit pa sa pagsulat ng code. Maaari itong gamitin sa pagsulat ng artikulo, paggawa ng plano, pagsusumaryo ng dokumento, at paglutas ng mga logic problem—ang Producer-Critic model ay maaaring gamitin sa lahat. Ibinigay ng aklat ang pitong mga aplikasyon, at ang pangunahing lohika ay pareho: unang lumikha, pagkatapos ay suriin, at pagkatapos ay ayusin.
Hindi mas mabuti ang Multi-Agent kung mas kumplikado ito
Ang pinakamasarap na bahagi ng seksyong ito ay ang anim na uri ng komunikasyon topology. Marami ang agad nagpapalit ng mga kumplikado, ngunit sa karamihan ng mga sitwasyon, sapat na ang tatlo:
Single Agent (Independent Execution): Ang task ay maaaring hiwalayin sa mga sub-problem na walang kinalaman sa isa't isa, at bawat Agent ay nag-aayos ng sarili nito. Simple at madaling pangalagaan.
Peer-to-Peer: Direkta ang komunikasyon sa pagitan ng mga Agent, walang sentral na node ng kontrol. De sentralisado, mataas ang fault tolerance, ang pagkabigo ng isang Agent ay hindi nakakaapekto sa buong sistema. Ngunit mataas ang gastos sa koordinasyon, madaling magkakaroon ng kaguluhan.
Supervisor (sentral na pagpaplano): Isang Supervisor Agent ang nagpapamahala sa isang grupo ng Worker Agent. Nag-aalok ng mga gawain, nagkukolekta ng mga resulta, at naglulutas ng mga konflikto. Malinaw ang hierarchy, madaling pamahalaan. Ngunit ang Supervisor ay isang single point of failure at bottleneck sa performance.
Ang tatlong iba pang uri (Supervisor-as-Tool, hierarkikal, at custom hybrid) ay mga variant at kombinasyon ng mga unang tatlo. Malinaw ito sa aklat: ang iyong kinakailangang topolohiya ay nakadepende sa karamihan ng iyong task. Habang mas hahati-hatiin ang task, mas mataas ang gastos sa komunikasyon, at sa isang tiyak na punto, mas epektibo ang Supervisor pattern kaysa sa hierarkikal.
Ang aking karanasan ay, marami ang nagugugol ng 80% ng kanilang oras sa paggawa ng communication protocol habang nagkalimot magtanong sa isang mas pangunahing tanong: kailangan ba talaga ng maraming Agent ang gawain na ito? Malinaw ito sa aklat: ang Level 2 na single Agent + Reflection ay madalas ay sapat na. Ang Level 3 ay para sa mga sitwasyon kung saan ang single Agent ay talagang hindi kayang gawin.
Memory na tatlong antas, naantipas ko na dati pero hindi ko pa binigyang pangalan
Ang kabanata ng Memory ang pinakamalalim sa akin, dahil habang isinulat ko ang dalawang artikulo tungkol sa Obsidian + Claude, patuloy kong isinasaalang-alang ang tanong: Paano dapat i-layer ang memory ng Agent?
Ang sagot ay nasa libro:
Session (Session Layer): Ang kontekstong bintana ng kasalukuyang usapin, ito ang pinakamaikling memorya at nawawala kapag natapos ang usapan. Ang mga modelo ng mahabang konteksto ay nagpapalawak lamang ng bintanang ito, ngunit sa pamamagitan ng本质上 ay pansamantala pa rin, at kailangang prosesuhin ang buong bintana sa bawat inference, kaya mahal at mabagal.
State (estado): Temporal na data habang nagpapatakbo ang gawain. Halimbawa, “Ano ang kasalukuyang gawain”, “Saan na ang progreso”, at “Ano ang mga intermediate na data na nabuo”. Mas mahaba kaysa sa Session, ngunit i-clear agad pagkatapos ng gawain. Nagbigay ang libro ng kompletong halimbawa gamit ang State mechanism ng Google ADK.
Memory (persistence layer): Matatag na memory na nagpapagana sa pagitan ng sesyon at task. Ang mga user preference, natutunang karanasan, at mahahalagang historical na desisyon ay itinatago sa database o vector library, gamit ang semantic retrieval. Binigyang-diin ng aklat ang isang napakahalagang punto: ang Memory ay hindi lang nakakatipon, kundi kailangan din ng isang buong estratehiya para sa “ano ang dapat i-store, kailan dapat i-store, at paano i-retrieve”. Masyadong maraming i-store ay nagdudulot ng ingay, samantalang masyadong kaunti ay hindi sapat.
Sa aking nakaraang artikulo tungkol sa Clawdbot, binanggit ko ang “state file” at “workspace document”, na sa pangkabuuan ay nagmumula sa paggawa ng State layer at Memory layer nang kamay; binigyan ng framework nito ng aklat.
Limang hypothesis, ang ikalimang isa ay pinakakamalayong-kamalayon
Ibinigay sa huli ang limang hipotesis tungkol sa kinabukasan ng Agent, at ang unang apat ay nasa loob pa rin ng makatotohanang pagtataya: ang pangkalahatang Agent mula sa pagsusulat ng code hanggang sa pagpapamahala ng proyekto, ang malalim na personalisadong aktibong paghahanap ng iyong mga pangangailangan, ang embodied intelligence na lumalabas sa screen at pumasok sa pisikal na mundo, at ang Agent bilang independiyenteng ekonomikong entidad.
Ilang panglima ang nagbigay-sigaw sa akin: Deformable Multi-Agent.
Magpapahayag ka lamang ng layunin, tulad ng “Gumawa ng isang e-commerce na negosyo para sa specialty coffee.” Ang sistema ay awtomatikong magdedesisyon: unang lumikha ng “Market Research Agent” at “Brand Agent.” Pagkatapos ng isang round ng data, awtomatikong masusuri na hindi kailangan ang Brand Agent, at ihihiwalay ito sa tatlong bagong agent: “Logo Design Agent,” “Website Building Agent,” at “Supply Chain Agent.” Kung ang Website Building Agent ang naging bottleneck, awtomatikong pipiliin ng sistema na kopyahin ito sa tatlong parallel na agent na magtatrabaho nang sabay-sabay sa iba’t ibang pahina. Sa buong proseso, awtomatikong tinatamaan ng sistema ang bawat agent’s prompt at patuloy na binabago ang istruktura ng team.
Tinatawag ng aklat na “goal-driven, self-transforming multi-agent system.” Hindi ito nagpapatupad ng iyong isinulat na plano, kundi nagbuo ng sarili nitong plano, nag-aadjust ng sarili nitong plano, at nagre-reorganize ng sarili nitong team ng pagpapatupad.
Ito ang nagpapagising sa akin sa AutoResearch ni Karpathy: isulat ang isang program.md, tukuyin ang layunin, mga indikador, at mga hangganan, tapos i-trigger ang “start”. Ang tao ay nasa labas ng loop. Pero hinaharap ng aklat na ito ang mas malalim: kahit paano magbuo o mag-restructure ng isang ekipa ng Agent, ibinibigay na sa sistema ang desisyon. Ang tao ay nagpapahayag lamang ng “ano ang kailangan”.
Tatlo pang gagawin agad
Pagkatapos basahin ang libro, may tatlong aksyon na agad kong maaaring gawin:
Una, idagdag ang isang Critic sa kasalukuyang Agent mo. Anuman ang gamit mo—Claude Code, CrewAI, o sariling framework—dagdagan ang isang hakbang sa dulo ng iyong kasalukuyang workflow: pahintulutan ang isa pang Agent (gamit ang iba’t ibang system prompt) na suriin ang output ng nakaraang hakbang. Code generation ay kasama ang code review, pagsusulat ng artikulo ay kasama ang fact-checking, at paggawa ng plano ay kasama ang pagtataya ng kakayahang maisagawa. Isang karagdagang pagtawag sa LLM, ngunit ang pagtaas sa kalidad ay madalas ay doble. Ang Producer-Critic pattern sa aklat ay ready to use.
Ikalawa, simulan ang Context Engineering, hindi lang ang Prompt Engineering. Tingnan muli ang iyong file ng mga utos para sa Agent. Kung ang lahat ay mga patakarang “Ano ang dapat gawin mo,” at kulang sa konteksto na “Ano ang iyong nakikita ngayon,” idagdag ito. Sabihin sa Agent kung saan ito nasa isang proyekto, anong mga desisyon ang ginawa nito dati, at ano ang mga preferensya ng user. Ang kabanata ng Context Engineering sa aklat at ang iyong
AGENTS.mday dalawang pagpapahayag ng parehong bagay.Ikatlo, huwag muna mag-umpisa sa Multi-Agent. Gawin mo muna ang iyong Single Agent hanggang Level 2: may mga kasangkapan, may Reflection, at may Memory. Muli itong binigyang-diin sa aklat na ang Level 2 na Single Agent kasama ang Producer-Critic at Context Engineering ay makakapag-akma sa karamihan ng mga praktikal na sitwasyon. Ang Level 3 ay para sa mga tunay na跨领域, maraming yugto, at kailangang magkaroon ng paralel na paghahati ng trabaho. Ang karaniwang problema ng karamihan ay hindi ang kulang sa bilang ng Agent, kundi ang hindi pa maayos na isang Agent.
453 pahina, inilabas ng Springer noong 2025. Ang mga halimbawa ng code ay kumakalat sa LangChain/LangGraph, Google ADK, CrewAI, at OpenAI API. Ang paunang salita ay isinulat ng VP ng Google Cloud AI, at may rekomendasyon mula sa CIO ng Goldman Sachs—nagustuhan nang hindi inaasahan.
Ngunit ang dahilan kung bakit ko ito inirerekomenda ay hindi “komprehensibo”. Pagkatapos mong basahin, malalaman mo ang isang bagay: ang lahat ng mga pagkakamali na iyong ginawa sa Agent sa nakaraang anim na buwan, ay mayroon nang nag-ayos ng mga pattern. Hindi ka na kailangang mag-imbento ng Reflection, hindi ka na kailangang maghula kung paano i-divide ang Memory, at hindi ka na kailangang subukan kung anong uri ng communication topology ang gagamitin sa Multi-Agent.
May nag-gawa ng mapa para sa iyo, ang natitira ay ang paglalakad.
Ginagamit mo ba ang AI Agent sa pag-develop? Saan na level ang iyong Agent ngayon?