رقابت ایجنت‌های برنامه‌نویسی حالا یک بازیگر جدی دیگر هم دارد.
تیم DeepSeek Harness پروژه‌ای متن‌باز با نام dsh-superagent منتشر کرده؛ یک نمونه تحقیقاتی از Coding Agentهای نسل جدید که قرار است بخش بیشتری از فرایند توسعه نرم‌افزار را با دخالت کمتر انسان انجام دهند.
ایده فقط این نیست که به هوش مصنوعی بگویید:
این تابع را بنویس.
بلکه سیستم بتواند درخواست‌های توسعه را از GitHub دریافت کند، آن‌ها را به Work Item تبدیل کند، در Session جداگانه روی کد کار کند، نتیجه را بررسی کند و در نهایت مثلاً یک Pull Request تحویل دهد.
در این مقاله از معین گیفت بررسی می‌کنیم dsh-superagent چیست، معماری Router و Worker آن چطور کار می‌کند، چه مقدار از توسعه نرم‌افزار را می‌تواند خودکار کند و چرا فعلاً نباید آن را یک محصول Production-ready در نظر گرفت.
dsh-superagent چیست؟
dsh-superagent یک Coding Agent متن‌باز است که برای کار روی یک Repository گیت‌هاب طراحی شده است.
این پروژه به‌صورت یک Bundle برای DeepSeek Harness منتشر شده و می‌تواند اتفاق‌های GitHub و در صورت نیاز پیام‌های Feishu را دریافت کند.
وقتی یک کاربر مجاز از Agent درخواست کاری کند، سیستم می‌تواند:
- درخواست را دریافت کند
- برای آن Ticket بسازد
- یک محیط کاری جدا ایجاد کند
- یک Agent Session برای Task اجرا کند
- روی Repository کار کند
- نتیجه را به همان Conversation برگرداند
- و در سناریوهای مناسب Pull Request بسازد
اما یک نکته مهم: این محصول رسمی نهایی DeepSeek نیست
خود Repository از همان ابتدای README هشدار می‌دهد که این پروژه:
Research Prototype
است.
DeepSeek صراحتاً می‌گوید کد برای استفاده تحقیقاتی و مرجع منتشر شده و نباید بدون بررسی و تطبیق وارد محیط Production شود.
حتی ممکن است:
- Bug داشته باشد
- بعضی قسمت‌های Engineering ناهماهنگ باشند
- برخی قابلیت‌های مطرح‌شده در مقاله طراحی هنوز در Prototype پیاده‌سازی نشده باشند
بنابراین بهتر است dsh-superagent را فعلاً یک نگاه عملی به آینده Coding Agentها بدانیم، نه محصول نهایی آماده جایگزینی تیم توسعه.
فلسفه اصلی پروژه؛ کمترین توجه انسان، بیشترین خروجی
یکی از جذاب‌ترین قسمت‌های پروژه، Philosophy آن است.
اصل مرکزی سیستم این جمله است:
تا حد ممکن توجه انسان را کمتر مصرف کن و در عوض بیشترین ارزش را تولید کن.
یعنی هدف فقط این نیست که Agent بیشتر کار کند.
هدف این است که Developer مجبور نباشد دائماً کنار Agent بماند و هر چند دقیقه یک بار:
- Continue بزند
- Task جدید بدهد
- خروجی را منتقل کند
- Context را دوباره توضیح دهد
Agent باید تا جایی که امکان دارد خودش Workflow را جلو ببرد و فقط زمانی انسان را درگیر کند که واقعاً تصمیم یا Review لازم است.
معماری Router و Worker
یکی از مهم‌ترین ایده‌های Super-agent جدا کردن هماهنگی از اجرای Task است.
به‌صورت ساده:
GitHub / Feishu
↓
Router
↓
Ticket / Task
↓
Worker
↓
Code / Tests / PR
↓
Review
↓
Result
Router چه کاری انجام می‌دهد؟
Router نقش هماهنگ‌کننده مرکزی را دارد.
یعنی درخواست‌ها و Eventهای مختلف را دریافت می‌کند و تصمیم می‌گیرد:
- آیا این Event باید بررسی شود؟
- آیا درخواست معتبر است؟
- آیا باید Ticket جدید ساخته شود؟
- این Task متعلق به کدام Worker است؟
Router خودش قرار نیست تمام Coding را انجام دهد.
Worker چه کاری انجام می‌دهد؟
برای هر Ticket، یک Executor Session جدا ساخته می‌شود.
نام Sessionها به شکل مشابه زیر است:
worker-<ticket-id>هر Worker همچنین Directory مخصوص خودش را دارد.
در نتیجه Context یک Task کمتر با Task دیگر مخلوط می‌شود.
یعنی چند Task می‌توانند همزمان اجرا شوند؟
بله.
یکی از نکات مهم معماری dsh-superagent پشتیبانی از Concurrency است.
Taskهای مختلف می‌توانند Worker Slotهای جدا داشته باشند و Launchهای مختلف همزمان اجرا شوند.
اگر یک Task مثلاً درگیر Build طولانی باشد، Task دیگری لزوماً متوقف نمی‌شود.
البته تعداد Workerهای همزمان براساس تنظیمات Concurrency محدود می‌شود.
Workerها حتی می‌توانند Subagent داشته باشند
داخل هر Executor امکان استفاده از Subagent هم وجود دارد.
یعنی یک Worker اصلی می‌تواند بخش‌هایی از کار را به Agentهای کوچک‌تر واگذار کند.
این موضوع dsh-superagent را به معماری Multi-agent نزدیک‌تر می‌کند.
اما بهتر است آن را به شکل ساده «چند هوش مصنوعی مستقل که مثل یک تیم کامل Developer کار می‌کنند» توصیف نکنیم؛ ساختار فعلی بیشتر ترکیبی از Router، Worker Sessionها و Subagentهای کنترل‌شده است.
Agent از کجا می‌فهمد باید کاری انجام دهد؟
یکی از تفاوت‌های Super-agent با Coding Assistantهای معمولی این است که ورودی فقط Prompt مستقیم کاربر نیست.
سیستم با مفهوم:
Trigger
کار می‌کند.
Trigger می‌تواند مثلاً از:
- GitHub Issue
- Pull Request
- Comment
- پیام تیم
- CI Result
ایجاد شود.
Agent می‌تواند این Eventها را بررسی کند و طبق Policy مشخص تصمیم بگیرد آیا باید روی آن‌ها کاری انجام دهد یا نه.
آیا Agent سرخود هر چیزی را تغییر می‌دهد؟
نه.
یکی از اصول Philosophy پروژه این است که Agent فقط در دو حالت باید Action انجام دهد:
- یک فرد مجاز مستقیماً از آن درخواست کار کرده باشد.
- یک Rule از قبل توسط تیم اجازه انجام آن کار را داده باشد.
در نتیجه هدف پروژه Autonomous بودن بدون کنترل نیست.
هدف این است که Autonomous Workflow در محدوده‌ای که تیم تعریف کرده اجرا شود.
مثلاً یک Workflow واقعی چگونه است؟
فرض کنید یک Developer داخل GitHub Issue می‌نویسد:
Login بعد از Refresh از کار می‌افتد. لطفاً بررسی و Fix شود.
سیستم می‌تواند این مسیر را طی کند:
GitHub Issue
↓
Trigger
↓
Authorization
↓
Ticket Created
↓
Worker Session
↓
Inspect Code
↓
Reproduce Bug
↓
Implement Fix
↓
Run Tests
↓
Open Pull Request
↓
Human Review
هر Ticket محیط کاری مستقل دارد
قبل از اجرای Assignment، سیستم می‌تواند برای Ticket یک Directory جدا ایجاد کند.
یکی از Workflowهای معمول استفاده از:
git worktreeاست.
در نتیجه Worker می‌تواند روی Branch مخصوص خودش کار کند بدون اینکه Taskهای دیگر Repository را به‌هم بزند.
Agent می‌تواند Command اجرا کند
Workerها به Shell دسترسی دارند و می‌توانند ابزارهای لازم برای توسعه را اجرا کنند.
مثلاً:
npm test
pnpm check
pytest
git diff
gh pr createبسته به پروژه و Permissionهای تعریف‌شده.
GitHub بخش مهمی از سیستم است
نسخه فعلی dsh-superagent مشخصاً برای یک GitHub Repository ساخته شده است.
Agent از ابزار:
ghبرای ارتباط با GitHub استفاده می‌کند.
بنابراین Workflowهایی مثل:
- Issue
- Pull Request
- Review
- Comment
- CI Feedback
می‌توانند داخل چرخه Agent قرار بگیرند.
فعلاً فقط یک Repository
این محدودیت مهم است.
dsh-superagent در نسخه Prototype برای:
یک GitHub Repository
طراحی شده است.
بنابراین هنوز قرار نیست یک Agent واحد تمام Repositoryها، تمام تیم‌ها و تمام Infrastructure یک شرکت را بدون تنظیم اضافه مدیریت کند.
پنل Web برای کارهایی که نیاز به انسان دارند
پروژه یک Web Panel هم دارد.
فلسفه Panel این نیست که هزاران Log به Developer نشان دهد.
بیشتر قرار است نشان دهد:
الان کدام Task واقعاً نیاز به توجه انسان دارد؟
مثلاً ممکن است وضعیت‌هایی مثل:
- Awaiting Review
- Blocked
- Failed
- Awaiting Answer
- Working
نمایش داده شوند.
اگر Agent وسط کار Fail شود چه؟
پروژه برای Failure و Recovery هم طراحی دارد.
برای بعضی خطاهای موقت مثل:
- Network Error
- HTTP 408
- HTTP 429
- HTTP 5xx
Retry با Backoff انجام می‌شود.
اگر Task واقعاً Block یا Failed شود، Agent می‌تواند منتظر دخالت انسان بماند.
Restart شدن سیستم هم لزوماً Task را نابود نمی‌کند
اطلاعاتی مثل:
- Ticket
- Directory
- Subscription
- Pending Message
- Session State
می‌توانند بعد از Restart باقی بمانند.
Worker جدید هنگام Recovery بررسی می‌کند قبلاً چه کاری انجام شده تا Actionهای خارجی را بی‌دلیل دوباره تکرار نکند.
Agent چه زمانی با انسان صحبت می‌کند؟
یکی از فلسفه‌های عجیب اما جذاب پروژه این است:
اگر انسان نیازی به Action ندارد، مزاحمش نشو.
یعنی Agent قرار نیست برای هر Step گزارش طولانی بدهد.
به‌طور کلی پیام زمانی ارسال می‌شود که:
- Task پذیرفته شده
- نتیجه آماده شده
- یک تصمیم انسانی لازم است
- Task Block یا Failed شده
آیا dsh-superagent خودش Pull Request می‌سازد؟
بله، یکی از سناریوهای اصلی پروژه این است که Worker تغییرات را انجام دهد و نتیجه را به‌شکل Pull Request ارائه کند.
اما Merge شدن به معنی آزادی کامل Agent نیست.
نسخه فعلی برای Auto-merge محدودیت‌هایی دارد و در حالت پیش‌فرض Agent خودش به‌سادگی هر PR را Merge نمی‌کند.
Human Review همچنان بخش مهم Workflow است
در Stageهای رسمی پروژه یک حالت مشخص با نام:
Awaiting reviewوجود دارد.
بنابراین حتی فلسفه خود پروژه هم بر حذف کامل Developer از چرخه تأکید نمی‌کند.
هدف بیشتر این است که انسان فقط در قسمت‌هایی که Judgment لازم است وارد شود.
امنیت؛ مهم‌ترین نکته قبل از اجرا
dsh-superagent می‌تواند Shell Command اجرا کند.
این یعنی اجرای آن روی سیستم واقعی باید با احتیاط زیادی انجام شود.
Documentation پروژه صریحاً می‌گوید Directoryهای جدا و Blocked Commandها:
Security Boundary واقعی محسوب نمی‌شوند.
Worker همچنان با Permissionهای OS User اجرا می‌شود.
بنابراین بهتر است Prototype را روی محیطی ایزوله و با Credentialهای محدود آزمایش کنید، نه روی Server حساس Production.
آیا Super-Agent واقعاً Bugها را خودش پیدا می‌کند؟
سیستم می‌تواند Eventهای GitHub، CI و Conversationها را دریافت کند و Worker برای بررسی Code اجرا کند.
اما این به معنی آن نیست که همیشه بدون Trigger مناسب به‌صورت آزاد کل Repository را Scan کرده و تمام Bugها را پیدا می‌کند.
رفتار Proactive براساس Ruleها و Policyهایی است که تیم تعریف می‌کند.
تفاوت با Claude Code یا Codex چیست؟
Claude Code و Codex معمولاً به‌عنوان Coding Agent مستقیم استفاده می‌شوند:
User
↓
Coding Agent
↓
Code
ایده dsh-superagent یک Layer بالاتر است:
Events
↓
Router
↓
Tickets
↓
Multiple Workers
↓
Coding Tools
↓
GitHub
↓
Human Review
تمرکز اصلی روی Orchestration، Continuity و مدیریت Workflow تیمی است.
Super-Agent یعنی چه؟
در طراحی DeepSeek Harness، Super-agent قرار است چند ویژگی داشته باشد:
- بتواند در طول زمان فعال بماند
- چند Task را همزمان مدیریت کند
- به Eventهای محیط واکنش نشان دهد
- بعد از Failure یا Restart کار را ادامه دهد
- نیاز به Micro-management انسان را کاهش دهد
اما تمام ایده‌های مقاله داخل Prototype نیستند
این نکته را خود DeepSeek بسیار واضح گفته است.
نسخه Public Repository با سیستم داخلی تیم یکسان نیست.
برخی معماری‌ها و ایده‌هایی که در مطلب Exploring Super-agent Design: Towards a More Autonomous Agent System مطرح شده‌اند، هنوز Direction آینده محسوب می‌شوند.
بنابراین نباید هر قابلیتی که در مقاله Super-agent توضیح داده شده را قابلیت آماده dsh-superagent تصور کرد.
زبان برنامه‌نویسی و License
نسخه فعلی پروژه عمدتاً با:
TypeScript
نوشته شده و تحت مجوز:
MIT
منتشر شده است.
بنابراین توسعه‌دهندگان می‌توانند Source Code را بررسی، Fork و براساس شرایط License تغییر دهند.
نصب dsh-superagent
Setup پروژه ساده یک‌دستوری نیست.
خود DeepSeek توصیه جالبی دارد: Repository را در اختیار Coding Agent خودتان قرار دهید و به آن بگویید فایل Setup را بخواند.
دستور پیشنهادی در README:
Read SETUP.md in this repository and set up dsh-superagent with me.Agent سپس باید Setup را مرحله‌به‌مرحله همراه شما انجام دهد.
چرا نصب کاملاً اتوماتیک نیست؟
چون مواردی مثل:
- GitHub Account
- Repository
- Model Provider
- Execution Environment
- Permissions
- Workspace
باید براساس محیط شما تنظیم شوند.
برای چه کسانی مناسب است؟
در وضعیت فعلی بیشتر برای:
- توسعه‌دهندگان علاقه‌مند به Agentic Coding
- پژوهشگران Multi-agent Systems
- تیم‌هایی که می‌خواهند Workflowهای GitHub را خودکار کنند
- افرادی که DeepSeek Harness را آزمایش می‌کنند
- سازندگان Coding Agentها
جذاب است.
برای چه کسی مناسب نیست؟
اگر دنبال ابزاری هستید که نصب کنید و همان لحظه بدون Setup پروژه Production شما را کاملاً خودکار مدیریت کند، dsh-superagent هنوز آن محصول نیست.
خود توسعه‌دهندگان نیز آن را Research Code توصیف کرده‌اند.
آیا DeepSeek وارد رقابت Coding Agentها شده؟
از نظر تحقیق و Infrastructure Agentic، بله؛ انتشار dsh-superagent نشان می‌دهد تیم DeepSeek Harness روی Agentهایی کار می‌کند که فراتر از یک Coding Chat ساده عمل کنند.
اما دقیق‌تر است بگوییم:
DeepSeek یک Prototype متن‌باز از معماری Coding Super-agent منتشر کرده است.
نه اینکه محصول تجاری نهایی‌ای در سطح Claude Code یا Codex عرضه شده باشد.
نکته جالب؛ بخش زیادی از خود پروژه را Coding Agentها نوشته‌اند
در README پروژه آمده که بخش قابل‌توجهی از Engineering این کد در جریان کار روزمره تیم و با کمک Coding Agentها انجام شده است.
یعنی خود پروژه‌ای که درباره Autonomous Coding است، تا حد زیادی با کمک Coding Agentها ساخته شده است.
لینک پروژه در GitHub
برای مشاهده Source Code، Documentation و Setup:
مشاهده dsh-superagent در GitHub →
جمع‌بندی
dsh-superagent یکی از جالب‌ترین نمونه‌های جدید در مسیر حرکت Coding Agentها از «دستیار برنامه‌نویسی» به سمت «عضو خودکار Workflow توسعه» است.
این سیستم می‌تواند درخواست‌ها و Eventهای GitHub را دریافت کند، برای هر Task یک Ticket و Worker Session جدا ایجاد کند، چند کار را همزمان اجرا کند، Shell و GitHub را به کار بگیرد و نتیجه را به شکل‌هایی مثل Pull Request تحویل دهد.
اما این پروژه هنوز یک Research Prototype است، فقط برای یک Repository طراحی شده و حتی DeepSeek نیز توصیه می‌کند قبل از استفاده واقعی کد را بررسی و متناسب با محیط خودتان اصلاح کنید.
به همین دلیل dsh-superagent را فعلاً بهتر است نمونه‌ای از آینده Agentic Software Development بدانیم؛ آینده‌ای که در آن انسان کمتر زمانش را صرف دادن Promptهای ریز می‌کند و بیشتر روی Review، تصمیم‌گیری و معماری تمرکز خواهد کرد.
اگر Coding Agentهای امروز مثل یک برنامه‌نویس کنار شما هستند، ایده Super-agent این است که فردا یک سیستم بتواند چند برنامه‌نویس هوش مصنوعی را پشت صحنه هماهنگ کند و فقط زمانی سراغ شما بیاید که واقعاً به تصمیم انسانی نیاز دارد.
اخبار Coding Agentها در معین گیفت
در معین گیفت جدیدترین پروژه‌های Claude Code، Codex، DeepSeek، Cursor و Agentهای برنامه‌نویسی را بررسی می‌کنیم تا تفاوت بین Demoهای تحقیقاتی، پروژه‌های متن‌باز و ابزارهای Production-ready را بهتر بشناسید.
اشتراک‌ها و خدمات مرتبط با این راهنما
برای مقایسه امکانات، قیمت و شرایط خرید، صفحه هر محصول را بررسی کنید.