SafeReach: عامل صوتی برای مدیریت بحران با اولویت «پذیرش شکست»

تصور کنید در میانه‌ی یک سیل یا طوفان هستید؛ دست‌هایتان پر است، محیط پر سر و صداست و تایپ کردن در یک چت‌بات عملاً غیرممکن است. در چنین لحظاتی، یک پاسخ اشتباه اما با اعتمادبه‌نفس درباره‌ی مکان پناهگاه‌ها می‌تواند به‌جای کمک، مرگبار باشد.

SafeReach یک دستیار صوتی برای مدیریت بحران است که ثابت می‌کند مهم‌ترین ویژگی یک هوش مصنوعی در شرایط اضطراری، دانستن زمانِ «ساکت شدن» و سپردن مدیریت به یک انسان است. این پروژه در جریان چالش «۱۰ روز عامل‌های صوتی — نسخه VoiceForBharat» توسط Murf AI توسعه یافته و هدف آن محیط‌های پر استرس است که در آن‌ها تایپ کردن غیرممکن است و دقت، مستقیماً با ایمنی جانی گره خورده است.

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

دستورالعمل طراحی

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

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

معماری قابلیت اطمینان

این سیستم به‌عنوان یک دستیار مبتنی بر مرورگر و تماس تلفنی عمل می‌کند. برای انتقال لحظه‌ای صوت بین کاربر و عامل، از LiveKit به‌عنوان لایه انتقال بلادرنگ (Real-time transport layer) استفاده شده است تا صوت را چه برای کاربرانی که از طریق مرورگر متصل می‌شوند و چه از طریق پروتکل SIP، جابه‌جا کند. موتور استدلال این سیستم توسط Google Gemini (به‌طور خاص نسخه gemini-3.5-flash-lite) تامین می‌شود و تبدیل گفتار به متن (STT) بر عهده‌ی Deepgram Nova-3 است.

برای خروجی نهایی، عامل از Murf Falcon با صدای «Anisha» (با لوکال en-IN) در سبک محاوره‌ای استفاده می‌کند تا لحنی آرام و کاربردی حفظ شود. بخش بک‌اند با پایتون و Next.js نوشته شده و با pnpm اجرا می‌شود. نکته‌ی فنی مهم این است که پروژه از یک فایل مجزای prompts.py برای مدیریت شخصیت‌های پیچیده و محدودیت‌های ایمنی استفاده می‌کند تا منطق اصلی در agent.py شلوغ نشود. این تفکیک اجازه داد تا تکرار و اصلاح مرزهای ایمنی با سرعت بیشتری انجام شود بدون اینکه کد سیم‌کشی (Wiring code) عامل به خطر بیفتد.

جزئیات پشته فنی

• فرانت‌اند: Next.js (بر پایه پروژه استارتر Murf LiveKit)، اجرا با pnpm.
• بک‌اند: Python، LiveKit Agents (شامل AgentSession و AgentServer)، LiveKit RTC.
• STT: Deepgram Nova-3.
• LLM: Google Gemini (gemini-3.5-flash-lite).
• TTS: Murf Falcon (صدای Anisha، لوکال en-IN، سبک محاوره‌ای).
• تشخیص نوبت (Turn Detection): MultilingualModel متعلق به LiveKit.
• VAD: Silero.
• حذف نویز: سیستم داخلی LiveKit (که برای شرکت‌کنندگان مرورگر و SIP به‌طور متفاوتی مدیریت می‌شود).
• حافظه: SQLite.
• داده‌های خارجی: API آب‌وهوای Open-Meteo.
• تلفنی: LiveKit SIP برای تماس‌های خروجی.
• ساختار بک‌اند: سازمان‌دهی شده در فایل‌های agent.py ،prompts.py ،memory.py ،escalation.py ،dashboard.py و یک دایرکتوری telephony/.

قابلیت‌ها و محدودیت‌های هسته

SafeReach به‌طور صریح برنامه‌ریزی شده تا هرگز تظاهر به مقام رسمی یا مرجع اضطراری نکند. قابلیت‌های آن به‌طور سخت‌گیرانه به موارد زیر محدود است:

• حافظه پایدار: با استفاده از SQLite، عامل نام، مکان، تعداد اعضای خانواده و نیازهای حرکتی کاربر (مثلاً «مادرم از ویلچر استفاده می‌کند») را به خاطر می‌سپارد. این کار باعث می‌شود اصطکاک ناشی از تکرار جزئیات حیاتی در طول بحران حذف شود، چرا که تکرار این موارد برای کاربران تحت استرس، یک عامل فشار روانی است. این تمرکز بر پایداری حافظه در عامل‌های هوشمند، یادآور راهکارهای Trigger.dev برای حذف تایم‌اوت‌ها و حفظ حافظه در عامل‌های پیچیده است که برای تداوم تجربه کاربر حیاتی است.
• داده‌های تاییدشده: سیستم دما، رطوبت نسبی و سرعت باد را به‌صورت لحظه‌ای از طریق API Open-Meteo استخراج می‌کند. یک قانون غیرقابل مذاکره در اینجا وجود دارد: اگر ابزار با خطا مواجه شد، عامل باید اعتراف کند که نمی‌تواند داده‌ها را بازیابی کند، نه اینکه یک تخمین محتمل و باورپذیر از طریق LLM تولید کند. یک شکاف صادقانه در اطلاعات، بر یک پاسخ ساختگی ترجیح داده می‌شود.
• پشتیبانی چندزبانه: سیستم توانایی مدیریت مکالمات به زبان انگلیسی هندی و ترکیبی از تامیل/انگلیسی (Tanglish) را دارد. این ویژگی برای کاربرانی در تامیل نادو که در شرایط استرس اغلب در میانه‌ی جمله زبان را تغییر می‌دهند، ضروری است.

