阅读时间 : 14 minutes

你花了数周时间打造了一个无懈可击的代理治理。急切/懒惰,会话结束程序,轮换备份。系统正在运行。然后有一天,代理变慢了。响应被稀释了。你测量:自动加载了1414行。而最糟的是,罪魁祸首既不是代码,也不是待办事项,也不是会话存档。罪魁祸首就是记录你方法的文件。

场景:051号会议,出了点问题

2026年4月30日,16:00。我正处于会议中`magic-stick`, 我的Linux Live ISO构建项目。Opencode代理自动加载了我的Eager文件,像往常一样 —AGENT.adoc, PROMPT_REPRISE.adoc, .agents/INDEX.adoc. 一切正常。

只是答案变得软绵绵的。代理多用了两秒才推理出来。它忘记了三条消息前就在眼前的细节。这不是崩溃,也不是错误——而是一种缓慢的退化,起初并不容易被察觉。

我在第 048 次会议中已经经历过这种情况,当时我发现治理文件的累计行数达到 5200 行。于是我提出了 Hot/Warm/Cold 机制,包含 10 次会议的滑动窗口、相同的冷浪以及双触发器传感器。问题在理论上已经解决。

但现在,我们处于第 051 会话。备份轮转已经成功进行 — — EAGER 文件从 2087 行减少到 500 行。然而,情况仍然沉重。我似乎漏掉了什么。

我打开一个终端并输入:

wc -l AGENT.adoc AGENT_MODUS_OPERANDI.adoc PROMPT_REPRISE.adoc \
  .agents/INDEX.adoc .agents/SESSIONS_HISTORY.adoc \
  .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
  287 AGENT.adoc
  627 AGENT_MODUS_OPERANDI.adoc
   51 PROMPT_REPRISE.adoc
  218 .agents/INDEX.adoc
   18 .agents/SESSIONS_HISTORY.adoc
  213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
 1414 total

1414 行。备份轮转已经很好地裁剪了 INDEX, SESSIONS_HISTORY 和 COMPLETED_TASKS — 它们很干净。但房间里有只我之前没看到的大象:627 行在单个文件中。AGENT_MODUS_OPERANDI.adoc.

这个文件,就是我在会议1中编写的,用来记录 Eager/Lazy 策略的。这是该方法的手册。而且它仅凭自己就成为了 EAGER 上下文的 44%。

@startuml
skinparam backgroundColor #FEFEFE

title 上下文 EAGER — 1414 行
rectangle "AGENT_MODUS_OPERANDI\n**627 行 (44%)**" as MOD #FFCDD2
rectangle "AGENT.adoc\n287 行 (20%)" as AG #BBDEFB
rectangle "INDEX.adoc\n218 行 (15%)" as IDX #C8E6C9
rectangle "COMPLETED_TASKS\n213 行 (15%)" as ARC #FFF9C4
rectangle "PROMPT_REPRISE\n51 行 (4%)" as PRO #E1BEE7
rectangle "SESSIONS_HISTORY\n18 行 (1%)" as HIS #FFE0B2

note bottom of MOD
记录该方法的文件已成为最大的一笔开支
end note

@enduml

这完全是讽刺。设计用于*节省*上下文的文件已成为上下文的主要*消费者*。就像你的汽车使用手册比发动机还重。

审计:剖析 627 行

我决定逐部分进行审计。不是为了删除 — 为了*理解*哪些内容值得放在EAGER中,哪些内容可以在其他地方存在而不丢失知识。

这是确切的结构`AGENT_MODUS_OPERANDI.adoc`以及我在其中发现的 :

章节 线条 内容 已存在于…​

P1 — 概览

64

问题已解决,基本原则,仪表盘与手册的类比

—

P2 — 文件结构

97

树形结构, 加载策略, 何时加载什么

您是专业翻译员。 将法语翻译成中文。 完全保留所有反引号代码片段(…​)原样不变——切勿修改反引号内的内容、间距或位置。 此文本可能是较大句子的一段——请在不请求更多上下文的情况下翻译此片段。 仅输出翻译后的文本——不要提供解释、评论、介绍、替代方案或选项。 —

P3 — 绝对规则

34

禁止 Git,禁止破坏性命令,禁止泄露秘密

