Open Interpreter یک عامل هوش مصنوعی متن‌باز است که داخل ترمینال اجرا می‌شود و می‌تواند فایل‌های پروژه را بررسی کند، کد بنویسد، تغییرات را روی فایل‌ها اعمال کند، فرمان‌های ترمینال را اجرا کند و نتیجه اجرای برنامه یا تست‌ها را تحلیل کند.

تفاوت اصلی Open Interpreter با یک چت‌بات معمولی این است که پاسخ آن به تولید متن محدود نمی‌شود. این ابزار می‌تواند پس از دریافت اجازه کاربر، روی فایل‌ها و پروژه واقعی کار کند.

برای مثال می‌توانید از آن بخواهید:

• ساختار یک پروژه را تحلیل کند.
• علت خطای برنامه را پیدا کند.
• یک قابلیت جدید به پروژه اضافه کند.
• تست‌های پروژه را اجرا و خطاها را اصلاح کند.
• فایل‌های متنی و داده‌ای را پردازش کند.
• تغییرات ایجادشده را بررسی و خلاصه کند.
• چند دستور تکراری را به یک فرایند خودکار تبدیل کند.
• یک پروژه قدیمی را مستندسازی کند.

Open Interpreter از ارائه‌دهندگان سفارشی سازگار با OpenAI پشتیبانی می‌کند. بنابراین می‌توان آن را به API درواره متصل کرد و بدون نیاز به خرید مستقیم اشتراک یا اعتبار خارجی، از مدل‌های موجود در درواره استفاده کرد.

نکته مهم درباره نسخه جدید Open Interpreter

بسیاری از آموزش‌هایی که در اینترنت پیدا می‌کنید مربوط به نسخه قدیمی Python هستند و دستور زیر را پیشنهاد می‌کنند:

pip install open-interpreter

اما پروژه رسمی Open Interpreter در سال ۲۰۲۶ تغییر مهمی داشته است. نسخه جدید با Rust توسعه داده شده، از ساختار Codex استفاده می‌کند و بیشتر به‌عنوان یک عامل برنامه‌نویسی داخل ترمینال شناخته می‌شود.

روش رسمی نصب نسخه جدید، استفاده از Installer ارائه‌شده در وب‌سایت Open Interpreter است. نسخه قدیمی Python اکنون به‌صورت یک Fork جداگانه و با نگهداری جامعه ادامه پیدا کرده است.

این مقاله فقط براساس نسخه جدید و رسمی Open Interpreter نوشته شده است. مخزن رسمی Open Interpreter

Open Interpreter دقیقاً چه کاری انجام می‌دهد؟

Open Interpreter بین کاربر، مدل هوش مصنوعی و سیستم‌عامل قرار می‌گیرد.

وقتی یک درخواست به آن می‌دهید، معمولاً مراحل زیر انجام می‌شوند:

1. ساختار پروژه و فایل‌های مرتبط را بررسی می‌کند.
2. برای انجام کار یک مسیر اجرایی پیشنهاد می‌دهد.
3. فایل‌های موردنیاز را می‌خواند.
4. تغییرات لازم را ایجاد می‌کند.
5. فرمان‌هایی مانند اجرای تست، Build یا Lint را اجرا می‌کند.
6. خروجی فرمان‌ها را برای مدل ارسال می‌کند.
7. در صورت وجود خطا، مسیر اصلاح را ادامه می‌دهد.
8. در پایان، تغییرات انجام‌شده را گزارش می‌کند.

Open Interpreter در نسخه جدید از Sandbox و Approval Policy استفاده می‌کند. Sandbox محدوده فنی دسترسی عامل را مشخص می‌کند و Approval Policy تعیین می‌کند چه اقداماتی پیش از اجرا به تأیید کاربر نیاز دارند. مستندات رسمی Sandbox و تأیید عملیات

Open Interpreter چه تفاوتی با چت‌بات دارد؟

یک چت‌بات معمولی می‌تواند برای شما کد تولید کند، اما معمولاً به پروژه محلی دسترسی ندارد. باید پاسخ را کپی کنید، داخل فایل قرار دهید، برنامه را اجرا کنید و خطا را دوباره برای چت‌بات بفرستید.

