لوپ اینجینیرینگ تو کلود؛ کار تا رسیدن به خط پایان
هوش مصنوعیClaude Opus 5خلاصهٔ کاملتر
تو این مقاله اومده که لوپ اینجینیرینگ یعنی بهجای یه پرامپت و یه پاسخ، به ایجنت یه چرخهٔ کاری تکرارشونده با خط پایان روشن بدی. کلود خودش قدمهای لازم رو برنامهریزی میکنه، اجراشون میکنه، چک میکنه که شرط پایان برقرار شده یا نه، و فقط وقتی برمیگرده سراغت که کارش تموم شده باشه یا واقعاً به نظرت احتیاج داشته باشه. آنتروپیک همین رو مکانیزم پشت تسکهای زمانبندیشده توصیف کرده.
به گفتهٔ نویسنده، «شرط پایان» یا criteria of done مهمترین چیزیه که باید درست بنویسی، چون هدف مبهم یا ایجنتی میسازه که خیلی زود وایمیسته یا بیهدف ادامه میده. شرط پایان خوب سه ویژگی داره: قابلاندازهگیریه، کل دامنهٔ کار رو پوشش میده، و مشخص میکنه وقتی کاری تمیز تموم نمیشه چی باید بشه. مثلاً مغایرتگیری فاکتورها وقتی «تمومه» که هر تراکنش یا مچ شده باشه یا برای بررسی دستی علامت خورده باشه.
لوپها با سه نوع تریگر راه میافتن. تریگر مبتنی بر نوبت با پیام آدم شروع میشه و کمترین صرفهجویی رو داره چون یکی باید حاضر باشه. تریگر زمانی رو یه زمانبندی اجرا میشه — مثلاً هر جمعه ساعت مشخص — و بیشتر اتوماسیون واقعی کسبوکار همینجاست. تریگر رویدادی هم با اتفاق بیرونی مثل رسیدن ایمیل فعال میشه؛ نویسنده میگه اغلب میشه اون رو با یه چک ساعتی زمانبندیشده شبیهسازی کرد و فقط کمی تأخیر رو پذیرفت.
دو محدودیت عملی هم مدام سر راه سبز میشن: تسکهای ابری فقط از راه کانکتورهای داخلی به اپهای بیرونی وصل میشن و جای امنی برای کلید API خام ندارن، و خیلی از کانکتورها به یه حساب محدودن. راهحل رایج، یه لایهٔ واسط مثل Composio ـه که اعتبارنامهها سمت خودش میمونن. ضمناً تسکهای ابری به فایلهای لوکال دسترسی ندارن، پس اطلاعات مشترک مثل قالبها یا پروفایل لحن باید جایی مثل Notion ذخیره بشه.
نکات کلیدی:
- لوپ یعنی چرخهٔ کاری تکرارشونده با شرط پایان مشخص، نه یه پرسش و پاسخ ساده
- شرط پایان باید قابلسنجش باشه و حالتهای حلنشده رو هم پیشبینی کنه
- سه نوع تریگر: مبتنی بر نوبت، زمانی و رویدادی
- تریگر رویدادی رو میشه با چکهای مکرر زمانبندیشده شبیهسازی کرد
- تسکهای ابری به فایل لوکال دسترسی ندارن؛ اطلاعات مشترک باید تو یه اپ متصل باشه
- لوپ برای کارهای تکراری و تعریفشده میارزه، نه برای کار مبهم و قضاوتمحور