گردش‌کار ارجاع به انسان

مهم‌ترین و اثرگذارترین بخش این ساختار، مکانیزم حضور انسان در چرخه (Human-in-the-loop) است. SafeReach می‌تواند موقعیت‌هایی را تشخیص دهد که شامل افراد به دام افتاده، مجروح یا کسانی است که در خطر فوری هستند. این سیستم به‌طور خودکار وضعیت‌های اضطراری را گزارش نمی‌کند؛ بلکه یک پروتکل سخت‌گیرانه چهارمرحله‌ای را دنبال می‌کند:

۱. تشخیص (Detect): شناسایی نیاز به کمک انسانی.
۲. توضیح (Explain): اطلاع‌رسانی به کاربر درباره اینکه عامل قصد دارد چه اطلاعاتی را به اشتراک بگذارد.
۳. اجازه (Permission): درخواست موافقت صریح از کاربر.
۴. ایجاد (Create): فراخوانی ابزار create_human_help_request.

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

ساختار داده‌های ارجاع

خلاصه‌ی ارجاع به‌طور عمدی محدود طراحی شده تا از حریم خصوصی محافظت شود. این خلاصه شامل موارد زیر است:

• شناسه مرجع (مثلاً SR-F423BE3E)
• برچسب زمانی (created_at) و وضعیت
• چه کسی نیاز به کمک دارد و چه اتفاقی افتاده است
• سطح فوریت و زبان مورد استفاده
• روش پیگیری ترجیحی
• مواردی که عامل پیش از این بررسی کرده است

این ساختار به‌طور صریح داده‌های حساس مانند رمزهای عبور، OTPها، پین‌ها یا شماره حساب‌ها را حذف می‌کند. کاربر یک شناسه مرجع concrete دریافت می‌کند تا مدرکی داشته باشد که درخواست او ثبت شده است.

مسیریابی چندعاملی و تحلیل‌ها

برای جلوگیری از حجیم شدن پرامپت‌ها (Prompt Bloat)، توسعه‌دهنده یک سیستم تفویض اختیار به متخصص (Specialist Handoff) را پیاده‌سازی کرد. وقتی کاربر درباره پناهگاه‌ها می‌پرسد، عامل اصلی به کاربر اطلاع می‌دهد («من شما را به متخصص اطلاعات پناهگاه وصل می‌کنم») و جلسه را به SafeReach Shelter Information Specialist منتقل می‌کند.

این عامل دوم دامنه‌ی به‌طور عمدی محدودتری دارد و فقط بر سوالات مربوط به پناهگاه تمرکز می‌کند. این عامل، زمینه‌ی (Context) مکالمه — از جمله مکان و مشکلات حرکتی — را به ارث می‌برد تا کاربر مجبور نباشد داستان خود را از ابتدا تعریف کند. این رویکرد، پروژه را از یک پرامپت واحد و بزرگ به یک سیستم چندعاملی کوچک تبدیل می‌کند.

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

درس‌های تلفنی و عیب‌یابی

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

سایر چالش‌های فنی عبارت بودند از:

• خطاهای Import پایتون: اجرای مستقیم عامل از طریق uv run python .\src\agent.py dev باعث خطای ImportError شد. راه حل این بود که برنامه به‌عنوان یک ماژول اجرا شود: uv run python -m src.agent dev.
• پیکربندی STT: تشخیص خودکار زبان در Deepgram ناهماهنگ بود؛ راه حل، پیکربندی صریح رفتار زبان در استریمینگ بود.
• منطق انتقال (Handoff): توسعه‌دهنده متوجه شد که کلاس پایه Agent متد داخلی handoff() یا transfer() ندارد. این امر مستلزم یک پیاده‌سازی سفارشی از طریق معماری agent/tool در LiveKit بود.
• باگ‌های طراحی: غریزه اولیه این بود که خلاصه‌های ارجاع را به‌طور خودکار هنگام تشخیص ایجاد کند. این مورد به جریان «تشخیص $\rightarrow$ توضیح $\rightarrow$ درخواست اجازه $\rightarrow$ ایجاد درخواست» اصلاح شد تا استانداردهای اخلاقی در پاسخ به بلایا حفظ شود.