Open Interpreter این چرخه را داخل محیط پروژه انجام می‌دهد:

چرا Open Interpreter برای کاربران ایرانی مناسب است؟

Open Interpreter متن‌باز است و روی کامپیوتر کاربر اجرا می‌شود. برای استفاده از نسخه ترمینال، الزام فنی به خرید اشتراک خارجی Open Interpreter وجود ندارد.

با اتصال آن به درواره:

• می‌توانید هزینه API را به‌صورت ریالی پرداخت کنید.
• نیازی به ساخت حساب مستقیم در چند سرویس خارجی ندارید.
• از یک آدرس API ثابت برای مدل‌های مختلف استفاده می‌کنید.
• کلید API از درواره دریافت می‌شود.
• می‌توانید مدل را متناسب با هزینه و پیچیدگی پروژه تغییر دهید.
• فایل‌ها و فرمان‌ها روی کامپیوتر خودتان مدیریت می‌شوند.

البته وقتی از یک مدل ابری استفاده می‌کنید، محتوای لازم برای پردازش درخواست به API مدل ارسال خواهد شد. بنابراین نباید تصور کرد که استفاده از نسخه محلی Open Interpreter، تمام پردازش هوش مصنوعی را آفلاین می‌کند.

برای پردازش کاملاً محلی نیز می‌توان Open Interpreter را به Ollama یا LM Studio متصل کرد. مستندات رسمی، هر دو را به‌عنوان ارائه‌دهنده محلی پشتیبانی می‌کنند. راهنمای انتخاب مدل در Open Interpreter

معماری اتصال Open Interpreter به درواره

ساختار این اتصال به‌صورت زیر است:

1. کاربر درخواست خود را در ترمینال وارد می‌کند.
2. Open Interpreter اطلاعات مرتبط پروژه را جمع‌آوری می‌کند.
3. درخواست به API درواره ارسال می‌شود.
4. مدل انتخاب‌شده درباره اقدام بعدی تصمیم می‌گیرد.
5. Open Interpreter تغییر یا فرمان پیشنهادی را نمایش می‌دهد.
6. در صورت نیاز، کاربر آن را تأیید می‌کند.
7. فرمان داخل Sandbox اجرا می‌شود.
8. خروجی برای ادامه فرایند به مدل بازگردانده می‌شود.

آدرس پایه API درواره در این معماری برابر است با:

https://api.darvareh.ir/v1

از آنجا که درواره API سازگار با OpenAI ارائه می‌کند، در تنظیمات Open Interpreter از Wire API نوع chat استفاده می‌کنیم.

پیش‌نیازهای نصب

برای استفاده از این آموزش به موارد زیر نیاز دارید:

• Windows، Linux، macOS یا WSL
• یک ترمینال مانند PowerShell، Windows Terminal یا Bash
• دسترسی به اینترنت برای نصب و فراخوانی مدل
• حساب کاربری درواره
• کلید API درواره
• شناسه یک مدل مناسب برنامه‌نویسی و Tool Calling
• Git برای کار با پروژه‌های نرم‌افزاری

Git برای اجرای Open Interpreter الزامی نیست، اما برای مشاهده تغییرات، بررسی Diff و کار روی Repositoryها توصیه می‌شود. راهنمای رسمی نصب

مرحله اول: دریافت کلید API درواره

ابتدا وارد درواره شوید و از پنل کاربری یک کلید API ایجاد کنید.

کلید را در اختیار دیگران قرار ندهید و آن را داخل فایل‌های پروژه، Repository عمومی یا کد سمت کاربر ننویسید.

برای بررسی کلید و مشاهده مدل‌های در دسترس می‌توانید از دستور زیر استفاده کنید:

curl https://api.darvareh.ir/v1/models \
  -H "Authorization: Bearer YOUR_DARVAREH_API_KEY"

در PowerShell می‌توانید از دستور زیر استفاده کنید:

$headers = @{
    Authorization = "Bearer YOUR_DARVAREH_API_KEY"
}

