代理上下文审计:当您自己的治理成为问题——以及如何在不失去任何东西的情况下修复它
发布于 27 April 2026
你花了数周时间打造了一个无懈可击的代理治理。急切/懒惰,会话结束程序,轮换备份。系统正在运行。然后有一天,代理变慢了。响应被稀释了。你测量:自动加载了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,禁止破坏性命令,禁止泄露秘密 |
|
P4 — 会话生命周期 |
133 |
模板打开, 工作规则, 6 步骤结束会议, 清单 |
|
P5 — 指标和阈值 |
49 |
理想的会话 (15-30 分钟, 1-3 文件),警示信号 |
— |
P6 — 会话类型 |
72 |
检测表, 提案格式, 例外 |
— |
P7 — 持续改进 |
39 |
跟踪指标,每周审查 |
— |
P8 — 启动检查清单 |
13 |
Bootstrap 新项目 |
— |
P9 — 参考文献 |
30 |
参考文件,外部资源 |
|
附件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`, 结果是:
-
提取161 行唯一知识 (P1 + P2) 在一个新文件中`LAZY_EAGER_ESSENTIALS.adoc`— 压缩到~50行,严格EAGER
-
重命名
AGENT_MODUS_OPERANDI.adocen.agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc— 627行的原始文件,保持 完整,在冷存储中 -
永远不要充电自动的百科文件 — 它是为人类而存在,为未来的蒸馏而存在,为六个月后在更好模型下调用的代理而存在。
@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/) 是一个带时间戳的快照——过去状态的备份。
百科全书,那是另外一回事。这是一种按主题结构的知识集合,全面但非线性。我们不会从头到尾读一本百科全书。我们会深入其中以回答特定的问题。
这就是这个文件的确切合同:
档案 |
角色 |
访问 |
粒度 |
|
历史数据(每月完成的任务) |
LAZY, 结构化 |
按时间顺序 |
|
冷快照(每10次会话为一波) |
COLD,完整副本 |
时间顺序的 |
|
全面的主题知识 (方法论, 模式) |
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 治理,以下是一个五步审计程序:
-
测量:`wc -l`在您所有的 EAGER 文件中。总数应少于 1000 行。
-
识别最大的: 占总量超过20%的文件是头号嫌疑犯。
-
逐节审计: 对每个部分,请自问 «此信息是否已经在其他地方? 该代理是否已经在另一个文件中读取过此信息? 它是否在最近的五次会议中被使用过?
-
分类器: 重复,从未使用过,独有的知识。
-
分路器或重新定位: 什么是独特且关键的 → 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 倍。没有丢失任何一行文档、任何一次会话存档、任何一条所学到的教训。
一切都在那里。只是整理得更好。
链接
-
条目 0108 — 急切/延迟策略:用 AsciiDoc 管理 AI 代理
-
条目 0110 — 热/温/冷机制 :滑动窗口和寒潮
-
我的网站:https://cheroliv.com
-
项目`magic-stick`: https://github.com/cheroliv/magic-stick
知识不必消失。它只需要在不必要的时候不被加载。
相关文章
31 May 2026
14 May 2026
12 May 2026