ایجنت کمک می‌کند؛ گردش کار قطعی هنوز صورتحساب را می‌دهد
قوی‌ترین محصول‌های AI انعطاف ایجنت را با مسیر قطعی اپ ترکیب می‌کنند، نه اینکه یکی را جای دیگری بگذارند. تا اوایل ۲۰۲۶ واژه ایجنت زبان پیش‌فرض بخش بزرگی از بحث محصول شده بود. ابزار بهتر شده و این طبیعی است. حالت خرابی هم آمده: گردش کار قطعی را قدیمی حساب کردن، در حالی که همان چیز کیفیت محصول را پایدار نگه می‌دارد.
حقیقت این است که خیلی از کارهای پرارزش هنوز از منطق قابل پیش‌بینی اپ سود می‌برند. اعتبارسنجی، مجوز، صورتحساب، اعلان، به‌روزرسانی رکورد، و بیشتر گذارهای وضعیتی که کاربر می‌بیند نباید پیش‌فرض «ایجنتی» باشند. باید صریح، قابل تست، و کسل باشند.
ایجنت کجا می‌درخشد
جایی که ایجنت به درد می‌خورد میانه مبهم است. فهمیدن قصد، انتخاب بین عمل‌های محدود، خلاصه کردن زمینه، یا پیش‌نویس کاری که سیستم قطعی بعداً اعتبار و اجرا می‌کند. این شراکت از سپردن کل سفر کاربر به مدل قوی‌تر است.
مثال را در محصول واقعی ببین، نه در دیاگرام. کاربر می‌گوید «این صورتحساب را با قرارداد پارسال میزان کن». مدل می‌تواند سند را بخواند، فرق را خلاصه کند، و یک پیشنهاد ساخت‌یافته بدهد: کدام بند، کدام مبلغ، کدام فیلد رکورد. اپ باید تصمیم بگیرد این کاربر حق دیدن قرارداد را دارد، مبلغ داخل محدوده مجاز است، و نوشتن در سیستم مالی فقط بعد از تأیید انسان انجام شود. اگر مدل خودش رکورد را آپدیت کند، دیگر دستیار نیست. اپراتور بدون رد است.
مرز را این‌طور بنویس. مدل پیشنهاد می‌دهد. طرح را اعتبار می‌کند. سیاست اجازه را قطعی چک می‌کند. اثر جانبی را کد معمولی اجرا می‌کند، با idempotency و لاگ. ایجنت اگر در این زنجیره جای «پیشنهاد» و «خلاصه‌سازی» را بگیرد مفید است. اگر جای «اجازه» و «نوشتن» را بگیرد، دیباگ گران می‌شود.
چرا قطعی بودن صورتحساب را می‌دهد
کارهایی که شکستشان برای کاربر قابل توضیح نیست باید مسیر قطعی داشته باشند. پرداخت یا ثبت شد یا نشد. دسترسی یا هست یا نیست. اعلان یا رفت یا در صف ماند. این حالت‌ها را نمی‌شود با «مدل فکر کرد بهتر است» توضیح داد. پشتیبانی، مالی، و حسابرسی زبان دیگری ندارند.
قطعی بودن یعنی می‌توانی تست بنویسی که بدون شبکه مدل هم معنی دارد. مجوز را با نقش کاربر و منبع چک کن. گذار وضعیت را با جدول مجاز چک کن. مبلغ را با طرح تایپ‌دار چک کن. این تست‌ها در CI ارزان‌اند و در حادثه قابل نقل‌اند. تست ایجنت هنوز لازم است، ولی جای این‌ها را نمی‌گیرد.
از دید فول‌استک، ابزار بهتر وقتی ارزش دارد که شکل اپ را آرام‌تر کند. شاید یک مسیر هم‌زمان بالاخره ناهم‌زمان شود. شاید قابلیت گران فقط روی تکه مبهم بنشیند. مدل قوی‌تر اگر منطق صورتحساب را هم ببلعد، اصطکاک کاربر را کم نکرده. سطح پاسخگویی را پاک کرده.
اشتباهی که هنوز می‌بینم
اشتباه این است که ایجنت را مسئول چیزی کنی که اپ باید مالکش باشد. دیباگ سخت می‌شود، پاسخگویی مات می‌شود، و محصول طوری می‌شکند که توضیحش برای کاربر گران است و درست کردنش گران‌تر.
شکلش معمولاً این است. یک پرامپت بلند می‌گوید «اگر مطمئن بودی ایمیل بفرست و اگر نه بپرس». مطمئن بودن معیار اپ نیست. معیار اپ یک شرط است: قالب تأیید شده، گیرنده مجاز است، سقف ارسال امروز رد نشده، انسان این نوع پیام را آزاد کرده. این شرط‌ها را در کد بگذار. مدل حداکثر پیش‌نویس متن را بدهد.
اشتباه دوم این است که بهبود پلتفرم را ارتقای معماری حساب کنی. نمی‌شود. اگر گردش کار مبهم است، اگر حفاظ ضعیف است، یا اگر کسی نمی‌تواند بگوید فراخوانی گران کجا است، ابزار جدید راه سریع‌تری برای ادامه آشفتگی است.
تکه‌های کسل هنوز اعتماد را می‌سازند. حالت خطا، زمان پاسخ، retry، لاگ، حسابرسی، و دست‌به‌دست به کد معمولی. ایجنتی که خطا را داخل جمله نصفه قایم می‌کند، کاربر را بدون اقدام بعدی می‌گذارد. مسیر قطعی حداقل می‌تواند بگوید کدام گذار رد شد و چرا.
چطور در محصول زنده جدا کنم
یک گردش کار را بردار که امروز بیش از حد به مدل چسبیده. جمله کار را بنویس. بعد دو ستون بکش. ستون مبهم: قصد، خلاصه، پیش‌نویس، انتخاب بین گزینه‌های از قبل مجاز. ستون قطعی: هویت، مجوز، پول، وضعیت رکورد، ارسال، حذف.
هر چیزی در ستون دوم باید بدون مدل قابل اجرا و قابل تست باشد. مدل فقط ورودی آن ستون را پیشنهاد می‌کند، آن هم با خروجی ساخت‌یافته که قبل از اثر جانبی اعتبار می‌شود. اگر اعتبار شکست خورد، اثر جانبی اجرا نمی‌شود. این را به‌صورت کد بنویس نه به‌صورت امید در پرامپت.
سقف هم بگذار. تعداد ابزار، تعداد قدم، و فهرست اثر جانبی مجاز. اگر سیستم نمی‌تواند توضیح دهد چرا ایستاد یا چرا از انسان پرسید، برای کار مهم آماده نیست. ایجنت بدون افسار همان گردش کار قطعی است که کنترلش را گم کرده.
انتشار را کوچک کن. اول مسیر را طوری عوض کن که اثر جانبی از مسیر مدل خارج شود، حتی اگر پیش‌نویس هنوز ساده باشد. کیفیت مدل را بعداً بهتر کن. ترتیب برعکس وسوسه‌کننده است و حادثه می‌سازد.
این هفته
یک کار کاربر را انتخاب کن که هم بخش مبهم دارد هم بخش حساس. مرز را در یک پاراگراف بنویس، قبل از اینکه فریمورک ایجنت را عوض کنی. تست قطعی را برای مجوز و گذار وضعیت اضافه کن. لاگ را طوری بگذار که بشود گفت پیشنهاد مدل چه بود و اپ کدام عمل را واقعاً اجرا کرد. اگر این دو را از هم تشخیص نمی‌دهی، هنوز شراکت نداری. یک حلقه مبهم داری که صورتحساب را هم در خودش حل کرده.
محصول خوب بین ایجنت و نرم‌افزار قطعی انتخاب نمی‌کند. تصمیم می‌گیرد هر کدام کجا بنشیند.
پرسش‌های کوتاه
**پس ایجنت را کنار بگذارم؟** نه. از مسیر پول، مجوز، و وضعیت بیرونش کن. در فهم قصد و پیش‌نویس نگه دار.
**اگر مدل فقط گاهی اثر جانبی را درست انجام دهد؟** گاهی کافی نیست. اثر جانبی باید هر بار از کد قطعی رد شود، حتی وقتی پیشنهاد مدل درست است.
**اعتبار ساخت‌یافته جای گردش کار را می‌گیرد؟** نه. اعتبار شکل داده را چک می‌کند. گردش کار قطعی اجازه و ترتیب عمل را چک می‌کند. هر دو لازم‌اند.