Cezar：GitHub Issue全生命周期管理的AI驾驶舱平台

Cezar是一个团队级SaaS平台，专为在GitHub issues上运行AI编码代理而设计。它提供了一个完整的驾驶舱界面，让每个代理运行的状态都清晰可见，支持自动分类、多步骤自动修复工作流，并以草稿PR结束，让人类始终保持对关键决策的控制权。

• 原作者/维护者：open-mercato
• 来源平台：github
• 原始标题：cezar
• 原始链接：https://github.com/open-mercato/cezar
• 来源发布时间/更新时间：2026-06-01T22:15:41Z

原作者与来源

• 原作者/维护者：open-mercato
• 来源平台：github
• 原始标题：cezar
• 原始链接：https://github.com/open-mercato/cezar
• 来源发布时间/更新时间：2026-06-01T22:15:41Z 原作者与来源\n\n- 原作者/维护者: open-mercato\n- 来源平台: GitHub\n- 原始标题: cezar\n- 原始链接: https://github.com/open-mercato/cezar\n- 发布时间: 2026年6月1日\n\n---\n\n引言：当GitHub Issues成为负担\n\n对于任何活跃的开源项目或企业代码库来说，GitHub Issues既是宝贵的反馈渠道，也是沉重的维护负担。新issue不断涌入，但分类、标记、优先级排序和实际修复往往滞后数天甚至数周。传统的"AI for GitHub"工具通常是点解决方案——一个标签生成器、一个重复检测器、一个自动修复机器人——并行运行多个工具后，你最终得到的是没有共享模型、没有共享可见性，也没有明确的人类介入点。\n\nCezar的设计理念截然不同：它不是另一个单点工具，而是一个驾驶舱，将这些任务整合到一个统一的交付流程中。\n\n---\n\nCezar是什么？\n\nCezar是一个团队级SaaS平台，专为在GitHub issues上运行AI编码代理而设计。它提供了一个完整的驾驶舱界面，让每个代理运行的状态——排队中、运行中、已暂停、失败、已完成——都清晰可见，并配备行级控制。\n\n核心功能包括：\n- 自动分类：每个传入的issue都会通过webhook自动触发分类流程\n- 自动修复工作流：Bug修复作为技能驱动的多步骤工作流运行，最终以草稿PR结束\n- 人机协作：代理处理例行事务，人类保持对判断决策的控制权\n\n---\n\n它解决了什么问题？\n\n积压超过分类速度\n\n新issue经常处于未标记、未确定优先级的状态数天。Cezar在webhook上自动分类每个传入的issue——类型、优先级、重复项、缺失信息——并发布一条汇总评论，而不是一墙机器人评论。\n\n代理运行缺乏可见性\n\n当你运行多个代理时，你不再知道哪个运行已暂停、哪个失败、哪个耗尽了回合预算。驾驶舱实时显示每个运行，支持每行的暂停、取消、恢复、重试、删除操作。\n\n交接而不失控制\n\n代理处理例行事务，但人工门控步骤会在低置信度决策时暂停工作流，让你在任何事情发布之前批准。修复以草稿PR形式落地——从不自动合并。\n\n无需fork的定制化\n\n操作是数据驱动的规范，技能是从仓库.ai/skills/目录拉取的Markdown操作手册。通过GUI中的克隆编辑覆盖内置功能，无需TypeScript插件。\n\n自带代理后端\n\nAnthropic API、Claude Code CLI或Codex CLI——为每个工作流步骤选择。通过自托管运行器在你自己的基础设施下、使用你自己的登录凭据运行订阅CLI。\n\n---\n\n为谁而设计？\n\n工程负责人\n\n管理稳定的bug报告和功能请求流入，希望在不丢失审计跟踪的情况下进行委派。Cezar提供端到端的可见性和控制。\n\n开源维护者\n\n积压增长速度超过分类时间，希望在issue上保持一致的声音——而不是五个机器人评论。Cezar的自动分类和统一评论机制解决了这个问题。\n\n平台/DevEx团队\n\n在多个仓库中推出代理工作流，寻找共享的可观测性、共享的操作手册和共享的门控。Cezar的工作空间级配置和技能共享机制满足这些需求。\n\n独立开发者\n\n一次性处理积压issue——CLI模式适用于本地JSON存储，无需SaaS或数据库。Cezar提供灵活的使用路径。\n\n---\n\n人机代理循环如何工作？\n\n一个bug报告到达GitHub。GitHub App webhook将分类作业加入队列。分类流程按确定性顺序运行每个启用的、触发器匹配on-issue-opened的操作。如果修复在范围内，自动修复工作流启动：verify-in-repo → root-cause → fix → review-loop → open PR (draft)——任何步骤都可以是人工门控，暂停直到你批准。\n\n\n ┌────────────────────────────────────────────────┐\nGitHub ──►─── │ webhook (issues.opened) │\n │ └─► jobs (deduped) │\n └────────────────────────────────────────────────┘\n │\n ▼\n ┌─────────────────────┼─────────────────────┐\n ▼ ▼ ▼\n Triage pass Autofix workflow CI follow-up\n ┌────────────┐ ┌──────────────────┐ ┌───────────────┐\n │ bug detect │ │ verify-in-repo │ │ classify CI │\n │ priority │ │ root-cause │ │ failure │\n │ duplicates │ │ fix │ │ patch + push │\n │ auto-label │ │ review-loop │ └───────────────┘\n │ … │ │ open PR (draft) │\n └────────────┘ └──────────────────┘\n │ │\n ▼ ▼\n agent_run_events ──realtime──► Cockpit UI\n │\n human-gates pause here\n for your approval\n\n\n每个步骤写入结构化事件；驾驶舱（/cockpit、/cockpit/[runId]）通过Supabase Realtime订阅并实时渲染步骤图填充。issue上的单一活跃评论（然后是PR）随着步骤完成而编辑——一个一致的声音，而不是机器人墙。\n\n---\n\n核心功能详解\n\n驾驶舱（Cockpit）\n\n驾驶舱是Cezar的核心界面，显示工作空间中每个代理运行的实时状态。每行代表一个运行，包含：\n- 当前状态（排队中、运行中、已暂停、失败、已完成）\n- 触发器类型和来源\n- 关联的issue或PR\n- 行级控制按钮：暂停、取消、恢复、重试、删除\n\n运行详情（Run Detail）\n\n点击任何运行进入详情视图，包含：\n- 步骤图：可视化显示工作流进度\n- 流式事件日志：实时更新的操作记录\n- 每个步骤的输入输出和决策上下文\n\n活动日志（Activity Feed）\n\n工作空间范围的审计跟踪，记录：\n- 所有代理运行的开始和结束\n- 人工门控决策\n- 系统事件和错误\n- 配置变更\n\n收件箱（Inbox）\n\n待决策和暂停运行的集中视图，确保没有需要人类注意的事项被遗漏。\n\n操作编辑器（Action Editor）\n\n配置每个操作的系统提示、技能和效果。支持：\n- 系统提示词编辑\n- 技能绑定\n- 效果配置\n\n验收设置（Acceptance Settings）\n\n控制每个操作的模型选择、自动接受策略和置信度阈值。\n\n操作目录（Actions Catalog）\n\n内置和用户自定义操作的统一管理界面，支持克隆和编辑。\n\n技能管理（Skills）\n\n内置技能与仓库.ai/skills/目录的集成，支持：\n- 技能列表浏览\n- 渲染正文和提示预览\n- 版本控制和更新\n\n工作流编辑器（Workflows Editor）\n\n拖放式步骤排序和技能绑定，无需编写代码即可配置复杂工作流。\n\n运行器管理（Runners）\n\n注册和管理自托管运行器，支持心跳监控和状态检查。\n\n---\n\n快速开始\n\n推荐路径：自托管SaaS（完整驾驶舱+自动分类），配合本地Supabase Docker堆栈。\n\nbash\ngit clone https://github.com/comerito/cezar.git\ncd cezar\nyarn install\n\n1. 启动本地Supabase堆栈（Docker中的db + kong + Realtime）\nyarn db:start\n\n2. 设置环境变量（完整列表见docs/SELF-HOSTING.md）\ncat > .env.local <<EOF\nNEXT_PUBLIC_SUPABASE_URL=...\nSUPABASE_SERVICE_ROLE_KEY=...\nANTHROPIC_API_KEY=sk-ant-...\nGITHUB_APP_ID=...\nGITHUB_APP_PRIVATE_KEY=\"-----BEGIN...\"\nGITHUB_APP_WEBHOOK_SECRET=...\nCRON_SECRET=...\nNEXT_PUBLIC_APP_URL=https://app.example.com\nEOF\n\n3. 运行\nyarn workspace @cezar/gui dev\n\n\n然后在你的仓库上安装GitHub App，完成Workspaces → New向导（项目环境预设、标签目录分析、工作流默认设置），打开/dashboard。新issue将开始自动分类。\n\n> 偏好无数据库、无SaaS路径？单人使用CLI针对本地JSON存储运行。见docs/INSTALL.md。\n\n---\n\n技术架构\n\nCezar采用现代Web技术栈构建：\n\n- 前端: Next.js + TypeScript，提供响应式驾驶舱界面\n- 后端: Node.js服务层，处理GitHub webhook和业务逻辑\n- 数据库: Supabase（PostgreSQL + Realtime），支持实时事件流\n- 代理后端: 支持Anthropic API、Claude Code CLI、Codex CLI等多种选择\n- 自托管运行器: 支持在自有基础设施上运行代理\n\n数据流架构\n\n\nGitHub Webhook\n │\n ▼\n┌─────────────────┐\n│ Cezar Backend │\n│ (job enqueue) │\n└────────┬────────┘\n │\n ▼\n┌─────────────────┐\n│ Supabase │\n│ (queue + events)│\n└────────┬────────┘\n │\n ▼\n┌─────────────────┐\n│ Agent Runner │\n│ (skill execution)│\n└────────┬────────┘\n │\n ▼\n┌─────────────────┐\n│ Realtime │\n│ (UI updates) │\n└─────────────────┘\n\n\n---\n\n与竞品的差异化\n\n| 特性 | Cezar | GitHub Actions + AI | 独立AI工具 |\n|------|-------|---------------------|-----------|\n| 统一界面 | 完整驾驶舱 | 分散的日志 | 单点工具 |\n| 实时可见性 | 实时步骤图 | 延迟的日志查看 | 通常无 |\n| 人工门控 | 内置工作流暂停 | 需手动配置 | 通常无 |\n| 技能系统 | Markdown操作手册 | 需自定义 | 各工具不同 |\n| 多后端支持 | Anthropic/Claude/Codex | 通常单一 | 通常单一 |\n| 自托管选项 | 完整支持 | 部分支持 | 通常无 |\n| 统一评论 | 单一活跃评论 | 多步骤日志 | 多个机器人 |\n\n---\n\n使用场景示例\n\n场景一：自动化Bug分类\n\n新bug报告到达时，Cezar自动：\n1. 检测issue类型（bug/feature/question）\n2. 确定优先级（critical/high/medium/low）\n3. 检查重复项\n4. 识别缺失信息\n5. 添加适当标签\n6. 发布汇总评论\n\n场景二：端到端自动修复\n\n对于确认的bug，Cezar执行完整工作流：\n1. 在仓库中验证问题\n2. 分析根本原因\n3. 生成修复代码\n4. 内部审查循环\n5. 发起草稿PR\n6. 等待人类批准\n\n场景三：CI失败自动跟进\n\nPR构建失败时，Cezar可以：\n1. 分类CI失败类型\n2. 尝试生成补丁\n3. 推送修复到PR分支\n4. 重新触发CI\n\n---\n\n总结与展望\n\nCezar代表了AI辅助软件开发工作流的一个重要方向：从单点工具向统一平台的演进。它解决了当前AI编码工具碎片化、缺乏可见性、难以控制的核心问题，提供了一个真正可生产使用的AI代理驾驶舱。\n\n对于希望在不失去控制的前提下获得AI自动化能力的团队，Cezar提供了一个 compelling 的选择。它的驾驶舱 metaphor 直观易懂，人机协作设计确保了关键决策始终在人类手中，而灵活的部署选项则适应了不同规模和需求的团队。\n\n随着AI代理技术的成熟，我们可以期待Cezar这样的平台将在软件开发生命周期中扮演越来越重要的角色，从简单的自动化工具进化到真正的智能协作伙伴。