چگونه «تراشیدن بافت» حافظه، نویز عامل‌های هوش مصنوعی را پاکسازی می‌کند؟

اگر امروز در حال توسعه‌ی عامل‌های هوش مصنوعی هستید، احتمالاً با پنجره متنی (Context Window) به عنوان یک دفترچه خاطرات غیرقابل تغییر برخورد می‌کنید که پیام‌ها صرفاً تا رسیدن به سقف محدودیت، به انتهای آن اضافه می‌شوند. اما رویکرد تئوری ادراک (Perception Theory) پیشنهاد می‌کند این پنجره را به جای یک گزارش خطی، به عنوان یک فضای طراحی قابل تغییر (Mutable Design Space) ببینیم که مدل می‌تواند فعالانه آن را بازنویسی کند.

این مفهوم که «تراش‌کاری متنی» (Context Sculpting) نامیده شده، مدل استاندارد «پرامپت سیستم + تاریخچه» را کنار می‌گذارد. در این حالت، حافظه‌ی عامل به جای یک گفتگو خطی، به یک سطح کنترلی تبدیل می‌شود که می‌توان در لحظه آن را هرس کرد، فشرده کرد یا مسیر آن را تغییر داد. این ایده از مطالعه‌ی مقاله‌ی «کالبدشناسی یک هارنس عامل» توسط ویو (Viv) شکل گرفت. ویو در این نوشتار مروری بر مفهوم هارنس (Harness) داشت که طی سال گذشته توسعه یافته است. او اشاره کرد که از زمان عرضه ChatGPT، مدل ذهنی ما از یک پرامپت سیستم، یک پیام کاربر و لیستی همواره در حال رشد از پیام‌ها و فراخوانی ابزارها، به‌شدت در ذهن ما تثبیت شده است.

چشم‌انداز تغییرپذیری

شهود اصلی در پشت تراش‌کاری متنی، حذف فرض «فقط-اضافه-شونده» (append-only log) است. نویسنده این سوال را مطرح کرد که آیا یک مدل می‌تواند تشخیص دهد چه زمانی در حال چرخه زدن است، کجا گیر کرده یا در مسیر اشتباهی پیش می‌رود؟ اگر پنجره متنی تغییرپذیر باشد، مدل می‌تواند بخش‌های ابتدایی تاریخچه را «خود-فشرده» (Auto-compact) کند تا از پر شدن زودرس پنجره متنی جلوگیری کرده یا آن را به تأخیر بیندازد.

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

در ۵ ژوئن ۲۰۲۶، مجموعه‌ای از آزمایش‌های «تحقیق بر اساس حس» (Vibe Research) نشان داد که دادن اختیار به یک مدل بزرگ‌تر برای مدیریت پنجره متنی یک مدل کوچک‌تر، می‌تواند یا یک تسک را به‌شدت بهینه کند یا به یک فاجعه‌ی مهندسی گران‌قیمت منجر شود. این رویکرد مشابه «استراتژی مشاور» است که پیش‌تر توسط آنتروپیک (Anthropic) مطرح شد؛ جایی که یک مدل با هوش بالا (مانند Opus) به عنوان مشاور در کنار یک مدل مجری بهینه‌تر (مانند Sonnet یا Haiku) قرار می‌گیرد تا به سطح هوش تراز اول با کسری از هزینه دست یابد. پژوهشگر همچنین اشاره کرد که این مفهوم تحت تأثیر ایده‌های مربوط به مدل‌های زبانی بازگشتی (RLMs) بوده است.

معماری یک هارنس تراش‌کاری

طبق گزارش منتشر شده در perceptiontheory.bearblog.dev، این سیستم از یک حلقه‌ی دو لایه بر بستر چارچوب Pi agent harness استفاده می‌کند. مدل Pi به دلیل رویکرد مینیمالیستی، قابلیت گسترش بالا و فراهم کردن تمام قلاب‌های (Hooks) لازم برای پیاده‌سازی یک پنجره متنی تغییرپذیر انتخاب شد. پژوهشگر برای توسعه‌ی نقشه با Claude همکاری کرد و سپس برای پیاده‌سازی و اجرای آزمایش‌ها از Codex استفاده نمود. Codex حتی پیش‌نویس پست وبلاگی را هم تهیه کرد، هرچند نویسنده برای روایت نهایی از کلمات خودش استفاده کرد.