Invoke-RestMethod `
    -Method GET `
    -Uri "https://api.darvareh.ir/v1/models" `
    -Headers $headers

از خروجی دریافت‌شده، مقدار دقیق id مدل موردنظر را یادداشت کنید.

برای Open Interpreter بهتر است مدلی را انتخاب کنید که در برنامه‌نویسی، اجرای ابزار و دنبال‌کردن دستورهای چندمرحله‌ای عملکرد مناسبی داشته باشد.

مرحله دوم: نصب Open Interpreter در Linux یا macOS

ترمینال را باز و دستور رسمی زیر را اجرا کنید:

curl -fsSL https://www.openinterpreter.com/install | sh

پس از پایان نصب، ترمینال را ببندید و دوباره باز کنید. سپس نسخه برنامه را بررسی کنید:

interpreter --version

فرمان کوتاه زیر نیز برای اجرای برنامه قابل استفاده است:

i

اگر فرمان شناسایی نشد، ابتدا یک ترمینال جدید باز کنید تا تغییرات مربوط به PATH اعمال شوند.

نصب Open Interpreter در Windows

PowerShell را باز و دستور رسمی زیر را اجرا کنید:

irm https://www.openinterpreter.com/install.ps1 | iex

پس از پایان نصب، PowerShell را ببندید و مجدداً باز کنید. سپس اجرا را بررسی کنید:

interpreter --version

برای پروژه‌هایی که ابزارها و فرمان‌های Linux دارند، استفاده از WSL نیز امکان‌پذیر است. در WSL باید همان دستور نصب Linux را اجرا کنید:

curl -fsSL https://www.openinterpreter.com/install | sh

برای پروژه‌های Windows از PowerShell و مسیرهای Windows استفاده کنید. برای پروژه‌های Linux، Docker و ابزارهای مبتنی بر Bash معمولاً WSL محیط سازگارتری فراهم می‌کند. راهنمای Open Interpreter برای Windows

مرحله سوم: تعریف کلید API درواره

در Linux، macOS یا WSL دستور زیر را اجرا کنید:

export DARVAREH_API_KEY="YOUR_DARVAREH_API_KEY"

این متغیر فقط در همان جلسه ترمینال فعال خواهد بود.

در PowerShell از دستور زیر استفاده کنید:

$env:DARVAREH_API_KEY = "YOUR_DARVAREH_API_KEY"

این مقدار نیز فقط برای پنجره فعلی PowerShell تنظیم می‌شود.

استفاده از Environment Variable باعث می‌شود کلید API را مستقیماً داخل فایل تنظیمات Open Interpreter قرار ندهید.

مرحله چهارم: ساخت فایل تنظیمات Open Interpreter

Open Interpreter تنظیمات پایدار را از فایل config.toml می‌خواند.

مسیر تنظیمات در Linux، macOS و WSL:

~/.openinterpreter/config.toml

مسیر تنظیمات در Windows:

%USERPROFILE%\.openinterpreter\config.toml

در Linux یا WSL پوشه را بسازید:

mkdir -p ~/.openinterpreter
nano ~/.openinterpreter/config.toml

در Windows می‌توانید از PowerShell استفاده کنید:

New-Item `
    -ItemType Directory `
    -Force `
    "$env:USERPROFILE\.openinterpreter"

سپس فایل را با Notepad باز کنید:

notepad "$env:USERPROFILE\.openinterpreter\config.toml"

مرحله پنجم: اتصال Open Interpreter به درواره

تنظیمات زیر را داخل config.toml قرار دهید:

model_provider = "darvareh"
model = "YOUR_MODEL_ID"

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[model_providers.darvareh]
name = "Darvareh"
base_url = "https://api.darvareh.ir/v1"
env_key = "DARVAREH_API_KEY"
wire_api = "chat"

مقدار زیر را با شناسه دقیق مدل موجود در درواره جایگزین کنید:

YOUR_MODEL_ID

بخش‌های این تنظیمات عبارت‌اند از:

• model_provider: ارائه‌دهنده فعال را مشخص می‌کند.
• model: شناسه دقیق مدل را تعیین می‌کند.
• sandbox_mode: دسترسی نوشتن را به Workspace محدود می‌کند.
• approval_policy: برای عملیات خارج از محدوده عادی از کاربر اجازه می‌گیرد.
• base_url: آدرس پایه API درواره است.
• env_key: نام متغیری است که کلید API از آن خوانده می‌شود.
• wire_api: نوع درخواست ارسالی به API را مشخص می‌کند.

