از چت‌بات تا عامل اجرایی

هدف‌های یادگیری

در پایان این درس می‌توانی «مرزبندی پاسخ متنی، فراخوانی ابزار و تغییر وضعیت» را توضیح دهی، نمونه‌ای مستقل اجرا کنی و خروجی را با معیارهای مشخص آزمایش کنی.

پیش‌نیاز

درس‌های قبل این فصل، شناخت مفاهیم فصل 1 و یک محیط آزمایشی بدون اطلاعات واقعی مشتری.

مسئله واقعی

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

آموزش مفهومی

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

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

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

اجرای گام‌به‌گام

1. محدوده MVP را تعریف کن: فقط یک سناریوی «از چت‌بات تا عامل اجرایی» و یک مقصد آزمایشی.
2. ورودی تست را با شناسه DEMO-01-01 بساز و فیلدهای ضروری را مشخص کن.
3. برای هر درخواست نمودار ورودی → تصمیم → ابزار → پاسخ ترسیم کن. هر انتقال داده را به قرارداد مشخص گره بزن.
4. قبل از عمل نهایی، نتیجه اعتبارسنجی و مجوز را کنترل کن؛ در صورت ابهام به وضعیت needs_review برو.
5. همان ورودی را دوباره ارسال کن تا بررسی شود اقدام تکراری اتفاق نمی‌افتد.
6. یک ورودی ناقص و یک timeout شبیه‌سازی کن و نتیجه هر دو را در گزارش ثبت کن.

نمونه داده و شبه‌کد

{
  "event_id": "DEMO-01-01",
  "customer": {
    "name": "مشتری آزمایشی",
    "consent": true
  },
  "intent": "demo",
  "state": "pending_review",
  "source": "training_form"
}

if not validate(payload): return reject(400)
if already_processed(event_id): return previous_result
result = evaluate_with_rules(payload)
if result.requires_sensitive_action: queue_for_human_review(result)
else: save_draft(result)
record_trace_without_personal_data(event_id)

این قطعه شبه‌کد آموزشی است، نه کد آماده اتصال به سرویس تولیدی. پیاده‌سازی واقعی به مجوز، API مقصد و ذخیره پایدار رویداد نیاز دارد.

خطای رایج و رفع آن

خطا: دادن اختیار نوشتن در CRM به مدل بدون مجوز. راه‌حل: ابزار نوشتن را پشت لایه تأیید و دسترسی قرار بده. ابتدا در تست منفی بازتولید کن، سپس فقط همان مسیر معیوب را اصلاح و تست رگرسیون اجرا کن.

تمرین مستقل

در یک محیط تست، «برای هر درخواست نمودار ورودی → تصمیم → ابزار → پاسخ ترسیم کن». فایل خروجی مورد انتظار: جدول تصمیم درباره اجرای دستی/خودکار. یک نتیجه موفق، یک نتیجه نامعتبر و یک اجرای تکراری را ضمیمه کن. از داده واقعی مشتری استفاده نکن.

معیار موفقیت

• خروجی «جدول تصمیم درباره اجرای دستی/خودکار» با شناسه و تاریخ تولید شده باشد.
• ورودی نامعتبر بدون اقدام خارجی رد شود.
• اجرای مجدد با همان event_id رکورد یا پیام تکراری نسازد.
• مجوز و تأیید انسانی برای اقدام حساس رعایت شود.
• مستند کوتاهی از محدودیت‌ها و نحوه بازیابی خطا ارائه شود.

جمع‌بندی

در این درس «مرزبندی پاسخ متنی، فراخوانی ابزار و تغییر وضعیت» را از تعریف تا آزمون مستقل پیش بردی. این خروجی جزء قابل اتصال به فصل‌های بعدی است؛ پیش از اتصال به حساب واقعی باید امنیت و صحت مجوزها مستقل ارزیابی شود.

{
  "event_id": "DEMO-01-01",
  "status": "pending_review",
  "consent": true
}