معماری شامل یک «عامل داخلی» (Inner Agent) است که تسک را انجام می‌دهد و یک «عامل خارجی» (Outer Agent) که نقش تراش‌کار را دارد. عامل داخلی به‌طور صریح نمی‌داند که تراش‌کاری در حال رخ دادن است. اما عامل خارجی کل متن داخلی را می‌بیند و در هر نوبت فرصت مداخله دارد.

بعد از هر نوبت که عامل داخلی می‌گیرد، عامل خارجی کل متن را بازرسی کرده و یکی از چهار اقدام زیر را انتخاب می‌کند:

• عبور (pass_through): عامل خارجی هیچ کاری نمی‌کند و اجازه می‌دهد عامل داخلی ادامه دهد.
• بازنویسی متنی (rewrite_context): عامل خارجی متن داخلی را با یک نسخه اصلاح‌شده و تراش‌خورده جایگزین می‌کند. ابزار اصلی مداخله، بازنویسی کامل متن است، نه وصله‌های کوچک و جزئی.
• بازگشت (rollback): سیستم متن را به یک نقطه‌ی بازگشت (checkpoint) قبلی برمی‌گرداند.
• پایان (terminate): عامل خارجی تصمیم می‌گیرد تسک کامل شده و اجرا را متوقف می‌کند.

در سطح کلی، منطق سیستم از این حلقه پیروی می‌کند: while run_is_active: inner_agent.take_one_turn() -> outer_agent.observe(full_inner_context) -> decision = outer_agent.decide(). اگر بازنویسی انتخاب شود، متن داخلی جایگزین می‌گردد و اگر بازگشت انتخاب شود، یک چک‌پوینت قدیمی بازیابی می‌شود.

دمو ۱: ناظر محافظه‌کار

اولین سری آزمایش‌ها به عنوان یک مطالعه‌ی موردی مهندسی طراحی شد، نه یک مقاله پژوهشی سخت‌گیرانه. نویسنده اعتراف کرد که در ابتدا «توهمات بزرگی» درباره نوشتن یک مقاله داشت، اما برای پاسخ به یک سوال کلیدی به «تحقیق بر اساس حس» روی آورد: چه اتفاقی می‌افتد اگر به یک مدل اجازه دهید متن کاری مدل دیگری را بین هر نوبت بازنویسی کند؟

در این تنظیمات، از gpt-5.4-mini به عنوان عامل داخلی و gpt-5.4 به عنوان عامل خارجی استفاده شد. دو تسک خاص برای تایید نتایج به کار گرفته شد:

• تسک اصلاح کد (Coding Repair): عامل باید یک ابزار مدیریت تسک ساده (CLI) مبتنی بر فایل را اصلاح می‌کرد تا دستور node verify.mjs با موفقیت اجرا شود. در فضای کاری، یک یادداشت قدیمی و منسوخ به عنوان عامل گمراه‌کننده (Distractor) قرار داده شده بود. برای موفقیت، هر ۵ تست باید پاس می‌شدند.
• تسک سنتز پیکره محلی (Local-Corpus Synthesis): عامل باید به سوالی تنها با استفاده از یک پیکره کوچک در پوشه docs/ پاسخ می‌داد و نتیجه را در ساختاری ثابت در فایل answer/final_answer.md می‌نوشت. این پیکره شامل اسناد گمراه‌کننده بود و تاییدیه بر اساس شکل فایل خروجی و زنجیره شواهد بررسی می‌شد.

برای ایجاد یک خط مبنا (Baseline)، پژوهشگر دو اجرای «فقط داخلی» و دو اجرای «با هارنس خارجی» برای هر تسک انجام داد (در مجموع ۸ اجرا). محدودیت‌هایی (Guardrails) برای تعداد نوبت‌های حداکثری عامل داخلی و حداکثر هزینه تخمینی API تعریف شد.

از نظر فنی، هارنس عالی عمل کرد: ۸ مورد از ۸ اجرا با موفقیت به پایان رسید و ۸ مرحله تاییدیه پاس شدند. هیچ‌کدام از محدودیت‌ها فعال نشدند. با این حال، نتایج یک شکاف بهره‌وری بزرگ را نشان داد. هزینه اجرای کامل هارنس ۰.۷۰۷۹ دلار بود که ۱۴ برابر بیشتر از خط مبنای عامل داخلی بود، در حالی که عامل خارجی حتی یک بار هم بازنویسی یا بازگشت انجام نداد.