Open Interpreter برای ارائه‌دهندگان سفارشی از سه نوع ارتباط responses، chat و messages پشتیبانی می‌کند. برای APIهای مبتنی بر Chat Completions باید مقدار chat انتخاب شود. مستندات رسمی Model Providers

مرحله ششم: اجرای Open Interpreter

وارد پوشه پروژه شوید:

cd path/to/your-project

سپس Open Interpreter را اجرا کنید:

interpreter

یا از فرمان کوتاه استفاده کنید:

i

در اولین آزمایش، یک درخواست ساده و محدود وارد کنید:

ساختار این پروژه را بررسی کن، فایل‌های اصلی را معرفی کن و هیچ تغییری ایجاد نکن.

برای یک بررسی کاملاً Read-only می‌توانید برنامه را با این دستور اجرا کنید:

interpreter \
  --sandbox read-only \
  "ساختار پروژه را تحلیل کن و فقط گزارش بده"

این حالت برای آشنایی اولیه با ابزار و بررسی پروژه‌های ناشناس مناسب است.

بررسی تنظیمات فعال

پس از ورود به رابط Open Interpreter، دستور زیر را وارد کنید:

/debug-config

این دستور نشان می‌دهد تنظیمات نهایی از کدام فایل‌ها دریافت شده‌اند.

برای انتخاب یا تغییر مدل:

/model

برای مشاهده یا تغییر مجوزها:

/permissions

اگر Open Interpreter به ارائه‌دهنده اشتباه متصل شد، موارد زیر را بررسی کنید:

model_provider = "darvareh"

و:

[model_providers.darvareh]

نام Provider باید در هر دو قسمت دقیقاً یکسان باشد.

اولین پروژه عملی: تحلیل یک Repository

ابتدا Open Interpreter را در حالت Read-only اجرا کنید:

cd my-project

interpreter \
  --sandbox read-only \
  "این پروژه را تحلیل کن و معماری، نقاط ورود، وابستگی‌ها و روش اجرای آن را توضیح بده"

در این حالت عامل می‌تواند فایل‌ها را بررسی کند، اما اجازه تغییر آن‌ها را ندارد.

خروجی را از نظر موارد زیر بررسی کنید:

• آیا زبان و Framework پروژه درست تشخیص داده شده است؟
• آیا فایل‌های اصلی شناسایی شده‌اند؟
• آیا دستور اجرای پروژه صحیح است؟
• آیا عامل از خواندن فایل‌های غیرضروری خودداری کرده است؟
• آیا مدل توانسته ارتباط اجزای پروژه را توضیح دهد؟

پروژه عملی دوم: اصلاح یک خطا

برای ویرایش فایل‌های داخل پروژه، از حالت workspace-write استفاده کنید:

interpreter \
  --sandbox workspace-write \
  --ask-for-approval on-request

سپس یک درخواست مشخص وارد کنید:

تست‌های پروژه را اجرا کن، علت تست‌های ناموفق را پیدا کن و قبل از تغییر فایل‌ها مسیر اصلاح را توضیح بده. فقط فایل‌های مرتبط را تغییر بده و در پایان تست‌ها را دوباره اجرا کن.

درخواست مشخص معمولاً نتیجه بهتری از جمله کوتاهی مانند «این پروژه را درست کن» ایجاد می‌کند.

بهتر است در درخواست مشخص کنید:

• هدف نهایی چیست؟
• چه فایل‌هایی نباید تغییر کنند؟
• چه فرمان‌هایی باید اجرا شوند؟
• معیار موفقیت چیست؟
• آیا تغییر وابستگی‌ها مجاز است؟
• آیا عامل باید قبل از ویرایش برنامه خود را توضیح دهد؟

اجرای غیرتعاملی با interpreter exec

برای وظایف مشخص می‌توانید از حالت غیرتعاملی استفاده کنید:

interpreter exec "فایل README را براساس ساختار فعلی پروژه به‌روزرسانی کن"

برای دریافت خروجی JSON:

interpreter exec \
  --json \
  "این Repository را خلاصه کن"

حالت غیرتعاملی برای Scriptها، فرایندهای تکراری و محیط‌های CI مناسب است؛ اما قبل از استفاده عملی باید رفتار عامل را روی یک محیط آزمایشی بررسی کنید.

ادامه جلسه قبلی

Open Interpreter می‌تواند جلسه‌های قبلی را از سر بگیرد.

برای مشاهده و انتخاب یک جلسه:

interpreter resume

برای ادامه آخرین جلسه:

interpreter resume --last

این قابلیت زمانی مفید است که تحلیل یا توسعه یک پروژه در چند مرحله انجام می‌شود و نمی‌خواهید تمام زمینه گفتگو را دوباره توضیح دهید.

استفاده از Open Interpreter برای بررسی تغییرات Git

یکی از کاربردهای مناسب Open Interpreter، بررسی تغییرات ایجادشده در پروژه است.

برای بررسی تغییرات Commit‌نشده می‌توانید از فرمان زیر استفاده کنید:

interpreter exec review --uncommitted

همچنین می‌توانید درخواست زیر را مطرح کنید:

تغییرات Git را بررسی کن. خطاهای احتمالی، تغییر رفتار، تست‌های ازدست‌رفته و بخش‌های نیازمند مستندسازی را گزارش بده. هیچ فایلی را تغییر نده.

بهتر است پیش از شروع کار مطمئن شوید تغییرات مهم قبلی Commit شده‌اند. به این ترتیب مشاهده و بازگرداندن تغییرات عامل ساده‌تر خواهد بود.

اتصال MCP به Open Interpreter

Open Interpreter از Model Context Protocol یا MCP پشتیبانی می‌کند. MCP به عامل اجازه می‌دهد از ابزارهای مشخصی مانند مستندات داخلی، پایگاه داده، Issue Tracker یا سرویس‌های سازمانی استفاده کند.

نمایش MCP Serverهای ثبت‌شده:

interpreter mcp list

اضافه‌کردن یک MCP Server محلی:

interpreter mcp add my-server -- command-to-start-server

اضافه‌کردن یک MCP Server مبتنی بر HTTP:

interpreter mcp add docs \
  --url https://mcp.example.com

MCP را فقط زمانی اضافه کنید که کاربرد مشخصی برای آن دارید. فعال‌کردن تعداد زیادی ابزار می‌تواند انتخاب ابزار را برای مدل دشوارتر و مصرف توکن را بیشتر کند. راهنمای رسمی MCP در Open Interpreter

حالت‌های Sandbox در Open Interpreter

Open Interpreter سه حالت اصلی Sandbox دارد:

برای استفاده روزمره، ترکیب زیر مناسب‌تر است:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

حالت danger-full-access را برای استفاده عادی فعال نکنید. همچنین گزینه --yolo کنترل Sandbox و تأیید عملیات را کنار می‌گذارد و برای سیستم اصلی مناسب نیست.

Open Interpreter نیز در مستندات رسمی توصیه می‌کند کاربران نامطمئن کار را با workspace-write و on-request آغاز کنند.

چند نمونه پرامپت کاربردی

تحلیل پروژه

ساختار پروژه را بررسی کن و یک گزارش شامل معماری، وابستگی‌ها، نقاط ورود، روش اجرا و بخش‌های فاقد تست تهیه کن. هیچ فایلی را تغییر نده.

اضافه‌کردن قابلیت

یک Endpoint برای بررسی سلامت سرویس اضافه کن. ابتدا ساختار فعلی API را بررسی کن، از الگوی موجود پروژه پیروی کن، تست بنویس و در پایان تست‌ها را اجرا کن.

اصلاح خطا

این خطا را بازتولید کن، علت اصلی را پیدا کن و کوچک‌ترین تغییر ممکن را برای اصلاح آن انجام بده. وابستگی جدید اضافه نکن و در پایان تست مرتبط را اجرا کن.

مستندسازی

براساس کد فعلی پروژه، بخش نصب، تنظیم متغیرهای محیطی، اجرای توسعه و اجرای تست‌ها را به README اضافه کن. هیچ ادعایی که از داخل Repository قابل تأیید نیست ننویس.

پردازش فایل داده

