Vibe Coding with OMO

Opencode + OhMyOpenAgent — 从 Plan 到 E2E 部署的完整工作流

2026.04.01 — 2026.06.03 · 约 2 个月
AI 摘要

本文档记录了使用 opencode + OhMyOpenAgent 进行 vibe coding 的完整工作流：从 Prometheus 需求访谈到 cicd-fullchain 全链路部署。2 个月内交付 5 个 xxx-service 服务到生产，343 次 commit 通过自研 9 个 CICD Skills 和 ops-dev agent 自动部署至 Kubernetes。

Chapter 01 概览 · 架构 · 数据
1.1

What is OpenCode

OpenCode 是运行在终端的 AI 编程助手 — 它是 "壳" (the shell)。提供多 agent 协作、后台并行任务、LSP 集成、技能 (Skills) 系统。它本身是一个通用框架，通过插件和 subagent 扩展能力。

官网: opencode.ai

核心定位：终端 AI 编程助手，是 OhMyOpenAgent 的宿主环境。没有 OpenCode，OMO 无从运行。
1.2

What is OhMyOpenAgent (OMO)

OhMyOpenAgent (OMO) 是 OpenCode 的 插件，为 OpenCode 添加多 agent 编排能力 — 11 个专业 agent、并行任务执行、多模型自动路由。

GitHub: code-yeongyu/oh-my-openagent

类比：就像 oh-my-zsh 是 zsh 的插件集 — zsh 本身已经是功能完整的 shell，但 oh-my-zsh 添加了主题、插件、自动补全、命令别名，让它从"可用"升级到"好用"。

同样地，OpenCode = zsh（基础能力），OMO = oh-my-zsh（编排层）。

安装仅需一条命令：bunx oh-my-openagent install。安装后，OpenCode 获得 11 个专业 agent，覆盖从需求访谈、计划审查、代码编写到运维部署的完整链路。

1.3

vibe coding 实践统计

两个月的产出，浓缩成数字。

343
开发 Commits
5
Active 服务
155
GitOps MRs
363
Pipeline 执行
来源: push 316 + MR事件 24 + API触发 23
25
工作计划 Plans
9
自创 Skills
15
Releases
注 — Pipeline (363) > Commits (343) 的原因：
24 次 MR 事件 pipeline（创建/更新 MR 时触发） + 23 次 API 触发（xxx-registry 手动重跑） + batch push 多次 commit 共享一个 pipeline（如 sma-simulator: 54 commits → 12 pipelines）。
Chapter 02 Inside OMO: The Agent Architecture

"OpenCode 只是个终端 AI，怎么能同时写代码、审查计划、部署上线？它背后是怎么组织多个 agent 协作的？"

Prometheus 和 Sisyphus-Junior 都是 OMO 的组成部分，不是独立的工具。OMO 内部采用 3 层架构，11 个专业 agent 各司其职。

OpenCode + OhMyOpenAgent
▎Planning Layer — 规划层
Prometheus 需求访谈 → 计划生成，READ-ONLY claude-opus-4-7
Metis 计划分析，检查遗漏 / guardrails / scope creep 多模型路由
Momus 计划审查，循环质检直到 "OKAY" 多模型路由
▎Execution Layer — 执行层
Sisyphus 主编排器，按 wave 分发任务给 specialist agents 多模型路由
Atlas 执行层 agent 多模型路由
▎Worker Layer — 工作层
Sisyphus-Junior 代码编写主力，不可委托， obsessively 跟踪 todos claude-sonnet-4-6
Hephaestus Worker 层 agent 多模型路由
Oracle 深度推理，架构咨询 / 复杂逻辑 多模型路由
Librarian 文档查询，查官方文档和 best practices 多模型路由
Explore 代码搜索，查代码库中相似实现 多模型路由
Multimodal-Looker 多模态 agent 多模型路由
自动模型路由：OMO 根据任务 category 自动选择最优模型。例如：visual-engineering → gemini-3.1-pro, ultrabrain → gpt-5.5, deep → gpt-5.4, quick → gpt-5.4-mini 等。用户只需声明 category，无需手动选模型。
2.1

支持工具 — LSP · AST-grep · Task/Delegation

除了 OMO agent 体系，OpenCode 还提供了以下核心工具，共同构成完整工程能力：

LSP 集成

