اگر به یک عامل هوش مصنوعی اجازه دهید فایلهای شما را مدیریت کند، باید مطمئن باشید که در مسیر بهینهسازی، کل کتابخانهتان را پاک نمیکند. حقیقت این است که کد قطعی (Deterministic Code) باید مالک هر اقدام جبرانناپذیری باشد تا امنیت دادههای شما تضمین شود. این درس اصلی معماری از پروژه مدیاری اسکات (Mediary Scout) است؛ یک عامل مدیریت کتابخانه رسانهای خود-میزبان که مدیریت اکتساب ذخیرهسازی ابری را با تفکیک «پیشنهاد» از «اجرا» انجام میدهد.
ساخت عاملهایی که با دنیای واقعی تعامل دارند، اغلب شبیه به قمار است. اکثر توسعهدهندگان سعی میکنند رفتارهای نامنظم یا غیرقابل پیشبینی مدل را با پرامپتهای پیچیده و بهتر اصلاح کنند، اما پرامپتها ماهیتاً احتمالی (Probabilistic) هستند. با تکیه بر منطق بهینهسازی منابع — مشابه روشی که Oxlo.ai با بهینهسازی پهنای باند حافظه، مصرف انرژی را کاهش میدهد — توسعهدهنده مدیاری اسکات دریافت که کارایی و امنیت را نمیتوان از مدل «درخواست» کرد؛ بلکه آنها باید به صورت سختافزاری یا نرمافزاری در لایهی کد تثبیت شوند.
معماری شعاع تخریب
مدیاری اسکات از تمایل به داشتن کتابخانه رسانهای متولد شد که شکاف میان «آنچه باید وجود داشته باشد» و «آنچه در واقعیت هست» را درک کند. در حالی که برخی ابزارها در جستوجو عالی هستند اما داراییها را ردیابی نمیکنند، برخی دیگر فایلها را جابهجا کرده و موفقیت عملیات را فرض میکنند. این قابلیتهای جستوجوی پیشرفته و خودکار در مدلهای جدیدتر نیز دیده میشود؛ برای مثال گوگل با اتوماسیون Gemini 2.5 Flash امکان جستوجوهای چندگانه و پیچیده در پایگاههای داده را فراهم کرده است. مدیاری اسکات دقیقاً روی همین شکاف عمل میکند: شما نام یک فیلم یا سریال را میگویید، یک عامل LLM ایندکسها را جستوجو میکند، بهترین مورد تطبیقیافته را به یک درایو ابری منتقل میکند و سپس مجدداً درایو را میخواند تا تأیید کند چه چیزی واقعاً در آنجا قرار گرفته است.
این سیستم برای حاکمیت کامل کاربر طراحی شده است. کاربران درایو ابری خود، مدل LLM مورد نظر و کلید متادیتای شخصی خود را به سیستم میآورند. این برنامه در قالب بیلدهای دسکتاپ برای مک و ویندوز جهت استفاده فوری در دسترس است، یا به صورت یک دموی فقط-خواندنی برای کسانی که میخواهند ابتدا روند یک اکتساب را تماشا کنند، ارائه شده است. در حال حاضر، این سیستم با ارائهدهندگان ذخیرهسازی ابری چینی مانند 115، Quark و GuangYaPan ارتباط برقرار میکند.
سازوکار عملیاتی سیستم
برنامه وب در این معماری نقش بسیار کمی در کارهای سنگین دارد. نقش اصلی آن تنها نوشتن یک ردیف در صف Postgres و بازگشت است.
از آنجا به بعد، یک Worker با مدت زمان اجرای طولانی، ردیف صف را برداشته و یک عامل ایزوله (Sandboxed Agent) را مقداردهی اولیه میکند. به این عامل مجموعهای خاص و محدود از ابزارها اعطا میشود:
- جستوجوی منابع (Search resources)
- انتقال یک کاندیدا (Transfer a candidate)
- لیست کردن یک دایرکتوری (List a directory)
- انتقال فایلها به یک پوشهی فصل (Move files into a season folder)
- علامتگذاری قسمتها به عنوان دریافتی (Mark episodes as obtained)
هر ابزار از یک گردشِ کار قطعی عبور میکند که مالک واقعی اثر جانبی (Side Effect) است. عامل یک اقدام را «پیشنهاد» میکند؛ لایهی قطعی تصمیم میگیرد که آیا این پیشنهاد مجاز است یا خیر، اقدام را انجام میدهد و سپس وضعیت جهان واقعی را بازمیخواند. این تفکیک تضمین میکند که مدل — که تنها بخشی است که توسعهدهنده نمیتواند بهطور کامل پیشبینی کند — کوچکترین شعاع تخریب (Blast Radius) ممکن را داشته باشد.
شکست اول: توهم تسلط بر پرامپت
به نقل از گزارش توسعهدهنده در dev.to، اولین شکست بزرگ زمانی رخ داد که عامل «بیش از حد دقیق» شد. وقتی عامل ماموریت یافت یک فصل ۱۲ قسمتی را جمعآوری کند (که در حالت بهینه حداکثر به یک بستهی کامل و خوب نیاز دارد)، تصمیم گرفت این نیاز را با ۱۱ بستهی متداخل از فصل پوشش دهد. برای رسیدن به این تصمیم، مدل ۱۶ جستوجوی مجزا را اجرا کرد.
در یک مرحله از برنامهریزی، مدل ۶.۸ دقیقه در حلقهی پردازش میماند. سپس حلقهی انتقال تلاش کرد تا هر ۱۱ بسته را پیش از آنکه هرگونه عملیات حذف تکراری (Deduplication) اجرا شود، دریافت کند. از آنجایی که سرویس 115 برای جلوگیری از این نوع فشار به API، یک بودجهی عملیاتی دارد، این اجرا با خطای PAN115_RATE_LIMIT مواجه شد و متوقف گشت. کل فرآیند اکتساب شکست خورد چون عامل سعی داشت جامع و کامل باشد.
در ابتدا، پرامپت توسعهدهنده شامل جملهای بود که میگفت تداخل فایلها ایمن است زیرا مرحلهای در آینده آنها را حذف تکراری میکند. این یک «دروغ» بود؛ زیرا عملیات حذف تکراری بعد از انتقالاتی اجرا میشد که پیش از آن بودجه API را تمام کرده بودند. پاکسازی وعده داده شده هرگز اتفاق نیفتاد.
تغییر کلمات پرامپت برای درخواست «خویشتنداری» شکست خورد؛ زیرا درخواست از یک مدل برای اقتصادی بودن، به اندازه درخواست از آب برای اینکه کمتر خیس باشد، بیاثر است. راهکار تنها در کد قطعی نهفته بود:
- تابع
trimToMinimalCoveringCandidates: یک تابع مجموعه-پوشش حریص (Greedy Set-Cover) که کمترین تعداد بستههای مورد نیاز برای پوشش هر قسمت خواسته شده را محاسبه کرده و بقیه را پیش از شروع انتقالات حذف میکند. - دروازه جستوجو (Search Gating): یک سقف سخت، تعداد جستوجوهای متمایز را به ۸ مورد محدود کرد و پرسوجوهای یکسان را در مرز ابزار حذف تکراری میکند. اگر مدل ۱۶ جستوجو بخواهد، تنها ۸ مورد دریافت میکند و پرسوجوهای تکراری، اسنپشاتهای حافظه موقت (Cached) را برمیگردانند.
شکست دوم: توهم حقیقت
دومین باگ حول محور «پوشش» (Coverage) بود — یعنی این پرسش که کاربر واقعاً کدام قسمتها را در اختیار دارد. توسعهدهنده ابتدا سعی کرد این موضوع را به صورت مکانیکی و خودکار با سه روش انجام دهد که همگی شکست خوردند:
۱. یک بازخوانی مجدد که بعد از علامتگذاری، درایو را برای «تأیید» حضور فایل چک میکرد.
۲. یک تجزیهکننده نام فایل (Filename Parser) که سعی میکرد شماره قسمتها را از روی عناوین حدس بزند.
۳. یک بررسی که اگر دایرکتوری حاوی هرگونه فایل ویدئویی بود، فیلم را به عنوان «دریافتی» علامت میزد.
هر یک از این رویکردها، قضاوت عامل را با یک حدس مکانیکی جایگزین میکرد. در نهایت یک نظم سختگیرانه ایجاد شد: عامل تنها پس از اینکه فایلها را منتقل کرده و به صورت تخت (Flatten) در جای خود قرار داده است، با بازرسی فایلهای واقعی دربارهی پوشش تصمیم میگیرد. سپس عامل در یک بیانیه ساده، بدون استفاده از IDهای فایل یا بازخوانیهای پنهان، اعلام میکند چه قسمتهایی را دریافت کرده است. سیستم این بیانیه را ثبت کرده و به مرحله بعد میرود.
این روند یک سیستم حسابداری دقیق ایجاد میکند که در آن مجموعه گمشده، حاصل تفریق دو مقدار است: هر آنچه عامل علامت زده در مقابل هر آنچه متادیتای رسمی میگوید پخش شده است. یک بررسی زمانبندی شده (Scheduled Sweep) تنها زمانی عامل را فعال میکند که این تفریق نشان دهد سریالها ناقص هستند. این یعنی هزاران سریال تکمیل شده هرگز اسکن نمیشوند، زیرا چیزی برای اسکن کردن باقی نمانده است.
شکست سوم: تلهی نمادین (Proxy Trap)
آخرین درس مربوط به یک باگ رابط کاربری (UI) بود که در آن نوار پیشرفت در حین اکتسابها خالی نمایش داده میشد، با وجود اینکه منطق برنامه پیشرفت را گزارش میکرد. این موضوع منجر به سه درخواست تغییر کد (PR) شکستخورده شد:
- PR 1: توسعهدهنده ریاضیات مربوط به نگاشت فاز نوار را اصلاح کرد. نوار همچنان خالی ماند.
- PR 2: چون یک جستوجو ۹۴ ثانیه از یک اجرای ۳ دقیقهای را میگرفت، نوار بین رویدادها یخ میزد. توسعهدهنده یک انیمیشن تدریجی در سمت کلاینت اضافه کرد تا بین آپدیتهای سرور حرکت داشته باشد. نوار باز هم خالی به نظر میرسید.
- PR 3: علت ریشهای کشف شد. بخش پرشونده نوار یک عنصر
<span>بود. از آنجایی که مقدار پیشفرض اسپانهاdisplay: inlineاست، ویژگیwidthهیچ اثری روی باکس نداشت و باعث میشد عرض آن به صفر پیکسل برسد.
در طول دو PR اول، توسعهدهنده با خواندن style.width (که مقادیر ۵٪، ۲۱٪ و ۳۴٪ را نشان میداد) شکست را «تأیید» میکرد، به جای اینکه پیکسلهای واقعی را چک کند. در حالی که style.width درست بود، اما تابع getBoundingClientRect() عرض صفر را گزارش میکرد. توسعهدهنده به یک «نمایاند» یا پروکسی — یعنی رشتهای در یک ویژگی استایل — اعتماد کرده بود، نه به مصنوعاتی که کاربر واقعاً میبیند.
چارچوب قطعی (Deterministic Framework)
طبق گزارش dev.to که در ۷ جولای ۲۰۲۶ منتشر شد، الگوی موفق برای قابلیت اطمینان عاملها، یک «هسته احتمالی» است که توسط «لولهکشی قطعی» احاطه شده باشد. این رویکرد سختگیرانه برای مدیریت دادهها یادآور راهکاری است که پروژه Lethe با حذف سخت دادههای منسوخ به کار میبرد تا توهمات حافظه در مدلها را بهطور کلی از بین ببرد. عامل در مدیاری اسکات عمداً کوچک نگه داشته شده است: او میخواند و انتخاب میکند، اما نمیتواند تصمیم بگیرد اجرایی به پایان رسیده است، نمیتواند پوشش را جعل کند، نمیتواند از بودجه جستوجو فراتر رود و نمیتواند به دایرکتوریهای خارج از محیط ایزولهاش دسترسی داشته باشد.
نکات کلیدی برای ساخت عاملهای قابل اعتماد:
- هسته احتمالی (Probabilistic Core): از LLM برای قضاوتهای پیچیده دنیای واقعی و انتخاب از بین نتایج استفاده کنید.
- لولهکشی قطعی (Deterministic Plumbing): مالک هر اقدام جبرانناپذیر را در کدی قرار دهید که مدل نتواند با آن بحث کند.
- دروازه سخت (Hard Gating): برای هر عددی که مدل تولید میکند (تعداد، فراخوانیها، جستوجوها)، یک سقف قطعی تعیین کنید.
- تأیید واقعی (Real-World Verification): وضعیت را بر اساس حالت واقعی جهان بسنجید، نه بر اساس روایت مدل از آن.
از آنجایی که این محدودیتها در کدی زندگی میکنند که مدل هرگز نمیبیند، غافلگیریها «ارزان» و قابل بازیابی میشوند. برای کسانی که به دنبال توسعه هستند، لایهی درایو یک پلاگین مستقل در پشت یک رجیستری برند (شامل یک کلاینت و یک مجری انتقال) است. در حالی که در حال حاضر از Quark و GuangYaPan پشتیبانی میکند، افزودن پشتیبانی از Google Drive یا Dropbox به دلیل این مرزهای تمیز، یک وظیفه محدود است و نه یک جراحی پیچیده در کد.
اگر در حال ساخت عاملهایی هستید که حذف یا انتقال فایل در دنیای واقعی را انجام میدهند، نتیجه روشن است: به مدل اعتماد نکنید که خودش را محدود کند، و به مرحلهای در آینده اعتماد نکنید که آشفتگیها را پاک کند. دروازه را بین مدل و اقدام قرار دهید. این پروژه در github.com/fancydirty/mediary-scout به صورت متنباز در دسترس است، با دموی زنده در demo.mediaryscout.app و نسخههای دسکتاپ در mediaryscout.app.
گام بعدی شما
- اگر در حال ساخت عاملهای خودکار هستید، هر عملیاتی که قابل بازگشت نیست (مانند حذف یا انتقال فایل) را از دسترس مستقیم LLM خارج کرده و به یک لایه تاییدیه کد منتقل کنید.
- برای کنترل هزینهها و نرخ خطا، سقفهای عددی (Hard Gating) را برای تعداد درخواستهای API مدل تعریف کنید.
- هرگز به گزارش مدل از وضعیت سیستم اعتماد نکنید؛ همیشه بعد از عملیات، وضعیت واقعی دیسک یا پایگاه داده را بازخوانی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو