Loop berjalan lancar empat puluh kali saat pengujian. Pada percobaan ke empat puluh satu, di produksi, loop memanggil tool SQL yang sama dengan query rusak yang sama berulang kali hingga menghabiskan anggaran API harian, dan hanya peringatan tagihan yang akhirnya membangunkan seseorang. Tidak ada yang menulis model yang buruk. Tidak ada yang mengubah prompt. Agent itu hanya tidak pernah memutuskan bahwa ia sudah selesai.
Inilah pola yang terus saya lihat pada tim yang memindahkan agent dari prototipe ke beban kerja 24/7. Loop AI agent sering gagal di produksi bukan karena modelnya tiba-tiba memburuk, melainkan karena lapisan eksekusi tidak memiliki disiplin terminasi, kontrak tool yang tervalidasi, konteks yang terbatas, dan state yang tahan lama. Loop agent adalah sistem stokastik yang membuat satu keputusan sekuensial demi satu. Tanpa beberapa guardrail tertentu, kegagalan yang jarang terjadi akan menjadi kegagalan yang pasti terjadi setelah Anda menjalankannya cukup lama. Platform agent terkelola (Vertex AI Agent Builder, Bedrock Agents, Azure AI Foundry) sudah menanamkan beberapa guardrail ini; panduan ini ditujukan bagi mereka yang memilih untuk self-host dan mengelola loop sendiri.
Taruhannya cukup nyata sehingga Gartner memperkirakan lebih dari 40% proyek agentic AI akan dibatalkan pada akhir 2027, dengan alasan biaya yang terus meningkat dan nilai yang tidak jelas. Berikut adalah enam cara spesifik loop gagal di produksi, mekanisme di balik masing-masing, dan pola harness yang memperbaikinya, lengkap dengan detail LangGraph dan n8n, serta apa yang dibutuhkan untuk benar-benar menjalankan ini 24/7.
Versi Singkat
- Infinite loop: Agent tidak pernah memutuskan bahwa ia sudah selesai. Gabungkan batas langkah keras (LangGraph's
recursion_limit, default 25) dengan deteksi no-progress yang menghentikan pemanggilan tool+argumen yang berulang. - Context overflow: Loop mengisi jendela konteksnya sendiri dengan riwayat yang terakumulasi hingga panggilan terpotong atau gagal. Ringkas riwayat pada interval tetap agar konteks kerja tetap terbatas.
- Silent tool failure: Sebuah tool mengembalikan string kosong, model membacanya sebagai no-op yang valid, dan agent "berhasil" tanpa melakukan apa pun. Validasi setiap hasil tool sebelum model melihatnya.
- Reasoning degradation: Kualitas menurun seiring bertambahnya konteks, bahkan di bawah batas keras. Kompres di tengah loop, tetapi lindungi instruksi keamanan yang dipinned saat melakukannya.
- State loss on restart: Crash berarti memulai dari awal. Checkpoint ke Postgres (LangGraph
PostgresSaver), bukan SQLite, untuk produksi. - Retry storm: Sepuluh agent yang masing-masing mencoba ulang sepuluh kali akan menghantam layanan yang mati dengan seratus permintaan. Tambahkan exponential backoff dengan jitter dan circuit breaker global.
Apa yang Tidak Dicakup Panduan Ini
Ini adalah panduan harness, berfokus pada rekayasa di sekeliling loop, bukan model di dalamnya. Beberapa topik terkait sengaja tidak dicakup:
- Kegagalan koordinasi multi-agent (pembacaan basi, state yang terbengkalai antar agent): masalah berbeda yang layak mendapat tulisan tersendiri.
- Keamanan agent (prompt injection, tool poisoning): kategori kegagalan terpisah dengan model ancamannya sendiri.
- Pemilihan model dan fine-tuning. Panduan ini mengasumsikan Anda sudah memilih model dan sedang men-debug sistem di sekelilingnya.
- Layanan agent terkelola, yang disebutkan di atas; pola di sini untuk jalur self-hosted.
Infinite Loop: Saat Agent Tidak Pernah Memutuskan Bahwa Ia Sudah Selesai
Sebuah agent akan terus looping selamanya jika tidak memiliki batas langkah keras maupun cara untuk mendeteksi bahwa ia telah berhenti membuat kemajuan. Solusinya terdiri dari dua bagian: pertahankan batas keras sebagai cost backstop, dan tambahkan deteksi no-progress yang meng-hash setiap pemanggilan tool-plus-argumen dan menghentikan eksekusi ketika melihat panggilan yang sama berulang. Di LangGraph, batas tersebut adalah recursion_limit, default 25 langkah; lewati batas itu dan graph akan menghasilkan GraphRecursionError.
Dokumentasi LangGraph menjelaskan batas tersebut sebagai mencapai "jumlah langkah maksimum sebelum mencapai kondisi berhenti," dan di sinilah jebakan yang perlu dipahami: recursion limit bukan perlindungan loop. Ini adalah cost backstop yang baru aktif setelah loop sudah membuang dua puluh lima langkah dan pengeluaran API yang menyertainya. Logika terminasi bawaan agent sendiri seharusnya menghentikannya jauh sebelum itu, dan logika tersebut bisa gagal secara independen. Satu kasus LangGraph yang dilaporkan menunjukkan agent text-to-SQL yang terus looping hingga mencapai recursion limit meski ada kondisi berhenti yang jelas dalam prompt. Agent terus memanggil tool query yang sama dengan SQL yang gagal, dan isu ditutup sebagai "not planned." Saya membaca itu sebagai sinyal yang jelas: jangan anggap batas sebagai kondisi berhenti Anda. Itu adalah sabuk pengaman Anda, bukan rem Anda.
Menaikkan batas sangatlah mudah; Anda meneruskannya melalui config saat memanggil graph:
# The hard ceiling -- a backstop, not loop protection
graph.invoke(
{"messages": [("user", "Generate the quarterly report")]},
{"recursion_limit": 50},
)Bagian yang benar-benar menghentikan loop yang macet adalah deteksi kemajuan. Mekanismenya sederhana: hash nama tool beserta argumennya di setiap langkah, simpan jendela pendek dari hash terbaru, dan hentikan eksekusi saat melihat pengulangan.
import hashlib
def step_signature(tool_name: str, tool_args: dict) -> str:
payload = f"{tool_name}:{sorted(tool_args.items())}"
return hashlib.sha256(payload.encode()).hexdigest()
# Inside your loop: terminate if the same tool+args repeats within the window
seen = recent_signatures[-WINDOW:]
sig = step_signature(tool_name, tool_args)
if sig in seen:
raise StopReason("no_progress: repeated tool call detected")
recent_signatures.append(sig)Ini menangkap agent yang secara teknis "berjalan" (memanggil tool, menghasilkan token) tetapi berputar pada tindakan yang sama yang gagal. Mode kegagalan yang disebutkan di sini memetakan ke apa yang disebut taksonomi MAST (IBM Research dan UC Berkeley) sebagai Unaware of Termination Conditions (FM-1.5), salah satu mode kegagalan yang analisis mereka kaitkan dengan kegagalan tugas secara langsung.
Batas langkah menghentikan biaya yang membengkak. Deteksi no-progress menghentikan loop yang secara teknis "maju" tetapi berulang. Produksi membutuhkan keduanya.
Context Window Overflow: Saat Loop Mengisi Konteksnya Sendiri dengan Sampah
Loop yang berjalan lama mengakumulasi setiap output tool, setiap pikiran perantara, dan setiap pesan yang dihasilkannya, lalu memasukkan semuanya kembali ke jendela konteks di setiap giliran. Akhirnya jendela penuh, dan panggilan baik terpotong diam-diam maupun gagal total. Solusinya adalah summarisasi konteks pada interval tetap: setiap N langkah, kompres riwayat yang terakumulasi menjadi ringkasan berjalan agar konteks kerja tetap terbatas.
Bayangkan sebuah research agent yang telah berjalan selama satu jam. Pada langkah ke-60, ia membawa teks lengkap setiap halaman yang telah diambilnya, setiap hasil pencarian, setiap jejak penalaran. Semua riwayat mentah itu tidak membantu pada langkah ke-61, namun semuanya tetap menghitung terhadap jendela, dan model membuang-buang anggaran atensi pada token yang tidak lagi diperlukan. Saat jendela penuh, penyedia layanan memotong dari salah satu ujung, dan agent diam-diam kehilangan instruksi yang diberikan di awal.
Pemicunya adalah keputusan tuning, dan ada titik referensi yang berguna untuk itu. Tulisan Mem0 tentang sistem produksi nyata mencatat bahwa kompresor agent Hermes "aktif pada 50% dari jendela konteks model secara default", dengan jaring pengaman sekunder pada 85% untuk sesi yang membengkak di antara giliran. Lima puluh persen adalah titik awal yang masuk akal: kompres cukup awal sehingga satu output tool yang besar tidak dapat melewati batas sebelum kompresi terjadwal berikutnya.
Catatan: Overflow dan penurunan kemampuan penalaran adalah dua masalah yang berbeda, dan bagian berikutnya membahas yang kedua. Overflow adalah batas keras: Anda kehabisan tokens. Penurunan bersifat bertahap: model menjadi semakin buruk. sebelum Anda mencapai batas. Anda perlu menangani keduanya, dan ambang pemicu di atas melindungi terhadap batas keras.
Konteks yang terbatas adalah tanggung jawab harness, bukan fitur model. Lakukan summarisasi pada interval sebelum jendela memaksa pemotongan diam-diam.
Kegagalan Pemanggilan Tool yang Diam: Saat Agent "Berhasil" Tanpa Melakukan Apa Pun
Pemanggilan tool mengembalikan string kosong atau pesan "no results found" yang lunak, model menginterpretasikannya sebagai hasil yang valid, dan agent terus berjalan seolah langkah tersebut berhasil, tampak sukses padahal tidak melakukan apa pun. Solusinya adalah validation gate pada setiap kembalian tool: lakukan schema-check atau sanity-check pada output sebelum model melihatnya, dan tampilkan kegagalan nyata yang harus ditangani loop daripada kesuksesan kosong.
Yang satu ini berbahaya karena tidak ada yang crash. Seorang developer yang menulis tentang mode kegagalan diam dalam production agent mengatakannya langsung: model menginterpretasikan string kosong generik sebagai no-op yang valid dan terus mengeksekusi tanpa menyadari kegagalan. Query database yang mengembalikan nol baris karena koneksi terputus terlihat identik, bagi model, dengan query yang secara sah tidak menemukan apa pun. Jadi agent melaporkan "tidak ada rekaman yang cocok" dan melanjutkan, dan Anda baru mengetahuinya seminggu kemudian bahwa sepertiga dari jalannya diam-diam rusak.
Validation gate berada di antara tool dan model:
def gate_tool_result(tool_name: str, result):
# Reject empties and soft errors before the model can rationalize them
if result is None or (isinstance(result, str) and not result.strip()):
raise ToolFailure(f"{tool_name} returned empty -- treat as failure, not no-op")
if isinstance(result, str) and result.lower().startswith(("error", "exception")):
raise ToolFailure(f"{tool_name} returned a soft error: {result[:120]}")
return result # validated -- safe to hand back to the modelIntinya bukan pada pemeriksaan yang tepat; pemeriksaan Anda akan bergantung pada apa yang secara sah dikembalikan setiap tool. Intinya adalah bahwa nilai kembalian yang tidak divalidasi adalah keputusan yang Anda serahkan kepada model stokastik, dan langkah default model adalah terus melanjutkan.
Kembalian tool yang tidak divalidasi adalah kegagalan diam yang menunggu terjadi. Validasi output, jangan percaya begitu saja pada panggilan.
Reasoning Degradation pada Konteks Panjang: Saat Agent Semakin Buruk Seiring Waktu Berjalan
Bahkan saat Anda berada di bawah batas konteks keras, kualitas penalaran menurun seiring bertambahnya konteks. Ini adalah efek "lost in the middle", di mana model secara konsisten memperhatikan awal dan akhir konteks panjang tetapi kehilangan bagian tengah. Solusinya adalah kompresi di tengah loop yang mempertahankan constraint yang dipinned: kompres kebisingan, lindungi instruksi yang kritis.
Mekanisme ini memiliki nama. Blog rekayasa Anthropic menyebutnya sebagai context rot: "seiring bertambahnya jumlah token dalam jendela konteks, kemampuan model untuk secara akurat mengingat informasi dari konteks tersebut menurun." Karena "setiap token memperhatikan setiap token lainnya," Anda mendapatkan hubungan berpasangan n² untuk n token, dan atensi model semakin menipis seiring bertambahnya panjang konteks.
Kualifikator itu, lindungi instruksi yang kritis, adalah kunci dari semuanya, dan ada insiden yang terdokumentasi yang menunjukkan alasannya. Dalam kasus yang dilaporkan, sebuah agent OpenClaw secara massal menghapus kotak masuk pengguna selama kompresi konteks, karena instruksi keamanan yang diberikan ("jangan mengambil tindakan sampai saya bilang") dihapus dari konteks aktif saat riwayat dikompres. Constraint yang seharusnya menjadi hal terakhir yang dihapus diperlakukan sebagai riwayat biasa dan diringkas.
Jadi "ringkas semua yang lebih lama dari N giliran" secara naif adalah berbahaya. Kompresi harus tahu apa yang tidak boleh pernah dihapus:
PINNED = {"system_constraints", "safety_instructions", "active_task_spec"}
def compress_history(messages):
pinned = [m for m in messages if m.tag in PINNED] # never summarized
transient = [m for m in messages if m.tag not in PINNED]
summary = summarize(transient) # lossy is fine here
return pinned + [summary] # constraints survive intactIni berbeda dari masalah overflow di bagian sebelumnya. Overflow adalah kehabisan ruang; degradation adalah model yang memburuk sementara masih ada ruang tersisa. Anda bisa berada di 60% dari jendela Anda dan sudah bernalar dengan buruk.
Catatan: Kompresi yang menghapus safety constraint adalah kelas bug yang berbeda dari kompresi yang kehilangan hasil pencarian yang sudah basi. Tandai constraint, spesifikasi tugas, dan instruksi "jangan lakukan X" apa pun sebagai dipinned, dan kecualikan dari summarizer sepenuhnya.
Kompresi yang menghapus instruksi keamanan lebih buruk dari tidak ada kompresi sama sekali. Lindungi constraint yang dipinned saat Anda melakukan kompresi.
State Loss on Restart: Saat Crash Berarti Mulai dari Awal
Saat agent yang berjalan lama crash, entah karena reboot, OOM kill, atau koneksi jaringan yang terputus, secara default tidak ada resume-from-checkpoint. Loop dimulai dari awal: ia mengulang pekerjaan yang sudah selesai dan, yang lebih buruk, dapat mengeksekusi ulang tindakan yang sudah dilakukan, seperti mengirim email yang sama dua kali atau menjalankan ulang panggilan API berbayar. Solusinya adalah checkpointing: simpan state loop setelah setiap langkah agar restart memuat ulang dari posisi terakhir berhenti alih-alih dari nol.
Di LangGraph, pilihan backend checkpoint adalah pilihan antara pengembangan dan produksi. Dokumentasi persistence LangGraph mendeskripsikan SqliteSaver sebagai "ideal untuk eksperimen dan workflow lokal" dan PostgresSaver sebagai "ideal untuk digunakan di produksi," dan yang terakhir adalah yang dijalankan LangSmith sendiri. Keduanya secara sengaja sejajar dalam kode, yang membuat kontrasnya mudah dilihat:
# Development -- single file, no server, do not ship this
from langgraph.checkpoint.sqlite import SqliteSaver
# Production -- survives the box it runs on
from langgraph.checkpoint.postgres import PostgresSaverDua detail yang sering menjebak orang. Pertama, paket checkpoint dipasang secara terpisah dari inti LangGraph (langgraph-checkpoint-sqlite dan langgraph-checkpoint-postgres adalah dependensi tersendiri), jadi box baru tidak akan memiliki Postgres saver sampai Anda menambahkannya. Kedua, setiap operasi checkpoint membutuhkan thread_id dalam config. ID itulah yang menghubungkan suatu run dengan state yang tersimpan, dan restart tanpa thread_id yang tepat tidak akan memuat apa pun.
Tips Pro: Paket checkpoint LangGraph dipasang secara terpisah.
langgraph-checkpoint-postgrestidak disertakan oleh paketlanggraphdasar, jadi pin-kan di file requirements produksi Anda sebelum Anda menemukan cara keras saat insiden.
n8n memiliki pembagian yang sama antara dev dan produksi, hanya dengan nama yang berbeda. Opsi memori bawaan juga disebut Simple Memory (atau Buffer Window Memory), dan jalur produksi adalah node Postgres Chat Memory untuk state yang harus bertahan setelah restart. Memori bawaan menyimpan percakapan dalam proses yang berjalan, yang cocok untuk pengujian tetapi berisiko untuk beban kerja 24/7. Praktisi yang menjalankan n8n agent secara langsung melaporkan harus bermigrasi ke penyimpanan berbasis Postgres setelah memori dalam proses membengkak hingga menumbangkan instance. Jika Anda menggunakan n8n dan agent Anda perlu mengingat sesuatu setelah restart, hubungkan ke Postgres Chat Memory sejak awal.
SQLite checkpointing adalah kenyamanan pengembangan. Bertahan dari restart produksi berarti Postgres (LangGraph) atau penyimpanan berbasis Postgres (n8n).
Retry Storm: Saat Agent Anda Sendiri DDoS-ing Layanan yang Mati
Ketika layanan downstream mati, retry naif per eksekusi mengubah fleet agent Anda menjadi denial-of-service yang Anda timbulkan sendiri. Solusinya memiliki dua bagian: exponential backoff dengan jitter pada setiap agent untuk menyebarkan retry dalam waktu, dan circuit breaker global yang aktif setelah ambang kegagalan bersama dan menghentikan seluruh kawanan dari menghantam layanan yang jelas sudah mati.
Matematikanya tidak kenal ampun. Seperti yang diframing sebuah tulisan tentang retry patterns , dengan sepuluh agent paralel yang masing-masing mencoba ulang sepuluh kali, Anda mengirim seratus permintaan ke layanan yang sudah di lantai, karena backoff setiap agent bersifat per eksekusi, bukan global. Backoff per-agent saja tidak memecahkan masalah ini. Sepuluh agent yang masing-masing mundur dengan sopan tetap mundur bersamaan jika semua dimulai pada waktu yang sama, sehingga mereka mencoba ulang dalam gelombang yang tersinkronisasi. Jitter memutus sinkronisasi dengan mengacak waktu tunggu setiap agent; circuit breaker memutus kawanan dengan berbagi satu bagian state kegagalan di seluruh agent.
Setengah backoff adalah masalah yang sudah terpecahkan di Python; library tenacity menangani exponential-with-jitter dengan bersih:
from tenacity import retry, stop_after_attempt, wait_random_exponential
@retry(wait=wait_random_exponential(multiplier=1, max=60), stop=stop_after_attempt(5))
def call_flaky_service(payload):
return downstream.post(payload)Circuit breaker adalah bagian yang harus bersifat global: dibagikan di seluruh agent, bukan diinstansiasi ulang per eksekusi. Saat kegagalan melewati ambang batas, circuit breaker terbuka, setiap agent gagal cepat alih-alih memanggil keluar, dan setelah cooldown dibiarkan satu probe untuk menguji apakah layanan sudah pulih. Breaker yang hidup di dalam proses setiap agent tidak melindungi apa pun, karena tidak ada yang dibagikan; layanan yang mati masih mendapat seratus permintaan penuh.
Backoff per eksekusi tetap membiarkan sepuluh agent menghantam layanan mati secara bersamaan. Circuit breaker harus bersifat global untuk menghentikan kawanan.
Enam Kegagalan Secara Sekilas
Sebelum bagian infrastruktur, berikut adalah seluruh katalog dalam satu tempat: kegagalan, mekanisme yang menyebabkannya, solusi harness, dan di mana parameter yang relevan berada di setiap framework.
| Mode kegagalan | Mekanisme | Solusi harness | Parameter framework |
|---|---|---|---|
| Infinite loop | Tidak ada batas langkah atau pemeriksaan kemajuan | Batas keras + deteksi no-progress | LangGraph recursion_limit (25) / n8n Max Iterations |
| Context overflow | Riwayat bertumbuh hingga jendela penuh | Summarisasi berbasis interval | Tingkat aplikasi (kompres pada ~50% dari jendela) |
| Silent tool failure | Kembalian kosong/lunak dibaca sebagai no-op yang valid | Validation gate pada setiap hasil tool | Tool wrapper tingkat aplikasi |
| Reasoning degradation | Atensi menurun seiring bertambahnya konteks ("context rot") | Kompresi mid-loop yang melindungi constraint yang dipinned | Tingkat aplikasi, sadar constraint |
| State loss on restart | Tidak ada checkpoint; loop dimulai dari nol | Persistent checkpointing | LangGraph PostgresSaver / n8n Postgres Chat Memory |
| Retry storm | Retry per eksekusi mengalir pada layanan yang mati | Backoff + jitter + circuit breaker global | tenacity + shared breaker state |
Catatan untuk pembaca yang menggunakan CrewAI, AutoGen, Dify, atau loop Python buatan sendiri: parameter framework berubah, tetapi keenam pola tidak. Deduplikasi, summarisasi interval, validasi schema, kompresi sadar constraint, checkpointing, dan circuit breaker global adalah konsep yang tidak tergantung framework. Detail LangGraph dan n8n di sini adalah pegangan konkret, bukan batas di mana pola tersebut berlaku.
Menentukan Ukuran Deployment Agent Produksi
Setiap pola di atas mengasumsikan Anda mengendalikan process manager, database, dan perilaku restart. Checkpointing tidak berguna jika loop yang crash tidak pernah kembali aktif, dan circuit breaker global membutuhkan tempat untuk menyimpan state bersama. Kontrol itulah yang diberikan self-hosting kepada Anda dan yang tidak diberikan oleh managed black box, sehingga keputusan terakhir adalah menentukan ukuran box yang menjalankan ini 24/7.
Untuk sebagian besar deployment single-agent (satu agent, panggilan LLM keluar ke API eksternal, Postgres checkpointing dasar) sebuah instance kecil sudah cukup: sekitar 2 GB RAM, 1 vCPU, and 60 GB of NVMe storage. Komputasi berat ada di sisi penyedia model; box Anda bertugas mengorkestrasikan, menyimpan checkpoint, dan menyimpan state, bukan menjalankan inferensi. Naik ke sekitar 4 GB RAM, 2 vCPU, and 120 GB NVMe ketika agent bersifat stateful dan multi-langkah dengan Postgres checkpointing plus Redis untuk hydration sesi, atau saat Anda menjalankan workflow bersamaan yang berbagi host.
Alasan ini membutuhkan VPS yang dikelola sendiri daripada platform yang terbatas adalah alasan yang sama mengapa solusi-solusi tersebut bekerja sama sekali: mereka membutuhkan akses root. Postgres Anda sendiri untuk checkpointing, Redis Anda sendiri untuk state sesi, dan process manager nyata seperti systemd or pm2, sehingga ketika sebuah loop mati, supervisor me-restart-nya dan agent memuat ulang dari checkpoint terakhirnya alih-alih memulai pekerjaan dari awal. Seluruh cerita pemulihan itu bergantung pada kepemilikan siklus proses.
Karena kami menjalankan n8n sebagai aplikasi one-click di marketplace kami sendiri, bagian itu dari setup adalah jalur terpendek di sisi kami: Anda bisa deploy n8n di Cloudzy VPS dengan konfigurasi berbasis Postgres yang dibutuhkan jalur produksi, pada instance di mana Anda memiliki akses root untuk menambahkan Redis dan process supervision sendiri. Ini adalah jejak self-hosted yang sama seperti yang dijelaskan di atas, di mana Anda memiliki database dan perilaku restart, yang itulah yang membuat checkpointing dan auto-recovery benar-benar bekerja.
Pola harness hanya seandal box tempat mereka berjalan. Checkpointing tidak berguna jika proses tidak pernah restart.
Pertanyaan yang Sering Diajukan
Bagaimana Cara Menghentikan LangGraph Agent Saya dari Looping Selamanya?
Gunakan dua mekanisme secara bersamaan. Atur recursion_limit sebagai batas langkah keras (defaultnya adalah 25) sehingga loop yang lepas kendali tidak dapat membakar anggaran tanpa batas, dan tambahkan deteksi no-progress yang meng-hash setiap pemanggilan tool-plus-argumen dan menghentikan ketika panggilan yang sama berulang dalam jendela terbaru. Batas saja adalah cost backstop yang aktif setelah pemborosan terjadi, bukan perlindungan loop nyata. Deteksi kemajuan adalah yang benar-benar menghentikan loop yang macet.
Berapa recursion_limit yang Tepat untuk LangGraph di Produksi?
Tidak ada angka universal. Sesuaikan dengan jumlah langkah sah maksimum yang seharusnya dibutuhkan agent Anda, tambah margin, dan perlakukan itu semata-mata sebagai cost backstop. Menaikkan batas tidak membuat agent yang looping menjadi konvergen. Jika agent Anda mencapai batas yang tinggi, solusinya adalah deteksi kemajuan, bukan batas yang lebih tinggi.
Mengapa n8n AI Agent Saya Terus Mencapai Max Iterations?
Mencapai batas Max Iterations berarti agent tidak konvergen: ia mengambil lebih banyak langkah daripada yang diizinkan batas tanpa mencapai kondisi berhenti. Naikkan batas hanya jika tugas secara sah membutuhkan lebih banyak langkah; jika tidak, anggap itu sebagai sinyal bahwa agent sedang macet. Waspadai satu jebakan spesifik: GitHub issue #22771 melaporkan bahwa ketika batas iterasi tercapai dengan "On Error: Continue" diatur, eksekusi dapat diarahkan ke output Success alih-alih output Error, sehingga run yang mencapai batas dan gagal bisa terlihat seperti sukses dalam workflow Anda.
Bagaimana Cara Mempertahankan State Agent Setelah Restart?
Di LangGraph, gunakan checkpointing PostgresSaver alih-alih SqliteSaver, yang dimaksudkan untuk pengembangan lokal. Di n8n, gunakan node Postgres Chat Memory alih-alih memori bawaan dalam proses. Keduanya membutuhkan database yang persisten, dan di LangGraph setiap operasi checkpoint membutuhkan thread_id yang menghubungkan suatu run dengan state yang tersimpan.
Apa yang Menyebabkan Reasoning Degradation dalam Jalannya Agent yang Panjang?
Kualitas penalaran menurun seiring bertambahnya konteks, bahkan sebelum Anda mencapai batas token keras. Ini adalah efek "lost in the middle", di mana model memperhatikan awal dan akhir konteks panjang tetapi kehilangan bagian tengah. Blog rekayasa Anthropic menyebut mekanisme dasarnya sebagai "context rot": karena setiap token memperhatikan setiap token lainnya, Anda mendapatkan hubungan berpasangan n² dan atensi model semakin menipis seiring bertambahnya panjang konteks. Solusinya adalah kompresi mid-loop yang meringkas riwayat basi sambil menjaga constraint yang dipinned dan instruksi keamanan tetap utuh.
Ditandai
