# Keel：将编码代理转化为工作负责人的多代理工作流框架

> Keel是一个项目无关的多代理工作流骨架，能够将GitHub Issue从待办事项驱动至合并完成，实现从需求理解、分支创建、代码实现、CI等待、代码审查、测试验证到安全合并的端到端自动化。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-09T14:45:10.000Z
- 最近活动: 2026-06-09T14:53:10.686Z
- 热度: 156.9
- 关键词: keel, 多代理, 工作流, GitHub, 自动化, 代码审查, 合并策略, CI/CD, LangGraph, RAG, DevOps
- 页面链接: https://www.zingnex.cn/forum/thread/keel
- Canonical: https://www.zingnex.cn/forum/thread/keel
- Markdown 来源: ingested_event

---

## 原作者与来源

- **原作者/维护者**: berkayturanci
- **来源平台**: GitHub
- **原始标题**: keel
- **原始链接**: https://github.com/berkayturanci/keel
- **发布时间**: 2026-06-09
- **许可证**: Apache-2.0

---

## 背景与动机

在现代软件开发中，编码代理（Coding Agents）如OpenHands、SWE-agent、Copilot coding agent和Devin等工具已经能够自动创建或更新Pull Request。然而，这些工具通常止步于PR创建阶段，缺乏对后续流程的管控——包括代码审查、合并策略、质量门禁和学习沉淀。

与此同时，PR审查工具（如CodeRabbit、Qodo/PR-Agent、Greptile）专注于审查已有PR，合并队列工具（如GitHub Merge Queue、Mergify、Graphite）专注于序列化测试后的PR合并，但这两类工具都无法覆盖从Issue创建到PR生成的完整生命周期。

Keel的诞生正是为了填补这一空白：它提供了一个**工作所有权骨架（workflow backbone）**，将编码代理、审查工具、质量门禁和合并策略整合到一个统一的生命周期中。

---

## 核心理念：三层架构

Keel采用清晰的三层架构设计，确保核心稳定性与项目灵活性之间的平衡：

```
Layer 3  EXTENSIONS   项目拥有的Lego组件，仅通过ADD-ONLY方式插入命名槽位
Layer 2  CONFIG       project.yaml — 每个项目的配置值（分支、构建命令、全局模式、代理等）
Layer 1  BACKBONE     keel-core — 固定的有序步骤机 + 不变量（本包）
```

这种设计的精妙之处在于：**只有keel-core的维护者可以修改骨架（Layer 1），而项目团队只能操作Layer 2和Layer 3**。这从根本上消除了因核心代码复制导致的漂移和覆盖类Bug。

---

## 骨架详解：13步工作流

Keel的骨架定义了一个完整的Issue到合并（issue-to-merge）工作流，包含13个有序步骤：

| 步骤 | 名称 | 主要钩子 | 执行者 |
|------|------|----------|--------|
| s0 | config | `after:config` | - |
| s1 | select | `before:select`, `select`, `after:select` | - |
| s2 | branch | `before:branch`, `after:branch` | - |
| s3 | guard | `guard` | - |
| s4 | implement | `before:implement`, `after-implement` | **代理** |
| s5 | classify | `classify`, `after:classify` | **代理** |
| s6 | ci | `before:ci`, `after:ci` | - |
| s7 | review | `reviewers`, `after:review` | **代理** |
| s8 | test | `tester`, `test`, `after:test` | - |
| s9 | fixloop | `before:fixloop`, `fixloop`, `after:fixloop` | - |
| s10 | merge | `pre-merge`, `after:merge` | - |
| s11 | capture | `capture`, `post-merge` | - |
| s12 | close | `before:close`, `on-close`, `after:close` | - |

### 关键步骤解析

**s4 - implement（实现阶段）**
这是编码代理真正介入的步骤。代理接收Issue描述，创建分支，实现代码变更。Keel通过`before:implement`和`after:implement`钩子允许项目插入自定义逻辑，如代码风格检查或依赖分析。

**s5 - classify（分类阶段）**
代理对变更进行风险分级，决定后续审查策略。高风险变更可能需要更多审查者或更严格的测试。

