Pengurangan Kuota Claude Code: Adakah Agen Mencipta 'Gunung Kod Legasi' Baharu?

Kuota mingguan Claude Code diperpanjang mendapat perhatian, artikel menganalisis mekanisme penggunaan Token pada program Agent. Pemakaian jangka panjang Agent menyebabkan working set terus membesar, setiap langkah mengakumulasi status historis, ditambah sifat cache yang tetap mengambil ruang context meski berjaya, menjadikan kos komputasi meningkat secara akumulatif. Pembersihan berlebihan akan menyebabkan “semantic page fault”, di mana Agent perlu mendapatkan semula maklumat. Artikel menunjukkan ketidakkonsistenan antara keadaan kod dan ketepatan penyimpanan keadaan reka bentuk boleh menyebabkan “kod warisan” yang dihasilkan AI: Agent seterusnya tidak dapat memahami sebab-akibat reka bentuk kod awal, akhirnya membentuk kod kompleks yang saling mengimbangi queue, bypass, dan retry.

Penulis artikel, sumber: Leifengwang

Kod memang ditulis oleh Agent, tetapi Agent seterusnya tidak lagi tahu mengapa Agent sebelumnya menulisnya begitu.

Kuota tambahan +50% untuk Claude Code yang asalnya dijadwalkan berakhir pada 19 Ogos telah diperpanjang oleh Anthropic hingga 31 Ogos. Sekitar masa penghujung tarikh asal, muncul perbincangan di Hacker News mengenai kos penggunaan Claude Code: ramai mendapati bahawa tugas yang tidak terlalu kompleks, apabila agen menjalankan beberapa pusingan, kuota akan berkurang dengan cepat.

Masalahnya ialah, Claude Code tidak hanya menghabiskan beberapa baris kod terakhir yang dihasilkan. Membaca fail, mencari rantai panggilan, menjalankan ujian, dan memproses log—setiap langkah akan terus memasuki konteks seterusnya. Semakin panjang tugas, semakin berat sejarah yang dibawa oleh Agen, dan sistem menjadi semakin bergantung kepada pembersihan dan pemampatan.

Kod boleh kekal sepenuhnya di repositori, tetapi sebab rekaan awal mungkin menjadi semakin nipis semasa pemampatan. Oleh itu, penggunaan Token dan tumpukan kod kotor bermula bertemu di tempat yang sama.

Batas pengiraan untuk coding chat biasa adalah jelas. Masukkan satu potong kod, model membacanya dan memberikan penjelasan atau cadangan pengubahsuaian, putaran ini pada dasarnya berakhir.

Unit asas Claude Code telah ditukar kepada agent loop. Model terlebih dahulu mengamati status semasa, menentukan fail mana yang perlu dibaca atau arahan mana yang perlu dijalankan; selepas alat mengembalikan hasil, model akan membuat penilaian seterusnya.

Membaca kod sumber, mencari rujukan, menjalankan ujian, melihat Git diff, dan mengubah fail kelihatan seperti satu tindakan berterusan, tetapi di sisi model, ia sebenarnya serangkaian permintaan inferens yang berasingan. Dokumentasi rasmi Claude Code juga menjadikan perulangan “penilaian model—panggil alat—penilaian berterusan berdasarkan keputusan” sebagai inti cara kerja Agen.

Sebagai contoh, masalah kegagalan status log masuk secara berkala. Agen terlebih dahulu mencari titik masuk, mendapati status berasal dari service, lalu meneruskan membaca service; setelah melihat cache, mencari siapa yang menulisnya; kemudian menjalankan ujian, ujian menghasilkan pengecualian lain, jadi melihat fixture; selepas memperbaiki, mengesahkan semula, ujian lama sekali lagi mengungkapkan masalah kompatibiliti.

Mungkin baru pada saat ini ia benar-benar menulis beberapa baris kod. Oleh itu,diff antara saiz dan jumlah pengiraan hampir tidak ada nisbah yang stabil. Di belakang patch 5 baris mungkin hanya ada 3 inferens, atau mungkin telah melalui 30 interaksi alat.