AGENT.adoc+INDEX.adoc

P4 — 会话生命周期

133

模板打开, 工作规则, 6 步骤结束会议, 清单

AGENT.adoc§会话结束 +INDEX.adoc

P5 — 指标和阈值

49

理想的会话 (15-30 分钟, 1-3 文件),警示信号

—

P6 — 会话类型

72

检测表, 提案格式, 例外

—

P7 — 持续改进

39

跟踪指标,每周审查

—

P8 — 启动检查清单

13

Bootstrap 新项目

—

P9 — 参考文献

30

参考文件,外部资源

AGENT.adoc(文件 EAGER/LAZY)

附件A+B

42

术语表,版本历史

—

裁决无可上诉:

  • 完全重复(167行) : P3, P4, P9 — 已经全部在`AGENT.adoc` ou INDEX.adoc,经常逐字逐句

  • 从未在实践中被咨询(215 行) : P5, P6, P7, P8, Annexes — 元治理,从未在任何会议中使用过

  • 唯一的知识(161 行) : P1 和 P2 — LAZY/EAGER 词汇,类比,加载策略

在627行上,382 都是噪声. 这些 382 行在 每次会话开始时 被加载,被代理消费,在我甚至说出“你好”之前就稀释了他的注意力。

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title 审计 AGENT_MODUS_OPERANDI.adoc — 627 行
left to right direction

rectangle "🟡 **重复项**\n167 行 (27%)" as DUP #FFF9C4 {
  card "P3 — 绝对规则\n(34 行)" as D1
  card "P4 — 生命周期\n(133 行)" as D2
  card "P9 — 参考\n(30 行)" as D3
}

rectangle "🔴 **未查看**\n215 行 (34%)" as JAM #FFCDD2 {
  card "P5 — 指标\n(49 行)" as J1
  card "P6 — 检测\n(72 行)" as J2
  card "P7 — 改进\n(39 行)" as J3
  card "P8 — Bootstrap\n(13 行)" as J4
  card "附录 — 词汇表\n(42 行)" as J5
}

rectangle "🟢 **唯一知识**\n161 行 (26%)" as UNI #C8E6C9 {
  card "P1 — 概览\n(64 行)" as U1
  card "P2 — 文件结构\n(97 行)" as U2
}

note bottom of UNI
这就是必须保存在 EAGER 中的。
其余 → 冷存储。
end note

@enduml

此图表是一切的关键。重复项(黄色)纯属噪声——代理会读取两次,分别来自两个不同的文件。从未被查看的(红色)是死记文档——精心编写却从未被使用。只有绿色部分包含了代理无法在其他地方找到的知识。

害怕失去工程学

此时,我眼前有确凿的证据:我必须减少`AGENT_MODUS_OPERANDI.adoc`. 但我犹豫。

这个文件是我手写的。每一节都是从实际会议中学到的课程的结果。P3 部分源自`rm -rf`意外地在`bakery-plugin`让我花费了真实的 Firebase 令牌。P4 部分是十五次会话的结果,在这些会话中我忘记归档并失去了线索。这个六步骤的程序并非出自一本书 — 它源于痛苦。

删除这些部分,就等于丢掉我自己工程的历史记录。产生这些内容的教训、我发现它们的时段、我不想再犯的错误。这不是文本——这是结晶的经验。

这就是我提出将指导解决方案的原则的地方:

_ 永远不要删除。始终重新定位。知识不必从项目中消失。它只需在不需要时不被自动加载。 _

解决方案:split百科的

我提出的模型很简单,它受到维基百科成长方式的启发:当一篇文章变得太长时,我们不把它切开——我们创建一篇详细的文章,并在主文章中保留一个摘要。

为`AGENT_MODUS_OPERANDI.adoc`, 结果是:

  1. 提取161 行唯一知识 (P1 + P2) 在一个新文件中`LAZY_EAGER_ESSENTIALS.adoc`— 压缩到~50行,严格EAGER

  2. 重命名 AGENT_MODUS_OPERANDI.adoc en .agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc— 627行的原始文件,保持 完整,在冷存储中

  3. 永远不要充电自动的百科文件 — 它是为人类而存在,为未来的蒸馏而存在,为六个月后在更好模型下调用的代理而存在。

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title 百科拆分 — AGENT_MODUS_OPERANDI
left to right direction

