عامل‌های هوش مصنوعی با WhaleHarness ابزارهای خود را می‌سازند و منتشر می‌کنند

تصور کنید یک عامل هوش مصنوعی به جای اینکه منتظر بماند تا یک برنامه‌نویس برایش ابزار بسازد، خودش کد بزند، آن را تست کند و در یک فروشگاه عمومی منتشر کند. این سناریو دیگر تخیلی نیست؛ عاملی به نام 屿 (Yǔ) اخیراً دو افزونه به نام‌های whale-store و whale-shot را بدون هیچ دخالت انسانی طراحی و عرضه کرده است. این کدها بدون اینکه حتی یک انسان آن‌ها را لمس کند، به فروشگاه عمومی ارسال شده‌اند.

این دستاورد از طریق WhaleHarness ممکن شده است؛ یک فروشگاه افزونه برای DeepSeek Harness (DSH) که از یک خط لوله (Pipeline) خودکار برای تأیید و استقرار ابزارهای ساخته‌شده توسط عامل‌ها استفاده می‌کند. در واقع، ما از مرحله‌ای که عامل‌ها صرفاً مصرف‌کننده ابزار بودند، به مرحله‌ای رسیده‌ایم که آن‌ها به مشارکت‌کنندگان فعال در اکوسیستم خود تبدیل شده‌اند. این تحول در واقع تکامل یافته‌ی رویکرد جدید DeepSeek برای توسعهٔ عامل‌های هوشمند است که بر پایه پلاگین‌های قابل تعویض بنا شده بود. در چشم‌انداز فعلی هوش مصنوعی عامل‌محور (Agentic AI)، اکثر ابزارها توسط توسعه‌دهندگان به صورت سخت‌افزاری (Hard-coded) نوشته می‌شوند. WhaleHarness این وضعیت را تغییر می‌دهد و با افزونه‌ها به عنوان بسته‌های استاندارد npm برخورد می‌کند که از یک قرارداد سخت‌گیرانه و مکانیکی پیروی می‌کنند.

همان‌طور که در بحث‌های گذشته ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اجازه دادن به مدل‌ها برای نوشتن و اجرای کد، ریسک‌های امنیتی بزرگی دارد. به همین دلیل WhaleHarness افزونه‌ها را به عنوان بسته‌های استاندارد npm می‌بیند که باید از یک قرارداد سخت‌گیرانه و مکانیکی پیروی کنند.

زمینه: افزونه DSH چیست؟

DeepSeek Harness در واقع یک لانچر برای پروفایل‌های عامل است که از دسته‌های افزونه cordis استفاده می‌کند. این ساختار در واقع بخشی از معماری مدیریت قابلیت‌های قابل تعویض در عامل‌های AI است که اجازه می‌دهد مقیاس‌پذیری سیستم افزایش یابد. طبق مستندات فنی، یک افزونه در اینجا یک برنامه پیچیده، یک دیمون (Daemon) یا یک اپلیکیشن وابسته به اعتبارنامه‌های حساس نیست، بلکه یک بسته npm ساده است که یک وصله (Patch) را تحت کلید dsh.bundle تعریف می‌کند. این ساختار به عامل اجازه می‌دهد تا ابزار خود را از طریق یک فرآیند ساده و قابل مشاهده به هارنس ثبت کند.

قرارداد سه-فایلی افزونه‌ها

به نقل از یک راهنمای فنی در dev.to که در ۲۳ اوت ۲۰۲۶ منتشر شد، هر افزونه DSH از سه فایل کوچک تشکیل شده که در مجموع حدود ۵۰ خط کد دارند. برای مثال، افزونه whale-breathe (که اولین افزونه جامعه در این فروشگاه است و توسط نویسنده‌ای به نام kwawa تحت لایسنس MIT منتشر شده) ساختار زیر را دنبال می‌کند:

• package.json: فایل تعریف که شامل کلید dsh.bundle.patch است که به فایل وصله اشاره می‌کند. نکته حیاتی این است که در بخش peerDependencies فقط می‌توان بسته‌های رسمی @deepseek-ai/* را لیست کرد (مثلاً @deepseek-ai/dsh-tools: ^0.1.0-rc.6).
• cordis.patch.yml: نقطه ورود که طبق یک قانون مکانیکی سخت، فقط می‌تواند شناسه (ID) خود افزونه را درج کند (مثلاً id: whale-breathe).
• lib/index.js: منطق اصلی ابزار. این فایل با استفاده از یک فراخوانی defineTool نام، توضیحات، پارامترها (مانند یک عدد برای دقایق) و یک طرح خروجی (Output Schema) را تعیین می‌کند. این فایل باید شامل یک تابع apply(ctx) باشد که ctx.tools.register(tool) را فراخوانی کند و همچنین باید خروجی‌های نام‌گذاری شده برای apply ،inject و name ارائه دهد.

خط لوله تأیید با رویکرد «اعتماد صفر»

برای جلوگیری از ورود کدهای مخرب به فروشگاه، WhaleHarness از یک سیستم وتوی «خط قرمز» استفاده می‌کند که جزئیات آن در فایل‌های zero-trust.html و agent.json آمده است. هرگونه ارسال که موارد زیر را امتحان کند، به طور خودکار رد می‌شود:

• استخراج داده (Network exfiltration): هرگونه تلاش برای ارسال داده به خارج از محیط ایزوله (Sandbox).
• اجرای کد پویا: استفاده از توابعی مثل eval یا child_process ممنوع است.
• سرقت اعتبارنامه‌ها: خواندن اسرار (Secrets)، کلیدها یا مسیرهای حساس سیستم.
• جعل منشأ (Provenance fraud): جعل هویت فروشگاه یا دروغ گفتن درباره عملکرد واقعی افزونه.

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

از ارسال تا ویترین فروشگاه

ارسال افزونه‌ها از طریق درخواست‌های HTTP PUT عمومی انجام می‌شود (مثلاً با دستور curl -T my-plugin-0.1.0.tgz https://whaleharness.com/submit/...). فایل ارسالی باید با فرمت .tgz یا .tar.gz و با حجمی کمتر از ۵ مگابایت باشد و سطح بالای آن باید پوشه package/ باشد.

سپس خط لوله یک چرخه چهارمرحله‌ای را اجرا می‌کند که توصیه می‌شود توسعه‌دهندگان خودشان نیز آن را اجرا کنند:
۱. ایجاد DSH_HOME تازه: شروع با یک محیط کاملاً پاک.
۲. نصب: اجرای دستور dsh plugin add -w <tarball>.
۳. تخلیه پیکربندی (Configuration Dump): استفاده از dump-config برای اطمینان از اینکه ثبت ابزار قابل مشاهده است.
۴. اجرا: بوت کردن سیستم و انجام یک فراخوانی بدون سر (Headless) برای تأیید اینکه ابزار اجرا شده و مقداری را برمی‌گرداند. اگر مدل نتواند ابزار را فراخوانی کند، افزونه منتشر نخواهد شد.

آمار اکوسیستم و زنجیره حقایق

تا ۲۳ اوت ۲۰۲۶، این فروشگاه ۱۶۵ افزونه را لیست کرده است. بررسی ۱۴۷۱ مخزن کد در این اکوسیستم، وضعیت زیر را نشان می‌دهد (تا ساعت ۰۶:۴۳:۲۳Z):

• ۶۱۱ مورد PASS: تأیید شده و مطابق استاندارد.
• ۴۳۳ مورد FORMAT: رد شده به دلیل مشکلات ساختاری.
• ۱۹۶ مورد RED-LINE: رد شده به دلیل نقض قوانین امنیتی.
• ۲۳۰ مورد: ارزیابی نشده.

در مجموع ۱۱۳۵ نویسنده ثبت شده‌اند. دو افزونه ساخته‌شده توسط عامل‌ها یعنی whale-store (نسخه 0.1.0، دور ۵۸۹) و whale-shot (نسخه 0.1.0، دور ۶۸۱) هر دو از این چرخه سخت‌گیرانه عبور کردند. افزونه whale-store دسترسی خواندنی به plugins.json و دایرکتوری حسابرسی را از طریق توابع whale_store_list ،search و install فراهم می‌کند. افزونه whale-shot از Playwright برای ارائه تصاویر PNG از نمای دسکتاپ و موبایل استفاده می‌کند که پیش از انتشار، روی یک VPS به صورت زنده تأیید شده است.

چرخه بازخورد عامل‌محور

این سازوکار یک چرخه بهبود بازگشتی ایجاد می‌کند. وقتی یک عامل (Agent) — شبیه به کارمندی که متوجه می‌شود ابزار لازم برای انجام کارش را ندارد و خودش می‌رود آن را می‌سازد — احساس کند قابلیتی را کم دارد (مثلاً گرفتن اسکرین‌شات یا گشت‌وگذار در فروشگاه افزونه‌ها)، می‌تواند ابزار را بنویسد، آن را به خط لوله ارسال کند و سپس برای تکمیل مأموریت اصلی‌اش، همان ابزار را نصب کند. این فرآیند در واقع نقطه اوج تبدیل مدل‌های زبانی به کارمندانی برای ویرایش کد است که پیش‌تر بررسی کرده بودیم. زمان معمول برای تکمیل این فرآیند در ۷۲ ساعت است و برای مشکلاتی که مربوط به فرمت است، ارسال‌های مجدد سریع‌تر بررسی می‌شوند.

برای توسعه‌دهندگان، این یعنی گلوگاه توانمندی عامل‌ها دیگر سرعت کدنویسی انسان نیست، بلکه توانایی عامل در پیروی از قرارداد DSH است. نقش انسان از «کدنویس» به «معمار خط لوله» تغییر می‌کند؛ کسی که تمرکزش بر تعریف مرزهای ایمنی است، نه منطق داخلی ابزار.

اگر عاملی دارید که مدام به دلیل نبود یک ابزار خاص شکست می‌خورد، مسیر حل مشکل اکنون مکانیکی است. شما می‌توانید عامل خود را راهنمایی کنید تا ساختار سه-فایلی را دنبال کند، آن را در یک tarball بسته‌بندی کرده و برای تأیید خودکار ارسال کند. برای دیدن اینکه عامل‌ها بیشتر به چه ابزارهایی نیاز پیدا کرده‌اند، می‌توانید رشد لاگ‌های حسابرسی WhaleHarness را دنبال کنید.

گام بعدی شما

• اگر عاملی دارید که مدام به دلیل نبود یک ابزار خاص شکست می‌خورد، ساختار سه-فایلی DSH را به او آموزش دهید.
• خروجی‌های whale-store را بررسی کنید تا ببینید عامل‌ها بیشتر به چه ابزارهایی نیاز پیدا کرده‌اند.
• برای امنیت بیشتر، محیط‌های ایزوله (Sandbox) مشابه WhaleHarness را برای تست کدهای تولیدشده توسط AI پیاده‌سازی کنید.

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