Jika tugas Agent dibahagikan, dua pemboleh ubah boleh diperoleh: satu ialah jumlah langkah, iaitu berapa banyak langkah yang diambil Agent untuk menyelesaikan tugas; dan yang lain ialah set kerja, iaitu berapa banyak status item yang masih perlu dipahami oleh model pada langkah semasa.

Hanya menambahkan langkah hitung sudah akan meningkatkan penggunaan. Jika working set masih terus membesar semasa disegerakan, keadaannya akan berbeza sama sekali. Langkah ke-3 mungkin hanya perlu memproses beberapa ribu Token, tetapi langkah ke-30 mungkin sudah membawa bersama peraturan projek, kod sumber berkaitan, keputusan ujian, sejarah pengubahsuaian, dan alat untuk meneruskan penarikan kesimpulan.

Ini juga merupakan titik permulaan perubahan struktur kos Coding Agent: jumlah pengiraan kini bergantung kepada “berapa banyak langkah × berapa berat setiap langkah”, bukan lagi berdasarkan berapa banyak baris kod yang ditulis.

Permintaan model Agent boleh dibahagikan kepada tiga bahagian kasar. Bahagian yang相对 stabil termasuk system prompt, CLAUDE.md, definisi alat, dan peraturan projek; bahagian yang sentiasa berubah termasuk fail kod, keputusan carian, log ujian, Git diff, dan trajektori tugas sebelumnya; akhirnya, terdapat reasoning, teks, dan kod yang dihasilkan oleh model dalam putaran ini.

Di sini terdapat salah faham yang mudah berlaku: sekiranya kandungan sebelumnya telah dibaca, seharusnya tidak perlu menghasilkan kos berulang yang banyak. Masalahnya ialah, LLM tidak mempunyai ingatan dalaman yang boleh diakses secara sewenang-wenang seperti program tradisional. Maklumat yang diketahui pada putaran sebelumnya, jika putaran seterusnya masih bergantung padanya, keadaan berkaitan masih perlu muncul dalam konteks yang tersedia.

Prompt cache boleh meredakan masalah ini. Dokumentasi rasmi Claude Code dengan jelas menyatakan bahawa tanpa cache prompt, setiap permintaan perlu memproses sejarah penuh semula; selepas cache berjaya, imbuhan awal yang telah diproses dan stabil boleh digunakan semula, yang mengurangkan pengiraan berulang dan kos.

Tetapi cache menyelesaikan "bolehkah sejarah yang sama digunakan semula dengan lebih murah", tetapi tidak menyelesaikan "adakah sejarah ini perlu diteruskan". Keadaan lama 100K Token yang mengenali cache menjadi lebih murah, tetapi ia masih mengambil ruang konteks, dan tetap menjadi keadaan di atas mana inferens semasa dibina.

于是可以把一个长任务粗略写成：第 t 步的输入规模，大约等于稳定前缀 S，加上当前有效工作集 W_t，再加这一轮刚产生的新信息 Δ_t。

Yang benar-benar menjadi masalah adalah W_t. Jika setiap langkah, Agen membaca lebih banyak kod sumber, mendapat lebih banyak log, dan meninggalkan keputusan tambahan, sementara maklumat lama tidak dikeluarkan dengan segera, maka W_t akan terus meningkat seiring kemajuan tugas.

Dalam model yang sangat disederhanakan tanpa cache atau pembersihan sama sekali, jika jumlah status berkesan yang ditambahkan setiap pusingan hampir sama, jumlah pemprosesan keseluruhan akan menunjukkan struktur akumulasi mendekati 1 + 2 + 3 + … + n. Dengan kata lain, jumlah langkah hanya meningkat dua kali ganda, tetapi sejarah status yang telah diproses oleh tugas tersebut mungkin meningkat lebih cepat.

Sistem sebenar mempunyai cache, pengeditan konteks, dan pemadatan, dan tidak akan mengikuti lengkung pertumbuhan ini secara mekanikal, tetapi bentuk masalahnya tidak berubah: semakin lama Agent beroperasi, semakin besar kemungkinan setiap tindakan baru akan dibina di atas sejarah yang lebih berat.

