چگونه گیت‌وی‌های قطعی مانع از Overtrading در عامل‌های هوش مصنوعی می‌شوند؟

تصور کنید یک عامل هوش مصنوعی به دلیل یک توهم ساده، کل موجودی حساب بورس شما را روی یک سهم پرریسک خالی کند. برای جلوگیری از این فاجعه، تنها راهکار، ایجاد یک مرز نرم‌افزاری قطعی است که اجازه ندهد مدل‌های زبانی به تنهایی تصمیمگیر نهایی باشند. این ضرورت بنیادین، محرک پیاده‌سازی فنی ۷ اکتبر ۲۰۲۶ بود که جزئیات ساخت یک گیت‌وی ریسک برای Robinhood Trading MCP (پروتکل زمینه مدل) را با استفاده از تایپ‌اسکریپت (TypeScript) برای اعمال محدودیت‌های معاملاتی سخت‌گیرانه تشریح کرد.

در اکثر ادغام‌های فعلی، مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — به عنوان مقام نهایی در استفاده از ابزارها عمل می‌کند. اگر کاربر بخواهد سهمی بخرد، مدل مستقیماً دستور را تولید کرده و آن را به API می‌فرستد. این رویکرد یک شکاف قابلیت اطمینان عظیم ایجاد می‌کند، زیرا LLMها به‌طور ذاتی نمی‌توانند تضمین کنند که یک معامله با یک سیاست ریسک پیچیده و چندمتغیره مطابقت دارد. این چالش در طراحی عامل‌ها، اهمیت قابلیت‌های ارتباطی مدل را دوچندان می‌کند؛ همان‌طور که قابلیت فراخوانی تابع در Gemini مسیر ساخت عامل‌های هوشمند چندمرحله‌ای را هموار کرد تا تعامل با ابزارها ساختاریافته‌تر شود.

برای مثال، سناریویی را تصور کنید که در آن کاربر به عامل می‌گوید «مقدار قابل‌توجهی از این سهم نوسانی را بخر». مدل ممکن است این عبارت را ۵,۰۰۰ دلار تفسیر کند، حتی اگر سیاست ریسک داخلی حساب، سفارش‌های تک‌گانه را به ۱,۰۰۰ دلار محدود کرده باشد. بدون وجود یک گیت‌وی، این معامله اجرا می‌شود. اما با وجود لایه نظارتی، درخواست پیش از آنکه هرگز به کارگزار برسد، رد می‌شود.

معماری کنترل

در این سیستم، نقش عامل هوش مصنوعی از «مجری» به «پیشنهاددهنده» تغییر می‌کند. جریان عملیاتی از یک مسیر خطی سخت‌گیرانه پیروی می‌کند: عامل هوش مصنوعی $ \rightarrow $ Trading MCP $ \rightarrow $ لایه مجوز $ \rightarrow $ گیت‌وی ریسک $ \rightarrow $ تایید سیاست $ \rightarrow $ اجرا $ \rightarrow $ حسابرسی.

این معماری بر چندین لایه مجزا برای تضمین ایمنی استوار است:

• لایه مجوز ابزار: تفکیک ابزارهای «خواندنی» (مانند دریافت داده‌های سبد سهام) از ابزارهای «نوشتنی» (مانند ثبت سفارش). یک عامل پژوهشی ممکن است فقط دسترسی خواندنی داشته باشد، در حالی که یک عامل معاملاتی به مجوزهای صریح نوشتنی نیاز دارد.
• قصد معاملاتی ساختاریافته: سیستم خروجی‌های متنی و آزاد مدل را به یک شیء تایپ‌شده به نام TradeIntent تبدیل می‌کند. این شیء شامل نماد سهم، جهت معامله (خرید/فروش)، نوع سفارش و ارزش اسمی است.
• موتور ریسک: یک سرویس قطعی در تایپ‌اسکریپت که قصد معامله را در برابر یک سیاست ریسک (RiskPolicy) ارزیابی می‌کند.

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

مدل عامل‌های خارجی Robinhood

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

روبین‌هود اتصال برای پلتفرم‌های متنوعی از جمله Claude، ChatGPT، Codex، Cursor، Grok، Perplexity، OpenClaw و Replit را مستند کرده است. یک تمایز طراحی حیاتی در این مدل، استفاده از یک حساب MCP اختصاصی برای معاملات است. در حالی که عامل می‌تواند اطلاعات را از حساب‌های اصلی کاربر در روبین‌هود بخواند، اما معاملات را از طریق این حساب اختصاصی Agentic/MCP اجرا می‌کند.

مجوزهای دقیق ابزار

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

• ابزارهای خواندنی: این‌ها شامل get_accounts ،get_portfolio ،get_watchlists ،get_market_data ،get_positions و get_history هستند.
• ابزارهای نوشتنی: این‌ها شامل place order (ثبت سفارش)، cancel order (لغو سفارش) و modify order (تغییر سفارش) هستند.

مجوزها از طریق یک تایپ به نام AgentPermissions مدل‌سازی می‌شوند که مقادیر بولی (Boolean) را برای readAccount ،readPortfolio ،readMarketData ،proposeTrade ،placeOrder و cancelOrder ردیابی می‌کند. برای مثال، یک عامل پژوهشی به‌گونه‌ای پیکربندی می‌شود که مجوزهای خواندن برای او true باشد اما placeOrder برای او false تنظیم شود.

اعتبارسنجی قصد معاملاتی

سیستم هرگونه خروجی متنی آزاد مدل را رد می‌کند. به جای پذیرفتن جملاتی مثل «بیایید مقدار زیادی از XYZ بخریم چون مومنتوم قوی به نظر می‌رسد»، گیت‌وی یک شیء تایپ‌شده TradeIntent را می‌طلبد:

type TradeIntent = {
  symbol: string;
  side: "buy" | "sell";
  orderType: "market" | "limit";
  quantity?: number;
  notional?: number;
  limitPrice?: number;
  rationale?: string;
};

این تبدیل باعث می‌شود جریان به این صورت تغییر کند: زبان طبیعی $ \rightarrow $ عامل هوش مصنوعی $ \rightarrow $ قصد معاملاتی ساختاریافته $ \rightarrow $ اعتبارسنجی طرح (Schema Validation) $ \rightarrow $ اعتبارسنجی ریسک. با تبدیل خروجی هوش مصنوعی به صرفاً یک ورودی برای سیستم نرم‌افزاری، منطق سیستم قابل تست می‌شود. در این حالت، درخواست ۵۰۰ دلاری در برابر سقف ۱,۰۰۰ دلاری پذیرفته (ALLOWED) می‌شود، اما درخواست ۵,۰۰۰ دلاری بلافاصله رد (REJECTED) می‌گردد.

بررسی‌های قطعی ریسک

موتور ریسک از هوش مصنوعی برای تصمیم‌گیری استفاده نمی‌کند، بلکه از منطق سخت‌افزاری (Hard-coded) برای ارزیابی یک شیء RiskPolicy بهره می‌برد که شامل maxOrderNotional (حداکثر ارزش سفارش)، maxPositionNotional (حداکثر ارزش موقعیت)، maxPortfolioExposure (حداکثر ریسک سبد)، maxDailyLoss (حداکثر ضرر روزانه)، maxTradesPerDay (حداکثر تعداد معاملات در روز) و مجموعه‌ای از allowedSymbols (نمادهای مجاز) است.

• لیست سفید نمادها: سیستم می‌تواند معاملات را به مجموعه‌ای خاص محدود کند، مانند new Set(["AAPL", "NVDA", "MSFT"]). اگر نمادی در این مجموعه نباشد، موتور دلیل SYMBOL_NOT_ALLOWED را برمی‌گرداند.
• سقف موقعیت: اگر حداکثر موقعیت مجاز ۲,۵۰۰ دلار باشد و موقعیت فعلی ۲,۲۰۰ دلار باشد، یک سفارش جدید ۵۰۰ دلاری رد می‌شود زیرا مجموع (۲,۷۰۰ دلار) از حد مجاز فراتر می‌رود.
• ریسک سبد سهام: گیت‌وی محدودیت‌های سطح بخشی (Sector-level) را اعمال می‌کند. اگر ریسک بخش تکنولوژی ۴۸٪ باشد و سقف مجاز ۴۰٪ باشد، موتور ریسک هرگونه معامله جدید در بخش تکنولوژی را، صرف‌نظر از استدلال عامل، مسدود می‌کند.
• کنترل ضرر روزانه: یک «قطع‌کننده» (Circuit Breaker) از طریق آستانه maxDailyLoss (مثلاً ۵۰۰ دلار) پیاده شده است. به محض رسیدن به این مقدار، RiskEngine تمام قصدهای معاملاتی بعدی را رد می‌کند.

