omo 工作流概述

omo（Orchestrated Multi-objective Optimization）是信号驱动的动态路由工作流。与 do 的线性七阶段不同，omo 根据实时分析结果动态决定执行路径——模拟经验丰富的技术 Leader 在面对复杂问题时的决策过程。

omo 擅长处理"你不知道不知道什么"的任务。当问题模糊时用 omo，当需求明确时用 do。

启动方式

Claude Code slash 命令（推荐）

claude
> /omo 修复高并发场景下 concurrent map writes panic

附加上下文

> /omo 修复并发问题 --context "CI 日志显示 data race 在 cache/store.go:47"

风险信号检测

omo 基于三类核心信号进行路由决策：

信号类型	衡量内容	权重
复杂度信号	技术复杂度、涉及文件数、跨语言/框架	0.40
跨模块影响	调用链深度、共享状态、接口变更	0.35
数据完整性	数据模型变更、数据库迁移	0.25

综合得分决定路由策略：

• 0-30：轻量路由 — 单个修复智能体直接解决
• 31-60：标准路由 — 探索 + 修复
• 61-85：深度路由 — 启用 EHRB 循环多路径验证
• 86-100：完全路由 — 完整多智能体协作

EHRB 循环

EHRB（Explore-Hypothesize-Repair-Verify）是 omo 的核心执行循环：

[omo:ehrb] 循环 1/5
[omo:ehrb:explore] 分析 goroutine dump...检测到 2 处潜在数据竞争
[omo:ehrb:hypothesize] 假设 1: sync.Map 未正确初始化 (置信度: 80%)
[omo:ehrb:hypothesize] 假设 2: channel 关闭后仍有写入 (置信度: 45%)
[omo:ehrb:repair] 实施假设 1 的修复方案...
[omo:ehrb:repair] 运行验证: go test -race ./...
[omo:ehrb:repair] 验证通过! 竞态条件已解决

实战：调试竞态条件

问题描述

项目在高并发场景下偶发 concurrent map writes panic。仅在 CI 的 -race 检测中触发。

启动工作流

claude
> /omo 修复 concurrent map writes --context "CI 日志显示 data race 在 cache/store.go:47"

omo 分析后：复杂度得分 72（并发问题），跨模块影响 55，数据完整性 40。综合得分 58.35 进入标准路由，但因检测到"并发"信号自动提升至深度路由，启用 EHRB 循环。

何时选择 omo

场景	推荐
Bug 根因调查	✅ omo
复杂重构（不确定性高）	✅ omo
性能优化	✅ omo
需求明确的功能开发	do
快速原型验证	sparv
企业级大型项目	bmad

CLI 参考

slash 命令

/omo 任务描述
/omo 任务描述 --context "附加上下文"

pinable 编排层

# 通过 pinable 调用
pinable --backend claude "修复 concurrent map writes"

与 do 工作流对比

维度	do	omo
执行路径	线性七阶段	信号驱动动态路由
适用场景	需求明确	Bug 调查、复杂重构
不确定性容忍	低	高
智能体数量	固定 7 个	动态 2-8 个
回溯机制	阶段间回退	EHRB 循环