سال 2026، سالی است که agent harnesses وارد production می‌شوند. نرم‌افزاری که کنترل دسترسی مدل به دنیای بیرون را بر عهده دارد — harnessesهایی مثل Codex، Claude Code، OpenCode، Pi و Project Think — آن‌قدر بالغ شده‌اند که تیم‌ها حالا agentها را به‌عنوان زیرساخت واقعی و باربر، نه فقط پروتوتایپ، مستقر می‌کنند 🚀.

اما ساختن agentهایی که در production زنده بمانند کار ساده‌ای نیست. این را خودمان هنگام ساخت Project Think به‌عنوان نخستین harness داخلی‌مان تجربه کردیم. در مسیر کمک به مشتریان برای اجرای agentها در production، با مجموعه‌ای از مشکلات رایج در سیستم‌های توزیع‌شده روبه‌رو شدیم که هر agent در فضای ابری با آن مواجه می‌شود.

وقتی یک agent قطع می‌شود، چطور باید بدون از دست رفتن context و هدررفت توکن‌ها به صورت خودکار و شیک از جای قبلی از سر بگیرد؟ چطور می‌توان کد غیرقابل‌اعتماد را امن اجرا کرد؟ چطور باید ابزارهایی که مدل برایشان آموزش دیده را قابل استفاده کرد؟ 🤔

یک harness به‌تنهایی نمی‌تواند همه این مسائل را حل کند؛ این مشکلات به state، storage و compute وابسته‌اند — یعنی وابسته به پلتفرمی که agent روی آن اجرا می‌شود. به همین دلیل آموخته‌هایمان از پایدارسازی Project Think را به‌عنوان یک لایه پایه در Cloudflare Agents SDK آوردیم. اجرای Durable، اجراهای پویا برای کد، یک فایل‌سیستم دوام‌پذیر و dynamic workflows حالا در دسترس هر harnessی است که روی Agents SDK بسازد.

هم‌زمان، لایه‌ای جدید بالای harness شکل گرفته است. فریم‌ورک‌هایی مثل Flue یک harness را با ساختار پروژه، قراردادها، ادغام‌ها و تجربه توسعه‌دهنده احاطه می‌کنند تا ساخت agentها محصولی و سریع‌تر شود 🧩.

برای حل چالش‌های مقیاس‌پذیری، یک استک سه‌لایه جدید در حال ظهور است که برای ساخت AI سطح production مناسب است. اجزا از تجربه توسعه‌دهنده تا پریمتیوهای پلتفرم به این شکل قرار می‌گیرند:

– Framework (مثل Flue): ساختار پروژه، قراردادها، ادغام‌ها، CLI و تجربه توسعه‌دهنده برای ساخت agent.
– Harness (مثل Pi، Project Think): حلقه agentic که ابزارها را صدا می‌زند، نتایج را می‌خواند، context را مدیریت می‌کند و تا تمام شدن کار ادامه می‌دهد.
– Runtime/platform (Cloudflare Agents SDK): محاسبه، state و پریمتیوهای ذخیره‌سازی که همه چیز روی آن تکیه دارد.

Agents SDK همان لایه پایین است: primitives مثل durable execution را برای هر harness و هر framework ممکن می‌کند. Flue، فریم‌ورک متن‌باز جدید از تیم پشت Astro، اولین کسی است که روی آن ساخته شده است. در ادامه می‌بینیم چطور.

Flue این هفته نسخه 1.0 Beta را منتشر کرد و روی harness Pi ساخته شده — همان harnessی که OpenClaw هم از آن استفاده می‌کند. وجه تمایز Flue این است که به‌جای اسکریپت‌نویسی رفتار agent، توصیف می‌کنید چه دانشی دارد: مدل، skills، sandbox و instructions را تعریف می‌کنید و agent به‌صورت autonomous هر کاری به آن بدهید حل می‌کند. لازم نیست حلقه orchestration بنویسید ✨.

این مدل declarative است که نوشتن agent را ساده می‌کند: مثلاً یک triage agent که گزارش باگ را می‌گیرد، آن را در sandbox بازتولید می‌کند و زیر 25 خط کد تشخیص می‌دهد چه مشکلی هست — بدون نوشتن حلقه orchestrator پیچیده.

تجربه توسعه‌دهنده در Flue از این قدرت می‌آید که agentها ایزوله نیستند؛ آنها طوری ساخته شده‌اند که در همان جاهایی که کاربران شما کار می‌کنند حضور داشته باشند و با ابزارهای دلخواه شما یکپارچه شوند.

Anywhere agents: agentها را می‌توانید در Slack، GitHub، Linear یا Discord قرار دهید با Channels از پیش‌پیکربندی‌شده که event verification و dispatch boilerplate را به‌صورت خودکار هندل می‌کنند.

