返回博客列表

37万星的开源项目这样管 PR：拆解 openclaw 的自动化审查流水线 Caclawphony

2026-05-29T22:00:00+08:00
openclawSymphonyCodexPR Review自动化AI AgentElixir

37万星的开源项目这样管 PR：拆解 openclaw 的自动化审查流水线 Caclawphony

openclaw 在 GitHub 上有 37.5 万颗星、7.8 万个 fork。每天涌入大量 PR，靠人工逐一审查根本不现实。他们的解决方案是一个叫 Caclawphony 的内部工具——基于 OpenAI 的 Symphony 框架，用 Elixir 写的一条全自动 PR 审查、修复、合并流水线。

本文拆解它的架构设计、流水线状态机、以及人类检查点的精妙平衡。

本文提纲

  1. 什么是 Caclawphony
  2. 流水线状态机：8 个阶段，3 个人类检查点
  3. Symphony：调度引擎的核心抽象
  4. WORKFLOW.md：把策略版本化
  5. 关键设计决策
  6. 对开源维护者的启发

什么是 Caclawphony

Caclawphony 是 openclaw 团队为自己的主仓库 openclaw/openclaw 搭建的 PR 自动化审查系统。它不是通用框架，而是一个维护者工具，专门处理 openclaw 仓库的 PR 生命周期。

整个系统架在三个组件上：

  • Linear：项目管理看板，每个 PR 对应一个 Issue
  • Symphony（OpenAI 开源）：调度框架，轮询 Linear 并分派 Codex Agent
  • Codex：OpenAI 的编程 Agent，执行具体的审查、修复、合并操作

用一句话概括：把 PR 变成 Linear Issue，让 Agent 跑完整个审查流程，人类只在关键节点介入。

流水线状态机：8 个阶段，3 个人类检查点

Caclawphony 的核心是一个精心设计的状态机。一个 PR 从进入到关闭，要经过这些状态：

Triage → Todo → Review → Review Complete → Prepare → Prepare Complete → Merge → Done

每个状态做什么：

状态 谁执行 做什么
Triage Agent 轻量级分析：PR 聚类检测、重复识别、基本健康检查。不需要 clone 仓库
Todo 🧑 人类 维护者审查 triage 结果，决定下一步
Review Agent 完整的 PR 审查，生成结构化审查报告
Review Complete 🧑 人类 维护者审查 Agent 的审查结果，决定路由
Prepare Agent Rebase、修复 BLOCKER/IMPORTANT 级问题、跑测试、推送（同时只允许 1 个）
Prepare Complete 🧑 人类 维护者确认修复结果
Merge Agent 确定性 squash merge，带署名和 co-author 信息
Done 终态 PR 已合并或关闭

还有三条旁路：

  • Request Changes：Agent 在 GitHub 上发起 request-changes，PR 退回给作者
  • Closure：Agent 关闭 PR（重复、过期、无效），附带结构化评论
  • Duplicate：标记为重复 PR，附带评估说明哪个是主 PR
graph LR
    A[Triage] -->|Agent| B[Todo]
    B -->|Human gate| C[Review]
    C -->|Agent| D[Review Complete]
    D -->|Human gate| E[Prepare]
    E -->|Agent| F[Prepare Complete]
    F -->|Human gate| G[Merge]
    G -->|Agent| H[Done]
    D -->|Route| I[Request Changes]
    D -->|Route| J[Closure]
    I --> K[Backlog]

3 个人类检查点（Human Gate）的设计非常克制：不是每一步都让人类签字，而是在 Agent 做完高风险操作后、下一步不可逆之前才介入。这样既保证了安全，又不让维护者变成瓶颈。

Symphony：调度引擎的核心抽象

Symphony（2.47万星，Elixir 写的，Apache 2.0 协议）是 OpenAI 开源的 Agent 调度框架。它的核心思路是：把项目管理看板变成 Agent 调度系统。

Symphony 不关心你的 Agent 具体做什么，它只负责：

  1. 轮询：每隔 30 秒扫描 Linear 看板，找出处于活跃状态的 Issue
  2. 隔离：为每个 Issue 创建独立的工作空间（workspace）
  3. 调度：按配置的并发限制分派 Codex Agent
  4. 恢复：Agent 崩溃后自动重试，支持指数退避
  5. 收敛：Issue 状态变了，立即停掉对应的 Agent 运行

系统架构分 6 层：

