ابرک دو مسیر جدا برای هوش مصنوعی دارد. ماژول abrak_mcp سرور MCP را داخل خود اودوو باز میکند تا کلاینت‌هایی مثل Claude و Cursor داده‌های ERP را بخوانند. ماژول abrak_ai_gateway مدل‌های زبانی سازگار با OpenAI را پشت یک درگاه و یک کیف پول مصرف جمع میکند. هر نوشتن در مسیر MCP فقط پس از پیش‌نمایش و تأیید انسانی انجام میشود.
پروتکل MCP در ERP یعنی چه؟
پروتکل Model Context Protocol راهی استاندارد است تا یک مدل زبانی بتواند ابزارهای یک سرور را ببیند و صدا بزند. در ابرک خود اودوو سرور است و واسطهٔ جداگانه‌ای در میان نیست. کلاینت با نشانی /mcp وصل میشود، از طریق مسیرهای OAuth در همان اودوو احراز هویت میکند و فقط ابزارهایی را می‌بیند که کاربرش اجازه دارد.
ابزارهای خواندنی شامل جست‌وجوی رکوردها، خواندن فیلدها، شمارش، گروه‌بندی و گزارش‌گیری هستند. ابزارهای نوشتنی هم وجود دارند، مانند ساخت، به‌روزرسانی، ثبت پیام و انتقال وضعیت. برای هر کدام قاعدهٔ جداگانه‌ای در کد تعریف شده است، و مجموعهٔ ابزارها در پوشهٔ tools ماژول قرار دارد.
چرا نوشتن باید پیش‌نمایش و تأیید داشته باشد؟
هر تغییر نوشتنی ابتدا با ابزار پیش‌نمایش نشان داده میشود و تفاوت دقیق را فهرست میکند. اجرای واقعی فقط با ابزار تأیید انجام میشود، و این ابزار توکنی می‌خواهد که خودش از پیش‌نمایش ساخته شده است. این توکن یک HMAC روی همان تغییری است که قرار است نوشته شود، و به کلیدی که درخواست را داده گره خورده است.
در کد، توکن پیش‌فرض ۳۰۰ ثانیه اعتبار دارد. هنگام تأیید، امضا دوباره محاسبه میشود و تغییر دوباره از روی همان بار امضاشده ساخته میشود. یعنی مقداری که نوشته میشود همان مقداری است که کاربر دیده و امضا شده است، نه هر چیزی که درخواست تلاش دوباره می‌آورد. اگر مدل نتیجه را از خودش بسازد، توکن معتبری در اختیار ندارد.
کلید، دامنه و سقف دسترسی
هر کلید MCP یک دامنهٔ دسترسی و عمر دارد. کاربر عادی فقط برای خودش کلید می‌سازد و نمیتواند کلیدی گستردهتر از سهم خودش بسازد. فقط مدیر MCP یا مدیر سیستم می‌تواند دامنه را بالا ببرد. کلید تازه‌ای که کاربر عادی می‌سازد هم از سقف عمر پیش‌فرض تنظیمات بیشتر نمی‌ماند.
سیاست مدل‌ها پیش‌فرض رد است. یعنی مدلی که در فهرست مجاز نیست، حتی اگر کاربر به آن در Odoo دسترسی داشته باشد، از راه MCP خوانده یا نوشته نمی‌شود. وقتی درخواستی رد شود، ابزار explain_denial دلیل را نشان می‌دهد: کدام لایه رد کرده، کدام قاعده، و کدام گروه کم است. این کار جلوی حدس زدن کاربر را می‌گیرد.
خواندن و نوشتن، دو دامنهٔ جدا
خواندن داده برای مدل کم‌خطرتر است، اما حتی خواندن هم می‌تواند اطلاعات حساس را بیرون ببرد. به همین دلیل دامنهٔ خواندن و نوشتن در کلید جدا هستند. کلیدی که فقط برای گزارش ساخته شده، نباید بتواند پیشنهاد یا سفارش بسازد، حتی اگر کاربرش در Odoo چنین حقی داشته باشد.
قاعدهٔ حداقل دسترسی در نسخهٔ ۱۹.۰.۱.۶.۱ ماژول با تست‌های مشخص پوشش داده شده است. هنگام ساخت کلید، مدیر سیستم باید بپرسد این کلید برای چه کاری است و کدام دامنه لازم است. کلیدی که کار مشخصی ندارد، همان ابتدا بسته میشود و هیچ کس بعداً مجبور نیست آن را پیدا کند.
مرز مالیاتی روی همین مسیر
ماژول tax_guard در کد MCP به‌صورت fail-closed کار میکند. هیچ ابزار MCP نمیتواند فاکتوری را به سامانهٔ مؤدیان بفرستد، لغو کند یا اصلاح کند. این قاعده در کد نوشته شده و با کلید، فهرست مجاز، پارامتر سیستم یا گروه کاربری عوض نمی‌شود.
این بررسی دو بار انجام میشود. پیش از فراخوانی، کنترل میکند که ابزار یا مدل مربوط به مؤدیان نباشد. پس از فراخوانی واقعی هم وضعیت مرتبط با مالیات پیش و پس را مقایسه میکند، و اگر چیزی به سامانه صف شده یا ارسال شده باشد، تراکنش برگشت داده میشود. کار مدل زبانی در این بخش به پیش‌نویس محدود میماند.
درگاه AI و کیف پول مصرف
ماژول abrak_ai_gateway مسیرهای سازگار با OpenAI دارد: فهرست مدل‌ها، تکمیل گفتگو و embedding. هزینهٔ هر فراخوانی پیش از اجرا از کیف پول رزرو میشود، بعد از پاسخ تسویه میشود و اگر پاسخی نیامد آزاد میشود. به این ترتیب کیف پول هم از مصرف بیشتر از موجودی جلوگیری میکند و هم پس از خطا هزینه‌ای بی‌دلیل کسر نمی‌کند.
در ماژول، چهار ارائه‌دهنده ثبت شده‌اند: ParsPack، Liara، OpenRouter و FreeModel. ارائه‌دهنده‌ای که از ایران محدود است از یک تونل خروجی عبور میکند، و نشانی این تونل در تنظیمات قابل تغییر است و نیاز به تغییر کد ندارد. ارائه‌دهنده‌هایی که مستقیم در دسترس‌اند، بدون تونل فراخوانی می‌شوند.
آنچه این مقاله ادعا نمی‌کند
این مقاله ادعای یک عامل خودکار را ندارد که بدون تأیید چیزی را در ERP بنویسد یا پرداختی انجام دهد. نوشتن داده از راه MCP با تأیید انسانی همراه است، و ارسال مالیاتی بیرون از دایرهٔ ابزارهای مدل قرار دارد.
همچنین این مقاله کیفیت پاسخ مدل‌ها را مقایسه نمی‌کند. کیفیت پاسخ به مدل، زبان و نوع کار بستگی دارد و باید با نمونه‌های واقعی سنجیده شود.
یک نمونه از کار: ثبت یک پیش‌نویس فروش
فرض کنید کارشناس فروش از یک کلاینت AI می‌خواهد پیشنهاد فروشی برای یک مشتری بسازد. کلاینت ابتدا با ابزار جست‌وجو مشتری را پیدا میکند و با ابزار خواندن، قیمت محصولات را می‌بیند. بعد درخواست ساخت پیشنهاد را می‌دهد. سرور ابتدا با ابزار پیش‌نمایش تغییر را نشان می‌دهد: رکوردهایی که ساخته می‌شوند و فیلدهایی که پر می‌شوند.
کارشناس می‌بیند قیمت یکی از ردیف‌ها اشتباه است و درخواست را اصلاح میکند. پیش‌نمایش تازه ساخته میشود و فقط پس از تأیید صریح، ابزار تأیید اجرا را انجام می‌دهد. در این نمونه هیچ‌چیز بدون نگاه انسان ثبت نشده است. پیشنهاد هم پیش‌نویس است و ارسالش به مشتری اقدامی جدا است که این مقاله ادعای خودکار بودنش را ندارد.
چه چیزی از فراخوانی‌ها ثبت میشود؟
ابزار get_tool_usage خلاصهٔ فراخوانی‌های همان اتصال را نشان می‌دهد: کدام ابزار صدا زده شده، چند بار، و با چه نتیجه‌ای. این گزارش به کلید خود کاربر محدود است. در اصلاحات امنیتی نسخهٔ ۱۹.۰.۱.۶.۰ آمده که این ابزار بدون کلید MCP لاگ همهٔ اتصال‌ها را برنمی‌گرداند. برای بازبینی فنی همین گزارش معمولاً کافی است و لازم نیست به لاگ خام پایگاه داده دست برد.
خطای دسترسی را چطور بفهمیم؟
هر رد دسترسی فقط یک خطای عمومی نیست. پیام رد می‌گوید کدام لایه رد کرده است: فهرست مدل MCP، قاعدهٔ دسترسی، قاعدهٔ رکورد یا قاعدهٔ فیلد. همچنین نام قاعدهٔ رد شده، گروه‌های کم و یک پیشنهاد اصلاح را نشان می‌دهد. پیش از اینکه کلاینت درخواستی را امتحان کند، با ابزار explain_denial می‌تواند بپرسد آن کار اصلاً مجاز است یا نه. این کار جلوی تلاش‌های تکراری مدل را می‌گیرد.
کنترل هزینهٔ مدل در عمل
فرض کنید تیم پشتیبانی روزانه چند ده پرسش از طریق درگاه AI می‌پرسد و هر پرسش هزینهٔ کوچکی دارد. اگر کیف پول تیم شارژ داشته باشد، هر فراخوانی با رزرو شروع میشود و با پاسخ تسویه میشود. اگر فراخوانی بعد از خطا رها شود، رزرو آزاد میشود و موجودی بی‌دلیل کم نمی‌شود.
این روش کنترل را روی مصرف واقعی می‌گذارد، نه روی حدس ماهانه. مدیر مالی می‌تواند بر اساس گزارش مصرف، بودجهٔ ماه بعد را تنظیم کند و ببیند کدام بخش بیشترین پرسش را دارد.
در درگاه AI، پیش از هر فراخوانی مبلغ آن در کیف پول رزرو میشود، پس از پاسخ تسویه میشود، و اگر فراخوانی ناموفق بماند رزرو آزاد میشود. این چرخه جلوی مصرف بی‌حساب را می‌گیرد و گزارش مصرف را برای مدیر مالی قابل خواندن میکند. پیش از روشن کردن دسترسی AI، فهرست ابزارهایی را که بیرون می‌گذارید بازبینی کنید.
روش گام‌به‌گام اتصال یک کلاینت AI به ابرک
- کلید MCP را با کمترین دامنهٔ لازم بسازید و عمر آن را کوتاه بگیرید.
- کلاینت را به نشانی
/mcpوصل کنید و با OAuth وارد شوید. - با ابزار خواندن از داده‌ها بپرسید و پاسخ مدل را با یک گزارش دستی بسنجید.
- هر نوشتن را ابتدا پیش‌نمایش ببینید، فقط بعد از تأیید اجرا کنید و تفاوت را یک بار دیگر بخوانید.
- گزارش مصرف و فعالیت کلید را دوره‌ای بررسی کنید و کلیدهای بی‌استفاده را باطل کنید.
منابع
مطالب و صفحه‌های مرتبط
- اتصال MCP ابرک
- درگاه هوش مصنوعی ابرک
- MCP چقدر امن است؟ تحلیل مدل تهدید برای اتصال AI به ERP
- ERP چیست؟ راهنمای جامع انتخاب و پیاده‌سازی برای شرکت ایرانی
می‌خواهید خودتان امتحان کنید؟ آزمایش ۱۴ روزهٔ رایگان ابرک را فعال کنید و طرح‌ها و قیمت‌ها را ببینید.
سؤالات متداول
آیا با MCP مدل زبانی می‌تواند داده‌های ERP را بخواند؟
بله، اگر کلید MCP دامنهٔ خواندن داشته باشد و مدل در فهرست مجاز باشد. هر خواندن با دسترسی همان کاربر انجام میشود، نه با دسترسی مدیر سیستم.
چرا برای هر تغییر دوباره تأیید می‌خواهیم؟
چون مدل ممکن است اشتباه کند یا تأیید را خودش بسازد. توکن تأیید روی همان تغییر امضا شده است، پس تغییر تازه‌ای بدون تأیید جدید اجرا نمی‌شود.
اگر کلید لو برود چه میشود؟
کلید را باطل کنید. کلید عمر دارد و کاربر عادی نمیتواند آن را گستردهتر کند، پس اثر لو رفتن به دامنهٔ همان کلید محدود میماند.
آیا ابزارهای MCP می‌توانند فاکتور مؤدیان را بفرستند؟
خیر. ماژول tax_guard ارسال، لغو و اصلاح در سامانهٔ مؤدیان را از راه MCP مسدود میکند و این قاعده در کد است.
کیف پول مصرف چطور هزینه را کم میکند؟
هزینهٔ تقریبی هر فراخوانی پیش از اجرا رزرو میشود. پس از پاسخ، مصرف واقعی تسویه میشود و اگر فراخوانی ناموفق باشد، رزرو آزاد میشود.
برای شروع کوچک چه کنم؟
یک کلید با دامنهٔ خواندن بسازید، یک گزارش ساده مثل فروش ماهانه را از مدل بخواهید، و نوشتن را تا پس از یک هفته آزمون نگه دارید.