مکانیزم ارزیابی ریسک

API اصلی برای ارزیابی ریسک به‌گونه‌ای طراحی شده است که کوچک و صریح باشد. سیستم از یک تایپ به نام RiskDecision برای انتقال نتیجه استفاده می‌کند:

type RiskDecision = 
  | { allowed: true; checks: string[]; } 
  | { allowed: false; reason: string; failedChecks: string[]; };

این ساختار به تابع evaluateTrade اجازه می‌دهد تا توضیح مفصلی درباره علت پذیرش یا رد یک معامله ارائه دهد. یک معامله باید زنجیره‌ای از بررسی‌ها را پشت سر بگذارد: مجاز بودن نماد، اندازه سفارش، سقف موقعیت، ریسک سبد، محدودیت ضرر روزانه و محدودیت تعداد معاملات. تنها زمانی که تمام بررسی‌های مورد نیاز پاس شوند، اجازه اجرا صادر می‌گردد.

مدیریت وضعیت و حضور انسان

سیستم دو حالت عملیاتی متمایز را بر اساس قابلیت‌های فعلی تایید معامله در Robinhood پشتیبانی می‌کند:

۱. حالت کمکی (Assisted Mode): عامل یک معامله را پیشنهاد می‌دهد، گیت‌وی ریسک آن را اعتبارسنجی می‌کند و سپس یک انسان باید به‌طور دستی سفارش را پیش از ارسال تایید کند. جریان به این صورت است: عامل $ \rightarrow $ قصد معامله $ \rightarrow $ ریسک $ \rightarrow $ درخواست تایید $ \rightarrow $ انسان $ \rightarrow $ روبین‌هود.

۲. حالت خودکار (Automated Mode): معامله به‌طور خودکار اجرا می‌شود، اما تنها در صورتی که تمام بررسی‌های قطعی ریسک و سیاست‌ها را پاس کند. جریان به این صورت است: عامل $ \rightarrow $ قصد معامله $ \rightarrow $ ریسک $ \rightarrow $ سیاست $ \rightarrow $ روبین‌هود.

برای حفظ یک ردپای حسابرسی (Audit Trail) قابل اعتماد، سیستم یک ماشین وضعیت (State Machine) سخت‌گیرانه برای سفارش‌ها پیاده می‌کند. یک معامله از چرخه حیات زیر عبور می‌کند:

PROPOSED (پیشنهاد شده) $ \rightarrow $ VALIDATED (اعتبارسنجی شده) $ \rightarrow $ APPROVED (تایید شده) $ \rightarrow $ SUBMITTED (ارسال شده) $ \rightarrow $ OPEN (باز) $ \rightarrow $ FILLED (پر شده) $ \rightarrow $ RECONCILED (تطبیق داده شده).

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

حسابرسی و ساختار پروژه

هر اقدام معنادار عامل یک AuditRecord تولید می‌کند که شامل برچسب زمانی، agentId (شناسه عامل)، اقدام انجام شده، ابزار مورد استفاده، inputHash (هش ورودی)، riskDecision (تصمیم ریسک)، approvalStatus (وضعیت تایید) و نتیجه نهایی است. این امر به توسعه‌دهندگان اجازه می‌دهد تا کل زنجیره را بازسازی کنند: درخواست کاربر $ \rightarrow $ تصمیم عامل $ \rightarrow $ فراخوانی ابزار $ \rightarrow $ تصمیم ریسک $ \rightarrow $ تایید $ \rightarrow $ سفارش $ \rightarrow $ نتیجه.

پروژه در یک ساختار دایرکتوری تمیز در تایپ‌اسکریپت سازماندهی شده است تا اطمینان حاصل شود که قوانین تجاری با مدل هوش مصنوعی جفت (Couple) نشده‌اند:

• src/agent/: تایپ‌های مربوط به عامل.
• src/mcp/: کلاینت MCP و رجیستری ابزارها.
• src/permissions/: موتور مجوزها.
• src/trades/: خدمات قصد معامله و اعتبارسنجی.
• src/risk/: سیاست ریسک و موتور ارزیابی.
• src/approvals/: خدمات تایید.
• src/audit/: ثبت وقایع حسابرسی.
• src/state/: مدیریت وضعیت اجرا.

مهندسی برای شکست

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

امنیت با این تضمین تامین می‌شود که گیت‌وی هرگز اسرار (Secrets) را ذخیره نمی‌کند. اعتبارنامه‌ها از طریق متغیرهای محیطی مدیریت می‌شوند (با استفاده از .env.example برای مخزن کد) و هرگز در سوابق حسابرسی چاپ نمی‌شوند یا در کنترل نسخه (Version Control) ثبت نمی‌گردند.

تست و اعتبارسنجی

منطق ریسک به‌گونه‌ای طراحی شده است که از طریق تحلیل مقادیر مرزی (Boundary Value Analysis) به‌شدت قابل تست باشد. برای مثال، اگر maxOrderNotional برابر ۱,۰۰۰ دلار باشد، سیستم تست می‌شود تا اطمینان حاصل شود مقادیر ۵۰۰ و ۱,۰۰۰ دلار پذیرفته و مقدار ۱,۰۰۱ دلار رد می‌شود. محدودیت‌های موقعیت نیز به همین ترتیب تست می‌شوند: با سقف ۲,۵۰۰ دلار و موقعیت فعلی ۲,۰۰۰ دلار، یک سفارش ۴۰۰ دلاری پذیرفته می‌شود اما سفارش ۵۰۱ دلاری رد می‌گردد.

تست‌های مجوز تایید می‌کنند که عامل‌ها نمی‌توانند از ابزارهای خارج از محدوده خود استفاده کنند. یک عامل پژوهشی تست می‌شود تا اطمینان حاصل شود get_portfolio پذیرفته (ALLOWED) و place_order رد (DENIED) می‌شود. جریان‌های تایید در هر دو حالت کمکی و خودکار تست می‌شوند تا اطمینان حاصل شود که رد کردن درخواست توسط کاربر به‌درستی مانع از اجرا می‌شود.

قابلیت استفاده مجدد و چشم‌انداز کلی

با جداسازی قوانین تجاری از مدل هوش مصنوعی، گیت‌وی ریسک قابل استفاده مجدد می‌شود. یک گیت‌وی واحد می‌تواند به یک عامل مبتنی بر تکانه (Momentum)، یک عامل بازتنظیم سبد (Rebalancing) یا یک عامل پژوهش‌محور خدمات دهد، بدون اینکه نیاز باشد منطق ایمنی برای هر یک از آن‌ها دوباره نوشته شود. عامل تغییر می‌کند، اما کنترل‌ها ثابت می‌مانند.

این تغییر در مهندسی، ارزش پیشنهادی برای توسعه‌دهندگان هوش مصنوعی را تغییر می‌دهد. چالش دیگر صرفاً اتصال یک LLM به یک API نیست، بلکه ساخت زیرساخت‌های کنترل‌شده‌ای است — شامل خروجی‌های ساختاریافته، کنترل‌های ریسک و قابلیت حسابرسی — که یک محصول مالی واقعی به آن نیاز دارد. معماری نهایی تضمین می‌کند که هوش مصنوعی پیشنهاد دهد، نرم‌افزار اعتبارسنجی کند، سیاست کنترل کند و روبین‌هود اجرا نماید.

گام بعدی شما

• اگر از MCP برای ابزارهای مالی استفاده می‌کنید، لایه اعتبارسنجی را از داخل پرامپت به یک سرویس خارجی در تایپ‌اسکریپت منتقل کنید.
• برای هر عامل، یک ماتریس مجوز (Read/Write) تعریف کنید تا دسترسی‌ها به حداقل برسد.
• یک سیستم ثبت وقایع (Audit Log) برای تمام تصمیمات ریسک پیاده کنید تا در صورت بروز خطا، زنجیره تصمیم‌گیری قابل ردیابی باشد.

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