ساختار فایل CSV داخل پوشه data را بررسی کن، ستون‌های ناقص و رکوردهای تکراری را گزارش بده و قبل از ساخت فایل پاک‌سازی‌شده، روش پیشنهادی را توضیح بده.

Open Interpreter یا Cline و Roo Code؟

اگر بیشتر زمان خود را در Visual Studio Code می‌گذرانید، Cline یا Roo Code ممکن است رابط آشناتری داشته باشند. اگر به یک عامل مستقل داخل ترمینال نیاز دارید، Open Interpreter انتخاب مناسب‌تری است.

Open Interpreter همچنین می‌تواند از طریق ACP در Editorها و Clientهای سازگار اجرا شود:

interpreter acp

مدیریت هزینه API

Open Interpreter ممکن است برای انجام یک وظیفه چندین بار با مدل ارتباط برقرار کند. تحلیل فایل، طراحی تغییر، اجرای فرمان، دریافت خروجی و اصلاح خطا هرکدام می‌توانند یک مرحله جداگانه باشند.

برای کنترل هزینه:

• ابتدا وظیفه را دقیق و محدود تعریف کنید.
• پروژه را از پوشه درست اجرا کنید.
• فایل‌های غیرضروری را از محدوده کار خارج کنید.
• برای تحلیل اولیه از مدل‌های اقتصادی‌تر استفاده کنید.
• مدل‌های قوی‌تر را برای تغییرات پیچیده انتخاب کنید.
• از درخواست‌های بسیار کلی مانند «کل پروژه را بهتر کن» پرهیز کنید.
• پس از طولانی‌شدن بیش‌ازحد جلسه، یک جلسه جدید با خلاصه لازم بسازید.
• خروجی‌های حجیم Build یا Log را بدون نیاز کامل وارد زمینه مدل نکنید.
• مصرف حساب را از پنل درواره بررسی کنید.

خطاهای رایج و روش رفع آن‌ها

خطای 401 یا Unauthorized

علت احتمالی، نبودن یا نامعتبر بودن کلید API است.

در Linux بررسی کنید:

echo "$DARVAREH_API_KEY"

در PowerShell:

$env:DARVAREH_API_KEY

اگر مقدار خالی بود، متغیر را دوباره تعریف و Open Interpreter را از همان ترمینال اجرا کنید.

خطای model not found

شناسه نوشته‌شده در config.toml باید دقیقاً با شناسه API مدل یکسان باشد:

model = "YOUR_EXACT_MODEL_ID"

فهرست مدل‌ها را دوباره از Endpoint زیر دریافت کنید:

https://api.darvareh.ir/v1/models

خطای مربوط به Responses API

اگر Endpoint در حالت Responses تنظیم شده باشد، اما مدل یا ارائه‌دهنده فقط Chat Completions را پشتیبانی کند، مقدار زیر را بررسی کنید:

wire_api = "chat"

پس از تغییر فایل، Open Interpreter را ببندید و مجدداً اجرا کنید.

مدل نمی‌تواند از ابزارها استفاده کند

هر مدل زبانی برای کار Agentic مناسب نیست. ممکن است مدل پاسخ متنی مناسبی تولید کند، اما نتواند فرمان‌ها و ابزارها را به‌درستی مدیریت کند.

در این شرایط:

• یک مدل مناسب برنامه‌نویسی انتخاب کنید.
• مدلی با پشتیبانی Tool Calling انتخاب کنید.
• وظیفه را ساده‌تر و مرحله‌بندی کنید.
• از درخواست‌های مبهم خودداری کنید.
• مدل دیگری را از درواره آزمایش کنید.

فایل‌ها تغییر نمی‌کنند

ممکن است برنامه در حالت read-only اجرا شده باشد.

تنظیمات را بررسی کنید:

/permissions

یا برنامه را با حالت Workspace اجرا کنید:

interpreter --sandbox workspace-write

عامل به شبکه دسترسی ندارد

در حالت Workspace، دسترسی شبکه ممکن است به‌صورت پیش‌فرض محدود باشد. اگر نصب وابستگی یا دسترسی به یک منبع خارجی لازم باشد، Open Interpreter باید درخواست تأیید نمایش دهد.

بدون بررسی، دسترسی کامل شبکه یا Sandbox را برای تمام جلسات فعال نکنید.

