agent های Letta را روی یک endpoint سازگار با OpenAI اجرا کنید.

پاسخ سریع: دو متغیر محیطی روی سرور.

مسیر مستند Letta برای endpoint های سازگار با OpenAI پیکربندی محیط روی سرور خودمیزبان است: OPENAI_API_BASE را روی URL endpoint و OPENAI_API_KEY را روی کلید آن تنظیم کنید هنگام راه‌اندازی سرور، و Letta مدل‌هایی که آن endpoint سرویس می‌دهد را ثبت می‌کند. برای APIsRouter base برابر https://api.apisrouter.com/v1 است. هیچ فیلد base-URL به ازای هر agent در UI وجود ندارد؛ endpoint یک تصمیم سطح-سرور است، به همین دلیل محیط سطحی است که اهمیت دارد. یک الزام غیرقابل‌مذاکره است و ارزش خواندن قبل از هر چیز دیگر را دارد: مستندات Letta بیان می‌کنند endpoint های سازگار با OpenAI باید از function calling پشتیبانی کنند، چون حلقه agent روی فراخوانی‌های ابزار ساخته شده. یک endpoint که فقط chat completions ساده انجام می‌دهد اصلاً نمی‌تواند یک agent Letta را اجرا کند. مدل‌های کاتالوگ روی APIsRouter tool calling استاندارد را روی /v1/chat/completions صحبت می‌کنند، که همان شکلی است که Letta انتظار دارد.

docker run \
  -v ~/.letta/.persist/pgdata:/var/lib/postgresql/data \
  -p 8283:8283 \
  -e OPENAI_API_KEY="$APISROUTER_API_KEY" \
  -e OPENAI_API_BASE="https://api.apisrouter.com/v1" \
  letta/letta:latest

چرا Letta بیشتر از یک اپ چت روی مدل خود تکیه می‌کند.

Letta (letta-ai در GitHub، حدود ۲۴ هزار ستاره) از پروژه پژوهشی MemGPT رشد کرد و agent های stateful می‌سازد: agent هایی با حافظه پایدار و خودویرایش که در طول session ها باقی می‌ماند. جایی که یک کلاینت چت پیام شما را می‌فرستد و پاسخ را چاپ می‌کند، یک agent Letta روی هر تعامل یک حلقه داخلی اجرا می‌کند، درباره آنچه می‌داند استدلال می‌کند، ابزارهای حافظه را برای خواندن و بازنویسی حافظه اصلی و archival storage خودش فرا می‌خواند، و تنها بعد از آن یک پاسخ تولید می‌کند. آن معماری دو پیامد برای مسیردهی endpoint دارد. اول، هر گام حلقه یک درخواست tool-calling است، به همین دلیل function calling یک الزام سخت است نه یک مزیت خوب؛ مدلی که با schema های ابزار دست‌وپنجه نرم می‌کند اینجا با ظرافت تنزل نمی‌کند، توانایی agent برای به‌خاطرسپردن را می‌شکند. دوم، حجم درخواست به ازای هر تعامل بیشتر از چیزی است که transcript مکالمه نشان می‌دهد، چون مدیریت حافظه هم‌زمان با پاسخ قابل‌مشاهده شلیک می‌شود. id مدلی که همه این را سرویس می‌دهد یک رشته ساده به endpoint است، پس با یک gateway چند-vendor پشت OPENAI_API_BASE، یک id Claude می‌تواند حلقه agent را اجرا کند در حالی که یک id سریع agent های سبک‌تر را روی همان سرور سرویس می‌دهد، هرکدام با handle خودش آدرس‌دهی می‌شوند.

وضعیت صادقانه پشتیبانی، مستقیم از upstream.

