پس از اینکه Agent وظیفه را بر عهده گرفت، اولین چیزی که باید سفت شود واحد کار است.

من اخیراً بحث های زیادی در مورد عامل می خوانم و در پایان همیشه به همین سوال برمی گردم: یک اثر را به چه کسی باید بدهد، قبل از تحویل چگونه باید بسته بندی شود و پس از بازگرداندن آن چگونه پذیرفته می شود. هنگامی که این مشکل در یک پروژه رخ می دهد، اولین چیزی که افزایش می یابد اغلب هزینه مدل نیست، بلکه پیچیدگی واحد کار است. اگر کار بیش از حد بزرگ بریده شود، مدل ظاهر می شود “انگار می تواند انجام شود”. مشکلات واقعی معمولاً در بازگشت، بازتولید و پذیرش نهفته است.

واحد کاری ابتدا باید امکان پذیرش داشته باشد

در چند روز گذشته، پس از کنار هم گذاشتن یادداشت های تکه تکه شده مارتین فاولر و چندین بحث در Thoughtworks Future of Software Retreat، واضح ترین احساس این است که مکالمه در جلسه به طور سطحی پراکنده بود، اما زیر آن در واقع فقط حول یک چیز می چرخید - واگذاری یک قطعه بزرگ از کار به Agent.

اتمام Kief Morris ساده ترین است. در جلسات مختلف بررسی کد، حوادث تولید، تقسیم کار تیمی و مسیریابی مدل مورد بحث قرار گرفت. به نظر می رسید که آنها در مورد چیزهای مختلفی صحبت می کردند، اما نتیجه یکسان بود: مردم اندازه “کار واحد” را تنظیم کرده اند. هرچه واحد بزرگتر باشد، تحویل آن آسان تر خواهد بود. هرچه واحد بزرگتر باشد، پس از بازگشت آن، پذیرش آن دشوارتر خواهد بود. این بدان معنا نیست که مدل نمی تواند این کار را انجام دهد، بلکه پیوند تأیید بعدی نمی تواند ابتدا نگه داشته شود.

به همین دلیل است که بارها و بارها از مهار یاد می شود. مدیریت زمینه، حسگرهای محاسباتی، آزمایش مبتنی بر ویژگی، روش‌های رسمی، این چیزها مانند ابزارهای اضافی به نظر می‌رسند، اما در واقع واحدهای کاری را جمع‌آوری می‌کنند. برخی از افراد agents.md را تا کمتر از 200 خط کنترل می کنند، نه برای اینکه به دنبال نظم در فرم باشند، بلکه برای اینکه سیستم را مجبور کنند فقط بخشی از اطلاعات را دریافت کند که واقعاً مفید است و واقعاً قابل بررسی است. متن خیلی شل است، البته Agent می تواند اجرا کند. اما پس از اجرا، هیچ کس نمی داند کدام لایه از محدودیت ها را بلعیده است.

خود میزبانی سطح کنترل را بالا می آورد

بحث های مربوط به مدل های خود میزبان نیز به همین موضوع اشاره دارد. پس از گران شدن توکن‌ها، الزامات انطباق سخت‌تر می‌شود و داده‌ها نمی‌توانند به بیرون درز کنند، مدل‌های منبع باز و مدل‌های محلی طبیعتا جذاب‌تر می‌شوند. اما هنگامی که خودتان مدل را حمل می کنید، مشکلاتی نیز خواهید داشت: GPU، اتاق استنتاج، مسیریابی، برگشت، تنظیم دقیق و انتخاب مدل. اینها خود قابلیت های مدل نیستند، اما تعیین می کنند که آیا سیستم در نهایت پایدار است یا خیر.

چنین هزینه هایی اغلب دست کم گرفته می شوند. بسیاری از تیم‌ها در ابتدا روی «اینکه مدل قوی‌تر است» تمرکز کردند، اما بعداً متوجه شدند که آنچه واقعاً زمان می‌برد، انتقال پایدار واحدهای کاری بین چندین مدل است. چه زمانی از یک مدل بزرگ، چه زمانی از یک مدل سبک و چه زمانی به سادگی از یک مدل محلی استفاده کنیم، این بستگی به ترجیح کلامی ندارد، بلکه به لایه ای از سطح کنترل بستگی دارد که می تواند برای انحراف و پوشش استفاده شود. بدون این لایه از چیزها، خود میزبانی از “ابتکار عمل” به “تعهد گرفتن پیچیدگی عملیات و تعمیر و نگهداری خود” می لغزد.