语言服务器协议 — 代码跳转、引用查找、符号重命名、诊断检查。所有 IDE 级操作在终端完成。

AST-grep

AST 感知的代码模式搜索和替换。支持 25 种语言，用于大规模重构和跨文件代码修改。

Task / 委派系统

多 agent 并行任务分发 — 主 agent 将独立任务分发给 explore、librarian、build、ops-dev 等专业 agent，并行执行后聚合结果。

Chapter 03 E2E 完整工作流

"我有一个新功能要开发，从说需求到代码跑在 K8s 上，整个流程是怎样的？中间需要我做什么操作？"

3.1

Phase 1 → Phase 4: 需求到部署

Auto

Phase 1: PROMETHEUS 需求访谈

  • 理解需求 & 边界
  • 3 个并行 agent: librarian + explore × 2
  • librarian 查文档, explore 查相似实现、测试基础设施
  • 记录到 .sisyphus/drafts/{name}.md
需求清晰 → Clearance Check 通过 → 自动生成计划
Auto

Phase 2: METIS 计划分析

  • 检查遗漏问题
  • 识别 scope creep
  • 补充 guardrails
  • 缺失的验收标准
计划生成到 .sisyphus/plans/{name}.md
用户高精度模式

Phase 3: MOMUS 计划审查

  • ≥90% 任务有验收标准
  • 所有文件引用已验证
  • 零业务逻辑假设
  • 循环直到 "OKAY" — 没有妥协
Momus 说 "OKAY" → 计划就绪
用户触发

Phase 4: /start-work — Sisyphus 并行执行

  • Wave 1: 并行 scaffolding — 7 个任务并发
  • Wave 2: 并行核心模块 — 7 个任务并发
  • Wave 3: 集成 — 6 个任务并发
  • Wave Final: 4 agent 审稿 — F1-F4 4 路并行
全部通过 → 用户确认
Phase 5

Phase 5: CICD 全链路部署 (下方详解)

  • commit + pre-commit gate → git push → pipeline
  • ↓ 详见下方 CICD 水平流程图
3.2

Phase 1 详解 — 意图分类与带证据提问

意图分类

类型特征策略
Build from Scratch新功能/从零开始librarian 查文档 + explore 查相似实现
Refactoring"refactor/restructure"explore 查调用链 + 测试覆盖率
Architecture系统设计/基础设施explore 查依赖图 + Oracle 咨询
Mid-sized明确范围的功能重点问边界和排除项

Pre-Interview Research (并行 3 agent)

librarian: 查官方文档、API 参考、production best practices, 跳过入门教程
explore:   查代码库中2-3个相似实现 — 目录结构、命名模式、共享 utilities
explore:   查测试基础设施 — 框架、断言风格、mock 策略、覆盖率

带证据的提问

Prometheus 不会空问。示例: "我找到你现有的 session pattern 在 lib/session.ts。是扩展现有模式，还是引入 NextAuth?"

每次有意义的交互后，更新 .sisyphus/drafts/{name}.md: 用户需求原文、技术决策 + 理由、调研发现、Scope 边界 (IN/OUT)。
3.3

Phase 2 — Metis 计划分析 (自动)

Metis 作为计划顾问，在生成计划前自动分析:

输入: 需求 + 访谈记录 + 调研结果
  ├─ 1. 应该问但没问的问题
  ├─ 2. 需要设置的 guardrails
  ├─ 3. 可能 scope creep 的区域 (如"也帮我写 adjacent module 的测试")
  ├─ 4. 未验证的假设 (如假设 test infra 存在)
  ├─ 5. 缺失的验收标准
  └─ 6. 未覆盖的边界情况 (空状态/无效输入/高并发)
自动执行: 无需用户确认，结果直接整合到计划。
3.4

Phase 3 — Momus 计划审查 (可选高精度模式)

检查清单

检查项通过标准
文件引用验证100% 引用文件存在于代码库
关键文件验证零失败
任务引用源≥80% 任务有明确参考
验收标准≥90% 任务有具体标准
业务逻辑假设零假设 (或全部有证据支撑)
全局理解计划逻辑清晰，工作流正确
关键红旗零严重问题

循环协议

while Momus.verdict != "OKAY":
    读取 Momus 反馈
    修复 ALL 提出的问题 (不是修一部分)
    重新生成 .sisyphus/plans/{name}.md
    重新提交 Momus
