llm-wiki 自我优化 2026-08-08

llm-wiki 自我优化 2026-08-08

今天的雷达主题不是 Karpathy，而是 让 AI 知识雷达自身更像可评测、可回放、可治理的 agent workflow。Aperture、Claimproof、Everdict、Active-SWE 和 Data Eng Bench 分别从日报选择、最终声明、评测平台、主动发现和领域现实性五个角度暴露了当前 llm-wiki 可以改进的地方。

今天学到什么

1. 雷达需要候选 tape，而不只是最终日报

aperture-agent-report-radar-skill 的关键启发是：日报质量不只取决于最终 synthesis，也取决于候选如何进入/离开视野。当前 llm-wiki log 会记录“未入库原因”，但还没有保存结构化候选 tape。更好的最小形态是：每次 cron 保存 query、candidate、score、decision、reason、source-health。

2. 最终报告也需要 evidence gate

claimproof-evidence-gated-agent-claims 提醒：agent 的 final answer 是会影响用户信任和下一步行动的输出，因此“已保存 raw / 已创建页面 / 已更新 index / 已重建向量”都应绑定 receipt。今天的执行已把文件路径列入 log/报告，并在结束前用脚本检查新文件、写入记录和 wikilink。

3. llm-wiki 工作流应逐步变成本地 eval cell

everdict-harness-agnostic-agent-eval-runtime 的价值不在于必须部署平台，而在于评测拆分：harness、environment、driver、grader、backend。对 llm-wiki，每日雷达的 micro-eval 可以先做结构检查：orient 是否完成、raw 是否有 sha256、source page 是否有深度五要素、concept 是否更新、_index/log 是否更新、未入库理由是否明确。

4. 发现型任务要有三阶段证据链

active-swe-proactive-bug-fixing-benchmark 把 proactive discovery 拆成发现、验证、judge。llm-wiki 雷达也应类似：发现候选只是第一步；判断它补充哪个概念或 workflow 是第二步；通过页面结构、wikilinks、写入记录和 index/log receipt 是第三步。

5. 领域 benchmark 要进入轮换

data-eng-bench-domain-coding-agent-benchmark 表明通用 coding benchmark 不足以代表真实专业工作。后续 AI 雷达应继续轮换数据工程、DevOps、安全、支付、工业运维、视觉/产品设计等领域，避免只沉淀通用 harness/skill 页面。

今天已做的低风险优化

1. 新增 5 个 source page，并在正文写入深度判断与「写入记录」。
2. 更新 Harness-Engineering、Context-Engineering、Agent-Benchmarks、External-Agent-Skills-Design-Patterns，把候选 tape、final-claim receipt、本地 eval cell、proactive/domain benchmark 纳入已有概念。
3. 在本优化文章中记录今天的 context manifest：发现路径、深挖来源、拒绝类别、仍需改进项。

建议但暂未自动执行的较大改动

1. 新增 radar candidate tape 文件：例如 wiki/ai/radar/2026-08-08-candidates.jsonl。这会引入新目录和维护协议，建议先确认长期格式后再固化。
2. 新增 llm-wiki radar checker 脚本：检查 raw sha256、写入记录、index/log、wikilink、最终报告 receipt。适合后续维护任务集中实现。
3. 调整 radar profile：每周至少一天偏向论文/arXiv/benchmark，至少一天偏向工程工具/skills，避免连续只看 GitHub 新 repo。

写入记录

• 2026-08-08 09:00 CST：新增当天自我优化文章，记录候选 tape、final-claim gate、本地 eval cell、主动发现和领域 benchmark 对 llm-wiki 雷达流程的优化启发。