Jadi, prompt pengguna yang sangat pendek dalam tugas panjang akan cepat kehilangan kehadirannya. Yang benar-benar mulai mendominasi kos, adalah set kerja yang terus dibawa oleh model untuk mempertahankan kesinambungan tugas.

Mengapa set kerja membengkak sebegitu pantas? Output alat adalah sumber utama. Kod sumber sekurang-kurangnya mempunyai struktur, tetapi log sering tidak ada.

一次 grep boleh mengembalikan ratusan rujukan, satu pembinaan mungkin menghasilkan banyak peringatan, satu kegagalan ujian mungkin membawa trace stack penuh, Docker, compiler, dan pengurus pakej juga akan menghasilkan banyak teks yang tidak mempunyai nilai jangka panjang untuk tugas tersebut.

Andaikan ujian langkah ke-10 menghasilkan log Token 8K. Semasa ia pertama kali dimasukkan ke dalam konteks, ia hanyalah 8K Token. Namun, Agen masih perlu menyemak kod sumber, mengubah, dan menguji semula; selagi log ini masih berada dalam sejarah yang sah, ia akan meningkatkan berat asas untuk banyak permintaan seterusnya.

Ia sangat serupa dengan write amplification dalam sistem penyimpanan: satu penulisan logik menyebabkan lebih banyak pemprosesan bawah tanah seterusnya. Dalam kes Agent, satu output alat ditulis ke dalam sejarah pelaksanaan, kemudian bergerak bersama inferens seterusnya.

Oleh itu, sama-sama Token 8K, tetapi diletakkan pada putaran sebelum tamat tugas dan pada permulaan tugas membawa kesan keseluruhan yang berbeza. Claude Code kini juga secara aktif mengurangkan pencemaran ini. Cadangan rasmi ialah menggunakan sub-agent untuk mengasingkan tugas dengan output tinggi, dan secara jelas menyatakan bahawa keputusan carian, log, dan kandungan fail yang banyak akan menghabiskan konteks sesi utama; definisi alat itu sendiri juga akan mengambil ruang, oleh itu, set alat yang terlalu besar juga akan menambah beban status.

Namun, muncul masalah sebaliknya di sini: tidak boleh memotong semua log hanya kerana log mahal. Dalam satu log 3000 baris, mungkin hanya 20 baris yang berkaitan dengan punca utama. Sistem tidak tahu terlebih dahulu baris mana yang 20 itu. Jika pembersihan dilakukan terlalu awal, Agent mungkin tiba-tiba memerlukan salah satu butiran tersebut dan hanya boleh menjalankan semula ujian atau membuka semula fail.

Ini boleh disebut semantic page fault, kegagalan halaman semantik. Dalam memori maya tradisional, apabila program mengakses halaman yang sudah tidak berada dalam memori, sistem akan memuat semula dari cakera; selepas Coding Agent membuang bukti awal tertentu, fenomena serupa berlaku, hanya ia ditunjukkan melalui pencarian semula repositori, pembacaan semula fail, pelaksanaan semula arahan, atau bahkan penurunan semula masalah yang sudah dianalisis sebelumnya.

Oleh itu, tugas panjang terperangkap dalam dilema: meninggalkan terlalu banyak sejarah membuat setiap langkah seterusnya semakin berat; membasmi terlalu agresif menyebabkan agen terus-menerus mengambil semula maklumat yang pernah dilihat sebelumnya.

Ini juga menjelaskan mengapa pengurusan konteks tidak boleh disederhanakan menjadi “kurangkan jumlah Token yang dimasukkan”. Yang perlu diselesaikan sebenarnya ialah pemilihan set kerja: maklumat apa yang perlu kekal dalam ruang kerja pada saat ini, dan mana yang hanyalah produk sampingan yang telah menyelesaikan misinya.

Di sini, compaction, memory, dan sub-agent baru benar-benar mempunyai alasan untuk wujud.

Claude Code akan secara automatik mampat sesi apabila mendekati sempadan konteks, serta membersihkan sebahagian keputusan alat yang lebih lama. Pihak rasmi juga mengingatkan bahawa perbualan yang tidak berkaitan, kandungan fail, dan keputusan arahan dalam sesi panjang mungkin memenuhi tetingkap dan mengganggu prestasi model.