تحلیل: قانون ۸۰/۲۰ در عامل‌های صوتی

این پروژه نشان می‌دهد که بخش «هوش مصنوعی» یک عامل صوتی — یعنی چسب بین STT، LLM و TTS — تنها ۲۰٪ از کار است. ۸۰٪ باقی‌مانده شامل سیستم پیرامون مدل است: مدیریت حافظه، مدیریت صادقانه‌ی خطاها و مرزهای حریم خصوصی.

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

ملاحظات امنیتی و حریم خصوصی

SafeReach به‌عنوان یک پروتوتایپ چالش، چندین اقدام پایه برای حریم خصوصی را اجرا کرده است:

• هیچ کلید API، شماره تلفن یا داده واقعی تماس‌گیرنده‌ای در مخزن (Repository) منتشر نشده است.
• خلاصه‌های ارجاع فقط به داده‌های ضروری عملیاتی محدود شده‌اند.
• هیچ OTP یا رمزی هرگز در لاگ‌ها گنجانده نمی‌شود.

برای انتقال به محیط عملیاتی (Production)، سیستم به رمزنگاری کامل در حالت انتقال و استراحت، لاگ‌های حسابرسی (Audit logging)، سیاست‌های تعریف‌شده برای نگهداری داده‌ها و یکپارچگی واقعی با سرویس‌های اضطراری تاییدشده نیاز دارد.

گام‌های بعدی

نسخه‌های آینده SafeReach قصد دارند با افزودن موارد زیر از مرحله پروتوتایپ فراتر روند:

• یکپارچگی تاییدشده با منابع واقعی اطلاعات اضطراری دولتی.
• داده‌های لحظه‌ای در دسترس بودن پناهگاه‌ها به‌جای راهنمایی‌های کلی.
• تشخیص خودکار ارجاعات تکراری.
• یک داشبورد پشتیبانی برای انسان‌ها جهت ردیابی ارجاعات باز.
• احراز هویت در سطح Production، رمزنگاری و به حداقل رساندن داده‌های شناسایی شخصی (PII).
• مانیتورینگ تأخیر (Latency) در کل خط لوله.
• مدیریت بهتر الگوهای گفتاری تامیل/Tanglish و تست‌های خودکار برای مسیریابی عامل.

جدول زمانی پیاده‌سازی و منطق

ساخت SafeReach یک توالی خاص را دنبال کرد تا اطمینان حاصل شود که ایمنی از ابتدا در سیستم نهادینه شده است:

• روز ۱-۲ (هویت): تمرکز بر prompts.py بود. پیش از کدنویسی ابزارها، توسعه‌دهنده تعریف کرد که عامل «مجاز نیست» چه کارهایی انجام دهد، مانند ساختن هشدارهای جعلی یا ادعای مقام رسمی.
• روز ۳ (تعامل): پیاده‌سازی رفتار چندزبانه برای پشتیبانی از ترکیب طبیعی تامیل و انگلیسی.
• روز ۴ (حافظه): یکپارچگی با SQLite برای جلوگیری از تکرار نیازهای حیاتی (مانند دسترسی به ویلچر) توسط کاربران در زمان بحران.
• روز ۵ (آب‌وهوا): افزودن API Open-Meteo با الزام سخت‌گیرانه «شکست صادقانه».
• روز ۶ (تلفنی): تست تماس‌های خروجی از طریق LiveKit SIP و مستندسازی حالت‌های شکست 486 Busy Here.
• روز ۷ (ارجاع): توسعه جریان درخواست کمک انسانی مبتنی بر اجازه.
• روز ۸ (تحلیل‌ها): ساخت داشبورد برای ردیابی نتایج واقعی تماس‌ها.
• روز ۹ (تخصص): ایجاد عامل متخصص اطلاعات پناهگاه برای کاهش پیچیدگی پرامپت.

تنظیمات نهایی پروژه

برای کسانی که قصد بازسازی این پروژه را دارند، محیط به تنظیمات خاصی نیاز دارد:

• اجرای بک‌اند: دستور uv sync و سپس uv run python -m src.agent dev.
• اجرای فرانت‌اند: دستور pnpm install و سپس pnpm dev.
• پیکربندی: متغیرهای محیطی در .env.local مدیریت می‌شوند تا اعتبارنامه‌های LiveKit، Murf، Deepgram و Google/Gemini محافظت شوند.

شما می‌توانید الگوهای معماری برای عامل‌های حساس را در مخزن گیت‌هاب پروژه بررسی کنید.

گام بعدی شما

• بررسی معماری تفکیک prompts.py از agent.py برای مدیریت بهتر مرزهای ایمنی در پروژه‌های خود.
• مطالعه مستندات LiveKit SIP برای درک محدودیت‌های زیرساختی تماس‌های صوتی AI.
• پیاده‌سازی مکانیزم «اجازه کاربر» پیش از ارسال داده‌های حساس در عامل‌های خودکار.

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