omo 智能路由编排

omo 工作流概述

omo（Orchestrated Multi-objective Optimization）是 PinableAgents 中最具智能化特征的工作流。与 do 工作流的线性七阶段流程不同，omo 采用信号驱动的动态路由机制——它不预设固定的执行路径，而是根据任务的实时分析结果，动态决定调用哪些智能体、以何种顺序执行。

omo 的核心设计思想是"面对不确定性，让系统自己找到最优路径"。在 Bug 调查、复杂重构、性能优化等不确定性较高的场景中，开发者往往无法在任务开始时就确定最佳的解决路径。omo 通过持续收集和分析任务执行过程中的信号，动态调整编排策略，模拟了经验丰富的技术 Leader 在面对复杂问题时的决策过程。

omo 的价值在于处理那些"你不知道不知道什么"的任务。当需求明确时用 do，当问题模糊时用 omo。

风险信号检测机制

omo 的路由决策基于三类核心风险信号的实时检测。每类信号都有量化的评分体系，综合得分决定了任务的复杂度等级和对应的路由策略。

复杂度信号（Complexity Signals）

衡量任务本身的技术复杂度。系统通过分析任务描述、涉及的代码量和技术栈来计算复杂度得分。

信号指标	检测方式	权重
涉及文件数	代码库搜索匹配	0.25
跨语言/框架	文件扩展名和导入分析	0.20
算法复杂度	任务描述关键词识别	0.20
并发/异步涉入	goroutine/async/channel 模式匹配	0.20
外部依赖数量	go.mod/package.json 分析	0.15

跨模块影响信号（Cross-module Impact Signals）

评估任务变更对其他模块的影响范围。高跨模块影响意味着变更可能引发级联效应，需要更审慎的路由策略。

调用链深度：变更点在调用链中的位置，越底层影响越大
共享状态：是否涉及全局变量、共享缓存、公共数据库表
接口变更：是否修改了公开的 API 契约或内部接口定义
配置耦合：是否涉及影响多个模块行为的配置项

数据完整性信号（Data Integrity Signals）

检测任务是否涉及数据模型变更、数据库迁移或数据转换逻辑。数据相关的变更通常不可逆，需要最高级别的审慎处理。

路由决策算法

omo 的路由引擎基于加权信号评分进行决策。每个信号类别的得分范围是 0-100，综合得分通过加权平均计算：

综合得分 = 复杂度得分 * 0.4 + 跨模块影响 * 0.35 + 数据完整性 * 0.25

路由策略映射：
  得分 0-30   -> 轻量路由（Light Route）
  得分 31-60  -> 标准路由（Standard Route）
  得分 61-85  -> 深度路由（Deep Route）
  得分 86-100 -> 完全路由（Full Route）

每种路由策略对应不同的智能体组合和执行流程。轻量路由可能只调用一个修复智能体直接解决问题，而完全路由则会调用探索、假设生成、多路径验证等多个智能体协作完成。

决策树详解

以下是 omo 路由引擎的决策树结构，以文本形式呈现。每个决策节点根据信号评分选择分支路径。

任务输入
  |
  +-- [信号采集] 分析任务描述和代码库
  |
  +-- 综合得分 <= 30?
  |     |
  |     YES -> 轻量路由
  |     |       +-- 调用 quick-fix 智能体
  |     |       +-- 直接实现并验证
  |     |       +-- 完成
  |     |
  |     NO -> 综合得分 <= 60?
  |           |
  |           YES -> 标准路由
  |           |       +-- 调用 code-explorer
  |           |       +-- 调用 bugfix 或 refactor 智能体
  |           |       +-- 运行验证套件
  |           |       +-- 完成
  |           |
  |           NO -> 综合得分 <= 85?
  |                 |
  |                 YES -> 深度路由
  |                 |       +-- 调用 code-explorer（深度模式）
  |                 |       +-- 启用 EHRB 循环
  |                 |       +-- 调用 hypothesis-generator
  |                 |       +-- 多路径并行验证
  |                 |       +-- 调用 integration-tester
  |                 |       +-- 完成
  |                 |
  |                 NO -> 完全路由
  |                         +-- 调用 code-explorer（全量扫描）
  |                         +-- 启用 EHRB 循环（最大深度）
  |                         +-- 调用 architect（重新评估架构）
  |                         +-- 多路径并行验证 + 回归测试
  |                         +-- 调用 security-reviewer
  |                         +-- 人工审查检查点
  |                         +-- 完成

智能体池与能力矩阵

