DeepSeek Harness در حال تبدیلشدن از یک برنامه عاملمحور معمولی به محیط اجرایی قابل ترکیب است؛ محیطی که در آن مدل، ابزار، مهارت، نشست، sandbox، ذخیرهسازی، حلقه اجرا، زمانبندی و حتی رابط کاربری به شکل افزونه تعریف میشوند. پروژه هنوز در مرحله developer preview است، اما شاخه 0.1.7 alpha این معماری را عملیتر کرده است: وابستگی افزونهها هنگام اجرا حل میشود، Plugin Manager میتواند افزونه را در زمان اجرا خارج کند و Creator mode برای افزونههای ماندگار به همین مدیر افزونه تکیه میکند.
اهمیت این تغییر در آن است که harness دیگر فقط پوستهای دور مدل نیست؛ به محیط اجرای عامل تبدیل میشود. این انعطاف قدرت زیادی به توسعهدهنده میدهد، اما همزمان نسخهبندی، سابقه تغییر و مدیریت چرخه عمر افزونهها را به بخشی از کنترل سامانه تبدیل میکند.
«همهچیز افزونه است» حالا اثر عملی بیشتری دارد
DeepSeek معماری Harness را بر پایه Cordis توضیح میدهد. قابلیتهای اصلی عامل در افزونهها قرار دارند. Standard mode مجموعه کامل ابزارهای عامل برنامهنویسی را ارائه میکند. Code mode ابزارها را از طریق SDK در اختیار مدل میگذارد تا چند مرحله را در یک برنامه ترکیب کند. Minimal mode برای آزمون مدلها عمداً ساده نگه داشته شده و Creator mode برای بررسی محیط اجرا و ساخت ترکیبهای جدید طراحی شده است.
در 0.1.7 alpha، وابستگی افزونهها هنگام اجرا resolve میشود و Plugin Manager امکان unload در زمان اجرا دارد. Creator mode نیز ابزارهای تعریف پویای قبلی را کنار گذاشته و افزونههای ماندگار را از مسیر Plugin Manager نصب میکند. CLI هم میتواند یک profile مشخص را مستقیم اجرا کند.
در نتیجه Harness بیش از گذشته شبیه یک پلتفرم قابل پیکربندی است تا یک عامل از پیش بستهبندیشده.
ترکیب پویا، مدل خطا را هم تغییر میدهد
در یک بسته ثابت، وضعیت وابستگیها نسبتاً ساده است: همه چیز هنگام شروع بارگذاری میشود یا برنامه خطا میدهد. در محیط قابل ترکیب، حالتهای بیشتری وجود دارد. افزونه میتواند نصب باشد اما فعال نباشد، بعداً بارگذاری شود یا در حالی خارج شود که سرویس دیگری به آن وابسته است.
تحلیل Aipolix این است که تیمهایی که روی DeepSeek Harness افزونه میسازند باید گراف افزونهها را بخشی از وضعیت محیط تولید بدانند. نسخه و مجموعه افزونههای فعال هر run باید ثبت شود، تغییر وابستگی پیش از rollout آزمایش شود و رویدادهای بارگذاری یا خروج افزونه در log قابل مشاهده باشند. در غیر این صورت دو نشست با مدل و prompt یکسان ممکن است فقط به دلیل تغییر ترکیب harness رفتار متفاوتی نشان دهند.
این موضوع برای بازتولیدپذیری مهم است. DeepSeek میگوید اطلاعاتی که مدل میبیند، فراخوانی ابزار، برنامهریزی subagent و context injection در session log افزایشی ثبت میشوند. این ردپا زمانی کامل است که بتوان ترکیب محیط اجرایی آن run را هم بازیابی کرد.
تغییر نشست و subagent نشان میدهد پلتفرم هنوز در حال حرکت است
همین خانواده انتشار تغییرهایی در فرمت نشست، رفتار subagent و API افزونهها دارد. پروژه مهاجرت به فرمتهای جدیدتر نشست را مستند کرده و بعضی APIهای افزونهای تغییر کردهاند. برای زنجیره subagentهای ادامهپذیر هم سقف پیشفرضی برای تعداد فرزندان فعال و عمق واگذاری تعیین شده است.
برای developer preview چنین تغییرهایی طبیعی است، اما نشان میدهد سطح توسعه هنوز پایدار نشده است. وقتی نشست ذخیرهشده، preset، profile و API افزونه با سرعتهای متفاوت تغییر کنند، بهرهبرداری از اکوسیستم سختتر میشود.
بنابراین pin کردن نسخه برای تیمهایی که Harness را آزمایش میکنند مهم است. ارتقا باید با داده واقعی نشست و افزونههای سفارشی آزمایش شود. preview جای مناسبی برای بررسی معماری است، نه برای فرضکردن سازگاری بین نسخههای alpha.
جدایی مدل از harness مزیت اصلی معماری است
ایده مهم DeepSeek Harness این است که توان مدل را از سازوکاری که امکان عملکردن را فراهم میکند جدا میسازد. ابزار، sandbox، وضعیت نشست، زمانبندی و orchestration در یک پیادهسازی وابسته به مدل قفل نشدهاند.
این جدایی میتواند مقایسه مدلها روی یک harness واحد یا تعویض جزء زیرساختی را آسانتر کند. همچنین جای روشنتری برای اعمال سیاست میسازد: مجوز، ذخیرهسازی، شبکه و دسترسی ابزار را میتوان در محیط اجرا کنترل کرد، نه فقط با دستور متنی.
در مقابل، harness قدرتمند خودش بخشی بزرگتر از پایه قابل اعتماد سامانه میشود. افزونهای که ابزار، ذخیرهسازی یا زمانبندی را تغییر میدهد، میتواند اختیار عامل را هم تغییر دهد. منشأ افزونه و مرز مجوزها در نتیجه به اندازه انتخاب مدل اهمیت پیدا میکند.
0.1.7 همچنان pre-release است
GitHub نسخههای 0.1.7 را pre-release علامتگذاری کرده است. alpha جدیدتر اصلاحهایی در کشف مدل، اتصال دوباره Web و تنظیمات تشخیص گفتار دارد و alpha قبلی تغییرهای گستردهتر runtime و افزونه را وارد کرده است.
باید این وضعیت را جدی گرفت. Harness برای آزمایش محیط اجرایی قابل ترکیب، توسعه افزونه و بررسی trace نشستها جذاب است، اما نشانهای برای ثابتبودن API یا رفتار مهاجرت در تولید نیست.
چه چیزی را آزمایش کنیم؟
یک ارزیابی خوب با profile کوچک و pinشده شروع میشود: مدل، ابزار و افزونه ذخیرهسازی مشخص باشند. سپس قبل و بعد از یک تغییر کنترلشده افزونه، runها و traceها مقایسه شوند. load/unload، بازیابی پس از restart، مهاجرت نشست و مرز مجوز نیز باید آزمایش شوند.
اهمیت 0.1.7 در این است که خود harness را قابل برنامهریزی و ترکیبپذیرتر میکند. فرصت، آزمایش سریعتر معماری عامل است؛ مسئولیت مهندسی هم روشن است: این ترکیب پویا به همان انضباط نسخهبندی، مشاهدهپذیری و کنترل تغییر نیاز دارد که برای وابستگیهای عادی نرمافزار لازم است.