فرمان interpreter پیدا نمی‌شود

پس از نصب، ترمینال را ببندید و دوباره باز کنید. سپس اجرا کنید:

interpreter --version

در Windows بررسی کنید Installer مسیر برنامه را به PATH اضافه کرده باشد. در WSL نیز نصب باید داخل همان محیط WSL انجام شود.

فایل TOML معتبر نیست

خطاهای رایج فایل TOML عبارت‌اند از:

• استفاده از کوتیشن‌های فارسی
• نوشتن نام Provider متفاوت در دو بخش
• حذف علامت مساوی
• تعریف تکراری یک تنظیم
• نوشتن آدرس مدل داخل base_url
• قرار دادن API Key به‌جای نام Environment Variable

برای مشاهده تنظیمات نهایی از دستور زیر استفاده کنید:

/debug-config

روش به‌روزرسانی Open Interpreter

برای دریافت نسخه جدید اجرا کنید:

interpreter update

پس از به‌روزرسانی، نسخه را بررسی کنید:

interpreter --version

از آنجا که Open Interpreter در سال ۲۰۲۶ تغییرات معماری مهمی داشته است، قبل از استفاده از دستورهای آموزش‌های قدیمی باید نسخه برنامه و مستندات رسمی را بررسی کنید.

اشتباهات رایج کاربران

• نصب نسخه قدیمی Python به‌جای نسخه رسمی جدید
• استفاده از آموزش‌هایی که api_base قدیمی را پیشنهاد می‌کنند
• قراردادن کلید API داخل Repository
• انتخاب مدل نامناسب برای Tool Calling
• اجرای عامل از پوشه اشتباه
• فعال‌کردن دسترسی کامل برای یک وظیفه ساده
• تأیید فرمان‌ها بدون خواندن آن‌ها
• شروع کار روی پروژه‌ای که تغییرات قبلی آن Commit نشده است
• ارائه درخواست بسیار کلی و بدون معیار موفقیت
• استفاده از مدل گران برای تمام مراحل کار
• انتظار عملکرد کاملاً آفلاین هنگام استفاده از API ابری

چک‌لیست نهایی راه‌اندازی

• نسخه رسمی جدید Open Interpreter نصب شده است.
• فرمان interpreter --version اجرا می‌شود.
• کلید API درواره ایجاد شده است.
• کلید در Environment Variable قرار دارد.
• شناسه دقیق مدل از درواره دریافت شده است.
• فایل config.toml ساخته شده است.
• model_provider روی darvareh قرار دارد.
• آدرس پایه https://api.darvareh.ir/v1 است.
• مقدار wire_api روی chat قرار دارد.
• اولین آزمایش در حالت read-only انجام شده است.
• برای ویرایش پروژه از workspace-write استفاده می‌شود.
• تأیید عملیات روی on-request قرار دارد.
• پروژه پیش از تغییرات مهم در Git ذخیره شده است.
• مصرف API از پنل درواره کنترل می‌شود.

پرسش‌های متداول

آیا Open Interpreter رایگان است؟

نسخه ترمینال Open Interpreter متن‌باز است. استفاده از مدل‌های ابری ممکن است هزینه API داشته باشد. با اتصال به درواره، هزینه مدل انتخاب‌شده براساس مصرف محاسبه و به‌صورت ریالی پرداخت می‌شود.

آیا Open Interpreter در ایران قابل استفاده است؟

بله. برنامه روی سیستم کاربر اجرا می‌شود و می‌توان آن را به API درواره متصل کرد. در این روش برای استفاده از مدل‌ها نیازی به پرداخت مستقیم ارزی به ارائه‌دهنده خارجی ندارید.

آیا Open Interpreter همان Code Interpreter در ChatGPT است؟

خیر. Code Interpreter یکی از قابلیت‌های محیط ChatGPT است، اما Open Interpreter یک پروژه متن‌باز مستقل است که داخل ترمینال اجرا می‌شود و می‌تواند روی فایل‌ها و فرمان‌های سیستم کار کند.

آیا برای Open Interpreter به کارت گرافیک نیاز داریم؟

