ControlKeel — governed coding-agent control plane

wiki/ai/sources/controlkeel-governed-agent-control-plane.md

分类：ai / sources · 更新：2026-08-13 09:05

ControlKeel — governed coding-agent control plane

深度判断

结论：晋升为正式 source page。 ControlKeel 值得入库，因为它把团队“怎么工作”的隐性规则变成 typed memory、policy checks、proof bundles、findings、budgets 和 evals，而不是继续依赖一份 agent-facing markdown。对用户的长期目标很相关：Hermes/llm-wiki 已经在把知识沉淀为 markdown，但下一步需要把高频 workflow 的规则变成可验证、可回归、可晋升的控制平面。

机制 / 一阶原理

它的 product loop 是 capture intent/policy → validate agent output → gate only when needed → persist evidence → improve with evals。README 的核心机制是把 intended delivery 与 actual delivery 对比，用 deterministic checks 和 advisory review 产生 findings，并把 recurring behavior 通过 human-gated deterministic promotion path 晋升为 checks、APIs、CLIs 或 workflows。

与已有 wiki 概念的关系

它与 Harness-Engineering 的 runtime/control-plane 方向、Context-Engineering 的“少 rediscovery，多 typed memory”、Agent-Benchmarks 的 with/without 本地 eval、External-Agent-Skills-Design-Patterns 的 skill lifecycle 都高度重叠。相比 ProdAgent 更偏生产框架，ControlKeel 更像日常 coding-agent 工作方式治理层。

对 Hermes / llm-wiki / agentic workflows 的启发

对 Hermes 的启发：每日 radar 可把重复失败/拒绝理由晋升为 typed radar policy，例如“高星但要求关闭防病毒 → supply-chain HOLD”、“只有 README 无行为证据 → source note not install”、“arXiv 429 → GitHub/官方博客 fallback”。但这些规则应有最小回归检查，避免今天的局部经验变成明天的过拟合。

失败模式、边界条件与未解问题

边界条件：它的 benchmark 证据被 README 明确限定在 named suite、subject 和 scoring definition，不应泛化为普遍质量保证；控制面若过度学习个人 taste，可能压制探索；云/团队功能涉及更多权限和同步边界，适合先作为设计模式学习。

来源与证据

GitHub: https://github.com/aryaminus/controlkeel
Stars at ingest: 11
Last pushed at ingest: 2026-08-12T18:10:25Z
Raw archive: controlkeel-governed-agent-control-plane-readme-2026-08-13

写入记录

2026-08-13 09:00 CST：从 GitHub README 深度入库，新增 source page、raw archive，并关联 harness/context/benchmark/skill 设计模式。