«مدیریت عامل‌ها از طریق پوشه‌ها»؛ رویکرد جدید ورسل برای مقیاس سازمانی

اگر از بازنویسی لوله‌کشی‌های تکراری و پیچیده برای هر عامل هوش مصنوعی جدید خسته شده‌اید، باید بدانید که ورسل (Vercel) راهی برای تبدیل معماری عامل شما به یک ساختار ساده از پوشه‌ها پیدا کرده است. چارچوب متن‌باز جدیدی به نام eve معرفی شده است که نیاز به ثبت دستی ابزارها و مدیریت پیچیده وضعیت (State) را از بین می‌برد و هر قابلیت عامل را مستقیماً به یک دایرکتوری روی دیسک متصل می‌کند. این ابزار که با مجوز Apache-2.0 و به صورت بسته npm منتشر شده، طراحی شده است تا توسعه‌دهندگان را از «سرهم کردن لوله‌کشی» دور کرده و به سمت «تعریف عملکرد واقعی عامل» سوق دهد.

بسیاری از توسعه‌دهندگان اکنون با پدیده «پراکندگی عامل‌ها» (Agent Sprawl) دست‌وپنجه نرم می‌کنند؛ وضعیتی که در آن هر ربات جدید به یک حلقه تکرار سفارشی و ادغام دستی برای هر ابزار نیاز دارد. این موضوع باعث ایجاد سربار شدید در محیط عملیاتی می‌شود و مقیاس‌پذیری عامل‌ها را بدون داشتن یک تیم مهندسی اختصاصی دشوار می‌کند. ورسل اکنون با تبدیل «شکل» عامل به یک قرارداد استاندارد، این مشکل را حل کرده است؛ رویکردی که خود این شرکت پیش از این برای اجرای بیش از ۱۰۰ عامل داخلی در محیط عملیاتی امروز به کار گرفته است.

قرارداد سیستم فایل (The Filesystem Contract)

در eve، دایرکتوری همان قرارداد است. شما نیازی به نوشتن فایل‌های پیکربندی حجیم ندارید؛ کافی است یک فایل به پوشه اضافه کنید تا چارچوب در زمان ساخت (Build time)، آن را متصل کند. کوچک‌ترین عامل ممکن تنها از دو فایل تشکیل شده است: یک فایل agent.ts برای تعریف مدل (مانند Claude Opus 4.8) و یک فایل instructions.md که به عنوان دستورالعمل سیستم (System Prompt) دائمی عمل می‌کند و به ابتدای هر فراخوانی مدل اضافه می‌شود. برای پشتیبانی از مدل‌های جایگزین (Fallbacks) نیز از AI Gateway استفاده می‌شود.

قابلیت‌ها در یک سلسله‌مراتب سخت‌گیرانه سازمان‌دهی شده‌اند که در آن ساختار دایرکتوری، هر قابلیت را به یک پوشه متصل می‌کند:

• agent.ts: تعریف مدلی که عامل روی آن اجرا می‌شود و پیکربندی زمان اجرا در TypeScript.
• instructions.md: یک فایل Markdown که تعریف می‌کند عامل کیست و چه نقشی دارد.
• tools/: هر فایل TypeScript در این پوشه به یک ابزار تبدیل می‌شود؛ نام فایل، همان نام ابزار را تعریف می‌کند. ابزارها برای تعریف ورودی از طرح‌واره (Schema) Zod استفاده می‌کنند.
• skills/: فایل‌های Markdown حاوی دانشی که فقط زمانی که موضوع مربوطه پیش بیاید، بارگذاری می‌شوند.
• connections/: لینک‌های امن به سرورهای MCP یا نقاط انتهایی OpenAPI. در اینجا eve نقش واسط احراز هویت را ایفا می‌کند تا مدل هرگز URL یا اطلاعات حساس (Credentials) را نبیند.
• channels/: فایل‌های آداپتور برای سطوحی مانند Slack، Discord، Teams، Telegram، Twilio، GitHub و Linear. در این سیستم، یک کانال می‌تواند وظیفه را به کانال دیگر منتقل کند.
• schedules/: محرک‌های مبتنی بر Cron برای انجام اقدامات خودکار و مستقل.
• subagents/: دایرکتوری‌هایی برای عامل‌های فرزند متخصص جهت مدیریت تفویض اختیار.
• sandbox/: یک پوشه اختیاری برای بازنویسی محیط ایزوله عامل و قرار دادن فایل‌های اولیه در فضای کاری (Workspace).
• lib/: کدهای مشترکی که توسط توسعه‌دهنده نوشته شده و در سراسر عامل استفاده می‌شوند.

«باتری‌های» آماده برای محیط عملیاتی

بر اساس گزارش‌ها، eve یک سیستم «همراه با باتری» (Batteries Included) است؛ به این معنا که سخت‌ترین بخش‌های مربوط به قابلیت اطمینان عامل‌ها را به‌صورت پیش‌فرض مدیریت می‌کند. شش قابلیت عملیاتی استاندارد در این چارچوب وجود دارد:

• اجرای بادوام (Durable Execution): هر گفتگو یک جریان کاری بادوام است که هر گام آن نقطه-گذاری (Checkpoint) می‌شود. یک جلسه می‌تواند متوقف شود، در برابر کرش یا استقرار (Deploy) جدید مقاوم باشد و دقیقاً از جایی که متوقف شده بود، از سر گرفته شود. این قابلیت بر پایه Workflow SDK متن‌باز است.
• محاسبات ایزوله (Sandboxed Compute): کدهای تولید شده توسط عامل به عنوان کدهای غیرقابل‌اعتماد تلقی می‌شوند. هر عامل محیط ایزوله (Sandbox) مخصوص خود را برای اجرای دستورات شل، اسکریپت‌ها و خواندن/نوشتن فایل‌ها دارد. در حالت محلی، این سیستم روی Docker، microsandbox یا just-bash اجرا می‌شود و در محیط عملیاتی از Vercel Sandbox استفاده می‌کند.
• تأییدیه انسانی (HITL): هر اقدامی می‌تواند به گونه‌ای تنظیم شود که نیاز به تأیید داشته باشد. با استفاده از فیلد needsApproval (مثلاً توقف در صورتی که یک اسکن SQL از ۵۰ گیگابایت فراتر رود)، عامل بدون مصرف منابع پردازشی، تا زمان تأیید انسان منتظر می‌ماند.
• اتصالات امن: در زمان اجرا، عامل‌ها می‌توانند از طریق لینک‌های واسط امن به Slack، GitHub، Snowflake، Salesforce، Notion و Linear متصل شوند.
• پشتیبانی چندکاناله: API مبتنی بر HTTP به‌صورت پیش‌فرض فعال است. یک عامل واحد از طریق یک فایل آداپتور برای هر کانال، به تمام سطوح دسترسی خدمات می‌دهد.
• ردیابی و ارزیابی (Tracing and Evals): هر اجرا یک Trace با استفاده از Spans استاندارد OpenTelemetry تولید می‌کند که به Braintrust، Honeycomb، Datadog یا Jaeger ارسال می‌شود. ارزیابی‌ها (Evals) مجموعه‌های تست امتیازدهی‌شده‌ای هستند که به‌صورت محلی یا در CI اجرا می‌شوند.

عملکرد در دنیای واقعی

ورسل برای اثبات کارایی این چارچوب، داده‌های مربوط به ۶ عامل داخلی خود را به اشتراک گذاشت:

• d0 (تحلیلگر داده): پرکاربردترین ابزار داخلی با مدیریت بیش از ۳۰,۰۰۰ پرسش در ماه. هر پرس‌وجو دقیقاً بر اساس مجوزهای کاربر پرس‌کننده محدود شده است.
• Vertex (مهندس پشتیبانی): مدیریت تیکت‌ها در مرکز کمک، مستندات و Slack. این عامل ۹۲٪ از تیکت‌ها را به‌طور خودکار حل کرده و مابقی را ارجاع می‌دهد.
• Lead Agent (SDR خودکار): بررسی هر لید جدید و پیگیری خودکار آن‌ها. هزینه سالانه آن حدود ۵,۰۰۰ دلار است اما ارزشی ۳۲ برابر این مبلغ بازمی‌گرداند و تنها توسط یک مهندس به‌صورت پاره‌وقت نگهداری می‌شود.
• Athena (داشبورد فروش): توسط تیم RevOps در ۶ هفته و بدون نیاز به مهندس ساخته شده است. این عامل به سوالات مربوط به خط لوله فروش از Snowflake و Salesforce به زبان ساده پاسخ می‌دهد.
• draft0 (عامل محتوا): اجرای یک خط لوله بازبینی برای شناسایی مشکلات آشکار پیش از آنکه متن توسط ویراستار انسانی دیده شود.
• V (عامل مسیریابی): به عنوان اولین نقطه تماس در Slack عمل کرده و وظایف را به عامل متخصصی که قادر به پاسخگویی است، ارجاع می‌دهد.

تحلیل: تغییر پارادایم عامل‌ها

برای یک توسعه‌دهنده عمل‌گرا، این رویکرد تمرکز را از «چگونه این را اجرا کنم» به «این عامل باید چه کاری انجام دهد» تغییر می‌دهد. در مقایسه با یک پشته دستی (DIY) — که نیاز به ثبت دستی ابزارها، مدیریت وضعیت سفارشی و مدیریت کانتینرهای شخصی دارد — eve مسیری بهینه شده فراهم می‌کند. این چارچوب منطق پیچیده «توقف و از سرگیری» را با یک فیلد ساده needsApproval جایگزین کرده و پیچیدگی‌های ایجاد زیرساخت را به یک دستور ساده vercel deploy تبدیل نموده است.

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

برای شروع، می‌توانید دستور npx eve@latest init my-agent را برای ایجاد ساختار پروژه اجرا کنید. این دستور وابستگی‌ها را نصب کرده و یک سرور توسعه را فعال می‌کند. از آن نقطه به بعد، دستور eve dev یک رابط کاربری تعاملی در ترمینال برای تست محلی فراهم می‌کند، eve eval مجموعه‌های تست را اجرا می‌کند و eve build مصنوعات را در پوشه .eve/ کامپایل می‌کند. در نهایت، ارسال به محیط عملیاتی از طریق خط لوله استاندارد ورسل انجام می‌شود، جایی که محیط ایزوله (Sandbox) به‌طور خودکار و بدون تغییر در کد، به محیط عملیاتی منتقل می‌گردد.

گام بعدی شما

• اگر در حال حاضر از معماری‌های پیچیده برای مدیریت State عامل‌ها استفاده می‌کنید، ساختار پوشه‌بندی eve را برای ساده‌سازی پروژه‌های کوچک خود تست کنید.
• بررسی کنید که کدام بخش‌های جریان کاری شما نیاز به تأییدیه انسانی (HITL) دارد تا هزینه‌های استنتاج بیهوده را کاهش دهید.
• برای پیاده‌سازی سریع ابزارهای داخلی، از ترکیب eve و سرورهای MCP استفاده کنید تا مدل‌ها بدون دسترسی مستقیم به URLها، داده‌ها را بازیابی کنند.

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