اگر از API درواره استفاده کنید، پردازش مدل روی زیرساخت ارائه‌دهنده انجام می‌شود و سیستم شما به کارت گرافیک قدرتمند نیاز ندارد. برای اجرای مدل محلی با Ollama ممکن است به RAM یا GPU بیشتری نیاز داشته باشید.

آیا می‌توان مدل Open Interpreter را تغییر داد؟

بله. شناسه مدل را می‌توانید در config.toml تغییر دهید یا از دستور زیر داخل برنامه استفاده کنید:

/model

آیا Open Interpreter می‌تواند فایل‌ها را حذف کند؟

عامل می‌تواند براساس سطح دسترسی تعیین‌شده عملیات مختلفی پیشنهاد دهد. به همین دلیل بهتر است از Sandbox محدود و Approval Policy مناسب استفاده کنید و فرمان‌های تغییردهنده یا حذف‌کننده را بدون بررسی تأیید نکنید.

آیا می‌توان Open Interpreter را به Ollama متصل کرد؟

بله. Open Interpreter به‌صورت داخلی از Ollama و LM Studio پشتیبانی می‌کند. برای آشنایی با اجرای مدل‌های محلی، مقاله آموزش Ollama را مطالعه کنید.

آیا Open Interpreter رابط گرافیکی دارد؟

محصول Open Interpreter دارای نسخه دسکتاپ جداگانه نیز هست، اما این آموزش مربوط به نسخه متن‌باز ترمینال است. نسخه ترمینال برای توسعه‌دهندگان، Repositoryها و فرایندهای خط فرمان مناسب‌تر است.

Open Interpreter بهتر است یا Cline؟

اگر محیط اصلی شما Visual Studio Code است، Cline تجربه یکپارچه‌تری داخل Editor ارائه می‌کند. اگر عامل مستقل ترمینال، اجرای غیرتعاملی، Resume، MCP و کار با Scriptها برایتان مهم است، Open Interpreter مناسب‌تر خواهد بود.

مقالات مرتبط

• آموزش اتصال Cline به API درواره
• آموزش اتصال Roo Code به API درواره
• راهنمای OpenAI Codex
• API سازگار با OpenAI چیست؟
• آموزش دریافت کلید API هوش مصنوعی
• راهنمای کامل MCP
• آموزش اجرای مدل‌های محلی با Ollama

منابع اصلی

• وب‌سایت رسمی Open Interpreter
• راهنمای رسمی نصب Open Interpreter
• مستندات تنظیمات Open Interpreter
• مستندات Model Providers
• راهنمای Sandbox و Approval
• مرجع فرمان‌های CLI
• مخزن رسمی Open Interpreter در GitHub

جمع‌بندی

Open Interpreter یک عامل هوش مصنوعی متن‌باز برای کار داخل ترمینال است که می‌تواند پروژه‌ها را تحلیل کند، فایل‌ها را تغییر دهد، فرمان‌ها را اجرا کند و نتیجه کار را مرحله‌به‌مرحله بررسی کند.

نسخه جدید Open Interpreter نسبت به نسخه قدیمی Python تغییرات اساسی دارد و اکنون از ساختار Codex، ارائه‌دهندگان سفارشی، Sandbox، Approval Policy، MCP، Session و اجرای غیرتعاملی پشتیبانی می‌کند.

با اتصال این ابزار به API درواره، کاربران ایرانی می‌توانند بدون خرید مستقیم اعتبار خارجی، مدل مناسب خود را انتخاب و هزینه مصرف را به‌صورت ریالی پرداخت کنند.

برای شروع، Open Interpreter را نصب کنید، کلید API درواره را در Environment Variable قرار دهید و Provider سفارشی را با آدرس زیر در config.toml تعریف کنید:

https://api.darvareh.ir/v1

پیشنهاد می‌شود نخستین آزمایش را روی یک پروژه نمونه و در حالت read-only انجام دهید. پس از اطمینان از عملکرد مدل و تنظیمات، دسترسی workspace-write را برای پروژه‌های واقعی فعال کنید.

این مقاله صرفاً با هدف آموزش و اطلاع‌رسانی تهیه شده است. پیش از استفاده عملی، مستندات رسمی سرویس‌ها و صفحه سلب مسئولیت را مطالعه کنید.