تصور کنید ابزاری دارید که اجازه نمی‌دهد تا وقتی استراتژی کدنویسی شما کاملاً تایید نشده، حتی یک خط کد تغییر کند. این دقیقاً همان چیزی است که OpenCode با جداسازی تفکر معماری از اجرای خام کد به دست آورده است. این پلتفرم اجازه می‌دهد توسعه‌دهنده تفکر سطح بالای معماری را از اجرای مستقیم کد ایزوله کند.
طبق راهنمای فنی منتشر شده در ۸ اوت ۲۰۲۶، این تفکیک ساختاری از یکی از رایج‌ترین تله‌های هوش مصنوعی، یعنی عجله در پیاده‌سازی پیش از بررسی دقیق استراتژی، جلوگیری می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل دقیق بر دسترسی‌های مدل، کلید کاهش خطاهای بحرانی در محیط‌های عملیاتی است.
بیشتر ابزارهای کدنویسی فعلی مانند یک رابط چت یکپارچه و یکپارچه (Monolithic) عمل می‌کنند؛ شبیه به آشپزی که هم‌زمان هم دستور پخت را می‌نویسد و هم مواد را می‌ریزد و در نتیجه ممکن است وسط کار متوجه شود نمک را فراموش کرده است. این رویکرد اغلب منجر به توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد — یا حذف بی‌صدای کدهای حیاتی در حین اجرا می‌شود. این چالش‌ها پیش‌تر در راهکارهای جداسازی محیط‌های کدنویسی برای توقف توهمات هوش مصنوعی مورد بررسی قرار گرفته بود. OpenCode با ایجاد یک مرز ذهنی، عامل «برنامه‌ریز» (Plan) را که محدود به تفکر و استراتژی است، از عامل «اجراکننده» (Build) که دارای مجموعه کامل ابزارهای لازم برای تغییر کد است، جدا می‌کند.
مکانیزم عامل‌های اصلی
در این پلتفرم، کاربران مستقیماً با دو عامل اصلی در تعامل هستند:
- Build: این عامل اصلی است که تمام ابزارها در آن فعال است. این گزینه استاندارد برای زمانی است که می‌خواهید عامل واقعاً روی کدبیس شما کار کند و تغییرات را اعمال نماید.
- Plan: این عامل محدودتر است. برای کاربرانی طراحی شده که می‌خواهند پیش از ورود به حالت اجرا، چندین بار روی مسئله فکر کنند، برنامه‌ریزی کنند و استراتژی خود را بسازند.
علاوه بر این حالت‌های اصلی، پلتفرم از سیستمی به نام عامل‌های فرعی (Subagents) استفاده می‌کند. این‌ها دستیاران تخصصی هستند که عامل‌های اصلی می‌توانند برای وظایفی خاص آن‌ها را فرا بخوانند، یا کاربران می‌توانند مستقیماً با استفاده از علامت '@' آن‌ها را صدا بزنند. این سیستم مانع از آن می‌شود که عامل اصلی مجبور باشد شخصاً تمام کدبیس را برای یافتن یک مورد خاص جست‌وجو کند.
جزئیات عامل‌های فرعی پیش‌فرض
بر اساس مستندات این سیستم، سه عامل فرعی داخلی تعریف شده است:
- General: یک عامل فرعی با کاربرد عمومی که برای پژوهش‌ها و وظایف چندمرحله‌ای که نیاز به بررسی و تحقیق دارند، طراحی شده است.
- Explore: عاملی با دسترسی «فقط خواندنی» (Read-only) که برای گشت‌وگذار در کدبیس‌ها طراحی شده است. از این عامل برای یافتن فایل‌ها بر اساس الگوها یا درک نحوه پیاده‌سازی یک قابلیت در سراسر پروژه، بدون ایجاد هرگونه تغییر، استفاده می‌شود.
- Scout: یک عامل دیگر با دسترسی «فقط خواندنی». این عامل برای پژوهش در مستندات خارجی یا مقایسه کدهای خارجی، مانند پیاده‌سازی‌های Upstream یا مخازن دیگر، به کار می‌رود.
توسعه‌دهندگان می‌توانند این اکوسیستم را با ایجاد عامل‌های سفارشی از طریق فایل‌های JSON در opencode.json یا فایل‌های Markdown گسترش دهند. این فایل‌ها را می‌توان به صورت عامل‌های سراسری در مسیر ~/.config/opencode/agents/ یا به صورت عامل‌های مختص هر پروژه در .opencode/agents/ ذخیره کرد.
برای مثال، یک کاربر می‌تواند عاملی به نام copywriter.md بسازد. با نام‌گذاری فایل به این صورت، این عامل با دستور @copywriter قابل فراخوانی می‌شود. این عامل را می‌توان با یک مدل خاص — مانند anthropic/claude-sonnet-4-20250514 — و دمای (Temperature) ۰.۷ تنظیم کرد تا تعادلی بین خلاقیت و دقت ایجاد شود.
مجوزهای عامل‌های سفارشی
عامل‌های سفارشی اجازه کنترل بسیار دقیق (Granular) بر رفتار هوش مصنوعی را می‌دهند. برای مثال، یک عامل کپی‌رایتینگ را می‌توان با محدودیت‌های زیر تنظیم کرد تا از هرگونه تغییر ناخواسته جلوگیری شود:
- edit: deny: جلوگیری از ایجاد تغییرات مستقیم در فایل‌ها.
- bash: deny: جلوگیری از اجرای دستورات در ترمینال.
این ساختار تضمین می‌کند که عامل صرفاً بر تولید متن‌های صیقل‌خورده، آماده به کار، با ساختاری موجز و زبانی متقاعدکننده تمرکز کند، بدون اینکه کدبیس را تغییر دهد. این چرخش، نقش توسعه‌دهنده را از یک مهندس پرامپت به یک ارکستراتور یا سازمان‌دهنده تغییر می‌دهد. به جای توضیح مکرر زمینه (Context) به یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — توسعه‌دهنده کتابخانه‌ای از ابزارهای تخصصی با محدودیت‌های تعریف‌شده می‌سازد. این رویکردی است که در مدیریت تاریخچه گفتگوهای AI با متدولوژی کنترل نسخه نیز برای سازماندهی تعاملات پیچیده پیشنهاد شده است. این امر بار شناختی مدیریت رفتار AI را کاهش داده و ریسک باگ‌های محیط عملیاتی ناشی از عامل‌های دارای دسترسی بیش از حد (Over-privileged) را به حداقل می‌رساند.
برای کسانی که نگران باگ‌های معرفی‌شده توسط هوش مصنوعی هستند — که اغلب زمانی رخ می‌دهد که عامل‌ها به طور بی‌صدا منطق کد را حذف کرده یا رفتار آن را تغییر می‌دهند — نویسنده پیشنهاد می‌کند این عامل‌ها را با git-lrc جفت کنند. این ابزار یک بازبین کد کوچک (Micro AI code reviewer) رایگان و با سورس در دسترس است که به کامیت‌های git متصل شده و هر Diff را پیش از نهایی شدن بررسی می‌کند. این ابزار دارای یک فرآیند راه‌اندازی ۶۰ ثانیه‌ای است تا کیفیت کد پیش از ورود به محیط Production تضمین شود.
گام بعدی شما
- یک عامل سفارشی در دایرکتوری
.opencode/agents/برای مدیریت تکراری‌ترین وظایف مستندسازی یا بازسازی کد (Refactoring) تعریف کنید. - دسترسی‌های
editوbashرا برای عامل‌های پژوهشی غیرفعال کنید تا امنیت کدتان تضمین شود. - ابزار git-lrc را برای بررسی خودکار Diffها در گردش‌کار خود بگنجانید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو