ruflo-intelligence 智能路由实战：基于三档模型选择器与学习模式的 Agent 任务编排
【免费下载链接】ruflo🌊 The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo
导读
本文围绕 Ruflo 插件体系中的ruflo-intelligence的intelligence-route技能（SKILL.md），系统讲解如何用三档模型选择器（3-Tier Model Router）+ 历史学习模式（learned patterns）为任意任务自动挑选最优 Agent 与模型档位，并通过hooks_explain输出可审计的路由依据。读完本文，你将掌握hooks_route、hooks_model-route、hooks_intelligence_pattern-search、neural_predict、hooks_model-outcome等工具组成的完整路由闭环，理解 Tier 1 确定性 codemod（$0、零 LLM）与 Tier 2/3 模型调度的边界，并能用 MCP 工具或@claude-flow/cli命令行落地同一套流程。
一、智能路由解决什么问题
在 Ruflo 的运行时中，任务到达后往往需要人工指定「用哪个 Agent、哪个模型」，这种手动选择既不透明也不经济——一个简单的var-to-const转换若被丢给 Sonnet，会付出毫秒级任务数秒的延迟与数美分的成本；而一个跨多文件重构若被丢给 Haiku，则大概率返工。
intelligence-route技能将这一决策数据化：用学习到的历史模式 + 三档模型路由器替代人工选择。其技能前置声明（frontmatter）明确给出能力边界：
name: intelligence-route description: Route tasks via the 3-tier model selector and learned patterns; emits a routing rationale via hooks_explain argument-hint: "<task-description> [--why]" allowed-tools: mcp__plugin_ruflo-core_ruflo__hooks_route mcp__plugin_ruflo-core_ruflo__hooks_explain mcp__plugin_ruflo-core_ruflo__hooks_model-route mcp__plugin_ruflo-core_ruflo__hooks_model-stats mcp__plugin_ruflo-core_ruflo__hooks_model-outcome mcp__plugin_ruflo-core_ruflo__hooks_intelligence_pattern-search mcp__plugin_ruflo-core_ruflo__hooks_intelligence_attention mcp__plugin_ruflo-core_ruflo__hooks_intelligence_stats mcp__plugin_ruflo-core_ruflo__neural_predict mcp__plugin_ruflo-core_ruflo__hooks_pre-task Bash技能接受一个任务描述，可选传入--why以要求输出路由解释。它的适用时机是任何非平凡任务开始之前——替换掉手工选 Agent 的旧流程。
该技能是 Ruflo 自学习系统（self-learning system）的用户面入口之一。
ruflo-intelligence插件将 29 个智能相关 MCP 工具组织为可发现的技能、命令与标准 4 步流水线（RETRIEVE → JUDGE → DISTILL → CONSOLIDATE），与ruflo-agentdb（命名空间约定）、ruflo-ruvector（轨迹记录基底）、ruflo-browser（会话回放）协同工作，详见 ruflo-intelligence/README.md。intelligence-route正是该流水线中JUDGE（评判）阶段的落地形态。
二、路由七步流程：从推荐到闭环训练
intelligence-route的核心是可重复执行的七步操作序列，每一步都对应一个具体的 MCP 工具：
- 获取 Agent 推荐— 调用
mcp__plugin_ruflo-core_ruflo__hooks_route，传入任务描述。返回{ recommended, confidence, reasoning }（推荐 Agent、置信度、推理依据）。 - 获取模型档位推荐— 调用
mcp__plugin_ruflo-core_ruflo__hooks_model-route，在 Haiku/Sonnet/Opus 三者间做选择。 - 检索历史相似模式— 调用
mcp__plugin_ruflo-core_ruflo__hooks_intelligence_pattern-search，寻找过往成功案例，命中即为 RETRIEVE 阶段的输入。 - 预测任务结局— 调用
mcp__plugin_ruflo-core_ruflo__neural_predict，对任务描述给出带置信度的成败预测，作为 JUDGE 阶段的路由信号。 - 按推荐档位派生 Agent— 以第 1、2 步的结果启动推荐 Agent。
- （可选）输出路由依据— 若调用时传了
--why，则调用mcp__plugin_ruflo-core_ruflo__hooks_explain，把「为什么选这个 Agent、这个模型」的完整理由交给用户，保证决策可审计。 - 任务完成后回灌结果— 调用
mcp__plugin_ruflo-core_ruflo__hooks_model-outcome，携带success: true|false，让路由器从结果中学习。
这七步构成了一个完整的路由闭环：推荐 → 执行 → 解释 → 反馈训练。第 7 步尤其关键——见下文「闭环训练」。
三、三档模型路由：延迟、成本与适用场景
路由器的核心决策模型是三档选择（3-Tier Model Routing），intelligence-route技能用一张表把它讲透：
| 档位 | 处理器 | 延迟 | 成本 | 适用场景 |
|---|---|---|---|---|
| 1 | 确定性 codemod（TypeScript 编译器） | ~1ms | $0 | 无需 LLM 的结构性变换：var-to-const、remove-console、add-logging |
| 2 | Haiku | ~500ms | ~$0.0002 | 低复杂度（<30%）、Bug 修复、快速补丁 |
| 3 | Sonnet/Opus | 2–5s | $0.003–$0.015 | 复杂推理、架构设计、安全审计、多文件重构 |
三档设计的目标是避免把简单变换丢给昂贵模型——正如hooks_route工具的底层描述所言：原生工具没有等价物，Claude Code 本身不会内省自己的模型选择成本（见 hooks-tools.ts）。
3.1 Tier 1：何时走确定性 codemod
当hooks_route返回[CODEMOD_AVAILABLE]字面量，且任务意图属于确定性的三类（var-to-const、remove-console、add-logging）时，应调用mcp__plugin_ruflo-core_ruflo__hooks_codemod，传入意图 + 文件，由 TypeScript 编译器直接应用变换——$0、无 LLM 参与。
底层实现位于 ADR-143，它把 Tier 1 从旧方案「Agent Booster」重构为确定性 codemod，原因在于审计发现旧执行路径是死代码、接线错误且模块无法解析——Agent Booster 本质是快应用合并引擎（接收 LLM 已算好的目标代码片段），而不是变换生成器，因此无法实现零 LLM 的意图变换。新的实现改用 TypeScript 编译器 API 做保留格式的文本范围编辑：定位精确 AST 节点、直接拼接原始源码、绝不重印整个文件，因此注释与空白得以保留。
三个确定性意图的变换规则（ADR-143 明确给出）：
var-to-const：绑定在整个文件中从未被重新赋值则改为const，否则保守地保留let（let永远合法）；remove-console：删除console.*(…)表达式语句，仅当该语句独占一行时整行移除；add-logging：在每个函数体插入一行console.log("<name> called")，幂等——已存在则跳过。
注意边界：add-types、add-error-handling、async-await需要判断力，按 ADR-143 它们不是 $0 的 codemod，会路由到模型（Tier 2/3）。hooks_codemod工具对这类意图会直接拒绝并提示「Route it to a model via hooks_model-route (Tier 2/3)」（见 hooks-tools.ts）。而 Agent Booster 仍作为一般快应用引擎依赖存在，但已移出 Tier 1 路径。
3.2 Tier 2/3：复杂度驱动的模型选择
当任务无法被确定性 codemod 覆盖，hooks_route内部会通过enhanced-model-router计算复杂度并返回{ tier, handler, model, complexity, confidence, estimatedLatencyMs, estimatedCost, recommendation }（见 hooks-tools.ts）。同时hooks_model-route提供独立的模型档位接口，其输入为{ task, preferSpeed?, preferCost? }，底层路由器返回{ model, confidence, uncertainty, complexity, reasoning, alternatives }，并在兼容性字段中声明实现为heuristic-thompson-bandit（启发式 + Thompson 置信区间上界，而非神经网络），见 hooks-tools.ts。
若模型路由器不可用，hooks_model-route会退化为简单启发式：complexity > 0.7 → opus，> 0.4 → sonnet，否则haiku，置信度固定 0.7 并标注implementation: 'fallback'。
四、闭环训练：hooks_model-outcome为什么是必选项
技能原文强调：「Closing the routing loop is mandatory（关闭路由环路是强制要求）」。路由决策只有在被回灌后才产生学习价值，否则路由器永远停留在初始状态。
# 成功 mcp tool call hooks_model-outcome --json -- '{"taskId": "T123", "success": true, "model": "haiku"}' # 失败并附原因 mcp tool call hooks_model-outcome --json -- '{"taskId": "T123", "success": false, "model": "haiku", "reason": "complexity-misjudged"}'技能原文直白地警告：「The router learns from these calls. Skipping them = no learning.（路由器从这些调用中学习。跳过它们 = 不学习。）」
底层看，hooks_model-outcome的 handler 直接调用ModelRouter.recordOutcome(task, model, outcome)，把结果写入Thompson 先验，见 hooks-tools.ts。其输入模式为{ task, model(enum: haiku|sonnet|opus), outcome(enum: success|failure|escalated) }——注意技能示例使用了success布尔 +reason，而工具级 schema 额外支持escalated这一状态，与置信度门控升级机制衔接（见下文）。
与路由配套的还有一个验证侧工具hooks_model-verify：它用廉价的结构信号（空输出/截断、拒绝模式、退化重复、对代码/JSON 任务做真实语法解析）在生成后给出{confident, reasons[], suggestedTier, escalate}判定，并把结论写入与hooks_model-outcome相同的学习流——这样 Bandit 能学到「廉价档位在哪些任务形态上会失败」。这构成了route → generate → verify → (escalate) → outcome的完整置信度门控序列（见 hooks-tools.ts）。
路由学习的效果可以在任何时候用hooks_model-stats查询：{ available, ...stats, timestamp }，供/intelligence仪表盘展示模型档位分布（见 hooks-tools.ts）。
五、CLI 替代方案：不开 MCP 也能跑通路由
若不想（或不方便）直接调 MCP 工具，技能提供了等价的命令行形态，底层都封装在@claude-flow/cli的hooks命令族中：
npx @claude-flow/cli@latest hooks route --task "description" npx @claude-flow/cli@latest hooks pre-task --description "description" npx @claude-flow/cli@latest hooks explain --topic "routing decision"hooks route与hooks_pre-task等价于第 1 步的 Agent 推荐——其中hooks_pre-task在 hooks-tools.ts 中实现为：基于任务描述做关键词复杂度判定（含complex/architecture/超长描述 → high，simple/fix/短描述 → low，否则 medium），并给出suggestedAgents（主 Agent 置信度递减排列）、estimatedDuration（high: 2-4 小时 / medium: 30-60 分钟 / low: 10-30 分钟）、risks与recommendations；hooks explain对应第 6 步的--why解释：它输出「基于关键词分析的路由决策」、命中模式列表、以及从.claude-flow/routing-outcomes.json读出的历史成功率（若文件存在），见 hooks-tools.ts。
六、在 4 步智能流水线中的定位
intelligence-route不是孤立技能，它嵌在ruflo-intelligence插件所定义的RETRIEVE → JUDGE → DISTILL → CONSOLIDATE四步流水线中（见 README.md）：
| 阶段 | 做什么 | 本技能用到的工具 |
|---|---|---|
| RETRIEVE | 从 HNSW 索引拉取相关模式与历史轨迹 | hooks_intelligence_pattern-search（第 3 步） |
| JUDGE | 对候选打分并给出裁决 | hooks_intelligence_attention、neural_predict（第 4 步）、hooks_explain（第 6 步） |
| DISTILL | 通过 LoRA/SONA 提炼关键经验 | （本技能之外，见neural-train技能） |
| CONSOLIDATE | 用 EWC++ 防止灾难性遗忘 | （本技能之外） |
技能的第 3 步pattern-search正是 RETRIEVE 的落地，第 4 步neural_predict与第 6 步hooks_explain共同构成 JUDGE——路由决策因此同时获得「历史模式」与「神经预测」双重依据。
七、把技能接进日常工作流：配置前提与最佳实践
安装与兼容性
ruflo-intelligence插件通过 Ruflo 插件市场安装：
/plugin marketplace add ruvnet/ruflo /plugin install ruflo-intelligence@ruflo兼容性约束（见 README.md）：CLI 固定到@claude-flow/cliv3.6 大版本 + 次版本；验证契约是运行bash plugins/ruflo-intelligence/scripts/smoke.sh。
与 Hook 集成的自动触发
intelligence-route的调用链在 Claude Code 钩子层已有官方接线（见 README.md）：
| 钩子 | 调用工具 | 阶段 |
|---|---|---|
pre-task | hooks_route+hooks_intelligence_pattern-search | RETRIEVE |
post-task --train-neural | agentdb_pattern-store（ReasoningBank，回退memory_store --namespace pattern） | DISTILL |
pretrain（一次性） | hooks_pretrain→ 播种memory_store --namespace patterns | 引导启动 |
这意味着只要配置了这些钩子，每次任务开始前路由推荐会被自动触发，无需每次手动调用技能——但--why的可审计解释仍需显式请求。
实战建议清单
- 先咨询再动手：任何非平凡任务开始前，先跑
hooks_route，命中[CODEMOD_AVAILABLE]就交给hooks_codemod，绝不送 LLM； - 区分确定性意图：
add-types/add-error-handling/async-await即使被意图分类器识别，也必须走模型路由，不要硬套 codemod； - 永远回灌结果：任务结束务必调
hooks_model-outcome，否则路由器不学习、三档边界永远不会自我修正； - 善用验证升级：生成后调用
hooks_model-verify，escalate: true时升档重做，再记录 outcome，让 Bandit 从升级中学习； - 查询与审计：用
hooks_model-stats观察档位分布，用hooks explain复核每一次路由的理由，用--why保留决策痕迹。
八、总结
intelligence-route是 Ruflo 自学习体系中最贴近日常开发的一条技能路径：它用七步闭环把「选谁干活、用什么模型、为什么这么选、选对了没有」全部数据化。Tier 1 的确定性 codemod（ADR-143）让结构性变换以 ~1ms、$0 的成本完成；Tier 2/3 的 Thompson Bandit 路由器在延迟与质量之间持续自我校准；hooks_model-outcome的强制回灌保证了每一次路由都在积累经验。
无论是通过 MCP 工具逐条调用，还是用npx @claude-flow/cli@latest hooks ...命令行批量执行，这套流程都同样可用。深入阅读 intelligence-route/SKILL.md、hooks-tools.ts、enhanced-model-router.ts 与 ADR-143，即可把路由决策完全纳入自己的可审计工作流。
【免费下载链接】ruflo🌊 The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