rectangle "**AGENT_MODUS_OPERANDI.adoc**\n627 行\n(拆分前)" as BEFORE #FFCDD2 {
}

rectangle " " as ARROW1
rectangle " " as ARROW2

rectangle "**LAZY_EAGER_ESSENTIALS.adoc**\n**~50 行 — EAGER**" as ESS #C8E6C9 {
  card "P1 精简\n(15 行)" as E1
  card "P2 精简\n(35 行)" as E2
}

rectangle "**.agents/encyclopedies/**\n**LAZY_EAGER_ENCYCLOPEDIE.adoc**\n627 行 — COLD" as ENC #BBDEFB {
  card "P1 至 附件\n(int完整, 未更改)" as C1
}

BEFORE -[#4CAF50]-> ESS : "提取\n关键知识"
BEFORE -[#2196F3]-> ENC : "保留 int完整\n的工程"

note bottom of ESS
在会话开始时自动加载
→ 代理理解词汇
end note

note bottom of ENC
永不自动加载
可供人类查看
用于未来蒸馏的原始材料
end note

@enduml

名称`encyclopedies/`这并非无关紧要。百科全书并不是档案文件——它是一套有组织的知识集合,可查询但不可携带。我们不会在地铁里阅读《Universalis百科全书》。我们把它放在图书馆里,只有在有具体问题时才会去查阅。

这正是该文件夹的作用:一个冷的、结构化的、完整的参考库——代理不会自动触碰它。

文件 ESSENTIALS 的内容

这就是新文件的具体样子`LAZY_EAGER_ESSENTIALS.adoc`, 从 P1 和 P2 提取并压缩 :

= Stratégie LAZY/EAGER — Principes Essentiels

[abstract]
Ce fichier définit la stratégie de gestion du contexte agent.
Chargé automatiquement (EAGER) en début de session.

== Principes

|===
| EAGER | LAZY
| Tableau de bord | Manuel du propriétaire
| Chargé automatiquement | Chargé sur demande
| <= 100 lignes, <= 10k tokens | Illimité, détaillé
| Règles absolues, mission courante | Archives, historique, références
|===

== Politique de Chargement

|===
| Fichier | Type | Quand charger
| PROMPT_REPRISE.adoc | EAGER | Début session (auto)
| *_ESSENTIALS.adoc | EAGER | Début session si EPIC active
| .agents/INDEX.adoc | EAGER | Début session (auto)
| *_REFERENCE.adoc | LAZY | Sur besoin (détails architecture)
| .agents/sessions/N-*.adoc | LAZY | Sur demande (détails session)
| .agents/encyclopedies/*.adoc | COLD | Jamais auto (humain seulement)
|===

== Comment l'Agent Sait Quoi Charger

Début session → PROMPT_REPRISE + INDEX + ESSENTIALS actifs.
Besoin de détails → charger les *_REFERENCE et sessions/ en LAZY.
Connaissance froide → encyclopedies/, jamais automatique.

五十行。这就是代理理解机制所需的全部。其余部分 — 课程历史、详细类比、逐步程序、附录 — 都存在于百科全书中。

而且最重要的是:没有任何内容被删除. 627行工程代码仍然存在,在`.agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc`. 它们只是被放在图书馆里,而不是放在工作台上。

结果:-50% 的 EAGER 上下文

分割前:

 287 AGENT.adoc
 627 AGENT_MODUS_OPERANDI.adoc
  51 PROMPT_REPRISE.adoc
 218 .agents/INDEX.adoc
  18 .agents/SESSIONS_HISTORY.adoc
 213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
1414 total

拆分后:

 287 AGENT.adoc
  50 LAZY_EAGER_ESSENTIALS.adoc       ← remplace 627 lignes
  51 PROMPT_REPRISE.adoc
 218 .agents/INDEX.adoc
  18 .agents/SESSIONS_HISTORY.adoc
 213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
 837 total                              ← -41%
@startuml
skinparam backgroundColor #FEFEFE

title 上下文 EAGER 在百科分割后 — 837 行 (-41%)
rectangle "AGENT.adoc\n287 行 (34%)" as AG #BBDEFB
rectangle "INDEX.adoc\n218 行 (26%)" as IDX #C8E6C9
rectangle "COMPLETED_TASKS\n213 行 (25%)" as ARC #FFF9C4
rectangle "PROMPT_REPRISE\n51 行 (6%)" as PRO #E1BEE7
rectangle "ESSENTIALS\n50 行 (6%)" as ESS #A5D6A7
rectangle "SESSIONS_HISTORY\n18 行 (2%)" as HIS #FFE0B2

note bottom of ESS
从 627 → 50 行
577 行工程
保存在冷存储中
没有任何丢失。全部已重新定位。
end note

@enduml

最大的消费者 (AGENT_MODUS_OPERANDI, 627 行) 已被替换为一个 50 行的文件。收益立即可见:577 行上下文被释放。代理松了一口气。

并且在`.agents/encyclopedies/`, 原始的 627 行文件正在等待。完整无缺。包含所有部分——包括那些是重复的部分,包括那些从未被使用过的部分。因为有一天,一个更好的模型或一个人类数据科学家会想要交叉这些角度,这些被接受的冗余,这些学到的教训。而那天,原始资料将会在那里。

为什么文件夹名为 `encyclopedies/

选择名称并非装饰性的。它编码了机制的哲学。

一个 存档 (archives/) 包含按时间顺序组织的历史数据 — 如每月的 COMPLETED_TASKS。一个 backup (backup/) 是一个带时间戳的快照——过去状态的备份。

百科全书,那是另外一回事。这是一种按主题结构的知识集合,全面但非线性。我们不会从头到尾读一本百科全书。我们会深入其中以回答特定的问题。

这就是这个文件的确切合同:

档案

角色

访问

粒度

archives/

历史数据(每月完成的任务)

LAZY, 结构化

按时间顺序

backup/

冷快照(每10次会话为一波)

COLD,完整副本

时间顺序的

encyclopedies/

全面的主题知识 (方法论, 模式)

COLD, 永不自动

主题

这种区别避免了混杂。每个文件都知道它应该存放的位置是根据 它包含的内容,而不是根据 它的创建时间。

该系列的逻辑续集

如果你已经读过前两篇文章,以下是这三部分如何相互嵌合的:

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 220

title 代理治理三部曲
left to right direction

package "📖 **Article 0108**\nEager 策略/Lazy" as A1 #E8F5E9 {
  card "代理记忆\n在会话之间" as M1
  card "文件 EAGER\n(自动加载)" as M2
  card "文件 LAZY\n(按需)" as M3
  card "6 步骤流程" as M4
}

package "🧊 **Article 0110**\nHot 机制/Warm/Cold" as A2 #FFF9C4 {
  card "老化\n上下文" as V1
  card "滑动窗口\n10 会话" as V2
  card "冷波\n相同" as V3
  card "传感器\n双触发器" as V4
}

package "🔍 **Article 0111**\n审计 + 百科解决方案" as A3 #BBDEFB {
  card "文件审计\nEAGER" as E1
  card "识别\n浪费" as E2
  card "拆分\nESSENTIALS/encyclopédie" as E3
  card "保留\n工程" as E4
}

A1 --> A2 : "记忆增长\n→ 需要一个机制\n老化"
A2 --> A3 : "老化不足\n→ 需要审计哪些\n值得被放在 EAGER"

note bottom of A3
✅ 三层已就位
在6个活跃项目中
end note

@enduml
  • 0108回答: « 如何在两个会话之间为代理赋予记忆?

  • 0110回答: « 如何防止这种记忆淹没代理?

  • 0111回答 : « 如果问题不在于档案的大小,而在于我们 选择 放入 EAGER 的内容吗?

第一篇文章构建了结构。第二篇添加了老化机制。第三篇审查内容 — 并发现方法论本身已成为问题。

我本来可以做得不同

事后看来,我看到了最初的设计错误。`AGENT_MODUS_OPERANDI.adoc`它被创建为一个单一的文档 — — 一个宣言。这是形式化思想的正确方法。但一旦思想被形式化,文档本应立即被拆分:核心内容放在 EAGER 中,完整内容放在 cold 中。

我没有这样做,因为我对这份文件感到自豪。627 行纯工程代码,手写而成,每一节都是一次课程的成果。这是我的作品。就像所有作者一样,我很难把它切开。

课:一个文档很好并不意味着它必须自动加载。. 内容的质量与其在代理人即时上下文中的相关性无关。

今天,规则很简单:在 EAGER 上下文中,超过 100 行的文档都是嫌疑对象。它值得审计。不是定罪 — — 审计。而问题从来不是« 是否应该删除它? »而是« 是否应该在每次会话中加载它?

审计您自身上下文的指南

如果您已经遵循了前两篇文章并建立了自己的 Eager/Lazy 治理,以下是一个五步审计程序:

  1. 测量:`wc -l`在您所有的 EAGER 文件中。总数应少于 1000 行。

  2. 识别最大的: 占总量超过20%的文件是头号嫌疑犯。

  3. 逐节审计: 对每个部分,请自问 «此信息是否已经在其他地方? 该代理是否已经在另一个文件中读取过此信息? 它是否在最近的五次会议中被使用过?

  4. 分类器: 重复,从未使用过,独有的知识。

  5. 分路器或重新定位: 什么是独特且关键的 → ESSENTIALS 紧凑。其余全部 →encyclopedies/。

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title 代理上下文审计程序 — 5 步骤
start

:1. **测量**\n`wc -l *.adoc .agents/*.adoc`;

if (Total > 1000 lignes ?) then (oui)
  :上下文过于沉重;
else (non)
  :✅ Contexte OK;
  stop
endif

:2. **识别嫌疑人**\n文件 > 20% 的总计;

:3. **逐段审计**\n对于每个章节 :\n• 已在其他地方 ? → 重复\n• 从未使用 ? → 死亡\n• 唯一信息 ? → 关键;

:4. **Classifier**\n🟡 重复项 → 从 EAGER\n中移除🔴 从未使用 → 冷存储\n🟢 唯一知识 → 保留;

:5. **拆分器**\n🟢 → ESSENTIALS(~50 行,EAGER)\n🟡🔴 → encyclopedies/(冷存储);

:✅ 优化的上下文 \n,无工程损失;

stop

@enduml

此程序需要 15 分钟。在一个包含 50 次会话的项目中,它为每个未来的会话节省数百个 token。投资回报率立即可见。

充满活力的治理

这三篇文章系列让我学到的就是,智能体治理不是一个成品。这是一个活的有机体. 她随着项目成长。 她会患上生长期疾病。 她需要定期体检。

第048次会议发现档案在膨胀。第051次会议发现方法论本身也在膨胀。第060次会议可能会发现其他东西。这是正常的。这是健康的。从不自我反思的治理是死气沉沉的治理。

已设置的三种机制 — Eager/Lazy、Hot/Warm/Cold、百科全书式分割 — 构成了防止上下文饱和的纵深防御体系。单独任何一种都不够。它们共同协同作用:

  • 急切/懒惰结构信息 按可用性

  • 热/温暖/冷结构信息 按新鲜度

  • 百科全书审计结构信息 按密度

@startuml
skinparam backgroundColor #FEFEFE
skinparam nodeBackgroundColor #E3F2FD

title 针对上下文饱和的深度防御
node "**代理上下文**\n~800 行\n健康" as CTX #C8E6C9

node "层 1\n**EAGER / LAZY**" as C1 #BBDEFB
node "层 2\n**HOT / WARM / COLD**" as C2 #BBDEFB
node "第3层\n**ESSENTIALS / ENCYCLOPÉDIE**" as C3 #BBDEFB

CTX --> C1 : "结构按\n**可用性**"
CTX --> C2 : "结构 par\n**新鲜度**"
CTX --> C3 : "结构 按\n**密度**"

note bottom of C3
这三层是必需的。单独任何一层都不够。
end note

@enduml

使用这三层,代理上下文在`magic-stick`从 2087 行(在任何优化之前)减少到大约 800 行 — — 减少了约 2.6 倍。没有丢失任何一行文档、任何一次会话存档、任何一条所学到的教训。

一切都在那里。只是整理得更好。

链接


知识不必消失。它只需要在不必要的时候不被加载。

相关文章