Trae Agent را به یک endpoint برای هر مدل اشاره دهید.

پاسخ سریع: یک بلوک provider، یک بلوک مدل.

پیکربندی فعلی Trae Agent YAML است: trae_config.yaml در دایرکتوری پروژه، با سه بلوک مرتبط. model_providers endpoint ها را تعریف می‌کند، و هر ورودی api_key، provider، و base_url می‌گیرد، پس یک gateway سازگار با OpenAI فقط یک provider از نوع openai با base_url عوض‌شده است. models config های مدل نام‌گذاری‌شده را تعریف می‌کند که به یک provider از طریق model_provider ارجاع می‌دهند. agents برابر trae_agent را به یکی از آن نام‌های مدل مقید می‌کند. README upstream دقیقاً همین شکل را برای مسیردهی از طریق یک سرویس چند-مدل نشان می‌دهد: یک ورودی provider برابر openai که base_url آن به ریشه /v1 سرویس اشاره می‌کند. برای APIsRouter، آن https://api.apisrouter.com/v1 است، و فیلد model سپس هر id کاتالوگی را به‌عنوان رشته ساده می‌گیرد، شامل id های Claude و Kimi، چون نوع provider فقط فرمت درخواست را تصمیم می‌گیرد، نه vendor را.

model_providers:
  apisrouter:
    api_key: your_apisrouter_api_key
    provider: openai
    base_url: https://api.apisrouter.com/v1

models:
  trae_agent_model:
    model_provider: apisrouter
    model: claude-sonnet-4-6
    max_tokens: 4096
    temperature: 0.5

چطور Trae Agent در داخل سیم‌کشی شده.

Trae Agent (bytedance در GitHub، حدود ۱۲ هزار ستاره) agent مهندسی-نرم‌افزار پژوهش-محور ByteDance برای خط فرمان است: به trae-cli یک وظیفه بدهید و آن را با یک حلقه tool شفاف کار می‌کند، bash، ویرایش فایل، و تفکر ترتیبی در میان ابزارهای داخلی، تا یک max_steps قابل‌پیکربندی. عمداً ماژولار است، به همین دلیل config provider ها را از مدل‌ها از agent ها جدا می‌کند: همان provider می‌تواند از چندین config مدل پشتیبانی کند، و عوض‌کردن چیزی که agent روی آن اجرا می‌شود یک ویرایش یک‌خطی به یک ارجاع نام است. دو اسلات مدل در عمل اهمیت دارند. trae_agent_model حلقه اصلی است، مدلی که استدلال، فراخوانی‌های tool، و ویرایش‌ها را انجام می‌دهد، جایی که max_steps برابر دویست یعنی یک وظیفه تکی می‌تواند یک دنباله بلند از فراخوانی‌های صورت‌حساب‌شده باشد. lakeview_model ویژگی Lakeview را قدرت می‌دهد، ویژگی خلاصه‌سازی-گام Trae که خلاصه‌های کوتاه و خوانا از کاری که agent در هر گام انجام داده تولید می‌کند. Lakeview مکرر شلیک می‌کند و خروجی آن نثری است که با نگاهی گذرا قابل‌فهم است، که آن را اسلات کتاب‌درسی برای یک id سریع می‌کند در حالی که حلقه اصلی یک id frontier نگه می‌دارد. پیکربندی از بیش از YAML resolve می‌شود: CLI مقادیر --provider و --model را به ازای هر اجرا می‌پذیرد، و متغیرهای محیطی مختص-provider، OPENAI_API_KEY و OPENAI_BASE_URL در میان مجموعه مستندشده، همان تنظیمات را تغذیه می‌کنند. flag ها روشی هستند که با آن‌ها یک مدل دوم را بدون لمس فایل A/B می‌کنید.

راه‌اندازی کامل: agent، Lakeview، و یک اجرا.

