مفهوم Harness Engineering کلید گمشده تولید نرم‌افزار با ایجنت‌ها در سال ۲۰۲۶ است. فرمول ساده‌ست:
Agent = Model + Harness.
هارنس یعنی هر چیزی که مدل نیست؛ از محدودیت‌ها و ابزارها گرفته تا لوپ‌های فیدبک و فایل‌های استیت. اگر مدل را CPU در نظر بگیریم، هارنس نقش Operating System را بازی می‌کند که منابع را مدیریت می‌کند، کارهای تکراری را Schedule می‌کند و اجازه نمی‌دهد مدل در Context Window خودش غرق شود. واقعیت این است که در پروژه‌های بزرگ، محیطی که مدل در آن کار می‌کند، بسیار مهم‌تر از خود مدل است.

فایل‌های AGENT.md یا CLAUDE.md ابزارهای اصلی این معماری در مخازن کد هستند. این‌ها فایل‌های Markdown هستند که در ریشه پروژه قرار می‌گیرند تا ایجنت در شروع هر سشن بدونه کجاست، کانونشن‌های تیم چیست و معماری فعلی چه وضعیتی دارد. جالب اینجاست که برای رهگیری پیشرفت (Progress Tracking)، استفاده از فایل‌های JSON بسیار پایدارتر از Markdown عمل می‌کند؛ چون ایجنت‌ها در سشن‌های طولانی کمتر تمایل دارند ساختار JSON را تصادفی خراب کنند. این فایل‌ها در واقع RAM ایجنت هستند که بین ری‌استارت‌های مختلف سشن، ثابت می‌مانند.

جدا کردن مرحله Planning از Execution یک اصل حیاتی در Harness Engineering است. ایجنتی که همزمان نقشه می‌کشد و کد می‌زند، خروجی غیرقابل اعتمادی دارد. در هارنس‌های سینیور، ابتدا یک Sprint Contract بسته می‌شود؛ یعنی یک ایجنت (Planner) پیشنهاد می‌دهد که چه تغییری می‌خواهد بدهد و ایجنت دوم (Evaluator) آن را نقد می‌کند. فقط بعد از توافق، مرحله پیاده‌سازی شروع می‌شود. این یعنی Context beats Instructions؛ نشان دادن نقشه راه و وضعیت فعلی فایل‌ها به ایجنت، صد برابر بهتر از نوشتن پرامپت‌های طولانی و انتزاعی جواب می‌دهد.

پدیده Harness Decay واقعیتی است که باید به آن عادت کنیم. هر قطعه در هارنس، در واقع فرضیه‌ای است درباره اینکه مدل چه کاری را نمی‌تواند انجام دهد. با آپدیت شدن مدل‌ها (مثلاً از Opus 4.5 به 4.8)، بخش‌هایی از هارنس که قبلاً ضروری بودند تبدیل به Overhead می‌شوند چون مدل خودش هوشمندتر شده و می‌تواند آن مرحله را حذف کند. به نظر من، مهندسی که هارنس می‌سازد باید با ذهنیت Build to delete کار کند؛ یعنی هر قطعه را جوری طراحی کند که به محض قوی‌تر شدن مدل، بتوان آن را حذف کرد تا هزینه توکن بیهوده بالا نرود.

هزینه اجرای یک لوپ کامل با هارنس مهندسی شده ممکن است ۲۰ برابر بیشتر از یک پرامپت ساده باشد، اما خروجی یک نرم‌افزار واقعی با UI تمیز و منطق درست است، نه یک دموی شکسته که فقط در اسکرین‌شات خوب به نظر می‌رسد. مهندس هوش مصنوعی واقعی در سال ۲۰۲۶ کسی نیست که پرامپت‌های زیباتری می‌نویسد، بلکه کسی است که بهترین Runtime را برای هوش طراحی می‌کند تا ایجنت بتواند در یک محیط ایزوله (Sandbox)، کد بزند، تست بگیرد و در صورت خطا، خودش را اصلاح کند.

📃 مستندات Anthropic درباره ارزیابی ایجنت‌ها:
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

📃 مقاله OpenAI درباره لوپ‌های ایجنتی Codex:
https://openai.com/index/unrolling-the-codex-agent-loop/

📃 چارچوب کاری Harness Engineering در arXiv:
https://arxiv.org/abs/2605.13357

به نظر من، دوران کل‌کل سر اینکه کدام مدل بهتر است تمام شده. برنده کسی است که هارنس قوی‌تری بسازد. اگر دیتابیس یا مخزن کد شما شلخته باشد، حتی قوی‌ترین مدل دنیا هم خروجی آشغال تحویل می‌دهد. سرمایه‌گذاری روی خوانایی کد برای ایجنت (Harnessability)، ارزشمندترین کاری است که یک تیم فنی می‌تواند انجام دهد.

🛠 Join @LLMEngineers Community