یک دستیار کدنویسی مبتنی بر مدل زبانی بزرگ مستندات و رابط برنامهنویسی لنگچین۴جی را دریافت کرد و از آنها برای طراحی و پیادهسازی یک سیستم کدنویسی چندعاملیِ شبیه به خود استفاده کرد. عامل کدنویسیِ ساختهشده در این فرا-آزمایش، باگهای واقعی را برطرف کرد، تستها را پشت سر گذاشت و روند اجرایی خود را شفاف ساز کرد.
فرا-آزمایشی برای ساختن هوش مصنوعی توسط هوش مصنوعی
ایده ساده اما دلهرهآور بود: مستندات فریمورک LangChain4j را به یک دستیار کدنویسی دادیم و از او خواستیم نسخهای از خودش را بسازد. هدف این بود که سیستم چندعاملی طراحی کند که بتواند مانند یک مهندس انسانی کد بنویسد، تست کند و اشکالزدایی نماید.
اینکه یک مدل زبانی بتواند نسخهای از خود را از روی مستندات بسازد، دو نکته مهم درباره لنگچین۴جی را آشکار میکند. نخست اینکه رابط برنامهنویسی این فریمورک به اندازه کافی برای مدل قابل فهم بود تا مستقیماً از آن استفاده کند. دوم اینکه فریمورک هماهنگی کافی را فراهم میکند تا سیستم تولیدشده بتواند یک وظیفه اشکالزدایی واقعی را از ابتدا تا انتها اجرا کند.
این پروژه همچنین فرصتی برای آزمایش فشار ابزارهای مانیتورینگ جدید لنگچین۴جی فراهم کرد. وقتی به یک هوش مصنوعی اجازه میدهید هوش مصنوعی دیگری بسازد، باید دقیقاً بدانید زیر پوست چه میگذرد.
کدنویسی بر اساس حس و حال؛ طراحی سیستم عاملیتمحور
برای شروع، پرامپت سادهای نوشتیم: «API و قابلیتهای فریمورک عاملیتمحور لنگچین۴جی را از مستندات و کد منبع آن مطالعه کن و یک کدنویس عاملیتمحور بر اساس آن طراحی کن که همزاد خودت باشد.»
پس از چند دقیقه پردازش، دستیار تصمیم گرفت الگوی ناظر (Supervisor) لنگچین۴جی بهترین گزینه برای این کار است و معماری اولیهای ارائه داد:
public interface SupervisorCoderSystem {
@SupervisorAgent(description = """
A multi-agent coding assistant that can explore codebases,
plan implementations, write/edit code, and run builds/tests.
It orchestrates specialized sub-agents to fulfill coding requests.
""",
subAgents = {
ExplorerAgent.class,
PlannerAgent.class,
Implementer.class,
ExecutorAgent.class,
})
@Override
String code(@K(UserRequest.class) String request,
@K(WorkingDirectory.class) String workingDirectory);
@SupervisorRequest
static String request(@K(UserRequest.class) String userRequest,
@K(WorkingDirectory.class) String workingDirectory) {
return "Using '" + workingDirectory + "' as your working directory, "
+ "fulfill the following user request: " + userRequest;
}
}
چهار زیرعامل تخصصی برای چرخه کدنویسی
دستیار کدنویسی چهار زیرعامل استفادهشده توسط ناظر را همراه با پیامهای سیستمی و کاربری آنها طراحی و توسعه داد:
- عامل کاوشگر (Explorer): کد موجود را بررسی و تحلیل میکند. ابزار اختصاصی این عامل، یک کاوشگر سیستم فایل است.
- عامل برنامهریز (Planner): برنامهای برای اقدامات لازم ایجاد میکند و مسیر پیادهسازی را ترسیم مینماید.
- عامل پیادهساز (Implementer): اقدامات را طبق برنامه اجرا میکند و کد را مینویسد یا ویرایش میکند. این عامل به یک ویرایشگر کد مجهز است.
- عامل اجراکننده (Executor): کد تولیدشده را با کامپایل و اجرای آن به کار میگیرد و نتایج را ارزیابی میکند.
نتایج برای اولین تکرار چشمگیر بود. اگر قبلاً با دستیاران کدنویسی حرفهای کار کرده باشید، میدانید که این تقریباً همان الگویی است که در دنیای واقعی استفاده میشود. آنها عموماً همین چهار اقدام را انجام میدهند و سپس برای رسیدن به هدف، آنها را به شکلی شبیه به ناظر هماهنگ میکنند.
الگوی گردشکار در برابر الگوی ناظر؛ سرعت در برابر انعطافپذیری
مقایسه دو الگوی کلیدی هوش مصنوعی عاملیتمحور نشاندهنده یک تبادل اساسی است. الگوی گردشکار (Workflow) که ساختار سختگیرانهتری دارد، با حذف سربار هماهنگی ناشی از LLM، سه برابر سریعتر از الگوی ناظر اجرا میشود.
الگوی ناظر به مدل زبانی اجازه میدهد تصمیم بگیرد کدام زیرعامل در هر مرحله فعال شود. این خودمختاری بیشتر انعطافپذیری بالایی ایجاد میکند، اما هر بار که LLM باید تصمیمی بگیرد، زمان و هزینه بیشتری مصرف میشود. در مقابل، الگوی گردشکار مسیر اجرای عاملها را از پیش تعیین میکند و نیاز به تصمیمگیریهای میانبرنامهای را به حداقل میرساند.
شفافیت عملکرد با MonitoredAgent
یکی از چالشهای اصلی در سیستمهای چندعاملی، درک رفتار آنها در زمان اجرا است. لنگچین۴جی با معرفی رابط MonitoredAgent این مشکل را هدف گرفته است. این رابط امکان دریافت گزارشی واضح از فراخوانیهای عامل و توپولوژی سیستم را فراهم میکند.
وقتی یک هوش مصنوعی در حال ساخت هوش مصنوعی دیگری است، این سطح از شفافیت حیاتی است. گزارشهای مانیتورینگ نشان میدهند کدام عامل در چه زمانی فعال شده، چه ابزارهایی فراخوانی شدهاند و چگونه دادهها بین عاملها جریان یافتهاند. این اطلاعات برای دیباگ، بهینهسازی و درک رفتار نوظهور سیستم ضروری است.
تأثیر انتخاب مدل زبانی بر موفقیت سیستم
یکی از کشفیات مهم این آزمایش، نقش مدل زبانی انتخابی بود. طراحی یکسان عامل با یک مدل قدیمیتر و ارزانتر با ورود به حلقه فراخوانی ابزار (Tool-Calling Loop) با شکست مواجه شد. عامل بهطور مداوم ابزارها را فراخوانی میکرد بدون اینکه پیشرفتی به سمت حل مسئله داشته باشد.
اما همان طراحی با یک مدل جدیدتر، وظیفه رفع باگ را با موفقیت تکمیل کرد. این تفاوت نشان میدهد که توانایی استدلال و تصمیمگیری مدل زبانی زیرین، تأثیری حیاتی بر عملکرد سیستمهای عاملیتمحور دارد. یک مدل ضعیفتر میتواند حتی بهترین معماری را نیز به ناکارآمدی بکشاند.
آینده عاملهای خودساز
این آزمایش پنجرهای رو به آیندهای است که در آن عاملهای هوشمند نه تنها کد مینویسند، بلکه سیستمهای عاملیتمحور جدیدی را طراحی و پیادهسازی میکنند. قابلیت خوانایی API لنگچین۴جی برای مدلهای زبانی، این فریمورک را به بستری مناسب برای چنین تلاشهایی تبدیل میکند.
پروژه حاصل این آزمایش در مخزن عمومی در دسترس است و میتواند نقطه شروعی برای پژوهشهای بیشتر در زمینه عاملهای خودساز و سیستمهای چندعاملی خودمختار باشد. پرسش اصلی اکنون این است: اگر یک هوش مصنوعی بتواند خودش را بسازد، چه مرزی برای تکامل این سیستمها باقی میماند؟