سیمون ویلیسون اشاره کرد که به مدل‌های قوی‌تر اجازه می‌دهد مدل‌های کوچک‌تری را برای انجام کار انتخاب کنند. این ایده نیز بسیار شبیه به کاری است که هواپیمای کنترل انجام می دهد. خود مدل لزوماً مرزهای هزینه تیم را نمی داند، اما سیستم می داند. رفتار با مدل به عنوان یک کارگزار و استفاده از آن برای تخصیص وظایف، به تحویل واقعی نزدیک‌تر است تا دنبال کردن کورکورانه یک مدل واحد برای تحویل فراگیر.

پذیرش و اهداف را نمی توان برون سپاری کرد

سم روبی “برای من سنگ بیاور” موضوع دیگری را آشکار کرد. دادن کار به مدل معادل افزودن یک مجری است. مسئولیت از بین نمی رود مدیران می‌توانند از LLM برای اکتشاف استفاده کنند، و می‌توانند اجازه دهند ابتدا مجموعه‌ای از راه‌حل‌های نامزد را بیرون بیاورد، اما معیارهای پذیرش نهایی هنوز باید به دست انسان بیفتد. اهداف پنهان دردسرسازترین هستند. مجوزها، حریم خصوصی، اقدامات مخرب و نشت زمینه اغلب در الزامات اصلی گنجانده نمی شوند.

بنابراین تست های انطباق اغلب مفیدتر از مشخصات هستند. مشخصات در توصیف “آنچه لازم است” خوب هستند، و تست ها در افشای “آنچه نمی تواند اتفاق بیفتد” بهتر هستند. این امر به ویژه در سیستم های عامل صادق است. این مدل می‌تواند اهداف صریح را به خوبی جبران کند، اما مرزهای ضمنی باید از طریق تأیید سخت‌تر تأیید شوند. تا زمانی که شرایط پذیرش در توضیحات مبهم باقی بماند، هر چه نماینده بیشتر انجام دهد، سیستم بیشتر به نظر می رسد که روی احتمال شرط بندی می کند.

بنابراین، بررسی کد، رسیدگی به حوادث و تعیین تکلیف، که قبلاً وظایف بسیار شبیه به انسان بودند، اکنون شروع به شکل‌های دیگر کرده‌اند. مدیران به طور مستقیم از مدل استفاده می کنند. در ظاهر، به نظر می رسد که کارایی را بهبود می بخشد، اما در سطح پایین، آنها در واقع یک روش مدیریت را تغییر می دهند: از مدیریت روش ها به مدیریت اهداف. اگر هدف به وضوح نوشته شده باشد، مدل فرصتی برای کار خواهد داشت. اگر هدف نامشخص باشد، مدل فقط ابهام را برای دیگران تشدید می کند.

تجربه و مهارت های خواندن هنوز در حال بهبود است

تخصص تعاملی و تخصص مشارکتی ذکر شده توسط دن دیویس نیز به این تغییر بسیار مرتبط است. این مدل می‌تواند مطالب زیادی را بخواند و قضاوت مناسبی داشته باشد، اما برای اینکه سیستم پایدار باشد، هنوز باید شخصی وجود داشته باشد که بتواند مشخصات را بخواند، نتایج را ببیند و بداند چه چیزی اشتباه است. نکته کلیدی در اینجا این نیست که مردم باید با مدل رقابت کنند تا ببینند چه کسی باهوش تر است، بلکه این است که مردم باید همچنان در موقعیتی قرار بگیرند که مرزها را مشخص کند.

وقتی صحبت از تحویل نرم افزار می شود، این موضوع ساده تر است. پس از آن که Agent زمام امور را به دست گرفت، کار انسانی کمتر به اجرای دستی و بیشتر بر روی تقسیم‌بندی وظایف، تعریف مرز، طراحی پذیرش و رسیدگی به استثناء می‌افتد. اینکه آیا می توان وظایف را واگذار کرد به وضوح تعیین می کند که آیا مدیریت زمینه بعدی، مسیریابی مدل و هماهنگ سازی ابزار ارزش انجام دادن دارند یا خیر. اگر واحد واضح نباشد، مهم نیست چند لایه وجود دارد، فقط مشکل را عقب می اندازد.

پس از خواندن این قطعات در چند روز گذشته، آنچه در ذهن من باقی می ماند نه نام مدل مشخصی است، نه یک چارچوب جدید، بلکه یک قضاوت ساده تر است: اولین چیزی که سیستم عامل نیاز به سفت کردن دارد، قابلیت مدل نیست، بلکه واحد کاری است. اگر واحد کوچکتر باشد، پذیرش سخت‌تر و مجوزها محدودتر باشد، سیستم این فرصت را خواهد داشت که پیچیدگی را در محدوده قابل کنترل نگه دارد.