تصور کنید هزینه یک پاسخ اشتباه در نظارت دریایی چقدر باشد: یک کشتی گشت که به دلیل اطلاعات غلط، کیلومترها از مسیر خارج شود، جان کارکنان را به خطر اندازد و منابع حیاتی و محدودی را که همین حالا هم تحت فشار هستند، تلف کند. برای جلوگیری از چنین شکست‌هایی، مؤسسه Ai2 عامل Shippy را توسعه داد. این یک عامل هوش مصنوعی است که برای محیط‌های حساس پلتفرم Skylight (پلتفرم آگاهی از دامنه دریایی) طراحی شده است، همان‌طور که در گزارش ۱۵ جولای ۲۰۲۶ به تفصیل آمده است.
ساخت یک عامل هوش مصنوعی برای اقیانوس‌ها، بیش از هر چیز، مسئلهٔ قابلیت اطمینان (Reliability) است. برخلاف چت‌بات‌های عمومی که با داده‌های ایستا کار می‌کنند، Shippy باید با سیگنال‌های زنده ماهواره‌ای و داده‌های کشتی‌ها تعامل کند که به‌طور مداوم به‌روزرسانی می‌شوند و یک تصویر ثابت نیستند. این سیستم به‌گونه‌ای طراحی شده است تا از «توهمات» (Hallucinations) رایج در مدل‌های زبانی بزرگ (LLM) جلوگیری کند. این کار از طریق محدود کردن نحوه دسترسی عامل به داده‌ها و اطمینان از اینکه هر پاسخ قابل راستی‌آزمایی است، محقق شده است. این رویکرد در راستای تحولی گسترده‌تر در طراحی سیستم‌های هوشمند است که در آن عامل‌های چندنفره و همکاری‌های پیچیده جایگزین بات‌های تک‌کاربره در مدیریت دانش سازمانی شده‌اند تا دقت و کارایی عملیاتی افزایش یابد.
کالبدشناسی یک عامل (The Anatomy of an Agent)
مؤسسه Ai2 معماری Shippy را در سه لایه متمایز تعریف می‌کند: روح، مهارت‌ها و پیکربندی. این ساختار باعث می‌شود هویت عامل از قابلیت‌های او و محیط فنی‌اش کاملاً جدا شود.
- روح (The Soul): یک پرامپت سیستمی است که شخصیت (Persona) و مرزهای رفتاری Shippy را تعریف می‌کند. در این لایه صراحتاً از عامل خواسته شده که از هرگونه تصمیم‌گیری حقوقی در مورد اینکه آیا یک کشتی در حال قانون‌شکنی است یا خیر، خودداری کند؛ با این تأکید که چنین تصمیماتی بر عهده انسان‌هاست، نه عامل‌های هوش مصنوعی. همچنین، این لایه مانع از هرگونه گمانه‌زنی فراتر از آنچه داده‌ها پشتیبانی می‌کنند می‌شود. این مرزها به‌جای اینکه به‌صورت ضمنی در فرآیند Fine-tuning قرار گیرند، به‌طور صریح در پرامپت نوشته شده‌اند تا قابل بازرسی (Auditable) و به‌راحتی قابل ویرایش باشند.
- مهارت‌ها (Skills): فایل‌های Markdown ماژولاری هستند که دارای «frontmatter» ساختاریافته‌اند و به عامل دستور می‌دهند که چگونه درخواست‌های خاص را مدیریت کند. این فرمت از همان مشخصات (Spec) مهارت-عامل پیروی می‌کند که در ابزارهایی مانند Claude Code و Codex استفاده می‌شود و باعث می‌شود هر مهارت دارای نسخه (Versioned) و قابل درک باشد.
- پیکربندی (Config): تنظیمات زمان اجرا (Runtime) هستند که چارچوب میزبان عامل (OpenClaw، یک فریم‌ورک متن‌باز) و مدل زیربنایی (Claude Opus 4.6) را مشخص می‌کنند. اسرار سیستم مانند کلیدهای API در زمان اجرا تزریق می‌شوند. این معماری به تیم اجازه می‌دهد تا مدل‌ها یا چارچوب‌ها را تنها با تغییر در پیکربندی و بدون نیاز به بازسازی کامل سیستم (Full Rebuild)، تعویض کنند.
جزئیات مهارت‌های عامل
مهارت‌های Shippy او را قادر می‌سازد تا پرس‌وجوهای پیچیده و چندمرحله‌ای را تنها در یک نوبت گفتگو (Dialogue Turn) حل کند. مجموعه مهارت‌های فعلی او شامل موارد زیر است:
- پرس‌وجوی API Skylight: برای بازیابی داده‌های کشتی‌ها و «رویدادها» (Events). رویدادها رفتارهای خاصی هستند که توسط Skylight شناسایی می‌شوند، مانند صیادی غیرقانونی یا انتقال کالا (Transshipment) بین دو کشتی.
- جستجوی مرزها: بازیابی مرزهای مناطق اقتصادی انحصاری (EEZ) و مناطق حفاظت‌شده دریایی (MPA).
- تفسیر مسیر (Track Interpretation): تحلیل سیگنال‌های موقعیت و حرکت (داده‌های مسیر کشتی) با تکیه بر طبقه‌بندی‌های فعالیتی که توسط مدل‌های Skylight، از جمله مدل Atlantes، تولید شده‌اند.
- تولید نقشه تعاملی: ایجاد لینک‌های عمیق (Deep links) که به تحلیلگر اجازه می‌دهد از یک پاسخ متنی در چت، مستقیماً به مکان دقیق روی نقشه Skylight برای تأیید اطلاعات بپرد.
به عنوان مثال، اگر کاربر بپرسد «فعالیت‌های صیادی در منطقه اقتصادی انحصاری پاناما در ماه گذشته را نشان بده»، عامل مختصات را حدس نمی‌زند. در عوض، دستورالعمل‌های مهارت، Shippy را هدایت می‌کند تا ابتدا عبارت «Panama EEZ» را از طریق API مناطق Skylight به یک چندضلعی مرزی (Boundary Polygon) تبدیل کند. سپس، رویدادهای صیادی را در آن هندسه جستجو کرده و متادیتای کشتی‌ها را از شرکایی مانند Global Fishing Watch یا TMT استخراج می‌کند.
سایر پرس‌وجوها می‌توانند چندین مهارت را به‌طور هم‌زمان فعال کنند. سؤالی مانند «آیا کشتی‌هایی در نزدیکی منطقه حفاظت‌شده Cordillera de Coiba فعالیت می‌کنند؟» هم‌زمان از مهارت پرس‌وجوی داده‌های Skylight، پایگاه داده ProtectedSeas برای درک زمینه مرز MPA، و مهارت مسیر کشتی برای تفسیر رفتار آن‌ها استفاده می‌کند.
ابزارهای قطعی برای مدل‌های غیرقطعی
عامل‌ها به‌طور ذاتی غیرقطعی (Nondeterministic) هستند، اما Ai2 استدلال می‌کند که اگرچه نمی‌توان تصمیمات یک مدل را کاملاً کنترل کرد، اما می‌توان ابزارهایی که مدل به سراغ آن‌ها می‌رود را پیش‌بینی‌پذیر کرد. برای دستیابی به این هدف، Shippy به‌جای ارسال فراخوانی‌های خام API، از طریق یک رابط خط فرمان (CLI) که مخصوص این کار ساخته شده، با Skylight تعامل می‌کند.
در نمونه‌های اولیه، Shippy فراخوانی‌های API را از ابتدا می‌ساخت. این روش منجر به جریان مداومی از باگ‌های ظریف شد: صفحه‌بندی‌های (Pagination) ناقص که باعث حذف بی‌صدای نتایج می‌شد، خطاهای کدگذاری هندسی، و پرس‌وجوهایی که به دلیل درک نادرست از انواع فیلترها، داده‌های غلط بازمی‌گرداندند. APIهای Skylight پیچیدگی زیادی دارند و شامل ده‌ها نوع ورودی، اشیاء فیلتر تودرتو و نشانگرهای صفحه‌بندی (Cursors) هستند.
CLI جدید این پیچیدگی را متراکم می‌کند. Shippy تنها یک دستور صادر می‌کند — مثلاً skylight events search با فلگ‌های فیلتر تایپ‌شده — و CLI مسئولیت احراز هویت، صفحه‌بندی و ساختاردهی خروجی را بر عهده می‌گیرد. این CLI دارای خود-مستندسازی است و از متون گسترده --help و پیام‌های خطای دقیق استفاده می‌کند تا به عامل کمک کند بدون حدس زدن، از اشتباهات خود بازیابی شود.
برای تضمین پایداری، CLI خروجی را به‌جای انتقال از طریق شل (Pipe)، در یک فایل JSON محلی می‌نویسد. این کار مانع از آن می‌شود که مجموعه‌های بزرگ نتایج با محدودیت‌های بافر لوله (Pipe buffer) برخورد کنند یا ابزارهایی مانند jq را مختل کنند. همچنین به عامل اجازه می‌دهد در مراحل بعدی به‌صورت برنامه‌ریزی‌شده به نتایج دسترسی داشته باشد.
در لایه‌های زیرین، یک API استاندارد وجود دارد که در آن انواع منابع — شامل کشتی‌ها، رویدادهای Skylight، مناطق، تصاویر ماهواره‌ای و مسیرهای کشتی — از طریق یک جفت عملیات مشترک یعنی search و aggregate قابل دسترسی هستند. این‌ها به عنوان طرح‌واره‌های تایپ‌شده (Typed Schemas) با توضیحات در سطح فیلد تعریف شده‌اند. این لایه‌بندی به این معناست که API، CLI و مهارت‌ها همگی را می‌توان به‌طور مستقل تست کرد.
امنیت از طریق Mothership
پلتفرم Skylight به صدها سازمان دولتی و سازمان غیردولتی در بیش از ۷۰ کشور خدمات می‌دهد. از آنج که یک افسر شیلات در فیلیپین، مناطق مورد علاقه (AOI) و لیست‌های نظارت بر کشتی‌های خاص خود را دارد، ایزولاسیون داده‌ها الزامی است.
مؤسسه Ai2 پلتفرم Mothership را توسعه داد؛ یک پلتفرم میزبان عامل که برای هر جلسه (Session) کاربر، یک استقرار اختصاصی در Kubernetes ایجاد می‌کند. این امر تضمین می‌کند که تاریخچه گفتگو و داده‌های یک کاربر هرگز برای هیچ‌کس دیگر قابل مشاهده نباشد.
هر جلسه یک محیط ایزوله (Sandbox) موقت ایجاد می‌کند که شامل موارد زیر است:
- Runtime عامل
- مهارت‌های مورد نیاز
- CLI اختصاصی Skylight
توکن وب JSON (JWT) مخصوص کاربر در زمان ایجاد محیط تزریق می‌شود تا اطمینان حاصل شود که تمام فراخوانی‌های API محدود به داده‌های آن کاربر است. در داخل این Sandbox، عامل می‌تواند کد بنویسد و اجرا کند، وابستگی‌ها (Dependencies) را نصب نماید و مجموعه‌داده‌ها را برای تحلیل‌های چندمرحله‌ای فراخوانی کند. در سطح شبکه، دسترسی Sandbox اکیداً به خدماتی که نیاز دارد محدود شده است.
ارزیابی کل سیستم
مؤسسه Ai2 از بنچمارک‌های استاتیک فاصله گرفت، زیرا این بنچمارک‌ها نمی‌توانند نحوه انتخاب ابزار توسط عامل یا واکنش او به داده‌های زنده را ثبت کنند. در عوض، آن‌ها یک چارچوب ارزیابی ساختند که عامل، مدل و Sandbox را به‌عنوان یک واحد واحد با استفاده از Harbor (یک چارچوب ارزیابی متن‌باز) امتیازدهی می‌کند.
متخصصان موضوعی (SME)، سناریوها و معیارهای ارزیابی (Rubrics) را می‌نویسند و بر اساس اولویت هر وظیفه، وزن‌های متفاوتی تعیین می‌کنند. برای یک پرس‌وجوی مربوط به رویدادهای صیادی، وزن‌دهی به این صورت است:
- بیشترین وزن: دقت داده‌ها (Data Accuracy)
- وزن متوسط: تشخیص مرز و بازه زمانی
- کمترین وزن: ارجاع به منابع و سبک پاسخ‌دهی
متخصصان همچنین پاسخ‌ها را به‌عنوان «درست» یا «غلط» علامت‌گذاری می‌کنند تا حقیقت زمینی (Ground Truth) فراهم شود. این خط لوله شامل یک پرامپت زبان طبیعی است که در Sandbox اجرا می‌شود و سپس یک داور LLM هر معیار را از ۰ تا ۱ همراه با استدلال مکتوب رتبه‌بندی می‌کند. سپس مجموع وزنی محاسبه شده و با یک آستانه قبولی (Pass Threshold) ثابت چک می‌شود.
آن‌ها یک پلاگین تخصصی برای Harbor نوشتند تا جلسات واقعی Shippy را در همان نسخه‌ای که تست می‌شود، روی داده‌های واقعی اجرا کند. این مجموعه آزمون‌ها به‌صورت موازی اجرا شده و نتایجی دارای برچسب زمانی تولید می‌کند. اگر نسخه‌ای در این معیارها دچار افت (Regression) شود، هرگز به دست کاربران نهایی نمی‌رسد.
اجراهای اخیر نشان می‌دهد که Shippy به‌طور مداوم در بازیابی داده‌ها و رعایت حفاظ‌ها (Guardrails) — مانند رد کردن صحیح درخواست‌های مربوط به اطلاعات نظامی — موفق است. با این حال، الگوهای شکست در موارد زیر شناسایی شده است:
- برنامه‌ریزی گشت (Patrol Planning): گاهی Shippy به‌جای ارائه پشتیبانی تصمیم‌ساز، وارد حوزه توصیه‌های تاکتیکی می‌شد.
- پرس‌وجوهای هندسی: ساده‌سازی مرزها گاهی باعث می‌شد عامل برخی رویدادهای خاص را نادیده بگیرد.
- استفاده از CLI: در یک مورد، عامل دستوری را ابداع کرد که در واقع در CLI وجود نداشت.
مسیر رسیدن به رابط کاربری عاملی (Agentic UI)
مؤسسه Ai2 اکنون در حال انتقال Shippy از یک دستیار متنی به یک کنترل‌کننده رابط کاربری (UI Controller) است. به‌روزرسانی‌های آینده به Shippy اجازه می‌دهد مستقیماً نقشه Skylight را هدایت کند؛ به این معنا که بتواند به‌طور خودمختار به یک منطقه برود، فیلترها را اعمال کند و بازه‌های زمانی را تنظیم کند.
تیم همچنین در حال پیاده‌سازی «مسیریابی مدل» (Model Routing) برای بهبود کارایی است؛ به‌گونه‌ای که جستجوهای ساده به مدل‌های کوچک‌تر و سریع‌تر ارسال شود و مدل Claude Opus 4.6 برای تحقیقات پیچیده رزرو گردد. در نهایت، «حافظه بین-رشته‌ای» (Cross-thread memory) به Shippy اجازه می‌دهد صلاحیت قضایی خاص یک تحلیلگر یا منابع مورد علاقه او را به خاطر بسپارد تا کاربر مجبور نباشد در هر گفتگو دوباره منطقه اقتصادی انحصاری (EEZ) خود را تعریف کند.
این رویکرد معماری اکنون در سایر پروژه‌های Ai2 از جمله EarthRanger برای حفاظت از حیات وحش و OlmoEarth برای ابزارهای متن‌باز مشاهده زمین به کار می‌رود. پلتفرم Mothership به‌گونه‌ای طراحی شده است که هدف کلی داشته باشد تا بتواند میزبان این عامل‌های دیگر نیز باشد.
آنچه این دستاورد برای این حوزه به معنا دارد، تغییر رویکرد از «مهندسی پرامپت» به «مهندسی سیستم» است. با محصور کردن یک مدل غیرقطعی در یک CLI قطعی و یک Sandbox امن، Ai2 نقشه‌راهی برای استقرار عامل‌ها در دامنه‌هایی ایجاد کرده است که در آن نرخ خطای حتی ۱٪ نیز غیرقابل قبول است.
گفتگو