Dari sudut pandang sistem, compaction sangat mirip dengan pembersihan sampah semantik. Masalahnya ialah, pembersihan sampah biasa menilai “adakah objek ini masih dirujuk”, manakala Agent mesti menilai “adakah maklumat ini masih bermakna di masa depan”.

Yang kedua jauh lebih sukar. Sebagai contoh, pada peringkat awal terdapat kesimpulan reka bentuk berikut: modul tertentu tidak boleh menyimpan sendiri status pengguna, kerana sistem memerlukan status hanya mempunyai satu pemilik, dan semua pengubahsuaian mesti melalui perkhidmatan.

Selepas beberapa langkah, jika maklumat ini diringkaskan menjadi: "Masalah status telah diselesaikan melalui penyesuaian service." Fakta tidak salah, tetapi maklumat telah berubah. Kandungan asal mengandungi constraint, manakala ringkasan seterusnya hanya menyimpan event.

Apabila Agent berhadapan dengan masalah prestasi berikutnya dan melihat panggilan perkhidmatan perlahan, ia kemungkinan besar akan menambahkan cache ke dalam modul tersebut. Ia tidak melanggar maklumat yang dimilikinya semasa ini; hubungan sebab-akibat yang melarang cache tidak lagi berkuasa.

Dokumen konteks Claude Code secara jelas menyatakan bahawa sebahagian peraturan yang berskup path dan CLAUDE.md bersarang akan diringkaskan semasa sesi, dan perlu membaca semula fail yang sepadan untuk memuat semula.

Memory cuba menyelesaikan masalah penyimpanan pengetahuan jangka panjang. Fail CLAUDE.md dan auto memory di direktori akar projek boleh mengekstrak kandungan seperti arahan pembinaan, spesifikasi projek, dan pengalaman penyesuaian daripada perbualan jangka pendek dan memuat semula semasa permulaan sesi. Namun, Anthropic juga menulis dengan jelas tentang kedudukannya: memory ini masih merupakan konteks, bukan konfigurasi wajib.

Perbezaan ini sangat penting. Jika "di sini tidak boleh mengakses database secara langsung" hanya ditulis dalam memori, ia masih tetap merupakan ayat bahasa semula jadi yang perlu difahami dan dipatuhi oleh model. Jika peraturan yang sama ditulis sebagai lint dependensi, batasan jenis, atau pemeriksaan CI, barulah ia menjadi invariant perisian yang tidak boleh dilanggar dengan mudah.

Sub-agent menyelesaikan aspek lain: pengasingan set kerja. Membiarkan Agent berasingan memindai repositori atau menganalisis log panjang, kemudian mengembalikan hasil yang telah dikompresi kepada Agent utama, dapat mengelakkan kebisingan asal memasuki thread utama. Salah satu penggunaan sub-agent yang diberikan secara rasmi oleh Claude Code ialah pengasingan konteks.

Harganya juga menarik: Agent utama mendapat keadaan yang lebih bersih, tetapi kehilangan sebahagian bukti asal; apabila beberapa Agent berjalan serentak, mereka akan membina konteks masing-masing. Oleh itu, apabila dilihat bersama-sama, compaction, memory, dan sub-agent sebenarnya sudah sangat menyerupai peringkat memori di era Agent:

Konteks semasa adalah memori kerja yang mahal, compaction bertanggungjawab untuk mampat, memori menyimpan status merentas sesi, dan sub-agent menggunakan ruang alamat berasingan untuk mengasingkan gangguan. Masalah juga berubah dari “adakah konteks cukup besar” kepada peringkat lain:

Status mana yang perlu disimpan dengan kejituan tinggi, dan status mana yang hanya perlu meninggalkan ringkasan. Masalah ini akan直接影响 kualiti kod seterusnya.

Setelah memahami struktur pelaksanaan sebelum ini, apabila melihat kuota mingguan Claude Code, akan nampak bahawa platform sukar untuk terus mengukur Agent berdasarkan “bilangan mesej”, kerana satu mesej telah kehilangan makna yang stabil.

