llm-wiki 自我优化 2026-07-20

llm-wiki 自我优化 2026-07-20

今日从内容更新学到什么

今天高价值材料集中在一个共同方向：agent 系统的下一阶段不是更长 prompt，而是可审计状态、可恢复上下文、可控 harness 和可重复评测。LoopX 代表 long-running loop 的状态内核；Entroly 代表 context receipts 与 recoverable compression；PawBench 代表 Model × Harness 共评测；AgentKernelArena 代表 A/B 与外部 reward signals。这些内容互相强化了 llm-wiki 既有的 Loop-Engineering、Context-Engineering、Harness-Engineering 和 Agent-Benchmarks 主线。

已做的低风险优化

1. 本次 radar 没有以 Karpathy 为中心，而是从 GitHub/README/API 发现 agent control plane、context OS、benchmark 和 A/B 环境。
2. 对每个晋升 source 页都补齐了“为什么重要、机制、一阶原理、关系、可执行启发、失败模式、深度判断、写入记录”。
3. 对 raw archive 使用 sha256 frontmatter 保存原始 README，降低未来 re-ingest 时 drift 不可见的问题。
4. 把“未入库原因”和“证据质量”写进日报，向 Entroly 式 context receipt 靠拢。

应如何调整雷达

• 新增关注关键词/项目簇：state kernel、local control plane、context receipts、recoverable compression、Model × Harness evaluation、agent A/B testing、RL-ready agent environment、tool/skill overload。
• 候选筛选更偏系统变量：优先找能改变 agent 状态管理、上下文预算、工具选择、验证膜、A/B 实验和失败诊断的材料；少收集只有 star 增长但无方法论的合集。
• 每日报告增加 evidence class：明确区分“已读取 README/原文”“只读 GitHub API 摘要”“访问失败”“已有重复页面”。
• 后续可做小型 A/B：固定一组 radar topic，对比 GitHub-first、blog/paper-first、benchmark-first 三种 discovery path 的入库质量和重复率。

仍待改进的问题

1. _index.md 的 AI 来源列表已经很长，单行塞入 120+ source，阅读和维护成本高；应考虑按主题拆分为 agent benchmarks、context engineering、harness/loop、skills/security 等子段。
2. log.md 已接近 500 行，后续很快需要按年或按规则轮转，避免 cron 每次读取近期记录困难。
3. 新页面使用的 wikilinks 多数指向已有 index 中的概念名，但需要后续 targeted link check 确认大小写/别名解析是否全部符合 Obsidian 与 wiki-lint 规则。
4. Ratel 今天只作为候选补充 raw，未再次晋升，因为 2026-07-12 已有正式 source 页；后续可做 Ratel + Entroly 的 comparison 页。

写入记录

• 2026-07-20 09:00 CST：新增当天自我优化文章，归纳状态内核、context receipt、model-harness 共评测和 A/B reward 环境对 llm-wiki 雷达与自动化治理的启发。