‏هارنس اینجینیرینگ: مهندسیِ محیطِ دور عامل

نویسنده با فرمولی شروع می‌کنه که حالا استاندارد شده: عامل = مدل + هارنس. مدل همون زبان‌مدله و هارنس یعنی بقیهٔ چیزها؛ حلقهٔ اجرا، ابزارها، سندباکس، چیدن کانتکست، مجوزها، تست‌هایی که باید پاس شن، state ای که بعد از کرش زنده می‌مونه، تریس‌ها و سقف بودجه. تو مقاله اومده که وقتی سورس Claude Code لو رفت، حدود ۵۱۲ هزار خط TypeScript توش شمرده شد و بخشی که واقعاً با مدل حرف می‌زنه سهم کوچیکی از اون بود؛ باقیش هارنسه.

نکتهٔ اصلی هم همینه: تو مدل رو کنترل نمی‌کنی، اجاره‌ش می‌کنی و هر چند ماه یه بار از زیر دستت عوض می‌شه. ولی هارنس کاملاً مال خودته، تو ریپوی خودت و زیر تست خودت. پس هر بار عامل تو پروداکشن خطا می‌ده دو تا راه داری: منتظر مدل بهتر بمونی، یا محیط رو جوری عوض کنی که اون خطا ساختاری غیرممکن شه. نویسنده می‌گه دومی مهندسیه و اولی فقط امیدواریه.

ریشهٔ اصطلاح رو هم دنبال می‌کنه: test harness تو تست نرم‌افزار، evaluation harness تو بنچمارک مدل‌ها، و مفهوم environment تو یادگیری تقویتی. هر سه یه شکل مشترک دارن؛ جزء جالبِ ماجرا کوچیکه و داربستِ دورش کارو ممکن می‌کنه. تو تقسیم‌بندی‌ای که از Böckeler نقل می‌کنه، هارنس داخلی چیزیه که فروشندهٔ ابزار می‌ده و هارنس بیرونی چیزیه که خودت روش سوار می‌کنی؛ و هر جزء یا guide حساب می‌شه (قبل از عمل) یا sensor (بعد از عمل).

مرز بین یه رَپر ساده و هارنس هم اندازه و پیچیدگی نیست، حلقهٔ بسته‌ست: تا وقتی خروجی مدل خودِ محصوله، رَپره؛ از لحظه‌ای که خروجی مدل تصمیمیه که سیستم اجراش می‌کنه و نتیجه‌ش برمی‌گرده تو کانتکست، همهٔ دغدغه‌های هارنس فعال می‌شن. حلقهٔ ساده‌ای که همه اولش می‌نویسن چیزی شبیه اینه:

def run(task: str) -> str:
    messages = [{"role": "user", "content": task}]
    while True:
        response = model.call(messages, tools=TOOLS)
        messages.append(response)
        if not response.tool_calls:
            return response.text

این کد کار می‌کنه، ولی به گفتهٔ نویسنده یه حادثهٔ پروداکشنِ در راهه؛ و بقیهٔ مقاله دقیقاً چیزهاییه که توش غایبه. سنسور باید ترنسفورمر باشه نه لوله — خروجی خام و ۶۰۰۰ توکنیِ pytest رو نده به مدل، یه سیگنال کوتاه با یه خط سرتیتر و اقدام بعدی بده. transcript فقط کشه و حقیقت تو یه ledger ماندگار می‌شینه که هر نوبت از نو رندر می‌شه، نه اینکه روی هم انباشته شه.

عامل هم حق نداره خودش بگه کارم تموم شد؛ پایان اجرا باید با معیارهای خروجِ ماشینی تأیید شه، وگرنه «همهٔ تست‌ها پاس شدن» می‌تونه فقط یه جملهٔ محتمل باشه. و آخرین قانون: به‌جای پرامپت‌نویسیِ سفت‌وسخت‌تر، فضای عمل رو تنگ کن تا اشتباه از اون مسیر اصلاً ممکن نباشه.

نکات کلیدی:

• عامل = مدل + هارنس؛ تو پروژهٔ واقعی تقریباً همه‌چیز هارنسه
• مدل اجاره‌ایه و عوض می‌شه، هارنس مال خودته و زیر تست خودته
• مرز رَپر و هارنس، بسته شدن حلقه‌ست نه اندازه و پیچیدگی
• سنسور باید سیگنال کوتاه و قابل‌اقدام بده، نه خروجی خام
• transcript کشه؛ حالت واقعی تو ledger ماندگار می‌مونه
• پایان کار رو سیستم تأیید می‌کنه، نه ادعای مدل