مسئلهی واقعی ایجنتهای کدنویس
بحث معمول دربارهی ایجنتهای هوش مصنوعی این است که «آیا کدشان به اندازهی کافی خوب است؟» ولی تیمهایی که واقعاً ایجنت را وارد جریان کارشان کردهاند، معمولاً با مشکل دیگری روبهرو میشوند.
ایجنت وقتی نیازمندی مبهم است، حدس میزند. و حدسش را با همان لحن قاطعی ارائه میدهد که یک کار کاملاً مشخص را. بعد آن حدس وارد شاخهی اصلی میشود، دو هفته بعد کسی میپرسد «چرا اینطوری پیادهسازی شده؟» و جواب این است که هیچکس تصمیم نگرفته بود — فقط کسی جلویش را نگرفته بود.
مشکل، کیفیت مدل نیست. مشکل این است که در جریان کار، جایی برای «نمیدانم» وجود ندارد و دروازهای بین کار ایجنت و وضعیت تمامشده نیست.
سه چیزی که یک ایجنت را از ابزار به همتیمی تبدیل میکند
۱. هویت مستقل
ایجنت باید حساب کاربری خودش را داشته باشد، نه اینکه با کلید یک نفر دیگر کار کند.
در WKFGo این با پرچم is_agent روی کاربر انجام میشود. کاربر ایجنت را یک انسان میسازد (که در minted_by ثبت میشود)، و از آن به بعد هر کاری که ایجنت میکند به نام خودش ثبت میشود.
چرا این مهم است؟ چون بدون آن، تاریخچهی پروژه دروغ میگوید. وقتی سه ماه بعد میخواهید بفهمید چه بخشی از کد را آدم نوشته و چه بخشی را ماشین — و این سؤالی است که دیر یا زود پرسیده میشود — به تفکیک واقعی نیاز دارید، نه به حدس زدن از روی سبک کامیتها.
مزیت جانبی: ایجنت هم مثل هر عضو دیگری زیر همان سیستم دسترسی است. اگر نمیخواهید ایجنت به ماژول مالی دسترسی داشته باشد، همانطور که برای یک کارآموز محدودش میکنید، برای او هم محدود میکنید.
۲. راهی برای پرسیدن
این مهمترین قطعه است و بیشتر از همه نادیده گرفته میشود.
ابزار ask_human به ایجنت اجازه میدهد وسط کار متوقف شود و سؤال بپرسد. سؤال بهصورت یک آیتم مسدودکننده روی همان تسک ثبت میشود، انسان از صفحهی تسک جواب میدهد، و جواب در بستهی زمینهی ایجنت ظاهر میشود تا از همانجا ادامه بدهد.
تفاوتش با «ایجنت در چت سؤال میپرسد» این است که سؤال جایی ثبت میشود که تصمیم به آن تعلق دارد — روی تسک، در تاریخچه، قابل جستجو. شش ماه بعد که کسی میپرسد «چرا این فیلد اختیاری است؟»، جواب کنار خود تسک است، نه گمشده در یک گفتوگوی قدیمی.
در عمل باید در دستورالعمل ایجنت صریح بگویید کِی بپرسد. چیزی شبیه این:
اگر معیار پذیرش چند تفسیر دارد که به پیادهسازیهای متفاوت منجر میشود، حدس نزن —
ask_humanرا صدا بزن و منتظر جواب بمان.
۳. دروازهای قبل از «تمامشده»
ایجنت نباید بتواند تسک را خودش تمامشده اعلام کند.
وقتی هویتی که به سرور MCP وصل شده یک ایجنت باشد، فراخوانی mark_done به submit_for_review تبدیل میشود. تسک به وضعیت «منتظر تأیید» میرود و در صف /task-approvals یک انسان مینشیند.
بازبین سه گزینه دارد: تأیید، رد با توضیح، یا درخواست تغییر. اگر تغییر بخواهد، تسک با بازخورد برمیگردد به صف ایجنت — و چون در my_queue کارهای ردشده اول فهرست میآیند، ایجنت اول سراغ همانها میرود.
هر دور بازبینی بهصورت یک رکورد جداگانه ثبت میشود، پس صفحهی تسک یک خط زمانی از رفتوبرگشتها نشان میدهد، نه انبوهی از کامنت که بازبین باید در آن بگردد.
چطور راهاندازی کنید
قدم اول: کاربر ایجنت بسازید. در بخش کاربران، یک حساب با پرچم ایجنت بسازید. اسمش را واضح بگذارید — مثلاً «ایجنت بکاند» — تا در بورد بشود تشخیصش داد.
قدم دوم: دسترسیاش را محدود کنید. از کم شروع کنید: خواندن تسک، بهروزرسانی وضعیت، ساخت کامنت. مالی و مدیریت کاربران را ندهید. بعداً اگر لازم شد اضافه کنید.
قدم سوم: کلید بسازید و به ویرایشگر وصل کنید. همان مسیر اتصال IDE با MCP است، فقط با کلید ایجنت بهجای کلید خودتان.
قدم چهارم: دستورالعمل بنویسید. این جایی است که بیشتر تیمها کم میگذارند. دستورالعمل باید بگوید کِی بپرسد، کِی کار را بفرستد، و چه چیزی خارج از حوزهی اوست:
قبل از شروع،
get_context_packرا برای تسک صدا بزن و معیار پذیرش را بخوان. اگر ابهامی هست که به پیادهسازیهای متفاوت منجر میشود،ask_humanبزن و صبر کن. وقتی تمام شد،submit_for_reviewبزن — تسک را خودت تمامشده اعلام نکن. شناسهی تسک را در پیام کامیت بنویس.
قدم پنجم: صف تأیید را جدی بگیرید. اگر کارهای ارسالشده سه روز در صف بمانند، ایجنت بیفایده میشود. یک نفر باید مالک این صف باشد.
چه چیزی را بسنجید
سه عدد بیشتر از بقیه میگویند این کار میکند یا نه:
نرخ تأیید در دور اول. چند درصد از کارهای ارسالی بدون درخواست تغییر تأیید میشوند؟ اگر پایین است، معمولاً مشکل از مدل نیست — معیار پذیرش تسکها به اندازهی کافی مشخص نیست.
تعداد سؤالهای ask_human در هر تسک. اگر صفر است، نگران باشید: یعنی ایجنت دارد حدس میزند. اگر خیلی زیاد است، یعنی تسکها بیش از حد بزرگ یا مبهماند.
زمان انتظار در صف تأیید. این عددی است که معمولاً اول خراب میشود و کل جریان را کند میکند.
هیچکدام از اینها معیار «کیفیت هوش مصنوعی» نیستند. همهشان معیار سلامت جریان کار شما هستند — که نکتهی اصلی همین است.
اشتباهات رایج
دسترسی کامل از روز اول. ایجنتی که میتواند تسک حذف کند یا رکورد مالی بزند، ریسکی است که لازم نیست بپذیرید.
نداشتن دستورالعمل کِی-بپرس. بدون آن، ایجنت پیشفرض حدس میزند، چون کار نیمهتمام رها کردن به نظرش شکست میآید.
استفاده از کلید یک انسان برای ایجنت. تاریخچه را خراب میکند و ممیزی را غیرممکن.
صف تأییدی که مالک ندارد. گلوگاه جدید میسازید و بعد نتیجه میگیرید که «ایجنت کند است».
تسکهای خیلی بزرگ. ایجنت روی کار مشخص و محدود خوب عمل میکند. «سیستم احراز هویت را بازنویسی کن» نتیجهی خوبی نمیدهد.
سؤالات متداول
آیا این یعنی ایجنت جای توسعهدهنده را میگیرد؟
نه، و اتفاقاً این الگو عکس آن را میگوید: هر کار ایجنت از دست یک انسان رد میشود. چیزی که کم میشود کار تکراری است، نه قضاوت.
اگر ایجنت سؤال بپرسد و کسی جواب ندهد؟
تسک مسدود میماند و در گزارش سن کار دیده میشود. این ویژگی است نه باگ — بهتر از این است که ایجنت حدس بزند و شما دو هفته بعد بفهمید.
چند ایجنت میتوانم داشته باشم؟
محدودیتی نیست. بعضی تیمها یکی برای بکاند و یکی برای فرانتاند دارند، با دسترسیهای متفاوت.
آیا کار ایجنت در گزارشها جدا دیده میشود؟
بله. چون ایجنت کاربر مستقلی است، در گزارش عملکرد و نقشهی بار مثل هر عضو دیگری ظاهر میشود.
جمعبندی
ایجنت هوش مصنوعی وقتی مفید میشود که مثل یک عضو جوان تیم با او رفتار کنید: هویت مشخص، دسترسی محدود، اجازهی پرسیدن، و بازبینی قبل از اینکه کارش تمامشده حساب شود.
هیچکدام از اینها به مدل بهتر نیاز ندارد. همهشان به جریان کار بهتر نیاز دارند.