Headless, but UI-ready: agentها نباید یک جعبه سیاه باشند. Flue می‌تواند agentها را کاملاً headless برای کارهای پس‌زمینه اجرا کند، اما @flue/react هوک‌های frontend فراهم می‌کند که state، اجرای ابزار و پیام‌های زنده agent را مستقیم به اپ شما stream می‌کند — بدون نیاز به ساخت plumbing real-time اختصاصی ⚡.

Ecosystem-ready: Flue اضافه کردن و به‌روزرسانی ادغام‌ها را ساده می‌کند؛ برای مثال با دستور flue add channel slack یک blueprint در Markdown تولید می‌شود که agent کدنویس شما می‌تواند آن را بخواند، ویرایش کند و به‌صورت تمیز در codebase شما ادغام کند.

طراحی شده برای production، نه فقط پروتوتایپ: انتقال یک agent از ترمینال محلی به اکوسیستم production، شکست‌های سنتی سیستم‌های توزیع‌شده را وارد می‌کند. کرش میزبان، timeouts از LLM providerها و راه‌اندازی‌های غیرمنتظره می‌توانند حافظه کوتاه‌مدت یک agent در حال اجرا را پاک کنند — و تجربه کاربری را خراب کنند.

Flue این مشکل را با Durable Streams حل می‌کند. هر event در تاریخچه اجرا به یک append-only log اضافه می‌شود. با پردازش هر prompt، پاسخ ابزار و انتخاب مدل به‌عنوان یک ledger غیرقابل‌تغییر، state agent دیگر volatile نیست. اگر یک process بمیرد، instance دیگری همان log را می‌گیرد و دقیقاً از همان مرحله ادامه می‌دهد ✅.

Deploy anywhere, including Cloudflare: Flue یک فریم‌ورک multi-cloud است. روی Node.js هر agent به‌صورت یک process بلندمدت اجرا می‌شود. می‌توانید آن را روی هر VM یا container مستقر کنید، در GitHub Actions اجرا کنید یا در یک سرور موجود embed کنید. اما وقتی هدف Cloudflare باشد، هر agent تبدیل به یک Durable Object می‌شود.

با اجرای هر Flue agent داخل Durable Object مخصوص خودش، Cloudflare می‌تواند به‌صورت خودکار به هر تعداد agent که نیاز دارید مقیاس دهد، هر کدام با storage و compute ایزوله. نیازی به provision کردن سرورها، مدیریت sticky sessions یا نگرانی درباره noisy neighbors نیست. وقتی Flue روی Cloudflare مستقر می‌شود، از durable execution با متدهای Agents SDK مثل runFiber(), stash() و onFiberRecovered() بهره‌مند می‌شود. Flue همچنین از @cloudflare/codemode و @cloudflare/shell برای اجرای کد sandboxed روی یک durable workspace استفاده می‌کند 🔒.

آنچه harnessها از یک پلتفرم agentic نیاز دارند: هدف Cloudflare برای Flue آن‌قدر موثر است که به‌خوبی با پریمتیوهای اصلی Agents SDK منطبق می‌شود. حتی می‌توانید کد منبع Flue را بررسی کنید تا ببینید چگونه Pi، harness زیرین، برای کار روی Cloudflare Agents SDK تطبیق داده شده است.

در ادامه می‌بینیم Flue چگونه زیرِ کاپوت از Agents SDK استفاده می‌کند و چه چیزی لازم است تا هر harness مدرن reliably در مقیاس اجرا شود.

هر harness agent به durable execution نیاز دارد. یک turn در agent یک درخواست ساده نیست: مدل توکن‌ها را stream می‌کند، ابزارها را صدا می‌زند، منتظر نتایج می‌ماند، شاید از انسان تأیید بگیرد یا کار را به subagent واگذار کند. این توالی ممکن است ثانیه‌ها یا دقیقه‌ها طول بکشد و در هر لحظه ممکن است process قطع یا کرش شود. در آن شرایط همه state که در حافظه بود از بین می‌رود: اتصال streaming، pending tool calls و محل پیشرفت turn. بله، تاریخچه گفتگو ممکن است روی دیسک ذخیره شده باشد، اما کاربر یک spinner می‌بیند که هرگز تمام نمی‌شود — تجربه‌ای خراب.

Fibers این مشکل را با فراهم کردن یک مکانیزم native برای checkpointing درست داخل Durable Object حل می‌کنند. runFiber() پیشرفت را در SQLite داخلی Durable Object قبل از شروع کار در Agent turn ثبت می‌کند و با stash() در طول پیشرفت turn چک‌پوینت می‌گیرد. وقتی یک instance جدید بعد از قطع بالا می‌آید، onFiberRecovered() آخرین چک‌پوینت را تحویل می‌دهد تا agent بداند یک turn قطع شده، تا کجا رسیده و تصمیم بگیرد چطور ادامه دهد.

