در دنیای به سرعت در حال توسعه هوش مصنوعی، ما اغلب درباره قدرت مدلهای پایه مانند GPT-5 یا Claude 4 میشنویم. اما اگر تا به حال تلاش کرده باشید یک Large Language Model (LLM) خام را وادار به انجام یک کار پیچیده و چندمرحلهای کنید—مانند رفع یک باگ در یک مخزن کد، پیمایش در یک مرورگر وب، یا مدیریت یک گردش کار سرتاسری (end-to-end workflow)—میدانید که یک مدل عریان به سرعت با محدودیت مواجه میشود.

اینجاست که Agent Harness وارد میدان میشود.

یک AI Agent فقط یک LLM نیست؛ بلکه ترکیبی از یک LLM و یک Agent Harness است. در حالی که LLM به عنوان «مغز» عمل میکند، Harness نقش سیستم عصبی، اسکلت و دستها را ایفا میکند و به AI اجازه میدهد تا با جهان تعامل داشته باشد.

این مقاله شما را با مفاهیم، تکامل گام به گام سیستمهای Agent، طبقهبندی ساختاری آنها و مسیر آینده نرمافزارهای Agent خودکار آشنا میکند.

۱. تکامل گام به گام یک Agent Harness

برای درک اینکه یک Agent Harness چه کاری انجام میدهد، میتوانیم مسیر تبدیل یک فراخوانی ساده LLM به یک سیستم عاملی (Agent) کاملاً مستقل و بالغ را دنبال کنیم.

گام ۱ تا ۴: عصر Prompting

• Raw LLM: ما کار را تنها با یک مدل پایه شروع میکنیم که متن را پردازش کرده و متن تحویل میدهد.
• User Prompt: ما یک پرسوجو از سمت کاربر اضافه میکنیم تا به مدل جهت بدهیم.
• System Prompt: ما یک دستورالعمل سیستمی (System Prompt)—یعنی دستورالعملهای پنهانی که پرسونای مدل، مرزها و قوانین تعامل را تعریف میکنند—معرفی میکنیم.
• Context Engineering: ما Prompt را با تکنیکهایی مانند Multi-shot Examples (نمایش نمونههایی از رفتار مطلوب) و دستورالعملهای Chain-of-thought غنی میکنیم تا مدل را مجبور کنیم استدلال خود را گام به گام توضیح دهد.

گام ۵ تا ۷: ابزارهای پویا و استدلال چندمرحلهای

• Search Engine: ما به مدل ابزاری برای جستجو در موتورهای سرچ خارجی میدهیم تا به جای تکیه بر دانش ایستا و وزنهای آموزشی خود، اطلاعات لحظهای و واقعی را دریافت کند.
• System Integrations: ما تلمتری (Telemetry) مستقیم و لاگهای سیستم را متصل میکنیم تا هوش مصنوعی بتواند خطاها را مستقیماً مشاهده کند.
• Multi-Step Reasoning: به جای انتظار دریافت پاسخ در یک نوبت (Turn)، به Agent اجازه میدهیم در یک حلقه (Loop) اجرا شود. مدل فکر میکند، اقدام میکند، نتایج را مشاهده میکند و گام بعدی خود را به صورت پویا اصلاح میکند.

گام ۸ تا ۱۲: محیط اجرا (Operating Environment)

• Tool Interfaces و MCP: به Agent رابطهای ساختاریافتهای داده میشود تا از طریق پروتکلهای استاندارد مانند Model Context Protocol (MCP) با سیستمعامل محلی، مرورگرهای وب یا APIها تعامل داشته باشد.
• Lifecycle & Context Management: بخش Harness چرخه حیات اجرا را کنترل میکند—آغاز به کار محیطهای امن (Sandboxes)، ذخیره نقاط بازیابی (Checkpoints) برای احیا پس از خرابیها، و مدیریت پویای پنجره محدود Context مدل.
• Sub-agents: برای اهداف پیچیده، Agent اصلی میتواند چندین Sub-agent تخصصی را برای انجام کارهای مجزا و کوچکتر راهاندازی کند.

گام ۱۳ تا ۱۶: بسترساز (Harness) در سطح تولید صنعتی (Production-Grade)

• Governance و Security: یک محیط امن (Sandbox) به دور محیط اجرا کشیده میشود تا از آسیبهای ناشی از اجرای کدهای ناامن یا حملات Prompt Injection جلوگیری شود. مرزهای سختگیرانه به جای تکیه بر فرمانبرداری مدل از پرامپت، به عنوان محافظهای کدنویسیشده اعمال میشوند.
• Memory و Skills Management: عامل (Agent) یک لایه حافظه پایدار برای به خاطر سپردن تلاشهای قبلی و یک مخزن «مهارتها» (Skills Registry) به دست میآورد—که اساساً خطمشیهای زبان طبیعی و با قابلیت استفاده مجدد هستند که به Agent آموزش میدهند چگونه وظایف خاص را انجام دهد.
• Observability: توسعهدهندگان دید کاملی نسبت به هر فراخوانی ابزار، هزینه Tokenها و مراحل استدلال میانی به دست میآورند تا الگوهای شکست و خطا را عیبیابی کنند.

