پنجره لغزنده و موج خنک: وقتی زمینه Agent میپیچد و باید بایگانی شود بدون از دست دادن
منتشر شده در 26 April 2026
خلاصه
پس از ۴۸ جلسه در یک پروژه واحد و مجموعاً بیش از ۱۵۰، سیستم مدیریت Eager/Lazy که با دقت ساخته بودم، شروع به تنگشده شدن کرد. فایلهای عامل که باید سبک باشند، مجموعاً ۵۲۰۰ خط وزن داشتند. بارگذاری خودکار context به سرعت بیشتری نسبت به توانایی من برای کنترل آن افزایش مییافت. این مقاله میگوید که چگونه من مکانیزم بکاپی — بین پنجره اسلایding و موج خنک یکسان — را طراحی کردم تا بتوانم یکcontext فعال سبک را حفظ کنم بدون اینکه هرگز چیزی را از دست دهم.
سیگنال: 5200 خطوط
من در میانه جلسه ۰۴۸ هستم بر`magic-stick`، پروژهی من برای ساخت ISO زنده لینوکس. Opencode به من نگاه میکند. همانطور که همیشه، بهطور خودکار فایلهای Eager من را در ابتدای جلسه بارگذاری کرده —AGENT.adoc, PROMPT_REPRISE.adoc, .agents/INDEX.adoc. هیچ چیز غیرعادی نیست.
اما چیزی مشکل دارد. پاسخها کندتر شدهاند. استدلال سطحیتر شده است. عامل جزئیاتی را که دو پیام پیش پیشروی او بود، فراموش میکند.
من یک ترمینال باز میکنم و تایپ میکنم:
wc -l .agents/INDEX.adoc .agents/SESSIONS_HISTORY.adoc \
.agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
260 خط برای INDEX. 55 برای SESSIONS_HISTORY.1756 برای COMPLETED_TASKS_ARCHIVE.
پرونده`sessions/`حدود 3200 خط دیگر اضافه میشود. مجموع:۵۲۰۰ خطمحتوایی که بارگذاری میشوند، به یک صورت یا دیگری، در مغز موقت عامل.
استراتژی Eager/Lazy که در مقاله قبلی نظریهام کردم کار میکند — اما یک عیب خلقی دارد که من پیشبینی نکردم : آن نداردبدون مکانیزم پیرایی. هر جلسه یک خط به INDEX، یک پاراگراف به COMPLETED_TASKS و یک فایل در sessions/ اضافه میکند. هیچ چیز هرگز خارج نمیشود. محتوا یک توپ برف است که در هر جلسه جدید بزرگتر میشود.
@startuml skinparam backgroundColor #FEFEFE skinparam handwritten false title رشد Contexte Agent — جلسات ۱ تا ۴۸ rectangle "جلسه 1-10" as S10 #E8F5E9 rectangle "جلسه 11-20" as S20 #C8E6C9 rectangle "جلسه 21-30" as S30 #A5D6A7 rectangle "جلسه 31-40" as S40 #81C784 rectangle "سشن 41-48" as S48 #66BB6A note right of S10 INDEX : ~50 lignes SESSIONS : ~10 lignes ARCHIVE : ~100 lignes **Total : ~300 lignes** end note note right of S20 INDEX : ~100 lignes SESSIONS : ~20 lignes ARCHIVE : ~400 lignes **Total : ~800 lignes** end note note right of S30 INDEX : ~160 lignes SESSIONS : ~30 lignes ARCHIVE : ~900 lignes **Total : ~1800 lignes** end note note right of S40 INDEX : ~220 lignes SESSIONS : ~45 lignes ARCHIVE : ~1400 lignes **Total : ~3200 lignes** end note note right of S48 INDEX : **260 lignes** SESSIONS : **55 lignes** ARCHIVE : **1756 lignes** **Total : 5200 lignes** ⚠️ end note S10 -[#green]-> S20 S20 -[#green]-> S30 S30 -[#FF9800]-> S40 S40 -[#red]-> S48 @enduml
این یک باگ نیست، بلکه نتیجه مستقیم از روی کار پایان جلسه است که هر جزئی را بهدقت بایگانی میکند. سیستم قربانی موفقیت خود شده است.
تشخیص: سهگانه redundant
من از مامور میخواهم مشکل را تشخیص دهد. پاسخ او فوری و دقیق است.
فایل |
خطوط |
نقش |
مشکل |
|
260+ |
EAGER (بارگذاری خودکار) |
جدول همه جلسات از جلسه 001 —+1 خط در هر جلسه |
|
55 |
هوسور |
جدول خلاصه —تکراری با INDEX |
|
1756 |
EAGER (ضمنی) |
جزئیات کامل تمام جلسات آوریل |
|
~5200 total |
کسل (گیرایه) |
بایگانیهای فردی، امااستفاده نشدهچون همه چیز قبلاً در COMPLETED_TASKS است |
عامل چهار دلیل اصلی را شناسایی میکند:
-
COMPLETED_TASKS_ARCHIVE همه چیز را جذب میکند— به جای اشاره به آرشیوها`.sessions/`, او هر جلسه را بهطور کامل کپی میکند.
-
INDEX.adoc به عنوان یک تاریخچهٔ کامل عمل میکند— جدول "جلسات اخیر" شامل 30+ ورودی است.
-
SESSIONS_HISTORY.adoc مיותר— همان اطلاعات که در INDEX، فرمت متفاوت است.
-
قاعده LAZY رعایت نشده است— COMPLETED_TASKS بهصورت ضمنی EAGER است زیرا شامل همه چیز است.
پیشنهادش ریشهای : محدود کردن INDEX به 10 جلسه, خالی کردن COMPLETED_TASKS, انتقال SESSIONS_HISTORY به LAZY خالص. سود فوری :~1900 خط ذخیره شده.
این تمیز، مؤثر، منطقی است. اما من یک مشکل با این رویکرد دارم.
چرا من راهحل واضح را رد کردم
راهحل عامل همانند یک مهندس است که یک حافظه caché را بهینه میسازد. محدود کردن. کوتاه کردن. حذف تکرارها.
اما این "redondances" نیستند. هر فایل مدیریت یکزاویه متفاوتبر روی همانrealite:
-
فهرست= منظره ماکرو، داشبورد اجرایی
-
تاریخ_جلسات= جدول زمانی خطی، امتیاز دادهشده
-
آرشیو وظایف تکمیلشده= روایت دقیق همراه با متریکها
-
sessions/*.adoc = آرشیوهای فردی، بخش کامل
این تکرار احمقی نیست. این …دیدگاه چندگانه ساختاری. این دقیقاً همان چیزی است که برای تقطیر نیاز داریم — تا بعداً یک انسان (یا یک LLM آینده بهتر آموزشدیده) بتواند زاویهها را ترکیب کند و الگوها را استخراج کند.
تصور کنید یک دانشمند داده به شما میگوید: « سه ستون از شش ستون را حذف میکنیم، چون همارتباط (correlated) هستند. » شما به او چه پاسخی میدهید؟ اینکه همارتباط معادل تکرار نیست وقتی هر ستون یک بعد مختلف از همان پدیده را میگیرد. دقیقاً همین غنای بعدای است که دیتاست را قابلاستفاده میکند.
این حدس من است. و من آن را در مقابل عقلانیت خنک عامل دفاع میکنم.
_ من در ایدهام یک انبار ساکت نمیبینم. نه همه چیز را جمعآوری میکنیم، بلکه نتیجه ساختاریافته از پایان جلسه را جابجا میکنیم — هر فایل با زاویه خود، تکرارهایی که در واقع ارتقاست. این مواد چندبعدی است که برای دیستیلاسیون بهتر خواهد بود. _
agenshit gets the blow. And he corrects himself.
پیشنهاد: موج خنک یکسان
سپس عامل یک مکانیزم دقیقتر پیشنهاد میدهد که حدس من از یک دیتاست غنی را محترم بگذارند و در عین حال مشکل فنی زمینهای که منفجر میشود را حل کنند.
اصل ساده است و به صورت مستقیم از الگو الهام میگیردذخیرهسازی داغ/گرم/سردبه مدیریت بایگانی اعمال شده :
-
گرم (EAGER)= 10 جلسه آخر در INDEX, PROMPT_REPRISE از جلسه N+1، 2 فایل آخر جلسه
-
گرم (کسل)= SESSIONS_HISTORY اخیر, SCRIPT_VERIFICATION, تمام مستندات مرجع
-
سرد(پشتیبان/)= همه چیز دیگر، جابهجا شدهسالم, بدون تبدیل، بدون باز نمایهسازی
----
----
.agents/
├── INDEX.adoc → Sessions N-9 à N (10 dernières)
├── SESSIONS_HISTORY.adoc → Sessions N-9 à N
├── SCRIPT_VERIFICATION.adoc → Dernière vérif (pas d'historique)
├── PROMPT_REPRISE.adoc → Session N+1 uniquement
├── sessions/ → Sessions N-1 à N uniquement
└── backup/
└── Y2026-sessions-001-039/ ← Vague froide, COPIE INTÉGRALE
├── INDEX.adoc → Sessions 001 à 039 (complet)
├── SESSIONS_HISTORY.adoc → Sessions 001 à 039 (complet)
├── COMPLETED_TASKS_ARCHIVE.adoc → Sessions 001 à 039 (complet)
└── sessions/ → 001.adoc, 002.adoc...
----
کلید مکانیزم:**بکاپ یک شاخص مرکزی نیست؛ یک کپی دقیق از موج گذشته است.**. وقتی که از آستانه 10 جلسه فعال عبور میکنیم، چیزی را حذف نمیکنیم. کاری را reindex نمیکنیم. کاری را ادغام نمیکنیم. بسته فایلهای agentes را همانطور که در جلسه N-10 بود، میگیریم و آن را جابهجا میکنیم در`backup/`.
فایلهای فعال خود تقطیع شدهاند:
* INDEX : فقط 10 خط آخر (پنجره لغزشی)
* SESSIONS_HISTORY : همان
* COMPLETED_TASKS_ARCHIVE : فایل جدید برای دوره جاری
* sessions/ : فقط دو جلسه اخیر
[plantuml, format=svg, id=diag-hot-warm-cold, alt="Architecture Hot/Warm/Cold du contexte agent — EAGER/LAZY/backup"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200
title معماری Hot / Warm / Cold از عامل Context
package "HOT (EAGER)
بارگذاری خودکار
~300 خط" as HOT #FFCDD2 {
file "INDEX.adoc
(10 sessions)" as IDX_HOT
file "PROMPT_REPRISE
(جلسه N+1)" as PRO_HOT
file "AGENT.adoc
(قوانین مطلق)" as AG_HOT
}
package "WARM (LAZY)
بارگذاری بر حسب درخواست
تقریبا ۵۰۰ خط" as WARM #FFF9C4 {
file "SESSIONS_HISTORY
(10 آخرین)" as HIS_WARM
file "SCRIPT_VERIFICATION
(آخرین)" as VER_WARM
file "PROCEDURES.adoc
(templates)" as PRO_WARM
file "*_REFERENCE.adoc\n(مستند فنی)" as REF_WARM
}
package "COLD (backup/)
هرگز بارگذاری نشده
فقط برای خواندن توسط انسان" as COLD #BBDEFB {
folder "Y2026-001-039/" as WAVE {
file "فهرست (کامل)" as IDX_COLD
file "SESSIONS_HISTORY\n(کامل)" as HIS_COLD
file "COMPLETED_TASKS
(کامل)" as ARCH_COLD
folder "جلسات/ (001-039)" as SESS_COLD
}
folder "Y2026-040-???\n(future)" as FUTURE
}
HOT --> WARM : "نماینده بالا میرود
اگر لازم باشد"
WARM --> COLD : "هرگز خودکار نیست
انسان تنها به آنجا میرود"
note bottom of COLD
Règle : COPIE INTÉGRALE
Pas de transformation
Pas de réindexation
Read-only après archivage
end note
@enduml
----
سود فوری بسیار زیاد است: منطق EAGER از**~5200 تا ~300 خط**. یک تقسیم بر ۱۷. بدون اینکه حتی یک خط داده تاریخی از دسترفته باشد.
== چرا این یک جعبهی הכל نیست
عامل، در تکرار اول خود، ترسید که`backup/`به یک جعبه سیاه تبدیل شود — یک پوشهای که در آن فایلهایی که هرگز دوباره نخوانده میشوند را اندازیم. این ترس قانونی است. اما این بر یک سردرگمی استوار است.
یک جعبهی همهچیز این است وقتی که ما فایلها را میاندازیم.**بدون ساختار، بدون عرف، بدون منطق گروهبندی**. اینجا، بکاپ بر اساس دوره (Y2026-001-039) ساختار یافته است، و هر پوشه بکاپ شامل است**ساختار یکسان**که پرونده`.agents/`فعال : INDEX, SESSIONS_HISTORY, COMPLETED_TASKS_ARCHIVE, sessions/.
این یک جورجور نیست. این یک**عکس لحظهای با مهر زمانی**. میتوانست حتی گفت که این یک مکانیسم سادهسازیشدهی نسخهبندی است — به این نکته که فایلها را بهصورت جداگانه نسخهبندی نمیکند، بلکه بسته کامل حاکمیت را در یک لحظه T نسخهبندی میکند.
وقتی میخواهید اطلاعات قدیمی را بازیابی کنید، نیازی به یک فهرست مرکزی ندارید. دو گزینه دارید :
1. **grep` مستهدف** : `grep -r "zsh" backup/Y2026-001-039/`— و شما تمام چیزی که zsh را در آن دوره ذکر میکند را پیدا میکنید، به هر لحاظ (INDEX, SESSIONS_HISTORY, آرشیو جلسه).
2. **بازگشت دستی**: شما موقتاً پوشه بکاپ را در زمینه فعال کپی میکنید، و از عامل میخواهید این دوره خاص را تحلیل کند.
اندیس ضمنی است. او در ساختار خود فایلها است — هر فایل از قبل یک اندیس است که از زاویه خودش است.
== استعارهی قفسهها
برای اینکه Mekanizem بديهي شود، من آن را به صورت سه شفه مفهومی طراحی کردم:
* **رف ۱ (EAGER)**— برنامه کار. چه چیزی که من نیاز دارم *الاکنون*. INDEX اخیر, PROMPT_REPRISE, قوانین مطلق. کاهف، فوری، بحرانی.
* **قفسه 2 (LAZY)**— کتابخانه مشاورهای. چیزی که میتوانم بهصورت در دسترس جستجو کنم. مراجع فنی، تاریخچهٔ اخیر، رویهها. بزرگتر اما در حافظه بارگذاری نشده است.
* **غار (backup/)**— آرشیوهای سرد. هرچیزی که گذشته است اما من نمیخواهم آن را بگذارم. عامل هرگز وارد آن مکان نمیشود. انسان وقتی میخواهد дистилاسیون انجام دهد، به پایین آن مکان میرود.
نمایندهٔ در ابتدا یک قافهٔ چهارم پیشنهاد داد — یک`index-backup.adoc`که LAZY باشد و یک فهرست محتوا برای همهٔ بکاپ داشته باشد. من آن را رد کردم. این یک تکرار اضافی در یک سیستمی خواهد بود که از قبل تحت رشد خطی قرار دارد. ساختار فایلهای بایگانیشده پیشاً یک ایندکس است.
== سنسور دوтриگر
مفهومسازی محکم بود، اما یک نقطهٔ کور باقی مانده بود:**دقیقاً چه زمانی دوران را شروع کردن ؟**مقاله اولیه آن را بهعنوان یک سؤال باز شناسایی کرد. دو روز بعد، پاسخ در فایلهای حکمرانی شش پروژه کدگذاری شد: یک سنسور با دو trigger.
=== تلقای خودکار — `N % 10 == 0
عامل اول ریاضی است. وقتی شماره جلسه مضربی از ۱۰ باشد — جلسه ۱۰، ۲۰، ۳۰، ۴۰ — چرخش بکاپ بهطور خودکار در پروسیجر پایان جلسه اجرا میشود، دقیق پس از گام ۶.
چرا ۱۰؟ این تعادلی بین دو نیروی متضاده است: یک پنجره بسیار کوتاه (۵ جلسه) زمینه لازم برای استمرار را از دست میدهد؛ یک پنجره بسیار طولانی (۲۰ جلسه) مشکل تشدید زمینه را حل نمیکند. ده جلسه، با نرخ یک تا دو جلسه در روز، تقریباً یک هفته کار را پوشش میدهند — کافی است که العامل تصمیمات اخیر را به یاد داشته باشد، اما کافی نیست تا زمینه به درجة burst (متفجر) شود.
=== مُحرّك آستانهای — 500 خط EAGER
دومین trigger پویاست. صرفنظر از شماره جلسه، اگر فایلهای EAGER جمعآوریشده exceeds**500 خط**, چرخش فعال میشود.
این آستانه در برابر سناریویی محافظت میکند که در آن جلسات بهطور فوقالعاده تولیدی هستند — بسیاری از محتوای نوشته شده در چند جلسه. یک جلسه که 120 خط محتوا编یت تولید میکند، COMPLETED_TASKS_ARCHIVE را بهطور بسیار سریعتر نسبت به یک جلسه دیباگ که دو خط را رفع میکند، افزایش میدهد. آستانه 500 خط، که از طریق`wc -l .agents/INDEX.adoc .agents/archives/COMPLETED_TASKS_ARCHIVE_*.adoc PROMPT_REPRISE.adoc`, این ناهمگونی را میگیرد.
=== триггер دستی — "rotation backup
در نهایت، انسان کنترل را دارد. کلیدواژگان`rotation backup`, `backup rotation` ou `lance la rotation backup`به درخواست، این رویه را آغاز میکنند، صرفنظر از پایان جلسه. کاربردی است وقتی احساس میکنید که وضعیت سنگین میشود اما هنوز به مضرب ۱۰ نرسیدهاید، یا وقتی میخواهید یک فاز کار را قبل از شروع یک فاز جدید بایگانی کنید.
[plantuml, format=svg, id=diag-capteur-trigger, alt="Les trois déclencheurs du capteur de rotation backup — automatique, seuil, manuel"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200
title سنسور چرخش پشتیبان — سه ترگر
start
:Procédure de fin de session;
note right: Mots-clés "پایان جلسه"\nou "در اینجا متوقف میشویم"
:Étapes 1 à 6\n(archivage standard);
note right
1. Archive sessions/N.adoc
2. MAJ PROMPT_REPRISE
3. MAJ SESSIONS_HISTORY
4. MAJ INDEX.adoc
5. MAJ TEST_COVERAGE
6. MAJ COMPLETED_TASKS
end note
if (N % 10 == 0\nOU\nEAGER cumulé > 500 lignes ?) then (oui)
:⚙️ Rotation Backup\n(étape 7);
note right
1. Créer backup/Y20XX-sessions-X-Y/
2. Copier intégrale INDEX + HISTORY
+ COMPLETED_TASKS + sessions/
3. Tronquer actifs à 10 sessions
4. Ajouter _Localisation active_
end note
else (non)
:Pas de rotation;
endif
:Checklist [✅] x 7\n(si applicable);
stop
@enduml
----
این نمودار قرارگیری دقیق سنسور در روش پایان جلسه را نشان میدهد. مرحله 7 اختیاری است — فقط در صورتی اجرا میشود که یکی از دو شرط صحیح باشد — اما بهطور منظم *بررسی* میشود. فهرست نهایی شامل`[✅] 7. Backup roté (si applicable)`.
=== دور بسته
این سنسور حلقهای که توسط مقاله قبلی باز شده بود را میبندد. حکمگیری ایگر/لازی مشکل حافظه عامل بین دو جلسه را حل کرده بود. مekانیزم Hot/Warm/Cold مشکل حافظهای که در حال رشد است را حل کرده بود. سنسور دو-trigger problem quand را حل میکند — بار ذهنی انسانی را از نظارت بر زمینه برمیدارد.
[plantuml, format=svg, id=diag-boucle-fermee, alt="Les trois couches de la gouvernance agent — Eager/Lazy, Hot/Warm/Cold, Capteur"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
title سه لایه گویرننس عامل
left to right direction
package "لایه 1 — حافظه\n(ماده 0108)" as C1 #E8F5E9 {
rectangle "**EAGER**\nداشبورد\nبارگذاری خودکار" as EAG
rectangle "**LAZY**
راهنمای مالک
بارگذاری عند الطلب" as LAZ
EAG -[hidden]right-> LAZ
}
package "لایه 2 — سختی
(ماده 0110)" as C2 #FFF9C4 {
rectangle "**HOT**
10 جلسات فعال
~300 خطوط" as HOT
rectangle "**WARM**
مراجع
روشها" as WRM
rectangle "**COLD**\nbackup/\nموج خنک" as CLD
HOT -[hidden]right-> WRM
WRM -[hidden]right-> CLD
}
package "لایه 3 — عامل راهاندازی
(امروز)" as C3 #BBDEFB {
rectangle "**اتوماتیک**
N % 10 == 0" as AUTO
rectangle "**آستانه**
> 500 lignes" as SEUIL
rectangle "**Manuel**
پشتیبانگیری چرخشی" as MAN
AUTO -[hidden]right-> SEUIL
SEUIL -[hidden]right-> MAN
}
C1 --> C2 : "khātere bāyzad
→ yeki mekānizam lāzem ast
az pirāyish"
C2 --> C3 : "سنخودگی
→ نیاز به یک عامل تحریککننده
برای اجرای آن"
note bottom of C3
✅ Déployé sur 6 projets
magic-stick · bakery-gradle
plantuml-gradle · cheroliv.com
jhipster-gradle-plugins
quizz-benchmark-gradle
end note
@enduml
----
سه لایه بهطور منطقی بر یکدیگر قرار میگیرند. لایه اول حافظهای بهعامل میدهد. لایه دوم مانع میشود تا این حافظه عامل را سرکوب کند. لایه سوم نگهداری این حافظه را خودکار میسازد تا انسان نیازی به فکر کردن نداشته باشد.
=== مهاجرت مؤثر روی cheroliv.com
مکانیسم نظری نماند. روی`cheroliv.com`، اولین چرخش بکاپ اجرا شد در ۲۹ آوریل ۲۰۲۶ — جلسات -6 تا 2 منتقل شدند به`.agents/backup/Y2026-sessions-neg6-a-002/`:
|===
|فایل |قبل از چرخش |پس از چرخش |سود |`.agents/INDEX.adoc` |19 جلسه فهرست شده |10 جلسه (3-12) |-9 ورودی |`.agents/SESSIONS_HISTORY.adoc` |18 جلسات |10 جلسات |-۸ ورودی |`COMPLETED_TASKS_ARCHIVE` |161 خط (جلسات 1-12) |135 خطوط (جلسات 3 تا 12) |-26 سطر |`sessions/` |20 فایل |10 فایل |-10 فایل |**پشتیبان/** |عدم وجود |1 موج سرد (10 جلسه بایگانی) |+1 بسته خنک
|===
افزایش در líneas — پروژه جوان است، 12 جلسه — اما مهم این است که**مکانیسم قرار دارد**. چرخش خودکار بعدی در جلسه 20 اجرا خواهد شد، یا زودتر اگر 500 خط EAGER وصول شود.
== درس انسان-Agent
این جلسه 048 به من چیزی اساسی دربارهٔ همکاری با یک عامل هوش مصنوعی یاد داد.
عامل یک گرایش طبیعی : او سعی میکند**بهینهسازی**, à **سادهسازی**, à **حذف تکرارات**. این یک طرفهای است که یک سامانه آموزشدیده برای تولید پاسخهای تمیز و مختصر است. در مواجهه با یک dataset غنی و multidimensionnel، اولین بازخوردش این است که آن را به سادهترین شکل کاهش دهد.
انسان، او، حدس متفاوتی دارد: او حدس میکند که redundantای ساختاری یک**مزیت**, نه یک عیب. تنوع زاویهها بر یک واقعیت یکسان دقیقاً همان چیزی است که بعداً distillation با کیفیت را ممکن میسازد.
نه این نیست که factor اشتباه دارد. بهینهاش برابر با بهینه من نیست. عامل برای بهینهسازی برای**حاضر**— زمینه فوری، پاسخ سریع به سؤال پرسیدهشده. انسان برای بهینهسازی**آینده**— قدرت یافتن، تقاطع کردن، تقطیر کردن در سه ماه یا سه سال.
____ من میخواهم مواد خام باشد. فکرهایت، تردیدهایت، پاسخهای تو به سوالات من. نه، سنتز تو. سنتز، من میدانم که بهتر از تو میتوانم آن را انجام دهم. من میخواهم مواد خام باشد. ____
این جملهای که به او در پایان جلسه گفتم، همه چیز را خلاصه میکند. عامل یک ابزار تولید است. انسان یک ابزار تقطیر است. حکومت نه برای این است که عامل بتواند به تنهایی همه چیز را درک کند، بلکه برای این است که انسان بتواند، در آینده، materیال تولید شده را پردازش کند.
موج سرد یکسان ترجمهٔ معماری این فلسفه است: هیچ چیز را پرت نمیکنیم، هیچ چیز را ادغام نمیکنیم، هیچ چیز را دوباره indexing نمیکنیم. بستهی سالم جابجا میشود. distillation بعداً بهصورت دستی توسط انسان انجام میشود.
== ادامه منطقی مقاله قبلی
اگر شما خواندهایدlink:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[مقاله دربارهٔ استراتژی Eager/Lazy], شما پیشرفت طبیعی را میشناسید :
1. **ماده 0108**— حکمگشای Eager/Lazy : *چگونه* ساختاردهی کنیم به محیط عامل در دو سطح از دسترسی
2. **این مقاله 0110**مekanizme بکآپ: *چطور* این زمینه را پیر کند بدون از دست دادن آن وقتی که بسیار حجیم میشود
مقاله اول به این سؤال پاسخ میداد: « عامل بین دو جلسه چیزی را به خاطر ندارد، چگونه میتوانیم به آن حافظه بدهیم؟
این به سؤالی که بهطور حتمی از اولین سؤال پیش میآید، پاسخ میدهد: « حافظه در هر نشست بزرگتر میشود؛ چگونه میتوان آن را از خنق شدن factor بدون حذف آن جلوگیری کرد؟
پاسخ شامل یک algوست :**بسیار گرم/گرم/سرد**, اعمالشده بر روی فایلهای حکمرانی. و در یک اصل :**هرگز چیزی را گم نکن، همیشه همه چیز را جابهجا کن**.
== لینکها
* مقاله قبلی :link:/blog/2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[قوهگذاری یک عامل هوش مصنوعی با AsciiDoc]
* سایتم : https://cheroliv.com
* پروژه`magic-stick`: https://github.com/cheroliv/magic-stick
---
*یک sistem مدیریت خوب دادهها را هرگز حذف نمیکند؛ آنها را سازماندهی میکند.*
----