Pagpapanatiling Nasa Context Window ang Mahahabang Agent Turn

Kaya lang basahin ng model ang isang tiyak na dami nang sabay-sabay, ang tinatawag na context window nito. Gumagawa ang agent ng Mythex ng mahabang trabaho: pagbasa ng maraming file, pagpapatakbo ng command, at pagbibigay ng nakatakdang gawain sa sub-agents. Nakita namin ang tatlong paraan kung paano pumalya ang mahabang trabaho: lumaki ang sub-agents hanggang tanggihan ng model ang bawat request, huminto nang maaga ang isang sub-agent dahil akala nitong wala na itong espasyo, at malayo sa tama ang bilang ng token namin para sa tekstong Russian, Chinese at Japanese. Ito ang binago namin.

Ilang termino muna

Tokens ang mga piraso ng teksto na binabasa ng model. Sa tokens binibilang ang mga limitasyon at gastos, hindi sa karakter o salita.
Context window ang pinakamalaking dami na mababasa ng model sa isang request. Nagtakda rin kami ng sarili naming mas mababang budget para sa bawat request, para makontrol ang gastos at bilis.
Tool results ang ibinabalik ng mga tool sa agent: ang laman ng file na binasa nito, ang output ng command na pinatakbo nito. Sa mahabang trabaho, sila ang karamihan sa ipinapadala.
Ang sub-agent ay katulong na sinisimulan ng pangunahing agent para sa isang hiwalay na gawain, gaya ng “i-check ang mga kabanatang ito laban sa mga tala”. Isang tagubilin ang natatanggap nito, saka nito pinagtatrabahuhan ang maraming tool call nang mag-isa.

Problema 1: lumaki ang sub-agents hanggang tanggihan sila ng model

Sa bawat hakbang, ipinapadala ng agent sa model ang usapan hanggang sa puntong iyon. Kapag sobrang laki na nito, pinuputol ito ng code namin, pero sa simula lang ng user message, para hindi kailanman mahati ang isang tool call at ang resulta nito. Itinatago nito ang unang mensahe, nagdadagdag ng tala na pinutol ang naunang usapan, at pinananatili ang pinakabagong buong turn na kasya.

Iisa lang ang user message ng sub-agent: ang tagubilin nito. Walang puwedeng putulan. Kaya ipinapadala nito ang buong kasaysayan nito sa bawat hakbang, lumalaki sa bawat pagkakataon, hanggang lumampas ang request sa dami na tinatanggap ng model, mga isang milyong token. Sa isang test na may 8 ganoong sub-agent, tinanggihan lahat ng 8.

Ang ayos: burahin muna ang mga lumang tool result

Nagkakasya na ngayon ang mga request sa budget sa tatlong hakbang, sinusubukan ang bawat isa lang kapag hindi sapat ang nauna:

Burahin ang pinakalumang tool results. Papalitan ang laman nito ng maikling tala: binura ang resulta para manatili ang usapan sa context ng model, at maaaring patakbuhin ulit ng agent ang tool kung kailangan nito. Ang file na binasa isang oras na ang nakalipas ay kadalasang pinakamalaki at pinakahindi kapaki-pakinabang sa request, at nandoon pa rin ang file para basahin ulit. Buo pa rin ang pinakabagong resulta.
Panatilihing buo ang user turns. Gaya ng dati: ang unang mensahe, isang tala, at ang pinakabagong buong turn na kasya.
Panatilihing buo ang tool rounds. Sa loob ng isang mahabang turn, na siya lang uri na mayroon ang sub-agent, panatilihin ang unang mensahe, isang tala, at ang pinakabagong buong round ng “tumawag ng tool, makuha ang resulta nito”.

Naghuhubog lang ito ng ipinapadala. Pinananatili pa rin ng naka-save na kasaysayan ng agent ang lahat. Sa parehong test, 0 sa 8 ang tinanggihan at natapos lahat ng 8.

Pagbubura nang maramihan, para gumana pa rin ang caching

Kayang gamitin muli ng mga provider ng model ang nagawa na sa simula ng request kung pareho ito sa huli, isang prefix cache. Kung buburahin namin ang isa pang resulta sa bawat tawag, magbabago ang simula ng request sa bawat tawag at hindi kailanman makakatulong ang cache.

