ایجنت رصد شبکههای اجتماعی
یه ایجنت تحقیق با LangGraph طراحی کردم و ساختم که حجم زیاد پستهای هر روز رو به یه گزارش کوتاه با لینک منبع تبدیل میکنه. به سؤال مشخص هم جواب میده؛ مثلاً اینکه چند تا حساب خاص یا فالوئرهاشون دربارهٔ یه موضوع چی گفتن.
مسئله
تیم چند موضوع پرتحرک رو توی X (توییتر) دنبال میکرد: دستههای موضوعی، آدمهای مشخص، کامیونیتیها و ترندها. برای عقب نموندن باید هر روز همون جستوجوها رو دستی تکرار میکرد، از بین کلی پست بیربط رد میشد و باز هم ممکن بود پست مهم از قلم بیفته. سؤالهای مشخص، مثل اینکه چند تا حساب یا فالوئرهاشون دربارهٔ یه موضوع چی میگن، از این هم وقتگیرتر بود.
نقش من
کل سیستم رو از طراحی تا اجرا خودم ساختم: workflow با LangGraph، جمعآوری از دستههای موضوعی، آدمها، فالوئرها، کامیونیتیها و ترندها، منطق فیلتر و سنجش ارتباط، promptهای LLM و اجرای زمانبندیشده توی Docker که گزارش روزانه رو خودکار میسازه.
مسیر کار
- ۰۱تعیین محدوده
- ۰۲جمعآوری
- ۰۳فیلتر و حذف تکراری
- ۰۴سنجش با LLM
- ۰۵خلاصه
- ۰۶تحویل با لینک منبع
تصمیمهای فنی مهم
واقعیت با کد، قضاوت با مدل
تازه بودن، زبان و تکراری بودن هر پست رو قاعدههای مشخص چک میکنن. از LLM فقط چیزی رو میپرسم که واقعاً کارشه: این پست ارزش وقت گذاشتن داره یا نه، و موضوعش چیه.
هیچ یافتهای دو بار نمیاد
لینکهایی که قبلاً تحویل داده شدن کنار میرن و هر رشتهتوییت (thread) یه واحد حساب میشه؛ پستی که هم از جستوجوی موضوعی پیدا بشه هم از جستوجوی حسابها، فقط یه بار توی گزارش میاد.
گزارشی که بشه چکش کرد
هر نتیجه یه خلاصهٔ حداکثر ۲۰۰ کاراکتری داره، دو سه جمله دربارهٔ اینکه چرا مهمه، و متن اصلی با لینکش؛ خواننده قبل از هر تصمیمی میتونه منبع رو ببینه.
تستپذیر و مقاوم در برابر خطای API
منبعهای داده پشت یه interface کوچیک به سبک ports-and-adapters هستن و یه نسخهٔ mock هم دارن؛ برای همین کل مسیر بدون شبکه تست میشه. لایههای retry و cache هم نمیذارن یه خطای موقتی API اجرای روزانه رو خراب کنه.
نتیجه
- یه گزارش روزانه با لینک منبع جای جستوجوهای دستی و تکراری بین دستهها، آدمها و کامیونیتیها رو گرفت.
- سؤالهای مشخص دربارهٔ یه موضوع، چند حساب خاص یا فالوئرهاشون هر وقت لازم بود جواب داده میشد، نه با گشتن دستی.
- هر نتیجه فقط یه کلیک با منبع اصلیش فاصله داشت؛ قبل از هر تصمیمی میشد چکش کرد.