config کامل agent را به یک مدل اصلی و Lakeview را به یک مدل سریع مقید می‌کند، هر دو از طریق همان ورودی provider. به واسطه توجه کنید: agents.trae_agent.model یک ورودی در models را نام می‌برد، و هر ورودی models یک provider را از طریق model_provider نام می‌برد. یک غلط‌تایپی در هرکدام از ارجاع‌ها زنجیره را شکست می‌دهد، پس سه نام را سازگار نگه دارید. یک نکته تاریخی که بیشتر tutorial های گیج‌کننده را توضیح می‌دهد: پیکربندی Trae Agent قبلاً trae_config.json بود، و repo اکنون آن فرمت را به‌عنوان legacy با YAML به‌عنوان فرم فعلی مستند می‌کند. راهنماهایی که JSON نشان می‌دهند یک چیدمان قدیمی‌تر را توصیف می‌کنند؛ کلیدها مهاجرت کردند، مفاهیم منتقل شدند. اگر یک config JSON قدیمی دارید، سند legacy-config در repo نگاشت را پوشش می‌دهد. زاویه یک-کلید ارزش تشریح کردن برای این ابزار به‌خصوص را دارد. فهرست provider native در Trae Agent vendor های آمریکایی و چینی را دربرمی‌گیرد، که معمولاً یک حساب و کلید به ازای هر vendor می‌خواهد، که برخی از آن‌ها بسته به جایی که هستید سخت به‌دست می‌آیند. پشت یک ورودی gateway، claude-sonnet-4-6، gpt-5.5، deepseek-v4-pro، glm-5.2، و kimi-k2.7-code همه یک رشته-مدل فاصله دارند، روی یک کلید، با یک موجودی، از هر طرف اقیانوس آرام که توسعه می‌دهید.

agents:
  trae_agent:
    enable_lakeview: true
    model: trae_agent_model
    max_steps: 200
    tools:
      - bash
      - str_replace_based_edit_tool
      - sequentialthinking
      - task_done

model_providers:
  apisrouter:
    api_key: your_apisrouter_api_key
    provider: openai
    base_url: https://api.apisrouter.com/v1

models:
  trae_agent_model:
    model_provider: apisrouter
    model: claude-sonnet-4-6
    max_tokens: 4096
    temperature: 0.5
  lakeview_model:
    model_provider: apisrouter
    model: claude-haiku-4-5-20251001
    max_tokens: 4096
    temperature: 0.5

انتخاب مدل‌ها برای حلقه agent.

flag های --provider و --model workflow مقایسه را ملموس می‌کنند: همان وظیفه را دوبار با flag های متفاوت اجرا کنید، گام‌ها-تا-انجام و usage قیمت‌گذاری‌شده به ازای هر مدل را در کنسول بخوانید، و برنده را به trae_config.yaml ارتقا دهید.

• حلقه اصلی کار tool افق-بلند است: خواندن فایل‌ها، ویرایش، اجرای bash، قضاوت اینکه کی وظیفه انجام شده. claude-sonnet-4-6 و gpt-5.5 یک برنامه دویست-گامی را کنار هم نگه می‌دارند؛ این اسلات آخرین جا برای صرفه‌جویی است.
• Lakeview خلاصه‌سازی فرکانس-بالا و کم-ریسک است. claude-haiku-4-5-20251001 یا deepseek-v4-flash آن را به‌طور مؤثر رایگان کنار هزینه حلقه اصلی نگه می‌دارد.
• kimi-k2.7-code و glm-5.2 کاندیدهای جدی برای حلقه اصلی روی کدبیس‌هایی با comment های چینی، تاریخچه commit، یا مستندات هستند؛ یک repo دوزبانه جایی است که آن‌ها از مدل‌های انگلیسی-اول در درک، نه فقط قیمت، برتری دارند.
• deepseek-v4-pro انتخاب حجمی برای اجراهای batch است، اجرای همان رفع در سرتاسر بسیاری repo یا اجرای agent در CI، جایی که هزینه هر-وظیفه ضرب می‌شود.
• max_steps تنظیم‌کننده هزینه شماست. مدلی که سرگردان می‌شود گام‌ها را می‌سوزاند؛ هنگام مقایسه کاندیدها، گام‌ها-تا-انجام را روی همان وظیفه مقایسه کنید، نه token به ازای هر درخواست.

پرداخت بر اساس مصرف · پایین‌تر از قیمت رسمی

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

حالت‌های شکست مختص Trae Agent.

