llm-wiki 自我优化 2026-07-10
llm-wiki 自我优化 2026-07-10
今天从内容更新中学到什么
今天入库的三篇材料形成一个共同主题：长期 agent 系统的改进对象不是单次回答，而是围绕回答的 workflow / harness / contract。
| - [[tthe-test-time-harness-evolution | TTHE]]：执行轨迹可以反哺 harness，让系统在不改模型权重的情况下改进 context construction、tool policy、verifier 和 recovery logic。 |
| - [[from-prompts-to-contracts-harness-engineering | From Prompts to Contracts]]：可靠产品化需要把 prompt 里的行为迁移到 code-owned contracts：source boundary、entity routing、answer contract、validator 和 trace。 |
| - [[workflow-as-knowledge-semantic-persistence | Workflow as Knowledge]]：workflow definition、workflow instance、context snapshot 和 dependency relation 本身应该成为可检查、可恢复、可复用的知识对象。 |
这三者对 llm-wiki 的共同启发是：wiki 不应只沉淀外部知识，也应沉淀“如何沉淀知识”的规则与证据；但这种自我优化要有边界，避免无人 cron 每天把规则改到漂移。
今天已经做的低风险优化
- 把 radar 产物显式写成 workflow evidence：本次 log 会记录 discovery path、deep judgment、入库/未入库原因、验证输出，而不是只列文件名。
- 强化页面合同：新建 source page 均包含“为什么重要 / 机制 / 与已有概念关系 / Hermes 启发 / 失败模式 / 深度判断 / 写入记录”。
- 更新核心概念页：已把 TTHE、Prompts-to-Contracts、Workflow-as-Knowledge 对 Harness-Engineering、Context-Engineering、Loop-Engineering 的启发写回对应概念页。
- 明确 derive/infer 边界：把 hash、文件存在、wikilink 检查、向量重建视为 derive；把深度判断、概念综合、晋升/拒绝理由视为 infer，并在本优化页中记录。
还应如何调整雷达
低风险、可直接采用
- 后续 AI radar 对 arXiv 新内容优先搜索
harness,workflow,context,coding agent,software engineering,tool policy,trace,memory,benchmark的组合，而不是围绕单个人或单一平台。 - 候选评分中增加一项：workflow-improvement potential（是否能改善 Hermes/llm-wiki 的流程本身）。
- 对“概念性论文”保持中等置信：如果 PDF 不可访问或没有实验/代码，仍可入库，但必须标明边界和失败模式。
需要谨慎、暂不自动执行
- 不自动改 cron prompt 或 CLI 工具的核心逻辑；今天只更新 wiki 内容与报告规则。若要把评分、候选 ledger 或 context manifest 固化成脚本，应单独测试。
- 不把每个候选都写成页面。TTHE 提醒轨迹有价值，但 Workflow as Knowledge 也提醒记录过载是风险；只有能改变长期 workflow 的候选才晋升。
今日未解问题
- 是否要为每日 radar 建立一个结构化
queries/或_meta/radar-ledger，记录候选评分表？这会提高可审计性，但可能增加噪音。 - 是否要为正式 source page 增加机器可检查的模板 lint？目前主要靠人工/agent 遵循。
- 是否要把 wiki-vquery 重建结果和新增页面清单写成固定 context manifest？这对复盘有帮助，但需要避免重复信息污染页面。
写入记录
- 2026-07-10 09:00 CST：新增当天 llm-wiki 自我优化文章，记录 TTHE、Prompts-to-Contracts、Workflow-as-Knowledge 对雷达流程、页面合同和 workflow 证据化的启发。