Kaya apat-apat na binubura ang pinakalumang resulta, hindi isa-isa. Nananatiling pareho ang naburang bahagi sa maraming tawag. Hindi ginagalaw ang resultang hindi gaanong mas malaki sa tala: ang pagbura nito ay halos walang natitipid at babaguhin pa rin ang simula ng request. Ang laki ang nagpapasya kung ilan ang nananatiling buo, hindi ang bilang: ang pinakabagong resulta na kasya sa isang-kapat ng budget ang nananatili, at palaging hindi bababa sa isa. Naglagay ang naunang bersyon ng nakapirming anim na buo, na tama para sa maiikling output ng command, pero sa mahabang pagbasa ng file ay nag-iwan ito ng karamihan ng budget sa mga lumang resulta.

Sinasabi na ngayon ng mga pagtanggi kung bakit

Hindi na inuulit ang request na tinanggihan ng model bilang invalid; kapag ipinadala ulit ang parehong request, parehong sagot din ang makukuha. Kapag masyadong mahaba ang usapan para sa model, makikita ng tao: “Naging masyadong mahaba ang usapang ito para mabasa ng model nang sabay-sabay. Magsimula ng bagong chat para sa susunod na hakbang. Mananatili ang lahat ng nagawa na.” Desisyon iyon ng tao, hindi pagkawala ng serbisyo, kaya hindi kami ginigising nito.

Problema 2: huminto ang agent para “makatipid ng espasyo”

Isang sub-agent na hiniling na basahin ang 40 mahabang kabanata ay huminto pagkatapos ng 2, at sinabing gusto nitong makatipid ng espasyo. Gumamit ito ng mga 100,000 token sa budget na 400,000.

Wala itong paraan para malaman na buburahin na ngayon ang mga lumang resulta para dito. Kaya sinabi namin ito. Ngayon, sinasabi ng mga tagubilin ng agent na kapag lumampas ang usapan sa kayang tanggapin ng model, binubura ang pinakalumang tool results at nananatiling buo ang pinakabago. Kaya huwag huminto sa mahabang gawain para makatipid ng espasyo; magpatuloy, at basahin ulit ang file kung kailangan mo ang nabura.

Hindi pag-aayos mula sa pananaw ng model ang ayos na hindi nakikita ng model. Makakatulong lang ang mekanismo kapag nagtitiwala ang agent dito.

Problema 3: pagbibilang ng token na parang lahat ay Ingles

Tinatantya namin ang token nang hindi pinapatakbo ang tokenizer, bilang karakter na hinati sa apat. Makatwirang panuntunan iyon para sa Ingles. Hindi ito para sa ibang script: ang Russian ay mga 2.2 karakter kada token, at ang Chinese o Japanese ay mga isa.

Kaya ang isang sub-agent na nagbabasa ng mga kabanatang Russian ay nagpadala ng request na mga 640,000 token, habang sinasabi ng tantya namin na nasa ilalim ito ng 400,000 na budget. Maaari ring lumampas ang tantya sa mahigpit na limitasyon ng model.

Ayon na sa script ang bilang ng tantya: karaniwang ASCII sa apat na karakter kada token, Chinese, Japanese at Korean sa isa, at ang lahat ng iba pa (Cyrillic, Greek, Arabic, mga may tuldik na letra, emoji) sa dalawa. Sinadya itong magkamali nang mataas. Sa isang kabanatang Russian, ngayon ay tinatantya ito sa 43,423 token laban sa mga 44,600 na sinukat; noon, 25,023 ang sinasabi nito. Dahil hindi na nagbabago ang mensahe kapag naisulat na, isang beses kinakalkula ang tantya nito at itinatago, sa halip na sa bawat hakbang.

Ang natutunan namin

Putulin kung nasaan talaga ang laki. Sa trabaho ng agent, nasa tool results iyon, hindi sa user messages.
Sabihin sa agent ang tungkol sa sarili nitong safety net. Kung hindi, magpaplano ito ayon sa mga limitasyong hindi na umiiral.
Ang “karakter ÷ 4” ay palagay para sa Ingles. Anumang bumibilang ng token para sa mga user na maraming wika ay dapat magbilang ayon sa script, o gumamit ng totoong tokenizer.
Bantayan ang cache. Ang request na nagbabago sa unahan sa bawat tawag ay mas mahal at mas mabagal.

Kung nagdaragdag ka ng AI features sa sarili mong app, sakop ng aming mga guide tungkol sa ano ang LLM at paano gumamit ng LLM APIs ang context window at tokens mula sa simula. Mas marami pang detalye tungkol sa paggana ng sub-agents sa Mythex sa sub-agents docs.