هر نقشه راه محصولی یک مورد دارد که می‌گوید «عامل هوش مصنوعی» (AI Agent). این کلمه نوید پیشرفت می‌دهد. به مدیریت نشان می‌دهد که تیم شما در حال ساختن آینده است، نه فقط نگهداری از حال. اما حقیقت ناخوشایندی وجود دارد که اکثر ویدئوهای دمو به شما نشان نمی‌دهند: یک عامل، گران‌ترین و غیرقابل‌پیش‌بینی‌ترین راه برای انجام یک کار است. برای اکثر وظایف تجاری، این ابزار کاملاً اشتباه است. بهترین مهندسان کسانی نیستند که برای ساختن آن عجله می‌کنند؛ بلکه کسانی هستند که می‌دانند چه زمانی باید متوقف شوند.

تله‌ی طبقه‌بندی

تماشای تیمی که در حال تعیین محدوده اولین عامل خود است، معمولاً صحنه‌ای شبیه به این را نشان می‌دهد: یک ایمیل پشتیبانی می‌رسد. یک مدل زبانی بزرگ (LLM) موضوع و متن را می‌خواند، تصمیم می‌گیرد که آیا این یک سوال مربوط به صورت‌حساب است یا یک باگ فنی، و آن را در صف مناسب قرار می‌دهد. تیم این را یک «عامل» می‌نامد. اما نیست.

آنچه آن‌ها ساخته‌اند، یک جریان قطعی (deterministic flow) با یک فراخوانی مدل در داخل آن است. مراحل ثابت هستند: دریافت ایمیل، فراخوانی مدل، هدایت به صف. هیچ حلقه‌ای وجود ندارد، از ابزاری استفاده نمی‌شود و هیچ لحظه‌ای نیست که سیستم برای بازنگری در برنامه خود (به دلیل شکست در تلاش اول) متوقف شود. سیستم در حین اجرا، پایگاه دانش را جستجو نمی‌کند، کد نمی‌نویسد یا وضعیت سفارش را بررسی نمی‌کند. فقط یک قضاوت انجام می‌دهد و از آن می‌گذرد. قرار دادن آن یک فراخوانی در یک میکروسرویس، آن را به یک عامل تبدیل نمی‌کند.

هزینه واقعی اشتباه گرفتن یک جریان با یک عامل، فقط زیرساخت اضافی نیست. بلکه آن عدم قطعیت (non-determinism) است که بدون هیچ سودی به وجود آورده‌اید. یک ایمیل مشابه ممکن است صبح سه‌شنبه با بعدازظهر چهارشنبه به طور متفاوتی مسیریابی شود، زیرا دما (temperature) غیرصفر است یا پرامپت دچار انحراف شده است. شما هزینه‌های مربوط به عامل را بابت تأخیر (latency)، هزینه توکن‌ها و سربار ارزیابی می‌پردازید، در حالی که یک جریان با یک مرحله طبقه‌بندی، مشکل را سریع‌تر و ارزان‌تر حل می‌کند.

از پایین نردبان شروع کنید

اکثر مشکلات، پسرعموهای ساده‌تری دارند که به همان خوبی آن‌ها را حل می‌کنند. آن را مانند یک نردبان تصور کنید و از پایین شروع کنید.

فرآیند را اصلاح کنید. گاهی اوقات کار فقط به این دلیل وجود دارد که دو سیستم با هم اختلاف نظر دارند. یک رکورد مشتری در CRM شما با پلتفرم تیکتینگ شما همگام نیست، بنابراین یک انسان باید هر روز صبح این شکاف را به صورت دستی پر کند. آن شکاف را با یک عامل خودکار نکنید؛ بلکه آن را حذف کنید. اگر خط لوله داده‌ها (data pipeline) سالم بود، آن کار از بین می‌رفت.

