کالبدشکافی طراحی DeepSeek Harness

پروژه DeepSeek Harness (با نام دستور dsh، مخزن deepseek-ai/deepseek-harness) به عنوان نسخه پیش‌نمایش توسعه‌دهندگان (Developer Preview) در اوت 2026 منتشر شد. تعریف رسمی آن مستقیم است: Agent = Model + Environment + Tools + State — ترکیبی چهاربخشی از مدل، محیط، ابزارها و وضعیت.

اگر کالبدشکافی‌های سه محصول پیشین می‌پرسیدند «یک هارنس چگونه باید طراحی شود»، پروژه DeepSeek Harness پرسشی رادیکال‌تر را مطرح می‌کند: آیا یک هارنس می‌تواند به یک زمان اجرای مستقل فارغ از یک مدل خاص تبدیل شود؟ پاسخ آن مثبت است، و این ایده را به غایت خود می‌رساند. به تعبیر مستندات معماری: هر بخشی از محصول یک پلاگین است، از جمله آداپتور مدل، رجیستری ابزار، لاگ نشست، و خود حلقه ایجنت.

در این مقاله، ما به طور ویژه سه مورد را بررسی می‌کنیم: هسته مبتنی بر پلاگین، درزهای قابلیتی (capability seams)، و پایپ‌لاین رویدادها، به همراه قوی‌ترین قید مهندسی آن: «قابل مشاهده برای مدل به معنای ثبت‌شده در لاگ است» (Model-visible means logged).

در یک جمله#

یک ایجنت کدنویسی سنتی ساختاری به شکل «LLM + حلقه ایجنت ثابت + مجموعه ابزار ثابت» دارد. پروژه DeepSeek Harness ساختاری به صورت «مدل + هسته پلاگینی (Cordis)» دارد. هسته تنها مسئول بارگذاری پلاگین‌ها، تخلیه آن‌ها، مدیریت وابستگی‌ها و رویدادها است و مالک هیچ قابلیت ایجنتی ملموسی نیست. به تعبیر مستندات معماری: «هیچ هسته دارای امتیازی برای وصله زدن وجود ندارد» و «شما dsh را با سوار کردن یک پلاگین در کنار سایرین گسترش می‌دهید». این بدان معناست که حتی خود حلقه ایجنت نیز مقدس یا تغییرناپذیر نیست: شما می‌توانید یک مدل DeepSeek، زیر-ایجنت‌های Claude Code، یک ساندباکس از راه دور، حافظه سفارشی، یک حلقه سفارشی و یک رابط کاربری سفارشی را در یک ایجنت کاملاً جدید ترکیب کنید.

این کامل‌ترین پیاده‌سازی از گزاره دوره است که می‌گوید «هر چیزی در بیرون از وزن‌های مدل، هارنس است»: اگر هارنس مستقل است، آن را به یک سیستم‌عامل برای خودش تبدیل کنید.

هسته معماری 1: درز قابلیتی (Capability Seam)#

پروژه DeepSeek Harness «قابلیت‌ها» را به عنوان سرویس (Service) نمایش می‌دهد، و تقریباً هر قابلیتی را به سه لایه تقسیم می‌کند:

Service Definition
        ↓
Service Provider
        ↓
Consumer

به عنوان مثال سیستم فایل را در نظر بگیرید: زیر FS Service چندین Provider وجود دارد — Local FS، E2B FS، و Remote FS — که همگی از طریق یک مجموعه سازگار از ابزارهای فایلی به سمت بالا در معرض دید قرار می‌گیرند. Shell، Subprocess، Sandbox، Web، LLM و SubAgent همگی از همین ساختار پیروی می‌کنند. این ساختار سه‌لایه‌ای خلاصه شخصی ما نیست؛ بخش Capability seams در مستندات معماری می‌گوید: یک درز یک قابلیت قابل تعویض با سه نقش است: یک Service Definition که اینترفیس را اعلام می‌کند، یک Service Provider که آن را پیاده‌سازی می‌کند، و یک Consumer که از آن استفاده می‌نماید، که معمولاً یک ابزار رو به مدل است.