graph TB
    subgraph "Symphony Architecture"
        L[Policy Layer - WORKFLOW.md]
        C[Config Layer - typed getters]
        O[Coordination Layer - orchestrator]
        E[Execution Layer - workspace + agent]
        I[Integration Layer - Linear adapter]
        V[Observability Layer - logs]
    end
    L --> C --> O --> E
    O --> I
    O --> V

最关键的设计是：Workflow 策略存放在仓库的 WORKFLOW.md 文件里，跟着代码一起版本化管理。团队改 Agent 行为不需要改调度器代码，改 Markdown 就行。

WORKFLOW.md：把策略版本化

Caclawphony 的 WORKFLOW.md 是整个系统的灵魂。它用 YAML frontmatter 定义运行时配置，Markdown body 定义 Agent prompt。举几个关键配置：

并发控制：

agent:
  max_concurrent_agents: 4          # 最多 4 个 Agent 并行
  max_concurrent_agents_by_state:
    prepare: 1                       # Prepare 状态同时只跑 1 个（资源限制）
    test: 1                          # Test 同样限 1 个

Workspace Hook（PR 进入工作空间后执行）：

hooks:
  after_create: |
    # Triage 阶段轻量级，不需要 clone 仓库
    if [ "$SYMPHONY_ISSUE_STATE" = "Triage" ]; then
      copy_skills
      echo "Triage enrichment -- skipping repo clone"
      exit 0
    fi
    # 其他阶段才 clone 仓库 + checkout PR 分支
    git clone /path/to/openclaw .
    PR_NUM=$(echo "$SYMPHONY_ISSUE_TITLE" | grep -oE '#[0-9]+' | head -1 | tr -d '#')
    gh pr checkout "$PR_NUM" --force

人类检查点（Agent 完成后暂停，通知维护者）：

gates:
  review_complete:
    assignee: "maintainer-user-id"
    notify: true
  prepare_complete:
    assignee: "maintainer-user-id"
    notify: true

通知（通过 Telegram 推送检查点提醒）：

notifications:
  telegram:
    bot_token: $TELEGRAM_BOT_TOKEN
    chat_id: $TELEGRAM_CHAT_ID
  gate_states: [Review Complete, Prepare Complete, Pre-merge]

这种"配置即代码"的思路意味着：审查策略的每一次变更都有 git 记录，可以 review、回滚、A/B 测试。

关键设计决策

GitHub 是审查状态的唯一真相源

Triage Agent 检查 gh pr reviews 来判断是否已有 CHANGES_REQUESTED 审查，以及作者是否推送了新 commit。这避免了 Agent 重复审查已经解决的问题。

Agent 不主动发言

一个硬性规则：Agent 只有在 Request Changes 状态下才被允许在 GitHub 上评论。其他所有状态，Agent 只在 Linear Issue 里工作。这是对开源社区的基本尊重——维护者的名字挂在项目上，不能让 Agent 乱说话。

重复 PR 要写评估报告

当一个 PR 被标记为重复时，Agent 不会简单关闭了事，而是生成一条结构化评论，解释：

  • 为什么判定为重复
  • 主 PR 是哪个，优势在哪
  • 被关闭的 PR 有哪些独特修复可能丢失

这种细致程度，比很多人类维护者做得都好。

聚类检测用多信号搜索

Triage 阶段的聚类不是简单标题匹配，而是综合多个信号：影响范围、关键词、修改文件、关联 Issue。Agent 会运行 pr-plan --live 刷新 PR 缓存，再用 pr-cluster 逐 PR 搜索。

对开源维护者的启发

Caclawphony 给了一个可复用的模式：大流量开源项目的 PR 管理可以做到"人类只做决策，机器做执行"。

具体来说：

  • Symphony 是通用框架，不绑定 openclaw。任何团队都可以用自己的 WORKFLOW.md 定义流水线
  • Codex 可替换，Symphony 的 Agent Runner 是抽象层，理论上可以换成 Claude Code、Cursor 等其他编程 Agent
  • Linear 可替换，当前版本只支持 Linear，但架构设计了 Integration Layer，未来可以适配 GitHub Projects、Jira
  • Elixir 的容错能力天然适合长时运行的调度服务——轻量级进程、监督树、热代码升级

当然也有局限：Caclawphony 本身不是通用工具，它硬编码了 openclaw 仓库的 Linear 状态 ID、标签体系、技能文件路径。想用到自己的项目，需要 fork 后改造。但 Symphony 框架本身是通用的，WORKFLOW.md 的规范也是通用的——这才是真正值得关注的底层基础设施。

作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。

觉得文章不错？分享给更多人！