مستندات خود Letta می‌گویند endpoint های پروکسی OpenAI رسماً پشتیبانی نمی‌شوند و احتمالاً با خطا مواجه خواهید شد، توصیه‌کننده اتصالات مستقیم provider به‌جای آن. آن هشدار سزاوار نقل‌قول است نه دفن‌شدن، چون بیشتر صفحات این موضوع وانمود می‌کنند وجود ندارد. آنچه در عمل معنی می‌دهد باریک‌تر از چیزی است که به‌نظر می‌رسد: Letta در برابر API های first-party تست می‌شود، و یک endpoint که از معناشناسی OpenAI منحرف می‌شود، به‌خصوص حول tool calling، شکست‌هایی تولید می‌کند که upstream اولویت نمی‌دهد. یک endpoint که واقعاً spec را پیاده‌سازی می‌کند، شامل فراخوانی‌های ابزار، خوب اجرا می‌شود، و آن دقیقاً همان معیار سازگاری‌ای است که یک gateway با آن زندگی یا می‌میرد. تاریخچه پشتیبانی همچنین یک باگ واقعی داشت که ارزش دانستن دارد. تا اوایل ۲۰۲۶، مدل‌های ثبت‌شده از طریق OPENAI_API_BASE به‌طور خودکار به‌عنوان provider openai-proxy پیشوند می‌گرفتند در حالی که ساخت agent در برابر فهرست کوتاه‌تری از پیشوندهای پذیرفته‌شده اعتبارسنجی می‌شد، پس مدل‌های پروکسی ثبت می‌شدند اما نمی‌توانستند برای ساخت agent استفاده شوند. این مسئله با یک fix در ژانویه ۲۰۲۶ بسته شد؛ اگر یک سرور قدیمی pin-شده اجرا می‌کنید و ساخت agent مدل‌هایی که سرور به‌وضوح فهرست می‌کند را رد می‌کند، این عدم‌تطابق همان چیزی است که به آن برخورده‌اید، و upgrade کردن راه‌حل است. یک هدف متحرک دیگر: سطح محصول Letta در حال جابه‌جایی بوده، و مستندات آن اکنون کاربران جدید را به‌سمت حالت‌های deployment جدیدتر هدایت می‌کند در حالی که اشاره می‌کند image کلاسیک Docker دیگر سطح فعالانه‌نگه‌داری‌شده نیست. متغیرهای محیطی بالا مکانیزم مستند برای سرور خودمیزبان هستند؛ مستندات فعلی را چک کنید تا ببینید upstream در هفته‌ای که deploy می‌کنید کدام artifact سرور را توصیه می‌کند.

# after the server is up, list models Letta knows about
curl -s http://localhost:8283/v1/models/ | head -50
# use the handle exactly as listed when creating agents

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

ارزیابی‌ای که اهمیت دارد وفاداری حلقه است: یک agent تست بسازید، یک مکالمه داشته باشید که به‌روزرسانی‌های حافظه را اجبار می‌کند، سپس حافظه اصلی agent را بخوانید و تأیید کنید واقعاً تغییر کرده. یک مدل می‌تواند پاسخ‌های دلپذیر بنویسد و همچنان قرارداد حافظه را شکست بدهد، و فقط تست حلقه آن را می‌گیرد.

• ویرایش حافظه کار ساختاریافته ابزاری است. claude-sonnet-4-6 و gpt-5.5 حلقه بازنویسی-حافظه-خودتان را قابل‌اعتماد مدیریت می‌کنند، که همان شایستگی اصلی است که یک agent Letta نیاز دارد.
• agent های طولانی‌عمر context را انباشته می‌کنند. مدل‌هایی که عمیق در یک context window منسجم می‌مانند اینجا بیشتر از چت stateless اهمیت دارند، که همان جایی است که claude-opus-4-7 جایگاه خود را برای دستیارهای پرمخاطره کسب می‌کند.
• ناوگان‌های agent سبک، یک به ازای هر کاربر یا هر وظیفه، workload حجمی هستند. claude-haiku-4-5-20251001 هزینه هر-agent را ثابت نگه می‌دارد در حالی که هنوز فراخوانی‌های ابزار شایسته انجام می‌دهد.
• deepseek-v4-pro ارزش تست‌کردن دارد برای agent هایی که استدلال را با ترافیک دوزبانه ترکیب می‌کنند؛ الزام tool-calling gate است، پس حلقه را تست کنید، نه فقط نثر را.
• هرچه انتخاب کنید، به ازای هر agent انتخاب کنید. سرور کل کاتالوگ را ثبت می‌کند، و هر agent به یک handle بایند می‌شود، پس یک concierge حافظه‌سنگین و یک agent وظیفه یک‌بارمصرف می‌توانند id های متفاوتی را کنار هم اجرا کنند.

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

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

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