**s7 - review（审查阶段）**
Keel支持多代理审查模式。通过集成[ai-jury](https://github.com/berkayturanci/ai-jury)多代理审查器，可以在PR上运行多个审查代理，实现类似人类代码审查的协作效果。

**s8 - test（测试阶段）**
项目可以定义自己的测试门禁，如构建检查、lint检查、设计一致性检查等。

**s10 - merge（合并阶段）**
Keel实现了多项安全合并策略：
- **时区感知的夜间禁止合并窗口**：避免在非工作时间自动合并
- **mkdir合并锁**：防止并发合并冲突
- **风险等级→审查者数量映射**：高风险变更需要更多审查者批准
- **热修复绕过**：紧急修复可以绕过部分门禁，但会留下审计日志

**s11 - capture（捕获阶段）**
这是Keel的学习沉淀机制。通过`compound-learning`标记，系统记录PR的学习状态（applied/deferred/skipped），支持创建学习笔记、仅标记或延迟处理。

---

## 与现有工具的比较

Keel在工具生态中占据独特位置：

| 类别 | 代表工具 | 通常止步于 | Keel的增量价值 |
|------|----------|------------|----------------|
| 编码代理 | OpenHands, SWE-agent, Copilot, Devin | 创建或更新PR | 需求接收、审查门禁、合并策略、收尾、学习捕获 |
| PR审查工具 | CodeRabbit, Qodo/PR-Agent, Greptile | 审查已有PR | 实现循环、测试、合并锁/窗口、计划学习捕获 |
| 合并队列 | GitHub Merge Queue, Mergify, Graphite | 序列化测试后的PR | Issue所有权（在PR存在之前） |

Keel不是要取代这些工具，而是作为**工作所有权骨架**，将它们整合到一个统一的生命周期中。

---

## 安装与快速开始

Keel是一个Python（≥3.11）包，仅依赖PyYAML：

```bash
pip install keel-workflow
```

快速开始命令：

```bash
keel setup --root .                           # 为项目添加keel配置和适配器
keel validate projects/example.yaml             # 验证配置
keel plan projects/example.yaml               # 显示项目的骨架计划
```

`keel plan`命令会渲染固定骨架与项目特定的门禁/扩展的组合结果，展示实际执行的步骤：

```
keel plan — example-flutter
  base_branch: main   core_version: ^1.0
  backbone:
     s4  implement  [agent]
     ...
     s8  test
           - gate: build
           - gate: lint
           - gate: design-parity
    s10  merge
           - gate: design-parity-gate
```

---

## 17个内置命令

Keel提供了17个开箱即用的命令，覆盖从日常开发到长期维护的各种场景：

- **核心命令**: `ship`（旗舰命令）、`ship-v2`、`implement`
- **审查相关**: `review-cycle`、`review-all-day`、`pr-loop`
- **回归与审计**: `regression`、`triage`、`ci-check`、`coverage`、`deps-audit`、`flake-audit`
- **工作流管理**: `morning`、`work-block`、`overnight`、`wrap`
- **维护**: `stale-prs`

这些命令通过Claude Code插件或技能适配器暴露，支持在Claude、Codex、Antigravity、Gemini等多种代理中使用。

---

## 自举与质量保证

Keel采用**自举（dogfooding）**模式驱动自身开发。项目使用`.keel/project.yaml`配置，基于最新的`^1.0`核心合约（Python + `make test` + `make lint`门禁），每次推送都会运行keel对自身核心的验证。

核心包（`config`, `model`, `extensions`, `findings`, `gates`, `orchestrator`, `cli`）保持**100%行覆盖率和分支覆盖率**，CI中的覆盖率门禁（`fail_under = 100`）确保质量不降级。

---

## 实际应用场景

**场景一：自动化Issue处理**
开发者创建Issue后，Keel自动评估Issue准备度，创建分支，调用编码代理实现功能，运行测试，请求审查，最终合并并关闭Issue——全程无需人工干预。

**场景二：夜间回归测试**
使用`overnight`命令，Keel可以在夜间自动运行回归测试，检查依赖更新，生成覆盖率报告，并在发现问题时创建新的Issue。

**场景三：多代理代码审查**
通过集成ai-jury，Keel可以在PR上运行多个审查代理，每个代理从不同角度（安全性、性能、可维护性）审查代码，汇总结果后提供给人类开发者参考。

---

## 总结与展望

Keel代表了软件工程自动化的下一阶段演进。v1版本专注于单个代理端到端拥有工作，而长期愿景是**自治软件团队**：多个代理在人工负责人的监督下，自主创建、认领、审查、交接和交付工作。

对于希望提升开发效率、减少重复劳动的团队，Keel提供了一个结构化的、可扩展的框架。它不是要取代开发者，而是将开发者从繁琐的流程管理中解放出来，让他们专注于真正需要人类判断的工作——产品权衡、凭证管理、审批决策和模糊范围界定。

随着AI代理能力的不断增强，像Keel这样的工作流骨架将成为连接人类意图与机器执行的关键基础设施，推动软件工程向更高层次的自动化迈进。