ForgeOS — skill intelligence and trust control plane

ForgeOS — skill intelligence and trust control plane

核心判断

ForgeOS 值得入库，因为它把 agent 可靠性明确拆成六个运行时问题：目标是什么、该用哪个 technique、最小上下文是什么、哪些步骤必须确定性执行、什么证据足以接受完成、失败后能否恢复和审计。这个框架高度契合用户的 Hermes/llm-wiki 实践：与其不断增加 prompt 和工具，不如建立 skill routing、context governance、deterministic step、evidence gate 与 recovery ledger。

机制 / 一阶原理

ForgeOS README 将流程描述为：confirmed intent → outcome + technique retrieval → hard policy / anti-trigger filters → minimum RoutePlan DAG → isolated ContextPack per work unit → deterministic / agent / reflection execution graph → anchored outputs + coverage ledger。它的机制重点是 把 agent work 拆成可路由、可隔离、可验证的工作单元。

第一性原理是：LLM 擅长生成和推理，但不擅长天然遵守边界、选择最小上下文、证明完成或跨失败恢复。因此 harness/control plane 应把这些高风险环节从“模型自觉”变成运行时结构：policy filter 决定不能做什么，ContextPack 决定能看什么，deterministic steps 决定哪些不能交给模型，ledger 决定完成是否有证据。

与现有 wiki 的关系

• 对 External-Agent-Skills-Design-Patterns：ForgeOS 是“skill 不是 prompt，而是 technique + route + context + evidence contract”的强例子。
• 对 Harness-Engineering：它把 harness 从工具集合推进到 trust control plane，尤其强调 deterministic / agent / reflection 分层。
• 对 Context-Engineering：isolated ContextPack 支持 purpose-shaped context，避免长期 wiki 或大 repo 的上下文污染。

对 Hermes / llm-wiki 的启发

1. 每次 deep ingest 可显式写一个 mini RoutePlan：发现 → raw → 晋升判断 → 页面更新 → link/index/log → reindex/验证。
2. wiki 页面可以增加轻量 evidence contract：哪些段落来自 raw，哪些是 synthesis，哪些仍是 open question。
3. Skills 应逐步有 manifest：触发、输入、风险等级、需要的 context pack、deterministic checks、完成证据。

失败模式 / 未解问题

• ForgeOS README 目标很大，实际可用性需通过安装、样例任务和 release-gated tests 验证。
• “128 techniques / 60 MCP tools” 这类广覆盖可能带来维护和选择噪音；如果 route retrieval 不准，会退化为复杂工具堆。
• Control plane 自身会成为关键依赖，需要版本、回归测试和安全审查。

写入记录

• 2026-08-01 09:06 CST：从 GitHub README 深度入库 ForgeOS，提炼 skill intelligence、ContextPack、RoutePlan DAG 与 evidence ledger 对 Hermes skill/runtime 的启发。