关键规则: 没有妥协 — Momus 说不行就修到行为止。不能跳过 — 用户要求高精度，Momus 就是门控。不限制次数 — 直到 OKAY 为止。
3.5

Phase 4 — Sisyphus 并行执行

设计原则

  • →最大化并行: 每个 wave 5-8 个任务并发
  • →依赖前置: Wave 1 是共享依赖 (类型/config/接口)
  • →单关注点: 每个任务 = 1-3 文件，>3 文件就拆分
  • →粒度规则: 任务少于 3 个 = 拆分不够

Wave 示例

Wave 1 — 7 个并行 (无依赖)

T1: 脚手架 T2: 类型定义 T3: Schema T4: 接口 T5: 基础设施 T6: 中间件 T7: 客户端

Wave 2 — 7 个并行 (依赖 Wave 1)

T8: 核心逻辑 ←依赖 1,2,4 T9: API ←依赖 1,2,4 T10: 存储 ←依赖 2,4 T11: 重试/降级 ←依赖 2,4,8 T12: UI 框架 T13: 数据层 T14: Telemetry ←依赖 5,10

Wave 3 — 6 个并行 (集成)

T15: 路由整合 ←依赖 6,11,14 T16: 可视化 T17-19: 部署配置 ←依赖 15 T20: 构建验证

Wave Final — 4 agent 并行审稿

F1: Oracle — 计划符合度 F2: 代码质量 (tsc/lint/test) F3: 真实 QA F4: Scope 忠实性 (spec vs diff)

→ 4 个全部 APPROVE → 用户明确 "okay"

3.5

Phase 5 — CICD 全链路部署

Pre-Commit Gate (MANDATORY)

  1. git rev-parse --short=8 HEAD → SHA 必须是 8 字符
  2. echo -n "$SHA_8" | wc -c | grep -q "^8$"
  3. kustomize build <overlay-path> → exit 0 才可 commit

CICD 流程图

⚡
OpenCode + OMO
commit → push → 触发 CI
▼
🔀
Git Push
触发 Pipeline
🏗️
Pipeline
build + test + docker
📦
xxx-registry
Harbor proxy
📋
GitOps MR
自动创建 PR
▼
✅
MR 合并
ops-dev 自动合并
🔄
ArgoCD
sync from CodeCommit
☸️
K8s 验证
rollout + pods + logs

K8s 验证详情

  • →kubectl rollout status (timeout 600s)
  • →kubectl get pods — Running, Ready, 0 restarts, >10min
  • →kubectl logs (grep ERROR/EXCEPTION/FATAL)

已知错误模式

Connection refused…kafka → bootstrap server 错 SSLHandshakeException → 证书问题 VaultException → Vault auth OOM killed → JVM heap BindException → 端口冲突

最后执行: lark-progress-notify 飞书通知

Chapter 04 自研 9 个 CICD Skills

"代码写好了，怎么推上去部署？CI/CD 能一键自动完成吗？"

4.1

核心 CICD Skills

