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

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

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

این مقاله مفاهیم اصلی، روند تکامل مرحلهبهمرحلهی Agent ها، طبقهبندی معماری آنها و مسیر آیندهی نرمافزارهای Agentic را توضیح میدهد.

۱. تکامل گام به گام یک 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: ما Agent را مستقیماً به Telemetry و لاگ های سیستم متصل میکنیم تا بتواند خطاهای Application را مستقیما مشاهده کند.
• Multi-Step Reasoning: به جای انتظار دریافت پاسخ در یک نوبت (Turn)، به Agent اجازه میدهیم در یک حلقه (Loop) اجرا شود. مدل فکر میکند، اقدام می کند، نتایج را مشاهده میکند و گام بعدی خود را به صورت پویا اصلاح میکند.

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

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

گام ۱۳ تا ۱۶: Agent Harness در سطح Production

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

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

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

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

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

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) لاگهای اجرا (مسیرها) را بررسی میکند، علت شکست عامل اصلی را تشخیص میدهد و پرامپتها، Skillها یا Tool Pipelineهای Agent را بهصورت خودکار اصلاح میکند.
4. Phase 4: Co-Evolution of LLM and Harness مدل پایهای که Agent بر آن متکی است بهطور خاص متناسب با رفتار و ساختار 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 نیز میتواند در قالب زبان طبیعی پیاده سازی شود؟ در حالی که Agent Harnessهای سنتیِ مبتنی بر کد، رفتار قابلپیشبینی و deterministic دارند، مقرون به صرفه و ایمن هستند، محققان با موفقیت از "Natural-Language Harnesses" استفاده میکنند؛ جایی که قواعد Orchestration، مراحل تایید و انتقال وظایف Agent به صورت Skillهای قابلویرایش در فایلهای Markdown تعریف میشوند. در ساختارهای مدرن، مرز بین کانتکست پرامپت و زیر ساخت کنترلی هاردکد شده (Hardcoded scaffolding) مدام در حال محو شدن است.

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

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

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

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

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