عاملها هنوز با چالشهای کار در میان پنجرههای متنی متعدد مواجهاند. برای خلق یک چارچوب مؤثرتر برای عاملهای بلندمدت، به مهندسان انسانی الهام گرفتیم.
همچنان که عاملهای هوش مصنوعی توانمندتر میشوند، توسعهدهندگان بهطور فزایندهای از آنها میخواهند کارهای پیچیدهای را انجام دهند که به ساعتها یا حتی روزها نیاز دارد. با این حال، بهدست آوردن پیشرفت مستمر عاملها در چندین پنجره متنی همچنان یک مسأله باز است.
چالش اصلی عاملهای بلندمدت این است که باید در جلسات جداگانه کار کنند و هر جلسه جدید بدون هیچگونه حافظهای از اتفاقات پیشین آغاز میشود. تصور کنید پروژهٔ نرمافزاریای که مهندسان آن به صورت شیفتی کار میکنند؛ هر مهندس جدید بدون دانستن اینکه در شیفت قبلی چه اتفاقی افتاده، وارد میشود. از آنجا که پنجرههای متنی محدود هستند و اکثر پروژههای پیچیده نمیتوانند در یک پنجره تکمیل شوند، عاملها نیاز به راهی برای پر کردن فاصلهٔ بین جلسات کدنویسی دارند.
ما راهحل دوگانهای برای فعالسازی Claude Agent SDK طوری که در میان چندین پنجرهٔ متنی مؤثر عمل کند، توسعه دادیم: یک عامل مقداردهی اولیه که محیط را در اولین اجرا راهاندازی میکند، و یک عامل کدنویسی که وظیفهٔ پیشرفت گامبهگام در هر جلسه را دارد، در حالی که آثار واضحی برای جلسهٔ بعدی میگذارد. نمونههای کد را میتوانید در راهنمای سریع همراه پیدا کنید.
مشکل عاملهای طولانیمدت
Claude Agent SDK یک چارچوب قدرتمند و عمومی برای عاملهاست که در کدنویسی و همچنین سایر وظایفی که نیاز به استفاده از ابزارها برای جمعآوری زمینه، برنامهریزی و اجرا دارند، مهارت دارد. این SDK قابلیتهای مدیریت زمینه مانند فشردهسازی را دارد که به عامل امکان میدهد روی یک وظیفه کار کند بدون اینکه پنجرهٔ متنی تماماً مصرف شود. بهطور نظری، با این تنظیمات میتوان انتظار داشت که یک عامل بتواند بهطرز بینهایت طولانی به انجام کارهای مفید ادامه دهد.
اما فشردهسازی بهتنهایی کافی نیست. حتی یک مدل پیشرفتهٔ کدنویسی همچون Opus 4.5 که بر روی Claude Agent SDK در حلقهای بر چندین پنجرهٔ متنی اجرا میشود، اگر فقط یک اعلان کلی مانند «یک کپی از claude.ai بساز» دریافت کند، نمیتواند به تولید یک برنامهٔ وب با کیفیت تولیدی برسد.
شکستهای Claude در دو الگو ظاهر شد. نخستین الگو این است که عامل تمایل دارد کارهای بیش از حد را یکبار انجام دهد — بهعبارت دیگر سعی میکند برنامه را یکباره تکمیل کند. این معمولاً باعث میشود مدل در میانهٔ پیادهسازی بهدلیل اتمام پنجرهٔ متنی متوقف شود و جلسهٔ بعدی با ویژگیای نیمهپیادهسازیشده و بدون مستندات آغاز شود. سپس عامل مجبور میشود حدس بزند چه اتفاقی افتاده و زمان زیادی را صرف بازگرداندن برنامهٔ پایه به حالت قابل اجرا میکند. این حتی با فشردهسازی نیز رخ میدهد، چرا که همیشه دستورالعملهای کاملاً واضحی به عامل بعدی منتقل نمیشود.
الگوی دوم شکست اغلب در مراحل بعدی پروژه ظاهر میشود. پس از اینکه برخی ویژگیها تکمیل شدهاند، یک نمونهٔ بعدی از عامل به محیط نگاه میکند، پیشرفت صورت گرفته را میبیند و کار را بهعنوان پایانداده اعلام میکند.
این مسأله به دو بخش تقسیم میشود. اول، لازم است یک محیط اولیه راهاندازی کنیم که پایهٔ تمام ویژگیهای مورد نیاز یک اعلان را فراهم سازد و عامل را برای کار گامبهگام و ویژگی به ویژگی آماده کند. دوم، باید هر عامل را بهطرزی هدایت کنیم که پیشرفت گامبهگامی به سوی هدفش داشته باشد و در عین حال محیط را در وضعیت «تمیز» در پایان هر جلسه ترک کند. منظور از «وضعیت تمیز» کدی است که برای ادغام به شاخهٔ اصلی مناسب باشد: بدون باگهای بزرگ، کد منظم و مستند، و بهطور کلی، توسعهدهنده میتواند بهراحتی روی ویژگی جدید کار کند بدون اینکه ابتدا به پاکسازی آشفتگیهای نامربوط بپردازد.
در آزمایشهای داخلی، این مشکلات را با یک راهحل دوقسمتی حل کردیم:
- عامل مقداردهی اولیه: اولین جلسهٔ عامل از یک اعلان ویژه استفاده میکند که از مدل میخواهد محیط اولیه را راهاندازی کند: اسکریپت
init.sh، فایلclaude-progress.txtکه گزارشی از کارهای انجامشدهٔ عاملها حفظ میکند، و یک تعهد (commit) اولیهٔ گیت که نشان میدهد چه فایلهایی افزوده شدهاند. - عامل کدنویسی: هر جلسهٔ پس از آن از مدل میخواهد پیشرفت گامبهگام داشته باشد و سپس بهروزرسانیهای ساختاریافتهای بگذارد.1
درک کلیدی اینجا این بود که راهی پیدا شود تا عاملها بهسرعت وضعیت کار را هنگام آغاز با پنجرهٔ متنی جدید درک کنند؛ این کار از طریق فایل claude-progress.txt همراه با تاریخچهٔ گیت انجام میشود. الهام این روشها از شناخت کارهایی که مهندسان نرمافزار مؤثر روزانه انجام میدهند، گرفته شد.
مدیریت محیط
در راهنمای بهروزرسانیشدهٔ Claude 4 برای اعلانها، چندین روش برتر برای گردش کار چندپنجرهای را به اشتراک گذاشتیم، شامل ساختار چارچوبی که «اعلان متفاوتی برای اولین پنجرهٔ متنی» استفاده میکند. این «اعلان متفاوت» از عامل مقداردهی اولیه میخواهد محیط را با تمام زمینههای ضروری که عاملهای کدنویسی آینده برای کار مؤثر نیاز دارند، راهاندازی کند. در اینجا، به بررسی عمیقتری از برخی اجزای کلیدی چنین محیطی میپردازیم.
فهرست ویژگیها
برای رفع مسألهٔ اینکه عامل برنامه را یکباره تکمیل کند یا پیشازوقت پروژه را تمامشده در نظر بگیرد، از عامل مقداردهی اولیه درخواست کردیم فایلی جامع از نیازهای ویژگیها بر پایهٔ اعلان اولیهٔ کاربر بنویسد. در مثال کلون کردن claude.ai، این به معنای بیش از ۲۰۰ ویژگی بود، از جمله «کاربر میتواند یک گفتگوی جدید باز کند، پرسشی را تایپ کند، Enter بزند و پاسخ هوش مصنوعی را ببیند». این ویژگیها ابتدا به عنوان «ناموفق» علامتگذاری شدند تا عاملهای کدنویسی بعدی بتوانند چارچوب واضحی از عملکرد کامل داشته باشند.
{"category":"functional","description":"New chat button creates a fresh conversation","steps":["Navigate to main interface","Click the 'New Chat' button","Verify a new conversation is created","Check that chat area shows welcome state","Verify conversation appears in sidebar"],"passes":false}ما از عاملهای کدنویسی میخواهیم فقط وضعیت فیلد passes را در این فایل تغییر دهند و دستورالعملهای قطعی مانند «حذف یا ویرایش تستها غیرقابل قبول است زیرا میتواند به فقدان یا نقص عملکرد منجر شود» را به کار بکشیم. پس از برخی آزمایشها، به این نتیجه رسیدیم که استفاده از JSON برای این منظور مناسبتر است؛ زیرا احتمال تغییر یا بازنویسی نادرست فایلهای JSON توسط مدل کمتر از فایلهای Markdown است.
پیشرفت گامبهگام
با این چارچوب اولیهٔ محیط، از تکرار بعدی عامل کدنویسی خواسته شد تا فقط روی یک ویژگی در هر بار کار کند. این رویکرد گامبهگام برای مقابله با تمایل عامل به انجام بیش از حد کارها همزمان، کلیدی بود.
پس از کار گامبهگام، همچنان ضروری است که مدل محیط را پس از اعمال تغییرات کد در وضعیت «تمیز» ترک کند. در آزمایشهای ما، بهترین روش برای القای این رفتار این بود که از مدل بخواهیم پیشرفت خود را بهصورت تعهدات گیت با پیامهای توصیفی ثبت کند و خلاصهای از پیشرفت را در یک فایل پیشرفت بنویسد. این امکان را به مدل میداد تا با استفاده از گیت، تغییرات نادرست کد را بازگرداند و وضعیتهای کاری پایهٔ کد را بازیابی کند.
این روشها همچنین کارایی را افزایش دادند، زیرا نیاز به اینکه یک عامل مجبور به حدس زدن اتفاقات پیشین باشد و وقت خود را صرف بازگرداندن برنامهٔ پایه به حالت عملی میکرد، از بین میبرد.
آزمون
آخرین الگوی مهم شکست که مشاهده کردیم، تمایل Claude به علامتگذاری یک ویژگی بهعنوان کامل بدون آزمون مناسب بود. در صورت عدم وجود اعلان صریح، Claude تمایل داشت تغییرات کد اعمال کند و حتی با تستهای واحد یا دستورات curl در مقابل سرور توسعهٔ آزمایش انجام دهد، اما تشخیص نداد که ویژگی بهصورت انتها‑به‑انتها کار نمیکند.
در ساخت یک برنامهٔ وب، Claude عمدتاً پس از دریافت اعلان صریح برای استفاده از ابزارهای خودکار مرورگر و انجام تمام آزمونها همانند یک کاربر انسانی، در تأیید ویژگیها بهصورت انتها‑به‑انتها موفق عمل کرد.
ارائه اینگونه ابزارهای آزمون به Claude بهطور چشمگیری عملکرد را بهبود داد، چرا که عامل توانست باگهایی را که تنها از روی کد آشکار نبودند، شناسایی و رفع کند.
مسائل برخی هنوز باقیاند، همانند محدودیتهای بینایی Claude و ابزارهای خودکار مرورگر که شناسایی تمام انواع باگها را دشوار میسازد. برای مثال، Claude نمیتواند پنجرههای هشدار بومی مرورگر را از طریق Puppeteer MCP ببیند و ویژگیهایی که به این پنجرهها وابستهاند، بهدلیل این محدودیت، مستعد باگ بیشتری میشوند.
آشنایی سریع
با در دست داشتن تمام موارد فوق، از هر عامل کدنویسی خواسته میشود تا یک سری مراحل را برای شناخت وضعیت خود اجرا کند؛ برخی از این مراحل ساده هستند اما همچنان مفیدند:
- دستور
pwdرا اجرا کنید تا دایرکتوریای که در آن کار میکنید را ببینید. شما فقط میتوانید در این دایرکتوری فایلها را ویرایش کنید. - لاگهای گیت و فایلهای پیشرفت را بخوانید تا در جریان کارهای اخیراً انجامشده قرار بگیرید.
- فایل فهرست ویژگیها را مطالعه کنید و بالاترین ویژگی اولویتی که هنوز تکمیل نشده است را برای کار انتخاب کنید.
این رویکرد در هر جلسه باعث صرفهجویی در توکنهای Claude میشود، چرا که نیازی به کشف روش آزمون کد ندارد. همچنین مفید است که از عامل مقداردهی اولیه بخواهیم اسکریپت init.sh را تهیه کند که سرور توسعه را اجرا کند، و سپس پیش از پیادهسازی ویژگی جدید، یک تست پایهٔ انتها‑به‑انتها انجام دهد.
در مورد کلون claude.ai، این به این معنا بود که عامل همیشه سرور توسعهٔ محلی را راهاندازی میکرد و با Puppeteer MCP یک گفتگوی جدید را آغاز، پیام ارسال و پاسخ دریافت میکرد. این اطمینان میداد که Claude میتواند به سرعت تشخیص دهد که آیا برنامه در وضعیت خراب باقی مانده است یا خیر و بلافاصله هر باگی را رفع کند. اگر عامل بهجای این کار، بلافاصله به پیادهسازی ویژگی جدید میپرداخت، احتمالاً مشکل را تشدید میکرد.
با توجه به تمام این موارد، یک جلسهٔ معمولی با پیامهای زیر از دستیار آغاز میشود:
[Assistant] I'll start by getting my bearings and understanding the current state of the project. [Tool Use] <bash - pwd> [Tool Use] <read - claude-progress.txt> [Tool Use] <read - feature_list.json> [Assistant] Let me check the git log to see recent work. [Tool Use] <bash - git log --oneline -20> [Assistant] Now let me check if there's an init.sh script to restart the servers. <Starts the development server> [Assistant] Excellent! Now let me navigate to the application and verify that some fundamental features are still working. <Tests basic functionality> [Assistant] Based on my verification testing, I can see that the fundamental functionality is working well. The core chat features, theme switching, conversation loading, and error handling are all functioning correctly. Now let me review the tests.json file more comprehensively to understand what needs to be implemented next. <Starts work on a new feature>الگوهای شکست عامل و راهحلها
| مشکل | رفتار عامل مقداردهی اولیه | رفتار عامل کدنویسی |
|---|---|---|
| Claude پیروزی کل پروژه را خیلی زود اعلام میکند. | فایل فهرست ویژگیها را تنظیم میکند: بر اساس مشخصات ورودی، فایل JSON ساختاریافتهای با فهرست توضیحات ویژگیهای انتها‑به‑انتها تنظیم میکند. | در ابتدای هر جلسه فهرست ویژگیها را میخواند و یک ویژگی واحد برای شروع کار انتخاب میکند. |
| Claude محیط را در وضعیت با باگ یا پیشرفت مستند نشده رها میکند. | یک مخزن گیت اولیه و فایل یادداشتهای پیشرفت ایجاد میشود. | جلسه با خواندن فایل یادداشتهای پیشرفت و لاگهای تعهدات گیت آغاز میشود و یک تست پایه روی سرور توسعه اجرا میشود. در پایان جلسه، تعهد گیت و بهروزرسانی پیشرفت نوشته میشود. |
| Claude ویژگیها را پیشازوقت بهعنوان کامل علامتگذاری میکند. | فایل فهرست ویژگیها را تنظیم میکند. | تمام ویژگیها را خودبازبینی میکند. ویژگیها را فقط پس از آزمون دقیق به عنوان «موفق» علامتگذاری میکند. |
| Claude باید زمانی صرف کند تا متوجه شود چگونه برنامه را اجرا کند. | یک اسکریپت init.sh بنویسد که سرور توسعه را اجرا کند. |
جلسه را با خواندن init.sh آغاز میکند. |
خلاصهای از چهار الگوی رایج شکست و راهحلها در عاملهای هوش مصنوعی طولانیمدت.
کارهای آینده
این پژوهش یک مجموعهٔ امکانپذیر از راهحلها را در یک چارچوب عامل طولانیمدت نشان میدهد تا مدل بتواند پیشرفت گامبهگام را در میان چندین پنجرهٔ متنی انجام دهد. با این حال، سؤالاتی باز همچنان وجود دارد.
به ویژه، هنوز مشخص نیست که آیا یک عامل کدنویسی عمومی واحد در تمام زمینهها بهترین عملکرد را دارد یا اینکه با استفاده از معماری چندعاملی میتوان عملکرد بهتری بهدست آورد. بهنظر میرسد که استفاده از عاملهای تخصصی مانند عامل آزمون، عامل تضمین کیفیت یا عامل پاکسازی کد میتواند در کارهای فرعی در طول چرخهٔ توسعهٔ نرمافزار عملکرد بهتری داشته باشد.
علاوه بر این، این نمایه برای توسعهٔ برنامههای وب تمامپشته بهینهسازی شده است. جهتگیریهای آینده شامل تعمیم این نتایج به حوزههای دیگر میشود. احتمالاً میتوان برخی یا تمام این درسها را در کارهای طولانیمدت عاملمحور مورد نیاز در، برای مثال، پژوهشهای علمی یا مدلسازی مالی بهکار گرفت.
تشکر و تقدیر
نوشتهٔ جاستین یانگ. تشکر ویژه از دیوید هرشی، پریثوی راجاساکران، جرمی هادفیلد، نائیا بوسکل، مایکل تینگلی، جسه مو، جیک ایاتن، ماریوس بولهاندارا، مگی وو، پدرام نوید، نادین یاسر و الکس نوتوف برای مشارکتهایشان.
این کار نشانگر تلاشهای مشترک چندین تیم در Anthropic است که امکانپذیر ساختن Claude برای مهندسی نرمافزار خودمختار با افق طولانی را فراهم کردند، بهویژه تیمهای کد RL و Claude Code. افراد علاقهمند به مشارکت میتوانند از سایت https://anthropic.com/careers درخواست دهند.
پاورنویسها
۱. ما در این زمینه اینها را بهعنوان عاملهای جداگانه میشناسیم؛ چرا که آنها دارای اعلان اولیهٔ کاربر متفاوتی هستند. سیستم اعلان، مجموعه ابزارها، و چارچوب کلی عامل در غیر این صورت یکسان است.