سردرگمی JSON-در-برابر-YAML همه‌چیز را هدایت می‌کند. یک trae_config.json کپی‌شده از یک راهنمای قدیمی‌تر در بهترین حالت به‌عنوان legacy خوانده می‌شود و در بدترین حالت نادیده گرفته می‌شود، و علامت این است که CLI طوری رفتار می‌کند که انگار هرگز چیزی پیکربندی نکرده‌اید. راه‌اندازی‌های فعلی به trae_config.yaml تعلق دارند؛ فایل‌های قدیمی را با استفاده از سند legacy-config در repo مهاجرت دهید به‌جای حدس‌زدن نام کلیدها. زنجیره سه-نام بی‌صدا می‌شکند. agents.trae_agent.model باید یک ورودی models را نام ببرد، و model_provider آن ورودی باید یک ورودی model_providers را نام ببرد. یکی را تغییرنام دهید و بقیه را نه و اجرا در startup با یک خطای resolution به‌جای یک خطای درخواست شکست می‌خورد، که شما را به YAML اشاره می‌دهد، نه شبکه. base_url می‌خواهد /v1 شامل شود، مطابق مثال upstream که به ریشه /v1 یک router اشاره می‌کند. یک host خام بعد از اینکه client مسیر chat-completions را اضافه کند ۴۰۴ تولید می‌کند. شکست Lakeview در حالی که agent کار می‌کند یعنی lakeview_model به یک id ارجاع می‌دهد که endpoint سرویس نمی‌دهد، آسان برای از دست‌دادن چون مدل اصلی را تست کرده‌اید و اسلات دوم را فراموش کرده‌اید. و متغیرهای محیطی که بی‌صدا providerای را که فکر می‌کردید فایل-پیکربندی‌شده است پشتیبانی می‌کنند، به‌خصوص OPENAI_API_KEY، ارزش چک‌کردن دارند وقتی احراز هویت بین شل‌ها ناسازگار رفتار می‌کند.

چه کسانی Trae Agent را از طریق یک gateway مسیردهی می‌کنند.

• توسعه‌دهندگانی که Claude یا GPT را می‌خواهند حلقه agent را هدایت کنند و GLM، Kimi، یا DeepSeek یک flag دورتر باشند، بدون نگه‌داشتن یک حساب نزد هر vendor.
• تیم‌های دوزبانه که در سرتاسر کدبیس‌های چینی و انگلیسی کار می‌کنند، که برای آن‌ها قوی‌ترین مدل به ازای هر repo ممکن است از هرکدام از اکوسیستم‌ها بیاید، قابل‌آدرس‌دهی از طریق یک کلید.
• مهندسانی که وظایف batch یا CI برای agent اجرا می‌کنند، جایی که ردیابی usage هر-کلید یک ناوگان از اجراهای trae-cli را به یک گزارش هزینه خوانا تبدیل می‌کند.
• پژوهشگرانی که مدل‌های agent را benchmark می‌کنند، چون Trae Agent برای مقایسه به‌سبک ablation ساخته شده و gateway هر کاندید را همان تغییر یک-flag می‌کند.
• توسعه‌دهندگان بدون دسترسی به صورت‌حساب یک vendor خاص. دسترسی مبتنی بر شارژ بدون الزام کارت وابستگی ثبت‌نام هر-provider را حذف می‌کند.

endpoint را تأیید کنید و اولین وظیفه را عیب‌یابی کنید.

تأیید کنید endpoint id های شما را قبل از اجرای اول سرویس می‌دهد: فهرست /v1/models با کلید شما نگارش معتبر برای هر فیلد model در YAML است، هم اسلات اصلی و هم اسلات Lakeview. شکست‌های اجرای اول تمیز مرتب می‌شوند. یک خطای resolution در config قبل از هر درخواستی زنجیره سه-نام یا یک فایل JSON قدیمی است. یک ۴۰۱ همان api_key در بلوک provider است، یا یک متغیر محیطی که آن را override می‌کند. یک ۴۰۴ روی هر درخواست یک base_url است که /v1 خود را گم کرده. یک خطای model-not-found اسلاتی که اشتباه است را نام می‌برد، چک کنید آیا مدل agent بوده یا مدل Lakeview. و اجرایی که شروع می‌شود اما در میان وظیفه متوقف می‌شود معمولاً سرگردانی مدل است نه شکست endpoint، که همان چیزی است که max_steps و log گام برای آن هستند. وقتی وظایف اجرا شوند، کنسول APIsRouter مدل، شمارش token، و هزینه هر-درخواست را نشان می‌دهد. agent ای که صد گام به ازای هر وظیفه می‌گیرد همه‌چیز را ضرب می‌کند، و usage log جایی است که یاد می‌گیرید یک وظیفه واقعاً روی هر مدل کاندید چقدر هزینه دارد.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

پرسش‌های پرتکرار