Mengganti nama pemboleh ubah adalah satu mesej, merekabentuk semula keseluruhan modul pengesahan juga adalah satu mesej. Yang pertama mungkin selesai dalam beberapa langkah, manakala yang kedua mungkin menjalankan puluhan pusingan, membaca puluhan fail, dan memulakan beberapa Agen. Satu permintaan yang sama boleh memerlukan keperluan sumber yang sama sekali berbeza tingkatannya.

Claude Code menggabungkan pembatasan gulir dan kuota mingguan; Codex kini secara jelas menghitung kredit berdasarkan token input, token input yang disimpan, dan token output; pakej Cursor memberikan kolam penggunaan yang berbeza kepada Agen, dan penggunaan model pihak ketiga akan dipengaruhi oleh harga API model.

Tiga produk tersebut mempunyai bahasa antaramuka yang berbeza, tetapi masalah asas yang perlu diselesaikan sangat serupa: bagaimana untuk mengalokasikan sumber penalaran kepada program pintar yang laluan pelaksanaannya tidak dapat ditentukan sebelumnya. Sulit untuk menentukan berapa lama satu Agen Pengekodan akan berjalan pada permulaan tugas.

Model mungkin akan segera menemukan punca utama, atau mungkin mengemukakan beberapa andaian yang salah secara berturut-turut; mungkin lulus dalam satu ujian sahaja, atau mungkin masuk ke dalam gelung debug yang panjang; mungkin hanya memerlukan satu Agent, atau mungkin dipisahkan menjadi beberapa sub-agent.

API tradisional suka mengenakan caj berdasarkan permintaan, kerana fluktuasi sumber bagi satu permintaan masih boleh dikawal dalam lingkungan tertentu. Agen menghancurkan kestabilan ini. Oleh itu, Token di sini mulai mempunyai sedikit nuansa masa CPU.

Perbandingan ini tidak boleh dianggap sama. Model yang berbeza mempunyai kos pengiraan yang berbeza untuk menangani jumlah Token yang sama, dan input, input yang disimpan, serta output juga mempunyai kos yang berbeza. Tetapi dari sudut pembangun, fungsinya semakin serupa: semuanya menggambarkan berapa banyak sumber pengiraan yang digunakan untuk melanjutkan tugas tersebut.

Anthropic semasa meningkatkan had penggunaan Claude Code tahun ini juga secara langsung menghubungkan peningkatan kuota dengan penambahan kapasiti pengiraan. Ini akan membawa kepada perubahan indikator yang menarik. Sebelum ini, apabila memerhatikan Coding Agent, mudah untuk membandingkan “siapa yang menulis soalan yang sama dengan baik dalam sekali cuba”. Ke depannya, mungkin lebih bermakna untuk menilai: siapa yang menggunakan pengiraan berkesan lebih sedikit untuk mencapai perubahan status kejuruteraan yang sama.

Jika seorang Agent menghabiskan banyak Token hanya untuk membuka semula fail, menjalankan semula ujian, dan memulihkan semula konteks yang telah hilang, Token tersebut tidak menukar kepada kemajuan kejuruteraan yang sepadan.

Dan keadaan pemulihan yang tidak cekap ini tepat berjumpa dengan hutang teknikal di peringkat seterusnya.

Di sini, perisian yang diuruskan oleh satu Coding Agent boleh diabstrakkan sebagai dua set status yang berkembang serentak. Satu set ialah status kod R_t. Fail, jenis, antaramuka, ujian, dan Git commit semuanya termasuk dalam lapisan ini. Satu baris retry yang ditambahkan pada langkah ke-20 oleh Agent, selama tidak dihapus, masih akan wujud sepenuhnya apabila fail dibuka pada langkah ke-100. Presisi penyimpanan perubahan sejarah dalam kod sangat tinggi.

Set lain adalah keadaan reka bentuk M_t. Mengapa di sini diperlukan retry, mengapa cache itu hanya boleh diletakkan di service, mengapa keadaan ini tidak boleh mempunyai dua pemilik, mengapa penilaian yang kelihatan berlebihan ini tidak boleh dihapus sementara, maklumat-maklumat ini termasuk dalam sebab-akibat reka bentuk.