در ۴ اجرای تحت هارنس، ۱۶ فراخوانی عامل خارجی رخ داد: ۱۲ مورد pass_through و ۴ مورد terminate بود. در این مرحله، عامل خارجی مانند یک «ناظر محافظه‌کار» عمل کرد. او پیشرفت را مشاهده می‌کرد و گاهی قصد گام بعدی را در فایل strategy_notes.txt صیقل می‌داد، اما هرگز مسیر عامل داخلی را آن‌قدر اشتباه ندید که هزینه یک بازنویسی را توجیه کند.

دمو ۲: تغییر به سمت مداخله هدفمند

برای تست اینکه آیا تراش‌کاری فعال واقعاً ممکن است، پژوهشگر تصمیم گرفت با تغییر پرامپت عامل خارجی، «به دنبال نتیجه بدود». پرامپت اولیه بیش از حد محافظه‌کار بود و مدام به pass_through ختم می‌شد. یک پروفایل جدید به نام «مداخله هدفمند» (intervention_targeted) ایجاد شد که صراحتاً به مدل خارجی دستور می‌داد از حالت پیش‌فرض pass_through فاصله بگیرد، هرگاه یک بازنویسی قابل دفاع بتواند:

• متن گمراه‌کننده را حذف کند.
• لاگ‌های اکتشافی سنگین (Tool-heavy) را فشرده کند.
• توضیحات دقیق را تزریق کند.
• تعداد نوبت‌های تلف شده را کاهش دهد.

برای به چالش کشیدن بیشتر سیستم و مجبور کردن عامل خارجی به اقدام، تسک‌ها نویزی‌تر شدند. تسک کدنویسی با اسناد متناقض و یادداشت‌های مهاجرت قدیمی شلوغ شد و در تسک سنتز، چندین زنجیره محتمل اما غلط و عوامل گمراه‌کننده صریح قرار داده شد. علاوه بر این، عامل داخلی (gpt-5.4-mini) با قرار دادن سطح تفکر (Thinking Level) روی «پایین»، تضعیف شد.

اجرای قهرمان: موفقیت در سنتز

در تسک نویزی سنتز، عامل خارجی پتانسیل واقعی تراش‌کاری را به نمایش گذاشت. این مورد «اجرای قهرمان» (Hero Run) نامیده شد زیرا مفهوم اصلی را به تصویر کشید: برخورد با متن گفتگو به عنوان یک سطح کنترلی تغییرپذیر. تسک نیاز داشت پاسخی از یک پیکره محلی ثابت استخراج شود، در حالی که چندین سند، زنجیره‌هایی محتمل اما غلط می‌ساختند.

اجرای تحت هارنس سه اقدام حیاتی انجام داد:

۱. تزریق بازنویسی (Inject Rewrite): در ابتدای مسیر، مدل خارجی متن را ساده کرد و یادداشتی متمرکز اضافه کرد که کدام مسیرهای تحقیق احتمالاً گمراه‌کننده هستند.
۲. بازنویسی فشرده (Compact Rewrite): پس از خواندن اسناد مرتبط، مدل خارجی تاریخچه نویزی و سنگینِ خواندن‌ها را با یک خلاصه موجز از زنجیره شواهد واقعی و فایل‌های دقیق برای ارجاع جایگزین کرد.
۳. اجرای مستقیم: چون متن اکنون تراش‌خورده و پاکیزه بود، مدل داخلی در نوبت بعدی پاسخ را نوشت و مدل خارجی بلافاصله دستور پایان را صادر کرد.

این توالی ثابت کرد که مدل خارجی می‌تواند متن داخلی را بازسازی کند تا شلوغی کاهش یابد و نوبت بعدی ساده‌تر و مستقیم‌تر شود. مجموعه مداخله هدفمند شامل ۴ اجرا بود و حدود ۱.۲۶ دلار هزینه داشت. در ۲ اجرای تحت هارنس این مجموعه، ۱۵ فراخوانی خارجی رخ داد: ۱۴ مورد rewrite_context و ۱ مورد terminate.

اجرای شکست‌خورده: فاجعه بیش‌کنترلی