۲. طبقهبندی یک Agent Harness مدرن

در بررسی معماریهای پیشرفته ساختارهای Agent، بخش Harness معمولاً به مسئولیتهای اصلی تقسیم میشود. یک طبقهبندی پرکاربرد به نام ETCLOVG وجود دارد که هفت لایه یک Agent Harness آماده برای محیط تولید را دستهبندی میکند:

۳. چهار فاز تکامل Harness

این نگهدارندهها (Agent Harnesses) چگونه مهندسی میشوند و به مرور زمان چگونه بهبود مییابند؟ پژوهشگران سیستمهای عاملی را به چهار فاز تکاملی مجزا تقسیم میکنند:

1. Phase 1: Single-Turn Prompting مدل با یک Prompt واحد که شامل تمام Context است در یک نوبت پرسش میشود (مانند تولید کدهای ساده).
2. Phase 2: Multi-Turn Loop عامل در یک حلقه تعاملی کار میکند. ابزاری را فعال میکند، بازخورد فوری و قابلاقدام (مانند خطاهای کامپایلر) را مشاهده کرده و اقدام بعدی خود را تنظیم میکند.
3. Phase 3: The Harness as an Optimization Target توسعهدهندگان دیگر به صورت دستی پرامپتهای سیستم یا دستورالعملهای عامل را ویرایش نمیکنند، بلکه سیستم خودش را بهبود میبخشد. یک «عامل ارزیاب» (Evaluator Agent) لاگهای اجرا (مسیرها) را بررسی میکند، علت شکست عامل اصلی را تشخیص میدهد و به طور خودکار پرامپتها، مهارتها یا خطوط انتقال ابزارِ عامل را برای رفع خطا ویرایش میکند.
4. Phase 4: Co-Evolution of LLM and Harness مدل LLM زیرین به طور خاص برای هماهنگی با Harness آموزش میبیند. از طریق یادگیری تقویتی (Reinforcement Learning) یا فرآیند Fine-tuning، مدل کارهایی را که پیش از این به کدهای پیچیده در لایه Harness نیاز داشتند، درونیسازی میکند. با گذشت زمان، مرز بین مدل و زیرساخت محو میشود.

۴. بحثهای کلیدی مهندسی

همزمان با اینکه صنعت به سمت ساخت نرمافزارهای خودکارتر پیش میرود، چند سوال کلیدی رویکرد تیمهای مهندسی را در طراحی Agentها شکل میدهد:

کارهای کوتاهمدت در برابر کارهای بلندمدت (Short-Horizon vs. Long-Horizon)

• وظایف Short-horizon (مانند پاسخ به یک سوال سریع، نوشتن یک تابع ساده) به شدت به توانایی خام مدل زیرین بستگی دارد تا سیستم Harness.
• وظایف Long-horizon (مانند توسعه یک وباپلیکیشن کامل از ابتدا، رفع مشکلات و مسائل نرمافزاری در گیتهاب) به طرز چشمگیری به کیفیت Harness وابسته هستند. بدون مدیریت پیشرفته Context و محافظت در برابر انحراف از هدف (State-drift)، حتی بهترین مدلها نیز با گذشت زمان هدف نهایی را گم میکنند.

ظهور Natural-Language Harnesses

آیا یک Harness باید کاملاً با کدهای قدرتمند (مثل Python یا TypeScript) نوشته شود یا خود Harness نیز میتواند در قالب زبان طبیعی پیادهسازی شود؟ در حالی که نگهدارندههای سنتیِ مبتنی بر کد، قطعی (Deterministic)، مقرونبهصرفه و ایمن هستند، محققان با موفقیت از "Natural-Language Harnesses" استفاده میکنند؛ جایی که قوانین هماهنگی، مراحل تایید و انتقال وظایف عامل به عنوان فایلهای مکتوب Markdown و تحت عنوان «مهارتها» (Skills) نوشته میشوند. در ساختارهای مدرن، مرز بین کانتکست پرامپت و اسکلتبندیهای هاردکد شده (Hardcoded scaffolding) مدام در حال محو شدن است.

سازگاری مدل و هاردنس (Model-Harness Compatibility)

بنچمارکها عملکرد ترکیب همزمان مدل و Harness را اندازهگیری میکنند، نه فقط کیفیت LLM به تنهایی را. یک مدل متنباز ضعیفتر که روی یک Harness بسیار بهینهشده و اختصاصی برای یک دامنه خاص اجرا میشود، اغلب میتواند از یک مدل پیشرو و بسته (Closed-source) که روی یک Harness عمومی و ضعیف اجرا شده است، پیشی بگیرد.

نتیجهگیری: آینده در همتکاملی (Co-Evolution) است

ساخت یک Agent Harness در سطح جهانی به شدت به منابع انبوه، تستهای دقیق، محیطهای امن (Sandboxing) و پروتکلهای ارزیابی نیازمند است.

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