‏Framer Agent حالا کل کار رو با یه برنامه JavaScript انجام می‌ده

تیم Framer تو این پست توضیح می‌ده که harness ایجنتش (یعنی لایه‌ای که خروجی مدل رو می‌گیره و روی سند اعمال می‌کنه) رو از اول ساخته. حالا ایجنت می‌تونه یه درخواست مثل «هرجا رنگ قدیمی برندمون هست رو عوض کن» رو با یه برنامه JavaScript انجام بده: سند رو بگرده، تصمیم بگیره کدوم nodeها باید عوض بشن و تغییرها رو اعمال کنه، بدون اینکه برای هر تصمیم برگرده سراغ مدل. طبق گفته تیم، این کار تا ۳۳ درصد هزینه رو کم کرده و ۲۰ درصد سریع‌ترش کرده.

Framer سندهای طراحی رو به شکل یه درخت نگه می‌داره که مثل یه AST عمل می‌کنه و کد و محتوای CMS ازش ساخته می‌شه. نسخه اول هارنس از یه DSL (یعنی یه زبان کوچیک مخصوص همین کار) استفاده می‌کرد که مدل باهاش دستور ساخت node و تنظیم property می‌فرستاد. مشکل اینجا بود که عوض کردن یه property روی ۱۰۰ فریم، ۱۰۰ تا دستور لازم داشت. خوندن یه مقدار و استفاده‌ش تو یه نوشتن هم چند تا فراخوانی جدا از مدل می‌خواست. یعنی حتی وقتی مدل کل مسیر رو از قبل می‌دونست، هارنس مجبورش می‌کرد قدم‌به‌قدم جلو بره.

برنامه‌های بلندتر دو تا دردسر دارن: کاربر باید صبر کنه تا کل کد نوشته بشه، و اگه برنامه تو خطهای اول متوقف بشه، توکن‌های بقیه‌ش هدر رفته. راه‌حل Framer اجرای eager هست: کدی که داره استریم می‌شه پارس می‌شه، دستورهای کامل JavaScript تو «cell»هایی گروه می‌شن و به یه Web Worker جدا فرستاده می‌شن. cellها به ترتیب و به شکل classic script اجرا می‌شن و متغیرها بینشون حفظ می‌شه. await سطح بالا هم به سینتکسی ترجمه می‌شه که classic script بفهمه.

const node = tree.get("button");
tree.patch(node, { fill: "#09f" });

تو مثال خود مقاله، cell اول node دکمه رو پیدا می‌کنه و cell دوم رنگش رو عوض می‌کنه. این تغییر روی بوم دیده می‌شه، در حالی که مدل هنوز داره cell سوم رو می‌نویسه. همین مرحله پارس کردن، کامنت‌هایی مثل // @step Building buttons رو به emit("Building buttons") تبدیل می‌کنه تا کاربر وسط کارهای طولانی هم گزارش پیشرفت ببینه.

قسمت دوم ماجرا cancellation هست. به ایجنت گفتن شرط‌های لازم رو قبل از کارهای وابسته چک کنه. اگه یه خطای جدی یا یه return زودهنگام پیش بیاد (مثلاً دکمه اصلاً وجود نداشته باشه)، بقیه تولید کد همون لحظه قطع می‌شه و دیگه پول توکن خروجی اضافه داده نمی‌شه. تغییرهایی که تا اون موقع اعمال شدن سر جاشون می‌مونن، و پیام خطا طوری طراحی شده که بگه چی خراب شد و ایجنت دفعه بعد چطور درستش کنه.

نکات کلیدی:

• معماری جدید به‌طور میانگین ۲ برابر قدم ابزار کمتر و ۳۹ درصد توکن ورودی کش‌شده کمتر برای هر پیام مصرف می‌کنه.
• هزینه تا ۳۳ درصد کمتر و سرعت ۲۰ درصد بیشتر شده، بدون افت کیفیتی که اندازه‌گیری شده باشه.
• کد در حال استریم به cell تبدیل می‌شه و تو یه Web Worker جدا به ترتیب اجرا می‌شه.
• کامنت // @step به emit() تبدیل می‌شه تا پیشرفت کار به کاربر نشون داده بشه.
• خطای جدی یا return زودهنگام، بقیه تولید کد رو قطع می‌کنه ولی تغییرهای انجام‌شده حفظ می‌شن.