ControlKeel
把团队的工程习惯转化为可执行的策略、审查关卡与持久化证据。
- Star 数
- ★ 11
- 最近更新
- 今天
- License
- NOASSERTION
- 主语言
- Elixir
- FA 评分
- 59/100 · 缺口较多
30 秒速览
- 可在哪里用
- 通用 · 跨平台CodexClaude Code（部分支持）
- 开始前需要
- 典型场景
- 已经使用 Codex、Claude、OpenCode 或其他受支持宿主的开发团队，希望在代理生成的变更进入主分支前执行统一策略检查。
- 主要局限
- 宿主能力并不统一：README 明确区分原生接入、较窄的 OAuth 托管 MCP、最小化 A2A 以及回退验证或代理路径，采用前需要核对具体宿主支持层级。
这个 Agent 能做什么，适合哪些场景？
ControlKeel 是面向 AI 编码代理的工程治理控制平面，用于比较预期交付与实际变更，并在风险工作进入主分支前实施检查。它提供 CLI、本地 stdio MCP 工具集、项目绑定、宿主接入与运行时导出，同时记录 findings、reviews、proof bundles、budgets、typed memory 和任务结果。其工作流先捕获范围、风险、预算、领域规则与人工评审偏好，再执行确定性验证和可选的咨询式审查，并在策略要求时加入人工批准。证据可以保存在本地，也可通过选择启用的云端遥测、workspace keys、cloud run packages 和回调路径参与同步。项目使用 Phoenix、Ecto 和 SQLite 开发，并通过 Burrito 与 GitHub Releases 提供单一二进制构建。
ControlKeel 通过 controlkeel setup 为当前代码库建立治理状态，再以 controlkeel attach <host> 接入受支持的编码代理宿主；如果只有 MCP 可用，则调用 ck_attach。controlkeel attach doctor 检查宿主接入，controlkeel provider doctor 检查 provider 配置，controlkeel status 显示状态，controlkeel findings 输出检查发现。运行时会读取已捕获的范围、风险、预算、domain pack 与人工偏好，对代理产出的变更执行确定性扫描和可选咨询式审查，根据策略决定是否阻断或要求人工批准，并持久化发现、审查、证明包、记忆、成本和任务结果。其可观测性流程还整理时间线、成本趋势、问题集群、评测候选、基准草案与晋升建议，使反复出现的问题能够转化为有回归证据支持的确定性检查。
- 已经使用 Codex、Claude、OpenCode 或其他受支持宿主的开发团队，希望在代理生成的变更进入主分支前执行统一策略检查。
- DevSecOps 团队需要把安全、合规或交付规则编码为可阻断高风险操作的治理关卡，并保留 findings 与 proof bundles。
- 频繁更换代理宿主的工程组织，希望通过项目绑定、MCP、宿主接入和运行时导出保存跨宿主的审查证据与 typed memory。
- 维护大量领域约定的团队，希望把反复向模型解释的评审偏好和交付习惯沉淀为可执行检查。
- 负责代理质量评估的团队，希望把运行轨迹和重复失败转化为特定 suite 与 subject 的回归证据和基准历史。
如何安装或部署这个 Agent？
可选择以下任一已记录的安装方式。源码没有给出 Node.js、Homebrew 或操作系统的最低版本，也没有说明本地首次运行必须提供哪些凭据。
使用 Homebrew：
brew tap aryaminus/controlkeel && brew install controlkeel使用 npm：
npm i -g @aryaminus/controlkeel使用发布页安装脚本：
curl -fsSL https://github.com/aryaminus/controlkeel/releases/latest/download/install.sh | shWindows PowerShell：
irm https://github.com/aryaminus/controlkeel/releases/latest/download/install.ps1 | iex若从源码开发，需要 Elixir 的 Mix 工具链；仓库给出的开发命令为：
mix setup
mix phx.server
mix test
mix precommit如何使用这个 Agent？
在需要治理的代码库目录中执行首次配置和宿主接入。下面使用 README 中明确给出的 OpenCode 示例；其他宿主应替换为其受支持的 host 名称。
controlkeel
controlkeel setup
controlkeel attach opencode
controlkeel attach doctor
controlkeel provider doctor
controlkeel status
controlkeel findings项目作用域默认只在当前仓库内写入宿主文件。仅当目标明确支持用户作用域时，才可使用 --scope user 写入用户配置；这不会把项目绑定或 proof 状态变成全局状态。接入或插件发生变化后需要重启宿主；若宿主要求 workspace trust、手动 provider 配置、重启或无法自动等待的计划审批，应先完成相应人工操作。如果环境只暴露 MCP，则为当前宿主调用 ck_attach。
这个 Agent 有哪些优点和局限？
- 同时提供 CLI、本地 stdio MCP、宿主接入和运行时导出，适合在不同代理宿主之间保留治理流程。
- 不仅生成建议，还能执行确定性策略检查、按风险阻断操作，并持久化 findings、reviews 和 proof bundles。
- 把 typed memory、成本、任务结果和评测证据纳入同一反馈循环，可将重复失败推进为有回归证据的检查。
- 公开的限定基准显示，在
host_comparison_v1的 12 个风险场景中，版本 0.3.45 的确定性验证捕获 12/12、阻断 9/12，且未消耗 provider tokens。
- 宿主能力并不统一：README 明确区分原生接入、较窄的 OAuth 托管 MCP、最小化 A2A 以及回退验证或代理路径，采用前需要核对具体宿主支持层级。
- 首次接入可能需要 workspace trust、手动 provider 配置以及宿主重启，无法保证完全无人值守。
- 公开基准只覆盖具名 suite、subject 和评分定义；确定性扫描结果不能视为模型驱动宿主在所有真实项目中的效果证明。
- 仓库许可证标记为
NOASSERTION，来源材料未提供可据以确认的授权条款，组织采用前需要单独核实。 - 双向云同步默认休眠，必须先配置；使用云端证据路径还会引入 workspace keys、遥测和运行时回调方面的部署决策。
这个 Agent 与同类方案有什么区别？
与只在 *.md 中告诉模型如何行动相比，ControlKeel 的定位是检查代理实际产出，并把规则落实为 typed memory、策略检查、发现记录和证明包。其公开的 host_comparison_v1 基准中，null_policy_baseline 捕获 0/12 个风险场景，而 controlkeel_validate 捕获 12/12；这一比较仅适用于该具名测试套件，不能外推为所有宿主或所有代码库的总体效果。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|
| ControlKeel 当前 | 59 · 缺口较多 | ★ 11 | 今天 | Elixir | Codex |
| Jev Review | 81 · 表现良好 | ★ 177 | 7 天前 | TypeScript | Codex · Claude Code |
| Alas 智能编程工作区 | 78 · 表现良好 | ★ 18 | 今天 | Swift | Codex · Claude Code |
| Bug Hunter | 79 · 表现良好 | ★ 514 | 1 个月前 | JavaScript | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示项目级附加默认仅写入仓库内部，用户级范围受到支持能力限制；工作流也使用明确的 contents/read、packages/write 或 contents/write 权限。README 要求高影响操作由人工批准，并在工作区信任、提供商配置、重启或计划审批时暂停；本地与可选云端路径及主要持久化数据类别亦有概述。扣分原因是这些控制大多属于说明性陈述，未提供实现代码；敏感数据处理仅明确提到日志脱敏和内置 GITHUB_TOKEN；第三方 Actions 仅固定到大版本标签而非提交摘要；安装脚本会直接通过 shell/PowerShell 执行；未说明卸载、状态回滚或恢复程序。仓库、作者账号和版权归属可辨认，但发布者身份未经企业注册表验证，因此不作超出文件证据的身份推断。
README 的产品循环、功能清单、安装流程和工作流所展示的构建、发布行为总体一致，且发布加版本流程在推送前复核 main 的提交。扣分原因是支持矩阵、依赖清单、实现和测试均未提供，无法静态确认依赖可获得性或宣称的运行行为；doctor/status/findings 命令表明存在诊断入口，但没有实际错误消息、降级策略或失败恢复示例。
材料明确面向使用多种编码代理的团队，覆盖本地治理、托管 MCP、无头运行、团队及自托管场景，并区分项目级、用户级、原生附加、导出和 MCP 回退路径。触发条件包括风险、意图和策略，且列出需要人工暂停的情形。扣分原因是主机支持的精确边界被委托给未提供的文档，未见规则匹配配置、误触发处理细节或不同环境的完整先决条件。
README 结构清楚，含快速开始、产品循环、当前功能、基准说明、文档地图和开发命令；三种主要安装渠道及 Windows 安装方式完整，Apache-2.0 正文也完整提供。命名在 CLI、MCP 和镜像中较一致，并有发布徽章及自动补丁版本和 CHANGELOG 更新流程。扣分原因是未提供 FAQ 内容、CHANGELOG、包清单或迁移政策；已知限制主要以范围说明和基准警告呈现；维护责任仅能关联到仓库账号和版权名，缺少明确支持渠道、响应承诺或经验证的组织身份。
输出模型包括 findings、reviews、proof bundles、budgets、typed memory、timelines 和 eval evidence，适合作为可审阅的治理产物。README 给出了相对于空策略基线的风险与良性场景结果，并报告验证延迟和零提供商 token，支持其潜在边际价值和部分成本收益。扣分原因是本次材料未包含基准定义、JSON 结果、实现或测试，无法核对这些数字；也未量化设置、维护、误报调查、云服务或人工审批成本。
README 将关键主张指向 benchmarks、claim matrix、支持矩阵和 API/CLI 参考，并明确区分确定性扫描证据与模型支持的代理主机证据，事实与推断边界较好。工作流也能交叉支持镜像发布和版本更新机制。扣分原因是所引用的验证文档、测试、导出数据和实现文件没有纳入材料，主要产品与基准主张因此只能单源追踪，无法进行充分的跨源佐证。
- 源码中未见：回滚或恢复路径运行前先备份，或在 git 分支、快照上操作，确保改动可以撤销。
- 快速安装命令会把远程 shell 或 PowerShell 脚本直接交给解释器；企业使用前应固定版本并审阅脚本。
- 未提供回滚、卸载或状态恢复说明；在让工具写入主机配置、策略状态或云端记录前，应先建立备份和恢复步骤。
- 基准数字及“确定性”“强制执行”等主张在本材料中缺少测试、实现和导出结果支持，不应视为独立复现。
- 第三方 GitHub Actions 使用 v3/v4/v6 标签而非不可变提交摘要，供应链策略严格的环境应额外固定和审查。
- 云同步、遥测、工作区密钥和 Webhook 的具体数据字段、保留期、目的地及删除机制未展示；启用前需另行核实。
常见问题
本地使用是否一定会产生模型调用费用？
它会在仓库外写入文件吗？
--scope user 仅适用于明确支持用户作用域的目标，并会写入用户配置，但不会把项目绑定或 proof 状态全局化。必须使用云服务吗？
接入失败时先检查什么？
controlkeel attach doctor、controlkeel provider doctor 和 controlkeel status。还应确认项目已被宿主信任，并在 attach 或插件变化后重启宿主。