از یک پرس‌وجو استفاده کنید. اگر پاسخ یک جستجوی ساده یا تجمیع داده‌ها است، با آن همان‌گونه برخورد کنید. «سه شنبه گذشته چند بازگشت وجه (refund) داشتیم؟» نیازی به استدلال ندارد؛ به SQL نیاز دارد. عاملی که زبان طبیعی را به SQL ترجمه می‌کند، ظاهراً ظریف به نظر می‌رسد، تا زمانی که متوجه شوید بار نگهداری آن از نوشتن سه پرس‌وجوی مستند شده که تیم شما از یک داشبورد اجرا می‌کند، بسیار بیشتر است.

یک جریان قطعی بسازید. وقتی قوانین ثابت هستند و نتیجه تکرارپذیر است، از منطق صریح استفاده کنید. اگر ارزش سفارش از حد مشخصی فراتر رفت، به بخش مالی ارجاع شود. اگر کاربری به مدت سی روز غیرفعال بود، یک ایمیل تعاملی ارسال شود. کد این کار را با صفر درصد تغییر و مشاهده‌پذیری کامل انجام می‌دهد. شما می‌توانید آن را unit-test کنید. شما نمی‌توانید یک «حس و حال» (vibe) را unit-test کنید.

از جریانی با یک فراخوانی مدل استفاده کنید. این جایی است که طبقه‌بندی، برچسب‌گذاری احساسات یا استخراج داده قرار دارد. مدل یک قضاوت واحد در یک اسکریپت صلب انجام می‌دهد. شما یک سند را دریافت می‌کنید، شماره فاکتور را استخراج می‌کنید و آن را در پایگاه داده می‌نویسید. مراحل اطراف آن به صورت hardcoded هستند. مدل انتخاب نمی‌کند که مرحله بعد چه باشد؛ بلکه فقط آنچه را می‌بیند برچسب می‌زند. این یک الگوی قدرتمند است، اما همچنان یک جریان است.

عامل را در آخرین مرحله بسازید. این مرحله را برای وظایفی رزرو کنید که در آن‌ها اقدام بعدی واقعاً به آنچه مدل در حین اجرا کشف می‌کند، بستگی دارد. اگر سیستم باید یک ایمیل را بخواند، متوجه شود که نیاز دارد یک محموله را در یک API لجستیک جستجو کند، متوجه شود که محموله تأخیر دارد و سپس بر اساس آن داده‌های تازه، یک پاسخ سفارشی بنویسد، شما در قلمرو عامل هستید. مسیر را نمی‌توان از قبل ترسیم کرد زیرا مدل تصمیم می‌گیرد پس از هر واقعیت جدید چه کاری انجام دهد.

تست تخته‌سفید

راه سریعی برای فیصله دادن به بحث در یک جلسه وجود دارد. از تیم خود بخواهید شاخه‌های تصمیم‌گیری را روی یک تخته‌سفید رسم کنند.

اگر می‌توانید قبل از اجرای مدل، هر مسیر را ترسیم کنید، یک جریان بسازید. اشکال لوزی را بکشید، دستورات if را بنویسید و تمام. پیش‌بینی‌پذیری یک ویژگی است، نه یک محدودیت.

اگر خود مدل باید تصمیم بگیرد که مرحله بعدی اصلاً چیست، اگر خودش ابزار را انتخاب می‌کند، پارامترها را تنظیم می‌کند و برای بازنگری در تصمیم خود به عقب برمی‌گردد، آن وقت به یک عامل نیاز دارید. آن مسیریابی پویا (dynamic routing) خط مرز است. به طور تصادفی از آن عبور نکنید، فقط چون می‌خواستید از یک API جدید استفاده کنید.

مالیات پنهان

دموها باعث می‌شوند عامل‌ها بدون اصطکاک به نظر برسند. محیط عملیاتی (Production) چهار مالیات را آشکار می‌کند که به سرعت انباشته می‌شوند.

عدم قطعیت (Non-determinism). همان...