این امر یک پرسش دیرینه در مهندسی هارنس را حل می‌کند: آیا یک ایجنت باید به «ابزارهای ملموس» وابسته باشد یا به «اینترفیس‌های قابلیتی»؟ پروژه DeepSeek Harness دومی را انتخاب می‌کند. از دیدگاه دوره، این بدان معناست که «زیرسیستم ابزارها» به عنوان یک اینترفیس استانداردسازی شده است. تغییر Providerها سطح ابزار در معرض دید مدل را بدون تغییر باقی می‌گذارد در حالی که محیط زیرین را به طور کامل جایگزین می‌کند.

هسته معماری 2: پایپ‌لاین رویدادها#

پروژه DeepSeek Harness حول یک جریان ساده «LLM ← ابزار ← LLM» ساخته نشده است. در درون خود، از یک پایپ‌لاین رویدادی استفاده می‌کند که در آن هر مرحله یک نقطه رویداد است که پلاگین‌ها می‌توانند آن را مشاهده کنند:

turn/start → claim input → assemble（system prompt / context / tools）
  → agent/pre-step → step/start → LLM request（agent/request）→ llm/stream
  → assistant/message → tool/call
  → tools/pre-execute（permission / guard / policy / hook）
  → tools/execute → tools/post-execute → tool/result → step/end → next turn

