تصور کنید یک کارمند دیجیتال دارید که شبانه‌روز بیدار است و هر تغییری در داده‌های وب‌سایت شما را می‌بیند و بلافاصله در یک جدول گزارش می‌کند. با Gemini Spark (جمینای اسپارک)، نخستین عامل همیشه‌فعال گوگل، این تخیل به واقعیت تبدیل شده است. اکنون این امکان فراهم شده است که یک گزارش زنده از گوگل آنالیتیکس ۴ (GA4) را به طور مستقیم سازمان‌دهی کرده و آن را به یک زنجیره منطق کسب‌وکار سفارشی هدایت کنید. در حالی که ادغام‌های بومی (Native) کارهای ساده با اسناد را مدیریت می‌کنند، پیاده‌سازی سرورهای سفارشی «پروتکل زمینه مدل» (Model Context Protocol یا MCP) است که این قابلیت‌های پیشرفته را آزاد می‌کند.
این ابزار دیگر یک چت‌بات ساده نیست که منتظر دستور شما بماند؛ بلکه به یک نیروی عملیاتی در فضای ابری تبدیل شده که حتی وقتی لپ‌تاپ شما خاموش است، وظایف را اجرا می‌کند. برخلاف مدل‌های زبانی بزرگ (LLM) سنتی که نیازمند فعال بودن کاربر در یک نشست (Session) هستند، Gemini Spark به صورت ۲۴ ساعته در ابر اجرا می‌شود. این سیستم بر سه ستون اصلی استوار است: وظایف (Tasks) برای اجرای جریان‌های کاری چندمرحله‌ای، مهارت‌ها (Skills) برای اتصال به ابزارها و زمان‌بندی‌ها (Schedules) برای فعال‌سازی خودکار در پس‌زمینه.
همان‌طور که در تحلیل قبلی ما درباره‌ی ارکستراسیون و جست‌وجوی دقیق اشاره کردیم، این رویکرد در واقع حرکت به سمت «اتوماسیون بدون رابط کاربری» یا Headless Automation است. برای یک مدیر کسب‌وکار، این یعنی هوش مصنوعی مانند پلی میان وب عمومی و داده‌های خصوصی شرکت عمل می‌کند — شبیه به یک مترجم که زبان پیچیدهٔ سرورها را به دستورات سادهٔ انسانی تبدیل می‌کند تا دیگر نیازی به تیم‌های تخصصی DevOps برای ساخت لایه‌های واسط (Middleware) نباشد.
شکستن سقف ادغام‌های بومی
به نقل از مستندات گوگل، Gemini Spark در ۱۹ می ۲۰۲۶ در کنفرانس Google I/O معرفی شد و از ۱۶ ژوئیه ۲۰۲۶ خدمات خود را در ژاپن آغاز کرد. هدف اصلی این عامل، عبور از مدل‌های پرسش-پاسخ (Q&A) و رسیدن به اجرای خودکار جریان‌های کاری پیچیده در چندین برنامه مختلف گوگل است.
این عامل در حالت پیش‌فرض، برنامه‌های Workspace مانند Gmail, Drive, Docs و Sheets را به‌خوبی مدیریت می‌کند. کاربران می‌توانند از طریق آدرس gemini.google.com/spark به این سرویس دسترسی داشته باشند و اتصالات بومی را از طریق نوار کناری «Connected Apps» فعال کنند. در حال حاضر، گوگل ورک‌اسپیس می‌تواند مستقیماً به Gemini Spark متصل شود تا از قابلیت‌های بومی در مدیریت اسناد، جست‌وجو و ارزیابی فرمول‌ها پشتیبانی کند. در این مسیر، کاربرانی که با چالش‌های دسترسی مواجه می‌شوند می‌توانند از راهکارهای رفع خطای Permission Denied در اتصال Gemini به ورک‌اسپیس برای بهینه‌سازی دسترسی‌های خود استفاده کنند.
در آزمایش‌های بومی، این عامل توانست یک چرخهٔ کامل «ایجاد -> نوشتن -> ارزیابی -> خواندن -> ترکیب» را اجرا کند. برای مثال، در یک پرامپت آزمایشی برای ساخت یک صفحه گسترده (Spreadsheet) با فرمول =GOOGLEFINANCE("CURRENCY:USDJPY") در سلول A1، Spark تنها متن را وارد نکرد؛ بلکه فایل را ساخت، فرمول پویا را درج کرد، منتظر ماند تا موتور محاسباتی گوگل شیت‌ها نرخ زنده را محاسبه کند و سپس مقدار ارزیابی شده سلول را برای نمایش در چت فراخواند.
این زنجیرهٔ ابزاری یک جهش معماری است؛ زیرا پیش از این، چنین دستورات پیچیده‌ای نیازمند چارچوب‌های خارجی یا سرورهای سفارشی پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) بود. این سیستم به جای یک ماکروی ساده در رابط کاربری، به صورت یک چرخه اجرای چندمرحله‌ای عمل می‌کند.
Spark همچنین در تحلیل پرس‌وجوهای چندمرحله‌ای موفق است. وقتی از او خواسته شود فایلی را در پوشه‌ای به نام «sample folder» پیدا کند، او صرفاً به دنبال این رشته متن نمی‌گردد. از آنجایی که پرس‌وجوهای استاندارد درایو اغلب به شناسه‌های دقیق پوشه (Folder ID) یا سینتکس والد (مانند 'folder_id' in parents) نیاز دارند، Gemini Spark ابتدا نام پوشه را که به زبان انسانی است به یک پرس‌وجوی جست‌وجوی درایو ترجمه می‌کند تا شناسه داخلی هدف را بیابد و سپس درخواست فهرست فایل‌های محدود به آن پوشه را صادر می‌کند. این فرآیند دو مرحله‌ای اجازه می‌دهد کاربران با مفاهیم سطح بالای انسانی با درایو تعامل کنند.
قابلیت‌های بومی اضافی شامل ارکستراسیون جریان کاری بین‌دامنه (Cross-domain) است. در یک تست، این عامل محتوای HTML خام را از یک URL عمومی (https://tanaikech.github.io/about/) دریافت کرد، استخراج معنایی و خلاصه‌سازی را انجام داد، متن حاصل را قالب‌بندی کرد و از طریق Docs API یک سند Google Doc جدید ساخت و در نهایت URL نهایی را به کاربر بازگرداند. این امر توانایی پیوند دادن بازیابی داده‌های وب خارجی با ایجاد اسناد داخلی در یک پرامپت واحد را تأیید می‌کند.
با این حال، یک مرز فنی بحرانی وجود دارد. Spark در دسترسی بومی به APIهای تخصصی گوگل، مانند Google Analytics Data API، BigQuery یا Google Cloud Logging شکست می‌خورد. طبق گزارش‌های فنی، در تستی برای استخراج متریک‌های کاربران فعال بر اساس شهر از GA4 برای بازه زمانی ۲۰۲۶-۰۸-۰۱ تا امروز (با Property ID "properties/###")، مدل به‌درستی تشخیص داد که ابزار لازم را ندارد و به‌جای توهم (Hallucination) — یعنی ساختن اطلاعات جعلی شبیه به خاطرات اشتباه یک دوست — از اجرای دستور امتناع کرد. او تصریح کرد که فاقد ابزار متصل برای Analytics Data API است، که این امر نیاز فنی به یک چارچوب توسعه‌ای مانند MCP را اثبات می‌کند.
سازوکار سرور MCP
برای عبور از این محدودیت‌ها، توسعه‌دهندگان می‌توانند از Google Apps Script (GAS) به عنوان وب‌اپلیکیشن‌های سرور MCP استفاده کنند. این کار اجازه می‌دهد Spark از طریق JSON-RPC 2.0 و پروتکل HTTP با GAS ارتباط برقرار کند. این رویکرد به‌ویژه از آن جهت مؤثر است که GAS اخیراً به عنوان یک سرویس اصلی در Google Workspace به وضعیت دسترسی عمومی (GA) رسیده است که حفاظت از داده‌های سازمانی، کنترل‌های مدیریتی و پشتیبانی فنی استاندارد را تضمین می‌کند. برای مدیریت هزینه‌ها در این لایه، گوگل یک لایه‌ی امنیتی برای مهار هزینه‌های پیش‌بینی‌نشده توکن‌ها ایجاد کرده است تا پایداری عملیاتی در مقیاس سازمانی حفظ شود.
با استفاده از وب‌اپلیکیشن‌های GAS، توسعه‌دهندگان می‌توانند مکانیزم‌های پیچیدهٔ احراز هویت — مانند OAuth 2.0، کلیدهای API (API keys)، هدرهای نشست (Session headers) یا تبادلات توکن چندمرحله‌ای — را کپسوله‌سازی کرده و در لایه اسکریپت مخفی کنند و در عوض، یک مجموعه ابزار تمیز و ساختاریافته به هوش مصنوعی ارائه دهند. این کار مشکلاتی را که در اثر محدودیت‌های امنیتی یا رویه‌ای در فراخوانی‌های بومی مستقیم رخ می‌داد، حل می‌کند.
گام‌های استقرار سرورهای MCP در GAS:
- راه‌اندازی پروژه: ایجاد یک پروژه GAS جدید از طریق گوگل درایو. استفاده از مخزن متن‌باز «Google API MCP / A2A Server for GASADK» که از کتابخانه‌های GASADK و GoogleApiApp برای مدیریت انتقال داده‌های JSON-RPC 2.0 استفاده می‌کند.
- پیکربندی Manifest: باز کردن فایل
appsscript.json(از طریق Project Settings > Show 'appsscript.json' manifest file). تنظیم منطقه زمانی (مثلاً "Asia/Tokyo"). افزودن وابستگی‌هایGASADK(نسخه ۱۲، شناسه:1w2mwhWQd4_6rom-UBRPD8gayBoqGH_87awSBVqGI8DdaQI_pOeSuGYDu) وGoogleApiApp(نسخه ۴، شناسه:1YVWd5qzz0quKljrJkliE143UwwJq1BopoZQSwNEqwNgHOPQ9VeaQeNS7) و فعال‌سازی سرویس پیشرفتهAnalyticsData(v1beta). - تعریف OAuth Scopes: تعریف دسترسی‌های لازم در Manifest، به‌ویژه:
https://www.googleapis.com/auth/analytics.readonlyبرای خواندن داده‌ها،https://www.googleapis.com/auth/script.external_requestبرای درخواست‌های خارجی وhttps://www.googleapis.com/auth/spreadsheetsبرای مدیریت شیت‌ها. - استقرار اسکریپت: کپی کردن محتوای
DeployMcpServer.jsاز گیت‌هاب در فایلCode.gs. اگرPropertiesServiceپیکربندی نشده باشد، اسکریپت از عبارتsampleبه عنوان کلید دسترسی پیش‌فرض (accessKey=sample) استفاده می‌کند. - تنظیمات Web App: استقرار پروژه به عنوان «Web app» با تنظیماتی که توسط «من» (Me) اجرا شود و برای «همه» (Anyone) قابل دسترسی باشد. کپی کردن URL استقرار (به شکل
https://script.google.com/macros/s/{DEPLOYMENT_ID}/exec). - ثبت در Spark: در بخش «Connected Apps» > «Custom apps for Spark»، وارد کردن URL وب‌اپلیکیشن به همراه پارامتر کلید دسترسی (مثلاً
https://script.google.com/macros/s/{DEPLOYMENT_ID}/exec?accessKey=sample)، پذیرفتن بیانیه امنیتی و تعیین نام برنامه (مثلاً GAS-MCP).
پس از اتصال، عامل می‌تواند فراخوانی‌های پیچیده API را انجام دهد. در آزمایش‌های عملی، وقتی از ابزار @gas-mcp برای دریافت داده‌های GA4 خواسته شد، Spark نیازها را به قالب JSON-RPC تبدیل کرد. سرور GAS مدیریت توکن‌های OAuth 2.0 را بر عهده گرفت، سرویس آنالیتیکس را فراخواند و متریک‌های خام JSON را بازگرداند. سپس Gemini Spark این داده‌ها را در قالب یک «خلاصه مدیریتی» (Executive Summary) و یک جدول رتبه‌بندی ۱۰ مورد اول ترکیب و ارائه کرد.
نتایج شناسایی کرد که سنگاپور با ۵۹ کاربر فعال (حدود ۴۳.۷٪ از کل ۱۳۵ کاربر)، رتبه اول را دارد و پس از آن مکان‌های نامشخص (۹ مورد) و مکان‌های (not set) (۸ مورد) قرار دارند. سایر شهرهای ثبت شده شامل Qinhuangdao (۴ مورد)، اوساکا (۴ مورد)، چنگدو (۳ مورد)، Council Bluffs (۳ مورد)، بمگالورو (۲ مورد)، سیاتل (۲ مورد) و احمدآباد (۱ مورد) بود. در مجموع، ۵۸ شهر مختلف ثبت شده بود که نشان دهنده یک دسترسی جهانی گسترده است.
معماری رویداد‌محور و وب‌هوک‌ها
فراتر از پرس‌وجوهای ساختاریافته، Gemini Spark مانند یک توزیع‌کنندهٔ رویدادهای بدون سرور (Serverless Event Dispatcher) عمل می‌کند. با تجزیه و تحلیل محرک‌های زبان طبیعی — مانند «وقتی ایمیلی جدید از [email protected] دریافت شد، داده‌ها را به Sheet1 در گوگل شیت با نام Sample for Gemini Spark ارسال کن» — این عامل یک قانون نظارتی در پس‌زمینه در زمان‌بند ابری خود ایجاد می‌کند.
وقتی این محرک (Trigger) فعال شود، عامل در فضای ابری به صورت ۲۴ ساعته و بدون دخالت کاربر بیدار شده و اقدام را اجرا می‌کند. در سناریوی تست شده، Gemini Spark به طور خودکار برچسب زمانی، موضوع و بدنه ایمیل دریافتی (مثلاً "2026-08-03 14:13:16 JST") را استخراج کرد و داده‌ها را به شیت هدف اضافه نمود.
این قابلیت نیاز به «زمان‌بندهای تکراری» (Time-driven triggers) سنتی در GAS که هر چند دقیقه یک‌بار برای بررسی داده‌ها اجرا می‌شوند و سهمیهٔ پردازشی را می‌بلعند و باعث تأخیر می‌شوند، یا وب‌هوک‌های پیچیده GCP Pub/Sub که نیازمند زیرساخت‌های سنگین IAM هستند را از بین می‌برد. در واقع Spark تبدیل به یک توزیع‌کنندهٔ رویداد با زیرساخت صفر شده است.
ادغام مستقیم وب‌هوک HTTP
برای کسانی که به دنبال جایگزینی سبک‌تر از MCP هستند، Spark از درخواست‌های مستقیم HTTP GET پشتیبانی می‌کند. این یک الگوی زیرساخت-صفر است که در آن کاربران داده‌های ایمیل را مستقیماً در یک رشته پرس‌وجوی URL (Query String) که به یک نقطه پایانی (Endpoint) در GAS ارسال می‌شود، نگاشت می‌کنند. یک نمونه پرامپت: sender={Email address of the sender.}&subject={Subject line or title of the email.}&content={Full message content of the email.}&summary={A concise summary of the email body.}.
برای تضمین پایداری در GAS برای این الگو، یک پیاده‌سازی قوی باید شامل LockService.getScriptLock() با یک زمان انتظار (مثلاً ۳۰,۰۰۰ میلی‌ثانیه) باشد تا از شکست‌های اجرای هم‌زمان (Concurrent Execution) هنگام افزودن ردیف‌ها به شیت جلوگیری شود. یک پیاده‌سازی نمونه از doGet و doPost برای هدایت درخواست‌ها به یک تابع اصلی استفاده می‌کند که برچسب زمانی، متد و محموله (Payload) در یک صفحه گسترده ثبت می‌کند.
این روش یک جایگزین سبک‌وزن است که به هیچ کتابخانه خارجی نیاز ندارد، اما تضادهای فنی مشخصی دارد:
- محدودیت‌های محموله (Payload): درخواست‌های مستقیم GET پارامترها را در URL قرار می‌دهند. بدنه طولانی ایمیل‌ها خطر عبور از محدودیت‌های استاندارد HTTP GET (معمولاً حدود ۲,۰۰۰ کاراکتر) یا ایجاد مشکلات کدگذاری URI را دارد. در مقابل، MCP از JSON-RPC روی بدنه استاندارد درخواست برای پشتیبانی از حجم‌های نامحدود داده استفاده می‌کند.
- محدودیت‌های متد: در حال حاضر Gemini Spark درخواست‌های خروجی POST را محدود کرده است. تلاش برای استفاده از POST منجر به خطاهای زمان اجرا می‌شود با این پیام: "Outbound HTTP requests are unavailable in this environment, so the POST request could not be completed automatically." اما MCP با مدیریت داخلی انتقال داده، این مشکل را دور می‌زند.
- سربار پرامپت: وب‌هوک‌ها نیازمند آن هستند که کاربران صراحتاً نگاشت پارامترهای پرس‌وجو را در چت تعریف کنند، در حالی که MCP این فرآیند را در تعاریف ابزارهای تایپ‌شده (مثلاً فقط با استفاده از
@gas-mcp) انتزاع می‌کند و نیازی به نمایش URLها یا طرح‌ها (Schemas) در گفتگو نیست.
تحلیل نهایی
این معماری، بار احراز هویت و تجزیه داده‌ها را از دوش هوش مصنوعی به یک اسکریپت امن در سمت سرور منتقل می‌کند. با استفاده از GAS به عنوان یک پروکسی، کاربران از افشای کلیدهای API مستقیماً در لایه پرامپت جلوگیری می‌کنند و در عین حال قابلیت‌های سطح بالایی را به عامل می‌بخشند.
برای سازمان‌ها، این بدان معناست که عوامل هوش مصنوعی از «کمک‌خلبان‌هایی» (Copilots) که صرفاً متن پیشنهاد می‌دهند، به «کارمندان دیجیتالی» تبدیل می‌شوند که حالت (State) و محرک‌ها (Triggers) را مدیریت می‌کنند. توانایی ترکیب تشخیص رویداد (Gmail) با اجرای ابزار (GAS) و استدلال (Gemini)، یک پشته اتوماسیون با زیرساخت صفر ایجاد می‌کند که با پلتفرم‌های پیچیده‌ای مانند Zapier یا Make.com رقابت می‌کند، اما کاملاً در اکوسیستم گوگل جای دارد. برای شروع ساخت، توسعه‌دهندگان باید کتابخانه‌های GASADK و GoogleApiApp را بررسی کنند تا پاسخ‌های JSON-RPC خود را برای پروتکل MCP استانداردسازی نمایند.
گفتگو