زیرساخت عامل و باطن جدید
· 12 min read · Filippo Spinella · AI, Agents, Infrastructure, Developer Tools
ما اغلب در مورد چارچوب های عاملی صحبت کرده ایم. LangGraph، CrewAI، AutoGen، SDK های مختلف، حلقه، فراخوانی ابزار، حافظه، برنامه ریز، منتقد، سرپرست. همه کلمات مفید، به خاطر خدا. اما هرچه بیشتر به عواملی که واقعاً استفاده میشوند نگاه میکنم، بیشتر به نظرم میرسد که بخش جالب به زیر سطح چارچوب حرکت کرده است.
این سؤال دیگر فقط این نیست: از کدام کتابخانه برای ایجاد یک مدل مرحله ای استفاده کنم؟
سوال واقعی این است: وقتی این نماینده از دمو بودن خودداری می کند کجا زندگی می کند؟
زیرا یک عامل جدی تابعی نیست که یک مدل را فراخوانی کند و متن را برگرداند. این یک سیستم توزیع شده کوچک است. باید زمینه را بخواند، از ابزارها استفاده کند، کد را اجرا کند، فایلها را لمس کند، تصمیمها را به خاطر بسپارد، اجازه بخواهد، به خوبی خراب شود، راهاندازی مجدد شود، لاگها را ترک کند، بودجه را نسوزاند و به بولدوزر داخل مخزن تولید تبدیل نشود.
چارچوب فرمان است. زیرساخت جاده، ترمز، گاراژ، بیمه و شخصی است که می داند کلیدها کجا هستند.
چون در حال حاضر صحبت های زیادی در مورد آن وجود دارد
در سال های 2023 و 2024 گفتگو بسیار مدل محور بود. کدام LLM؟ چقدر زمینه؟ چقدر هزینه دارد؟ چقدر در برنامه نویسی مهارت دارد؟
در سالهای 2025 و 2026 گفتگوها تغییر کرده است. مدل ها به اندازه کافی خوب هستند تا کار واقعی انجام دهند، اما به همین دلیل است که بیت های خسته کننده قابل مشاهده می شوند: زمان اجرا، امنیت، اتصال دهنده ها، هویت، قابلیت مشاهده، اجرای کد، استقرار، بازگشت.
این انتقال طبیعی از جادو به مهندسی است.
وقتی یک نماینده فقط نیاز به ایجاد پاسخ دارد، یک چت کافی است. هنگامی که شما نیاز به باز کردن یک درخواست کشش، پرس و جو از یک پایگاه داده، تماس با یک CRM، شروع یک کار، پیمایش یک سایت، خواندن Slack، کامپایل کد و به روز رسانی یک سند دارید، به یک سیستم عامل در اطراف آن نیاز دارید.
نه به معنای واقعی کلمه. در مفهوم سازمانی.
قطعه اول: یک زمان اجرا که در آن عامل می تواند دوام بیاورد
یک عامل اغلب در مراحل کار می کند. به وضعیت نگاه کنید، یک عمل را انتخاب کنید، از یک ابزار استفاده کنید، نتیجه را مشاهده کنید، برنامه را به روز کنید، تکرار کنید.
اگر این حلقه در یک درخواست HTTP زندگی کند، بلافاصله با مشکل مواجه خواهید شد. برخی از اقدامات کند هستند. برخی منتظر نظر انسان هستند. برخی شکست می خورند و باید دوباره محاکمه شوند. برخی باید از استقرار یا تایم اوت جان سالم به در ببرند.
اینجا جایی است که جریان های کاری بادوام، صف ها، پس زمینه های شغلی و ماشین های دولتی وارد عمل می شوند. آنها پر زرق و برق نیستند، اما تفاوت بین نماینده ای که در نسخه نمایشی باهوش به نظر می رسد و عاملی است که می توانید وقتی می خواهید قهوه بخورید، کار را ترک کنید.
برای من، زمان اجرا باید به سوالات بسیار ملموس پاسخ دهد:
- کجا وضعیت را بین یک مرحله و مرحله دیگر ذخیره کنم؟
- اگر فرآیند در نیمه راه از بین برود چه اتفاقی می افتد؟
- آیا می توانم مکث کنم و درخواست تأیید کنم؟
- آیا می توانم یک اجرا را دوباره پخش کنم تا بفهمم چرا او این انتخاب را انجام داده است؟
- آیا می توانم مدت زمان، حافظه، ابزار و هزینه را محدود کنم؟
Vercel با AI SDK ها، توابع، گردش کار و ابزارهایی برای ساخت عوامل در برنامه های وب به شدت در این زمینه تلاش می کند. اما نکته فقط Vercel نیست. نکته این است که عامل به یک خانه عملیاتی نیاز دارد، نه یک نقطه پایانی واحد.
قطعه دوم: جعبه شنی، چون عامل باید بدون شکستن کثیف شود
به محض اینکه یک عامل کد می نویسد یا دستورات را اجرا می کند، یک جعبه شنی مورد نیاز است.
به نظر یک کلمه فنی است، اما ایده داخلی است: شما به او یک میز کار می دهید. می تواند فایل ها را باز کند، وابستگی ها را نصب کند، آزمایش ها را اجرا کند، آزمایش ها را انجام دهد، خروجی تولید کند. اگر او اشتباه می کند، شما آسیب را مهار کرده اید. اگر جواب داد، نتیجه را تبلیغ کنید.
یک سندباکس عامل باید برخی از ویژگی ها را داشته باشد:
- سیستم فایل ایزوله
- CPU، حافظه و محدودیت های زمانی؛
- شبکه کنترل شده؛
- اسرار فقط در صورت لزوم نصب می شوند.
- سیاهههای مربوط به کامل.
- امکان صادرات مصنوعات؛
- بازنشانی تمیز بین اجراها، در صورت لزوم.
Vercel Sandbox دقیقاً به این سمت می رود: محیط های ایزوله برای اجرای کد، نصب وابستگی ها، کار با فایل ها و تولید مصنوعات بدون اجرای همه چیز در زمان اجرای برنامه اصلی.
این موضوع مهمتر از آن چیزی است که به نظر می رسد. بسیاری از نمونه های اولیه عامل مستقیماً از مدل به سیستم واقعی پرش می کنند. مدل می تواند ابزار را فراخوانی کند. ابزارها می توانند کارها را انجام دهند. همه چیز تا اولین دستور اشتباه، اولین وابستگی نصب شده در مکان اشتباه، اولین نشانه ای که به یک گزارش ختم می شود، زیبا به نظر می رسد.
جعبه شنی روش بزرگسالی برای گفتن است: برو جلو، اما اینجا.
قطعه سوم: MCP و مشکل کانکتور
پروتکل بافت مدل به یکی از جالبترین بخشهای اکوسیستم تبدیل شده است، زیرا تلاش میکند چیزی را استاندارد کند که در غیر این صورت به سرعت غیرقابل مدیریت میشود: چگونه یک مدل ابزارهای خارجی را کشف و استفاده میکند.
بدون استاندارد، هر ادغام یک جزیره کوچک است. یک کانکتور برای GitHub یک راه، یکی برای Slack به روش دیگر، یکی برای پایگاه های داده با معنایی متفاوت، یکی برای اتوماسیون مرورگر که هیچ به نظر نمی رسد.
MCP یک زبان مشترک بین مشتری و سرور پیشنهاد می کند: ابزارها، منابع، درخواست ها، مجوزها، حمل و نقل، کشف. حکومت و امنیت را به طور جادویی حل نمی کند، اما دستور زبان می دهد.
و گرامر مهم است. وقتی یک عامل می تواند به ابزارهای زیادی متصل شود، سؤال فقط این نیست که "آیا او می تواند این کار را انجام دهد؟" مشکل این است که «آیا او میداند چه کاری میتواند انجام دهد، با چه محدودیتهایی، از طرف چه کسی، و چه ردپایی از خود به جای گذاشته است؟».
برای من MCP یک هیاهو نیست زیرا "صدای ابزار را انجام می دهد". ما قبلاً این کار را انجام دادیم. این یک هیاهو است زیرا مرکز ثقل را از یکپارچه سازی واحد به فهرست عملیاتی ابزارها تغییر می دهد.
در یک معماری عاملی خوب، MCP به نوعی پچ پنل تبدیل می شود:
- GitHub برای کد و مسائل؛
- سست برای زمینه مکالمه.
- خطی یا جیرا برای کار برنامه ریزی شده.
- پایگاه داده فقط خواندنی برای تجزیه و تحلیل؛
- مرورگر یا اسکراپر کنترل شده برای سایت های خارجی؛
- ذخیره سازی اسناد؛
- محیط های اجرای ایزوله؛
- سیستم های داخلی با مجوزهای سخت در معرض.
بخش مشکل این است که یک کاتالوگ ابزار بدون سیاست فقط یک راه زیباتر برای ایجاد هرج و مرج است.
The fourth piece: identity and permissions
این منطقه ای است که بسیاری از دموها چشم خود را می بندند.
یک نماینده از طرف کسی عمل می کند. پس باید مشخص شود که موضوع عمل کیست.
آیا از مجوزهای کاربر استفاده می کند؟ از یک حساب خدمات؟ از یک فضای کاری؟ آیا دسترسی موقت دارید یا دائم؟ آیا می توانید همه چیز یا فقط برخی منابع را بخوانید؟ میتونی بنویسی آیا می توانید لغو کنید؟ آیا او می تواند به افراد واقعی پیامک ارسال کند؟
اگر به خوبی به این سؤالات پاسخ ندهید، دیر یا زود یک دستیار با کلیدهای خانه خواهید ساخت و هیچ خاطره ای از اینکه چه کسی آنها را به او داده است.
قانون کلی که من دوست دارم این است: عامل باید بتواند کمتر از انسان انجام دهد، نه بیشتر از انسان. و زمانی که مجبور است کار مخاطره آمیزی انجام دهد، باید بایستد و بپرسد.
این به معنای OAuth، محدوده توکن، مدیریت مخفی، گزارش حسابرسی، خط مشی ابزار، لیست مجاز، مرحله تأیید است. چیزهای نه چندان رمانتیک چیزهای ضروری
قطعه پنجم: خاطره و زمینه، اما بدون انباشتن زباله
عوامل به حافظه نیاز دارند، اما حافظه زمانی خطرناک است که تبدیل به اتاق زیر شیروانی شود.
حداقل سه نوع حافظه وجود دارد:
- حافظه اجرا: آنچه در این اجرا اتفاق افتاد.
- حافظه پروژه: قراردادها، تصمیمات، محدودیت ها.
- حافظه شخصی یا تیمی: ترجیحات، لحن، تشریفات، فرآیندها.
قرار دادن همه چیز در اعلان میانبر است. تا زمانی که دیگر کار نمی کند کار می کند. حافظه مفید باید مورد توجه قرار گیرد: فهرست بندی، به روز رسانی، منقضی شده، تأیید شده، قابل استناد.
ماموری که بد به یاد می آورد بدتر از ماموری است که به خاطر نمی آورد. چون با اطمینان حرف می زند.
بنابراین زیرساخت باید شامل بازیابی، فایل های دستورالعمل، پایگاه دانش، جاسازی در صورت نیاز، و همچنین تمیز کردن باشد. ما به فرهنگ حافظه نیاز داریم: چه چیزی وارد می شود، چه کسی آن را تأیید می کند، چه زمانی خراب می شود، چگونه آن را اصلاح کنم.
قطعه ششم: مشاهده پذیری، ارزیابی و بازپخش
اگر یک عامل اشتباه کند، گزارش "مدل نامیده می شود" کافی نیست.
شما می خواهید مسیر را ببینید. چه زمینه ای دریافت کرد؟ چه ابزارهایی در دسترس بود؟ کدام ابزار را انتخاب کردید؟ با چه استدلالی؟ چه پاسخی دریافت کردید؟ چقدر هزینه شد؟ کجا گیر کرده؟ آیا انسان چیزی را تایید کرد؟ آیا مدل خطا، ابزار، درخواست، داده یا مجوز خطا است؟
در اینجا عامل ها بیشتر شبیه سیستم های توزیع شده هستند تا ربات های چت.
شما نیاز به ردیابی های قابل خواندن دارید، نه فقط گزارش های متن. شما باید بتوانید یک اجرا را دوباره پخش کنید. مقایسه دو نسخه از یک عامل در وظایف شناخته شده ضروری است. ما باید رگرسیون ها را اندازه گیری کنیم: نه تنها "بهتر پاسخ می دهد"، بلکه "بلیط مناسب را بدون دست زدن به فایل های ناخواسته می بندد".
ارزیابیهای عاملی دشوارتر از ارزیابیهای متنی هستند، زیرا شامل اعمال هستند. مقایسه یک رشته مورد انتظار کافی نیست. شما باید به دنباله ها، عوارض جانبی، کیفیت مصنوع، زمان، هزینه، تعداد مداخلات انسانی نگاه کنید.
نکته خنده دار این است که ما همیشه به آنجا برمی گردیم: مهندسی نرم افزار. تست ها، محیط ها، ردیابی ها، برگشت ها. با این تفاوت که اکنون کد نیز تصمیم می گیرد که چه کاری انجام شود.
قطعه هفتم: رابط های انسانی
نماینده مجبور نیست فقط در یک چت زندگی کند.
برخی از نمایندگان به هیئت مدیره نیاز دارند. سایرین صفحه ای با وضعیت و گزارش. سایرین دکمه "تایید" را دارند. نظرات درون خطی بیشتر هنوز دیگران از یک CLI.
UI رفتار را تغییر می دهد. اگر تنها راه کنترل یک عامل نوشتن یک پیام طولانی باشد، کاربر دستورالعمل های مبهمی را به نماینده می دهد. با این حال، اگر او طرح، تفاوت، منابع، خطرات و اقدام بعدی را ببیند، می تواند دقیقاً مداخله کند.
یک زیرساخت عامل مناسب شامل سطوح کنترلی است:
- وضعیت فعلی؛
- طرح قابل ویرایش؛
- مصنوعات تولید شده؛
- تفاوت
- درخواست های تایید؛
- گاهشماری؛
- دکمه توقف؛
- دکمه امتحان مجدد؛
- مجوزهای قابل مشاهده
بی اهمیت به نظر می رسد، اما اینطور نیست. تفاوت بین "هوش مصنوعی خزنده" و "دستیار قابل اعتماد" اغلب فقط در این است که دستیار به شما نشان می دهد که کجا دست دارد.
پشته ذهنی
اگر بخواهم امروز آن را بکشم، حداقل پشته عامل این خواهد بود:
- مدل: استدلال، تولید، فراخوانی ابزار، در صورت لزوم چندوجهی.
- ارکستراسیون: حلقه، گام، برنامه ریز، سیاست، انسان در حلقه.
- زمان اجرا بادوام: گردش کار، صف، تلاش مجدد، مکث، از سرگیری.
- Sandbox: اجرای کد، سیستم فایل ایزوله، محدودیت ها، مصنوعات.
- لایه ابزار: MCP، API داخلی، مرورگر، پایگاه داده، مخزن.
- لایه هویت: OAuth، محدوده، راز، حسابرسی، سیاست.
- لایه حافظه: زمینه پروژه، بازیابی، دستورالعمل ها، انقضا.
- قابلیت مشاهده: ردیابی، بازپخش، ارزیابی، هزینه و معیارهای کیفیت.
- سطح محصول: چت به اندازه کافی، داشبورد در صورت نیاز، بررسی زمانی که مهم است.
چارچوب عاملی عمدتاً نقاط 2 و یک قطعه از نقطه 1 را پوشش می دهد. بقیه کار واقعی است.
کاری که من در عمل انجام خواهم داد
اگر تیمی به من میگفت «ما عوامل تولید میخواهیم»، من با ده نماینده شروع نمیکردم.
من با یک گردش کار کوچک، تکراری و قابل مشاهده شروع می کنم. به عنوان مثال: باز کردن PR های تعمیر و نگهداری، به روز رسانی اسناد از مسائل بسته، تهیه یک بررسی هفتگی، تریاژ اشکالات تکراری، تولید آزمایش برای فایل های آسیب دیده.
سپس محدودیت های بسیار واضحی را تعیین می کنم:
- بدون نوشتن بدون شاخه یا جعبه شنی.
- بدون اسرار در اعلان.
- ابزار در لیست مجاز.
- تایید انسان برای اقدامات خارجی؛
- ورود و ردیابی اجباری؛
- بودجه در هر اجرا؛
- خروجی همیشه قابل بازرسی
فقط در این صورت است که گسترش می دهم.
نمایندگان فقط به این دلیل که مدل ها اشتباه می کنند شکست نمی خورند. آنها شکست می خورند زیرا ما آنها را در محیط های مبهم، با مجوزهای گیج کننده و انتظارات نمایشی قرار می دهیم.
خواندن من
زیرساخت های نمایندگی به بهترین شکل خسته کننده است.
این بخشی نیست که باعث می شود در دمو دست بزنید. این بخشی است که به شما امکان می دهد در واقع از نسخه ی نمایشی صبح دوشنبه با افراد واقعی، داده های واقعی و پیامدهای واقعی استفاده کنید.
آینده کارگزاران تنها به این بستگی ندارد که چه کسی بهترین الگو را دارد. هر کسی که بهترین مکان را برای کار کردن او بسازد، تصمیم می گیرد: منزوی در هنگام آزمایش، متصل در صورت نیاز، همیشه قابل مشاهده، مجاز با معیارها و آنقدر متواضع که وقتی نمی داند متوقف شود.
اینجاست که ماموران دیگر اسباب بازی نیستند و به زیرساخت تبدیل می شوند.