M_tTidak ada penyimpanan tanpa kehilangan secara semula jadi seperti Git. Ia tersebar di dalam perbualan, penaakulan, balasan alat, memori, fail peraturan, dan ringkasan pemadatan. Selepas tugas berterusan maju, sebahagian kandungan dibersihkan, sebahagian diringkaskan, dan sebahagian perlu diperoleh semula.

Oleh itu, akan timbul ketidaksimetrian yang sangat penting: hasil yang dicapai boleh dikumpulkan dengan kejituan tinggi, tetapi hubungan sebab-akibat yang menghasilkan hasil tersebut akan terus dikurangkan sampelnya. Ini jauh lebih serius daripada sekadar mengatakan “Agen akan lupa sesuatu”.

Dalam kes konkrit satu masalah percanggahan, selepas analisis oleh Agent, ia dimasukkan ke dalam satu antrian. Pada masa itu, kesimpulan penuh yang dimilikinya ialah: hanya laluan penulisan A yang mengalami persaingan, oleh itu antrian hanya boleh meliputi A; laluan penulisan B memerlukan latensi rendah dan tidak boleh dimasukkan ke dalam antrian ini.

Kod telah menyimpan queue secara lengkap. Selepas dijalankan dalam jangka masa yang panjang, keadaan reka bentuk mungkin hanya tinggal “di sini gunakan queue untuk menyelesaikan race condition”.

Kemudian, B juga mengalami ralat yang berlaku secara rawak. Semasa agen membaca semula kod tersebut, ia secara semula jadi menghubungkan B ke dalam queue yang sedia ada.

Selepas itu, lewat meningkat, jadi tambah bypass. Bypass menyebabkan ketidakkonsistenan keadaan secara berkala, jadi tambah retry di luar. Di sini, tiada satu pun perubahan yang pasti keliru. Setiap pampas pada masa itu, dalam keadaan tempatan yang dilihat, bahkan mungkin sangat munasabah. Namun, kod telah berubah dari “satu model paralel yang jelas” menjadi queue, bypass, dan retry yang saling mengimbangi.

Tumpukan kod AI kemungkinan besar tumbuh dengan cara ini. Ia tidak semestinya menunjukkan diri sebagai model yang tiba-tiba menghasilkan sampah, tetapi lebih mungkin menunjukkan diri sebagai akumulasi kebenaran tempatan yang berterusan, sehingga model keseluruhan perlahan-lahan hilang.

Dalam perisian tradisional, masalah semacam ini biasanya terbentuk perlahan-lahan melalui peralihan tenaga kerja. Pencipta asal meninggalkan projek, dan pembangun baru yang melihat kod lama tidak tahu mengapa ia wujud, jadi mereka menambahkan lapisan logik kompatibiliti di luarannya.

Agen pengkodean mengubah "peralihan staf" menjadi "peralihan konteks". Langkah ke-20 dan langkah ke-100 kelihatan seperti sesi Claude Code yang sama, tetapi status rekaan yang mereka peroleh sebenarnya tidak lagi sepenuhnya sama. Dari sudut pandang maklumat, ia lebih menyerupai dua jurutera yang memelihara repositori yang sama melalui dokumen peralihan yang semakin mengecil.

Ujian hanya dapat menyelesaikan sebahagian daripadanya. Ujian cekap dalam melindungi tingkah laku: antaramuka sepatutnya mengembalikan apa, input tertentu tidak boleh gagal, dan ralat sebelumnya tidak boleh muncul semula. Banyak sekali batasan架构 tidak secara semula jadi ditunjukkan sebagai input dan output.

Status hanya boleh memiliki satu pemilik, lapisan domain tidak boleh bergantung secara terbalik pada UI, sesuatu package tidak dibenarkan menyambung langsung ke pangkalan data, operasi penulisan mesti melalui sempadan transaksi yang seragam; sekiranya pembatasan ini hanya terdapat dalam dokumen atau ingatan Agen, ia mudah dilanggar semasa pembaikan tempatan.

Hasilnya ialah keadaan kejuruteraan yang sangat rumit: ujian masih hijau, tetapi kod semakin sukar untuk dijelaskan. Lebih berbahaya lagi, terdapat gelung umpan balik di sini.

