در دو سال گذشته، توصیههای شغلی دربارهٔ عاملهای هوش مصنوعی عمدتاً حول یادگیریِ خوب دستور دادن به آنها بوده است. دیگر این مهارت، مهارت کمیابی نیست. مهارت کمیاب، ساختن چارچوبی است که یک عامل درون آن قرار میگیرد — چیزی که increasingly به آن harness گفته میشود — و این کار آنقدر مشخص و دشوار است که دارد بهجای یک مسئولیت جانبیِ «فرد هوش مصنوعی» در یک تیم، به شرح شغلی مستقل خودش تبدیل میشود.
روشنترین شرح عمومی از آنچه این کار واقعاً دربرمیگیرد، در خبرنامهٔ Lenny آمده است؛ این خبرنامه مستند کرده که ابزار مدیریت محصول ChatPRD چگونه چارچوبی ساخته تا باگهای Sentry را بهطور خودکار اشکالزدایی کند. اگر در حال سنجیدن این هستید که آیا در این حوزه تخصص پیدا کنید یا نه، خواندن کامل این مطلب ارزش دارد، چون به نکتهای اشاره میکند که بهراحتی ممکن است نادیده گرفته شود: مدل هرگز گلوگاه نبود. تیم از Claude Agent SDK بهعنوان پایه استفاده کرد و سپس بخش عمدهٔ تلاش مهندسی خود را صرف یک رابط کاربری ترمینال سفارشی و مجموعهای از آداپتورها کرد که عامل را به Sentry، Linear، GitHub و Vercel متصل میکردند. این کار، در مقیاس کوچک، همان شغل است. چهار سیستم، چهار طرح احراز هویت متفاوت، چهار شکل دادهٔ متفاوت، و رابطی که به انسان اجازه میدهد بدون مراقبت لحظهبهلحظه از هر گام، کار عامل را ببیند و در آن مداخله کند.
«چارچوب» در عمل به چه اجزایی تقسیم میشود
اگر میخواهید بفهمید آیا ارزش دارد این مجموعهمهارت را بسازید یا نه، بهتر است آن را به بخشهایی تفکیک کنید که برایشان جداگانه استخدام میکنند، یا دستکم در مصاحبه جداگانه ارزیابی میشوند:
- طراحی مجوزها. تصمیمگیری دربارهٔ اینکه عامل اجازه دارد چه کارهایی را بدون نظارت انجام دهد (خواندن یک تیکت، پیشنویس کردن یک PR) و کدام کارها به حضور انسان در چرخه نیاز دارند (ادغام، استقرار، حذف، خرج کردن پول) — و تبدیل این تصمیم به سیاست واقعی در کد، نه دستورالعملی در پرامپت که مدل ممکن است زیر فشار آن را نادیده بگیرد. این کار بیشتر به مهندسی کنترل دسترسی نزدیک است تا نوشتن پرامپت.
- آداپتورهای ابزار. پوششدهندههای نازک و بهخوبی آزمودهشده پیرامون هر سیستم خارجی (Sentry، Linear، GitHub، Vercel یا هر مجموعهفناوری دیگری که شرکت شما استفاده میکند) که نیت عامل را به یک فراخوانی امن و اعتبارسنجیشدهٔ API تبدیل میکنند و پاسخ را نیز به چیزی تبدیل میکنند که مدل بتواند دربارهاش استدلال کند. این همان مهندسی نرمافزار معمولی است — مدیریت خطا، تلاش مجدد، اعتبارسنجی شِما — که برای مصرفکنندهای جدید به کار گرفته شده است.
- رابط کاربری ترمینال یا کنسول. راهی برای اینکه انسان ببیند عامل چه کاری انجام میدهد، اقدامات را تأیید یا رد کند و وقتی عامل گیر میکند وارد عمل شود. ChatPRD یک رابط سفارشی ساخت؛ بسیاری از تیمها بهجای آن از کنسولهای آمادهٔ عامل استفاده خواهند کرد، اما همچنان کسی باید تصمیم بگیرد چه چیزی نمایش داده شود، چه چیزی پنهان بماند و انجام چه کاری به کلیک نیاز داشته باشد.
- انتخاب ابزار در مقیاس بالا. مطلبی از Machine Learning Mastery به نکتهای اشاره میکند که اگر چیزی فراتر از یک دمو میسازید، دانستنش ارزشمند است: دقت عامل در فراخوانی ابزارها معمولاً وقتی فهرست ابزارها از حدود دوازده گزینه فراتر میرود، افت میکند — مدل شروع میکند به فراخوانی اشتباه ابزارها، توهمسازی پارامترها یا متوقف شدن هنگام فراخوانیهای نامعتبر. راهکارهای کاهشی که در آن مطلب آمدهاند (محدود کردن ابزارهایی که حتی در یک زمینهٔ مشخص قابل مشاهدهاند، جستوجوی ابزار مبتنی بر بازیابی، مسیریابی به عاملهای فرعیِ تخصصی، گامهای برنامهریزی صریح، منطق بازگشت و چارچوبهای معیارسنجی ابزار برای شناسایی پسرفتها) خودشان فهرستی از کارهایی هستند که مهندس چارچوب باید بلد باشد پیادهسازی کند، نه اینکه فقط دربارهشان بداند.
- مهندسی زمینه و حافظه. همان منبع تمایزی را مطرح میکند که باید درونی شود: مهندسی زمینه (اینکه چه چیزهایی و در کجا وارد یک فراخوانی استنتاج واحد میشوند) و مهندسی حافظه (اینکه چه چیزهایی در طول نشستها پایدار میمانند، چگونه ذخیره میشوند و چگونه بازیابی میشوند) دو حوزهٔ متفاوت با حالتهای شکست متفاوتاند. ادعای منبع این است که بیشتر خرابیها در عاملهای بلندمدت و چندنشستی، به یکی گرفتن این دو برمیگردد — اینکه حافظهٔ نشست را صرفاً زمینهٔ بیشتر بدانیم یا برعکس — بهویژه در نقطهای که سیستم تصمیم میگیرد چه چیزی را بازیابی کند.
شواهدی که نشان میدهند این واقعاً نقشی قابل تأمین مالی است — نه فقط حوزهای ویژهٔ علاقهمندان
بدبینها بهطور منطقی خواهند پرسید که آیا «مهندس چارچوب» یک شغل است یا فقط وظیفهای درون شغل فرد دیگری. دو داده از این جمعبندی نشان میدهند که این نقش به سمت حالت اول حرکت میکند. نخست، تیم Aspire مایکروسافت — گروهی ۱۰نفره — از GitHub's Agentic Workflows برای خودکارسازی PRهای مستندسازی بین مخزنها استفاده کرد و طی دو انتشار، ۸۲ PR را با میانهٔ ۴۴.۸ ساعت پس از انتشار PR محصول مربوطه ادغام کرد؛ آن هم بدون نیروی انسانی جدید و بدون آموزش مجدد فرایندها. این تیم کوچک دقیقاً به این دلیل اهرم بزرگی ایجاد کرد که کسی روی چارچوب کار سرمایهگذاری کرده بود (تعریفهای گردشکار، مسیریابی بازبینی و منطق آغازگرها)، نه اینکه مهندسان بهصورت دستی PRهای مستندات را بنویسند. دوم، پروژهٔ SkillOpt از Microsoft Research فایلهای «مهارت» عامل — دستورالعملها و محدودیتهایی که نحوهٔ رفتار عامل را در چارچوبش شکل میدهند — را چیزی میداند که باید بهصورت نظاممند بهینه شود، نه اینکه دستی ویرایش شود؛ این پروژه گزارش میدهد که در هر ۵۲ خانهٔ یک شبکهٔ معیارسنجی (شش معیار، هفت مدل، سه حالت اجرا) بهترین یا همتراز بهترین بوده است و مهارتهای بهینهشده در مدلها و چارچوبهای مختلف انتقال پیدا کردهاند. چه این ابزار مشخص به استاندارد تبدیل شود و چه نشود، این موضوع نشان میدهد صنعت دارد پیکربندی چارچوب را بهعنوان یک مصنوع مهندسی با ابزارها و معیارهای سنجش مستقل خودش تلقی میکند — همان مسیری که «DevOps» را از مجموعهای از اسکریپتهای بداهه به یک حوزهٔ تخصصی تبدیل کرد.
اکنون زیرساختی نیز بهطور مشخص برای این لایه در حال ساخته شدن است. قابلیتهای تازهمعرفیشدهٔ «Managed Agents» گوگل در Gemini API — اجرای پسزمینه و ناهمگام، یکپارچهسازی با سرورهای MCP راه دور، فراخوانی توابع سفارشی و تازهسازی اعتبارنامهها در تعاملات مختلف — عملاً لولهکشیِ ازپیشساختهای برای همان مشکلاتی هستند که تیم ChatPRD دستی حل کرد. این الگوی معمولی است: چیزی که یک تیم امسال بهصورت سفارشی میسازد، یک فروشندهٔ پلتفرم سال آینده آن را به محصول تبدیل میکند. این موضوع نقش مهندسی چارچوب را حذف نمیکند؛ کف مهارت لازم را بالاتر میبرد و شغل را از نوشتن هر آداپتور از صفر، به سمت یکپارچهسازی و پیکربندی primitives مدیریتشده سوق میدهد؛ مشابه اینکه زیرساخت ابری مهندسان عملیات را حذف نکرد، بلکه چیزی را که وقتشان را صرف آن میکردند تغییر داد.
اگر هدف شما رسیدن به این نقش است، این موضوع برایتان چه معنایی دارد
اگر میخواهید برای این کار معتبر به نظر برسید، چند مورد مشخص و قابلبررسی را در نمونهکار یا رزومهٔ خود قرار دهید: یک آداپتور را از ابتدا تا انتها برای یک API واقعی که تحت کنترل شما نیست بسازید (از جمله احراز هویت، مدیریت خطا و محدودیت نرخ، نه فقط یک دمو در مسیر ایدهآل)؛ یک مدل مجوز برای عاملی طراحی و مستند کنید که اقدامات خواندن/پیشنهاد دادن/انجام دادن را از هم متمایز کند و توضیح دهد چرا هر مرز در جای فعلی قرار دارد؛ و یک رابط بازبینی بسازید یا پیکربندی کنید که در آن انسان پیش از اجرای اقدامات عامل آنها را تأیید کند، چون این همان بخشی است که بیشتر شرکتها پیش از اجازه دادن به عامل برای دست زدن به محیط تولید بر آن اصرار خواهند کرد. اگر در حال ارزیابی پیشنهاد شغلی مهندسی چارچوب یا تعیین دامنهٔ مسئولیتهای خود هستید، مشخصاً بپرسید چه کسی مالک مدل مجوزهاست، چه کسی مالک آداپتورهاست و چه کسی مالک سطح بازبینی انسانی است — در بسیاری از تیمها در حال حاضر این سه مورد مالک مشخصی ندارند، و دقیقاً همین شکافی است که این نقش برای پر کردن آن در حال شکلگیری است.
یک نکتهٔ احتیاطی را باید صریحاً بیان کرد: هیچیک از منابع بالا عددی دربارهٔ بازار استخدام برای این عنوان مشخص ارائه نمیکنند و «مهندس چارچوب» هنوز عنوان شغلیای نیست که در آگهیها ببینید — این نقش در عنوانهایی مانند «مهندس زیرساخت هوش مصنوعی»، «مهندس پلتفرم عامل» یا صرفاً «مهندس ارشد بکاند، سامانههای هوش مصنوعی» ظاهر میشود. این را مجموعهمهارتی بدانید که باید بسازید و دقیق توصیف کنید، نه عنوانی که در LinkedIn جستوجو کنید.