import { Agent } from "agents"; import type { FiberRecoveryContext } from "agents"; class MyAgent extends Agent { async doWork() { await this.runFiber("my-task", async (ctx) => { const step1 = await expensiveOperation(); ctx.stash({ step1 }); const step2 = await anotherExpensiveOperation(step1); this.setState({ ...this.state, result: step2 }); }); } async onFiberRecovered(ctx: FiberRecoveryContext) { if (ctx.name !== "my-task") return; const { step1 } = (ctx.snapshot ?? {}) as { step1?: unknown }; if (step1) { const step2 = await anotherExpensiveOperation(step1); this.setState({ ...this.state, result: step2 }); } } }

Flue روی target Cloudflare خود از runFiber() استفاده می‌کند. با hook مثل onFiberRecovered()، harness شما اختیار دارد که چطور اجرای یک turn را از سر بگیرد: آیا از یک مدل بازسازی کامل شبیه Project Think استفاده کند تا state را تعمیر کند یا فقط بخش‌هایی از turn را replay کند — انتخاب با شماست.

اجرای کد بهتر از پر کردن agentها با ابزارهای متعدد است. harnessها معمولاً به مدل‌ها ابزارهایی می‌دهند تا به دنیای بیرون دسترسی پیدا کنند، اما هرچه surface ابزارها بزرگ‌تر شود، مدل در انتخاب ابزار مناسب بدتر عمل می‌کند چون context window با تعریف ابزارها پر می‌شود. الگوی بهتر این است که به مدل یک ابزار واحد بدهید که کد اجرا می‌کند: مدل یک تابع TypeScript می‌نویسد که APIهای لازم را صدا می‌زند و harness آن را اجرا می‌کند. این همان فلسفه‌ای است که در معرفی Code Mode توضیح دادیم.

سؤال این است که آن کد کجا اجرا شود. برای اجرای کد تولیدشده توسط LLM به‌صورت امن به یک sandbox نیاز دارید. اما sandboxهای معمولی کند، پرهزینه و ناکارآمد خواهند بود اگر برای هر فراخوانی ابزار یک کانتینر بزنید. به همین دلیل Agents SDK، @cloudflare/codemode را فراهم می‌کند که Dynamic Workers را برای اجرای کد LLM-generated در یک Worker isolate با فقط bindingهایی که می‌دهید بسته‌بندی می‌کند.

Code Mode برای هر snippet یک Dynamic Worker تازه می‌سازد، آن را اجرا می‌کند و بعد دور می‌اندازد. Isolateها زیر 10ms استارت می‌زنند و حدود $0.002 به ازای هر لود هزینه دارند، که بسیار سریع‌تر و ارزان‌تر از بالا آوردن یک کانتینر کامل برای اجرای قطعه‌ای کوتاه کد است. Flue روی target Cloudflare خود از @cloudflare/codemode برای ابزار code استفاده می‌کند: agent جاوااسکریپت را علیه workspace می‌نویسد و با Code Mode اجرا می‌کند.

برای اکثر کارهای workspace شما نیازی به یک کانتینر کامل ندارید. harnessها اغلب به یک filesystem نیاز دارند تا فایل‌ها را بخوانند، خروجی بنویسند، بین کد جستجو کنند و diffs را تحلیل کنند — به‌ویژه coding agents که در فایل‌سیستم زندگی می‌کنند. اما اگر harness در یک environment serverless اجرا شود، چطور فایل‌سیستمی durable و پایدار بین اجراها داشته باشیم؟ پاسخ معمول کانتینر است که کار می‌کند اما هزینه‌بر است برای کاری که اغلب فقط عملیات متنی است.

@cloudflare/shell به agent شما یک virtual durable filesystem داخل Durable Object می‌دهد که توسط SQLite پشتیبانی می‌شود. این ابزار عملیات تایپ‌شده فایل — read، write، edit، search، grep، diff — را فراهم می‌کند تا harnessها بتوانند با کارایی بالا و هزینه کمتر نسبت به کانتینر کامل، روی محتوای متنی و کد کار کنند 🗄️.

خلاصه برای مخاطب DevOps/SRE: اگر می‌خواهید agentها را به‌صورت production-grade مستقر کنید، به سه لایه فکر کنید: یک framework برای DX و یک harness برای منطق agentic، و در پایین یک runtime که primitives مثل durable execution، sandboxed dynamic code execution، و durable virtual filesystem را فراهم کند. ترکیب Agents SDK با فریم‌ورک‌هایی مثل Flue نشان می‌دهد این معماری چطور عملی و قابل‌مقیاس‌پذیر است — و ابزارهایی مثل runFiber(), @cloudflare/codemode و @cloudflare/shell در عمل مشکلات کلاسیک distributed systems و serverless را حل می‌کنند 🔧.