llm-wiki 自我优化 2026-08-26
llm-wiki 自我优化 2026-08-26
今天从内容更新中学到什么
今天的高价值主题不是更多新工具，而是让 agent workflow 的 claim 更可信的三层证据：
| 1. [[reliable-cua-statistical-computer-use-eval | reliable-cua]] 提醒：即使任务和 verifier 正确，统计汇总方式仍会影响结论。llm-wiki radar 未来若要说“某规则提升了质量”，不能只看一天或一个总数，而要按来源类型、任务类型、失败类型和重复 run 分层。 |
| 2. [[keidai-mcp-gateway-identity-control-plane | Keidai]] 提醒：工具接入越多，越需要 agent identity、credential boundary、approval ledger 和 call trace。llm-wiki 的无人 cron 当前多是知识写入，低风险；但若未来接入发布、数据库、生产 API，应先有 control-plane 合同。 |
| 3. [[rsihub-frozen-evaluator-agent-self-improvement | RSIHub]] 提醒：自我优化不能只靠每天新增反思规则。候选 prompt/skill 可以变，但 evaluator、archive、status stamping 和报告重算路径必须在候选之外。 |
已执行的低风险优化
- 今日正式页面没有新增薄概念页，而是创建 3 个 source 页，并把 durable insight 汇入既有 Agent-Benchmarks、MCP-Gateway-Runtime、Loop-Engineering。
- 将“统计可靠性 / frozen evaluator / identity boundary”纳入后续 radar 判断维度，避免继续只按 GitHub stars 或 README 新鲜度晋升。
- 在本页记录一个更具体的 llm-wiki radar micro-benchmark 方向：用小型 frozen suite 检查 orient、raw archive、promotion/rejection、index/log/write-record、claim receipt。
还应如何调整雷达
1. 候选 tape 增加统计/评测字段
后续遇到 benchmark / eval / harness 项目时，应优先记录：
- task hierarchy：domain / app / scenario / config / rollout；
- repeats：重复次数和随机种子；
- uncertainty：置信区间、bootstrap 或至少稳定性说明；
- verifier boundary：隐藏/独立 verifier 是否与 solver 隔离；
- reporting path：最终报告是否从 artifacts/archive 重算。
2. MCP / runtime 项目晋升门槛收紧
MCP gateway 类项目很多。后续不应因为“支持 MCP aggregation”就晋升；至少要有下列一项：identity、credential isolation、approval gate、policy-as-code、audit/call trace、tool namespace compression、session lifecycle 或 operator control plane。
3. 自我优化规则需要 rule-rent review
每周或每月应抽查最近新增的 radar 规则：它解决了哪个 failure mode？是否有文件/报告/拒绝理由证明它有用？是否增加了无效搜索、薄页面或 prompt 负担？没有证据的规则应合并、降级为建议或删除。
未解问题
- 是否值得为 llm-wiki radar 建一个真正的
radar-eval/小型 fixture？它需要写文件和可能调整 cron/脚本，范围较大，今天未自动执行。 - wiki 的
_index.mdAI 来源列表已经很长，继续按日期追加会让导航变重；可能需要单独的 2026 radar topic map 或按主题分组。 - GitHub API 在雷达中经常触发 rate limit；后续可考虑维护低频候选缓存，而不是每天重复宽搜索。
写入记录
- 2026-08-26 09:01 CST：新增当天自我优化文章，记录统计可靠性、MCP 身份控制面、frozen evaluator 对 llm-wiki radar 的优化启发。