Keel

**你的 agent 正在给自己的作业打分。Keel 负责测量其中的程度。** ``` npx skills add broomva/keel ``` 船的龙骨（Keel）是衡量其他一切事物的基准线——而 *平稳的龙骨（even keel）*是一种稳定属性，而非装饰品。 Keel 只测量一件事： 在 agent 维护的代码库中，大多数验证都没能做到这一点。一个 LLM 审查 另一个 LLM 写的内容。一份文档根据 另一份文档进行验证。一个状态字段显示为 “passed”，因为有什么东西把它设置成了“passed”。流水线（pipeline）显示为通过（绿色），但实际上 什么都没有被验证。 ## 它的功能 Keel 会遍历目标的验证边缘——CI 步骤、测试目标、审查 门禁、部署条件、集成信号——并对每一个进行分类： | 类别 | 信号的产出者是… | |---|---| | `anchored` | 在 actor 的写入边界之外——进程退出码、类型检查器、已结算的支付、客户操作 | | `self_referential` | 在写入边界之内——LLM 对输出的评判、文档与文档的核对、自行设置的状态 | | `unknown` | 无法追踪。**判定为失败（Fails closed）。** | | `not_a_check` | 什么都不是——该节点未断言任何属性。不计入比例中，这也是为什么它是唯一值得被纳入购物清单的类别 | **Grounding ratio（基础比例）** = `anchored / (anchored + self_referential + unknown)`。 `unknown` 会被算作扣分项，这是故意的。缺乏依赖的证据 并不代表独立的证据。 ## 每次运行都会变得更便宜 新颖的形状由 agent 进行判断。重复出现的形状会被固化为 **probe（探针）**——小巧、可审查的脚本——这样下一次出现时就不需要 消耗任何模型调用了。probe 库本身就是代码，这意味着它是可 diff、可测试且 可拒绝的，并且它会在每个运行 Keel 的人身上产生复利效应。 Probe 可以**弃权（abstain）**。它们绝不能返回 `unknown`。一个不确定的 probe 会回落给 agent，因此一个懒惰的 probe 会降级为“询问”，而 不是“看起来没问题”。 ## 并且它会自我审计 Probe 会发生偏移。Keel 会以 agent 的方式对 probe 分类过的一部分节点样本重新进行决策，在此过程中隐藏缓存的判定结果，并淘汰那些不一致的 probe。 该库的一致率就是 Keel 自身的反向指标——一个在测量基础牢固度的同时，却 拒绝测量自身基础牢固度的工具，将会犯下 它存在正是为了去发现的那种完全相同的错误。 ## 从数字到路径 一个无人能采取行动的比例只是一份成绩单。因此 `keel route` 会读取报告， 并且对于每个未锚定的检查，提出一条通往锚定信号的路径，且该信号**已经 存在于同一个图中**： 其背后的规则是：**独立性无法凭空制造，但可以被 路由。** Keel 绝不会发明锚点。它只是将一个不断言任何内容的检查连接到一个 你已经拥有的产出者上——当不存在这样的产出者时，它会 直接说明，而不是进行猜测。 路由永远不会改变这个比例。提议并不等同于改变；只有当人类应用了变更 并且 Keel 从目标重新进行测量时，这个数字才会改变。提议 更改你的图的事物，绝不能同时也是对其进行评分的事物， 否则这个分数将失去任何意义——因此这种分离是由测试 强制执行的，而不是由口头承诺强制执行的。 ## 模式 | | | |---|---| | `keel measure` | 遍历验证边缘，进行分类，并报告比例 | | `keel route` | 为未锚定的检查提出通往你已有锚点的路由建议 | | `keel audit` | 对缓存的判定样本重新进行决策；报告一致率 | `keel construct`（反向指标配对、仲裁、审计循环）和 `keel apply` 已经有了规范，但尚未构建——请参阅 [`docs/plans/constructive-grounding-layer.md`](docs/plans/constructive-grounding-layer.md)。 ## 使用方法 Keel 运行在**你的 agent 框架内**——Claude Code、Codex、Cursor，或者 任何支持读取 [Agent Skills](https://agentskills.io) 的工具。它不会 重新实现一套框架，也没有守护进程或托管服务。 ``` npx skills add broomva/keel # requires the skills CLI; Bun for local dev ``` 然后用通俗易懂的语言将你的 agent 指向一个目标： ``` measure the grounding of this repo with keel ``` Agent 会收集验证边缘，对每一个进行分类，并写入一个 `report.json`，以及一个独立的 HTML 报告，该报告可以通过 `file://` 打开，并且 在通过电子邮件发送后依然能够正常访问。之后可以要求它执行 `route`，从而为每个 未锚定的检查获取一份提议。 没有任何数据会被传输到任何地方。probe 无法处理的分类过程将 在你框架已经在运行的任何模型中发生，并遵循你现有的 提供商条款。 ## 实事求是的范围界定 Keel 测量的是验证的*形状*，而不是其质量。一个代码库可以 100% 被锚定，但测试却很糟糕。锚定说明信号来自外部；但它 并不说明这个信号就足够了。 以及一个根本的局限，在产品中就明确指出，而不是让你日后才发现：**测试的 执行是锚定的；但其断言的预言机（oracle）可能并非如此。** 当同一个 agent 编写了实现和断言时，runtime 会诚实地判定 通过/失败——但规范是在写入边界内编写的， 两者可能会一起发生偏移并保持绿灯。Keel 对执行轴进行分类，并 明确指出这个局限，而不是悄悄地将其升级为证明。 ## 贡献 最有价值的贡献是**一个 probe**——一个可审查的小脚本，它 能在不调用模型的情况下对重复出现的形状进行分类，从而使 Keel 对 所有人来说都变得更便宜。紧随其后的是：告诉我们 Keel 出现了**错误**的分类。这 是该项目能收到的最有用的 Bug 报告。 | | | |---|---| | [CONTRIBUTING.md](CONTRIBUTING.md) | 环境设置、冻结的 schema 规则、如何编写 probe | | [SECURITY.md](SECURITY.md) | 私下披露，以及 Keel 会在你的机器上执行什么操作 | | [Misclassification issue](https://github.com/broomva/keel/issues/new?template=misclassification.yml) | Keel 分配了错误的类别 | | [Design system](skills/keel/design/README.md) | token、组件和品牌规则 | ## 许可证 MIT — 详见 [LICENSE](LICENSE)。

标签：AI智能体, Homebrew安装, LLM评估, Ollama, 后端开发, 开源框架, 持续集成