Arsitektur mula menjadi kacau, agen seterusnya perlu membaca lebih banyak fail untuk memahami fungsi; semakin rumit hubungan bergantung, semakin besar set kerja; semakin berat set kerja, semakin banyak sistem perlu dibersihkan dan dikompres; semakin nipis rekod sebab-akibat reka bentuk, semakin mudah pengubahsuaian seterusnya bergantung pada kod semasa dan ujian tempatan.

Oleh itu, kerumitan kod meningkatkan kos Token, dan tekanan Token pula secara berbalik mendorong pengekalan status yang lebih pendek dan pembaikan yang lebih tempatan. Ini adalah mekanisme yang perlu diwaspadai di sebalik “semakin banyak iterasi, semakin banyak masalah” dalam Agent coding.

Ia bukan masalah kemampuan model tunggal, tetapi masalah sistem yang melibatkan ketidakkonsistenan presisi dalam penyimpanan keadaan kod dan keadaan reka bentuk.

Agen pengkodan semakin mampu bertindak dalam jangka masa yang panjang, tetapi "mampu berjalan selama beberapa jam" sendiri belum tentu menjadi indikator kemampuan yang baik.

Jika seorang Agent perlu membaca semula fail yang telah diubahnya 2 jam sebelumnya, menarik semula semula sebab keabstrakan tertentu wujud, dan menjalankan semula ujian yang telah dilakukan sebelumnya selepas bekerja selama 3 jam, maka sebahagian besar pengiraan dalam 3 jam itu sebenarnya digunakan untuk pemulihan status.

Masalah seterusnya akan menjadi: Sebuah Agen masih mampu mengekalkan berapa banyak maklumat sebab-akibat yang berharga untuk keputusan seterusnya selepas 50 langkah, 100 langkah.

It can be called state fidelity.

Kerana ia mengukur bukan berapa banyak Token yang boleh dimasukkan ke dalam konteks, tetapi berapa banyak maklumat reka bentuk utama yang masih wujud dalam bentuk yang boleh digunakan selepas panggilan alat, pemampatan, lintas sesi, dan pencarian ingatan. Ini juga bermaksud, ingatan jangka panjang Agen tidak boleh bergantung semata-mata pada konteks yang lebih panjang.

Beberapa pengetahuan sesuai disimpan dalam memori, seperti cara membina projek dan kebiasaan pembangunan; beberapa keputusan sepatutnya dimasukkan ke dalam ADR yang terstruktur atau indeks kod; manakala yang melanggar sempadan arsitektur sistem sekiranya dilanggar lebih sesuai ditulis secara langsung ke dalam jenis, ujian, lint, peraturan bergantung, dan CI.

Sekiranya satu peraturan telah menjadi kekangan yang boleh dilaksanakan oleh perisian, Agent tidak perlu “mengingat”nya. Dalam putaran seterusnya, Agent boleh lupa satu perbualan, tetapi tidak boleh melanggar kompiler dan ujian dengan mudah.

Jika kadar keaslian rendah, semakin lama Agent berjalan, semakin banyak ranjau yang ditanam ke dalam sistem.

Ini mungkin juga merupakan garis yang perlu dilalui oleh Coding Agent untuk berpindah dari “bisa menulis kod” ke “mampu mengekalkan perisian dalam jangka panjang”: memindahkan pengetahuan reka bentuk dari ingatan bahasa yang bersifat kebarangkalian kepada keadaan perisian yang boleh dicari, disahkan, dan dieksekusi.

Jika berjalan secara autonomi semakin lama, akan muncul situasi yang sangat absurd. Agent semakin cepat menulis kod, dan projek berubah dengan pantas, tetapi setiap beberapa masa, ia perlu memahami semula dunia yang ditinggalkan pada masa sebelumnya.

Satu perkataan biasa dalam kod warisan tradisional ialah: "Jangan sentuh bahagian ini, tak tahu kenapa ia akan meletup."

Kod warisan AI mungkin lebih aneh lagi: kod memang ditulis oleh Agent, tetapi Agent seterusnya sudah tidak tahu mengapa Agent sebelumnya menulisnya begitu.