cicd-fullchain
全链路部署
commit→pipeline→ECR→GitOps MR→ArgoCD→K8s; 支持所有 xxx-service 服务，china.dev/china.test/cn.prod; 8-char SHA pre-commit gate; 两种模式: 开发 (dev push) 和 发布 (release)
xxx-test-report
GitLab 测试报告
生成 xxx-service 三服务 (converter/manager/exchange-api) pipeline 测试 CSV 报告，导入飞书多维表格
xxx-new-service-design
新服务设计
Connected Safety 新服务创建完整指南: K8s namespace、Go 路由、CI 模板、ArgoCD 注册、overlay 结构
cicd-poc-deploy
POC 部署
概念验证服务的快速部署流程
cicd-quick-dev
快速开发
开发分支快速部署，跳过部分 CI 阶段
xxx-vin-scanner
VIN 调度
扫描 RMS Redis 活跃 VIN、查询 freshness、rotation、top-N 选择、/api/test/* endpoint 调用
artifactory-token
Artifactory 认证
JFrog Artifactory Maven token 自动获取 + settings.xml 配置、SSO 登录
xxx-kube-login
K8s 集群登录
xxx QA K8s SSO+2FA 自动登录、cookie 缓存避免重复 2FA、kube config 更新
lark-progress-notify
飞书通知
部署里程碑自动飞书通知 (ACL-deployed/code-deployed/verified/custom)
4.2

Ops-Dev Subagent (运维专属 Agent)

ops-dev 是 oh-my-openagent 中注册的专用 CICD 运维 subagent。

职责

  • →ALL CICD: GitLab + GitHub + GitOps + ArgoCD + K8s
  • →覆盖中国区所有微服务 (任何 china.dev / china.test / cn.prod 环境)
  • →环境自治: token 过期刷新、kube 超时修复、proxy 自动处理
  • →MR 自动合并: 定位 pipeline MR → 确认 → 合并
  • →K8s 验证 + 日志 + 飞书通知

在 CICD 流程中的分工

cicd-fullchain skill: 理解工作流、准备前置步骤
  ┌─ Step 0-3: 常规 agent (commit, push, pipeline 监控)
  │
  ▼
ops-dev subagent: Step 4+ (所有部署操作)
  ├─ 搜索 open MRs → 确认 → 合并
  └─ ArgoCD sync 等待 → kubectl 验证 → 飞书通知
4.2

调研 & 数据 Skills

#Skill用途
11xxx-ds-queryConnected Safety 数据源查询 (4 文件: SKILL + 配置 + 参考)
Chapter 05 /ulw 模式 — 持续工作到完成

"写完 plan 后，有没有一种方法让它自动跑完所有步骤，不用每步都来确认？不达目标不罢休。"

5.1

什么是 /ulw

Ultrawork 模式 — 连续工作循环，不中断、不询问 (除非阻塞):

/ulw → 设定明确目标 → Agent 自主执行 → 完成自动继续 → 全部完成
5.2

统计数据

/ulw 执行

共计 10 个成功案例，涵盖模拟器重构、协议迁移、路由修复、服务创建等场景。

工作计划

累计创建 20 个工作计划，覆盖从架构设计到部署验证的全生命周期。

Chapter 06 实战经验 & 最佳实践

"这套工作流在实际项目中踩了哪些坑？有什么可以避开的？"

6.1

CI/CD 关键教训

问题 根因 解决方案
ImagePullBackOff SHA 只有 7 字符 Pre-commit gate, git rev-parse --short=8
pipeline CVE 扫描阻塞 历史已有 CVE dp_upload_bom 临时跳过 → 修复后恢复
GitOps overlay 无效 YAML 缩进错误 kustomize build pre-commit lint
ArgoCD sync 失败 7-char vs 8-char tag Harbor webhook 只认 8-char
Kafka mTLS 连接失败 SSL bundle 注册方式不匹配 尝试 7 种方式 → BeanPostProcessor
6.2

团队协作模式

  • →Lark 通知 = 部署验收必要环节, 每个里程碑自动发送
  • →Ops-Dev 独立于编码 agent — 代码专注功能, ops 专注部署
  • →飞书多维表格 = 测试报告仪表盘, skill 自动上报
  • →Confluence 文档 链接在 README, 每个服务标明
Chapter 07 命令速查

"我刚开始用，日常开发有哪些常用命令？"

本地开发

cd xxx-service/<service>/
mvn clean install
mvn spring-boot:run \
  -Dspring-boot.run.profiles=local

CICD

git add -A && git commit \
  -m "type(scope): desc" && git push
kubectl get pods -n xxx-ns
kubectl logs -n xxx-ns \
  -l app=<service> --tail=100

Pre-Commit Gate

SHA_8=$(git rev-parse --short=8 HEAD)
echo -n "$SHA_8" | wc -c | grep -q "^8$"
kustomize build apps/partner/<service>/\
  overlays/china.dev

Opencode

/start-work {plan-name}   # 执行计划
/ulw                      # 持续工作模式
/cancel                   # 取消

Lark 通知

./scripts/notify-progress.sh china.dev code-deployed "<Tag> / <Pod>"
Chapter 08 技术栈清单
技术栈
语言
Java 21/25
Node.js 22
框架
Spring Boot
Lombok
消息
Kafka
Confluent Avro/Protobuf
存储
Redis
Jedis (xxx-service)
容器
Docker · K8s
ArgoCD · Istio
CI/CD
GitLab CI
Harbor proxy
前端
React 17
Mapbox · deck.gl
通知
Lark 飞书