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

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

今天学到的雷达规则

今天的高价值来源集中在三个可复用字段：权限边界、监督通道、harness 归因。AIPermission / GATRA 说明 MCP/tool runtime 不应只记录“有什么工具”，还应记录谁在用、token 作用域、approval、trajectory cap、policy verdict 和 audit trail。Baseerat / LongPuzzleBench / MobileController 说明 computer-use 评测不应只记录最终成功，还应记录 observation channel、verified state、wait-stable、action receipt 和状态漂移。Harness Arena 则说明 agent 结果不能只归因于模型，必须记录 harness version 和 blind review。

已执行的低风险优化

1. 今日正式 source 页全部补充“深度判断”和“写入记录”，避免薄摘要进入 wiki。
2. _index 今日新增项按主题覆盖 MCP runtime、computer-use verified state、long-horizon GUI、harness benchmark，避免雷达再次收敛成 Karpathy 或单一工具追踪。
3. 概念页补充方向选择为 Agent-Benchmarks、Harness-Engineering、MCP-Gateway-Runtime、Loop-Engineering 四个枢纽，减少新 source 页孤岛化。

建议加入后续雷达评分字段

• identity_boundary：是否说明 agent/job/user identity 如何绑定。
• credential_boundary：凭据是否留在 gateway/connector，还是暴露给 agent。
• trajectory_budget：是否支持跨调用累计预算/风险/速率。
• observation_channel：agent、auditor、human 分别能看到 screenshot/DOM/a11y/tree/state 中哪些通道。
• verified_state_path：最终状态由谁读取，是否独立于 agent narration。
• harness_attribution：同一模型下 harness 差异是否可测。

对 llm-wiki / Hermes 的启发

未来如果给 Hermes 接入 SSH、数据库、Kubernetes、浏览器或手机模拟器，默认不应是“把工具交给模型”，而应先有 gateway policy、短期 capability、approval/audit 和 action receipt。这连接到 MCP-Gateway-Runtime、Harness-Engineering、Loop-Engineering 与 Agent-Benchmarks 四个枢纽：权限边界决定能不能安全行动，harness 合同决定行动如何发生，loop receipt 决定状态如何推进，benchmark 归因决定改进是否可信。每日知识雷达自身也可按这个思路演进：每次 deep ingest 都输出 candidate tape、raw hash、source page、概念页补充、index/log/reindex 证据，减少“报告说入库但不可复核”的风险。

未解问题

• 当前 wiki 仍主要靠自然语言页面维护雷达规则；是否需要一个机器可读 radar-gates.yaml 来记录评分字段和晋升门槛。
• wiki-vquery reindex 是否应只在 deep ingest 成功后增量执行，还是每日固定重建以避免 metadata drift。
• computer-use 主题是否需要从 Loop-Engineering 中拆出独立概念页，专门沉淀 observation/state/receipt/failure taxonomy。

写入记录

• 2026-08-28 09:00 CST：新增当天自我优化文章，总结权限边界、监督通道、harness 归因三类雷达字段，并记录已执行与建议优化。