بسیاری از توسعه‌دهندگان وقتی یک مدل زبانی پیشرفته را وارد ریپازیتوری کد خود می‌کنند، انتظار دارند با یک پرامپت دقیق کارهای مهندسی را بی‌نقص تحویل دهد؛ اما در عمل با کدهای ناقص، تستهای ردشده یا تغییرات ناخواسته در فایلهای نامربوط روبه‌رو می‌شوند. مشکل اصلی در توانایی مدل نیست، بلکه در غیاب ساختاری است که فرآیند کار، وضعیت، محدوده و بازخورد را برای آن مدیریت کند.
در این درس یاد می‌گیرید که چگونه با طراحی یک «میز کار» (Workbench) استاندارد شامل هفت سطح اساسی، رفتار غیرقابل‌پیش‌بینی مدلهای زبانی را مهار کنید و خروجی‌هایی ایمن، تکرارپذیر و آماده‌ی پروداکشن به دست آورید.
یک مدل توانمند به‌تنهایی کافی نیست. ایجنت‌های قابل‌اعتماد به یک میز کار (workbench) نیاز دارند: دستورالعملها، وضعیت، دامنه، بازخورد، اعتبارسنجی، بازبینی و تحویل کار. اگر این‌ها را کنار بگذارید، حتی یک مدل مرزی (frontier model) هم کدی تولید میکند که انتشارش در محیط پروداکشن امن نیست.
اهداف یادگیری
- تفکیک توانمندی مدل از قابلیت اطمینان در اجرا.
- نام بردن از سطوح هفت‌گانه‌ی میز کار که امکان انتشار کد یک ایجنت را تعیین می‌کنند.
- مقایسه‌ی اجرای صرفاً مبتنی بر پرامپت با اجرای هدایت‌شده توسط میز کار، روی یک تسک کوچک در ریپازیتوری.
- تهیه‌ی گزارش حالت‌های شکست که در آن، هر سطح نادیده‌گرفته‌شده به عارضه‌ای که ایجاد کرده نگاشت شده باشد.
صورت مسئله
یک مدل مرزی را داخل یک ریپازیتوری واقعی می‌اندازید و میخواهید اعتبارسنجی ورودی را اضافه کند. مدل 4 فایل را باز میکند، کدی به‌ظاهر درست می‌نویسد، اعلام موفقیت میکند و متوقف می‌شود. شما تست‌ها را اجرا می‌کنید؛ 2 تست رد می‌شوند. فایل سومی هم دستکاری شده که اصلاً ربطی به اعتبارسنجی نداشته است. هیچ ردپایی هم نیست که نشان دهد ایجنت چه فرضیاتی داشته، اول چه چیزی را امتحان کرده، یا چه کارهایی باقی مانده است.
مدل در پایتون اشتباه نکرده بود؛ در خودِ «کار» اشتباه کرده بود. هیچ ایده‌ای نداشت چه چیزی «انجامشده» به‌حساب می‌آید، کجا اجازه‌ی نوشتن دارد، کدام تست‌ها مرجع نهایی هستند، یا چطور نشست (session) بعدی قرار است کار را پی بگیرد.
این باگ مدل نیست؛ باگ میز کار است. فضایی که ایجنت را در بر گرفته، فاقد اجزایی است که تولید خروجی یکباره را به مهندسی قابل‌اعتماد و قابل‌ازسرگیری تبدیل می‌کنند.
مفهوم اصلی
میز کار همان محیط کاری است که هنگام انجام تسک، دور مدل را میگیرد. این میز کار 7 سطح (surface) دارد:
| سطح | چه چیزی را با خود حمل میکند | پیامد غیبت آن |
|---|---|---|
| دستورالعملها (Instructions) | قوانین آغازین، کارهای ممنوعه، تعریف «انجامشده» (definition of done) | ایجنت حدس می‌زند انتشار یعنی چه |
| وضعیت (State) | تسک فعلی، فایلهای دستکاری‌شده، موانع، اقدام بعدی | هر نشست از صفر شروع می‌شود |
| دامنه (Scope) | فایلهای مجاز، فایلهای ممنوع، معیارهای پذیرش | تغییرات به کدهای نامربوط نشت میکند |
| بازخورد (Feedback) | خروجی واقعی دستورات که در حلقه ثبت می‌شود | ایجنت پس از دریافت خطای 400 اعلام موفقیت میکند |
| اعتبارسنجی (Verification) | تست‌ها، لینتر، تست سریع صحت‌سنجی (smoke run)، بررسی دامنه | کدِ «ظاهراً درست» به شاخه‌ی main می‌رسد |
| بازبینی (Review) | بررسی دوباره با نقشی متفاوت | سازنده خودش به تکلیف خودش نمره می‌دهد |
| تحویل کار (Handoff) | چه چیزی تغییر کرد، چرا، چه کارهایی باقی مانده است | نشست بعدی باید همه‌چیز را از نو کشف کند |
میز کار مستقل از مدل است. می‌توانید مدل را عوض کنید و این سطوح را نگه دارید؛ اما نمی‌توانید سطوح را بردارید و قابلیت اطمینان را حفظ کنید.
حلقه روی فایل وضعیت بسته می‌شود، نه روی تاریخچه‌ی چت. چت فرار است؛ ریپازیتوری، سیستم ثبت نهایی (system of record) شماست.
میز کار در برابر مهندسی پرامپت
پرامپت به مدل می‌گوید در این نوبت گفت‌وگو چه میخواهید. میز کار به مدل می‌گوید چطور در طول نوبت‌ها و در میان نشستهای مختلف کار را پیش ببرد. بیشتر ماجراهای شکست ایجنت‌ها، در واقع شکست‌های میز کار هستند که لباس مهندسی پرامپت پوشیده‌اند.
میز کار در برابر فریم‌ورک
فریم‌ورک به شما یک محیط اجرا (Runtime) مانند LangGraph، AutoGen یا Agents SDK می‌دهد. میز کار به ایجنت جایی برای کار کردن درون آن محیط اجرا می‌دهد. به هر دو نیاز دارید. این بخش آموزشی روی دومی تمرکز دارد.
استدلال بر پایه‌ی اصول اولیه، نه طبقه‌بندی‌های شرکت‌های تجاری
این روزها مطالب زیادی درباره‌ی «مهندسی بستر آزمایشی» (harness engineering) نوشته می‌شود. Addy Osmani، OpenAI، Anthropic، LangChain، Martin Fowler، MongoDB، HumanLayer، Augment Code، Thoughtworks، لیست awesome در walkinglabs و جریان پیوسته‌ای از مقالات Medium و Hacker News همگی به آن می‌پردازند. این مراجع بر سر مرزهای یک بستر آزمایشی، محدوده‌ی دامنه و واژگانِ مورد استفاده اختلاف دارند. نیازی نیست طرف یکی از آن‌ها را بگیریم. این سطوح هفت‌گانه در اصل یک لایه‌ی کاربری (UX) هستند؛ در زیربنای هر میز کار، همان عناصر پایه‌ی سیستم‌های توزیع‌شده قرار دارند که هر سیستم بک‌اند قابل‌اعتمادی را سر پا نگه می‌دارند.
برچسب ایجنت را یک لحظه کنار بگذارید. اجرای یک ایجنت، فرآیندی محاسباتی است که در طول زمان، میان پروسه‌ها و بین ماشین‌ها حرکت میکند. برای قابل‌اعتماد کردن آن، به همان عناصر پایه‌ای نیاز دارید که هر سیستم پروداکشنی می‌خواهد.
| عنصر پایه | ماهیت آن چیست | چه نقشی برای یک ایجنت ایفا میکند |
|---|---|---|
| تابع (Function) | گرداننده‌ی دارای نوع (Typed handler). تا حد امکان محض (pure). مالک ورودی‌ها و خروجی‌های خود است. | فراخوانی ابزار، بررسی قانون، مرحله‌ی اعتبارسنجی، صدا زدن مدل |
| ورکر (Worker) | پروسه‌ی بلندمدت که مالک یک یا چند تابع و چرخه‌ی حیات آن‌هاست | سازنده، بازبین، مدل اعتبارسنج، سرور MCP |
| محرک (Trigger) | منبع رویدادی که تابعی را فراخوانی میکند | تیک حلقه‌ی ایجنت، درخواست HTTP، پیام صف، کرون (cron)، تغییر فایل، هوک (hook) |
| محیط اجرا (Runtime) | مرزی که تعیین میکند چه چیزی کجا با چه مهلت زمانی (timeout) و منابعی اجرا شود | پروسه‌ی Claude Code، محیط اجرای LangGraph، کانتینر ورکر |
| پروتکل HTTP / RPC | سیم رابط میان فراخواننده و ورکر | پروتکل فراخوانی ابزار، درخواست MCP، ای‌پی‌آی مدل |
| صف (Queue) | بافر پایا میان محرک و ورکر؛ مدیریت پس‌فشار (back-pressure)، تلاش مجدد، پایاپایی (idempotency) | تابلوی تسک‌ها، لاگ بازخورد، صندوق ورودی بازبینی |
| پایایی نشست (Session persistence) | وضعیتی که از کرش‌ها، ری‌استارت‌ها و تعویض مدلها جان سالم به در می‌برد | فایل agent_state.json، چک‌پوینت‌ها، پایگاه‌های داده‌ی کلید-مقدار، خودِ ریپازیتوری |
| سیاست مجوزدهی (Authorization policy) | چه کسی می‌تواند چه تابعی را با چه دامنه‌ای صدا بزند | فایلهای مجاز/ممنوع، مرزهای تاییدیه‌ها، لیست قابلیت‌های MCP |
حالا این سطوح هفت‌گانه‌ی میز کار را روی آن عناصر پایه نگاشت کنید:
- دستورالعملها — سیاست + متادیتای تابع. قوانین در واقع بررسی‌ها (توابع) هستند. مسیریاب (
AGENTS.md) سیاستی است که به راه‌اندازی محیط اجرا ضمیمه شده است. - وضعیت — پایایی نشست. یک مخزن کلیددار که محیط اجرا در هر مرحله آن را می‌خواند؛ فایل، دیتابیس کلید-مقدار یا پایگاه داده؛ معنای پایایی مهم است، نه بستر ذخیره‌سازی.
- دامنه — سیاست مجوزدهی به ازای هر تسک. الگوهای مجاز/ممنوع یک فهرست کنترل دسترسی (ACL) هستند. تاییدیه‌های الزامی هم یک شبکه‌ی دسترسی به شمار می‌روند.
- بازخورد — لاگ فراخوانی‌ها که درون یک صف نوشته می‌شود. هر فراخوانی شل یک رکوردِ مانا و قابل‌بازپخش است.
- اعتبارسنجی — یک تابع. روی ورودی‌ها قطعی (deterministic) است. هنگام بستن تسک فعال می‌شود. با رویکرد عدم قطعیت بسته می‌شود (fails closed).
- بازبینی — یک ورکر مجزا با مجوز فقط-خواندنی روی دست‌سازه‌های سازنده و مجوز فقط-نوشتنی روی گزارش‌های بازبینی.
- تحویل کار — یک رکورد مانا که محرک پایان نشست آن را تولید میکند. محرک راه‌اندازیِ نشست بعدی آن را می‌خواند.
خود حلقه‌ی ایجنت ورکری است که رویدادها را دریافت میکند (پیام کاربر، نتیجه‌ی ابزار، تیک تایمر)، توابعی را فرا می‌خواند (ابتدا مدل، سپس ابزارهایی که مدل انتخاب کرده)، رکوردهایی ثبت میکند (وضعیت، بازخورد) و محرک‌هایی را صادر میکند (اعتبارسنجی، بازبینی، تحویل کار). هیچ رمز و رازی نیست؛ دقیقاً شبیه یک پردازنده‌ی جاب (job processor) کار میکند.
الگوهای رایج، ترجمه‌شده به عناصر پایه
تمام الگوهای محبوب بستر آزمایشی به این 8 عنصر پایه تبدیل می‌شوند. جدول تطبیق زیر این موضوع را نشان می‌دهد:
| الگوی ارائه‌دهندگان تجاری یا جامعه | ماهیت واقعی آن چیست |
|---|---|
| حلقه‌ی رالف (Ralph Loop در Claude Code، Codex، کتاب agentic_harness) — تزریق مجدد نیت اصلی به پنجره‌ی بافتار جدید، وقتی ایجنت می‌خواهد زود متوقف شود | محرکی که تسک را با بافتاری تر و تمیز دوباره در صف می‌گذارد؛ پایایی نشست، هدف را جلو می‌برد |
| برنامه‌ریزی / اجرا / اعتبارسنجی (PEV) | 3 ورکر، هر کدام برای یک نقش، که با وضعیت و صف در میان فازها ارتباط دارند |
| تفکیک بستر و محاسبات (OpenAI Agents SDK، آوریل 2026) — جداسازی لایه‌ی کنترل از لایه‌ی اجرا | بازتعریف همان تفکیک لایه‌ی کنترل از لایه‌ی داده؛ دهه‌ها قبل از مطرح شدن نام ایجنت وجود داشته است |
| پاسپورت باز ایجنت (OAP، مارس 2026) — امضا و بررسی هر فراخوانی ابزار طبق سیاستی اعلانی پیش از اجرا | سیاست مجوزدهی که ورکرِ پیش‌از‌اقدام آن را اعمال میکند، همراه با صف حسابرسیِ امضاشده |
| راهنماها و سنسورها (Birgitta Böckeler / Thoughtworks) — قوانین پیش‌خوران (feedforward) + مشاهده‌پذیری پس‌خوران (feedback) | سیاست مجوزدهی + توابع اعتبارسنجی + ردگیری‌های مشاهده‌پذیری |
| فشرده‌سازی تدریجی 5 مرحله‌ای (مهندسی معکوس Claude Code، آوریل 2026) | ورکری برای مدیریت وضعیت که مثل کرون روی پایایی نشست اجرا می‌شود تا آن را داخل بودجه نگه دارد |
| هوک‌ها / میان‌افزارها (LangChain، Claude Code) — شنود فراخوانی‌های مدل و ابزار | محرک‌ها + توابعی که مسیر فراخوانی محیط اجرا را می‌پوشانند |
| مهارت‌ها در قالب Markdown با افشای تدریجی (Anthropic، Flue) | ریجستری توابعی که در آن متادیتای تابع درست سر وقت (JIT) وارد بافتار می‌شود |
| ایجنت‌های ساندباکس (Codex، Sandcastle، Vercel Sandbox) | لایه‌ی محاسباتی: محیط اجرایی با فایل‌سیستم، شبکه و چرخه‌ی حیات کاملاً ایزوله |
| سرورهای MCP | ورکر‌هایی که توابع را روی یک RPC پایدار ارائه می‌دهند، همراه با لیست قابلیت‌ها به عنوان مجوز |
هر ردیف این جدول، رسیدن جامعه‌ی ایجنت‌ها به عنصر پایه‌ای است که قبلاً در سیستم‌های توزیع‌شده نام مشخصی داشت و حالا نام جدیدی گرفته است؛ برچسب‌هایی کاربردی برای بازاریابی، ولی ناکارآمد به عنوان واژگان مهندسی.
آمارهای واقعی چه می‌گویند
ادعای برتری بستر آزمایشی بر خودِ مدل، حالا پشتوانه‌ی عددی دارد. دانستن این ارقام ارزش دارد، چون تنها استدلال درست در برابر این حرف است که می‌گویند «فقط صبر کن تا مدل باهوش‌تری بیاید».
- در Terminal Bench 2.0 — با مدلی یکسان، تغییر بستر آزمایشی رتبه‌ی یک ایجنت کدنویسی را از فراتر از 30 تیم اول به رتبه‌ی 5 رساند (LangChain، Anatomy of an Agent Harness).
- در Vercel — حذف 80% از ابزارهای ایجنت، نرخ موفقیتش را از 80% به 100% رساند (MongoDB).
- در Harvey — دقت ایجنت‌های حقوقی صرفاً از طریق بهینه‌سازی بستر آزمایشی بیش از 2 برابر شد (MongoDB).
- 88% پروژه‌های ایجنت هوش مصنوعی سازمانی به محیط پروداکشن نمی‌رسند. ریشه‌ی این شکست‌ها دور محیط اجرا می‌چرخد، نه استدلال مدل (preprints.org، Harness Engineering for Language Agents، مارس 2026).
- بررسی بنچمارک سال 2025 روی 3 فریم‌ورک متن‌باز محبوب نشان داد تکمیل تسک حدود 50% بود؛ در شرایط بافتار طولانی، نرخ عملکرد WebAgent از 40-50% به زیر 10% سقوط کرد که عمدتاً ناشی از حلقه‌های بی‌نهایت و فراموشی هدف بود (در تحلیل‌های اوایل 2026 بازتاب گسترده‌ای داشت).
پیام این نیست که «بستر آزمایشی برای همیشه برنده است». مدلها به‌مرور ترفندهای بستر آزمایشی را در خود حل می‌کنند. پیام اصلی این است که امروز، بار اصلی مهندسی دور مدل قرار دارد نه داخل آن، و عناصری که این بار را می‌کشند، همان‌هایی هستند که تمام سیستم‌های پروداکشن همیشه به آن‌ها نیاز داشته‌اند.
ارائه‌دهندگان تجاری کجا کم می‌آورند
این همان بخشی است که نیازی به تعارف در آن نیست.
- مقاله‌ی Anatomy of an Agent Harness از LangChain اجزای اصلی بستر آزمایشی را بررسی میکند: پرامپت‌ها، ابزارها، هوک‌ها، ساندباکس‌ها، ارکستراسیون، حافظه، مهارت‌ها، ساب‌ایجنت‌ها و «حلقه‌ی ساده‌ی» محیط اجرا. این مطلب صف‌ها، ورکرها به عنوان واحد استقرار، منطق محرک‌ها، پایایی نشست به عنوان دغدغه‌ای مستقل، یا سیاست مجوزدهی را نام نمی‌برد. با بستر آزمایشی مثل شیئی برخورد میکند که پیکربندی‌اش می‌کنید، نه سیستمی که مستقرش می‌سازید.
- مقاله‌ی Agent Harness Engineering از Addy Osmani چارچوب
Agent = Model + Harnessو الگوی جغجغه‌ای (ratchet pattern) را جا می‌اندازد، اما نمی‌گوید یک بستر آزمایشی دقیقاً از چه ساخته شده است؛ بیشتر شبیه اعلام موضع است تا یک مشخصات فنی (spec). - شرکت‌های Anthropic و OpenAI سطوح کاربری را عمیق‌تر می‌شکافند اما در حصار محیط‌های اجرای خودشان می‌مانند. خبر «تفکیک بستر و محاسبات» در نسخه‌ی آوریل 2026 فریم‌ورک Agents SDK، نخستین متن یک ارائه‌دهنده‌ی تجاری است که صراحتاً تفکیک لایه‌ی کنترل از لایه‌ی داده را تأیید میکند. این ایده‌ای پایه است، نه تازه.
- کتاب agentic_harness با بستر مثل یک آبجکت پیکربندی برخورد میکند (Agentic Engineering نوشته‌ی Jaymin West، فصل 6) و برنده‌ترین جمله‌اش این است: «بستر آزمایشی مرز اصلی امنیتی در یک سیستم ایجنتیک است.» این فقط تکرار مفهوم «سیاست مجوزدهی» است.
- بحث‌های Hacker News هم مدام به همین نقطه می‌رسند. در تاپیک آوریل 2026 با عنوان The agent harness belongs outside the sandbox استدلال می‌شود که بستر آزمایشی باید «بیشتر شبیه هایپروایزری باشد که بیرون همه‌چیز می‌نشیند و بر اساس بافتار و کاربر مجوز دسترسی می‌دهد.» این هم صرفاً نگاه به سیاست مجوزدهی به عنوان لایه‌ای جداگانه است.
لازم نیست با این نوشته‌ها مخالفت کنید تا متوجه خلاء بشوید. آن‌ها دارند لایه‌ی کاربریِ سیستمی را توصیف می‌کنند که از قبل وجود دارد. ما خودِ سیستم را می‌سازیم. وقتی سیستم درست ساخته شود، سطوح هفت‌گانه خودبه‌خود از دل همان عناصر پایه بیرون می‌آیند. وقتی سیستم غلط چیده شود، صد دست بزک کردن AGENTS.md هم جای خالی صف را پر نمی‌کند.
بنابراین وقتی جای دیگر نام «مهندسی بستر آزمایشی» را شنیدید، آن را به عناصر پایه ترجمه کنید. پرامپت‌ها و قوانین، همان سیاست‌ها و توابع هستند. داربست‌ها (scaffolding) همان محیط اجرا هستند. گاردریل‌ها همان مجوزدهی + اعتبارسنجی هستند. هوک‌ها همان محرک‌ها هستند. حافظه همان پایایی نشست است. Ralph Loop بازگرداندن تسک به صف است. ساب‌ایجنت‌ها همان ورکرها هستند. ساندباکس‌ها همان لایه‌های محاسباتی هستند. واژه‌ها عوض می‌شوند؛ مهندسی عوض نمی‌شود. میز کار همان لایه‌ی کاربری روبه‌روی ایجنت است؛ و بستر آزمایشی—به آن معنایی که پس از موج‌های تبلیغاتیِ بعدی هم دوام می‌آورد—یعنی توابع، ورکرها، محرک‌ها، محیط‌های اجرا، صف‌ها، پایایی و سیاست‌هایی که درست به هم وصل شده‌اند.
پیاده‌سازی عملی
اسکریپت code/main.py یک تسک کوچک در ریپازیتوری را 2 بار اجرا میکند. اول فقط با پرامپت، بعد با اتصال 7 سطح میز کار. مدل یکسان، تسک یکسان. اسکریپت سطوحی را که در اجرای ناموفق غایب بودند می‌شمارد و گزارش حالت‌های شکست را چاپ میکند.
این تسک عمداً کوچک انتخاب شده است: افزودن اعتبارسنجی ورودی به یک هندلر تک‌فایلی به سبک FastAPI و نوشتن تستی که با موفقیت پاس شود.
اجرای آن:
python3 code/main.pyخروجی: لاگ مقایسه‌ای کنار هم از هر 2 اجرا، فایلی به نام failure_modes.json که اجرای صرفاً مبتنی بر پرامپت را خلاصه میکند، و حکمی تک‌خطی برای اجرای با میز کار.
ایجنت این درس یک استاب (stub) کوچک و مبتنی بر قانون است؛ نکته‌ی اصلی سطوح اطراف هستند، نه خود مدل. در ادامه‌ی این مبحث آموزشی، هر یک از این سطوح را در قالب یک دست‌سازه‌ی واقعی و چندبارمصرف از نو می‌سازید.
کاربرد در عمل
3 جایی که سطوح میز کار همین حالا در دنیای واقعی وجود دارند، حتی اگر کسی آن‌ها را به این نام صدا نزند:
- Claude Code، Codex، Cursor. فایلهای
AGENTS.mdوCLAUDE.mdهمان سطح دستورالعملها هستند. دستورات با اسلش دامنه‌ی دسترسی هستند. هوک‌ها نقش اعتبارسنجی را بازی می‌کنند. - LangGraph، OpenAI Agents SDK. چک‌پوینت‌ها و مخازن نشست، سطح وضعیت هستند. سازوکارهای Hand-off همان سطح تحویل کار به شمار می‌روند.
- CI در یک ریپازیتوری واقعی. تست‌ها، لینت و بررسی تایپ‌ها اعتبارسنجی هستند. قالب پول‌ریکوئست سطح تحویل کار است. فایل CODEOWNERS همان لایه‌ی بازبینی است.
مهندسی میز کار یعنی صریح و چندبارمصرف کردن این سطوح، به‌جای اینکه بگذاریم هر تیمی از نو آن‌ها را با آزمون و خطا کشف کند.
تحویل نهایی
فایل outputs/skill-workbench-audit.md مهارتی چندبارمصرف است که ریپازیتوری فعلی را بر اساس سطوح هفت‌گانه‌ی میز کار بررسی میکند و گزارش می‌دهد کدام موارد غایب، کدام ناقص و کدام سالم هستند. آن را کنار هر ستاپ ایجنتی بگذارید؛ بلافاصله به شما می‌گوید چه چیزی را باید اول درست کنید.
تمرین‌ها
- ریپازیتوری فعلی خودتان را که یک ایجنت روی آن فعال است بردارید. به سطوح هفت‌گانه از 0 (غایب) تا 2 (سالم) امتیاز بدهید. ضعیف‌ترین سطح شما کدام است؟
- فایل
main.pyرا طوری توسعه دهید که اجرای صرفاً مبتنی بر پرامپت، ادعایی دروغین از «موفقیت» تولید کند. بررسی کنید که آیا سد اعتبارسنجی مچ آن را میگیرد یا خیر. - یک سطح هشتم برای محصول خودتان اضافه کنید. دلیل بیاورید که چرا این سطح در هیچ‌کدام از سطوح هفت‌گانه‌ی موجود ادغام نمی‌شود.
- اسکریپت را با یک ایجنت استاب دیگر اجرا کنید که توهمِ نوشتن روی فایلی اضافه را دارد. کدام سطح اول از همه جلوی آن را میگیرد؟
- پنج حالت شکست پرتکرار در صنعت را از فاز 14 · 26 روی این 7 سطح نگاشت کنید. هر سطح برای خنثی کردن کدام حالت شکست طراحی شده است؟
اصطلاحات کلیدی
| اصطلاح | در گفتار رایج | معنای واقعی آن |
|---|---|---|
| میز کار (Workbench) | «ستاپ و کانفیگ» | سطوح مهندسی‌شده‌ی اطراف مدل که کار را قابل‌اعتماد می‌کنند |
| سطح (Surface) | «یک داک» یا «یک اسکریپت» | ورودی نام‌دار و ماشین‌خوان که ایجنت در هر نوبت آن را می‌خواند یا می‌نویسد |
| سیستم ثبت نهایی (System of record) | «یادداشت‌ها» | فایلی که ایجنت بعد از پریدن تاریخچه‌ی چت، آن را حقیقت قطعی می‌داند |
| تعریف «انجامشده» (Definition of done) | «تأییدیه‌ی نهایی» | چک‌لیستی عینی و مبتنی بر فایل که ایجنت نمی‌تواند وانمود به انجام آن کند |
| ارزیابی میز کار (Workbench audit) | «چک کردن آمادگی ریپو» | بررسی سطوح هفت‌گانه برای پیدا کردن قطعات جاافتاده قبل از شروع به کار |
برای مطالعه‌ی بیشتر
این منابع را مثل داده‌های خام بخوانید، نه احکام نهایی. هر کدام فقط گوشه‌ای از سیستم را دسته‌بندی کرده‌اند. قبل از تصمیم‌گیری درباره‌ی به‌کارگیری هر مفهوم، اول آن را به یک عنصر پایه (تابع، ورکر، محرک، محیط اجرا، HTTP/RPC، صف، پایایی، سیاست) برگردانید.
دیدگاه شرکت‌های تجاری:
- Addy Osmani, Agent Harness Engineering — ایده‌ی
Agent = Model + Harnessو الگوی جغجغه‌ای؛ بسیار خلاصه در بخش زیرساخت - LangChain, The Anatomy of an Agent Harness — اجزای اصلی بستر: پرامپت‌ها، ابزارها، هوک‌ها، ارکستراسیون، ساندباکس‌ها، حافظه، مهارت‌ها، ساب‌ایجنت‌ها، محیط اجرا؛ فاقد صف‌ها، نحوه‌ی استقرار و مجوزدهی
- OpenAI, Harness engineering: leveraging Codex in an agent-first world — نگاه تیم Codex به سطوح اطراف محیط اجرای خودشان
- OpenAI, Unrolling the Codex agent loop — خلاصه‌سازی حلقه‌ی ایجنت به یک
whileروی فراخوانی توابع - Anthropic, Effective harnesses for long-running agents — سطوح کارهای بلندمدت در یک محیط اجرای مشخص
- Anthropic, Harness design for long-running application development — نکات تجربی در طراحی کاربردی
- قابلیت‌های بستر Deep Agents در LangChain — سطح تنظیمات پیکربندی محیط اجرا
نوشته‌های افراد عملیاتی با جزئیات کاربردی:
- Martin Fowler / Birgitta Böckeler, Harness engineering for coding agent users — راهنماها (پیش‌خوران) + سنسورها (پس‌خوران)؛ تمیزترین تصویرسازی بر پایه‌ی تئوری کنترل
- HumanLayer, Skill Issue: Harness Engineering for Coding Agents — «مشکل از مدل نیست، مشکل از کانفیگ است»
- MongoDB, The Agent Harness: Why the LLM Is the Smallest Part of Your Agent System — ارقام مستند: جهش Vercel از 80% به 100%، دوبرابر شدن دقت Harvey، ارتقای Terminal Bench از بیرون 30 تیم به 5 تیم برتر
- Augment Code, Harness Engineering for AI Coding Agents — راهنمای جامع با اولویت دادن به محدودیت‌ها
- پادکست Sequoia، گفت‌وگوی Harrison Chase درباره Context Engineering Long-Horizon Agents — اهمیت دغدغه‌های محیط اجرا نسبت به دغدغه‌های خود مدل
کتاب‌ها، مقالات و پیاده‌سازی‌های مرجع:
- Jaymin West, Agentic Engineering — فصل 6: بسترهای آزمایشی — بررسی کامل در قالب کتاب؛ در نظر گرفتن بستر آزمایشی به عنوان مرز اصلی امنیتی
- preprints.org, Harness Engineering for Language Agents (مارس 2026) — چارچوب دانشگاهی با محوریت کنترل / عاملیت / محیط اجرا
- walkinglabs/awesome-harness-engineering — فهرست گلچین‌شده درباره‌ی بافتار، ارزیابی، مشاهده‌پذیری و ارکستراسیون
- ai-boost/awesome-harness-engineering — فهرست گلچین‌شده‌ی جایگزین (ابزارها، ارزیابی‌ها، حافظه، MCP، مجوزها)
- HKUDS/OpenHarness — بستر آزمایشی متن‌باز با ایجنت شخصی توکار
بحث‌های Hacker News که به خاطر اختلاف‌نظرها ارزش خواندن دارند، نه هم‌صدایی‌ها:
- HN: Effective harnesses for long-running agents
- HN: Improving 15 LLMs at Coding in One Afternoon. Only the Harness Changed
- HN: The agent harness belongs outside the sandbox — استدلال در خصوص استقرار لایه‌ی مجوزدهی در سطحی کاملاً مستقل
ارجاعات مرتبط در این دوره‌ی آموزشی:
- فاز 14 · 23 — استانداردهای GenAI در OpenTelemetry: لایه‌ی مشاهده‌پذیری که در ادبیات سنسورها به آن اشاره می‌شود
- فاز 14 · 26 — کاتالوگ حالت‌های شکست که سطوح هفت‌گانه برای خنثی کردن آن‌ها طراحی شده‌اند
- فاز 14 · 27 — دفاع در برابر تزریق پرامپت که در عنصر پایه‌ی سیاست مجوزدهی قرار دارد
- فاز 14 · 29 — محیط‌های اجرای پروداکشن (صف، رویداد، کرون): محل استقرار عملیاتی عناصر پایه‌ی این درس در دنیای واقعی