Vercel حوالی اواسط ژوئن ۲۰۲۶ eve را با شعاری منتشر کرد که مسخره کردنش آسان است و کنار گذاشتنش سخت: مثل Next.js، برای ایجنت. شرط واقعی باریکتر است. ایجنت یک دایرکتوری است. ابزارها فایلاند. پرامپت سیستم در instructions.md زندگی میکند. نشستها پایدارند. فایلسیستم سطح نویسندگی است.
برای من این کمتر یک لانچ است و بیشتر یک سؤال بستهبندی. یک سال رفتار ایجنت را در رونوشت چت، تکه YAML، و پیکربندی پلتفرمی چپاندهایم که فقط داخل داشبورد کسی رندر میشود. گذاشتن ایجنت در ریپو، بهشکل مسیرهایی که PR میتواند diff کند، یا اصلاح درست است یا آیین تازه. احتمالاً هر دو، بسته به تیم.
درخت چه ادعایی دارد
چیدمان معمول eve زیر agent/ لانه پوشههای صاحبنظر است. agent.ts دستگیره مدل و رانتایم را دارد. instructions.md پرامپت همیشه روشن است. tools/ تابعهای تایپداری است که مدل میتواند صدا بزند. skills/ رویه را درخواستی بار میکند. channels/ برای Slack و Discord و HTTP و شبیه آنهاست. schedules/ خودمختاری به شکل cron است. subagents/ ایجنت فرزند را بسته تو در تو میکند. sandbox/ بذر فضای کار و انتخاب جداسازی است.
eve این درخت را راه میرود و رانتایم را سیم میکشد. post_chart.ts را در tools/ بینداز، در Markdown بنویس ایجنت کیست، و فریمورک ادعا میکند لولهکشی مال اوست. اجرای پایدار، سندباکس، تأیید، و ارزیابی زیرش نشستهاند تا از حلقه لخت مدل شروع نکنی.
این داستان سندباکس Agents SDK از OpenAI نیست. آن خط درباره مالکیت رانتایم اجرا و جداسازی برای ایجنت کدنویسی است. حرف eve قرارداد است: دایرکتوری سطح محصول است، همانطور که app/ به یک نسل از توسعهدهنده Next.js یاد داد صفحه کجا میرود.
کی شکل دایرکتوری کمک میکند
مالکیت تیم روشنتر میشود. ایجنت صورتحساب یک پوشه با ورودی CODEOWNERS است. ایجنت پشتیبانی یکی دیگر. بحث اینکه کدام صفحه Notion مرجع است تمام میشود، یا دستکم گرانتر میشود.
پرامپت قابل بازبینی میشود. تغییر instructions.md در همان PR کنار ابزاری میآید که دسترسی شبکه گرفته. این بازبینی سالمتر است از اینکه «پرامپت سیستم پنجشنبه پیش در UI میزبانیشده عوض شد».
ابزار بهشکل فایل کمی انضباط تحمیل میکند. ابزار یک ماژول است با اسکیما و execute. میشود تستش کرد. میشود grep کرد. میشود وقتی استفاده نمیشود حذفش کرد، بهجای اینکه قابلیت زامبی در یک مگاپرامپت بماند.
آشناسازی هم به همان دلیل بهتر میشود که create-next-app کار کرد: مهندس تازه درخت را باز میکند و حدس میزند کانال Slack یا زمانبندی هفتگی کجا میرود. حدسپذیری زیرساخت دستکمگرفتهشده است.
اگر ایجنت عمر طولانی، چندابزاری، و مال بیش از یک نفر است از اینجا شروع میکنم. ربات پشتیبانی، ایجنت عملیات داخلی، ایجنت گزارش زمانبندیشده، از آن نوع کسل پروداکشن، از چیدمان قابل بازبینی بیشتر سود میبرند تا از یک DSL گراف زیرک.
کی آیین میشود
هر ایجنت کلیسای پوشه نمیخواهد. کمکمهاجرت یکبارمصرف که یک بعدازظهر در سندباکس اجرا میشود به channels/ و schedules/ و subagents تو در تو نیاز ندارد. اگر تیم بیشتر وقتش را صرف عوض کردن اسم دایرکتوری برای راضی کردن فریمورک میکند تا تحویل ابزار، قرارداد دارد هزینه میدهد.
جاذبه پلتفرم واقعی است. eve متنباز است، با مدلهای زیاد و سرور MCP کار میکند، و هنوز راحت کنار پیشفرض استقرار و سندباکس و workflow خود Vercel زندگی میکند. اگر از قبل آنجایی، اشکالی ندارد. اگر رانتایمت جای دیگری است و هر مسیر «همینطور کار میکند» فرض را روی API نشست آنها، توکن ادامه آنها، و داستان استقرار آنها گذاشته، مالیات است. قرارداد دایرکتوری سفر میکند. پیشفرض عملیاتی میچسبد.
آسایش دروغین ساختار هم هست. درخت تمیز میتواند instructions.md مبهم و ابزار با شبکه باز را قایم کند. شکل فایلسیستم بازبینی امنیت نیست. مجوز، نقطه تأیید، و بودجه هنوز قرارداد صریح میخواهند؛ همان کسلی که میخواهم قبل از هر فریمورک نسخهبندی شود.
چطور روی تیم واقعی ارزیابیاش کنم
شکل را قبل از ازدواج با رانتایم بدزد. حتی اگر روی حلقه نازکتری بمانی، چیدن دستور، ابزار، و مهارت بهصورت فایل در ریپو عادت خوبی است. ارزیابی را کنار ایجنت بگذار، همانطور که تست را کنار مسیر میگذاری.
اگر eve را میگیری، با instructions.md و tools/ مثل کد پروداکشن رفتار کن: بازبینی PR، CODEOWNERS، و هیچ ویرایش خاموش پرامپت در داشبورد. نشست پایدار را برای کاری بگذار که منتظر انسان میماند یا از استقرار رد میشود. درخت کامل را برای ایجنتی که به اسکریپت تکابزاری نزدیکتر است رد کن.
قفل را در لایه ازسرگیری و کانال ببین، نه در Markdown. پرامپت جابهجا میشود. معنی نشست و فرض استقرار نه.
eve درست میگوید ایجنتها به چیدمان پیشفرض پروژه نیاز داشتند، همانطور که اپ وب داشت. اشتباه این است که «Next.js برای ایجنت» را دلیل بس کنی برای نپرسیدن اینکه مجوز مال کیست، چه چیزی از سقوط جان به در میبرد، و دایرکتوری به تیم کمک میکند یا فقط به فریمورک اتاق بیشتری برای جابهجایی میدهد.
ابزار شبکه را در همان PR که پرامپت را شل میکند قایم نکن. اگر diff هم دستور را عوض کرد هم سطح دسترسی را، بازبین باید هر دو را ببیند و حق داشته باشد یکی را رد کند. پوشه تمیز این حق را نمیسازد. قانون بازبینی میسازد.
دایرکتوری مالک حادثه را مشخص نمیکند
پوشه مرتب این سؤال را جواب نمیدهد که نیمهشب که ایجنت پیام اشتباه به کانال زد، چه کسی بیدار میشود. CODEOWNERS شروع خوبی است، به شرطی که همان آدمها به لاگ نشست و به کلید ابزار دسترسی داشته باشند. اگر مالک پوشه نتواند اجرا را متوقف کند، مالکیت نمایشی است.
من برای هر ابزار یک جمله نگه میدارم: چه چیزی را میخواند، چه چیزی را عوض میکند، و خاموش کردنش یعنی چه. جمله را کنار فایل ابزار میگذارم، نه در ویکی. اگر ابزار شبکه دارد، میزبانهای مجاز را در همان ماژول مینویسم تا diff بازبینی را مجبور به دیدن کند. instructions.md حق ندارد این فهرست را با یک جمله مبهم دور بزند.
schedules/ را دیرتر از tools/ اضافه میکنم. خودمختاری زمانبندیشده یعنی ایجنت وقتی کسی نگاه نمیکند کار میکند. تا وقتی مسیر تعاملی را با بازبینی انسان ندیدهای، cron فقط حادثه را به ساعت خلوت منتقل میکند. subagents هم همینطور. ایجنت فرزند وقتی معنی دارد که قرارداد ورودی و خروجیاش از والد جدا و قابل تست باشد. اگر فقط پرامپت را قاچ کردهای، پوشه تو در تو خوانایی را بدتر کرده.
شکل را از eve بردار حتی اگر رانتایم را نبری. ازدواج با نشست و کانال را وقتی بپذیر که مسیر ازسرگیری و مدل استقرارتان همان است. در غیر این صورت دایرکتوری عادت خوب است و بقیه فریمورک مالیات.