(پایپ‌لاین فوق برگرفته از بخش Turn flow در مستندات معماری است: رویدادهای turn/*، step/*، user/message، assistant/*، و tool/* رویدادهای نشست ماندگار هستند، در حالی که agent/pre-step، agent/request، llm/stream، و tools/* نقاط گسترشی هستند که پلاگین‌ها می‌توانند آن‌ها را مشاهده نمایند.)

بزرگ‌ترین مزیت این طراحی در آن است که بسیاری از قابلیت‌ها نیازی به اصلاح خود حلقه ایجنت ندارند. می‌خواهید یک بررسی امنیتی قبل از اجرای ابزار انجام دهید؟ به tools/pre-execute گوش دهید. می‌خواهید حافظه اضافه کنید؟ آن را در agent/pre-step تزریق کنید. می‌خواهید رفتار را ثبت کنید؟ در رویدادهای نشست مشترک شوید. می‌خواهید درخواست مدل را تغییر دهید؟ به agent/request هوک بزنید. می‌خواهید تصمیم بگیرید آیا استدلال ادامه یابد؟ به agent/turn-stopping گوش دهید.

در مقایسه با درس 11، «مشاهده‌پذیر ساختن زمان اجرای ایجنت»، DeepSeek Harness فراتر می‌رود: به جای صرفاً «افزودن لاگ‌ها»، هر مرحله از حلقه را به یک نقطه رویداد تبدیل می‌کند، و اجازه می‌دهد مشاهده‌پذیری، مجوزها، حافظه و سیاست‌ها به عنوان شنونده به حلقه متصل شوند به جای آنکه در آن هاردکد گردند.

هسته معماری 3: لاگ رویدادهای نشست و «قابل مشاهده برای مدل به معنای ثبت در لاگ است»#

پروژه DeepSeek Harness دارای یک لاگ رویدادهای نشست الحاق‌محور (append-only Session Event Log) است و یک قید مهندسی قدرتمند وضع می‌کند. بخش Session log در مستندات معماری بیان می‌دارد:

قابل مشاهده برای مدل به معنای ثبت در لاگ است (Model-visible means logged). هر چیزی که به یک درخواست مدل می‌رسد باید از روی لاگ قابل بازسازی باشد، و یک نامتغیر زمان اجرا این را اعمال می‌کند.

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

نگاشت به چارچوب دوره#

تفاوت بنیادین میان DeepSeek Harness و سه محصول دیگر در این است که Pi، Claude Code، و Codex همگی هارنس را «درون یک ایجنت مشخص» بهینه‌سازی می‌کنند، در حالی که DeepSeek Harness هارنس را به عنوان یک سیستم‌عامل مستقل از مدل تعریف می‌کند، به طوری که خود ایجنت صرفاً یک برنامه کاربردی قابل تعویض در حال اجرا بر روی آن سیستم‌عامل است. هزینه این رویکرد نیز به همان اندازه آشکار است: انعطاف‌پذیری بیشتر به معنای هزینه پیکربندی بالاتر است، که یک نقطه ضعف ذاتی در طراحی «هارنس به مثابه سیستم‌عامل» محسوب می‌شود (نسخه Developer Preview نیز به عنوان نگاهی اولیه به سازوکارهایی که هنوز در حال تکامل هستند جایگاه‌یابی شده است).

طرح‌های شایسته الگوبرداری#

1. هر مرحله از حلقه را به یک نقطه رویداد تبدیل کنید: مجوزها، حافظه، سیاست‌ها و لاگ‌ها را به عنوان شنونده به حلقه متصل کنید به جای اینکه آن‌ها را در حلقه هاردکد نمایید.
2. درزهای قابلیتی را استانداردسازی کنید: به «اینترفیس‌های قابلیتی» وابسته باشید نه «ابزارهای ملموس»، تا بتوان محیط را به طور کامل جایگزین کرد بدون آنکه سطح ابزار قابل مشاهده برای مدل تغییر کند.
3. قابل مشاهده برای مدل به معنای ثبت در لاگ است: هر چیزی که برای مدل قابل مشاهده است باید لاگ شود، و بدین ترتیب مشاهده‌پذیری از یک «ویژگی اختیاری» به یک «قید اصول اولیه‌ای» ارتقا می‌یابد.
4. لاگ‌های نشست الحاق‌محور: وضعیت قابل بازپخش و تحویل‌های قابل اعتماد ضمانتی مهندسی فراهم می‌آورند که «هر نشست وضعیتی تمیز بر جای بگذارد».

مراجع (منابع اصلی / سورس کد)#

تمام ادعاها را می‌توان در منابع اصلی یا سورس کدهای زیر ردگیری کرد:

• DeepSeek Harness: تعریف محصول «Agent = Model + Environment + Tools + State»، جایگاه Developer Preview، و دستور dsh.
  https://deepseek.com/harness
• deepseek-ai/deepseek-harness (دستور dsh، مجوز MIT):
  https://github.com/deepseek-ai/deepseek-harness
• architecture.md: منبع محوری این مقاله — «هر بخشی از محصول یک پلاگین است»، «هیچ هسته دارای امتیازی برای وصله زدن وجود ندارد»، پایپ‌لاین رویدادی Turn flow، نقش‌های سه‌گانه درزهای قابلیتی، قید «Model-visible means logged» و نامتغیر زمان اجرای آن، لاگ رویدادهای نشست الحاق‌محور، و درزهای قابلیتی نظیر fs/tools/telemetry و زیرسیستم‌های ctx.*.
  https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/architecture.md
• مستندات معماری تکمیلی: مقدمه‌ای بر هسته Cordis (پلاگین‌ها ارائه‌دهنده سرویس‌ها، رویدادهای تایپ‌شده، اثرات بازگشت‌پذیر هستند)، جزئیات درزهای قابلیتی، و زیرسیستم Session.
  https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/cordis-primer.md ｜ https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/capability-seams.md ｜ https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/subsystems/session.md

درس‌های مرتبط: درس 11 · مشاهده‌پذیر ساختن زمان اجرای ایجنت ｜ درس 12 · بر جای گذاشتن یک تحویل تمیز در پایان هر نشست ｜ درس 2 · هارنس در واقع چیست