بدهی فنی ایجنتها: هر کار رو کجای معماری بذاریم؟
خلاصهٔ کاملتر
کای ویونر تو این مقاله از مقالهٔ معروف گوگل در سال ۲۰۱۵ شروع میکنه که میگفت کد ML فقط یه جعبهٔ کوچیک وسط یه سیستم خیلی بزرگتره. نویسنده معتقده تو ایجنتها هم همینه: صدا زدن مدل جعبهٔ کوچیکه و دورش پرامپت، ابزارها، حافظه، retry، تأیید، دسترسیها، بودجه و audit نشستن. agentic technical debt یعنی هزینهٔ میانبرهایی که این تیکهها رو سریعتر از تست و استانداردسازی به هم وصل میکنن.
آمارها هم همینو نشون میدن. Gartner پیشبینی کرده تا آخر ۲۰۲۶، ۴۰٪ اپهای سازمانی ایجنت داشته باشن، ولی بیش از ۴۰٪ پروژههای ایجنتی تا آخر ۲۰۲۷ کنسل بشن. تو نظرسنجی Camunda از ۱۱۵۰ نفر، ۷۱٪ گفتن از ایجنت استفاده میکنن ولی فقط ۱۱٪ موارد به production رسیده. دلیلش اینه که خروجی ایجنت قطعی نیست، روی سیستمهای واقعی کار انجام میده، کارش ممکنه چند روز طول بکشه و صاحبهای زیادی داره.
نویسنده چهار لایه تعریف میکنه. Model که فکر و تصمیم میگیره. Agent harness یعنی runtime دور مدل برای یه ایجنت که حلقهٔ کنترل، صدا زدن ابزار و حافظه رو میگردونه (مثل LangGraph یا OpenAI Agents SDK). Durable execution یعنی ذخیرهٔ هر قدم تا یه کار طولانی بعد از crash ادامه پیدا کنه، مثل Temporal. آخرش هم orchestration control plane که کار رو بین سیستمها و تیمها هماهنگ میکنه و تأیید، deadline و audit دستشه.
تقسیم کارها اینطوریه: harness فقط retryهای بیعارضه رو انجام میده، ولی قدمی که یه سیستم کسبوکار رو تغییر میده باید با یه business ID تکرار بشه تا مثلاً یه رزرو دوبار ثبت نشه. تأیید انسانی یه قدم صریح با timeout و مسیر escalation تو control plane هست. بودجهٔ توکن هم دو سطح داره: harness یه run رو محدود میکنه و control plane بودجهٔ هر تیم یا فرایند رو. تو حملههای LLMjacking که Mandiant بررسی کرده، مهاجمها تو یه روز بیش از ۱۰۰ هزار دلار هزینهٔ مدل بالا آوردن.
اشتباههای رایج از نظر نویسنده: نوشتن قانون تأیید تو پرامپت («قبل از refund بالای ۱۰۰۰ یورو بپرس») که هیچکس نمیتونه ثابت کنه همیشه کار کرده، retry تو حلقهٔ ایجنت که باعث میشه تأمینکننده دوتا credit note بگیره، و audit پخششده تو trace هر فریمورک. مثالش یه اختلاف فاکتوره که اکثرش با تطبیق قطعی و بدون AI حل میشه و ایجنت فقط یه قدم محدود وسطش رو انجام میده و هیچوقت خودش تنهایی تصمیم نمیگیره پول جابهجا بشه. نویسنده برای control plane از Kestra استفاده میکنه.
البته هر ایجنتی control plane نمیخواد. یه دستیار کدنویسی یا ایجنت تحقیق تو یه اپ با harness خودش کافیه. ولی وقتی فرایند از چند سیستم رد میشه، پول یا مشتری درگیره، auditor گزارش کامل میخواد یا ایجنتهای چند vendor روی یه فرایند کار میکنن، این لایه لازمه. نویسنده میگه چون مدلها دارن کالای عمومی میشن، ارزش داره میره سمت لایهای که state و تأیید و audit رو نگه میداره.
نکات کلیدی:
- فقط ۱۱٪ موارد استفادهٔ ایجنتی تو نظرسنجی Camunda به production رسیدن
- retry قدمهایی که سیستم واقعی رو تغییر میدن باید با business ID باشه، نه تو حلقهٔ ایجنت
- تأیید انسانی باید یه قدم صریح با timeout و escalation باشه، نه یه جمله تو system prompt
- بودجهٔ توکن در دو سطح: هر run تو harness و هر تیم یا فرایند تو control plane
- ایجنت تنها تو یه اپ معمولاً به control plane نیاز نداره




