تیپ #۲۶

بازیابی کار پس از خطا با ذخیرهٔ وضعیت

عامل‌های طولانی‌مدت معمولاً وسط کار می‌شکنند: یک فراخوانی ابزار تایم‌اوت می‌خورد، مدل خروجی نامعتبر می‌دهد، یا پروسه از بین می‌رود. اگر وضعیت اجرا فقط در حافظه باشد، هر خطا یعنی شروع از صفر و پرداخت دوبارهٔ هزینهٔ همهٔ توکن‌ها. راه‌حل این است که بعد از هر گام یک checkpoint از گراف وضعیت، با یک thread id مشخص، ذخیره کنی تا اجرا از آخرین گام سالم ادامه پیدا کند 💾. نکتهٔ ظریف ماجرا idempotent بودن گام‌هاست، چون در بازگشت همان گام خطادار دوباره اجرا می‌شود و اثری مثل ارسال ایمیل یا پرداخت نباید دو بار تکرار شود.

توضیح کامل‌تر

در ساخت عامل‌های طولانی‌مدت، وضعیت اجرا چیزی بیشتر از تاریخچهٔ پیام‌هاست و شامل گام فعلی گراف، خروجی ابزارها، متغیرهای میانی و تصمیم‌های گرفته‌شده می‌شود. موتورهای اجرای گراف مانند LangGraph بعد از هر super-step یک checkpoint از این وضعیت را در یک انبار پایدار مثل Postgres یا Redis می‌نویسند و آن را با یک thread id به یک مکالمه یا کار مشخص گره می‌زنند. وقتی خطایی رخ می‌دهد، به‌جای اجرای دوبارهٔ کل زنجیره فقط همان گام ناتمام از آخرین checkpoint بازپخش می‌شود. این کار هم هزینهٔ توکن را به‌شدت پایین می‌آورد و هم الگوهایی مثل human-in-the-loop را ممکن می‌کند، چون می‌توان اجرا را متوقف کرد، وضعیت را بررسی کرد و بعد ادامه داد. مثال ساده: یک عامل پژوهشی با ۴۰ فراخوانی ابزار در گام ۳۷ کرش می‌کند و با checkpoint از گام ۳۶ ادامه می‌دهد، نه از صفر. تن‌ها شرط جدی این است که هر گام idempotent باشد، وگرنه بازپخش ممکن است یک ایمیل را دو بار بفرستد یا یک پرداخت را تکرار کند. به همین دلیل بهتر است اثرات جانبی بیرونی را با یک کلید یکتا یا idempotency key همراه کنی تا اجرای دوباره بی‌خطر شود.