Token Warden — benchmark-gated agent memory
Token Warden — benchmark-gated agent memory
一句话结论
Token Warden 把 agent memory / behavioral rule 当作要付租金的上下文资产：规则只有在 frozen benchmark 上证明节省的 tokens 大于携带成本，才保留。这对 Context-Engineering 和 llm-wiki 的直接启发是：长期规则、skills、关注名单、雷达 prompt 和 wiki 页面都不应无限累积；它们需要“是否仍然付租”的证据。
为什么这对用户重要
用户的 Hermes 环境已经有大量技能、wiki 页面、cron prompt、关注主题和每日自我优化建议。复利系统最容易滑向另一面：每次都加一点规则，长期变成 context tax。Token Warden 的价值不只是省钱，而是提供一种治理原则：拒绝无证据的永久上下文。这可以防止 llm-wiki radar 因历史偏好、重复主题和薄页面膨胀而变慢、变窄、变噪。
机制 / 一阶原理
Token Warden 的循环是 collect → distill → bench → select。Stop hook 记录昂贵 session 的成本；模型从 waste trace 中提出候选规则；/warden-select 在 frozen golden suite 上用 with/without 对照测试候选；只有净收益超过成本的规则才进入长期记忆。
它最有价值的部分是 measurement discipline：作者实现并测量了多个看似合理的统计/算法改进，然后删除了在自身数据上不划算或无效的设计。README 中强调 estimator accuracy 与 decision quality 不同，false positive 和 false negative 的经济成本不同，context window 稀缺才应由 packer 处理，而不是在 admission gate 上过度保守。
与已有 wiki 概念的关系
- 与 Context-Engineering：上下文不是免费资源，长期规则必须证明边际收益。
- 与 Agent-Benchmarks：它把 memory/rule 的价值变成 A/B benchmark，而不是经验判断。
- 与 Loop-Engineering：它给 self-improvement loop 加上“候选规则 → 冻结评测 → 选择/删除”的外部证据门。
- 与 LLM-Wiki：wiki 页面和雷达主题同样有维护成本；长期不产生检索/决策价值的页面应合并、降级或归档。
对 Hermes / llm-wiki 的可执行启发
- 对 radar 自我优化建议增加“租金”标准：只把会改变未来行为、可验证且不重复的建议沉淀为 durable rule。
- 每月抽样检查高频 rules/关注主题：哪些带来高价值入库，哪些连续只产出低价值候选，应降权。
- 对
wiki/ai/sources/llm-wiki-optimization-*做主题聚合；若连续多日重复“增加 receipts / 写入记录 / index/log”，应合并为一个 checklist，而不是每天新增同义规则。
失败模式 / 边界条件
- Token Warden 的经济结论依赖具体 agent、任务、token 价格和 golden suite；README 也承认真实生产工作流是否存在可泛化节省仍未完全证明。
- 小团队或个人仅按 token 成本可能不回本；价值更多在于拒绝坏规则、维持上下文清洁。
- benchmark-gated memory 容易过拟合 frozen suite；需要轮换任务、保留拒绝记录，并检查规则是否伤害未覆盖场景。
写入记录
- 2026-08-24 09:00 CST：新增 Token Warden source 页，提炼 benchmark-gated memory、context rent 与 llm-wiki 规则治理启发。