یک سند، دو دست: عامل باید کنارت بشینه، نه جلوت
فرانتاند
هوش مصنوعیخلاصهٔ کاملتر
این پست نسخهٔ نوشتاری سخنرانی نویسنده تو Local-First Confـه و حول یه اپ موسیقی کوچیک به اسم Pizzo میچرخه. Pizzo همون چیزهایی رو داره که از یه اپ موسیقی انتظار داری — پیشروی آکورد، کنترل تمپو، درام، بیس، سینث و کلی دکمه و اسلایدر. ولی یه عامل هم داره: میتونی بگی «این رو تو ر مینور رؤیاییتر کن» و آکوردها عوض میشن، یا بخوای یه خط بیس متحرک اضافه کنه.
نکتهای که نویسنده روش دست میذاره اینه که عامل یه اپ موسیقی جدید تولید نمیکنه و کد نمیده که دانلود کنی؛ دستش رو میبره تو همون آهنگی که الان باز داری و عوضش میکنه. بعد تو میتونی با دست خودت دوباره تغییرش بدی. یک سند، دو دست.
او میپرسه چرا عاملهای کدنویس زودتر از همه به اینجا رسیدن، و جوابش اینه که مدل تنها کار نمیکنه. عاملهای کد معمولاً یه فضای کاری دارن، جایی برای اجرا و دیدن نتیجه، ابزارهایی برای خوندن و نوشتن و فراخوانی، و یه کامپیوتر با دسترسی به دادهٔ کاربر. کد هم بهطور غیرعادی مناسبه چون «متن اجراشدنی»ه و حلقهٔ بازخورد خودش با خود رسانه میاد. به تعبیر نویسنده، ما فقط کد رو به مدل ندادیم — کل کارگاه رو دادیم. بیرون از برنامهنویسی اما داستان خیلی نازکتره: بیشتر محصولات یه جعبهٔ چت جلوی اپ موجود میذارن.
بخش مرکزی استدلال همینه. راه بدیهی افزودن عامل اینه که چت بشه دروازه: تو، بعد جعبهٔ چت، بعد عامل، بعد اپلیکیشن، بعد چیزی که مال توئه. اونوقت برای دستزدن به کار خودت، اول باید خودت رو برای یه فیلد ورودی توضیح بدی. نویسنده نه اینو میخواد نه حالت پنهانِ پشتصحنه رو؛ عامل رو کنار خودش میخواد. تو Pizzo هر دوشون میتونن دست ببرن تو خمیر اپلیکیشن: عامل با قصد و ابزار، آدم با انگشت و ماوس و کیبورد یا کنترلر MIDI.
به همین دلیل به این ایده که چت جانشین رابط گرافیکیه بدبینه. دستکاری مستقیم خوبه چون یه سلول صفحهگسترده یا اسلایدر یه بداهت فضایی داره که زبان نداره. به گفتهٔ او چت وقتی مفیده که نتیجه رو میدونی ولی حرکت دقیق رو نه؛ دستکاری مستقیم وقتی مفیده که حرکت رو میدونی.
خطای رایج دیگه اینه که مکالمه ناخواسته به منبع حقیقت تبدیل بشه و وضعیت روی یه رونوشت گفتوگو پخش بشه. Pizzo آهنگ رو بهعنوان وضعیت معمولی اپلیکیشن نگه میداره؛ چت فقط یکی از سطحهای ورودی روی آهنگه، نه ظرفی که آهنگ توش زندگی میکنه. نکتهٔ مهندسی جالب اینه که مدل مخفیانه تئوری موسیقی حل نمیکنه. وقتی میخوای آهنگ رو ترانسپوز کنه، یه تابع قطعی این کارو انجام میده و مدل عمدتاً قصد مبهم رو به یه عملیات و آرگومانهاش تبدیل میکنه:
const operations = {
transpose(semitones: number) {
song.update((draft) => {
draft.chords = transposeChords(draft.chords, semitones);
draft.bass = transposeNotes(draft.bass, semitones);
});
},
};دکمه transpose(2) رو صدا میزنه و عامل هم transpose(2) رو صدا میزنه؛ نسخهٔ عادی و نسخهٔ هوش مصنوعی جدا وجود نداره. همین بخش مهم اپ رو کسلکننده و قابل تست نگه میداره: آرگومانها اعتبارسنجی میشن، دسترسیها اعمال میشن و تغییرها ثبت و قابل واگرد میمونن.
نویسنده در پایان همین ایده رو به زیرساخت وصل میکنه: وقتی مخاطب از چند ده میلیون توسعهدهنده به صدها میلیون آدم عادی میرسه، دادن یه سرور همیشهروشن به هر کدوم اسرافکاریه — و برای همین Project Think رو بهشکل بدونسرور میسازه. جملهای که کل بحث رو خلاصه میکنه اینه: «هارنس همون اپه» — اپ از قبل سند، کنترلها، منطق قطعی، تاریخچه و همگامسازی رو داره، و اینا دقیقاً همون چیزهاییان که یه عامل دور خودش لازم داره.
نکات کلیدی:
- عامل باید کنار کاربر بشینه، نه بین کاربر و اپلیکیشن
- سند باید صاحب خودش باشه؛ مکالمه نباید به منبع حقیقت تبدیل بشه
- دکمه و عامل باید یه عملیات یکسان رو صدا بزنن، نه دو پیادهسازی جدا
- بخشهای دقیق کار رو کد قطعی انجام بده؛ مدل فقط قصد رو به عملیات ترجمه کنه
- همون معماری عاملهای کد رو میشه دور آهنگ، صفحهگسترده، بوم یا نقشه بست
