خلاصه

پس از ۴۸ جلسه در یک پروژه واحد و مجموعاً بیش از ۱۵۰، سیستم مدیریت 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

من از مامور می‌خواهم مشکل را تشخیص دهد. پاسخ او فوری و دقیق است.

فایل

خطوط

نقش

مشکل

.agents/INDEX.adoc

260+

EAGER (بارگذاری خودکار)

جدول همه جلسات از جلسه 001 —+1 خط در هر جلسه

.agents/SESSIONS_HISTORY.adoc

55

هوس‌ور

جدول خلاصه —تکراری با INDEX

COMPLETED_TASKS_ARCHIVE_2026-04.adoc

1756

EAGER (ضمنی)

جزئیات کامل تمام جلسات آوریل

.agents/sessions/*.adoc

~5200 total

کسل (گیرایه)

بایگانی‌های فردی، امااستفاده نشدهچون همه چیز قبلاً در COMPLETED_TASKS است

عامل چهار دلیل اصلی را شناسایی می‌کند:

  1. COMPLETED_TASKS_ARCHIVE همه چیز را جذب می‌کند— به جای اشاره به آرشیوها`.sessions/`, او هر جلسه را به‌طور کامل کپی می‌کند.

  2. INDEX.adoc به عنوان یک تاریخچهٔ کامل عمل می‌کند— جدول "جلسات اخیر" شامل 30+ ورودی است.

  3. SESSIONS_HISTORY.adoc مיותר— همان اطلاعات که در INDEX، فرمت متفاوت است.

  4. قاعده 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 مدیریت خوب داده‌ها را هرگز حذف نمی‌کند؛ آن‌ها را سازماندهی می‌کند.*
----

مقالات مرتبط