ContextForge：确定性上下文预算与路由插件
ContextForge：确定性上下文预算与路由插件
核心判断
ContextForge 值得深度入库，因为它把 Context Engineering 从“整理更多资料”推进到“把 context window 当作预算管理对象”。它用 Shadow Index、tier routing、filesystem memory、two-strike circuit breaker、output compression 和 hooks，把 token、工具选择、失败恢复和上下文外部化变成可执行约束。
机制 / 一阶原理
ContextForge 的六个支柱是：structure over search、token budget awareness、filesystem as memory、cheapest correct tier、fail loud/fail fast、hard constraints over soft guidance。它的 Shadow Index 试图用预构建符号 manifest 代替整文件读取；routing tier 先用 CLI/script，再升级到小模型/大模型；输出过大写盘摘要；重复失败触发 halt 并写 failure ledger。
一阶原理是：context window 不是数据库，而是工作寄存器。长期状态、决策、失败、manifest、worklog 应在文件系统中持久化；模型上下文只加载当前任务需要的最小、高信号片段。token 效率不是少做事，而是把确定性工作交给确定性工具，把不该常驻的知识放到可检索磁盘结构中。
对 Hermes / llm-wiki 的启发
Hermes 当前已经有 read_file/search_files/patch 等窄工具，ContextForge 提醒我们应继续偏好 progressive disclosure：先 count/files，再读相关段落；先用专用工具，再用 shell；长输出落盘或摘要；失败两次后停止并写明诊断，而不是无限重试。对 llm-wiki，_index、wikilinks、raw hash、wiki-vquery、log 都是 context budget 的组成部分，应该减少重复搜索和薄页面噪音。
它也提醒 skill 设计要有可编译/可 lint 的结构：rules、skills、agents、hooks 来自 core source，而非到处手写分叉。这与 External-Agent-Skills-Design-Patterns 中的渐进披露、lockfile、lifecycle governance 一致。
失败模式与边界
ContextForge 依赖 hooks、manifest 和外部文件纪律；如果 manifest 不更新、hooks 未触发、tier routing 过度禁止探索，就可能让 agent 错过必要上下文。它适合作为上下文预算和确定性约束的模式来源，但任何本地改造都需要先用小任务 A/B 验证 adoption、token savings 与正确率，而不是直接安装全套规则。
相关页面
- Context-Engineering
- Harness-Engineering
- External-Agent-Skills-Design-Patterns
- token-diet-token-efficiency-skill
写入记录
- 2026-07-31 09:01 CST：新增对 ContextForge 的 Shadow Index、tier routing、filesystem memory、circuit breaker、输出压缩和 Hermes progressive-disclosure 纪律的分析。