رد کردن ساخت agent برای مدلی که سرور فهرست می‌کند همان باگ تاریخی پیشوند است. مدل‌های ثبت‌شده از طریق یک پروکسی یک پیشوند provider حمل می‌کردند که ساخت agent روی نسخه‌های تحت‌تأثیر رد می‌کرد. fix در ژانویه ۲۰۲۶ فرود آمد؛ روی release های فعلی، handle نشان‌داده‌شده در فهرست مدل همان handle ای است که کار می‌کند. اگر روی یک image قدیمی‌تر pin هستید، این قوی‌ترین دلیل تکی برای upgrade قبل از دیباگ هر چیز دیگر است. agent ای که پاسخ می‌دهد اما هرگز به‌خاطر نمی‌سپارد یک شکست tool-calling است. یا endpoint function calling را پیاده‌سازی نمی‌کند، یا مدل پشت id به‌ضعف با schema های ابزار برخورد می‌کند. علامت مکالماتی است که کار می‌کنند در حالی که حافظه اصلی هرگز به‌روز نمی‌شود. همان agent را روی claude-sonnet-4-6 تست کنید تا مشکلات endpoint را از مشکلات مدل جدا کنید. متغیرهای محیطی تنظیم‌شده در جای اشتباه یک کلاسیک Docker است: OPENAI_API_BASE صادرشده در shell شما برای یک کانتینر راه‌اندازی‌شده بدون فلگ‌های -e کاری نمی‌کند. متغیرها باید به خود process سرور برسند. و چون endpoint سطح-سرور است، به‌خاطر بسپارید شعاع انفجار: تغییر OPENAI_API_BASE هر agent روی آن سرور را جابه‌جا می‌کند. هیچ override endpoint به ازای هر agent وجود ندارد، پس یک سرور به ازای هر gateway توپولوژی تمیز است، با انتخاب مدل به ازای هر agent که تمایز را انجام می‌دهد.

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

• سازندگان دستیارهای پایدار که ویرایش حافظه با کیفیت Claude می‌خواهند بدون یک حساب vendor، کلید، و سطح صورت‌حساب جدا برای هر مدلی که امتحان می‌کنند.
• تیم‌هایی که ناوگان‌های agent اجرا می‌کنند جایی که هر کاربر یک agent می‌گیرد، و ردیابی usage هر-کلید هزینه واقعی لایه حافظه را به یک گزارش خوانا تبدیل می‌کند.
• پژوهشگرانی که مقایسه می‌کنند مدل‌ها چطور با حافظه خودویرایش برخورد می‌کنند، جایی که هر کاندید یک تغییر handle روی یک agent تست است نه یک migration provider.
• self-hoster ها در محیط‌هایی که دسترسی مستقیم API vendor مسدود است و یک endpoint gateway تکی چیزی است که سیاست شبکه اجازه می‌دهد.
• توسعه‌دهندگان بدون دسترسی به صورت‌حساب یک vendor خاص. دسترسی مبتنی بر شارژ بدون الزام کارت وابستگی ثبت‌نام هر-provider را حذف می‌کند.

endpoint را تأیید کنید و اولین agent را عیب‌یابی کنید.

قبل از سرور، gateway را تأیید کنید: مدل‌ها را با کلید فهرست کنید، و یک chat completion با یک تعریف ابزار متصل اجرا کنید، چون tool calling همان قابلیتی است که Letta واقعاً به آن وابسته است. اگر رفت‌وبرگشت tool-call در curl کار کند، نیمه endpoint اثبات شده است. سپس سرور را با دو متغیر راه‌اندازی کنید و فهرست مدل آن را بخوانید. ظاهرشدن مدل‌ها آنجا ثبت را اثبات می‌کند؛ یک agent ساخته‌شده با موفقیت از یک handle فهرست‌شده مسیر پیشوند را اثبات می‌کند؛ مکالمه‌ای که حافظه اصلی را به‌روز می‌کند حلقه را سرتاسر اثبات می‌کند. به آن ترتیب دیباگ کنید، چون هر مرحله مجموعه شکست متمایزی دارد: env var ها، نسخه سرور، و شایستگی ابزار مدل به‌ترتیب. وقتی agent ها اجرا شوند، کنسول APIsRouter مدل، شمارش token، و هزینه هر-درخواست را نشان می‌دهد. agent های stateful به ازای هر تعامل بیشتر از آنچه transcript آن‌ها نشان می‌دهد صورت‌حساب می‌شوند، چون مدیریت حافظه پشت هر پاسخ اجرا می‌شود، و usage log جایی است که آن ضریب پنهان به عددی تبدیل می‌شود که می‌توانید بودجه‌بندی کنید.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"What is 2+3?"}],
       "tools":[{"type":"function","function":{
         "name":"calc","description":"add numbers",
         "parameters":{"type":"object","properties":{
           "a":{"type":"number"},"b":{"type":"number"}}}}}]}'

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