در مقابل، تسک اصلاح کد به یک «فاجعه بیش‌کنترلی» (Oversteering Disaster) تبدیل شد. اگرچه کد در نهایت تایید شد، اما فرآیند به‌شدت ناکارآمد و خطرناک بود. Codex این مورد را مثالی عالی از اینکه چرا این ایده همزمان جذاب و خطرناک است، توصیف کرد.

مقایسه اجرای کنترلی (بدون هارنس) با اجرای تحت هارنس، تضاد شدیدی را نشان می‌دهد:

• اجرای کنترلی: تسک را در ۷ نوبت حل کرد، حدود ۴۲.۷ ثانیه زمان برد و هزینه آن ۰.۰۱۵ دلار بود.
• اجرای تحت هارنس: ۱۲ نوبت زمان برد، ۵۶۶.۹ ثانیه طول کشید و ۱.۰۶ دلار هزینه داشت.

در اجرای تحت هارنس، عامل خارجی ۱۲ فراخوانی و ۱۲ تصمیم بازنویسی داشت. او مکرراً از «تزریق بازنویسی» برای اصلاح سردرگمی در مسیر و از «بازنویسی فشرده» برای جمع کردن متن سنگین استفاده کرد. سپس بازنویسی‌های بیشتری تزریق کرد تا عامل را به سمت تاییدیه هل دهد.

از یک منظر، این یک موفقیت بود چون هارنس واقعاً مسیر را تغییر داد و مدل خارجی قدرت کنترل واقعی اعمال کرد. اما از منظری دیگر، یک فاجعه بود: اجرا ۷۰ برابر گران‌تر از خط مبنا بود، دچار تأخیر (Latency) شدید شد و نتوانست دستور terminate را به‌موقع صادر کند. اجرا تنها زمانی پایان یافت که محدودیت maxInnerTurns فعال شد، حتی با وجود اینکه کد قبلاً اصلاح شده بود.

درس اصلی: پرامپت به مثابه سیاست

این نتایج نشان می‌دهد که توانایی بازنویسی متن، کمتر از «سیاست» (Policy) حاکم بر زمان انجام آن اهمیت دارد. پژوهشگر نتیجه گرفت که سوال جذاب دیگر این نیست که «آیا یک عامل خارجی می‌تواند مداخله کند؟» (پاسخ بله است)، بلکه این است که «چه سیاست مداخله‌ای باعث می‌شود بازنویسی بیشتر از آنکه مضر باشد، مفید باشد؟»

تغییر از یک «ناظر مودب» به یک «ویراستار فعال» تنها با یک تغییر در پرامپت رخ داد. این یعنی برای توسعه‌کنندگان عامل، لایه کنترلی فقط زیرساخت نیست، بلکه همان «رفتار» است. پرامپت، سطح واقعی سیاستی است که تعیین می‌کند سیستم بهینه باشد یا تلف‌کننده منابع.

همان‌طور که Codex اشاره کرد، بخش جالب فنی بودنِ توانایی بازنویسی نیست، بلکه این است که اجازه دادن به آن، یک «مسئله کنترلی» جدید ایجاد می‌کند. برای علاقه‌مندان به پیاده‌سازی، کد کامل، گزارش‌های دمو و نقشه پژوهشی اصلی در مخزن گیت‌هاب پروژه در https://github.com/perceptiontheory/context-sculpting در دسترس است. مستندات خاص شامل blog_post_draft.md ،demo_report.md و research_plan.md هستند.

یکی از تکان‌دهنده‌ترین دستاوردهای نقشه پژوهشی، این بینش کلیدی است: پنجره متنی عامل داخلی یک گزارش (Log) نیست، بلکه یک فضای طراحی است که عامل خارجی فعالانه آن را تراش می‌دهد.

همان‌طور که هوش مصنوعی از پارادایم «چت» به پارادایم «عامل» حرکت می‌کند، احتمالاً شاهد بازنگری بنیادی در گزارش‌های فقط-اضافه-شونده خواهیم بود. چالش همچنان باقی است: یافتن سیاست مداخله‌ای که بازنویسی را مفیدتر از مضر کند. اگر در حال طراحی حلقه‌های عامل هستید، باید ارزیابی کنید که آیا مدل شما به یک تاریخچه استاتیک نیاز دارد یا به یک حافظه پویا که توسط یک ناظر هرس شود.