omo 工作流可以调用的智能体池包含以下成员，每个智能体有明确的能力边界和调用条件。

智能体	核心能力	触发条件
code-explorer	代码库结构分析、依赖追踪、调用链映射	所有路由策略
quick-fix	小范围单文件修复	轻量路由
bugfix	Bug 定位和修复，含根因分析	标准及以上路由
refactor	代码重构，保持行为不变	标准及以上路由
debug	运行时调试，日志分析，断点追踪	深度及以上路由
hypothesis-generator	生成问题假设并设计验证实验	深度及以上路由
architect	架构级评估和重构方案设计	完全路由
security-reviewer	安全漏洞检测和修复建议	完全路由

EHRB 模式详解

EHRB（Explore-Hypothesize-Repair-Backtrack）是 omo 在深度和完全路由中使用的核心问题解决模式。它模拟了资深工程师调试复杂问题时的思维过程。

Explore（探索）

在已有信息的基础上，深入探索问题的具体表现和上下文。这一步不是泛泛的代码浏览，而是带有明确目标的定向探索——根据已知的症状和线索，聚焦在最可能的问题区域。

Hypothesize（假设）

基于探索结果生成问题根因的假设列表。每个假设都附带置信度评分和可验证的预测。例如："假设竞态条件发生在 goroutine A 和 B 对共享 map 的并发读写（置信度 75%），预测：加入 -race 标志后可重现"。

Repair（修复）

针对最高置信度的假设实施修复方案。修复在隔离的 Git worktree 中进行，不影响主代码库。修复完成后自动运行验证测试。

Backtrack（回溯）

如果修复未能通过验证，系统回溯到 Hypothesize 阶段，排除已证伪的假设，重新评估剩余假设的置信度，并可能基于新发现生成新的假设。这个循环最多执行五次，超过后请求人工介入。

# EHRB 循环的日志输出示例
[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] 验证通过! 竞态条件已解决

实战：调试竞态条件

以下演示使用 omo 工作流调试一个 Go 项目中的竞态条件问题。

问题描述

项目在高并发场景下偶发 panic，错误信息为 concurrent map writes。问题在本地环境难以稳定复现，仅在 CI 的 -race 检测中触发。

启动 omo 工作流

# 使用 omo 调查并修复竞态条件
pinable-agents run omo \
  --task "修复高并发场景下 concurrent map writes panic" \
  --context "CI 日志显示 data race 在 cache/store.go:47"

# 或通过 codeagent CLI 直接调用
codeagent --backend claude --workflow omo \
  --task "fix concurrent map writes in cache module"

路由过程

omo 的信号检测引擎分析后得出：复杂度得分 72（并发问题触发高权重），跨模块影响 55（cache 模块被多处调用），数据完整性 40。综合得分 58.35，进入标准路由。然而由于检测到"并发"关键信号，路由引擎将其提升至深度路由，启用 EHRB 循环。这种信号触发的路由提升是 omo 的核心智能特征之一。

跨模块重构路由

当 omo 检测到任务涉及跨模块重构时，会激活特殊的重构路由策略。该策略的核心是"变更隔离"——将大范围的重构拆解为多个可独立验证的小变更，每个小变更都在独立的 Git worktree 中完成，通过测试后才合入主分支。

重构路由的典型流程是：首先调用 architect 智能体评估重构范围和风险；然后将重构拆解为有序的变更步骤；每个步骤由 refactor 智能体执行并由 integration-tester 验证；最后由 code-reviewer 进行全量审查。

CLI 命令参考

# 基本用法
pinable-agents run omo --task "任务描述"

# 指定最大 EHRB 循环次数
pinable-agents run omo --task "任务描述" --max-ehrb-cycles 3

# 强制使用特定路由策略
pinable-agents run omo --task "任务描述" --route deep

# 输出路由决策详情（不执行）
pinable-agents run omo --task "任务描述" --dry-run

# 附加上下文信息
pinable-agents run omo --task "任务描述" \
  --context-file ./error-log.txt \
  --context "仅在 Linux CI 环境复现"

与 do 工作流的对比

维度	do 工作流	omo 工作流
执行路径	线性七阶段	信号驱动动态路由
适用场景	需求明确的功能开发	Bug 调查、复杂重构、性能优化
不确定性容忍	低（需要明确需求）	高（可以从模糊问题开始）
智能体数量	固定 7 个	动态 2-8 个
执行时间	可预测	取决于问题复杂度
回溯机制	阶段间回退	EHRB 循环回溯

目录